On Mon, Nov 15, 2010 at 9:13 AM, Daniel-Constantin Mierla
<mico...@gmail.com> wrote:
>
>
> On 11/13/10 5:42 PM, JR Richardson wrote:
>>>
>>> -----Original Message-----
>>> From: Iñaki Baz Castillo [mailto:i...@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<mico...@gmail.com>:
>>>>>
>>>>> 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
>>> <i...@aliax.net>
>>
>> [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.
>
> 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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
