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
