Well now I&#39;ve made further changes and it appears that the carrier must be doing some late night maintenance - because I&#39;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">&lt;<a href="mailto:tmerritt@fonality.com">tmerritt@fonality.com</a>&gt;</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&#39;s ridiculously hard.<br>
<br>
We&#39;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&#39;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 &lt;<a href="mailto:bogdan@opensips.org">bogdan@opensips.org</a>&gt; wrote:<br>
<br>
&gt; Hi Tyler,<br>
&gt;<br>
&gt; 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>


&gt;<br>
&gt; Just a supposition<br>
&gt;<br>
&gt; Regards,<br>
&gt; Bogdan<br>
&gt;<br>
&gt; Tyler Merritt wrote:<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; We&#39;ve got three parties for this example:  A, B, C<br>
&gt;&gt;<br>
&gt;&gt; A - Asterisk end-point Polycom<br>
&gt;&gt;<br>
&gt;&gt; B - Asterisk end-point Polycom<br>
&gt;&gt;<br>
&gt;&gt; C - Outside end-point Uniden<br>
&gt;&gt;<br>
&gt;&gt; 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>
&gt;&gt;<br>
&gt;&gt; A calls C - call completes - talk, no issues.<br>
&gt;&gt;<br>
&gt;&gt; C presses the transfer button, which is a flash-hook putting A on hold.  C dials B.<br>
&gt;&gt;<br>
&gt;&gt; B answers the call - both parties talk.<br>
&gt;&gt;<br>
&gt;&gt; C presses the flash-hook button again in order to complete the transfer.<br>
&gt;&gt;<br>
&gt;&gt; A can hear B - B cannot hear A.<br>
&gt;&gt;<br>
&gt;&gt; The RTP debug from Asterisk shows that RTP packets from B are still going to C.<br>
&gt;&gt;<br>
&gt;&gt; B didn&#39;t get the RE-INVITE apparently - but I cannot figure out where the packet is.  It&#39;s not showing up in OpenSIPs sip_trace, and it&#39;s definitely not getting to Asterisk.<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t have control of the Carrier-side C5 to check, and they have been slow to provide me with a wireshark trace.<br>
&gt;&gt; Is there anything else I could do in OpenSIPs to determine if the RE-INVITE is not being handled properly besides what I&#39;ve already mentioned?<br>
&gt;&gt;<br>
&gt;&gt; Thanks in advance.<br>
&gt;&gt;<br>
&gt;&gt; Tyler<br>
&gt;<br>
&gt; --<br>
&gt; Bogdan-Andrei Iancu<br>
&gt; OpenSIPS Event - expo, conf, social, bootcamp<br>
&gt; 2 - 4 February 2011, ITExpo, Miami,  USA<br>
&gt; OpenSIPS solutions and &quot;know-how&quot;<br>
&gt;<br>
</div></div></blockquote></div><br>