Re: [OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips
Hi Jeff
Did you ever find a true resolution for the Broadsoft reinvite issue, I'm
experiencing the same issue where OpenSIPS processes the Re-Invite before the
ACK.
This Race Condition causes our Gateway Controller to send a BYE and
disconnect the call.
Any new workaround for this?
Thanks
Albert
On 03 Apr 2010, at 2:21 AM, Jeff Pyle wrote:
If the SDP from the provider in their 200 OK has a c=0.0.0.0, I'd ask the
provider what's up.
I bet it's the provider's SBC not able to handle the fact that Broadworks puts
the SDP on the ACK. I've met a few that handle it incorrectly.
- Jeff
On Apr 2, 2010, at 10:23 AM, Brett Nemeroff wrote:
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.commailto: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.commailto: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.orgmailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.orgmailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.orgmailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.orgmailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.orgmailto:Users@lists.opensips.org
Re: [OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips
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
Re: [OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips
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
Re: [OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips
If the SDP from the provider in their 200 OK has a c=0.0.0.0, I'd ask the
provider what's up.
I bet it's the provider's SBC not able to handle the fact that Broadworks puts
the SDP on the ACK. I've met a few that handle it incorrectly.
- Jeff
On Apr 2, 2010, at 10:23 AM, Brett Nemeroff wrote:
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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips
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
Re: [OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips
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
Re: [OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips
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
Re: [OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips
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
