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