Hi Tyler,
So ngrep-ing on proxy, you do not see the second re-INVITE (which leads
to one way audio)....A possibility is that the re-INVITE may by-pass
your opensips. Do you do record-routing also for sequential requests ?
There are some bogus UAC/UAS that continuously update the route set,
even after the dialog was setup. So maybe the first re-InVITE works ok
as you correctly do RR for initial INVITE, but second re-INVITE fails
because UAC/UAS expect RR on first re-INVITE too....
Just a supposition
Regards,
Bogdan
Tyler Merritt wrote:
Hi,
We've got three parties for this example: A, B, C
A - Asterisk end-point Polycom
B - Asterisk end-point Polycom
C - Outside end-point Uniden
OpenSIPs sits in front of the Asterisk servers and communicates with a
carrier C5 switch directly (same local area network inside a lab facility)
A calls C - call completes - talk, no issues.
C presses the transfer button, which is a flash-hook putting A on
hold. C dials B.
B answers the call - both parties talk.
C presses the flash-hook button again in order to complete the transfer.
A can hear B - B cannot hear A.
The RTP debug from Asterisk shows that RTP packets from B are still
going to C.
B didn't get the RE-INVITE apparently - but I cannot figure out where
the packet is. It's not showing up in OpenSIPs sip_trace, and it's
definitely not getting to Asterisk.
I don't have control of the Carrier-side C5 to check, and they have
been slow to provide me with a wireshark trace.
Is there anything else I could do in OpenSIPs to determine if the
RE-INVITE is not being handled properly besides what I've already
mentioned?
Thanks in advance.
Tyler
--
Bogdan-Andrei Iancu
OpenSIPS Event - expo, conf, social, bootcamp
2 - 4 February 2011, ITExpo, Miami, USA
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
