One document matched: draft-roach-martini-gin-00.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!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 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-kaplan-martini-mixing-problems PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kaplan-martini-mixing-problems-00.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-roach-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="February" day="2" 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 the 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.
The document "SIP IP-PBX Registration Problems"
<xref target="I-D.kaplan-martini-mixing-problems"/> describes
several deployed IP PBX registration techniques, along with
a number of problems that arise from the approaches that
have been implemented to date.
</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.
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>
This document uses the terms defined in section 2 of
"SIP IP-PBX Registration Problems"
<xref target="I-D.kaplan-martini-mixing-problems"/>.
</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 understands 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, as well as a syntactically
valid (but rare) set of characters to indicate where
the phone number is to be placed for incoming calls.
</t>
<t>
We also define some lightweight extensions for GRUU to
allow the use of public GRUUs assigned by the SSP.
</t>
<t>
Finally, we non-normatively demonstrate that existing
procedures that can be used to generate
temporary GRUUs for terminals behind the PBX.
</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 "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.
</t>
<t><list style="hanging"><t>
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.
</t></list></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>
[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.]
</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 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".
</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 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.
</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)">
<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 herein.
</t>
<section title="Public GRUUs">
<t>
For this mechanism to work correctly with pubic GRUUs,
we require a minor extension to the public GRUU behavior
between the SSP and the PBX.
</t>
<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 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
So, for example, when the PBX registers the with the following
contact header field:
<figure> <artwork>
Contact: <sip:()@198.51.100.3;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;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>
</artwork></figure>
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:
<figure> <artwork>
Contact: <sip:line-1@10.20.1.17>;
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
</artwork></figure>
The PBX will replace the "*" in the pub-gruu it received from
the SSP 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:
<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~00:05:03:5e:70:a6";
+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
;expires=3600
</allOneLine>
</artwork></figure>
</t>
</section>
<section title="Temporary 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).
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 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>
</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 both the "()" syntax and the "bnc"
parameter are forbidden to appear 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)">
<t>
RFC 3327 <xref target="RFC3327"/>
-- needs analysis. Some people think it might "just work."
</t>
</section>
<section title="Service Route Discovery">
<t>
RFC 3608 <xref target="RFC3608"/>
-- needs analysis. Some people think it might "just work."
</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>
<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
Require: bulk-number-contact
Contact: <sip:()@198.51.100.3:5060;bnc>
Expires: 7200
Content-Length: 0
]]></artwork> </figure>
<figure> <artwork><![CDATA[
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: ...
<sdp body here>
]]></artwork> </figure>
<figure> <artwork><![CDATA[
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>
]]></artwork> </figure>
</section>
<section title="Issues Solved">
<t>
The document "SIP IP-PBX Registration Problems"
<xref target="I-D.kaplan-martini-mixing-problems"/> 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.
</t>
<t>
<list style="hanging">
<t hangText="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).
<vspace blankLines="1"/>
</t>
<t hangText="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 <xref target="pbx-reg-event"/>.
<vspace blankLines="1"/>
</t>
<t hangText="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 <xref target="pbx-reg-event"/>.
<vspace blankLines="1"/>
</t>
<t hangText="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.
<vspace blankLines="1"/>
</t>
<t hangText="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.
<vspace blankLines="1"/>
</t>
<t hangText="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.
<vspace blankLines="1"/>
</t>
<t hangText="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.
<vspace blankLines="1"/>
</t>
<t hangText="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.
<vspace blankLines="1"/>
</t>
<t hangText="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.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="IANA Considerations">
<t>
This isn't even close to finished. It's here to remind me
that there are IANA impacts.
</t>
<section title="New SIP Option Tag">
<t>
bulk-number-contact
</t>
</section>
<section title="New SIP URI Parameter">
<t>
bnc
</t>
</section>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc3261;
&rfc3263;
</references>
<references title='Informative References'>
&draft-kaplan-martini-mixing-problems;
&rfc3327;
&rfc3608;
&rfc3680;
&rfc5626;
&rfc5627;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:38:44 |