diff options
Diffstat (limited to 'doc/rfc/rfc5947.txt')
| -rw-r--r-- | doc/rfc/rfc5947.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc5947.txt b/doc/rfc/rfc5947.txt new file mode 100644 index 0000000..c4ef49a --- /dev/null +++ b/doc/rfc/rfc5947.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Elwell +Request for Comments: 5947 Siemens Enterprise Communications +Category: Informational H. Kaplan +ISSN: 2070-1721 Acme Packet + September 2010 + + + Requirements for Multiple Address of Record (AOR) Reachability + Information in the Session Initiation Protocol (SIP) + +Abstract + + This document states requirements for a standardized SIP registration + mechanism for multiple addresses of record (AORs), the mechanism + being suitable for deployment by SIP service providers on a large + scale in support of small to medium sized Private Branch Exchanges + (PBXs). The requirements are for a solution that can, as a minimum, + support 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. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5947. + + + + + + + + + + + + + + + + + +Elwell & Kaplan Informational [Page 1] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + +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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided 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 ....................................12 + + + + + + + + + + + +Elwell & Kaplan Informational [Page 2] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + +1. Introduction + + The Session Initiation Protocol (SIP) [RFC3261], together with its + extensions, supports multiple means of obtaining the connection + information necessary 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) within its domain, it can use a + location service to obtain the registered Contact Universal Resource + Identifiers (URIs), together with any associated path information + [RFC3327], and build a route set to reach each target user agent + (UA). The SIP REGISTER method can be used to register Contact URIs + and path information. SIP-outbound [RFC5626] enhances this mechanism + to cater to UAs behind Network Address Translators (NATs) and + firewalls. When an entity needs to send a request to a target for + which it is not authoritative, the entity can follow [RFC3263] + procedures for using the Domain Name System (DNS) to obtain the next- + hop connection information. + + In practice, many small- and medium-sized businesses use a SIP + Private Branch Exchange (SIP-PBX) that is authoritative for tens or + hundreds of SIP AORs. This SIP-PBX acts as a registrar/proxy for + these AORs for users hosted by the SIP-PBX. A SIP Service Provider + (SSP) provides SIP peering/trunking capability to the SIP-PBX. The + SIP-PBX needs to be reachable from the SSP so that the SSP can handle + inbound out-of-dialog SIP requests targeted at these AORs, routing + these requests to the SIP-PBX for onward delivery to registered UAs. + + Experience has shown that existing mechanisms are not always + sufficient to support SIP-PBXs for small/medium businesses. In + particular, RFC 3263 procedures are generally inappropriate, except + for some larger SIP-PBXs. In current deployments, mechanisms for the + dynamic provision of reachability information based on the SIP + REGISTER method are commonly used. However, these mechanisms vary in + detail, leading to interoperability issues between SIP-PBXs and SSPs, + and the need for equipment to support different variants. A more + detailed statement of the problem is given in Section 3. + + This document states requirements for a standardized SIP registration + mechanism for multiple AORs, the mechanism being suitable for + deployment by SSPs on a large scale in support of small- to medium- + sized SIP-PBXs. The requirements are for a solution that can, as a + minimum, support AORs based on E.164 numbers. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + +Elwell & Kaplan Informational [Page 3] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + + The terms address of record (AOR), proxy, REGISTER, registrar, + request, response, and user agent (UA) are to be interpreted as + described in [RFC3261]. + +3. Problem Statement + + A number of other standards organizations have addressed the issue of + a SIP-PBX registering with its SSP, notably ETSI [ETSI_TS_182025] and + 3rd Generation Partnership Project (3GPP) [3GPP.24.229]. Also, + various SSPs have produced proprietary specifications for use with + their own offerings. The reader is encouraged to review the + documents produced by those organizations. + + A short summary of the general concept is as follows. The figure + below illustrates 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 virtually all models, the SIP-PBX generates a SIP REGISTER request + using a mutually agreed-upon SIP AOR -- typically based on the SIP- + PBX's main attendant-/reception-desk number. The AOR is often in the + domain of the SSP, and both the To and From URIs used for the + REGISTER request identify that AOR. In all respects, it appears on + + + + + +Elwell & Kaplan Informational [Page 4] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + + the wire as a "normal" SIP REGISTER request, as if from a typical + user's UA. However, it generally implicitly registers other AORs + associated with the SIP-PBX. + + For both 3GPP and ETSI mechanisms, the 200 OK response to the + REGISTER request, sent after a successful authentication challenge, + contains a P-Associated-URI (PAU) [RFC3455] header field listing the + other SIP URIs or TEL URIs (i.e., phone numbers) of the SIP-PBX, + which are implicitly registered AORs. The registered reachability + information from the REGISTER request will be used to reach not only + the single explicitly registered AOR but also each of the implicitly + registered AORs. In order to reduce the number of PAU entries, a + "wildcard" syntax model is defined [3GPP.23.003], which uses a + regular expression syntax in the user field of the URI to express + multiple AORs in a compressed manner. + + For routing requests for 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 the case of + 3GPP and ETSI, the SSP has the option of using loose routing instead, + and inserting the registered Contact URI as a loose route Route + header field value, while leaving the Request-URI alone. This + decision is made based upon manually provisioned information in the + registrar's database (i.e., 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 the REGISTER + request or response is any different from a "normal" REGISTER request + or response. This has caused issues when SIP-aware middleboxes + between the SIP-PBX and the registrar serve both SIP-PBXs and normal + UAs yet need to apply different policies to the two cases. + + Furthermore, some middleboxes expect the registrar to follow normal + [RFC3261] procedures of Request-URI replacement with the registered + Contact URI for routing subsequent requests to the SIP-PBX. If the + registrar adopts a different practice for requests to SIP-PBXs, this + can cause the middlebox to fail to route such requests correctly, + because there is no indication that the registration was any + different. + + Lastly, lack of an indication of implicit registration makes + troubleshooting more difficult because the on-the-wire messages are + indistinguishable from "normal" registrations. Note that even the + + + + + +Elwell & Kaplan Informational [Page 5] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + + existence of a PAU header field in the response does not indicate + that implicit registration for a SIP-PBX has occurred, since the PAU + header field is also used for normal UAs with multiple identities. + +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 + + The current syntax for "wildcarded" PAUs is illegal for TEL URIs, + based on the ABNF rules for TEL URIs in [RFC3966]. + +3.2. Issues with Routing Inbound Requests to the SIP-PBX + +3.2.1. Loss of Target Information + + If the proxy-registrar follows [RFC3261] for registration resolution + of requests targeted at one of the SIP-PBX's AORs, and thus replaces + the Request-URI with the registered Contact URI, it is not clear + which AOR is the intended target of the request. The To URI, for + example, may not contain the intended target AOR if the request was + forwarded/retargeted prior to reaching the proxy-registrar. Some + middleboxes between the registrar and SIP-PBX will overwrite the + Request-URI specifically to try to fix this issue. In some cases, a + P-Called-Party-ID header field [RFC3455] will contain the intended + target AOR; and in some cases, the History-Info header field + [RFC4244] will contain it. The SIP-PBX needs to know where to look + to find the required information and, in the case of History-Info, + needs to identify the particular element containing the required + information. + +3.2.2. Inconsistent Placement of Target URI Information in Inbound + Requests + + Even when all information needed by the SIP-PBX is provided, in some + deployments, inbound SIP requests from the SSP have the registered + SIP-PBX Contact URI in the Request-URI, whereas in other deployments + inbound SIP requests have the intended target SIP-PBX user (AOR) in + the Request-URI and the Contact URI in the Route header field. There + are other variants, too. Interoperability problems arise when a SIP- + PBX designed or configured for one variant attempts to interwork with + an SSP designed or configured for another variant. + + + + + + + +Elwell & Kaplan Informational [Page 6] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + +3.2.3. Request-URI Misrouting + + Although many SIP-PBXs support registration with an SSP, they do not + consider themselves authoritative for the explicitly or implicitly + registered AORs if the domain portion still identifies the SSP's + domain. They expect the domain portion to be their own IP Address, + Fully Qualified Domain Name (FQDN), or domain. Currently, + middleboxes have to fix that issue. + +3.3. Policy-Related Issues + + The following are largely policy matters for the SSP, but it should + be noted the policies described below will not work in some + situations. A mechanism for solving the SIP-PBX registration problem + will not solve these policy issues directly, although when specifying + the mechanism, the opportunity can be taken to highlight the impact + of such policies. + +3.3.1. Authorization Policy Mismatches + + Many SSPs perform a first-order level of authorization for requests + from the SIP-PBX by checking the URI in the From, P-Asserted- + Identity (PAI), or P-Preferred-Identity (PPI) [RFC3325] header field + for one matching either an explicitly or implicitly registered AOR + for the same Contact URI and/or Layer-3 IP Address. However, some + SIP-PBXs change the Contact URI they use for non-REGISTER requests to + be different from the one they explicitly registered. For example, + they change the user portion of the Contact URI, or even the host + portion. This is particularly true for a SIP-PBX operating as a + proxy and forwarding the Contact URI from the UA behind the SIP-PBX + (the SIP-PBX typically being identified in a Record-Route header + field), rather than acting as a Back-to-Back User Agent (B2BUA) and + substituting its own Contact URI. This can cause an SSP to fail to + find an AOR corresponding to the Contact URI for non-REGISTER + requests, resulting in the SSP rejecting such requests or asserting + its own PAI value, rather than asserting a value based on received + header fields. + +3.3.2. PAI or PPI URI Mismatches + + Some SSPs expect the PAI or PPI URI in SIP requests received from the + SIP-PBX to match one of the explicitly or implicitly registered AORs, + whereas some SIP-PBXs generate the URIs using their local IP Address, + hostname, or domain name. Some SSPs expect the PAI or PPI URI in SIP + requests received from the SIP-PBX to be the explicitly registered + + + + + + +Elwell & Kaplan Informational [Page 7] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + + AOR only, as it is the main billing number, instead of the implicitly + registered AOR of the calling party. In either case, this can result + in the SSP rejecting requests with values that do not match, or + asserting its own PAI value. + + Again, these are policy matters for the SSP, but drawbacks should be + noted. For example, rejection of requests can rule out requests from + sources beyond the SIP-PBX (e.g., calls forwarded by the SIP-PBX), + unless the SIP-PBX changes the PAI or PPI URI to a value acceptable + to the SSP (in which case it will no longer identify the calling + user). If the SSP changes the PAI or PPI URI, again the request will + fail to identify the calling user. + +4. Requirements + + The following are requirements of the mechanism. + + REQ1: The mechanism MUST allow a SIP-PBX to enter into a trunking + arrangement with an SSP whereby the two parties have agreed + on a set of telephone numbers assigned to the SIP-PBX. + + REQ2: The mechanism MUST allow a set of assigned telephone numbers + to comprise E.164 numbers, which can be in contiguous ranges, + discrete, or in any combination of the two. + + REQ3: The mechanism MUST allow a SIP-PBX to register reachability + information with its SSP, in order to enable the SSP to route + to the SIP-PBX inbound requests targeted at assigned + telephone numbers. + + REQ4: The mechanism MUST allow UAs attached to a SIP-PBX to + register with the SIP-PBX for AORs based on assigned + telephone numbers, in order to receive requests targeted at + those telephone numbers, without needing to involve the SSP + in the registration process. + + REQ5: The mechanism MUST allow a SIP-PBX to handle requests + originating at its own UAs and targeted at its assigned + telephone numbers, without routing those requests to the SSP. + + REQ6: The mechanism MUST allow a SIP-PBX to receive requests to its + assigned telephone numbers originating outside the SIP-PBX + and arriving via the SSP, so that the SIP-PBX can route those + requests onwards to its UAs, as it would for internal + requests to those telephone numbers. + + + + + + +Elwell & Kaplan Informational [Page 8] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + + REQ7: The mechanism MUST provide a means whereby a SIP-PBX knows at + which of its assigned telephone numbers an inbound request + from its SSP is targeted. + + REQ8: The mechanism MUST provide a means of avoiding problems due + to one side using the mechanism and the other side not. + + In other words, the mechanism is required to avoid the + situation where one side believes it is using the + mechanism and the other side believes it is not, e.g., the + SIP-PBX believes it is performing the registration of + multiple telephone numbers, but the SSP believes a single + AOR is being registered. + + REQ9: The mechanism MUST observe SIP backwards compatibility + principles. + + In other words, the mechanism is required to provide a + graceful means of recovery or fall-back if either side + does not support the mechanism. For example, this might + involve the use of an option tag. + + REQ10: The mechanism MUST work in the presence of a sequence of + intermediate SIP entities on the SIP-PBX-to-SSP interface + (i.e., between the SIP-PBX and the SSP's domain proxy), where + those intermediate SIP entities indicated during registration + a need to be on the path of inbound requests to the SIP-PBX. + + These intermediate SIP entities can be edge proxies, + session border controllers, etc. + + REQ11: The mechanism MUST work when a SIP-PBX obtains 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, which are expected to be able to use normal + RFC 3263 procedures to route requests, including requests + needing to be routed via the SSP in order 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, e.g., using Transport Layer + Security (TLS) as specified in [RFC3261]. + + + +Elwell & Kaplan Informational [Page 9] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + + REQ15: The mechanism MUST support authentication of the SIP-PBX by + the SSP and vice versa, e.g., using SIP digest authentication + plus TLS server authentication as specified in [RFC3261]. + + REQ16: The mechanism MUST allow the SIP-PBX to provide its UAs with + 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 to allow a set of assigned + telephone numbers to comprise local numbers as specified in + [RFC3966], which can be in contiguous ranges, discrete, or in + any combination of the two. + + REQ20: The mechanism MUST be extensible to allow a set of + arbitrarily assigned SIP URI's as specified in [RFC3261], as + opposed to just telephone numbers, without requiring a + complete change of mechanism as compared to that used for + telephone numbers. + +5. Desirables + + The following are desirable properties of the mechanism. + + In addition to the desirables below, the general aim is to require + only relatively modest changes to a substantial population of + existing SSP and SIP-PBX implementations, in order to encourage a + fast market adoption of the standardized mechanism. Ease of market + adoption is paramount here. Many SIP-PBXs and SSPs have implemented + mechanisms based on the REGISTER method, and the need for substantial + changes to those implementations will discourage convergence on a + single standard in the foreseeable future. + + DES1: The mechanism SHOULD allow an SSP to exploit its mechanisms + for providing SIP service to normal UAs in order to provide a + SIP trunking service to SIP-PBXs. + + + + + + + + + +Elwell & Kaplan Informational [Page 10] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + + DES2: The mechanism SHOULD scale to SIP-PBXs of several thousand + assigned telephone numbers. + + This will probably preclude any mechanism involving 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 + is impossible to give a precise limit, and hence the desire + 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 + + The means by which a third domain can route a request to the SSP for + onward delivery to the SIP-PBX is outside the scope of this work. + This is related to REQ13, which requires normal routing based on RFC + 3263 be used. + + Provisioning is outside the scope of this work. In particular, an + SSP will need to assign a set of telephone numbers to a SIP-PBX, and + a SIP-PBX will need to be aware of the set of assigned numbers and + allocate those numbers to its users. Automated means for a SIP-PBX + to obtain, from its SSP, the set of assigned telephone numbers is + considered to be a provisioning topic. + +7. Security considerations + + The security of signaling between the SIP-PBX and the SSP is + important. Some of the requirements above already address this. + + In particular, it is important that an entity acting as a SIP-PBX + cannot register with an SSP and receive inbound requests to which it + is not entitled. The SSP is assumed to have procedures for ensuring + that a SIP-PBX is entitled to use a set of E.164 telephone numbers + prior to entering into agreement with that SIP-PBX for using those + telephone numbers with this mechanism. Furthermore, by + authenticating the SIP-PBX when it provides reachability information, + the SSP can be sure that it delivers inbound requests only to the + correct destination. + + + + + + + + +Elwell & Kaplan Informational [Page 11] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + +8. Acknowledgements + + The contents of the document have been compiled from extensive + discussions within the MARTINI WG, the individuals concerned being + too numerous to mention. + +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. + + + +Elwell & Kaplan Informational [Page 12] + +RFC 5947 Multiple AOR reachability in SIP September 2010 + + + [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 + + + + + + + + + + + + + + + + +Elwell & Kaplan Informational [Page 13] + |