RFC 5947
Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)
Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP) 🎀
okay bestie, let's get into RFC 5947 ✨ It's an Informational doc, so it's not a Standards Track spec, just published for information 💅 It's from the IETF, dated September 2010, and it's RFC number 5947 with ISSN 2070-1721. The authors are J. Elwell (Siemens Enterprise Communications) and H. Kaplan (Acme Packet). Its header doesn't list anything it obsoletes or updates. 🦋
Abstract ✨
okay so this doc basically lays out a wishlist of requirements (a serious one, though 🙈) for a standardized SIP registration mechanism that covers multiple addresses of record (AORs). It's meant for SIP service providers to deploy at a large scale, supporting small-to-medium Private Branch Exchanges (PBXs). The minimum ask is that the solution supports AORs based on E.164 numbers. 💖
Status of This Memo 🌈
This document is not an Internet Standards Track specification; it is published for informational purposes.
It's a product of the Internet Engineering Task Force (IETF), so 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 check out Section 2 of RFC 5741 if you're curious about that. 🧐
For the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5947.
Copyright Notice 💜
Copyright (c) 2010 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 in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled from 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 ....................................................3
2. Terminology .....................................................3
3. Problem Statement ...............................................4
3.1. Issues with the REGISTER Transaction .......................5
3.1.1. Mishandling by SIP-Aware Middleboxes ................5
3.1.2. REGISTER Response Growth ............................6
3.1.3. Illegal "Wildcard" Syntax ...........................6
3.2. Issues with Routing Inbound Requests to the SIP-PBX ........6
3.2.1. Loss of Target Information ..........................6
3.2.2. Inconsistent Placement of Target URI
Information in Inbound Requests .....................6
3.2.3. Request-URI Misrouting ..............................7
3.3. Policy-Related Issues ......................................7
3.3.1. Authorization Policy Mismatches .....................7
3.3.2. PAI or PPI URI Mismatches ...........................7
4. Requirements ....................................................8
5. Desirables .....................................................10
6. Non-Requirements ...............................................11
7. Security considerations ........................................11
8. Acknowledgements ...............................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................121. Introduction 🌸
okay so the Session Initiation Protocol (SIP) [RFC3261], plus its extensions, has several ways to get the connection info needed to deliver out-of-dialog SIP requests to their intended targets. When a SIP proxy needs to send a request to a target address of record (AOR) inside its domain, it can ask a location service for the registered Contact Universal Resource Identifiers (URIs), along with any associated path info [RFC3327]. Then it builds a route set to reach each target user agent (UA). The SIP REGISTER method is how Contact URIs and path info get registered. SIP-outbound [RFC5626] levels this up for UAs stuck behind Network Address Translators (NATs) and firewalls. And when an entity wants to reach a target it isn't authoritative for, it can follow [RFC3263] procedures and use the Domain Name System (DNS) to find the next-hop connection info. ✨
In practice, lots of small and medium businesses run a SIP Private Branch Exchange (SIP-PBX) that's authoritative for tens or hundreds of SIP AORs. This SIP-PBX acts as the registrar/proxy for those AORs, for users hosted on the SIP-PBX. A SIP Service Provider (SSP) gives the SIP-PBX SIP peering/trunking capability. The SIP-PBX has to be reachable from the SSP, so the SSP can handle inbound out-of-dialog SIP requests aimed at these AORs and route them to the SIP-PBX for onward delivery to registered UAs. 💅
Experience has shown that existing mechanisms aren't always enough for SIP-PBXs at small and medium businesses. Honestly, RFC 3263 procedures are generally inappropriate, except for some of the bigger SIP-PBXs. Right now, mechanisms that dynamically provide reachability info based on the SIP REGISTER method are commonly used. The problem is they vary in detail, which causes interoperability issues between SIP-PBXs and SSPs, and means equipment has to support different variants. 😭 Section 3 has the full breakdown.
This document states requirements for a standardized SIP registration mechanism for multiple AORs. The mechanism is meant to be deployed by SSPs at a large scale, in support of small- to medium-sized SIP-PBXs. The minimum ask is that the solution supports AORs based on E.164 numbers. 🫶
2. Terminology 💖
Here's the key word squad: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". In this doc they're to be interpreted as described in [RFC2119]. 👑
Also, address of record (AOR), proxy, REGISTER, registrar, request, response, and user agent (UA) are to be interpreted as described in [RFC3261]. 🦋
3. Problem Statement 🔥
Other standards orgs have already tackled the issue of a SIP-PBX registering with its SSP, most notably ETSI [ETSI_TS_182025] and the 3rd Generation Partnership Project (3GPP) [3GPP.24.229]. Various SSPs have also written proprietary specs for their own offerings. Go read what those orgs put out, it's worth it 🧚
Here's the general concept in a nutshell. The figure below shows the scope of the problem:
+----+
| UA |----+
+----+ | - - - - - - - - - - - - - -
| : SCOPE OF PROBLEM :
+----+ | : :
| UA |--+ | +---------+ +---------+
+----+ | | | | | |
| +------| | | |
+----+ +--------| SIP-PBX |------------------| SSP |
| UA |-----------| | | |
+----+ | | | |
+---------+ +---------+
: :
----------------> : ------------------> :
UAs register with : SIP-PBX registers with :
SIP-PBX on behalf of : SSP once on behalf of :
individual AORs : multiple AORs :
: :
: <------------------ :
<---------------- : SSP delivers inbound :
SIP-PBX forwards : requests to SIP-PBX :
inbound requests : :
to appropriate UAs : :
- - - - - - - - - - - - - -In basically every model, the SIP-PBX generates a SIP REGISTER request using a mutually agreed-upon SIP AOR. That's usually based on the SIP-PBX's main attendant/reception-desk number. The AOR is often in the SSP's domain, and both the To and From URIs in the REGISTER request identify that AOR. On the wire, it looks totally "normal", like a SIP REGISTER from a typical user's UA. But it generally implicitly registers other AORs associated with the SIP-PBX. 🌈
For both the 3GPP and ETSI mechanisms, the 200 OK response to the REGISTER request, sent after a successful authentication challenge, has a P-Associated-URI (PAU) [RFC3455] header field. That header lists the other SIP URIs or TEL URIs (aka phone numbers) of the SIP-PBX, which are implicitly registered AORs. The reachability info from the REGISTER request gets used to reach not just the one explicitly registered AOR, but also each implicitly registered AOR. To cut down on the number of PAU entries, a "wildcard" syntax model is defined [3GPP.23.003]. It uses a regular expression syntax in the user field of the URI to express multiple AORs in a compressed way. 🎀
For routing requests to any of the explicitly or implicitly registered AORs from the SSP to the SIP-PBX, the Request-URI is typically replaced with the registered Contact URI. In 3GPP and ETSI, the SSP has the option of using loose routing instead. It inserts the registered Contact URI as a loose route Route header field value and leaves the Request-URI alone. That decision is made based on manually provisioned info in the registrar's database, the Home Subscriber Server (HSS). 🧠
3.1. Issues with the REGISTER Transaction 😤
3.1.1. Mishandling by SIP-Aware Middleboxes
None of the currently available mechanisms indicate that a REGISTER request or response is any different from a "normal" one. That's caused issues when SIP-aware middleboxes sit between the SIP-PBX and the registrar. They serve both SIP-PBXs and normal UAs, but need to apply different policies to each case. 💀
Some middleboxes also expect the registrar to follow normal [RFC3261] procedures, meaning Request-URI replacement with the registered Contact URI for routing subsequent requests to the SIP-PBX. If the registrar does something different for requests to SIP-PBXs, the middlebox might fail to route those requests correctly. There's no sign the registration was any different. 🙈
Lastly, without an indication of implicit registration, troubleshooting is harder, because the on-the-wire messages are indistinguishable from "normal" registrations. Even the presence of a PAU header field in the response doesn't tell you that implicit registration for a SIP-PBX happened. That's because the PAU header field is also used for normal UAs with multiple identities. Not a clear signal at all, bestie. 🔍
3.1.2. REGISTER Response Growth
If a SIP-PBX represents many AORs, the PAU list in the response can grow the SIP message size beyond the limits for UDP. 🌸
3.1.3. Illegal "Wildcard" Syntax
Okay bestie, the current syntax for "wildcarded" PAUs is a no-go for TEL URIs 💀. Per the ABNF rules for TEL URIs in [RFC3966], it's illegal. 🙈
3.2. Issues with Routing Inbound Requests to the SIP-PBX
3.2.1. Loss of Target Information
Here's the vibe: if the proxy-registrar follows [RFC3261] for registration resolution on requests aimed at one of the SIP-PBX's AORs, and it swaps the Request-URI for the registered Contact URI, it gets really unclear which AOR was the actual target. 😭 The To URI might not have the intended target AOR at all, especially if the request got forwarded or retargeted before it reached the proxy-registrar. Some middleboxes between the registrar and the SIP-PBX overwrite the Request-URI specifically to patch this up. 🩹
Sometimes the intended target AOR shows up in a P-Called-Party-ID header field [RFC3455], and sometimes it's in the History-Info header field [RFC4244]. So the SIP-PBX needs to know where to look for the info it needs. And if it's History-Info, it also needs to figure out which particular element holds the goods. 🔍
3.2.2. Inconsistent Placement of Target URI Information in Inbound Requests
Even when the SIP-PBX gets all the info it needs, deployments can be super inconsistent. 🙃 In some setups, inbound SIP requests from the SSP stick the registered SIP-PBX Contact URI in the Request-URI. In other setups, the Request-URI holds the intended target SIP-PBX user (AOR), and the Contact URI goes in the Route header field instead. And there are other variants too! 🌀
So when a SIP-PBX built or configured for one variant tries to talk to an SSP built or configured for another, things break. Interop drama, bestie. 💔
3.2.3. Request-URI Misrouting
Many SIP-PBXs do support registration with an SSP, but they don't see themselves as authoritative for the explicitly or implicitly registered AORs if the domain portion still points at the SSP's domain. 🙅♀️ They expect that domain portion to be their own IP Address, Fully Qualified Domain Name (FQDN), or domain. Right now, middleboxes have to patch that gap. 🩹
3.3. Policy-Related Issues
These are mostly policy matters for the SSP, but heads up: the policies described below won't work in some situations. 👀 A mechanism for fixing the SIP-PBX registration problem won't directly solve these policy issues. Still, while specifying the mechanism, we can take the chance to call out how these policies hit things. 📣
3.3.1. Authorization Policy Mismatches
Lots of SSPs do a first-order authorization check on requests from the SIP-PBX. They look at the URI in the From, P-Asserted-Identity (PAI), or P-Preferred-Identity (PPI) [RFC3325] header field, and they want it to match an AOR that's explicitly or implicitly registered for the same Contact URI and/or Layer-3 IP Address. 🔐
The problem is that some SIP-PBXs use a different Contact URI for non-REGISTER requests than the one they explicitly registered. For example, they might change the user portion of the Contact URI, or even the host portion. 😬 This is especially common when a SIP-PBX acts as a proxy and forwards the Contact URI from the UA behind it (the SIP-PBX is usually identified in a Record-Route header field), instead of acting as a Back-to-Back User Agent (B2BUA) and swapping in its own Contact URI.
So the SSP can fail to find an AOR matching the Contact URI for non-REGISTER requests. The result? The SSP rejects those requests, or it asserts its own PAI value instead of one based on the header fields it received. Ugh. 💅
3.3.2. PAI or PPI URI Mismatches
Some SSPs expect the PAI or PPI URI in SIP requests from the SIP-PBX to match one of the explicitly or implicitly registered AORs. Meanwhile, some SIP-PBXs generate those URIs using their local IP Address, hostname, or domain name. 🙄
Some SSPs also expect the PAI or PPI URI to be only the explicitly registered AOR, since it's the main billing number, rather than the implicitly registered AOR of the calling party. Either way, the SSP might reject requests whose values don't match, or it might assert its own PAI value. 💀
Again, these are policy matters for the SSP, but the drawbacks are worth knowing about. 📝 Rejecting requests can rule out legit requests coming from beyond the SIP-PBX, like calls the SIP-PBX forwarded. The only way around that is for the SIP-PBX to rewrite the PAI or PPI URI into a value the SSP accepts, but then it no longer identifies the calling user. And if the SSP rewrites the PAI or PPI URI, the request fails to identify the calling user too. Circle of pain. 🌀
4. Requirements ✅
Here's what the mechanism has to do, no cap. 💖
- REQ1: The mechanism MUST let a SIP-PBX enter a trunking arrangement with an SSP, where both parties have agreed on a set of telephone numbers assigned to the SIP-PBX. 📞
- REQ2: The mechanism MUST let a set of assigned telephone numbers include E.164 numbers, which can be in contiguous ranges, discrete, or any mix of the two. 🔢
- REQ3: The mechanism MUST let a SIP-PBX register its reachability information with its SSP, so the SSP can route inbound requests aimed at the assigned telephone numbers over to the SIP-PBX. 🛤️
- REQ4: The mechanism MUST let UAs attached to a SIP-PBX register with the SIP-PBX for AORs based on assigned telephone numbers. That way they can receive requests aimed at those numbers, without the SSP having to be involved in the registration. 🙌
- REQ5: The mechanism MUST let a SIP-PBX handle requests from its own UAs that are aimed at its assigned telephone numbers, without sending those requests out to the SSP. 🏠
- REQ6: The mechanism MUST let a SIP-PBX receive requests to its assigned telephone numbers that came from outside the SIP-PBX and arrived via the SSP. The SIP-PBX can then route them onward to its UAs, just like it would for internal requests to those numbers. 🚀
- REQ7: The mechanism MUST provide a way for a SIP-PBX to know which of its assigned telephone numbers an inbound request from its SSP is targeting. 🎯
- REQ8: The mechanism MUST provide a way to avoid problems caused by one side using the mechanism while the other side doesn't. 🫣
In other words, the mechanism has to avoid the situation where one side thinks it's using the mechanism and the other side thinks it isn't. For example, the SIP-PBX thinks it's registering multiple telephone numbers, but the SSP thinks only a single AOR is being registered. 🙈
- REQ9: The mechanism MUST follow SIP backwards compatibility principles. 🔙
In other words, the mechanism has to provide a graceful way to recover or fall back if either side doesn't support it. For example, this might involve using an option tag. 🏷️
- REQ10: The mechanism MUST work when there's a sequence of intermediate SIP entities on the SIP-PBX-to-SSP interface (that is, between the SIP-PBX and the SSP's domain proxy), as long as those intermediate SIP entities indicated during registration that they need to be on the path of inbound requests to the SIP-PBX. 🛣️
These intermediate SIP entities can be edge proxies, session border controllers, and so on. 🧚
- REQ11: The mechanism MUST work when a SIP-PBX gets its IP address dynamically. 🌐
- REQ12: The mechanism MUST work without requiring the SIP-PBX to have a domain name, or the ability to publish its domain name in the DNS. 🙅♀️
- REQ13: For a given SIP-PBX and its SSP, there MUST be no impact on other domains. Those domains are expected to be able to use normal RFC 3263 procedures to route requests, including requests that need to go via the SSP to reach the SIP-PBX. 🌍
- REQ14: The mechanism MUST be able to operate over a transport that provides end-to-end integrity protection and confidentiality between the SIP-PBX and the SSP, for example using Transport Layer Security (TLS) as specified in [RFC3261]. 🔒
- REQ15: The mechanism MUST support authentication of the SIP-PBX by the SSP, and vice versa. For example, that could be SIP digest authentication plus TLS server authentication as specified in [RFC3261]. 🤝
- REQ16: The mechanism MUST let the SIP-PBX give its UAs public or temporary Globally Routable UA URIs (GRUUs) [RFC5627]. 🌟
- REQ17: The mechanism MUST work over any existing transport specified for SIP, including UDP. 🚚
- REQ18: Documentation MUST give guidance or warnings about how authorization policies may be affected by the mechanism, to address the problems described in Section 3.3. 📚
- REQ19: The mechanism MUST be extensible, so a set of assigned telephone numbers can include local numbers as specified in [RFC3966], which can be in contiguous ranges, discrete, or any mix of the two. 🧩
- REQ20: The mechanism MUST be extensible to allow a set of arbitrarily assigned SIP URI's as specified in [RFC3261], not just telephone numbers. And it should do that without needing a complete change of mechanism compared to the one used for telephone numbers. 🦋
5. Desirables 🍓
These are the desirable properties of the mechanism. 💜
On top of the desirables below, the big goal is to require only relatively modest changes to a large population of existing SSP and SIP-PBX implementations. That's how we get a fast market adoption of the standardized mechanism. Ease of market adoption is paramount here, bestie! ✨ A lot of SIP-PBXs and SSPs already use mechanisms based on the REGISTER method, and needing big changes to those implementations would discourage everyone from converging on a single standard for the foreseeable future. 😩
- DES1: The mechanism SHOULD let an SSP use its mechanisms for providing SIP service to normal UAs in order to provide a SIP trunking service to SIP-PBXs. 🎀
- DES2: The mechanism SHOULD scale to SIP-PBXs with several thousand assigned telephone numbers. 🔢
This will probably rule out any mechanism that involves a separate REGISTER transaction per assigned telephone number. 🙅♀️
In practice, the mechanism is more likely to be used on SIP-PBXs with up to a few hundred telephone numbers. But it's impossible to give a precise limit, which is why we want to be able to support several thousand. 🧮
- DES3: The mechanism SHOULD scale to support several thousand SIP-PBXs on a single SSP. 🌈
6. Non-Requirements 🧚
Okay so this part is about what's not on the to-do list 💅. How a third domain routes a request to the SSP for onward delivery to the SIP-PBX is outside the scope of this work 🦋. It's kinda related to REQ13, which says normal routing based on RFC 3263 should be used 🎀.
Provisioning is also out of scope, no cap 💀. An SSP has to assign a set of telephone numbers to a SIP-PBX, and the SIP-PBX has to know that set and hand those numbers out to its users 📞. How the SIP-PBX gets its assigned numbers from its SSP automatically is considered a provisioning topic, so it's a different conversation 🌸.
7. Security considerations 🔐
The security of signaling between the SIP-PBX and the SSP is seriously important 😭. Some of the requirements above already cover this, so you've got a head start ✨.
It is especially important that an entity acting as a SIP-PBX cannot register with an SSP and receive inbound requests it isn't entitled to 🚨. Nobody gets to sneak into someone else's phone numbers, periodt 💅.
The SSP is assumed to have procedures for checking that a SIP-PBX is entitled to use a set of E.164 telephone numbers before it agrees to let that SIP-PBX use them with this mechanism 🕵️♀️. Also, by authenticating the SIP-PBX when it provides reachability information, the SSP can be sure it only delivers inbound requests to the correct destination 🔒. That's the main character move right there 👑.
8. Acknowledgements 🫶
The contents of this document were compiled from extensive discussions within the MARTINI WG 🌈. There were way too many people involved to mention every single one, so huge love to all of them 💖.
9. References 📚
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.9.2. Informative References
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002.
[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project
(3GPP)", RFC 3455, January 2003.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC4244] Barnes, M., "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 4244,
November 2005.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009.
[3GPP.23.003]
3GPP, "Numbering, addressing and identification", 3GPP
TS 23.003 3.15.0, October 2006.
[3GPP.24.229]
3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP); Stage 3", 3GPP TS 24.229 10.0.0,
June 2010.
[ETSI_TS_182025]
ETSI TS 182 025, "Telecommunications and Internet
converged Services and Protocols for Advanced Networking
(TISPAN); Business trunking; Architecture and functional
description".Authors' Addresses 🎀
John Elwell
Siemens Enterprise Communications
EMail: john.elwell@siemens-enterprise.com
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803
USA
EMail: hkaplan@acmepacket.com📦 where this page comes from
- ietf: rfc5947 2010-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms