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.
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. - Jeff On Apr 2, 2010, at 10:23 AM, Brett Nemeroff wrote: > Jeff, > I used the cfgutils usleep function to achieve the same and it worked > perfectly. The 400 Bad request because of the race condition regarding > the ACK/reinvite is fixed. With one exception.... > > The reINVITE from the BroadSoft has no SDP. > > BroadSoft ---> reINVITE-->OpenSIPS ----> Provider (NO SDP in invite) > Provider ---> 200 OK + SDP ---> OpenSIPs --> Broadsoft (has c=0.0.0.0 in it) > BroadSoft --> ACK + SDP --> OpenSIPs -> Provider (has c=0.0.0.0 in it) > > Needless to say, there is no audio on this call. > > I think it's worth mentioning that: > 1. This is ONE LEG of a simultaneous ring from a BroadSoft > 2. The initial invite for this leg has a c=0.0.0.0 from the BroadSoft > in SDP (before the reINVITE) > > Who's at fault here? Any ideas? > > Thanks, > Brett > > > > > > On Thu, Apr 1, 2010 at 8:24 PM, Jeff Pyle <[email protected]> wrote: >> First, the nuts and bolts. >> >> In the loose_route section: >> >> if (!is_method("ACK")) { >> perl_exec("nonack_delay"); >> } >> >> And, in the Perl file: >> >> sub nonack_delay { >> select(undef,undef,undef,0.060); >> return 1; >> } >> >> I lied. Not 100ms, but 60ms. >> >> 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. >> >> I do believe 400 was the negative response of choice from most UAs subjected >> to the out-of-order ugliness. >> >> >> - Jeff >> >> >> >> On Apr 1, 2010, at 4:21 PM, Brett Nemeroff wrote: >> >>> WOW >>> >>> Ok, well the real question is.. did the 100ms sleep fix your problem? >>> And what was the result of the ordering issue for you? Did you get a >>> 400 from the provider like I'm seeing? >>> >>> >>> I'll give it a shot.. >>> -Brett >>> >>> >>> On Thu, Apr 1, 2010 at 2:56 PM, Jeff Pyle <[email protected]> wrote: >>>> 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. >>>> >>>> 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. >>>> >>>> >>>> - Jeff >>>> >>>> On Apr 1, 2010, at 3:47 PM, Brett Nemeroff wrote: >>>> >>>>> Hello All, >>>>> I'm working with a Broadsoft which is setup to send outbound calls to >>>>> OpenSIPs. The Broadsoft extension is set to ring simultaneously >>>>> multiple extensions. One which hits the proxy and the other is >>>>> internal on the broadsoft. >>>>> >>>>> What I'm seeing is an outbound call from broadsoft to the proxy to the >>>>> provider (normal) >>>>> the provider answers and replies with a 200 OK, forwarded onto >>>>> broadsoft, without problem. >>>>> >>>>> However, then I immediately get a ACK / INVITE FROM the broadsoft in >>>>> reply to the 200 OK. That seems ok, but when it goes to the provider >>>>> the ORDER is switched and it forwards the INVITE first THEN the ACK. >>>>> >>>>> I'm not sure if that matters, but the provider is replying with a 400 >>>>> Bad Request. Which may be because I'm trying to reinvite a call which >>>>> hasn't been ACKd yet? >>>>> >>>>> Any ideas here? why would the order change? And could this potentially >>>>> cause call setup issues? >>>>> >>>>> Thanks, >>>>> Brett >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
