MARTINI WG A. B. Roach
Internet-Draft Tekelec
Intended status: Standards Track March 30, 2010
Expires: October 1, 2010
Registration for Multiple Phone Numbers in the Session Initiation
Protocol (SIP)
draft-ietf-martini-gin-00
Abstract
This document defines a mechanism by which a SIP server acting as a
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.
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 October 1, 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
Roach Expires October 1, 2010 [Page 1]
Internet-Draft Globally Identifiable Number Routing March 2010
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. Registering for Multiple Phone Numbers . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 9
7.2.1. PBX Aggregate Registration State . . . . . . . . . . . 9
7.2.2. Individual Extension Registration State . . . . . . . 10
7.3. Client-Initiated (Outbound) Connections . . . . . . . . . 10
7.4. Non-Adjacent Contact Registration (Path) and Service
Route Discovery . . . . . . . . . . . . . . . . . . . . . 10
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Usage Scenario: Basic Registration . . . . . . . . . . . . 11
8.2. Usage Scenario: Using Path to Control Request URI . . . . 13
9. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.1. New SIP Option Tag . . . . . . . . . . . . . . . . . . . . 19
10.2. New SIP URI Parameters . . . . . . . . . . . . . . . . . . 19
10.2.1. 'bnc' SIP URI paramter . . . . . . . . . . . . . . . . 19
10.2.2. 'sg' SIP URI paramter . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Roach Expires October 1, 2010 [Page 2]
Internet-Draft Globally Identifiable Number Routing March 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 [3], and the
registrar procedures described in RFC 3261 [2].
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 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.
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
understanding the solution defined in this document.
Within the problem space that has been established for this work,
Roach Expires October 1, 2010 [Page 3]
Internet-Draft Globally Identifiable Number Routing March 2010
several constraints shape our solution. These are being defined in
the MARTINI requirements document [5]. 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
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 RFC 2119 [1].
Further, the term "SSP" is meant as an acronym for a "SIP Service
Provider," while the term "PBX" is used to indicate a SIP Private
Branch Exchange.
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 and any
intermediaries understand 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.
We also define some lightweight extensions for GRUU to allow the use
of public and temporary GRUUs assigned by the SSP.
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).
5. Registering for Multiple Phone Numbers
To register for multiple phone numbers, the PBX sends a REGISTER
Roach Expires October 1, 2010 [Page 4]
Internet-Draft Globally Identifiable Number Routing March 2010
message to the SSP. This REGISTER varies from a typical register in
two important ways. First, it must contain an option tag of
"bulknumbercontact" in both a "Require" header field and a "Proxy-
Require" header field. Second, in at least one "Contact" header
field, it must include a Contact URI that contains the URI parameter
"bnc", and no user portion (hence no "@" symbol). A URI with a "bnc"
parameter MUST NOT contain a user portion.
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.
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
SSP expects to receive from external parties (e.g.
"sip:+12145550102@ssp.example.com"), and the corresponding Contact
will be formed adding a user portion to the REGISTER's Contact URI
containing 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;user=phone;bnc>, then the Contact value
associated with the aforementioned AOR will be
<sip:+12145550102@198.51.100.3:5060;user=phone>.
Aside from the "bnc" parameter, all URI parameters present on the
"Contact" URI in the REGISTER message MUST be copied to the Contact
Roach Expires October 1, 2010 [Page 5]
Internet-Draft Globally Identifiable Number Routing March 2010
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 on the 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 [2].
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 [10] work
correctly with the mechanism defined by this document.
7.1.1. Public GRUUs
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 public GRUU to the PBX in
the normal fashion. Because the URI being registered contains a
"bnc" parameter, the GRUU will also contain a "bnc" parameter. In
particular, this means that the GRUU will not contain a user portion.
When a terminal registers with the PBX using GRUU procedures for a
Contact, it adds an "sg" parameter to the GRUU parameter it received
from the SSP. This "sg" parameter contains a disambiguation token
that the SSP can use to route the request to the proper user agent.
So, for example, when the PBX registers with the following contact
header field:
Roach Expires October 1, 2010 [Page 6]
Internet-Draft Globally Identifiable Number Routing March 2010
Contact: <sip:198.51.100.3;user=phone;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;user=phone;bnc>;
pub-gruu="sip:ssp.example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6";
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=7200
</allOneLine>
When its own terminals register, the PBX can then add whatever device
identifier it feels appropriate in an "sg" parameter, 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 add an "sg" parameter to the pub-gruu it received from
the SSP with a token that uniquely identifies the device (possibly
the URN itself; possibly some other identifier); insert a user
portion containing the fully-qualified E.164 number associated with
the extension; and return the result to the terminal as its public
GRUU. The 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;sg=00:05:03:5e:70:a6";
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
;expires=3600
</allOneLine>
When an incoming request arrives at the SSP for a GRUU corresponding
to a bulk number contact ("bnc"), the SSP performs slightly different
processing for the GRUU than a Proxy/Registrar would. When the GRUU
is re-targeted to the registered bulk number contact, the SSP MUST
copy the "sg" parameter from the GRUU to the new target. The PBX can
then use this "sg" parameter to determine which user agent the
request should be routed to.
Roach Expires October 1, 2010 [Page 7]
Internet-Draft Globally Identifiable Number Routing March 2010
7.1.2. Temporary GRUUs
PBXes have two options for creating temporary GRUUs for use by its
terminals.
7.1.2.1. Approach 1 - Self Made 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 [10]). 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 a 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.
For example, using the same setup as in the "Public GRUU" section
above, an extensions registering with the PBX might obtain a temp
gruu by receiving a Contact header field that looks like:
<allOneLine>
Contact: <sip:line-1@10.20.1.17>;
pub-gruu="sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-
00a0c91e6bf6;sg=a0471c99573b877b";
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
;expires=3600
</allOneLine>
7.1.2.2. Approach 2 - Anonymous Public GRUUs
If a PBX does not satisfy the criteria for producing its own "Self-
made GRUUs," then it may create temporary GRUUs based on the public
GRUUs it received from the SSP at registration time. To create
Roach Expires October 1, 2010 [Page 8]
Internet-Draft Globally Identifiable Number Routing March 2010
Temporary GRUUs of this form, the PBX will add an opaque "sg"
parameter to the public GRUU it received from the SSP, and will omit
the user portion.
Note that, because these GRUUs are temporary GRUUs, a unique "sg"
parameter will be generated for each successful registration attempt.
The PBX tracks the various "sg" values associated with each user
agent, and can re-target to the correct instance when the request
arrives.
For this approach to function, the SSP must be able to resolve a GRUU
based solely on the value of its "gr" parameter, as the user portion
of the GRUU will not contain an E.164 number. Further, the SSP will
not know which actual extension the request is destined for, only
that it corresponds to an extension belonging to the PBX.
Using the same basic setup as the example for the public GRUU, a
terminal might receive a temporary GRUU by getting back a Contact
header field that looks like this:
<allOneLine>
Contact: <sip:line-1@10.20.1.17>;
temp-gruu="sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-
00a0c91e6bf6;sg=0UYYRV046P";+sip.instance="<urn:uuid:d0e2f290-104b-
11df-8a39-0800200c9a66>";expires=3600
</allOneLine>
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 [8]. 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.
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
Roach Expires October 1, 2010 [Page 9]
Internet-Draft Globally Identifiable Number Routing March 2010
correspond to the mapped Contact created by the registration (e.g.,
"sip:+12145550105@98.51.100.3").
In particular, the "bnc" parameter is forbidden from appearing 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 [9] -- needs analysis. Some people think it might "just
work."
7.4. Non-Adjacent Contact Registration (Path) and Service Route
Discovery
RFC 3327 [6] defines a means by which a registrar and its associated
proxy can be informed of a route that is to be used between the proxy
and the registered user agent. The scope of the route created by a
"Path" header field is contact-specific; if an AOR has multiple
contacts associated with it, the routes associated with each contact
may be different from each other.
At registration time, any proxies between the user agent and the
registrar may add themselves to the Path. By doing so, they request
that any requests destined to the user agent as a result of the
associated registration include them as part of the Route towards the
User Agent. Although the Path mechanism does deliver the final Path
value to the registering UA, UAs typically ignore the value of the
Path.
To provide similar functionality in the opposite direction -- that
is, to establish a route for requests sent by a registering UA -- RFC
3608 [7] defines a means by which a UA can be informed of a route
Roach Expires October 1, 2010 [Page 10]
Internet-Draft Globally Identifiable Number Routing March 2010
that is to be used by the UA to route all outbound requests
associated with the AOR used in the registration. This information
is scoped to the AOR within the UA, and is not specific to the
Contact (or Contacts) in the REGISTER request.
The registrar unilaterally generates the values of the service route
using whatever local policy it wishes to apply. Although it is
common to use the Path and/or Route information in the request in
composing the Service-Route, registrar behavior is not constrained in
any way that requires it to do so.
In considering the interaction between these mechanisms and the
registration of multiple AORs in a single request, implementors of
proxies, registrars, and intermediaries must keep in mind the
following issues, which stem from the fact that GIN effectively
registers multiple AORs and multiple Contacts.
First, all location service records that result from expanding a
single "bnc" Contact will necessarily share a single path. Proxies
will be unable to make policy decisions on a contact-by-contact basis
regarding whether to include themselves in the path. Second, and
similarly, all AORs on the PBX that are registered with a common
REGISTER message will be forced to share a common Service-Route.
One interesting technique that Path and Service-Route enable is the
inclusion of a token or cookie in the user portion of the Service-
Route or Path entries. This token or cookie may convey information
to proxies about the identity, capabilities, and/or policies
associated with the user. Since this information will be shared
among several AORs and several Contacts when multiple AOR
registration is employed, care should be taken to ensure that doing
so is acceptable for all AORs and all Contacts registered in a single
REGISTER message.
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.
8.1. Usage Scenario: Basic Registration
This example shows a basic bulk REGISTER transaction, followed by an
INVITE addressed to one of the registered terminals.
Roach Expires October 1, 2010 [Page 11]
Internet-Draft Globally Identifiable Number Routing March 2010
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
Proxy-Require: bulknumbercontact
Require: bulknumbercontact
Contact: <sip:198.51.100.3:5060;user=phone;bnc>
Expires: 7200
Content-Length: 0
INVITE sip:+12145550105@ssp.example.com;user=phone 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: ...
<sdp body here>
Roach Expires October 1, 2010 [Page 12]
Internet-Draft Globally Identifiable Number Routing March 2010
INVITE sip:+12145550105@198.51.100.3;user=phone 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>
8.2. Usage Scenario: Using Path to Control Request URI
This example shows a bulk REGISTER transaction with the SSP making
use of the "Path" header field extension [6]. This allows the SSP to
designate a domain on the incoming Request URI that does not
necessarily resolve to the PBX from when the SSP applies RFC 3263
procedures to it.
Internet SSP PBX
| | |
| |REGISTER |
| |Path:<sip:pbx@198.51.100.3;lr> |
| |Contact:<sip:pbx.example;bnc> |
| |<--------------------------------|
| | |
| |200 OK |
| |-------------------------------->|
| | |
|INVITE | |
|sip:+12145550105@ssp.example.com| |
|------------------------------->| |
| | |
| |INVITE |
| |sip:+12145550105@pbx.example |
| |Route:<sip:pbx@198.51.100.3;lr> |
| |-------------------------------->|
Roach Expires October 1, 2010 [Page 13]
Internet-Draft Globally Identifiable Number Routing March 2010
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
Proxy-Require: bulknumbercontact
Require: bulknumbercontact
Path: <sip:pbx@198.51.100.3:5060;lr>
Contact: <sip:pbx.example;user=phone;bnc>
Expires: 7200
Content-Length: 0
INVITE sip:+12145550105@ssp.example.com;user=phone 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: ...
<sdp body here>
INVITE sip:+12145550105@pbx.example;user=phone SIP/2.0
Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
Route: <sip:pbx@198.51.100.3:5060;lr>
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>
Roach Expires October 1, 2010 [Page 14]
Internet-Draft Globally Identifiable Number Routing March 2010
9. Requirements Analysis
The document "Requirements for multiple address of record (AOR)
reachability information in the Session Initiation Protocol (SIP)"
[5] contains a list of requirements and desired properties for a
mechanism to register multiple AORs with a single SIP transaction.
This section evaluates those requirements against the mechanism
described in this document.
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.
The requirement is satisfied.
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.
The requirement is satisfied; the DIDs associated with a
registration is established by bilateral agreement between the SSP
and the PBX, and is not part of the mechanism described in this
document.
REQ3 - The mechanism MUST allow a SIP-PBX to register reachability
information with its SSP, in order to enable the SSP to route to the
SIP-PBX inbound requests targeted at assigned telephone numbers.
The requirement is satisfied.
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.
The requirement is satisfied; in the presumed architecture, PBX
terminals register with the PBX, an require no interaction with
the SSP.
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.
The requirement is satisfied; PBXes may recognize their own DID
and their own GRUUs, and perform on-PBX routing without sending
the requests to the SSP.
Roach Expires October 1, 2010 [Page 15]
Internet-Draft Globally Identifiable Number Routing March 2010
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.
The requirement is satisfied
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.
The requirement is satisfied. For ordinary calls and calls using
Public GRUUs, the DID is indicated in the user portion of the
Request-URI. For calls using Temp GRUUs constructed with the
mechanism described in Section 7.1.2.2, the "sg" parameter
provides a correlation token the PBX can use to identify which
terminal the call should be routed to.
REQ8 - The mechanism MUST provide a means of avoiding problems due to
one side using the mechanism and the other side not.
The requirement is satisfied through the 'bulknumbercontact'
option tag and the 'bnc' Contact parameter.
REQ9 - The mechanism MUST observe SIP backwards compatibility
principles.
The requirement is satisfied through the 'bulknumbercontact'
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.
The requirement is satisfied through the use of the Path mechanism
defined in RFC 3327 [6]
REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address
dynamically.
The requirement is satisfied by allowing the PBX to use an IP
address in the Bulk Number Contact URI contained in a REGISTER
Contact header field.
REQ12 - The mechanism MUST work without requiring the SIP-PBX to have
Roach Expires October 1, 2010 [Page 16]
Internet-Draft Globally Identifiable Number Routing March 2010
a domain name or the ability to publish its domain name in the DNS.
The requirement is satisfied by allowing the PBX to use an IP
address in the Bulk Number Contact URI contained in a REGISTER
Contact header field.
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.
The requirement is satisfied by allowing the domain name in the
Request URI used by external entities to resolve to the SSP's
servers via normal RFC 3263 resolution procedures.
REQ14 - The mechanism MUST be able to operate over a transport that
provides integrity protection and confidentiality.
The requirement is satisfied; nothing in the proposed mechanism
prevent the use of TLS between the SSP and the PBX.
REQ15 - The mechanism MUST support authentication of the SIP-PBX by
the SSP and vice versa.
The requirement is satisfied; PBXes may employ either SIP digest
authentication or mutually-authenticated TLS for authentication
purposes.
REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with
public or temporary Globally Routable UA URIs (GRUUs) [10].
The requirement is satisfied via the mechanisms detailed in
Section 7.1.
REQ17 - The mechanism MUST NOT preclude the ability of the SIP-PBX to
route on-PBX requests directly, without hair-pinning the signaling
through the SSP.
The requirement is satisfied; PBXes may recognize their own DID
and their own GRUUs, and perform on-PBX routing without sending
the requests to the SSP. (Note that this requirement duplicates
REQ5, and will probably be removed in a future version of the
requirements document.)
REQ18 - The mechanism MUST work over any existing transport specified
for SIP, including UDP.
Roach Expires October 1, 2010 [Page 17]
Internet-Draft Globally Identifiable Number Routing March 2010
The requirement is satisfied to the extent that UDP can be used
for REGISTER requests in general. The application of certain
extensions and/or network topologies may exceed UDP MTU sizes, but
such issues arise both with and without the mechanism described in
this document. This document does not exacerbate such issues.
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-PBXes.
The desired property is satisfied; the routing mechanism described
in this document is identical to the routing performed for singly-
registered AORs.
DES2 - The mechanism SHOULD scale to SIP-PBX's of several thousand
assigned telephone numbers.
The desired property is satisfied; nothing in this document
precludes DID pools of arbitrary size.
DES3 - The mechanism SHOULD scale to support several thousand SIP-
PBX's on a single SSP.
The desired property is satisfied; nothing in this document
precludes an arbitrary number of PBXes from attaching to 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.
The desired property is difficult to evaluate in the context of
any solution. The mechanism proposed in this document uses the
REGISTER method, which is the method preferred by many existing
PBX deployments. The handling of request routing logic is nearly
identical to that of RFC 3261 proxy/registrars, allowing
implementors to leverage existing proxy/registrar code.
10. IANA Considerations
This document registers a new SIP option tag to indicate support for
the mechanism it defines, plus two new SIP URI parameters.
Roach Expires October 1, 2010 [Page 18]
Internet-Draft Globally Identifiable Number Routing March 2010
10.1. New SIP Option Tag
This section defines a new SIP option tag per the guidelines in
Section 27.1 of RFC 3261[2].
Name: bulknumbercontact
Description: This option tag is used to identify the extension that
provides Registration for Multiple Phone Numbers in SIP. When
present in a Require or Proxy-Require header field of a REGISTER
request, it indicates that support for this extension is required
of registrars and proxies, respectively, that are a party to the
registration transaction.
Reference: RFCXXXX (this document)
10.2. New SIP URI Parameters
This specification defines two new SIP URI parameters, as per the
registry created by RFC 3969 [4].
10.2.1. 'bnc' SIP URI paramter
Parameter Name: bnc
Predefined Values: No (no values are allowed)
Reference: RFCXXXX (this document)
10.2.2. 'sg' SIP URI paramter
Parameter Name: sg
Predefined Values: No
Reference: RFCXXXX (this document)
11. Security Considerations
There are certainly security implications associated with the
mechanisms described in this document, mostly dealing with the
unprecedented semantic inclusion of multiple AORs in a single
REGISTER request. This section will be formulated following an
analysis of the security impact of GIN on Path, Service-Route, and
Outbound.
12. Acknowledgements
Thanks to John Elwell for his requirements analysis of the mechanism
described in this document, and to Dean Willis for his analysis of
the interaction between this mechanism and the Path and Service-Route
extensions.
Roach Expires October 1, 2010 [Page 19]
Internet-Draft Globally Identifiable Number Routing March 2010
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[4] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
December 2004.
13.2. Informative References
[5] Elwell, J. and H. Kaplan, "Requirements for multiple address of
record (AOR) reachability information in the Session Initiation
Protocol (SIP)", draft-ietf-martini-reqs-02 (work in progress),
March 2010.
[6] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
[7] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Service Route Discovery During
Registration", RFC 3608, October 2003.
[8] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[9] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
[10] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)",
RFC 5627, October 2009.
Roach Expires October 1, 2010 [Page 20]
Internet-Draft Globally Identifiable Number Routing March 2010
Author's Address
Adam Roach
Tekelec
17210 Campbell Rd.
Suite 250
Dallas, TX 75252
US
Email: adam@nostrum.com
Roach Expires October 1, 2010 [Page 21]
