> -----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. Thanks you for your advice and clarification. JR _______________________________________________ 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
