Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP)
draft-ietf-martini-reqs-08.txt

Abstract

This document states requirements for a standardized SIP registration mechanism for multiple addresses of record, 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.

This work is being discussed on the martini@ietf.org mailing list.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on December 30, 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
2.  Terminology
3.  Problem statement
    3.1.  Issues with the REGISTER transaction
        3.1.1.  No explicit indicator
        3.1.2.  REGISTER response growth
        3.1.3.  Illegal wildcarding syntax
    3.2.  Issues with routing inbound requests to the SIP-PBX
        3.2.1.  Loss of target information
        3.2.2.  Inconsistent placement of target URI information in inbound requests
        3.2.3.  Request-URI mis-routing
    3.3.  Policy-related issues
        3.3.1.  Authorization policy mismatches
        3.3.2.  PAI or PPI URI mismatches
4.  Requirements
5.  Desirables
6.  Non-requirements
7.  IANA considerations
8.  Security considerations
9.  Acknowledgements
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses

1.  Introduction

The Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), 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] (Willis, D. and B. Hoeneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts,” December 2002.), 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] (Jennings, C., Mahy, R., and F. Audet, “Managing Client-Initiated Connections in the Session Initiation Protocol (SIP),” October 2009.) enhances this mechanism to cater for 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] (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.) 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, implementations of this mechanism 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 Section 3 (Problem statement).

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

The terms address of record (AOR), proxy, REGISTER, registrar, request, response and user agent (UA) are to be interpreted as described in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).

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 182 025] (, “ETSI TS 182 025 "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Business trunking; Architecture and functional description",” .) and 3GPP [3GPP TS 24.229] (, “3GPP TS 24.229 "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3",” .). 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.

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 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] (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),” January 2003.) 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 TS 23.003] (, “3GPP TS 23.003 "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification",” .), 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.  No explicit indicator

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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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 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 an 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 wildcarding syntax

The current syntax for "wildcarded" PAUs is illegal for TEL URIs, based on the ABNF rules for TEL URIs.

3.2.  Issues with routing inbound requests to the SIP-PBX

3.2.1.  Loss of target information

If the proxy-registrar follows [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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] (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),” January 2003.) will contain the intended target AOR; and in some cases the History-Info header field [RFC4244] (Barnes, M., “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.) 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 for or configured for one variant attempts to interwork with an SSP designed for or configured for another variant.

3.2.3.  Request-URI mis-routing

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, 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] (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.) 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 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 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.

REQ7 - The mechanism MUST provide a means whereby a SIP-PBX knows which of its assigned telephone numbers an inbound request from its SSP is targeted at.

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 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 TLS as specified in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).

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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).

REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with public or temporary Globally Routable UA URIs (GRUUs) [RFC5627] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP),” October 2009.).

REQ17 - The mechanism MUST work over any existing transport specified for SIP, including UDP.

REQ19 - 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 (Policy-related issues).

REQ20 - The mechanism MUST be extensible to allow a set of assigned telephone numbers to comprise local numbers as specified in [RFC3966] (Schulzrinne, H., “The tel URI for Telephone Numbers,” December 2004.), which can be in contiguous ranges, discrete, or in any combination of the two.

REQ21 - The mechanism MUST be extensible to allow a set of arbitrarily assigned SIP URI's as specified in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), 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.

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 to be used.

Provisioning is outside the scope of this work. In particular, a 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.  IANA considerations

This document requires no IANA actions.

8.  Security considerations

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.

9.  Acknowledgements

The contents of the document have been compiled from extensive discussions within the MARTINI WG, the individuals concerned being too numerous to mention.

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses