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

JR Richardson jmr.richardson at gmail.com
Sat Nov 13 17:42:32 CET 2010


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

Thanks you for your advice and clarification.

JR




More information about the sr-users mailing list