One document matched: draft-roach-martini-gin-00.txt
MARTINI WG A. B. Roach
Internet-Draft Tekelec
Intended status: Standards Track February 2, 2010
Expires: August 6, 2010
Registration for Multiple Phone Numbers in the Session Initiation
Protocol (SIP)
draft-roach-martini-gin-00
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 6, 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.
Abstract
This document defines a mechanism by which a SIP server acting as a
Roach Expires August 6, 2010 [Page 1]
Internet-Draft Globally Identifiable Number Routing February 2010
traditional Private Branch Exchange (PBX) can register with a SIP
Service Provider (SSP) to receive phone calls for extensions
designated by phone numbers. In order to function properly, this
mechanism relies on the fact that the phone numbers are fully
qualified and globally unique.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. Registering for Multiple Phone Numbers . . . . . . . . . . . . 5
6. SSP Processing of Inbound Phone Number Requests . . . . . . . 6
7. Interaction with Other Mechanisms . . . . . . . . . . . . . . 6
7.1. Globally Routable User-Agent URIs (GRUU) . . . . . . . . . 6
7.1.1. Public GRUUs . . . . . . . . . . . . . . . . . . . . . 6
7.1.2. Temporary GRUUs . . . . . . . . . . . . . . . . . . . 8
7.2. Registration Event Package . . . . . . . . . . . . . . . . 8
7.2.1. PBX Aggregate Registration State . . . . . . . . . . . 9
7.2.2. Individual Extension Registration State . . . . . . . 9
7.3. Client-Initiated (Outbound) Connections . . . . . . . . . 9
7.4. Non-Adjacent Contact Registration (Path) . . . . . . . . . 9
7.5. Service Route Discovery . . . . . . . . . . . . . . . . . 9
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Issues Solved . . . . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. New SIP Option Tag . . . . . . . . . . . . . . . . . . . . 12
10.2. New SIP URI Parameter . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Roach Expires August 6, 2010 [Page 2]
Internet-Draft Globally Identifiable Number Routing February 2010
1. Introduction
One of SIP's primary functions is providing rendezvous between users.
By design, this rendezvous has been provided through a combination of
the server look-up procedures defined in RFC 3263 [2], and the
registrar procedures described in RFC 3261 [1].
The intention of the original protocol design was that any user's AOR
would be handled by the authority indicated by the hostport portion
of the AOR. The users registered individual reachability information
with the this authority, which would then route incoming requests
accordingly.
In actual deployments, some SIP servers have been deployed in
architectures that, for various reasons, have requirements to provide
dynamic routing information for large blocks of AORs, where all of
the AORs in the block were to be handled by the same server. For
purposes of efficiency, many of these deployments do not wish to
maintain separate registrations for each of the AORs in the block.
This leads to the desire for an alternate mechanism for providing
dynamic routing information for blocks of AORs.
Because this problem has certain similarities with the REGISTER
operation, several non-standard, ad hoc extensions to REGISTER have
been developed to address this desire. The document "SIP IP-PBX
Registration Problems" [3] describes several deployed IP PBX
registration techniques, along with a number of problems that arise
from the approaches that have been implemented to date.
Although the use of REGISTER to update reachability information for
multiple users simultaneously is somewhat beyond the original
semantics defined for REGISTER, this approach has seen significant
deployment in certain environments. In particular, deployments in
which small to medium SIP PBX servers are addressed using E.164
numbers have used this mechanism to avoid the need to maintain DNS
entries or static IP addresses for the PBX servers.
In recognition of the momentum that a REGISTER-based approach has
within that relatively narrow ecological niche, this document defines
a REGISTER-based approach that is tailored to E.164-addressed
extensions in a SIP PBX environment. It is not intended for general-
purpose registration of SIP URIs in which the user portion is non-
numeric or non-globally-unique.
2. Constraints
The following paragraph is perhaps the most important in
Roach Expires August 6, 2010 [Page 3]
Internet-Draft Globally Identifiable Number Routing February 2010
understanding the solution defined in this document.
Within the problem space that has been established for this work,
several constraints shape our solution. These are being defined in
the MARTINI requirements document. In terms of impact to the
solution at hand, the following two constraints have the most
profound effect: (1) The PBX cannot be assumed to be assigned a
static IP address; and (2) No DNS entry can be relied upon to
consistently resolve to the IP address of the PBX.
3. Terminology
This document uses the terms defined in section 2 of "SIP IP-PBX
Registration Problems" [3].
4. Mechanism Overview
The overall mechanism is achieved using a REGISTER request with a
specially-formatted Contact URI. This document also defines an
option tag that can be used to ensure a registrar understands the
mechanism described herein.
The Contact URI itself is tagged with a URI parameter to indicate
that it actually represents a multitude of phone-number-associated
contacts, as well as a syntactically valid (but rare) set of
characters to indicate where the phone number is to be placed for
incoming calls.
We also define some lightweight extensions for GRUU to allow the use
of public GRUUs assigned by the SSP.
Finally, we non-normatively demonstrate that existing procedures that
can be used to generate temporary GRUUs for terminals behind the PBX.
Aside from these extensions, the REGISTER message itself is processed
by a registrar in the same way as normal registrations: by updating
its location service with additional AOR to Contact bindings.
Note that the list of extensions associated with a PBX is a matter of
local provisioning at the SSP and at the PBX. 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 extensions; see
Section 7.2.1).
Roach Expires August 6, 2010 [Page 4]
Internet-Draft Globally Identifiable Number Routing February 2010
5. Registering for Multiple Phone Numbers
To register for multiple phone numbers, the PBX sends a REGISTER
message to the SSP. This REGISTER varies from a typical register in
two important ways. First, it must contain an option tag of "bulk-
number-contact" in a "Require" header field. Second, in at least one
"Contact" header field, it must include a Contact URI that contains
the URI parameter "bnc" and the special sequence of characters "()"
exactly once in the user portion of the URI.
The character sequence "()" is selected for the following
properties: it is syntactically valid in the user portion of a SIP
URI; it has a vanishingly small chance of appearing in URIs
currently in use; and it provides an easy-to-identify and somewhat
intuitive visual marker for the destination of the phone number.
Because of the constraints discussed in Section 2, the host portion
of the Contact URI will generally contain an IP address, although
nothing in this mechanism enforces or relies upon that fact. If the
PBX operator chooses to maintain DNS entries that resolve to the IP
address of his PBX via RFC 3263 resolution procedures, then this
mechanism works just fine with domain names in the Contact header
field.
[OPEN ISSUE: do we need a Proxy-Require also? It seems we probably
do: we're adding special meaning to the syntax of Contact, and
altering the semantics of REGISTER to indicate more than one user.]
The URI parameter indicates that special interpretation of the
Contact URI is necessary: instead of representing a single, concrete
Contact URI to be inserted into the location service, it represents a
multitude of Contact URIs (one for each associated phone numbers),
semantically resulting in a multitude of AOR-to-Contact rows in the
location service.
The registrar, upon receipt of a REGISTER message in the foregoing
form, will use the value in the "To" header field to identify the PBX
for which registration is being requested. It then authenticates the
PBX (using, e.g., SIP Digest authentication, mutual TLS, or some
other authentication mechanism). After the PBX is authenticated, the
registrar updates its location service so that each of the phone
numbers 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
Roach Expires August 6, 2010 [Page 5]
Internet-Draft Globally Identifiable Number Routing February 2010
SSP expects to receive from external parties (e.g.
"sip:+12145550102@ssp.example.com"), and the corresponding Contact
will be formed by replacing the "()" sequence from the REGISTER's
Contact URI field with the fully-qualified, E.164-formatted phone
number (including the preceding "+" symbol) and removing the "bnc"
parameter. For example, if the "Contact" header field contains the
URI <sip:()@198.51.100.3:5060;bnc>, then the Contact value associated
with the aforementioned AOR will be
"sip:+12145550102@198.51.100.3:5060".
Aside from the "bnc" parameter, all URI parameters present on the
"Contact" URI in the REGISTER message MUST be copied to the Contact
value stored in the location service.
6. SSP Processing of Inbound Phone Number Requests
In general, after processing the AOR to Contact mapping described in
the preceding section, the SSP Proxy/Registrar (or equivalent entity)
performs traditional Proxy/Registrar behavior, based in such mapping.
For inbound SIP requests whose AOR indicates an E.164 number assigned
to one of the SSP's customers, this will generally involve setting
the target set to the registered contacts associated with that AOR,
and performing request forwarding as described in section 16.6 of RFC
3261.
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)
To enable advanced services to work with extensions behind a SIP PBX,
it is important that the GRUU mechanism defined by RFC 5627 [8] work
correctly with the mechanism defined herein.
7.1.1. Public GRUUs
For this mechanism to work correctly with pubic GRUUs, we require a
minor extension to the public GRUU behavior between the SSP and the
Roach Expires August 6, 2010 [Page 6]
Internet-Draft Globally Identifiable Number Routing February 2010
PBX.
When a PBX registers a Bulk Number Contact (a Contact with a "bnc"
parameter), and also invokes GRUU procedures for that Contact during
registration, then the SSP will assign a special public GRUU to the
PBX. It differs from normal public GRUUs in three ways: (1) The user
portion will contain the character sequence "()"; (2) the GRUU will
contain a "bnc" parameter to indicate the special treatment defied by
this document, and (3) the "gr" parameter will contain a single "*"
character.
As with the Bulk Number Contact URIs, the "()" character sequence in
the GRUU represents the fully-qualified E.164-formatted phone number
associated with the GRUU.
In a similar fashion, the single "*" character that appears in the
"gr" parameter indicates a location that the PBX may use to add its
own GRUU disambiguation material, so that the PBX may uniquely
identify the proper user agent.
So, for example, when the PBX registers the with the following
contact header field:
Contact: <sip:()@198.51.100.3;bnc>;
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Then the SSP may choose to respond with a Contact header field that
looks like this:
<allOneLine>
Contact: <sip:()@198.51.100.3;bnc>;
pub-gruu="sip:()@ssp.example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6*;bnc";
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=7200
</allOneLine>
Where the "*" indicates that the SSP will ignore any characters after
the final "6". When its own terminals register, the PBX can then add
whatever device identifier it feels appropriate, in place of the "*",
and present this value to its own terminals. For example, assume the
extension associated with the phone number "+12145550102" sent the
following Contact header field in its register:
Contact: <sip:line-1@10.20.1.17>;
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
The PBX will replace the "*" in the pub-gruu it received from the SSP
Roach Expires August 6, 2010 [Page 7]
Internet-Draft Globally Identifiable Number Routing February 2010
with a token that uniquely identifies the device (possibly the URN
itself; possible some other identifier); replace the "()" with the
fully-qualified E.164 number associated with the extension; and
return the result to the terminal as its public GRUU. This resulting
Contact header field would look something like this:
<allOneLine>
Contact: <sip:line-1@10.20.1.17>;
pub-gruu="sip:+12145550102@ssp.example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6~00:05:03:5e:70:a6";
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
;expires=3600
</allOneLine>
7.1.2. Temporary GRUUs
If a PBX wishes to provide temporary GRUUs for its terminals, it may
do so by producing its own "Self-made GRUUs" (as defined in section
4.3 of RFC 5627). These GRUUs are produced using the PBX's own IP
address (or domain, if it maintains one in DNS). The temporary GRUUs
are then propagated to terminals using normal GRUU mechanism.
The ability to produce temporary GRUUs in this fashion is predicated
on the conditions described in section 4.3 of RFC 5627. In
particular, it requires PBX to be publicly routable, and willing to
accept requests destined for its own Self-made GRUUs from sources
other than the SSP. If these conditions cannot be satisfied (or the
PBX operator chooses not to satisfy them for policy reasons), then
the PBX users will not be able to make use of temporary GRUUs.
This mechanism is also predicated on the IP address for the PBX being
relatively stable over long period of time. This is generally a safe
assumption to make, as frequent PBX IP address changes will result in
intermittent connectivity issues and interruptions to ongoing calls.
On a related note: when used with this extension, the SSP will not
return a temporary GRUU in the registration response for any contacts
that include a "bnc" parameter in their URI.
7.2. Registration Event Package
As this mechanism inherently deals with REGISTER behavior, it is
imperative to consider its impact on the Registration Event Package
defined by RFC 3680 [6]. In practice, there will be two main use
cases for subscribing to registration data: learning about the
overall registration state for the PBX, and learning about the
registration state for a single PBX extension.
Roach Expires August 6, 2010 [Page 8]
Internet-Draft Globally Identifiable Number Routing February 2010
7.2.1. PBX Aggregate Registration State
If the PBX (or another interested and authorized party) wishes to
monitor or audit the registration state for all of the extensions
currently registered to that PBX, it can subscribe to the SIP
registration event package at the PBX's main URI -- that is, the URI
used in the "To" header field of the REGISTER message.
The NOTIFY messages for such a subscription will contain a body that
contains one record for each phone number associated with the PBX.
The AORs will be in the format expected to be received by the SSP
(e.g., "sip:+12145550105@ssp.example.com"), and the Contacts will
correspond to the mapped Contact created by the registration (e.g.,
"sip:+12145550105@98.51.100.3").
In particular both the "()" syntax and the "bnc" parameter are
forbidden to appear in the body of a reg-event notify.
7.2.2. Individual Extension Registration State
If the SSP receives a SUBSCRIBE request for the registration event
package with a Request-URI that indicates a contact registered via
the "Bulk Number Contact" mechanism defined in this document, then it
MUST proxy that SUBSCRIBE to the PBX in the same way that is would
proxy an INVITE bound for that AOR.
Defining the behavior in this way is important, since the reg-event
subscriber is interested in finding out about the comprehensive list
of devices associated with the phone number. Only the PBX will have
authoritative access to this information. For example, if the user
has registered multiple terminals with differing capabilities, the
SSP will not know about the devices or their capabilities. By
contrast, the PBX will.
7.3. Client-Initiated (Outbound) Connections
RFC 5626 [7] -- needs analysis. Some people think it might "just
work."
7.4. Non-Adjacent Contact Registration (Path)
RFC 3327 [4] -- needs analysis. Some people think it might "just
work."
7.5. Service Route Discovery
RFC 3608 [5] -- needs analysis. Some people think it might "just
work."
Roach Expires August 6, 2010 [Page 9]
Internet-Draft Globally Identifiable Number Routing February 2010
8. 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.
Internet SSP PBX
| | |
| |REGISTER |
| |Contact:<sip:()@198.51.100.3;bnc>|
| |<--------------------------------|
| | |
| |200 OK |
| |-------------------------------->|
| | |
|INVITE | |
|sip:+12145550105@ssp.example.com| |
|------------------------------->| |
| | |
| |INVITE |
| |sip:+12145550105@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:pbx@ssp.example.com>
From: <sip:pbx@ssp.example.com>;tag=a23589
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Require: bulk-number-contact
Contact: <sip:()@198.51.100.3:5060;bnc>
Expires: 7200
Content-Length: 0
INVITE sip:+12145550105@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:gsmith@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: ...
Roach Expires August 6, 2010 [Page 10]
Internet-Draft Globally Identifiable Number Routing February 2010
<sdp body here>
INVITE sip:+12145550105@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:gsmith@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>
9. Issues Solved
The document "SIP IP-PBX Registration Problems" [3] describes a
number of problems that arise in the ad hoc solutions currently
deployed. This section evaluates these issues against the mechanism
proposed in this document.
No Explicit Indicator: This mechanism includes both an explicit
indicator that the mechanism must be applied (a new "bulk-number-
contact" option tag) as well as a specific protocol marker that
indicates exactly where the extension is to be applied (the "bnc"
URI parameter).
Undefined Behavior on PAU Mismatch: This mechanism does not propose
the use of P-Associated-URI in the REGISTER response as an
integral part of the document. PBXes that wish to learn
registration information for its associated extensions may
subscribe to their own registration state, as described in
Section 7.2.1.
REGISTER Response Growth: This mechanism does not propose the use of
P-Associated-URI in the REGISTER response as an integral part of
the document. PBXes that wish to learn registration information
for its associated extensions may subscribe to their own
registration state, as described in Section 7.2.1.
Roach Expires August 6, 2010 [Page 11]
Internet-Draft Globally Identifiable Number Routing February 2010
Illegal Wildcarding Syntax: Rather than defining a general-purpose
wild-carding syntax, this mechanism defines a very lightweight
syntax for indication of where E.164 numbers are to be substituted
in Contact URIs.
Loss of Target Info: Because the binding from AOR to Contact URI is
under control of the requestor, and because the model of proxy/
registrar routing defined in RFC 3261 is maintained, the system
exhibits the same properties as it would if each user were
registered individually. Target information is preserved.
Request-URI vs. Loose-Route Mismatches: As before: because the
binding from AOR to Contact URI is under control of the requestor,
and because the model of proxy/registrar routing defined in RFC
3261 is maintained, the system exhibits the same properties as it
would if each user were registered individually. Loose routing
and Request-URI handling are kept consistent with proxy/registrar
handling described in RFC 3261, so no mismatches can arise.
Authorization Policy Mismatches: Because the binding from AOR to
Contact URI is under control of the publisher, it can ensure that
the Contact URI associated with an AOR matches the Contact URIs it
uses for outgoing calls. This eliminates the authorization policy
mismatches described.
P-Asserted-Identity Mismatches: Because the information published by
this mechanism inherently mimics individual registration for each
of the associated AORs, the expectation that each of these AORs
can be used as a P-Asserted-Identity is preserved, avoiding any
implementation confusion regarding valid values for this field.
Trust Domain Mismatches for Privacy/Identity: The MARTINI working
group appears to be reaching rough consensus that this issue is
out of scope and out of charter for solutions it is responsible
for considering. It is not analyzed with respect to the proposed
solution.
10. IANA Considerations
This isn't even close to finished. It's here to remind me that there
are IANA impacts.
10.1. New SIP Option Tag
bulk-number-contact
Roach Expires August 6, 2010 [Page 12]
Internet-Draft Globally Identifiable Number Routing February 2010
10.2. New SIP URI Parameter
bnc
11. References
11.1. Normative References
[1] 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.
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
11.2. Informative References
[3] Kaplan, H., "SIP IP-PBX Registration Problems",
draft-kaplan-martini-mixing-problems-00 (work in progress),
December 2009.
[4] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
[5] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Service Route Discovery During
Registration", RFC 3608, October 2003.
[6] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[7] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated
Connections in the Session Initiation Protocol (SIP)", RFC 5626,
October 2009.
[8] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
URIs (GRUUs) in the Session Initiation Protocol (SIP)",
RFC 5627, October 2009.
Roach Expires August 6, 2010 [Page 13]
Internet-Draft Globally Identifiable Number Routing February 2010
Author's Address
Adam Roach
Tekelec
17210 Campbell Rd.
Suite 250
Dallas, TX 75252
US
Email: adam@nostrum.com
Roach Expires August 6, 2010 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 01:10:33 |