RFC 6405
Voice over IP (VoIP) SIP Peering Use Cases
RFC 6405: Voice over IP (VoIP) SIP Peering Use Cases ✨
okay bestie, this one is all about how VoIP phone calls get handed between networks over SIP peering 📞🎀
Title block facts 💅
- Authors: A. Uzelac, Ed. (Global Crossing) and Y. Lee, Ed. (Comcast Cable) 👑
- Category: Informational 🦋
- ISSN: 2070-1721
- Date: November 2011 🗓️
- Obsoletes and updates: the title block doesn't list anything this RFC obsoletes or updates 🙈
Abstract
okay so this doc lays out a bunch of the most common VoIP use cases for SIP peering 🌸 they get sorted into static and on-demand, and then each of those gets split again into direct and indirect 🧚 these aren't every single use case out there, just the most common ones people are actually running today 💖
Status of This Memo
ngl this part is the legal-ish stuff, but it matters 🫶 this document is not an Internet Standards Track specification. it's published for informational purposes only 📚
it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community ✨ it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🔥 not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 💅
if you want the current status, any errata, or a way to send feedback, check out http://www.rfc-editor.org/info/rfc6405 🌈
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the date of publication. please read these carefully, bestie, because they spell out your rights and restrictions for this doc 🥹 any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💜
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Reference Architecture ..........................................3
4. Contexts of Use Cases ...........................................4
5. Use Cases .......................................................4
5.1. Static Peering Use Cases ...................................5
5.2. Static Direct Peering Use Case .............................5
5.2.1. Administrative Characteristics .....................10
5.2.2. Options and Nuances ................................10
5.3. Static Direct Peering Use Case - Assisting LUF and LRF ....11
5.3.1. Administrative Characteristics .....................12
5.3.2. Options and Nuances ................................12
5.4. Static Indirect Peering Use Case - Assisting LUF and LRF ..12
5.4.1. Administrative Characteristics .....................19
5.4.2. Options and Nuances ................................19
5.5. Static Indirect Peering Use Case ..........................19
5.5.1. Administrative Characteristics .....................20
5.5.2. Options and Nuances ................................21
5.6. On-Demand Peering Use Case ................................21
5.6.1. Administrative Characteristics .....................21
5.6.2. Options and Nuances ................................21
6. Acknowledgments ................................................22
7. Security Considerations ........................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................231. Introduction ✨
this doc describes important VoIP use cases for [RFC3261]-based SIP peering 📞 the Session PEERing for Multimedia INTerconnect (SPEERMINT) working group came up with these use cases, and they're meant to help figure out requirements and other issues the working group should resolve later 🦋
only VoIP-related use cases are considered here 💖 other real-time SIP stuff like Instant Messaging (IM), video chat, and presence is out of scope, so don't go looking for it in here 🙈
the use cases in this document are described as comprehensive as possible, but they should not be considered the exclusive set of use cases 🌸
2. Terminology 💅
this doc uses terms defined in [RFC5486], so go check there for the definitions 📚
3. Reference Architecture 🧚
the diagram below gives you the context for the VoIP use cases in this doc 🎀 terms like SIP Service Provider (SSP), Lookup Function (LUF), Location Routing Function (LRF), Signaling Path Border Element (SBE), and Data Path Border Element (DBE) are all defined in [RFC5486] 💜
the Originating SSP (O-SSP) is the SSP that originates a SIP request 👑 the Terminating SSP (T-SSP) is the SSP that terminates the SIP request coming from the O-SSP ✨ the assisting LUF and LRF Provider offers LUF and LRF services to the O-SSP 🫶 and the Indirect SSP (I-SSP) is the SSP providing indirect peering service(s) to the O-SSP so it can connect to the T-SSP 🌈
+--------------------+------------------------+--------------------+
| Originating SSP | Assisting LUF and LRF | Terminating SSP |
| Domain | Provider Domain | Domain |
| | | |
| +-----+ +-----+ | +------+ +------+ | +-----+ +-----+ |
| |O-LUF| |O-LRF| | |A-LUF | | A-LRF| | |T-LUF| |T-LRF| |
| +-----+ +-----+ | +------+ +------+ | +-----+ +-----+ |
| | | |
| +-------+ +-----+ +------------------------+ +-----+ +-------+ |
| |O-Proxy| |O-SBE| | Indirect SSP Domain | |T-SBE| |T-Proxy| |
| +-------+ +-----+ | | +-----+ +-------+ |
| | +-----+ +-----+ | |
| +---+ +-----+ | |O-SBE| |O-DBE| | +-----+ +---+ |
| |UAC| |O-DBE| | +-----+ +-----+ | |T-DBE| |UAS| |
| +---+ +-----+ | | +-----+ +---+ |
| | | |
+--------------------+------------------------+--------------------+
General Overview
Figure 1that picture is the general overview, and yep, some of the stuff in Figure 1 is optional 🦋
4. Contexts of Use Cases 💖
use cases get sorted into two general groups: static and on-demand peering [RFC5486] 🎀 each group can be split again into Direct Peering and Indirect Peering [RFC5486] ✨ there can be some overlap between these categories, but the scenarios have different requirements 🌸 each use case must specify a basic set of required operations that each SSP performs when peering 🫶
these can include:
- Peer Discovery: peer discovery goes through a Lookup Function (LUF) to figure out the Session Establishment Data (SED) [RFC5486] of the request 💅 in VoIP use cases the request usually has a phone number in it 📞 the O-SSP puts that phone number into the LUF, and the LUF will normally hand back a SIP address of record (AOR) [RFC3261] with a domain name in it 🔥
- Next-Hop Routing Determination: resolving the SED info is needed to route the request to the T-SSP 🧚 the LRF handles this part 👑 once the O-SSP has the SED, it may use the standard procedure from [RFC3263] to discover the next-hop address 🌈
- Call setup: SSPs that interconnect with each other may also define specifics about which peering policies to use when contacting the next hop, so they can a) reach the next hop at all and b) prove the sender is a legit peering partner 🥹 examples include hard-coding the transport (TCP/UDP/TLS), a non-standard port number, a specific source IP address (e.g., in a private Layer 3 network), which TLS client certificate [RFC5246] to use, and other authentication schemes 💜
- Call reception: this step makes sure the type of relationship (static or on-demand, indirect or direct) is understood and acceptable ✨ for example, the receiving SBE needs to work out whether the INVITE it got really came from a trusted member 🛡️
5. Use Cases 🌸
please note there are intra-domain message flows inside the use cases, just as background info 🧚 only inter-domain communications are relevant to this doc 💖
5.1. Static Peering Use Cases 🎀
static peering [RFC5486] is when two SSPs form a peering relationship, with some kind of association set up before any traffic gets exchanged 🫶 that pre-association is a prerequisite to static peering 🔥 static peering is used when two peers want a consistent, tightly controlled approach to peering 👑 in this scenario, a bunch of variables, like an identification method (remote proxy IP address) and Quality-of-Service (QoS) parameters, can be defined upfront and known by each SSP before peering starts 💅🦋
5.2. Static Direct Peering Use Case ✨
okay so this is the simplest peering use case, and honestly it's giving clean. 💅 Two SSPs sit down, agree to set up a SIP peering relationship, and the connection is statically configured with the peer SSPs directly connected. Before they link up, they can swap interconnection parameters like Differentiated Service Code Point (DSCP) [RFC2474] policies, the maximum number of requests per second, and the proxy location. Usually the T-SSP only accepts traffic that comes straight from its trusted peer. 🔒
+--------------------+ +---------------------+
| O-SSP | | T-SSP |
| +-----+ | | +-----+ |
| |O-LUF| | | |T-LUF| |
| |O-LRF| | | /|T-LRF| |
| /+-----+\ | | / +-----+ |
| (2) (4,5,6) | | / |
| / \ | | /(8,9) |
|+-------+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-----(7)-----+T-SBE|-(10)-|T-Proxy||
|+-------+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (11) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | UAC +======|O-DBE+=====(12)====+T-DBE|=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ |
+--------------------+ +---------------------+
example.com example.net
Static Direct Peering Use Case
Figure 2Here's the high-level vibe of the whole use case, bestie. 🦋
1. The User Agent Client (UAC) starts a call with a SIP INVITE sent to O-Proxy. O-Proxy is the home proxy for UAC. 📞
INVITE sip:+19175550100@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9
Max-Forwards: 10
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>Notice that UAC slid its Fully Qualified Domain Name (FQDN) into the VIA and CONTACT headers. This example assumes UAC actually has its own FQDN. 🎀
2. UAC knows the User Agent Server's (UAS's) TN, but it doesn't know UAS's domain. So it adds its own domain to build the SIP URI for the Request-URI and TO header. O-Proxy looks at the Request-URI and spots the user parameter "user=phone". That parameter is a little flag saying the Request-URI is a phone number. 📱 So O-Proxy pulls the TN out of the Request-URI and asks the LUF for SED information from a routing database. In this example the LUF is an ENUM [RFC6116] database, and the ENUM entry looks something like this:
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
IN NAPTR (
10
100
"u"
"E2U+SIP"
"!^.*$!sip:+19175550100@example.net!"
. )This SED data can be set up by the O-SSP, or it can be filled in by the T-SSP. 🌸
3. O-Proxy checks out the SED and sees the domain is external. Based on O-Proxy's internal routing policy, it decides to go through O-SBE to reach T-SBE. So O-Proxy sends the INVITE request to O-SBE and adds a Route header holding O-SBE. 🧚
INVITE sip:+19175550100@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-proxy.example.com:5060
;branch=z9hG4bKye8ad
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9;received=192.0.1.1
Max-Forwards: 9
Route: <sip:o-sbe1.example.com;lr>
Record-Route: <sip:o-proxy.example.com;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>4. O-SBE gets the request and pops the top entry of the Route header, the one that says "o-sbe1.example.com". Then it looks at the Request-URI and does an LRF lookup for "example.net". Here the LRF is a Naming Authority Pointer (NAPTR) DNS query [RFC3403] on that domain name. O-SBE gets back a NAPTR response that looks like this: 🔍
IN NAPTR (
50
50
"S"
"SIP+D2T"
""
_sip._tcp.t-sbe.example.net. )
IN NAPTR (
90
50
"S"
"SIP+D2U"
""
_sip._udp.t-sbe.example.net. )5. Since TCP has the lower order in the NAPTR response, O-SBE picks TCP as its transport protocol. So it sends an SRV DNS query for the SRV record [RFC2782] for "_sip._tcp.t-sbe.example.net." to O-LRF. 🧠
;; priority weight port target
IN SRV 0 2 5060 t-sbe1.example.net.
IN SRV 0 1 5060 t-sbe2.example.net.6. "t-sbe1.example.net" has the higher weight, so O-SBE sends an A record DNS query for "t-sbe1.example.net." to get the A record: 💜
;; DNS ANSWER
t-sbe1.example.net. IN A 192.0.2.100
t-sbe1.example.net. IN A 192.0.2.1017. O-SBE sends the INVITE over to T-SBE. O-SBE is the egress point to the O-SSP domain, so it should ensure subsequent mid-dialog requests traverse via itself. If O-SBE chooses to act as a back-to-back user agent (B2BUA) [RFC3261], it will generate a new INVITE request in the next step. If O-SBE chooses to act as a proxy, it should record-route to stay in the call path. In this example, O-SBE is a B2BUA. 👑
INVITE sip:+19175550100@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-sbe1.example.com:5060
;branch= z9hG4bK2d4zzz
Max-Forwards: 8
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-osbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@o-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>Heads up: O-SBE may re-write the Request-URI with the target domain in the SIP URI. Some proxy implementations will only accept the request if the Request-URI contains their own domains. 👀
8. T-SBE figures out the called party's home proxy and directs the call to the called party. T-SBE may use an ENUM lookup or some other internal mechanism to find the home proxy. If T-SSP uses an ENUM lookup, this internal ENUM entry is different from the external ENUM entry populated for O-SSP. In this example, the internal ENUM query returns the UAS's home proxy. 🏠
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
IN NAPTR (
10
100
"u"
"E2U+SIP"
"!^.*$!sip:+19175550100@t-proxy.example.net!"
. )9. T-SBE gets the NAPTR record and, following the requirements in [RFC3263], queries DNS for the SRV records that the NAPTR result points to. It doesn't find any, so T-SBE then queries DNS for the A record of the domain "t-proxy.example.net.". 🔎
;; DNS ANSWER
t-proxy.example.net. IN A 192.0.2.210. T-SBE is a B2BUA, so it generates a fresh INVITE and sends it to UAS's home proxy: ✨
INVITE sip:bob@t-proxy.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy
Max-Forwards: 7
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@t-proxy.example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.net;user=phone;
transport=tcp>
</allOneLine>11. Finally, UAS's home proxy forwards the INVITE request to the UAS. 🎉
INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-proxy.example.net:5060
;branch= z9hG4bK28u111
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy; received=192.2.0.100
Max-Forwards: 6
Record-Route: <sip:t-proxy.example.net:5060;lr>,
<sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@t-proxy.example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.net;user=phone;
transport=tcp>
</allOneLine>12. RTP is now set up between the UAC and UAS. The media shown in Figure 2 goes through O-DBE and T-DBE, but using a DBE is optional. 🎶
5.2.1. Administrative Characteristics
The static direct peering use case usually shows up where the two administrative domains really trust each other. 🫶 Both domains typically sign a peering agreement that spells out the policies and terms clearly. 📝
5.2.2. Options and Nuances
In Figure 2, O-SSP and T-SSP peer through SBEs. Normally the operator deploys the SBE at the edge of its administrative domain, and the signaling traffic passes between the two networks through the SBEs. 🌐 Operators have lots of reasons to deploy an SBE. For example, the O-SSP may use [RFC1918] addresses for its UA and proxies, and those addresses aren't routable in the target network. The SBE can handle that with a NAT function. 🙈 The SBE also makes it cheaper and easier to deploy or remove Layer 5 network elements. Picture a setup where multiple proxies connect to a single SBE: an operator can add or remove a proxy without coordinating with the peer operator, because the peer operator only "sees" the SBE. As long as the SBE stays in the path, the peer operator doesn't need to be notified. 💅
When an operator deploys SBEs, the operator is required to advertise the SBE to the peer LRF, so the peer operator can locate the SBE and route traffic to it accordingly. 📡
SBE deployment is a decision made within an administrative domain, and either one or both administrative domains can decide to deploy SBE(s). For the peer network, what matters most is identifying the next-hop address, and this decision doesn't affect the network's ability to identify that next-hop address. 🦄
5.3. Static Direct Peering Use Case - Assisting LUF and LRF ✨
okay so this one is basically Static Direct Peering (Section 5.2) but with a helper 🧚. The O-SSP and T-SSP still have to have a pre-association set up first 🤝. The only real difference is that the O-SSP hands its LUF and LRF jobs to an Assisting LUF/LRF Provider 💅. That provider stores the SED needed to reach the T-SSP and gives it to the O-SSP whenever the O-SSP asks 🌸
+-----------------+
|LUF/LRF Provider |
| |
| +-------+ |
| +-+ A-LUF | |
| / | A-LRF | |
+--------------------+ / ++-------+ +---------------------+
| O-SSP |/ / | T-SSP |
| +------------/(4,5,6) | +-----+ |
| / | / | |T-LUF| |
| (2) +-+/ | +-|T-LRF| |
| / / | | / +-----+ |
| / / | | /(8,9) |
|+-------+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-------(7)-------+T-SBE|-(10)-|T-Proxy||
|+-------+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (11) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | UAC +======|O-DBE+=======(12)======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ |
+--------------------+ +---------------------+
example.com example.netStatic Direct Peering with Assisting LUF and LRF
Figure 3
The call flow is almost the same as Static Direct Peering, except Steps 2, 4, 5, and 6 happen at the LUF/LRF Provider instead of inside the O-SSP domain 🦋
Just like Static Direct Peering, the O-DBE and T-DBE in Figure 3 are optional 🌈
5.3.1. Administrative Characteristics
The LUF/LRF Provider is the one supplying LUF and LRF services for the O-SSP 🎀 Put together, the LUF/LRF Provider, O-SSP, and T-SSP make up one trusted administrative domain 👑 Still, to reach the T-SSP, the O-SSP has to have pre-arranged peer agreements with the T-SSP, no shortcuts 😭 The Layer 5 policy lives in the O-SSP and T-SSP domains, and the LUF/LRF Provider may not be aware of any Layer 5 policy between the O-SSP and T-SSP 🙈
A LUF/LRF Provider can serve multiple administrative domains 💜 It typically does not share SED from one administrative domain to another without appropriate permission 🔒
5.3.2. Options and Nuances
The LUF/LRF Provider has a few ways to hand SED over to the O-SSP 🧁 The most common ones are an ENUM lookup and a SIP Redirect 🍓 Before the O-SSP sends a request to the LUF/LRF Provider, it should negotiate which query method it's going to use 🫶
Ngl, this is the messy part 💀 The LUF/LRF Providers must be populated with the T-SSP's AORs and SED. Right now that procedure is non-standardized and really labor intensive 😩 If you want the full tea on this problem, it's written up in the work in progress [DRINKS] ✨
5.4. Static Indirect Peering Use Case - Assisting LUF and LRF
okay the big difference between a Static Direct Use Case and a Static Indirect Use Case is the Layer 5 relationship between the O-SSP and T-SSP 🦋 In the Indirect version, those two do NOT have direct Layer 5 connectivity, so they need one or more Indirect Domains to help route the SIP messages and possibly the media too 🧚
So the O-SSP and T-SSP want to be peers, but for some reason they can't connect directly 🥺 That could be business demands, domain policy controls, or whatever else is going on. Because the relationship is indirect, the signaling goes from the O-SSP through one or more I-SSPs to reach the T-SSP 🌸
The O-SSP is also using a LUF/LRF Provider in this one 💅 That provider stores the T-SSP's SED, which the T-SSP pre-populated 🎀 The big win is that the T-SSP only has to populate its SED once, into the provider. Any O-SSP that needs the T-SSP's SED can then use that same LUF/LRF Provider 👑 Honestly, current practice shows it's super hard for the T-SSP to push its SED to every O-SSP that needs to reach its subscribers 😭 Especially in the Enterprise environment 💼
The LUF/LRF Provider and the I-SSP can be the same provider or two different ones 🌈
+------------------+
| LUF/LRF Provider |
| I-SSP |
| +-------+ |
| ---+ A-LUF | |
| / | A-LRF | |
+--------------------+ / +-------+ +---------------------+
| O-SSP |/ / | T-SSP |
| +-------------/ / | +-----+ |
| / |(4,5,6) | |T-LUF| |
| / | / | +----+T-LRF| |
| (2) + +--- | / +-----+ |
| / / | | /(9,10) |
|+-------+ +-----+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
|+-------+ +-----+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (12) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
| | UAC +=(13)=|O-DBE+=====+I-DBE+======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
+-------------------------------------------------------------+
example.com example.org example.netIndirect Peering via an LUF/LRF Provider and I-SSP (SIP and Media)
Figure 4
Here's the high-level play-by-play of the use case 📱
- The UAC starts a call with a SIP INVITE sent to the O-Proxy 📞 The O-Proxy is the home proxy for the UAC 🏠
INVITE sip:+19175550100@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9
Max-Forwards: 10
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>- The UAC knows the UAS's TN but not the UAS's domain 🤷♀️ So it tacks on its own domain to make the SIP URI for the Request-URI and the TO header 🎀 The O-Proxy checks the Request-URI and spots the user parameter "user=phone". That tells it the Request-URI is a phone number 📱 So the O-Proxy pulls out the TN and queries the LUF for SED info from a routing database. In this example, the LUF is an ENUM database 🔍 The ENUM entry looks something like this:
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
IN NAPTR (
10
100
"u"
"E2U+SIP"
"!^.*$!sip:+19175550100@example.org!"
. )Note that the response says the next-hop is the SBE in the I-SSP 👀 Also, the O-SSP may have a pre-association with the I-SSP 🤝 If it does, the O-SSP will forward every request that has an external domain in the Request-URI, or an unknown TN, to the I-SSP. The O-SSP then relies on the I-SSP to figure out the T-SSP and route the request correctly 🧠 In that setup, the O-SSP can skip Steps 2, 4, 5, and 6 and send the request straight to the I-SBE. This setup is commonly used in the Enterprise environment 💼✨
- The O-Proxy's internal routing policy says to use the O-SBE to reach the I-SBE 🛣️ So the O-Proxy sends the INVITE to the O-SBE and adds a Route header containing the O-SBE 🎀
INVITE sip:+19175550100@example.org;user=phone SIP/2.0
Via: SIP/2.0/TCP o-proxy.example.com:5060
;branch=z9hG4bKye8ad
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9;received=192.0.1.1
Max-Forwards: 9
Route: <sip:o-sbe1.example.com;lr>
Record-Route: <sip:o-proxy.example.com;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>- The O-SBE gets the request and pops the top Route entry, the one with "sip:o-sbe1.example.com" 🔝 Then it looks at the Request-URI and does an LRF lookup for "example.org" 🔎 In this example, the LRF is a NAPTR DNS query on the domain. The O-SBE gets back a response like this:
IN NAPTR (
50
50
"S"
"SIP+D2T"
""
_sip._tcp.i-sbe.example.org. )
IN NAPTR (
90
50
"S"
"SIP+D2U"
""
_sip._udp.i-sbe.example.org. )- Since TCP has the lower order in the NAPTR response, the O-SBE picks TCP as its transport protocol 🚚 So it sends an SRV DNS query for "_sip._tcp.i-sbe.example.org." to the O-LRF, and gets back the SRV records 🧾
;; priority weight port target
IN SRV 0 2 5060 i-sbe1.example.org.
IN SRV 0 1 5060 i-sbe2.example.org.- "i-sbe1.example.org" has the higher weight, so the O-SBE sends a DNS query for an A record of "i-sbe1.example.org." to get the address 🎯
;; DNS ANSWER
i-sbe1.example.org. IN A 192.0.2.200
i-sbe1.example.org. IN A 192.0.2.201- The O-SBE sends the INVITE to the I-SBE 🚀 The O-SBE is the entry point into the O-SSP domain, so it should make sure subsequent mid-dialog requests keep going through itself 🫶 If the O-SBE acts as a B2BUA, it generates a new back-to-back INVITE request in the next step. If the O-SBE acts as a proxy instead, it should record-route so it stays in the call path 🦋 In this example, the O-SBE is a B2BUA 👑
- Okay so the I-SBE gets the request and checks its internal routing database on the TN 📞. It figures out the target belongs to the T-SSP 🎯. Since the I-SBE is a B2BUA, it generates a brand-new INVITE request to the T-SSP ✨.
INVITE sip:+19175550100@.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP i-sbe1.example.org:5060
;branch= z9hG4bK2d4777
Max-Forwards: 7
Route: <sip:t-sbe1.example.net;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-isbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@i-sbe1.example.org;user=phone;
transport=tcp>
</allOneLine>Note that if the I-SSP wants the media to traverse through the I-DBE, the I-SBE must modify the Session Description Protocol (SDP) in the Offer so it points to its DBE 🎀.
- The T-SBE figures out the called party's home proxy and sends the call along to the called party 📬. It can use ENUM lookup or some other internal mechanism to find that home proxy 🔍. If the T-SSP uses ENUM lookup, this internal ENUM entry is different from the external ENUM entry populated for O-SSP 🙈. This internal entry has the info needed to identify the next hop to reach the called party. In this example, the internal ENUM query returns the UAS's home proxy 💖.
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
IN NAPTR (
10
100
"u"
"E2U+SIP"
"!^.*$!sip:+19175550100@t-proxy.example.net!"
. )Note that this step is optional 🦋. If the T-SBE has other ways to locate the UAS home proxy, it can skip this step and send the request straight to the UAS's home proxy. We show this step to illustrate just one of the many possible ways to locate UAS's home proxy 🌸.
- The T-SBE gets the NAPTR record and, following the requirements in [RFC3263], queries the DNS for the SRV records indicated by the NAPTR result 🔎. It doesn't find any, so the T-SBE then queries DNS for the A record of domain "t-proxy.example.net.". 💅
;; DNS ANSWER
t-proxy.example.net. IN A 192.0.2.2- The T-SBE sends the INVITE to the UAS's home proxy 🚀:
INVITE sip:+19175550100@t-proxy.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy
Max-Forwards: 6
Record-Route: <sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>- Finally, the UAS's home proxy forwards the INVITE request to the UAS 🥳.
INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-proxy.example.net:5060
;branch= z9hG4bK28u111
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy; received=192.2.0.100
Max-Forwards: 5
Record-Route: <sip:t-proxy.example.net:5060;lr>,
<sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>- In Figure 4, RTP is established between the UAC and UAS via the O-DBE, I-DBE and T-DBE 🎶. The use of DBE is optional 💜.
5.4.1. Administrative Characteristics 🎀
5.4.1.1
This use case looks super similar to the Static Direct Peering Use Case with Assisting LUF and LRF 👯. The big difference is that the O-SSP and T-SSP don't have direct Layer 5 connectivity. Instead, the O-SSP connects to the T-SSP indirectly via the I-SSP 🦋.
Typically, an LUF/LRF Provider serves multiple O-SSPs. Two O-SSPs may use different I-SSPs to reach the same T-SSP 🌈. For example, O-SSP1 may use I-SSP1 to reach T-SSP, but O-SSP2 may use I-SSP2 to reach T-SSP 🫶. Given the O-SSP and T-SSP pair as input, the LUF/LRF Provider will return the SED of the I-SSP that is trusted by the O-SSP to forward the request to T-SSP ✨.
In this use case there are two levels of trust relationship 🔥. The first is between the O-SSP and the LUF/LRF Provider. The O-SSP trusts the LUF/LRF to provide the T-SSP's SED. The second is between the O-SSP and the I-SSP. The O-SSP trusts the I-SSP to provide Layer 5 connectivity to help the O-SSP reach the T-SSP. The O-SSP and I-SSP have a pre-arranged agreement for policy 📜. Note that Figure 4 shows a single provider supplying both the LUF/LRF and the I-SSP, but the O-SSP can choose two different providers 💅.
5.4.2. Options and Nuances 🧚
Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP may deploy SBE and DBE for NAT traversal, security, transcoding, etc. 🛡️ The I-SSP can also deploy the SBE and DBE for similar reasons (as depicted in Figure 4) 💖.
5.5. Static Indirect Peering Use Case ✨
This use case shares a lot of properties with the Static Indirect Use Case with Assisting LUF and LRF 👭. The difference is that the O-SSP uses its internal LUF/LRF to control the routing database 🗂️. By controlling the database, the O-SSP can apply different routing rules and policies to different T-SSPs 🍓. For example, the O-SSP can use I-SSP1 and Policy-1 to reach T-SSP1, and use I-SSP2 and Policy-2 to reach T-SSP2 🌸. Note that there could be multiple I-SSPs and multiple SIP routes to reach the same T-SSP, but the selection process is out of scope of this document 🙈.
+--------------------+-------------------+---------------------+
| O-SSP | I-SSP | T-SSP |
| +-----+ | | +-----+ |
| -+O-LUF| | | |T-LUF| |
| / |O-LRF+\ | | +----+T-LRF| |
| / +-----+ \ | | / +-----+ |
| /(2) \(4,5,6) | /(9,10) |
|+-------+ +-----+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+--(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
|+-------+ +-----+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (12) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
| | UAC +=(13)=+O-DBE+======+I-DBE+======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
+--------------------------------------------------------------+
example.com example.org example.net
Indirect Peering via I-SSP (SIP and Media)
Figure 55.5.1. Administrative Characteristics 🎀
The Static Indirect Peering Use Case gets used when there's no direct interconnection between the originating and terminating domains, whether that's due to business or physical constraints 🚧.
O-SSP <---> I-SSP = Relationship O-IIn the O-I relationship, the typical policies, features, or functions that make this relationship necessary are number portability, ubiquity of termination options, security certificate management, and masquerading of originating VoIP network gear 🎭.
T-SSP <---> I-SSP = Relationship T-IIn the T-I relationship, the typical policies, features, or functions observed are codec "scrubbing", anonymizing, and transcoding 🧼. The I-SSP must record-route and stay in the signaling path 🛣️. The T-SSP will not accept any message sent directly from the O-SSP 🚫.
5.5.2. Options and Nuances 💅
In Figure 5 we show an I-DBE, but using an I-DBE is optional 🙌. For example, the I-DBE can be used when the O-SSP and T-SSP don't have a common codec 🎵. To involve an I-DBE, the I-SSP should know the list of codecs supported by the O-SSP and T-SSP 📋. When the I-SBE receives the INVITE request, it will decide whether to invoke the I-DBE 🤔. An I-DBE may also be used if the O-SSP uses Secure Real-time Transport Protocol (SRTP) [RFC3711] for media and the T-SSP doesn't support SRTP 🔐.
5.6. On-Demand Peering Use Case 🌈
On-demand peering [RFC5486] describes how two SSPs form a peering relationship without a pre-arranged agreement 💫.
The basis of this use case is that there's no pre-established relationship between the O-SSP and T-SSP 🤷♀️. The O-SSP and T-SSP don't share any info before the dialog initiation request. When the O-Proxy invokes the LUF and LRF on the Request-URI, the terminating user information must be publicly available 📢. When the O-Proxy routes the request to the T-Proxy, the T-Proxy must accept the request without any pre-arranged agreement with the O-SSP 🫣.
The On-demand Peering Use Case is uncommon in production 😅. In this memo we're only capturing the high-level descriptions 📝. Further analysis is expected when this use case becomes more popular 👀.
5.6.1. Administrative Characteristics 🎀
The On-demand Direct Peering Use Case is typically implemented in a scenario where the T-SSP allows any O-SSP to reach its serving subscribers 🌍. The T-SSP administrative domain doesn't require any pre-arranged agreement to accept the call. The T-SSP makes its subscriber information publicly available 📖. This model mimics the Internet email model, where the sender doesn't need a pre-arranged agreement to send email to the receiver 💌.
5.6.2. Options and Nuances 🛡️
Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP can decide to deploy the SBE. Since the T-SSP is open to the public, it's considered a higher security risk than the static model 😬, because there's no trusted relationship between the O-SSP and T-SSP. The T-SSP should protect itself from any attack launched by an untrusted O-SSP 🚨.
6. Acknowledgments 🫶
Michael Haberler, Mike Mammer, Otmar Lendl, Rohan Mahy, David Schwartz, Eli Katz and Jeremy Barkan are the authors of the early individual documents 🙌. Their use cases are captured in this document 💜.
Also, Jason Livingood, Daryl Malas, David Meyer, Hadriel Kaplan, John Elwell, Reinaldo Penno, Sohel Khan, James McEachern, Jon Peterson, Alexander Mayrhofer, and Jean-Francois Mule made many valuable comments related to this document 🌟.
The editors would also like to extend a special thank you to Spencer Dawkins for his detailed review of this document 👑.
7. Security Considerations 🔐
Okay bestie, this part is SERIOUS 😭🔐 Session interconnect for VoIP has a whole bunch of security issues that people need to think about, no cap. For example, if the O-SSP and T-SSP are peering over the public Internet, the O-SSP MUST protect the signaling channel and MUST accept messages only from an authorized T-SSP. Non-negotiable, periodt 💅
This document does not go deep into the threats, though 🙈 [RFC6404] is the one that covers the different security threats and countermeasures related to VoIP peering, so go read that one if you want the full tea ☕💜
8. References 📚
8.1. Normative References 💖
- [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. 🎀
- [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. 🌸
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. ✨
- [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. 🦋
- [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. 🧚
- [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009. 🍓
- [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, March 2011. 🌈
- [RFC6404] Seedorf, J., Niccolini, S., Chen, E., and H. Scholz, "Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures", RFC 6404, November 2011. 👑
8.2. Informative References 🫶
- [DRINKS] Channabasappa, S., "Data for Reachability of Inter/tra-NetworK SIP (DRINKS) Use cases and Protocol Requirements", Work in Progress, August 2011. 🌷
- [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. 💜
- [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 🔥
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. ⭐
Authors' Addresses 🎀
Adam Uzelac (editor) Global Crossing U.S.A.
EMail: adam.uzelac@globalcrossing.com URI: http://www.globalcrossing.com
Yiu L. Lee (editor) Comcast Cable U.S.A.
EMail: yiu_lee@cable.comcast.com URI: http://www.comcast.com
📦 where this page comes from
- ietf: rfc6405 2011-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms