Just an update on this: it's ridiculously hard. We've done some major surgery on the route logic, and at this point I have the strange condition where opensips seems to be sending multiple ACKs to the carrier on a single reINVITE. The carrier should be sending us two invites - one for each leg of the call (because we are transferring the call into a DID we own).
I am tcpdumping the packets and we have tons of these ACKs flying all directions. I still have to make a mod based on the to domain of the first ACK, but I don't think that is going to clear everything up all at once. Why would we generate multiple ACKs? Some loop in my routing logic? Sent from my iPhone 4 On Feb 4, 2011, at 22:34, Bogdan-Andrei Iancu <[email protected]> wrote: > 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
