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

[Bogdan-Andrei Iancu]

Hi Jeff,

Jeff Pyle 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. 
For this solution, you can use the usleep function provided by opensips :
       
http://www.opensips.org/html/docs/modules/1.6.x/cfgutils.html#id228403

And you can optimize this a bit by doing sleep only for the non-ACK 
sequential requests - check based on totag.
Also , if you were using dialog support, you can check the dialog state, 
and if there is an re-INVITE for a dialog still in "confirmed but not 
acked" state, do the sleep, otherwise, let it go through.

>  I would certainly love a "real" solution, that is, speeding up the ACK or some other mechanism to enforce the sequence.
>   
The problem is that opensips tries to do something more than it should - 
it tries to match (as transactions) the ACK for 200 OK against the 
INVITE - this is bogus (the the 200 OK ACK and INVITE are separate 
transactions) and the algorithm is very slow and costly - normally this 
is dialog matching and not transaction matching.

I would love to disable that part (and be fully RFC compliant), but this 
will alter some of the current behaviour, like :
    - ACC module is using TM to get the 200OK ACK  - not sure how many 
people are using it.
    - OSP module is using that also, so sure for what purposes.


Regards,
Bogdan


>
> - 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
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro