<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Jeff<div><br></div><div>Did you ever find a true resolution for the Broadsoft reinvite issue, I'm experiencing the same issue where OpenSIPS processes the Re-Invite before the ACK.</div><div><br></div><div>This "Race Condition" causes our Gateway Controller to send a BYE and disconnect the call.</div><div><br></div><div>Any new workaround for this?</div><div><br></div><div>Thanks</div><div><br></div><div>Albert</div><div><br></div><div><div>On 03 Apr 2010, at 2:21 AM, Jeff Pyle wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>If the SDP from the provider in their 200 OK has a c=0.0.0.0, I'd ask the provider what's up.<br><br>I bet it's the provider's SBC not able to handle the fact that Broadworks puts the SDP on the ACK. I've met a few that handle it incorrectly.<br><br><br>- Jeff<br><br><br>On Apr 2, 2010, at 10:23 AM, Brett Nemeroff wrote:<br><br><blockquote type="cite">Jeff,<br></blockquote><blockquote type="cite">I used the cfgutils usleep function to achieve the same and it worked<br></blockquote><blockquote type="cite">perfectly. The 400 Bad request because of the race condition regarding<br></blockquote><blockquote type="cite">the ACK/reinvite is fixed. With one exception....<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The reINVITE from the BroadSoft has no SDP.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">BroadSoft ---> reINVITE-->OpenSIPS ----> Provider (NO SDP in invite)<br></blockquote><blockquote type="cite">Provider ---> 200 OK + SDP ---> OpenSIPs --> Broadsoft (has c=0.0.0.0 in it)<br></blockquote><blockquote type="cite">BroadSoft --> ACK + SDP --> OpenSIPs -> Provider (has c=0.0.0.0 in it)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Needless to say, there is no audio on this call.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I think it's worth mentioning that:<br></blockquote><blockquote type="cite">1. This is ONE LEG of a simultaneous ring from a BroadSoft<br></blockquote><blockquote type="cite">2. The initial invite for this leg has a c=0.0.0.0 from the BroadSoft<br></blockquote><blockquote type="cite">in SDP (before the reINVITE)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Who's at fault here? Any ideas?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thanks,<br></blockquote><blockquote type="cite">Brett<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Thu, Apr 1, 2010 at 8:24 PM, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a>> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">First, the nuts and bolts.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In the loose_route section:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> if (!is_method("ACK")) {<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> perl_exec("nonack_delay");<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> }<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">And, in the Perl file:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> sub nonack_delay {<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> select(undef,undef,undef,0.060);<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> return 1;<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> }<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I lied. Not 100ms, but 60ms.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">This worked like a champ, at the cost of keeping a non-ACK message fermenting in the process for exactly 60ms longer than it otherwise would have. A bit of a kick in teeth to scalability but I saw no other solution.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I do believe 400 was the negative response of choice from most UAs subjected to the out-of-order ugliness.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- Jeff<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On Apr 1, 2010, at 4:21 PM, Brett Nemeroff wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">WOW<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Ok, well the real question is.. did the 100ms sleep fix your problem?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">And what was the result of the ordering issue for you? Did you get a<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">400 from the provider like I'm seeing?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I'll give it a shot..<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-Brett<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Thu, Apr 1, 2010 at 2:56 PM, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a>> wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This goes way back. Bogdan addressed it last year sometime, citing a reason why ACK processing is slower than other processing. And, since the two messages hit different children of Opensips, the ACK hits the exit gate after the reINVITE, even though the ACK arrived first. I've seen it with Broadworks and Asterisk.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">There were a number of solutions posted although none of them worked for me. My workaround is to call a perl script to sleep for 100ms if the message is not an ACK. That allows the ACK time to get through. I would certainly love a "real" solution, that is, speeding up the ACK or some other mechanism to enforce the sequence.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- Jeff<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Apr 1, 2010, at 3:47 PM, Brett Nemeroff wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hello All,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I'm working with a Broadsoft which is setup to send outbound calls to<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">OpenSIPs. The Broadsoft extension is set to ring simultaneously<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">multiple extensions. One which hits the proxy and the other is<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">internal on the broadsoft.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">What I'm seeing is an outbound call from broadsoft to the proxy to the<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">provider (normal)<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the provider answers and replies with a 200 OK, forwarded onto<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">broadsoft, without problem.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">However, then I immediately get a ACK / INVITE FROM the broadsoft in<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">reply to the 200 OK. That seems ok, but when it goes to the provider<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the ORDER is switched and it forwards the INVITE first THEN the ACK.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I'm not sure if that matters, but the provider is replying with a 400<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Bad Request. Which may be because I'm trying to reinvite a call which<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">hasn't been ACKd yet?<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Any ideas here? why would the order change? And could this potentially<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">cause call setup issues?<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Thanks,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Brett<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Users mailing list<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Users mailing list<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Users mailing list<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Users mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Users mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br></blockquote><blockquote type="cite"><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></blockquote><br><br>_______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>http://lists.opensips.org/cgi-bin/mailman/listinfo/users<br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt; ">Internet Solutions<br>Tel: +27(0)87 356 6566<br>Cell: +27(0)78 803 2800<br>VoIS: +27(0)87 350 0118<br>Web: <a href="http://www.is.co.za/vois">www.is.co.za/vois</a> <<a href="http://www.is.co.za/vois">http://www.is.co.za/vois</a>> </span></font></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br>
<FONT face=Verdana size=1>Please note: This email and its content are
subject to the disclaimer as displayed at the following link </FONT><A
href="http://www.is.co.za/legal/E-mail+Confidentiality+Notice+and+Disclaimer.htm"><FONT
face=Verdana
size=1>http://www.is.co.za/legal/E-mail+Confidentiality+Notice+and+Disclaimer.htm</FONT></A><FONT
face=Verdana size=1>. Should you not have Web access, send an email to </FONT><A
href="mailto:mdisclaimers@is.co.za"><FONT face=Verdana
size=1>disclaimers@is.co.za</FONT></A><FONT face=Verdana size=1> and a copy will
be sent to you.</FONT>
</body></html>