[SR-Users] Handle '486 busy here' from upstream carrier

[JR Richardson]

On Mon, Nov 15, 2010 at 9:13 AM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
>
>
> On 11/13/10 5:42 PM, JR Richardson wrote:
>>>
>>> -----Original Message-----
>>> From: Iñaki Baz Castillo [mailto:ibc at 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 at 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
>>> <ibc at 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