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@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
--
Bogdan-Andrei Iancu
www.voice-system.ro
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
