Thank you for emailing customer service for your Prepaid Debit Card. For security reasons, we are unable to assist with your request via email. Please call customer service at 1-866-692-9374/TTY 1-866-656-5913. Agents are available 24 hours a day to take your call. If your card is lost or stolen, choose the 'lost or stolen' option in the automated menu.
Thank you, Prepaid Account Customer Service -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Dale R. Worley Sent: Thursday, March 28, 2024 2:27 PM To: Amanpreet Singh <amanpreeet.si...@gmail.com> Cc: sandesh.go...@gmail.com; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Call route advance standard 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cs.columbia.edu_mailman_listinfo_sip-2Dimplementors&d=DwICAg&c=e_t7h8KAIi5Kn8KejKi17w&r=268winfLqjz9oUe1vez_plBUtC4f0r4HaQpdzhs-IvQCwjbn750h0QGlcz7CcnOo&m=AK10EZzS9E-3dpW1GBM4Ajl04ajTkJ6jq3RTeHE7llWFPlbN_1-WB0IMy1J8G7Ms&s=4A0Qt8syqcOhL7BVFz4Rt_WeL-38YxeUWQkneIAzPBI&e= _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
