MARTINI WG                                                     J. Elwell
Internet-Draft                         Siemens Enterprise Communications
Intended status:  Informational                                H. Kaplan
Expires:  August 23, 2010                                    Acme Packet
                                                       February 19, 2010


     Requirements for multiple address of record (AOR) reachability
          information in the Session Initiation Protocol (SIP)
                     draft-ietf-martini-reqs-01.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 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 to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 23, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Elwell & Kaplan          Expires August 23, 2010                [Page 1]

Internet-Draft      Multiple AOR reachability in SIP       February 2010


   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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Problem statement  . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Issues with the REGISTER transaction . . . . . . . . . . .  5
       3.1.1.  No explicit indicator  . . . . . . . . . . . . . . . .  5
       3.1.2.  Undefined behaviour on PAU mismatch  . . . . . . . . .  5
       3.1.3.  REGISTER response growth . . . . . . . . . . . . . . .  5
       3.1.4.  Illegal wildcarding syntax . . . . . . . . . . . . . .  5
     3.2.  Issues with routing requests . . . . . . . . . . . . . . .  6
       3.2.1.  Loss of target information . . . . . . . . . . . . . .  6
       3.2.2.  Request-URI vs. loose-route mismatches . . . . . . . .  6
       3.2.3.  Request-URI mis-routing  . . . . . . . . . . . . . . .  6
     3.3.  Policy-related issues  . . . . . . . . . . . . . . . . . .  6
       3.3.1.  Authorization policy mismatches  . . . . . . . . . . .  6
       3.3.2.  PAI or PPI URI mismatches  . . . . . . . . . . . . . .  7
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Desirables . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Non-requirements . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Security considerations  . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12













Elwell & Kaplan          Expires August 23, 2010                [Page 2]

Internet-Draft      Multiple AOR reachability in SIP       February 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 URI(s), 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 for UAs behind NATs and
   firewalls.  When a 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-PBX
   that is authoritative for tens or hundreds of SIP AORs.  This SIP-PBX
   acts as a registrar/proxy for these AORs for clients hosted by the
   SIP-PBX.  UAs register with the SIP-PBX on behalf of the AORs
   concerned.  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.

   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 PBXs.  The requirements are for a solution that can, as a
   minimum, support AORs based on E.164 numbers.  The ability to handle
   other forms of AOR is outside the scope of this document, although a
   solution that can handle other forms of AOR is not precluded if it
   does not lead to significant additional complexity or a delay in
   producing the standard.




Elwell & Kaplan          Expires August 23, 2010                [Page 3]

Internet-Draft      Multiple AOR reachability in SIP       February 2010


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].

   The terms address of record (AOR), proxy, REGISTER, registrar,
   request 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] and 3GPP
   [3GPP].  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 almost always
   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" first-party SIP REGISTER request, as if from a
   typical subscriber 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 or TEL URI Identities (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, 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



Elwell & Kaplan          Expires August 23, 2010                [Page 4]

Internet-Draft      Multiple AOR reachability in SIP       February 2010


   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 middleboxes between the
   SIP-PBX and the registrar serve both SIP-PBXs and normal subscriber
   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
   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 subscriber UAs with multiple
   identities.

3.1.2.  Undefined behaviour on PAU mismatch

   There is no defined behavior for the SIP-PBX if the PAU header
   field's list of URIs does not match what the SIP-PBX expects it to
   be.  It is not clear if the SIP-PBX should de-register, re-register,
   or ignore the difference; nor is there a way for the SIP-PBX to
   indicate the error in signaling.

3.1.3.  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.4.  Illegal wildcarding syntax

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





Elwell & Kaplan          Expires August 23, 2010                [Page 5]

Internet-Draft      Multiple AOR reachability in SIP       February 2010


3.2.  Issues with routing requests

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.  Request-URI vs. loose-route mismatches

   Some SIP-PBXs expect that inbound SIP requests from the SSP will have
   the registered Contact-URI in the Request-URI, and thus not
   interoperate with the loose-route scheme of 3GPP and ETSI.  Other
   SIP-PBXs are fine with the Request-URI being the intended target, but
   cannot handle receiving a Route header field identifying their
   registered Contact-URI as a loose-route entry.

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-



Elwell & Kaplan          Expires August 23, 2010                [Page 6]

Internet-Draft      Multiple AOR reachability in SIP       February 2010


   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.  If no match is
   found, the request is rejected.  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 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.

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.  This triggers request rejection or PAI
   overwriting.

   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.

   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 deemed to have been 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



Elwell & Kaplan          Expires August 23, 2010                [Page 7]

Internet-Draft      Multiple AOR reachability in SIP       February 2010


   SIP-PBX inbound requests targeted at assigned telephone numbers.

   REQ4 - The mechanism MUST NOT prevent UAs attached to a SIP-PBX
   registering with the SIP-PBX on behalf of 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 internally
   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 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 intermediate SIP
   entities on the SSP side of the SIP-PBX-to-SSP interface (i.e.,
   between the SIP-PBX and the SSP's domain proxy), where those
   intermediate SIP entities need to be on the path of inbound requests
   to the PBX.

      These intermediate SIP entities can be edge proxies, session
      border controllers, etc..




Elwell & Kaplan          Expires August 23, 2010                [Page 8]

Internet-Draft      Multiple AOR reachability in SIP       February 2010


   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 integrity protection and confidentiality.

   REQ15 - The mechanism MUST support authentication of the SIP-PBX by
   the SSP and vice versa.

   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 NOT preclude the ability of the SIP-PBX to
   route on-PBX requests directly, without hair-pinning the signalling
   through the SSP.

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


5.  Desirables

   The following are desirable properties of the mechanism.

   DES1 - The mechanism SHOULD allow an SSP to exploit its mechanisms
   for providing SIP service to ordinary subscribers 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 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-



Elwell & Kaplan          Expires August 23, 2010                [Page 9]

Internet-Draft      Multiple AOR reachability in SIP       February 2010


   PBXs on a single SSP.

   DES4 - The mechanism SHOULD require 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.


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 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.



Elwell & Kaplan          Expires August 23, 2010               [Page 10]

Internet-Draft      Multiple AOR reachability in SIP       February 2010


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

   [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.

10.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.

   [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



Elwell & Kaplan          Expires August 23, 2010               [Page 11]

Internet-Draft      Multiple AOR reachability in SIP       February 2010


              Agent URIs (GRUUs) in the Session Initiation Protocol
              (SIP)", RFC 5627, October 2009.

   [3GPP]     "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"".

   [ETSI]     "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

   Phone:  +44 1908 855608
   Email:  john.elwell@siemens-enterprise.com


   Hadriel Kaplan
   Acme Packet
   71 Third Ave.
   Burlington, MA  01803
   USA

   Email:  hkaplan@acmepacket.com




















Elwell & Kaplan          Expires August 23, 2010               [Page 12]