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
