[OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips

[Brett Nemeroff]

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 <jpyle at fidelityvoice.com> 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 <jpyle at fidelityvoice.com> 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
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>