12 Nov
2010
12 Nov
'10
12:51 a.m.
Hi All,
Asterisk><kamailio 3.0.2><sip carrier
I see normal tansactions until the carrier send back a '486 Busy Here'
then kamailio sends an 'INVITE SDP', then I get a '100 trying' from
the carrier then a '482 Loop Detected" from the carrier.
Shouldn't kamailio relay the 486 to the original invite server and not send SDP?
I'm guessing I'm not handling 486 propperly in my config:
http://pastebin.com/crfMe81D
Here is a pastebin of the call graph:
http://pastebin.com/rnQZDyFU
I was thinking about including this in my failure route:
if (t_check_status("486")) {
append_branch();
t_relay();
}
Would that do any good?
Thanks.
JR
--
JR Richardson
Engineering for the Masses
12 Nov
12 Nov
2:29 a.m.
2010/11/11 JR Richardson <jmr.richardson(a)gmail.com>om>:
I was thinking about including this in my failure
route:
if (t_check_status("486")) {
append_branch();
t_relay();
}
Would that do any good?
The above code instructs Kamailio to create a new branch to the same
destination upon receipt of hte 486 response. So obviously it's wrong.
What do you want to achieve with the above code??
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:17 a.m.
On Thu, Nov 11, 2010 at 6:29 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2010/11/11 JR Richardson
<jmr.richardson(a)gmail.com>om>:
Hello,
The idea is to receive the 486 from the carrier and not send the
INVITE SDP back to the carrier, this is causing the carrier to send a
482 loop detected. I would like to recognize the 486 response from
the carrier as a busy and relay it to the original INVITE server then
exit, so then another route can be processed by the INVITE server and
not handled as a loop and dropped.
I don't understand why kamailio would send an ACK then an INVITE SDP
to the carrier after receiveng a 486 Busy?
So the append_branch should not be used, ok, what about just the
t_relay and exit?
if (t_check_status("486")) {
t_relay();
exit;
}
Would this work?
This is a production system, so I can't just throw trial and error
code at it and hope it works. I'm not sure how to mock up and test
the various codes I'm seeing from the carrier. My test lab works
great with basic functionality and execution, I'm only seeing some of
these scenarios in production.
Thanks for your suggestions.
JR
--
JR Richardson
Engineering for the Masses
I was thinking about including this in my failure
route:
if (t_check_status("486")) {
append_branch();
t_relay();
}
Would that do any good?
The above code instructs Kamailio to create a new branch to the same
destination upon receipt of hte 486 response. So obviously it's wrong.
What do you want to achieve with the above code??
--
Iñaki Baz Castillo
<ibc(a)aliax.net> 
4:18 a.m.
On 11/11/2010 09:17 PM, JR Richardson wrote:
So the append_branch should not be used, ok, what
about just the
t_relay and exit?
if (t_check_status("486")) {
t_relay();
exit;
}
Would this work?
This is a failure route, a special type of reply route. Replies are
automatically passed back, unless explicitly dropped or suppressed due
to serial forking via a new branch.
So, you don't need to do t_relay() for the response to get back to the
sender. In fact, you shouldn't, because this will be taken by Kamailio
to mean something different than you intend.
The t_relay() call is only for statefully relaying _requests_.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
10:25 p.m.
Hello,
On 11/12/10 3:17 AM, JR Richardson wrote:
On Thu, Nov 11, 2010 at 6:29 PM, Iñaki Baz
Castillo<ibc(a)aliax.net> wrote:
First, if you create a new branch and send to same SIP gateway
and you
get loop detected, then the gateway is broken. It does not see that
there is a different branch value in the top Via header.
2010/11/11 JR
Richardson<jmr.richardson(a)gmail.com>om>:
Hello,
The idea is to receive the 486 from the carrier and not send the
INVITE SDP back to the carrier, this is causing the carrier to send a
482 loop detected. I was thinking about including this in my failure
route:
if (t_check_status("486")) {
append_branch();
t_relay();
}
Would that do any good?
The above code instructs Kamailio to create a new branch
to the same
destination upon receipt of hte 486 response. So obviously it's wrong.
What do you want to achieve with the above code??
--
Iñaki Baz Castillo
<ibc(a)aliax.net> I would like to recognize the 486 response from
the carrier as a busy and relay it to the original INVITE server then
exit, so then another route can be processed by the INVITE server and
not handled as a loop and dropped.
I don't understand why kamailio would send an ACK then an INVITE SDP
to the carrier after receiveng a 486 Busy?
So the append_branch should not be used, ok, what about just the
t_relay and exit?
if (t_check_status("486")) {
t_relay();
exit;
}
Would this work?
t_relay() is only for SIP __requests__, not for SIP __replies__.
If you want to let the 486 go back to the initiator of INVITE, just exit
the failure route:
if (t_check_status("486")) {
exit;
}
In case you want to change the reply code to something else, then you
can use t_reply() to overwrite the reply received, for example, change
the 486 is 404:
if (t_check_status("486")) {
t_reply("404", "Not found");
exit;
}
This is a production system, so I can't just throw
trial and error
code at it and hope it works. I'm not sure how to mock up and test
the various codes I'm seeing from the carrier. My test lab works
great with basic functionality and execution, I'm only seeing some of
these scenarios in production.
So far, I haven't seen a better testing suite than a production
environment ;-)
Cheers,
Daniel
Thanks for your suggestions.
JR
--
Daniel-Constantin Mierla
http://www.asipto.com
13 Nov
13 Nov
4:09 p.m.
2010/11/12 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hi Daniel, the 482 reply is correct:
----------------------------------------------------------------------------------
RFC 3261 - 8.2.2.2 Merged Requests
If the request has no tag in the To header field, the UAS core MUST
check the request against ongoing transactions. If the From tag,
Call-ID, and CSeq exactly match those associated with an ongoing
transaction, but the request does not match that transaction (based
on the matching rules in Section 17.2.3), the UAS core SHOULD
generate a 482 (Loop Detected) response and pass it to the server
transaction.
The same request has arrived at the UAS more than once, following
different paths, most likely due to forking. The UAS processes
the first such request received and responds with a 482 (Loop
Detected) to the rest of them.
----------------------------------------------------------------------------------
This is exactly the case the user is experimenting: the INVITE arrives
twice to the same server, with same From tag, Call-ID and CSeq, but
different branch/transaction. So 482 is the correct response.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
The idea is to
receive the 486 from the carrier and not send the
INVITE SDP back to the carrier, this is causing the carrier to send a
482 loop detected.
First, if you create a new branch and send to same SIP gateway and you get
loop detected, then the gateway is broken. It does not see that there is a
different branch value in the top Via header.
6:42 p.m.
-----Original Message-----
From: Iñaki Baz Castillo [mailto:ibc@aliax.net]
Sent: Saturday, November 13, 2010 8:10 AM
To: Daniel-Constantin Mierla
Cc: JR Richardson; SR-Users
Subject: Re: [SR-Users] Handle '486 busy here' from upstream carrier
2010/11/12 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
get
[JR Richardson]
So I think I figured out what is going on here, I'm not configured correctly
for this upstream carrier, using Dispatcher with only one server is causing
the issue. When I get a failure or busy, I am branching back to the same
server and there is the problem, I should not call ds_next_dst(); in my
failure route for this carrier because there are no more destination
servers.
I think this is causing another problem I am seeing as well so I will focus
on this for a bit and see if I can get it worked out.
Thanks you for your advice and clarification.
JR
The idea
is to receive the 486 from the carrier and not send the
INVITE SDP back to the carrier, this is causing the carrier to send a
482 loop detected.
First, if you create a new branch and send to same SIP gateway and you loop detected, then the gateway is broken. It
does not see that there is
a
different branch value in the top Via header.
Hi Daniel, the 482 reply is correct:
--------------------------------------------------------------------------
--------
RFC 3261 - 8.2.2.2 Merged Requests
If the request has no tag in the To header field, the UAS core MUST
check the request against ongoing transactions. If the From tag,
Call-ID, and CSeq exactly match those associated with an ongoing
transaction, but the request does not match that transaction (based
on the matching rules in Section 17.2.3), the UAS core SHOULD
generate a 482 (Loop Detected) response and pass it to the server
transaction.
The same request has arrived at the UAS more than once, following
different paths, most likely due to forking. The UAS processes
the first such request received and responds with a 482 (Loop
Detected) to the rest of them.
--------------------------------------------------------------------------
--------
This is exactly the case the user is experimenting: the INVITE arrives
twice to the same server, with same From tag, Call-ID and CSeq, but
different branch/transaction. So 482 is the correct response.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
15 Nov
15 Nov
5:13 p.m.
On 11/13/10 5:42 PM, JR Richardson wrote:
It is what I spotted in a
previous email. ds_next_dst() should be used
in a IF condition and only when the returned value is true, then relay
again.
Cheers,
Daniel
-----Original
Message-----
From: Iñaki Baz Castillo [mailto:ibc@aliax.net]
Sent: Saturday, November 13, 2010 8:10 AM
To: Daniel-Constantin Mierla
Cc: JR Richardson; SR-Users
Subject: Re: [SR-Users] Handle '486 busy here' from upstream carrier
2010/11/12 Daniel-Constantin Mierla<miconda(a)gmail.com>om>:
get
[JR Richardson]
So I think I figured out what is going on here, I'm not configured correctly
for this upstream carrier, using Dispatcher with only one server is causing
the issue. When I get a failure or busy, I am branching back to the same
server and there is the problem, I should not call ds_next_dst(); in my
failure route for this carrier because there are no more destination
servers.
I think this is causing another problem I am seeing as well so I will focus
on this for a bit and see if I can get it worked out. The idea
is to receive the 486 from the carrier and not send the
INVITE SDP back to the carrier, this is causing the carrier to send a
482 loop detected.
First, if you create a new branch and send to same SIP gateway
and you loop detected, then the gateway is broken. It
does not see that there is
a
different branch value in the top Via header.
Hi Daniel, the 482 reply is correct:
--------------------------------------------------------------------------
--------
RFC 3261 - 8.2.2.2 Merged Requests
If the request has no tag in the To header field, the UAS core MUST
check the request against ongoing transactions. If the From tag,
Call-ID, and CSeq exactly match those associated with an ongoing
transaction, but the request does not match that transaction (based
on the matching rules in Section 17.2.3), the UAS core SHOULD
generate a 482 (Loop Detected) response and pass it to the server
transaction.
The same request has arrived at the UAS more than once, following
different paths, most likely due to forking. The UAS processes
the first such request received and responds with a 482 (Loop
Detected) to the rest of them.
--------------------------------------------------------------------------
--------
This is exactly the case the user is experimenting: the INVITE arrives
twice to the same server, with same From tag, Call-ID and CSeq, but
different branch/transaction. So 482 is the correct response.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net> Thanks you for your advice and clarification.
JR
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
10:01 p.m.
On Mon, Nov 15, 2010 at 9:13 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
On 11/13/10 5:42 PM, JR Richardson wrote:
It is what I spotted in a previous email. ds_next_dst() should be used in a
IF condition and only when the returned value is true, then relay again.
Yes, my ds_next_dst() is wrapped in an if statement:
if(ds_next_dst()) {
append_branch();
t_on_failure("FAIL_ONE");
t_relay();
}
I was able to mock up a failure test and what I am seeing is the
append_branch() is causing the retransmit of the invite back to the
failed server, which in turn causes the loop error. But if I take the
append_branch() out of the failure route, then I get these errors:
ERROR: t_forward_nonack: no branches for forwarding
ERROR: w_t_relay_to: t_relay_to failed
So I don't understand the purpose of the append_branch() in a failure
and why it is retransmitting the invite back to a failed server?
I also found that specifying an error code and exiting will work and
not retransmit the invite back to the failed server.
if (t_check_status("404")) {
xlog("L_INFO", "request is 404 - exit\n");
exit;
}
Thanks.
JR
--
JR Richardson
Engineering for the Masses
-----Original Message-----
From: Iñaki Baz Castillo [mailto:ibc@aliax.net]
Sent: Saturday, November 13, 2010 8:10 AM
To: Daniel-Constantin Mierla
Cc: JR Richardson; SR-Users
Subject: Re: [SR-Users] Handle '486 busy here' from upstream carrier
2010/11/12 Daniel-Constantin Mierla<miconda(a)gmail.com>om>:
[JR Richardson]
So I think I figured out what is going on here, I'm not configured
correctly
for this upstream carrier, using Dispatcher with only one server is
causing
the issue. When I get a failure or busy, I am branching back to the same
server and there is the problem, I should not call ds_next_dst(); in my
failure route for this carrier because there are no more destination
servers.
I think this is causing another problem I am seeing as well so I will
focus
on this for a bit and see if I can get it worked out. >
> The idea is to receive the 486 from the carrier and not send the
> INVITE SDP back to the carrier, this is causing the carrier to send a
> 482 loop detected.
First, if you create a new branch and send to same SIP gateway and you
get
loop detected, then the gateway is broken. It does not see that there is
a
different branch value in the top Via header.
Hi Daniel, the 482 reply is correct:
--------------------------------------------------------------------------
--------
RFC 3261 - 8.2.2.2 Merged Requests
If the request has no tag in the To header field, the UAS core MUST
check the request against ongoing transactions. If the From tag,
Call-ID, and CSeq exactly match those associated with an ongoing
transaction, but the request does not match that transaction (based
on the matching rules in Section 17.2.3), the UAS core SHOULD
generate a 482 (Loop Detected) response and pass it to the server
transaction.
The same request has arrived at the UAS more than once, following
different paths, most likely due to forking. The UAS processes
the first such request received and responds with a 482 (Loop
Detected) to the rest of them.
--------------------------------------------------------------------------
--------
This is exactly the case the user is experimenting: the INVITE arrives
twice to the same server, with same From tag, Call-ID and CSeq, but
different branch/transaction. So 482 is the correct response.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:12 p.m.
Hello,
On 11/13/10 3:09 PM, Iñaki Baz Castillo wrote:
2010/11/12 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
Hi Daniel, the 482 reply is correct:
I expected the r-uri changes as well (serial forking). In regard to this
similar case, there is a difference between loop detection and spirals,
maybe sorted out in a follow-up rfc.
Cheers,
Daniel
The idea
is to receive the 486 from the carrier and not send the
INVITE SDP back to the carrier, this is causing the carrier to send a
482 loop detected.
First, if you create a new branch and send to same SIP gateway
and you get
loop detected, then the gateway is broken. It does not see that there is a
different branch value in the top Via header.
----------------------------------------------------------------------------------
RFC 3261 - 8.2.2.2 Merged Requests
If the request has no tag in the To header field, the UAS core MUST
check the request against ongoing transactions. If the From tag,
Call-ID, and CSeq exactly match those associated with an ongoing
transaction, but the request does not match that transaction (based
on the matching rules in Section 17.2.3), the UAS core SHOULD
generate a 482 (Loop Detected) response and pass it to the server
transaction.
The same request has arrived at the UAS more than once, following
different paths, most likely due to forking. The UAS processes
the first such request received and responds with a 482 (Loop
Detected) to the rest of them.
----------------------------------------------------------------------------------
This is exactly the case the user is experimenting: the INVITE arrives
twice to the same server, with same From tag, Call-ID and CSeq, but
different branch/transaction. So 482 is the correct response.
Regards.
--
Daniel-Constantin Mierla
http://www.asipto.com
16 Nov
16 Nov
12:48 a.m.
2010/11/15 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
I expected the r-uri changes as well (serial forking).
In regard to this
similar case, there is a difference between loop detection and spirals,
maybe sorted out in a follow-up rfc.
Yes, in case the RURI changes (or some other headers as Route) then
it's not loop but a spiral.
However the author of the thread didn't modify the RURI, just created
a new branch and sent it again.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5127
days inactive
5131
days old
10 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
JR Richardson