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. <br>
<br><br><div class="gmail_quote">On Wed, Feb 9, 2011 at 7:20 PM, Tyler Merritt <span dir="ltr"><<a href="mailto:tmerritt@fonality.com">tmerritt@fonality.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Just an update on this: it's ridiculously hard.<br>
<br>
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).<br>
<br>
I am tcpdumping the packets and we have tons of these ACKs flying all directions.<br>
<br>
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.<br>
<br>
Why would we generate multiple ACKs? Some loop in my routing logic?<br>
<br>
Sent from my iPhone 4<br>
<div><div></div><div class="h5"><br>
On Feb 4, 2011, at 22:34, Bogdan-Andrei Iancu <<a href="mailto:bogdan@opensips.org">bogdan@opensips.org</a>> wrote:<br>
<br>
> Hi Tyler,<br>
><br>
> 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....<br>
><br>
> Just a supposition<br>
><br>
> Regards,<br>
> Bogdan<br>
><br>
> Tyler Merritt wrote:<br>
>> Hi,<br>
>><br>
>> We've got three parties for this example: A, B, C<br>
>><br>
>> A - Asterisk end-point Polycom<br>
>><br>
>> B - Asterisk end-point Polycom<br>
>><br>
>> C - Outside end-point Uniden<br>
>><br>
>> OpenSIPs sits in front of the Asterisk servers and communicates with a carrier C5 switch directly (same local area network inside a lab facility)<br>
>><br>
>> A calls C - call completes - talk, no issues.<br>
>><br>
>> C presses the transfer button, which is a flash-hook putting A on hold. C dials B.<br>
>><br>
>> B answers the call - both parties talk.<br>
>><br>
>> C presses the flash-hook button again in order to complete the transfer.<br>
>><br>
>> A can hear B - B cannot hear A.<br>
>><br>
>> The RTP debug from Asterisk shows that RTP packets from B are still going to C.<br>
>><br>
>> 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.<br>
>><br>
>> I don't have control of the Carrier-side C5 to check, and they have been slow to provide me with a wireshark trace.<br>
>> 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?<br>
>><br>
>> Thanks in advance.<br>
>><br>
>> Tyler<br>
><br>
> --<br>
> Bogdan-Andrei Iancu<br>
> OpenSIPS Event - expo, conf, social, bootcamp<br>
> 2 - 4 February 2011, ITExpo, Miami, USA<br>
> OpenSIPS solutions and "know-how"<br>
><br>
</div></div></blockquote></div><br>