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

[Daniel-Constantin Mierla]

Hello,

On 11/13/10 3:09 PM, Iñaki Baz Castillo wrote:
> 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:
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

> ----------------------------------------------------------------------------------
> 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