One document matched: draft-ietf-martini-gin-00.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY rfc3263 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml'>
<!ENTITY rfc3327 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3327.xml'>
<!ENTITY rfc3608 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3608.xml'>
<!ENTITY rfc3680 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3680.xml'>
<!ENTITY rfc3969 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3969.xml'>
<!ENTITY rfc5626 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5626.xml'>
<!ENTITY rfc5627 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5627.xml'>
<!ENTITY draft-ietf-martini-reqs PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-martini-reqs-02.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc symrefs="no"?>
<rfc ipr="trust200902" docName="draft-ietf-martini-gin-00" category="std">
<front>
<title abbrev="Globally Identifiable Number Routing">Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)</title>
<author initials="A. B." surname="Roach" fullname="Adam Roach">
<organization>Tekelec</organization>
<address>
<postal>
<street>17210 Campbell Rd.</street>
<street>Suite 250</street>
<city>Dallas</city> <region>TX</region> <code>75252</code>
<country>US</country>
</postal>
<email>adam@nostrum.com</email>
</address>
</author>
<date month="March" day="30" year="2010" />
<area>Real Time Applications and Infrastructure</area>
<workgroup>MARTINI WG</workgroup>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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 <xref target="RFC3263"/>, and the registrar procedures
described in RFC 3261 <xref target="RFC3261"/>.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Constraints" anchor="constraints">
<t>
The following paragraph is perhaps the most important
in understanding the solution defined in this document.
</t>
<t>
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
<xref target="I-D.ietf-martini-reqs"/>.
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.
</t>
</section>
<section title="Terminology">
<t> 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
<xref target="RFC2119" />.</t>
<t>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.</t>
</section>
<section title="Mechanism Overview">
<t>
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.
</t>
<t>
The Contact URI itself is tagged with a URI parameter
to indicate that it actually represents a multitude of
phone-number-associated contacts.
</t>
<t>
We also define some lightweight extensions for GRUU to
allow the use of public and temporary GRUUs assigned by
the SSP.
</t>
<t>
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.
</t>
<t>
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 <xref target="pbx-reg-event"/>).
</t>
</section>
<section title="Registering for Multiple Phone Numbers">
<t>
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 "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.
</t>
<t>
Because of the constraints
discussed in <xref target="constraints"/>, 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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>.
</t>
<t>
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.
</t>
</section>
<section title="SSP Processing of Inbound Phone Number Requests">
<t>
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 <xref target="RFC3261"/>.
</t>
</section>
<section title="Interaction with Other Mechanisms">
<t>
The following sections describe the means by which this mechanism
interacts with relevant REGISTER-related extensions currently
defined by the IETF.
</t>
<t>
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.
</t>
<section title="Globally Routable User-Agent URIs (GRUU)" anchor="gruu">
<t>
To enable advanced services to work with extensions
behind a SIP PBX, it is important that the GRUU
mechanism defined by RFC 5627
<xref target="RFC5627"/>
work correctly with the mechanism defined by this document.
</t>
<section title="Public GRUUs">
<t>
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.
</t>
<t>
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.
</t>
<t>
So, for example, when the PBX registers with the following
contact header field:
<figure> <artwork>
Contact: <sip:198.51.100.3;user=phone;bnc>;
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</artwork></figure>
Then the SSP may choose to respond with a Contact header field
that looks like this:
<figure> <artwork>
<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>
</artwork></figure>
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:
<figure> <artwork>
Contact: <sip:line-1@10.20.1.17>;
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
</artwork></figure>
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:
<figure> <artwork>
<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>
</artwork></figure>
</t>
<t>
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.
</t>
</section>
<section title="Temporary GRUUs">
<t>
PBXes have two options for creating temporary GRUUs
for use by its terminals.
</t>
<section title="Approach 1 - Self Made GRUUs">
<t>
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
<xref target="RFC5627"/>).
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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:
</t>
<figure> <artwork>
<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>
</artwork></figure>
</section>
<section title="Approach 2 - Anonymous Public GRUUs" anchor="anon-gruu">
<t>
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 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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:
</t>
<figure> <artwork>
<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>
</artwork></figure>
</section>
</section>
</section>
<section title="Registration Event Package">
<t>
As this mechanism inherently deals with REGISTER behavior,
it is imperative to consider its impact on the Registration
Event Package defined by RFC 3680 <xref target="RFC3680"/>.
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.
</t>
<section title="PBX Aggregate Registration State"
anchor="pbx-reg-event">
<t>
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.
</t>
<t>
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").
</t>
<t>
In particular, the "bnc" parameter is forbidden from
appearing in the body of a reg-event notify.
</t>
</section>
<section title="Individual Extension Registration State">
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Client-Initiated (Outbound) Connections">
<t>
RFC 5626 <xref target="RFC5626"/>
-- needs analysis. Some people think it might "just work."
</t>
</section>
<section title="Non-Adjacent Contact Registration (Path) and Service Route Discovery">
<t>
RFC 3327 <xref target="RFC3327"/> 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.
</t>
<t>
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.
</t>
<t>
To provide similar functionality in the opposite direction --
that is, to establish a route for requests sent by a registering
UA -- RFC 3608 <xref target="RFC3608"/> defines a means
by which a UA can be informed of a route 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Examples">
<t>
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.
</t>
<section title="Usage Scenario: Basic Registration">
<t>
This example shows a basic bulk REGISTER transaction,
followed by an INVITE addressed to one of the registered
terminals.
</t>
<figure> <artwork><![CDATA[
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 |
| |-------------------------------->|
]]></artwork> </figure>
<figure> <artwork><![CDATA[
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
]]></artwork> </figure>
<figure> <artwork><![CDATA[
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>
]]></artwork> </figure>
<figure> <artwork><![CDATA[
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>
]]></artwork> </figure>
</section>
<section title="Usage Scenario: Using Path to Control Request URI">
<t>
This example shows a bulk REGISTER transaction with
the SSP making use of the "Path" header field extension
<xref target="RFC3327"/>.
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.
</t>
<figure> <artwork><![CDATA[
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> |
| |-------------------------------->|
]]></artwork> </figure>
<figure> <artwork><![CDATA[
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
]]></artwork> </figure>
<figure> <artwork><![CDATA[
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>
]]></artwork> </figure>
<figure> <artwork><![CDATA[
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>
]]></artwork> </figure>
</section>
</section>
<section title="Requirements Analysis">
<t>
The document "Requirements for multiple address of record
(AOR) reachability information in the Session Initiation
Protocol (SIP)" <xref target="I-D.ietf-martini-reqs"/>
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.
</t>
<t>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.</t>
<t><list style='empty'><t>The requirement is satisfied.</t></list></t>
<t>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.</t>
<t><list style='empty'><t>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.</t></list></t>
<t>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.</t>
<t><list style='empty'><t>The requirement is satisfied.</t></list></t>
<t>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.</t>
<t><list style='empty'><t>The requirement is satisfied; in the presumed architecture, PBX terminals register with the PBX, an require no interaction with the SSP.</t></list></t>
<t>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.</t>
<t><list style='empty'><t>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.</t></list></t>
<t>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.</t>
<t><list style='empty'><t>The requirement is satisfied</t></list></t>
<t>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.</t>
<t><list style='empty'><t>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 <xref target="anon-gruu"/>, the "sg" parameter provides a correlation token the PBX can use to identify which terminal the call should be routed to.</t></list></t>
<t>REQ8 - The mechanism MUST provide a means of avoiding problems due to one side using the mechanism and the other side not.</t>
<t><list style='empty'><t>The requirement is satisfied through the 'bulknumbercontact' option tag and the 'bnc' Contact parameter.</t></list></t>
<t>REQ9 - The mechanism MUST observe SIP backwards compatibility principles.</t>
<t><list style='empty'><t>The requirement is satisfied through the 'bulknumbercontact' option tag.</t></list></t>
<t>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.</t>
<t><list style='empty'><t>The requirement is satisfied through the use of the Path mechanism defined in RFC 3327 <xref target="RFC3327"/> </t></list></t>
<t>REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address dynamically.</t>
<t><list style='empty'><t>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.</t></list></t>
<t>REQ12 - The mechanism MUST work without requiring the SIP-PBX to have a domain name or the ability to publish its domain name in the DNS.</t>
<t><list style='empty'><t>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.</t></list></t>
<t>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.</t>
<t><list style='empty'><t>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.</t></list></t>
<t>REQ14 - The mechanism MUST be able to operate over a transport that provides integrity protection and confidentiality.</t>
<t><list style='empty'><t>The requirement is satisfied; nothing in the proposed mechanism prevent the use of TLS between the SSP and the PBX.</t></list></t>
<t>REQ15 - The mechanism MUST support authentication of the SIP-PBX by the SSP and vice versa.</t>
<t><list style='empty'><t>The requirement is satisfied; PBXes may employ either SIP digest authentication or mutually-authenticated TLS for authentication purposes.</t></list></t>
<t>REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with public or temporary Globally Routable UA URIs (GRUUs) <xref target="RFC5627"/>.</t>
<t><list style='empty'><t>The requirement is satisfied via the mechanisms detailed in <xref target="gruu"/>.</t></list></t>
<t>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.</t>
<t><list style='empty'><t>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.)</t></list></t>
<t>REQ18 - The mechanism MUST work over any existing transport specified for SIP, including UDP.</t>
<t><list style='empty'><t>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.</t></list></t>
<t>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.</t>
<t><list style='empty'><t>The desired property is satisfied; the routing mechanism described in this document is identical to the routing performed for singly-registered AORs.</t></list></t>
<t>DES2 - The mechanism SHOULD scale to SIP-PBX's of several thousand assigned telephone numbers.</t>
<t><list style='empty'><t>The desired property is satisfied; nothing in this document precludes DID pools of arbitrary size.</t></list></t>
<t>DES3 - The mechanism SHOULD scale to support several thousand SIP-PBX's on a single SSP.</t>
<t><list style='empty'><t>The desired property is satisfied; nothing in this document precludes an arbitrary number of PBXes from attaching to a single SSP.</t></list></t>
<t>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.</t>
<t><list style='empty'><t>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.</t></list></t>
</section>
<section title="IANA Considerations">
<t>
This document registers a new SIP option tag to indicate support
for the mechanism it defines, plus two new SIP URI parameters.
</t>
<section title="New SIP Option Tag">
<t> This section defines a new SIP option tag per the guidelines
in Section 27.1 of RFC 3261<xref target="RFC3261"/>.
<list style="hanging">
<t hangText="Name:">bulknumbercontact</t>
<t hangText="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.
</t>
<t hangText="Reference:">RFCXXXX (this document)</t>
</list>
</t>
</section>
<section title="New SIP URI Parameters">
<t>
This specification defines two new SIP URI parameters, as per the
registry created by RFC 3969 <xref target="RFC3969"/>.
</t>
<section title="'bnc' SIP URI paramter">
<t>
<list style="hanging">
<t hangText="Parameter Name:">bnc</t>
<t hangText="Predefined Values:">No (no values are allowed)</t>
<t hangText="Reference:">RFCXXXX (this document)</t>
</list>
</t>
</section>
<section title="'sg' SIP URI paramter">
<t>
<list style="hanging">
<t hangText="Parameter Name:">sg</t>
<t hangText="Predefined Values:">No</t>
<t hangText="Reference:">RFCXXXX (this document)</t>
</list>
</t>
</section>
</section>
</section>
<section title="Security Considerations">
<t>
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.
</t>
</section>
<section title="Acknowledgements">
<t>
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.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc3261;
&rfc3263;
&rfc3969;
</references>
<references title='Informative References'>
&draft-ietf-martini-reqs;
&rfc3327;
&rfc3608;
&rfc3680;
&rfc5626;
&rfc5627;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:42:31 |