Well now I've made further changes and it appears that the carrier must be doing some late night maintenance - because I'm getting 0 replies to my 200 OKs now - so Asterisk just continues to re-generate them endlessly.
On Wed, Feb 9, 2011 at 7:20 PM, Tyler Merritt <tmerr...@fonality.com> wrote: > 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 <bog...@opensips.org> 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 Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
