Hi Amanpreet You can configure your B2BUA to use the same call-id on the second trunk too.
On Fri, Mar 29, 2024 at 1:08 AM Amanpreet Singh <amanpreeet.si...@gmail.com> wrote: > 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 > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
