30 Dec
2005
30 Dec
'05
5:09 p.m.
All,
We have had a new issue arise within openser, basically we
connect to a SIP carrier that uses Asterisk as a proxy. Naturally, this
carrier is hellbent on offloading the RTP traffic, thus the reinvites.
My issue is that they appear to be sending the second invite "too fast",
before the initial RTP even gets a chance to establish. This was working
just fine before, and I believe they changed something. Anyway, they're
refusing to help with this issue, so now I must "fix" it on my end.
OpenSER is in-part, the problem.. See below:
(Sorry if formatting is off, dump from tethereal ..)
0.000000 204.13.233.13 -> 206.80.70.47 SIP/SDP Request: INVITE
sip:8886963856@206.80.70.47, with session description
0.001752 206.80.70.47 -> 204.13.233.13 SIP Status: 100 trying -- your
call is important to us
0.002723 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@sip.stl.netlogic.net, with session description
0.010327 206.80.70.54 -> 206.80.70.47 SIP Status: 100 Trying
0.292175 206.80.70.54 -> 206.80.70.47 SIP Status: 180 Ringing
0.292692 206.80.70.47 -> 204.13.233.13 SIP Status: 180 Ringing
2.016246 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.016893 206.80.70.47 -> 204.13.233.13 SIP/SDP Status: 200 OK, with
session description
2.050871 204.13.233.13 -> 206.80.70.47 SIP Request: ACK
sip:+1314xxxxxxx@206.80.70.54
2.051233 204.13.233.13 -> 206.80.70.47 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54 2.051827 206.80.70.47 -> 204.13.233.13
SIP Status: 100 trying
--<<KABOOM>>--
2.051956 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54,
2.052112 206.80.70.47 -> 206.80.70.54 SIP Request: ACK
sip:+13142664000@206.80.70.54
2.053028 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.053336 206.80.70.54 -> 206.80.70.47 SIP Status: 503 Server error
Where you see "kaboom", is the problem. If you notice, the time between
the first ACK and second INVITE is about 1ms .. While this shouldn't be
a problem, you'll notice when the ACK/INVITES are getting statefully
forwarded, they're getting sent out of order. The end point is an
Asterisk machine, thus the 503 error.
Carrier_Ast --> OpenSER --> Netlogic_Ast
I am using loose_route to forward, just like everyone else, they are
even hitting loose_route in the correct order.. Thoughts? Suggestions?
This seems like something internal to OpenSER, I have tried butchering
the config to force the ACK out first and it just created more problems.
Thanks!
Matt S
31 Dec
31 Dec
2:54 p.m.
Hello,
without the full grep of the packages, I am doing just assumptions.
The ACK is for first INVITE, so the the Asterisk should match it against
the first transaction it created. For the second INVITE, it should wait
for another ACK. This is a common race in IP world due to different path
routing and cannot be avoided, even if you fix something on openser, the
delay may occur on the wire.
The ACK sent for a 200OK is a separate transaction, and it is routed
according to Route headers. You cannot change it in OpenSER/SER unless
you make the proxy to be call stateful, to act as an end User Agent.
I am not sure what the RFC says exactly about how the end User Agent
must act. It may be logically to drop the re-INVITE if the ACK for the
first invite didn't arrive or create a temporary transaction and wait
for both ACKs.
Cheers,
Daniel
On 12/30/05 17:09, Matt Schulte wrote:
All,
We have had a new issue arise within openser, basically we
connect to a SIP carrier that uses Asterisk as a proxy. Naturally, this
carrier is hellbent on offloading the RTP traffic, thus the reinvites.
My issue is that they appear to be sending the second invite "too fast",
before the initial RTP even gets a chance to establish. This was working
just fine before, and I believe they changed something. Anyway, they're
refusing to help with this issue, so now I must "fix" it on my end.
OpenSER is in-part, the problem.. See below:
(Sorry if formatting is off, dump from tethereal ..)
0.000000 204.13.233.13 -> 206.80.70.47 SIP/SDP Request: INVITE
sip:8886963856@206.80.70.47, with session description
0.001752 206.80.70.47 -> 204.13.233.13 SIP Status: 100 trying -- your
call is important to us
0.002723 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@sip.stl.netlogic.net, with session description
0.010327 206.80.70.54 -> 206.80.70.47 SIP Status: 100 Trying
0.292175 206.80.70.54 -> 206.80.70.47 SIP Status: 180 Ringing
0.292692 206.80.70.47 -> 204.13.233.13 SIP Status: 180 Ringing
2.016246 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.016893 206.80.70.47 -> 204.13.233.13 SIP/SDP Status: 200 OK, with
session description
2.050871 204.13.233.13 -> 206.80.70.47 SIP Request: ACK
sip:+1314xxxxxxx@206.80.70.54
2.051233 204.13.233.13 -> 206.80.70.47 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54 2.051827 206.80.70.47 -> 204.13.233.13
SIP Status: 100 trying
--<<KABOOM>>--
2.051956 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54,
2.052112 206.80.70.47 -> 206.80.70.54 SIP Request: ACK
sip:+13142664000@206.80.70.54
2.053028 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.053336 206.80.70.54 -> 206.80.70.47 SIP Status: 503 Server error
Where you see "kaboom", is the problem. If you notice, the time between
the first ACK and second INVITE is about 1ms .. While this shouldn't be
a problem, you'll notice when the ACK/INVITES are getting statefully
forwarded, they're getting sent out of order. The end point is an
Asterisk machine, thus the 503 error.
Carrier_Ast --> OpenSER --> Netlogic_Ast
I am using loose_route to forward, just like everyone else, they are
even hitting loose_route in the correct order.. Thoughts? Suggestions?
This seems like something internal to OpenSER, I have tried butchering
the config to force the ACK out first and it just created more problems.
Thanks!
Matt S
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
2 Jan
2 Jan
4:24 p.m.
I see what you mean, and was worried that would be the answer .. :-)
The ACK is for first INVITE, so the the Asterisk
should match it
against the first transaction it created.
Since the cseq's are different, Asterisk flips out, since it expects the
102 cseq before the 103 .. This is normal behavior, right?
It may be logically to drop the re-INVITE if the ACK
for the first
invite didn't arrive or create a temporary transaction and wait
for both
ACKs.
Well, the cats out of the bag, this carrier doesn't want to disable
reinvites.. I think they have altered the Asterisk code to send a
reinvite ASAP as opposed to 'waiting' for the RTP stream to setup. We
have never ever had this problem before.. For those of you wondering,
the carrier is TXLink..
Any other suggestions? Hehe. Thanks much.
Matt
-----Original Message-----
From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro]
Sent: Saturday, December 31, 2005 6:55 AM
To: Matt Schulte
Cc: users(a)openser.org
Subject: Re: [Users] Dealing with reinvites
Hello,
without the full grep of the packages, I am doing just assumptions.
The ACK is for first INVITE, so the the Asterisk should match it against
the first transaction it created. For the second INVITE, it should wait
for another ACK. This is a common race in IP world due to different path
routing and cannot be avoided, even if you fix something on openser, the
delay may occur on the wire.
The ACK sent for a 200OK is a separate transaction, and it is routed
according to Route headers. You cannot change it in OpenSER/SER unless
you make the proxy to be call stateful, to act as an end User Agent.
I am not sure what the RFC says exactly about how the end User Agent
must act. It may be logically to drop the re-INVITE if the ACK for the
first invite didn't arrive or create a temporary transaction and wait
for both ACKs.
Cheers,
Daniel
On 12/30/05 17:09, Matt Schulte wrote:
All,
We have had a new issue arise within openser, basically we
connect to
a SIP carrier that uses Asterisk as a proxy.
Naturally, this carrier
is hellbent on offloading the RTP traffic, thus the reinvites.
My issue is that they appear to be sending the second invite "too
fast", before the initial RTP even gets a chance to establish. This
was working just fine before, and I believe they changed something.
Anyway, they're refusing to help with this issue, so now I must "fix"
it on my end.
OpenSER is in-part, the problem.. See below:
(Sorry if formatting is off, dump from tethereal ..)
0.000000 204.13.233.13 -> 206.80.70.47 SIP/SDP Request: INVITE
sip:8886963856@206.80.70.47, with session description
0.001752 206.80.70.47 -> 204.13.233.13 SIP Status: 100 trying --
your call is important to us
0.002723 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@sip.stl.netlogic.net, with session description
0.010327 206.80.70.54 -> 206.80.70.47 SIP Status: 100 Trying
0.292175 206.80.70.54 -> 206.80.70.47 SIP Status: 180 Ringing
0.292692 206.80.70.47 -> 204.13.233.13 SIP Status: 180 Ringing
2.016246 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.016893 206.80.70.47 -> 204.13.233.13 SIP/SDP Status: 200 OK, with
session description
2.050871 204.13.233.13 -> 206.80.70.47 SIP Request: ACK
sip:+1314xxxxxxx@206.80.70.54
2.051233 204.13.233.13 -> 206.80.70.47 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54 2.051827 206.80.70.47 -> 204.13.233.13
SIP Status: 100 trying
--<<KABOOM>>--
2.051956 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54,
2.052112 206.80.70.47 -> 206.80.70.54 SIP Request: ACK
sip:+13142664000@206.80.70.54
2.053028 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.053336 206.80.70.54 -> 206.80.70.47 SIP Status: 503 Server error
Where you see "kaboom", is the problem. If you notice, the time
between the first ACK and second INVITE is about 1ms .. While this
shouldn't be a problem, you'll notice when the ACK/INVITES are getting
statefully forwarded, they're getting sent out of
order. The end point
is an Asterisk machine, thus the 503 error.
Carrier_Ast --> OpenSER --> Netlogic_Ast
I am using loose_route to forward, just like everyone else, they are
even hitting loose_route in the correct order.. Thoughts? Suggestions?
This seems like something internal to OpenSER, I have tried butchering
the config to force the ACK out first and it just
created more
problems.
Thanks!
Matt S
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
7:10 p.m.
I'm not sure what the standard says, but AFAIK the dialog is confirmed
with 200 Ok from the first INVITE. Thus, Asterisk should accept the new
reINVITE although the ACK was not received yet. (IMO, receiving an
reINVITE imply that the previous 200 Ok was ACKnowledged).
IMO Asterisk should accept the reINVITE (just like when the ACK was
received, thus stopping retransmissions). If then the ACK is received,
the CSeq does not match, thus it should be ignored.
Which Asterisk version do you use? 1.2.1? Try to discuss the problem on
the devel mailing list, and create a bug report on bugs.digium.com with
suggested proposals how to fix the problem.
regards
klaus
Matt Schulte wrote:
I see what you mean, and was worried that would be the
answer .. :-)
The ACK is for first INVITE, so the the Asterisk
should match it
against the first transaction it created.
Since the cseq's are different, Asterisk flips out, since it expects the
102 cseq before the 103 .. This is normal behavior, right?
It may be logically to drop the re-INVITE if the
ACK for the first
invite didn't arrive or create a temporary transaction and wait for both
ACKs.
Well, the cats out of the bag, this carrier doesn't want to disable
reinvites.. I think they have altered the Asterisk code to send a
reinvite ASAP as opposed to 'waiting' for the RTP stream to setup. We
have never ever had this problem before.. For those of you wondering,
the carrier is TXLink..
Any other suggestions? Hehe. Thanks much.
Matt
-----Original Message-----
From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro]
Sent: Saturday, December 31, 2005 6:55 AM
To: Matt Schulte
Cc: users(a)openser.org
Subject: Re: [Users] Dealing with reinvites
Hello,
without the full grep of the packages, I am doing just assumptions.
The ACK is for first INVITE, so the the Asterisk should match it against
the first transaction it created. For the second INVITE, it should wait
for another ACK. This is a common race in IP world due to different path
routing and cannot be avoided, even if you fix something on openser, the
delay may occur on the wire.
The ACK sent for a 200OK is a separate transaction, and it is routed
according to Route headers. You cannot change it in OpenSER/SER unless
you make the proxy to be call stateful, to act as an end User Agent.
I am not sure what the RFC says exactly about how the end User Agent
must act. It may be logically to drop the re-INVITE if the ACK for the
first invite didn't arrive or create a temporary transaction and wait
for both ACKs.
Cheers,
Daniel
On 12/30/05 17:09, Matt Schulte wrote:
All,
We have had a new issue arise within openser, basically we
connect to
a SIP carrier that uses Asterisk as a proxy.
Naturally, this carrier
is hellbent on offloading the RTP traffic, thus the reinvites.
My issue is that they appear to be sending the second invite "too
fast", before the initial RTP even gets a chance to establish. This
was working just fine before, and I believe they changed something.
Anyway, they're refusing to help with this issue, so now I must "fix"
it on my end.
OpenSER is in-part, the problem.. See below:
(Sorry if formatting is off, dump from tethereal ..)
0.000000 204.13.233.13 -> 206.80.70.47 SIP/SDP Request: INVITE
sip:8886963856@206.80.70.47, with session description
0.001752 206.80.70.47 -> 204.13.233.13 SIP Status: 100 trying --
your call is important to us
0.002723 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@sip.stl.netlogic.net, with session description
0.010327 206.80.70.54 -> 206.80.70.47 SIP Status: 100 Trying
0.292175 206.80.70.54 -> 206.80.70.47 SIP Status: 180 Ringing
0.292692 206.80.70.47 -> 204.13.233.13 SIP Status: 180 Ringing
2.016246 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.016893 206.80.70.47 -> 204.13.233.13 SIP/SDP Status: 200 OK, with
session description
2.050871 204.13.233.13 -> 206.80.70.47 SIP Request: ACK
sip:+1314xxxxxxx@206.80.70.54
2.051233 204.13.233.13 -> 206.80.70.47 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54 2.051827 206.80.70.47 -> 204.13.233.13
SIP Status: 100 trying
--<<KABOOM>>--
2.051956 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54,
2.052112 206.80.70.47 -> 206.80.70.54 SIP Request: ACK
sip:+13142664000@206.80.70.54
2.053028 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.053336 206.80.70.54 -> 206.80.70.47 SIP Status: 503 Server error
Where you see "kaboom", is the problem. If you notice, the time
between the first ACK and second INVITE is about 1ms .. While this
shouldn't be a problem, you'll notice when the ACK/INVITES are getting
statefully forwarded, they're getting sent out
of order. The end point
is an Asterisk machine, thus the 503 error.
Carrier_Ast --> OpenSER --> Netlogic_Ast
I am using loose_route to forward, just like everyone else, they are
even hitting loose_route in the correct order.. Thoughts? Suggestions?
This seems like something internal to OpenSER, I have tried butchering
the config to force the ACK out first and it just
created more
problems.
Thanks!
Matt S
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
2:26 p.m.
Matt Schulte wrote:
--<<KABOOM>>--
2.051956 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54,
2.052112 206.80.70.47 -> 206.80.70.54 SIP Request: ACK
sip:+13142664000@206.80.70.54
2.053028 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.053336 206.80.70.54 -> 206.80.70.47 SIP Status: 503 Server error
Asterisk behaves a little bit weird: it first says 200 Ok, then 503.
What is the status of the call after the 503? Is the call still open in
your aserisk? How does the Carriers Gateway react?
regards
klaus
Where you see "kaboom", is the problem. If you notice, the time between
the first ACK and second INVITE is about 1ms .. While this shouldn't be
a problem, you'll notice when the ACK/INVITES are getting statefully
forwarded, they're getting sent out of order. The end point is an
Asterisk machine, thus the 503 error.
Carrier_Ast --> OpenSER --> Netlogic_Ast
I am using loose_route to forward, just like everyone else, they are
even hitting loose_route in the correct order.. Thoughts? Suggestions?
This seems like something internal to OpenSER, I have tried butchering
the config to force the ACK out first and it just created more problems.
Thanks!
Matt S
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
4:19 p.m.
Thanks for the response (You too Daniel :-) .. ) Ast is OK'ing the
invite, but since the ACK should have come first, it passes the 503.
Outcome is random, the RTP usually establishes at least one direction.
Since the call leg is destroyed the call is not billed, nor can it be
BYE'd or 487'd ..
After that cap, confusion sets in between our carrier and OpenSER box.
Usually a pattern of OK's and 503's..
-----Original Message-----
From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Sent: Monday, January 02, 2006 6:26 AM
To: Matt Schulte
Cc: users(a)openser.org
Subject: Re: [Users] Dealing with reinvites
Matt Schulte wrote:
--<<KABOOM>>--
2.051956 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54,
2.052112 206.80.70.47 -> 206.80.70.54 SIP Request: ACK
sip:+13142664000@206.80.70.54
2.053028 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.053336 206.80.70.54 -> 206.80.70.47 SIP Status: 503 Server error
Asterisk behaves a little bit weird: it first says 200 Ok, then 503.
What is the status of the call after the 503? Is the call still open in
your aserisk? How does the Carriers Gateway react?
regards
klaus
Where you see "kaboom", is the problem. If you notice, the time
between the first ACK and second INVITE is about 1ms .. While this
shouldn't be a problem, you'll notice when the ACK/INVITES are getting
statefully forwarded, they're getting sent out of
order. The end point
is an Asterisk machine, thus the 503 error.
Carrier_Ast --> OpenSER --> Netlogic_Ast
I am using loose_route to forward, just like everyone else, they are
even hitting loose_route in the correct order.. Thoughts? Suggestions?
This seems like something internal to OpenSER, I have tried butchering
the config to force the ACK out first and it just
created more
problems.
Thanks!
Matt S
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6899
days inactive
6902
days old
5 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Klaus Darilion -
Matt Schulte