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

[Daniel-Constantin Mierla]

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.

Cheers,
Daniel

> Thanks you for your advice and clarification.
>
> JR
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
http://www.asipto.com