MARTINI WG H. Kaplan
Internet Draft Acme Packet
Intended status: Standards-Track
Expires: April 25, 2011 October 25, 2010
SIP GIN MARTINI with
Open-plan Local-number Identifier Values for Enterprises (OLIVE)
draft-kaplan-martini-with-olive-02
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 April 25, 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 April 18, 2010 [Page 1]
Internet-Draft SIP MARTINI with OLIVE October 2010
Abstract
The Martini Working Group has defined a mechanism for SIP IP-PBX
type devices to REGISTER and obtain SIP service for E.164-based
Address of Records, using the GIN mechanism [draft-gin]. This
document defines a means for open-plan Local-Numbers to be used with
Martini-based IP-PBXs.
Table of Contents
1. Introduction..................................................2
2. Definitions...................................................3
3. Background....................................................3
3.1. The GIN Mechanism........................................3
3.2. Local-Numbers............................................4
4. The Solution - an Overview....................................4
5. Registering for Local-Number AoRs.............................5
6. SSP Processing of Inbound Non-E.164 Requests..................7
7. Interaction with Other Mechanisms.............................7
7.1. Globally Routable User-Agent URIs (GRUU).................7
7.2. Registration Event Package...............................7
7.3. Non-Adjacent Contact Registration (Path) and Service Route
Discovery......................................................8
8. Open Issues...................................................8
9. Examples......................................................8
9.1. Usage Scenario: Basic Registration case..................9
10. IANA Considerations.........................................10
11. Security Considerations.....................................10
12. Acknowledgements............................................10
13. Informative References......................................11
Author's Address.................................................12
Appendix A - Why Local-Numbers may need processing by SSPs.......12
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, with the GIN mechanism [draft-gin].
The current GIN 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.
These forms of AoRs are not supported by the current GIN mechanism.
This document defines a means by which they can be supported, in a
manner consistent with [RFC3261] and [draft-gin].
Kaplan Expires - April 2011 [Page 2]
Internet-Draft SIP MARTINI with OLIVE October 2010
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.).
Open-plan: an open-plan is a dialing-plan which is not constrained
to be a specific set of numbers all known to the SSP; some specific
numbers may be known by the SSP, and/or a beginning set of digits
are known to the SSP and used to route calls to different branches
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.
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
3.1. The GIN Mechanism
The GIN 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 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
Kaplan Expires - April 2011 [Page 3]
Internet-Draft SIP MARTINI with OLIVE October 2010
registered Contact URI, and adding any Path information as a Route
set, etc.
3.2. Local-Numbers
The Local-Number syntax for TEL URIs is defined in [RFC3966], such
that a local-number is a set of digits, possibly with an extension
or isdn-subaddress parameter, and scoped to the domain name or
global-number-digits in its phone-context. In theory, a SIP UA can
target its request to a Local-Number using the [RFC3966] syntax in a
TEL URI or SIP URI, and have the request delivered to the UA or IP-
PBX identified by the user digits for the given phone-context, which
may subsequently route the request to the specific extension or
isdn-subaddress.
In practice it's not that simple. Most branch-office IP-PBXs do not
use the Local-Number syntax for their targets, and do not recognize
such syntax if they receive it in the Request URI. Often the SSP
adds the phone-context to received requests from the IP-PBX, and
removes it when sending to the IP-PBX. The reasons for this
include: (a) the IP-PBX is wholly within the context and thus has no
knowledge of, nor concern that there cold be, other contexts; (b)
the IP-PBX may not actually know all the numbers in the private
number plan, only its local ones; and (c) historically it has not
been necessary for them to add such explicit indicators for things
to work, and thus the status-quo is difficult to change.
Furthermore, 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. In other words, the SSP may not know about all
possible Local-Number numbers, and even a given IP-PBX may not know
them all for its Enterprise; the knowledge may be distributed. This
presents difficulties for certain GIN functions such as reg-event,
and is why this document refers to GIN support for Local-Numbers as
being for "open-plan" scenarios.
4. The Solution - an Overview
The general concept proposed in this document is to logically apply
GIN for the complete set of Local-Number "AoRs" of the Registered-to
domain, as if they were individually Registered. The GIN-based
REGISTER request would cause the Registrar to logically populate the
set of AoR-to-Contact bindings, as it did before.
Kaplan Expires - April 2011 [Page 4]
Internet-Draft SIP MARTINI with OLIVE October 2010
The Contact URI user portion would also be "expanded", using the
same user portion as that of the implicitly registered AoRs: namely
a Local-Number format. The Local-Number username is "normalized" in
the same manner as [draft-gin].
Note that the list of Local-Number 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 GIN [draft-gin] registration nor in
subsequent [RFC3261] routing behavior in the IP-PBX, nor in 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 Local-Number AoRs
This document's mechanism relies on the GIN [draft-gin] Registration
mechanism. The IP-PBX Registers into the SSP, using a REGISTER
request with the "gin" option-tag in the Require and Proxy-Require
header fields, and a Contact URI containing the "bnc" URI parameter
and no user portion. After the PBX is authenticated, the registrar
updates its location service so that each of the Local-Number AoRs
associated with the PBX creates a unique AOR to Contact mapping.
In practice, however, 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.)
Kaplan Expires - April 2011 [Page 5]
Internet-Draft SIP MARTINI with OLIVE October 2010
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
<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,
Kaplan Expires - April 2011 [Page 6]
Internet-Draft SIP MARTINI with OLIVE October 2010
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.
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.
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.
6. SSP Processing of Inbound Non-E.164 Requests
The SSP Proxy/Registrar (or equivalent entity) performs traditional
Proxy/Registrar behavior, based on the logical mapping described in
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 GIN GRUU mechanism has no
dependency on the AoR being 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 AoR being an E.164.
Kaplan Expires - April 2011 [Page 7]
Internet-Draft SIP MARTINI with OLIVE October 2010
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.
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 AoR being 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 - April 2011 [Page 8]
Internet-Draft SIP MARTINI with OLIVE October 2010
9.1. Usage Scenario: Basic Registration case
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 - April 2011 [Page 9]
Internet-Draft SIP MARTINI with OLIVE October 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 - April 2011 [Page 10]
Internet-Draft SIP MARTINI with OLIVE October 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 - April 2011 [Page 11]
Internet-Draft SIP MARTINI with OLIVE October 2010
Author's Address
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803, USA
Email: hkaplan@acmepacket.com
Appendix A - Why Local-Numbers 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.
- The SSP provides inter-branch private dialing, by routing on
some number of leading digits of a Local-Number.
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 AoR to be used and appear in the SSP.
Kaplan Expires - April 2011 [Page 12]