[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
MARTINI WG                                                    H. Kaplan
Internet Draft                                              Acme Packet
Intended status: Standards-Track
Expires: November 3, 2011                                   May 3, 2010


                             SIP MARTINI with
        Other Logical Identifier Values which are not E.164 (OLIVE)
                    draft-kaplan-martini-with-olive-01


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 November 3, 2011.

Copyright and License 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 BSD License.




Kaplan                Expires November 18, 2010              [Page 1]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


Abstract

   The Martini Working Group is defining a mechanism for SIP IP-PBX
   type devices to REGISTER and obtain SIP service for E.164-based
   Address of Records.  This document defines a means for other, non-
   E.164 AoRs of the Registered-to SSP's domain to be used with
   Martini-based IP-PBXs.

Table of Contents

   1.    Introduction................................................2
   2.    Definitions.................................................3
   3.    Background on Current Martini Mechanism.....................3
   4.    The Solution - an Overview..................................4
   5.    Registering for AoRs........................................4
      5.1.   Registering Local Number AoRs...........................6
      5.2.   Registering for other domains...........................7
   6.    SSP Processing of Inbound Non-E.164 Requests................7
      6.1.   Processing of Local-Number Requests.....................8
   7.    Interaction with Other Mechanisms...........................8
      7.1.   Globally Routable User-Agent URIs (GRUU)................8
      7.2.   Registration Event Package..............................8
      7.3.   Non-Adjacent Contact Registration (Path) and Service Route
      Discovery......................................................9
   8.    Open Issues.................................................9
   9.    Examples....................................................9
      9.1.   Usage Scenario: Basic Registration case 1..............10
      9.2.   Usage Scenario: Basic Registration case 2..............12
   10.   IANA Considerations........................................13
   11.   Security Considerations....................................13
   12.   Acknowledgements...........................................13
   13.   Informative References.....................................14
   Author's Address.................................................15
   Appendix A - Why non-E.164 AoRs may need processing by SSPs......15
   Appendix B - Issues with non-E.164 Identifiers...................16
   o  Globally unique AoR...........................................16
   o  Registered Contact Username...................................16
   o  Avoiding syntax mismatches....................................17


1. Introduction

   In many deployed SIP Service Provider (SSP) architectures, it is
   common to use REGISTER requests to provide the reachability
   information for IP-PBXs, instead of DNS-based resolution and
   routing.  An IETF-defined mechanism for doing so is being worked on
   in the Martini Working Group, in [draft-gin].




Kaplan                 Expires - November 2009               [Page 2]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


   The current Martini mechanism only supports E.164-based AoRs,
   however in actual deployments private-extension or "local" numbers
   are used for hosted and carrier-provided intra-Enterprise calling
   services, and domain-scoped "email-style" URIs may become more
   popular in the near future.  Neither of these forms of AoRs are
   supported by the current Martini mechanism.  This document defines a
   means by which they can be supported, in a manner consistent with
   [RFC3261] and [draft-gin].

   Background information is provided in the Appendices.

2. Definitions

   For brevity's sake, this document uses the word "request" instead of
   "out-of-dialog request", but in all case means out-of-dialog
   request.

   AoR: address-of-record, as defined by RFC 3261: a URI by which the
   user is canonically known (e.g., on their business cards, in the
   From header field of their requests, in the To header field of
   REGISTER requests, etc.).

   Local-Number: an AoR which follows the form of local-number in
   [RFC3966], but may be encoded in a SIP or TEL URI.  The local-number
   contains a 'phone-context' parameter identifying the scope of its
   number.

   Email-style URI: a SIP AoR which does not identify a global E.164
   number or Local-Number.

   Implicit Registration: implicitly providing the reachability
   information for something other than the AoR explicitly indicated in
   the Register transaction.

   Reachability Information: a set of URI's identifying the host and
   path of Proxies to reach that host; like any URI, these URI's may
   identify the specific connection transport, IP Address, and port
   information, or they may only identify FQDN's.

   SSP: SIP Service Provider, as defined by [RFC5486].

3. Background on Current Martini Mechanism

   The current Martini mechanism, defined in [draft-gin], allows a SIP
   UA such as an IP-PBX to Register a set of E.164 AoRs in "bulk".
   Instead of creating a separate REGISTER transaction for every E.164
   AoR, the IP-PBX sends one REGISTER request with a 'bnc' Contact URI
   parameter which indicates the Contact URI needs to be expanded in
   the Registrar's location service database.  The expansion is such


Kaplan                 Expires - November 2009               [Page 3]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


   that each E.164 user number becomes the user portion of the
   Registered Contact URI, one for each implicitly Registered E.164
   number-based AoR.

   SIP Request routing to the Registered E.164 AoR then follows normal
   [RFC3261] procedures, replacing the Request URI with the (expanded)
   Registered Contact URI, and adding any Path information as a Route
   set, etc.

4. The Solution - an Overview

   The general concept proposed in this document is to simply apply
   [draft-gin] for any set of AoRs of the Registered-to domain, for any
   valid set of user strings as defined in [RFC3261].  The [draft-gin]
   REGISTER request would cause the Registrar to populate the set of
   AoRs to Contact bindings, as it did before.

   The Contact URI user portion would also be "expanded", using the
   same user portion as that of the implicitly Registered AoRs.  In the
   case of a Local-Number, the username is "normalized" in the same
   manner as [draft-gin].

   Note that the list of AoRs associated with a PBX is a matter of
   local provisioning at the SSP and at the PBX, as it was in [draft-
   gin].  The mechanism defined in this document does not provide any
   means to detect or recover from provisioning mismatches (although
   the registration event package can be used as a standardized means
   for auditing such AoRs).

   No new option-tag is required, because this document's mechanism
   does not require any changes in Martini [draft-gin] Registration or
   subsequent [RFC3261] routing behavior in the IP-PBX or any proxies
   along the path.  The routing follows the [RFC3261] Registered AoR-
   contact resolution model, which is a basic function of SIP.

   The only SIP devices affected by this document's mechanism is the
   SSP's Registrar, which needs to update the appropriate AoR entries,
   and any proxy/ies of the SSP which perform route resolution by
   looking up the contents of the (logical) location-service database.
   Since such proxies may not even be in the path of the REGISTER
   request, an option-tag will not help.  And since the Registrar and
   Proxies in question are all under control of the same administrative
   entity (the SSP), it is reasonable to expect them all to support
   this document's mechanism, if any do.

5. Registering for AoRs

   This document's mechanism relies on the Martini [draft-gin]
   Registration mechanism.  The IP-PBX Registers into the SSP, using a


Kaplan                 Expires - November 2009               [Page 4]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


   REGISTER request with the [draft-gin] option-tag in the Require and
   Proxy-Require header fields, and a Contact URI containing the
   [draft-gin] "bnc" URI parameter and no user portion.  After the PBX
   is authenticated, the registrar updates its location service so that
   each of the AoRs associated with the PBX creates a unique AOR to
   Contact mapping.  Semantically, each of these mappings will be
   treated as a unique row in the location service.  The actual
   implementation may, of course, perform internal optimizations to
   reduce the amount of memory used to store such information.

   For each of these unique rows, the AOR will be in the format that
   the SSP expects to receive from external parties (e.g.
   "sip:bob@ssp.example.com"), and the corresponding Contact will be
   formed adding a user portion to the REGISTER's Contact URI
   containing the AoR user name and removing the "bnc" parameter.  For
   example, if the Contact header field contains the URI
   <sip:198.51.100.3:5060;foo=bar;bnc>, then the Contact value
   associated with the aforementioned AOR will be
   <sip:bob@198.51.100.3:5060;foo=bar>.

   Local-Numbers have slightly different Contact URI expansion rules,
   as defined later.

   As in [draft-gin], aside from the "bnc" parameter, all URI
   parameters present in the Contact URI in the REGISTER message MUST
   be copied to the Contact value stored in the location service.

   If the SIP UA generating the REGISTER request (i.e., the IP-PBX) is
   implicitly Registering for "Email-style" AoRs, it MUST NOT include a
   "user=phone" URI parameter in the bulk Contact URI of the REGISTER
   request.  "Email-style" URI's are not phone numbers, and as such
   their expanded Contact value cannot have a "user=phone" or
   "user=dialstring" URI parameter.  Therefore, if the REGISTER
   request's Contact URI included a URI parameter named "user" with a
   value of "phone" or "dialstring", AoRs of "Email-style" MUST NOT be
   bound to the Contact of the REGISTER.  In other words, the UA has
   indicated it expects a phone or dialstring, and nothing else.

   Note that the location service database, and any entry model
   described here, is purely an abstract concept used by [RFC3261],
   [draft-gin], and this document; an actual implementation may do
   whatever it likes internally, so long as the external behavior
   follows the model.  For example, if an SSP does not maintain any
   specific knowledge of the Local Number dial-plan, but simply
   performs prefix or default routing for an Enterprise's private
   extensions, the SSP could just route based on the E.164 phone-
   context field value without having a separate physical "AoR"
   database entry for each local number of that context.



Kaplan                 Expires - November 2009               [Page 5]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


5.1. Registering Local Number AoRs

   Local-Numbers present a complexity for AoR Registration, because
   their user portion is scoped to the phone-context's value.  In
   practice the SSP domain may not have specific knowledge of any or
   all user names within a given phone-context's scope.  In fact, the
   Local-Number TEL URI parameters (which are URI user parameters in
   SIP URIs), may only have meaning to the ultimate target of the
   request, or some entity which is authoritative for the phone-
   context's user names.  Those parameters cannot be removed by the SSP
   if it does not actually process the user portions of the Local-
   Number. (i.e., if it does not have the dial-plan, etc.)

   With regard to this document's mechanism, what this means is that
   such an SSP cannot physically instantiate an AoR in a database for
   every possible Local-Number and cannot physically instantiate an
   expanded Contact URI for every possible Local-Number user name with
   every possible user parameter.  That does not inhibit the mechanism
   from working or being usable, however, because the location-service
   database model is purely an abstract concept.  What's important is
   that the route-resolving Proxy be able to lookup and replace an AoR
   it is authoritative for, to a Registered Contact URI, such that the
   resultant Request URI matches what the IP-PBX expects to receive.

   It is "safe" to do this because the explicitly Registered Contact
   URI of the [draft-gin] REGISTER request had no user portion, and
   thus no possible URI user parameters.  As defined in [draft-gin],
   the Contact URI parameters of the REGISTER are saved and reused, but
   not URI user parameters.

   There are multiple ways of describing the logical AoR instantiation
   and Contact URI expansion rules.  They could be described as
   covering every possible ABNF expansion, such that every possible
   user and parameter logically exists in the location-service database
   (but obviously not physically exists).  Or it could be described as
   only the phone-context value itself being an "AoR" entry and Contact
   URI expansion, with a policy to allow any and all user names and
   parameters to be copied instead of replaced by the Contact URI.

   This remains an open issue for discussion, as discussed in section
   8.

   Regardless, for an implicitly Registered SIP AoR with a URI user
   portion matching the syntax outlined for "local-number" TEL URIs in
   [RFC3966]: the Contact is expanded following the other AoR models,
   EXCEPT that all URI user parameters are also included.  For example,
   if the logically provisioned "AoR" from the previous examples were:
   "sip:12345;ext=678;phone-context=+1212555@ssp.example.com", it would
   logically get an automatically generated Contact value of


Kaplan                 Expires - November 2009               [Page 6]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


   <sip:12345;ext=678;phone-context=+1212555@198.51.100.3:5060;foo=bar>
   and if the AoR were "sip:12345;ext=678;phone-
   context=ssp.example.com@ssp.example.com", the resultant Contact
   value would be <sip:12345;ext=678;phone-
   context=ssp.example.com@198.51.100.3:5060;foo=bar>.

   Note that in practice it is not uncommon to receive a SIP URI which
   does not strictly comply with the formatting rules of [RFC3966], but
   is processed as if it were, based on local policies.  That is legal,
   of course, but from a logical perspective the SIP URI is actually
   retargeted or transformed into the syntactically valid form
   following [RFC3966], and that form MUST be the one used for routing,
   Contact URI expansions, etc.  Likewise, if the URI were a TEL URI,
   it MUST be logically transformed into a SIP URI of the SSP's domain
   as defined in section 19.1.6 of [RFC3261], with an appropriate
   phone-context, before executing the rules.

5.2. Registering for other domains

   The mechanism defined herein only applies to AoRs of the Registered-
   to domain, as it did for [draft-gin].  In other words, if the bulk
   REGISTER had a To-URI of "sip:pbx123@ssp.example.com", then it is
   bulk Registering AoRs scoped to the domain "ssp.example.com".  This
   follows the same model as [RFC3261], where the Registered AoR is
   defined by the To-URI of the REGISTER.

   Other AoRs of other domains, such as "sip:bob@foo.example.net", MAY
   be routed to the Registered AoRs based on local policy provisioning,
   but in so doing are effectively re-targeted to the Registered AoR.
   Such SIP requests routed to the IP-PBX will have a Request-URI of
   the expanded registered contact, and be indistinguishable from
   requests which were originally for the registered AoR all along.
   (except through [RFC4244] History-Info processing)

   If the IP-PBX wishes to distinguish inbound requests among such AoRs
   of different domains, it MUST Register to each domain separately,
   using a unique Contact URI for the REGISTER request of each domain.
   The Contact URI can be made unique by inserting a URI parameter.
   This parameter will then be reflected in the Request-URI for inbound
   requests to the IP-PBX, based on the expansion rules defined herein
   and in [draft-gin].

   [Open issue: should we define a new parameter for this? Like ";user-
   context=foo.example.net"?]

6. SSP Processing of Inbound Non-E.164 Requests

   The SSP Proxy/Registrar (or equivalent entity) performs traditional
   Proxy/Registrar behavior, based on the mapping described in Section


Kaplan                 Expires - November 2009               [Page 7]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


   5 and [draft-gin].  For Local-Numbers in particular, the following
   section provides additional detail.

6.1. Processing of Local-Number Requests

   As discussed in section 5.1, Local-Numbers present a special case
   which may need to be handled with more explicit rules than [RFC3261]
   or [draft-gin] currently prescribe.  If the location-service
   database is described as having every possible expansion, then the
   Request would be processed in the same manner as section 5 and
   [draft-gin].

7. Interaction with Other Mechanisms

   The following sections describe the means by which this mechanism
   interacts with relevant REGISTER-related extensions currently
   defined by the IETF.

   Currently, the descriptions are somewhat informal, and omit some
   details for the sake of brevity.  If the MARTINI working group
   expresses interest in furthering the mechanism described by this
   document, they will be fleshed out with more detail and formality.

7.1. Globally Routable User-Agent URIs (GRUU)

   The GRUU mechanism for this document's mechanism works exactly the
   same way as defined in [draft-gin].  The [draft-gin] GRUU mechanism
   has no dependency on the global uniqueness of the AoR username, nor
   on being digits or an E.164.

7.2. Registration Event Package

   The Registration Event Packet behavior for this document's mechanism
   works exactly the same way as defined in [draft-gin].  The [draft-
   gin] reg-event model has no dependency on the global uniqueness of
   the AoR username, nor on being digits or an E.164.

   There is, however, an issue for Local-Numbers, if the SSP does not
   actually know the full list of Local-Number user names in the given
   phone-context scope.  In such a case, it is TBD for how to handle
   this.

   This remains an open issue for discussion, as discussed in section
   8.







Kaplan                 Expires - November 2009               [Page 8]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


7.3. Non-Adjacent Contact Registration (Path) and Service Route
    Discovery

   The Path and Service-Route behavior and considerations for this
   document's mechanism are exactly the same as defined in [draft-gin].
   The [draft-gin] Path and Service-Route model has no dependency on
   the global uniqueness of the AoR username, nor on being digits or an
   E.164.

8. Open Issues

   This document has several open issues, which were noted previously.
   They center around the handling of Local-Numbers.  Local-Numbers are
   difficult because they are doubly-scoped: once at the URI level by
   the domain name, and internally by the phone-context URI user
   parameter.  The authoritative system for the Local-Number user
   portion (the system(s) which knows what they are and how to process
   them) is not necessarily identified by the URI's domain name, but
   rather may be identified by the phone-context's value.

   If the phone-context identifies the SSP domain, all's well - but
   that's rarely the case.  More likely is that it identifies an E.164
   number, or a sub-domain of the SSP, or another domain entirely.
   This causes issues with certain functions such as the reg-event
   package, which has been identified as an open issue.

9. Examples

   These will be fleshed out more in later versions of the draft, with
   explanations of the processing performed at each step.  For the time
   being, they just show the basic syntax described above.




















Kaplan                 Expires - November 2009               [Page 9]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


9.1. Usage Scenario: Basic Registration case 1

   This example shows a basic bulk REGISTER transaction, followed by an
   INVITE addressed to one of the registered terminals.


   Internet                        SSP                              PBX
   |                                |                                 |
   |                                |REGISTER                         |
   |                                |Contact:<sip:198.51.100.3;bnc>   |
   |                                |<--------------------------------|
   |                                |                                 |
   |                                |200 OK                           |
   |                                |-------------------------------->|
   |                                |                                 |
   |INVITE                          |                                 |
   |sip:bob@ssp.example.com         |                                 |
   |------------------------------->|                                 |
   |                                |                                 |
   |                                |INVITE                           |
   |                                |sip:bob@198.51.100.3             |
   |                                |-------------------------------->|


   REGISTER sip:ssp.example.com SIP/2.0
   Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
   Max-Forwards: 70
   To: <sip:pbx123@ssp.example.com>
   From: <sip:pbx123@ssp.example.com>;tag=a23589
   Call-ID: 843817637684230998sdasdh09
   CSeq: 1826 REGISTER
   Proxy-Require: gin
   Require: gin
   Supported: path
   Contact: <sip:198.51.100.3:5060;bnc>
   Expires: 7200
   Content-Length: 0














Kaplan                 Expires - November 2009              [Page 10]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


   INVITE sip:bob@ssp.example.com SIP/2.0
   Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
   Max-Forwards: 69
   To: <sip:2145550105@some-other-place.example.net>
   From: <sip:alice@rabbithole.example.org>;tag=456248
   Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
   CSeq: 24762 INVITE
   Contact: <sip:line-1@192.0.2.178:2081>
   Content-Type: application/sdp
   Content-Length: ...

   <sdp body here>


   INVITE sip:bob@198.51.100.3 SIP/2.0
   Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
   Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
   Max-Forwards: 68
   To: <sip:2145550105@some-other-place.example.net>
   From: <sip:alice@rabbithole.example.org>;tag=456248
   Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
   CSeq: 24762 INVITE
   Contact: <sip:line-1@192.0.2.178:2081>
   Content-Type: application/sdp
   Content-Length: ...

   <sdp body here>
























Kaplan                 Expires - November 2009              [Page 11]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


9.2. Usage Scenario: Basic Registration case 2

   This example shows a basic bulk REGISTER transaction, followed by an
   INVITE addressed to one of the registered terminals, for a Local-
   Number AoR.


   Internet                        SSP                              PBX
   |                                |                                 |
   |                                |REGISTER                         |
   |                                |Contact:<sip:198.51.10.3;f=b;bnc>|
   |                                |<--------------------------------|
   |                                |                                 |
   |                                |200 OK                           |
   |                                |-------------------------------->|
   |                                |                                 |
   |INVITE                          |                                 |
   |sip:1234;ext=678                |                                 |
   | ;phone-context=+1212555        |                                 |
   | @ssp.example.com               |                                 |
   |------------------------------->|                                 |
   |                                |                                 |
   |                                |INVITE                           |
   |                                |sip:1234;ext=678                 |
   |                                | ;phone-context=+1212555         |
   |                                | @198.51.100.3;f=b               |
   |                                |-------------------------------->|


   REGISTER sip:ssp.example.com SIP/2.0
   Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
   Max-Forwards: 70
   To: <sip:pbx123@ssp.example.com>
   From: <sip:pbx123@ssp.example.com>;tag=a23589
   Call-ID: 843817637684230998sdasdh09
   CSeq: 1826 REGISTER
   Proxy-Require: gin
   Require: gin
   Supported: path
   Contact: <sip:198.51.10.3:5060;f=b;bnc>
   Expires: 7200
   Content-Length: 0









Kaplan                 Expires - November 2009              [Page 12]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


   INVITE sip:1234;ext=678;phone-context=+1212555
       @ssp.example.com SIP/2.0
   Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
   Max-Forwards: 69
   To: <sip:2145550105@some-other-place.example.net>
   From: <sip:alice@rabbithole.example.org>;tag=456248
   Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
   CSeq: 24762 INVITE
   Contact: <sip:line-1@192.0.2.178:2081>
   Content-Type: application/sdp
   Content-Length: ...

   <sdp body here>


   INVITE sip:1234;ext=678;phone-context=+1212555
       @198.51.100.3;f=b SIP/2.0
   Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
   Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
   Max-Forwards: 68
   To: <sip:2145550105@some-other-place.example.net>
   From: <sip:alice@rabbithole.example.org>;tag=456248
   Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
   CSeq: 24762 INVITE
   Contact: <sip:line-1@192.0.2.178:2081>
   Content-Type: application/sdp
   Content-Length: ...

   <sdp body here>


10.  IANA Considerations

   This document makes no request of IANA.


11.  Security Considerations

   This section is still TBD, but it should follow/have the same issues
   as [draft-gin].

12.  Acknowledgements

   Thanks to Adam Roach for providing text copied from [draft-gin].







Kaplan                 Expires - November 2009              [Page 13]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


13.  Informative References

   [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., Schulzrinne, H., "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263, June
              2002.

   [RFC3327]  Willis, D., and Hoeneisen, B., "Session Initiation
              Protocol (SIP) Extension Header Field for Registering
              Non-Adjacent Contacts", RFC 3327, December 2002.

   [RFC3455]  Garcia-Martin, M., Henrikson, E., and Mills, D., "Private
              Header (P-Header) Extensions to the Session Initiation
              Protocol (SIP) for the 3rd-Generation Partnership Project
              (3GPP)", RFC 3455, January 2003.

   [RFC3608]  Willis, D., and Hoeneisen, B., "Session Initiation
              Protocol (SIP) Extension Header Field for Service Route
              Discovery During Registration", RFC 3608, October 2003.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
              3966, December 2004.

   [RFC4244]  Barnes, M. (ed.), "An Extension to the Session Initiation
              Protocol (SIP) for Request History Information", RFC
              4244, November 2005.

   [RFC5486]  Malas, D., and Meyer, D., "Session Peering for Multimedia
              Interconnect (SPEERMINT) Terminology", RFC 5486, March
              2009.

   [draft-gin] Roach, A. B., "Registration for Multiple Phone Numbers
              in the Session Initiation Protocol (SIP)", draft-ietf-
              martini-gin-01, April 2010.

   [draft-4244bis] Barnes, M., et al, "An Extension to the Session
              Initiation Protocol (SIP) for Request History
              Information", draft-ietf-sipcore-rfc4244bis-00, February
              2010.








Kaplan                 Expires - November 2009              [Page 14]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


Author's Address

   Hadriel Kaplan
   Acme Packet
   71 Third Ave.
   Burlington, MA 01803, USA
   Email: hkaplan@acmepacket.com


Appendix A - Why non-E.164 AoRs may need processing by SSPs

   There is some debate about how a non-E.164 AoR could even be
   received by the SSP for processing to begin with.  This section
   describes how such could be the case.

   It should be noted that this document only deals with SIP AoRs of
   the same URI domain name as that of the REGISTER's To URI - namely
   the SSP's domain.

   A SIP Request targeted to a Local-Number could require processing by
   the SSP because:
      - The SSP provides IP-Centrex type services for some of the AoRs
        of an Enterprise, for example for small branches, while
        providing SIP-Trunk service to the main IP-PBX(s).  Requests
        from the IP-Centrex UAs will thus be targeted to Local-numbers
        as they are received by the SSP Proxy on their way to the IP-
        PBX.
      - The SSP provides inbound extension dialing, for example by
        offering private calling-card services, such that a E.164
        number call is terminated by an Application Server of the SSP
        which authenticates the caller belongs to an Enterprise and
        then allows private extension dialing, as a UAC, thereby
        originating a new SIP session Request using a Local-Number
        target.

   A SIP Request targeted to an Email-style AoR could require
   processing by an SSP because:
      - The SSP provides Email-style AoRs for business customers - for
        example "sip:bob@ssp.example.net".
      - The SSP has a sub-division or sub-entity which uses IP-PBX
        Martini trunks into the SSP main domain, for which the SSP
        provides AoRs of the main SSP domain - for example, a sales
        division IP-PBX in a sub-domain of sales.ssp.example.net, but
        for which the SSP provides an AoR of
        "sip:sales@ssp.example.net".
      - The Email-style AoR is scoped to the Enterprise's domain, but
        the Request originated from within the SSP - for example by one
        of its subscriber SIP UAs.  Since SIP UAs generally send their
        Requests through their SSP's proxies, the Request will be


Kaplan                 Expires - November 2009              [Page 15]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


        processed by them first.  This type of AoR (i.e., one scoped
        outside of the SSP's domain) is NOT in scope for this document.

   There are other possibilities as well, of course, but this section
   is only intended to provide some basic rational for why it is
   possible for a local-number or email-style AoR to be used and appear
   in the SSP.


Appendix B - Issues with non-E.164 Identifiers

   At the initial outset of Martini's work, the problem space to work
   on was narrowed to E.164 numbers only, for several reasons.  This
   section attempts to identify the reasons in detail, and address
   them.

o Globally unique AoR

   One of the initial benefits cited for only supporting E.164 is that
   an E.164 user name is globally unique by itself, and thus changing
   the host portion of the Request-URI does not impact the identity of
   the intended target of the Request.

   Fortunately, [draft-gin] does not in fact rely on that property of
   the AoR username.  What [draft-gin] does is emulate what would have
   happened had the IP-PBX Registered each E.164-based AoR separately.
   It is not in fact Registering an "E.164 number" - it is Registering
   typical [RFC3261] AoRs, which just happen to be formatted as E.164
   numbers.  For example, the IP-PBX is not implicitly Registering the
   identity of "+12125551212", it is instead implicitly Registering for
   the SIP AoR of "sip:+12125551212@ssp.example.net".  The SSP may well
   associate and route requests for "tel:+12125551212" to that AoR's
   Registered contact, but in so doing it can be described as logically
   performing a transformation of the TEL URI to a SIP URI and looking
   up that SIP URI in its location service database.

   Interestingly, the AoR that was implicitly Registered is globally
   unique, *regardless* of the fact that the user portion happens to be
   an E.164 number.  It is globally unique, because the AoR is of the
   domain "ssp.example.net" - just as any [RFC3261] SIP AoR is globally
   unique due to its host domain portion.

o Registered Contact Username

   The other rational for needing a globally unique identifier is the
   Registered Contact URI.  Because the Martini model performs a bulk
   Registration and uses a defined expansion rule for how to expand the
   Registered Contact into a unique Contact URI per AoR, the rule's
   output needs to be unambiguous and generate a unique Contact per


Kaplan                 Expires - November 2009              [Page 16]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


   AoR.  For example, if the IP-PBX has multiple SSPs it Registers
   into, it can't just receive a request to "sip:bob@192.1.2.3",
   because it won't know if that's to "sip:bob@ssp1.example.net" or
   "sip:bob@ssp2.example.net", which may be different users.

   This is a real problem, but what it requires/needs is a globally
   unique Contact URI, not a globally unique AoR user name.  In fact,
   [draft-gin] suffers from this problem as well, in some ways.
   Although it is unambiguous what the target of the request may be
   (because the username is globally unique), it still may be important
   for the IP-PBX to know which implicitly Registered AoR the request
   was resolved from, before being sent to it.  For example, the IP-PBX
   may want to know the request is for
   "sip:+12125551212@ssp.example.net.uk" vs.
   "sip:+12125551212@ssp.example.net.fr".  The IP-PBX *would* have
   Registered separately for each domain, but if its contact is the
   same (and if it went through the same path, etc.), there would be no
   unique identifier for inbound Requests.

   This problem could be solved numerous ways.  For one, this is a
   similar issue to that solved by [RFC4244] or being worked on in
   [draft-4244bis].  Secondly, and more importantly, the IP-PBX could
   simply make the Contact unique by inserting a parameter in the
   Contact URI it Registers, or inserting a Path header field with
   unique information per Register target domain.

   Regardless of the solution, it is solvable without impacting the
   user portion of the AoR being implicitly Registered.  Therefore,
   there is no need to make the username portion globally unique, and
   thus once again there is no need for [draft-gin] to only be used for
   E.164 AoRs.

o Avoiding syntax mismatches

   Another issue with the Contact bulk-expansion rule and implicitly
   Registering Contact URIs is guaranteeing the Registrar uses a
   username the IP-PBX will accept/expect.  In particular, there are
   numerous syntactic forms a phone number can take in the user portion
   of a SIP URI, for example with or without a leading "+", or with
   visual-separators or not.  Since the IP-PBX is not actually
   Registering an explicit Contact URI user portion for each AoR, there
   needs to be an assurance that the format of the expanded-to user
   portion matches what it expects.

   For Email-style URIs, this is actually quite straight-forward,
   because there is only one form the user name can take: if the AoR is
   "sip:bob@ssp.example.net", then a simple AoR-user-based expansion
   rule would suffice because "bob" can only have one form. (e.g., even



Kaplan                 Expires - November 2009              [Page 17]


Internet-Draft          SIP MARTINI with OLIVE                May 2010


   case-sensitivity matters)  Thus there is no syntax mismatch concern
   for generic string names.

   Local-Numbers in TEL URIs, or SIP URIs formed from TEL URIs, are
   more difficult, however.  Like E.164 (i.e., global-number) formats,
   they are not as well constrained.  They may have visual-separators,
   for example, and if their phone-context parameter value is a global-
   number, it too has the same formatting "looseness" of E.164 number
   user names.

   To make matters worse, the SSP does not always have full knowledge
   of all Local-Numbers it can route requests for, nor of their URI
   user-portion parameters.





































Kaplan                 Expires - November 2009              [Page 18]