Thanks Dale for your inputs. My UAC is B2BUA and thus sending a new call-id in INVITE for the route advance to the next trunk.
Ranjit, Peer is expecting the same call-id on the second trunk after route advance, was wondering if we have something around this to find a common ground to address this. Regards, Aman On Thu, Mar 28, 2024 at 11:56 PM Dale R. Worley <wor...@ariadne.com> wrote: > Amanpreet Singh <amanpreeet.si...@gmail.com> writes: > > I'm looking to see if there is any RFC defining the standard around route > > advance/ re-routing of calls to the next available route based on the SIP > > failure response. > > > > Looked into SIP Peering RFC6271 and RFC5486, however it doesn't cover the > > route advance requirements. > > In regard to the SIP *specification*, a critical question is the nature > of the device that is forwarding the call onward and doing route > advance. If it is sending outward INVITEs with the same Call-ID as the > INVITE it receives, it is a "proxy" doing "sequential forking", and the > requirements are in RFC 3261. What changes the proxy is allowed to make > on the call as it passes through are relatively limited. > > OTOH, if the outward INVITE has a different Call-ID, then the device is > a "back-to-back user agent" (B2BUA), and from the SIP point of view, it > is the UAS of the arriving INVITE and the UAC of the outgoing INVITE. > The SIP specifications place no limits on what a B2BUA may do, including > sending out what are effectively different forks of a call with > different Call-IDs. > > A lot of telephony systems use B2BUAs rather than the SIP proxies that > were envisioned in the original SIP architecture. > > > To be specific, we have SIP trunks with a provider, when a call fails on > > the first trunk with SIP 50X UAC is doing route advance to the next trunk > > with that provider as per priority. UAC is generating a new call-id in > the > > INVITE for call to the second trunk; however the peer expects the INVITE > > with the same call-id. > > There are two factors involved. One is whether the device claims to be > a proxy, in which case it is required to use the same Call-ID on > different forks of a call that it handles. The other is what the > trunking provider *requires*, which isn't necessarily limited by the SIP > specifications. As a matter of good system architecture, I would expect > that alternative forks of one call would have the same Call-ID, so that > downstream devices can tell that they *are* alternative forks of one > call. > > Dale > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
