15 Nov
2010
15 Nov
'10
9: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>