DISPATCH WG H. Kaplan
Internet Draft Acme Packet
Intended status: Standards Track D. Hancock
Expires: June 19, 2010 CableLabs
J. Elwell
Siemens Enterprise
December 19, 2009
Session Initiation Protocol (SIP) Implicit Registrations
draft-kaplan-martini-shaken-implicit-registrations-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 19, 2010.
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Kaplan Expires June 19, 2010 [Page 1]
Internet-Draft SIP Implicit Registrations December 2009
Abstract
This document defines a mechanism for providing reachability
information for multiple AoRs using a single SIP REGISTER method
transaction.
Table of Contents
1. Introduction................................................2
2. Definitions.................................................3
3. Background Discussion.......................................3
3.1. The Need for Implicit Registration......................4
3.2. Benefits of using REGISTER..............................5
4. Implicit Registration Mechanism.............................5
4.1. Overview of the Mechanism...............................5
4.2. Administrative Responsibility of AoRs...................6
4.3. User Agent Behavior.....................................6
4.3.1 Generating the REGISTER Request.......................6
4.4. Registrar Behavior......................................7
4.4.1 Processing the REGISTER Request.......................7
4.4.2 Routing SIP Requests..................................8
5. Examples....................................................9
5.1. Example-1: Registrar only...............................9
5.2. Example-2: Registrar with Proxy........................11
6. IANA Considerations........................................14
7. Acknowledgments............................................14
8. Informative References.....................................14
Authors' Addresses...............................................15
1. Introduction
The SIP protocol, as defined in [RFC3261] and its extensions,
supports multiple means of resolving the connection information
necessary to deliver out-of-dialog SIP requests to their intended
targets. When a SIP UA or Proxy needs to send a request to a target
which is scoped in a domain for which it is not
authoritative/responsible, the UA/Proxy can use [RFC3263] procedures
for using DNS to resolve the next-hop connection information. When
a UA/Proxy needs to send a request to a target address-of-record
(AoR) within its domain, it can use its location service to resolve
the Registered Contact URI, and potentially any Path information
attached to it per [RFC3327], to build a route set to reach the
target UA(s).
It is not uncommon, however, to use REGISTER requests to provide the
reachability information for such cases, even for AoRs and domains
the REGISTER request does not explicitly identify it is registering
Kaplan Expires - June 2009 [Page 2]
Internet-Draft SIP Implicit Registrations December 2009
for. This draft defines the behavior of such a mechanism, coined
"Implicit Registration".
This authors know of at least four organizations using this type of
model: the SIP Forum, ETSI, 3GPP, and CableLabs.
2. Definitions
For brevity's sake, this document uses the word "request" instead of
"out-of-dialog request", but in all cases this term means out-of-
dialog request.
AoR: address-of-record, as defined by RFC 3261: a URI by which the
user is canonically known (e.g., on their business cards, in the
From header field of their requests, in the To header field of
REGISTER requests).
Domain Name: An explicit identifier which defines a separate scope
of authority, following the syntax and semantics of DNS.
Explicitly Registered AoR: A mutually agreed-upon AoR used for the
REGISTER transaction, identified in the To-URI of the REGISTER
request.
Implicit Registration: implicitly providing the reachability
information for something other than the AoR indicated in the
Register transaction.
Reachability Information: a set of URIs identifying the host and
path of Proxies to reach that host; like any URI, these URIs may
identify the specific connection transport, IP Address, and port
information, or they may only identify FQDN's.
SSP: SIP Service Provider, as defined by [RFC5486].
3. Background Discussion
In some environments, notably the Small-to-Medium Business (SMB)
market, SIP devices in the Enterprise are effectively IP-PBX's,
behind which are other devices (including SIP devices) supporting
individual users within the Enterprise. The SIP IP-PBX receives
Primary Rate Interface (PRI) type SIP trunk services from a SIP
Service Provider (SSP). The SIP IP-PBX device is authoritative for
its local AoRs and uses Implicit Registration to provide
reachability information to the SSP for those AoRs.
In SIP, there is an assumption that AoRs of a given SIP Domain are
under the authority of that Domain, and it alone has the right and
responsibility to provide SIP services for those AoRs, such as call-
Kaplan Expires - June 2009 [Page 3]
Internet-Draft SIP Implicit Registrations December 2009
forwarding, forking, fallback to voicemail, etc. When a SIP UA
registers an AoR, it is actually claiming authority/responsibility
for that AoR. Likewise, when a SIP UA (e.g., a SIP IP-PBX) performs
an Implicit Registration, it is actually claiming
authority/responsibility for the set of AoRs it is implicitly
Registering for.
3.1. The Need for Implicit Registration
Even if the SMB has its own Domain Name, not every small business
owner has a DNS, or has the technical capability to provision DNS
entries (e.g., SRV's) appropriately in their DNS, or has the ability
to do so through any third party which hosts their domain name(s),
or has the wish to make their SIP device address known publicly. In
many cases, DNS resolution would not be sufficient to route requests
to the SMB, because specific SIP Proxies need to be traversed to
reach the SMB. Furthermore, the SMB may not have its own Domain
Name at all, and instead merely has an IP Address.
Because a single SSP may support multiple thousands of such SMB IP-
PBX's, it is impractical and cost-prohibitive to manually provision
their IP Addresses in every SIP node along the path which needs to
reach the SMB IP-PBX customer. Instead, a dynamic reachability
mechanism is needed.
Such a mechanism already exists for SIP: the REGISTER method. A
REGISTER request provides dynamic reachability information for an
AoR's authoritative domain.
Since a REGISTER request mechanism is generally supported by most
SIP Service Providers' equipment, it has become common practice for
small SIP IP-PBX's to use the mechanism as a means of providing
their reachability information. In some cases interoperability
problems have arisen, due to differing expectations and
implementations of how such a mechanism should work in practice.
Kaplan Expires - June 2009 [Page 4]
Internet-Draft SIP Implicit Registrations December 2009
3.2. Benefits of using REGISTER
Using a REGISTER request for providing reachability information has
several benefits:
. It alleviates the Enterprise from having a SIP signaling
address publicly viewable in DNS.
. It provides mechanisms that make the SIP device publicly
reachable even if a NAT exists between the device and the
Service Provider network.
. It avoids having to statically provision the path from the
Service Provider core through edge proxies per Enterprise,
because the Path header field can be used.
. It allows the Service Provider to give the SIP device a pre-
loaded route set for subsequent requests, using the Service-
Route header field per [RFC3608].
. It provides a periodic keep-alive mechanism, in order to detect
service outages, and service restoration.
. It is an existing SIP request method type, known to be
supported by most SIP devices.
. It is conceptually similar to the Registration behavior model
in RFC 3261.
4. Implicit Registration Mechanism
4.1. Overview of the Mechanism
In an Implicit Registration model, the SIP UA (i.e., an IP-PBX)
Registers using a single, mutually agreed-upon, Address-of-Record
(AoR).
The Contact URI it Registers for that AoR, along with any Path
header field information, represents the reachability information
used to route subsequent requests from the SSP to the SIP UA, for
the Registered AoR and any implicitly registered AoRs.
The REGISTER transaction creates a real SIP Registration per
[RFC3261], and updates a location service database for the SIP AoR
being Registered as well as other mutually agreed-upon AoRs.
The mechanics of routing out-of-dialog requests to the AoRs,
however, is different from "normal" Registration-based location
service resolution routing. In particular, in order for the UA to
determine which AoR is being targeted by a request, the request-URI
is not replaced by the Registered Contact-URI; instead the Contact-
URI is inserted as a loose-route Route header field value, along
with any stored Path information.
Kaplan Expires - June 2009 [Page 5]
Internet-Draft SIP Implicit Registrations December 2009
4.2. Administrative Responsibility of AoRs
In an Implicit Registration model, the SIP UA (i.e., an IP-PBX) is
technically authoritative for its explicitly and implicitly
Registered AoRs. What this means is that a request from one AoR of
the IP-PBX targeted for another AoR of the same IP-PBX would be
routed locally within the IP-PBX, directly to the other AoR. This
implies that UAs behind the IP-PBX need to Register reachability
information for their AoRs with the SIP IP-PBX, so that they can be
reached from the SIP-PBX. If they were to Register their
reachability information with the SSP instead, they would not be
reachable from within the IP-PBX, only from the SSP. By registering
with the IP-PBX, which in turn uses implicit registration to
register their AoRs with the SSP, those UAs can be reached either
from within the IP-PBX or from the SSP (via the IP-PBX).
4.3. User Agent Behavior
4.3.1 Generating the REGISTER Request
All procedures for constructing the REGISTER request defined in
section 10.2 of [RFC3261] apply, with the additional constraints
defined in this section.
The target Request-URI of the REGISTER request MUST be the Domain
Name of the SSP or a Registrar host name of the SSP.
The To and From URIs of the REGISTER request MUST contain the
mutually agreed-upon explicit AoR to be Registered, in a SIP or SIPS
URI format. The URI MUST have a user portion, to uniquely identify
the IP-PBX.
Note that using a SIP URI instead of a SIPS URI for the AoR does not
preclude using TLS for the entire path between the UA and the
Registrar, nor does it preclude using SIPS URIs for the explicit or
implicit AoRs in other SIP requests to or from the Registering SIP
UA. For a SIPS scheme to be usable, the Implicit Registration would
have to be done over a transport which SIPS allows (e.g., TLS).
The To header field MUST contain a new "multi" header parameter,
with the value "true". This indicates the AoR being Registered may
not be the only AoR being registered, and that instead the mechanism
defined in this document is being used. A new option-tag defined
later in this document will require the Registrar to support this
new parameter.
The REGISTER request MUST contain one and only one Contact URI,
which MUST be the transport connection reachability address
information for reaching the UA/IP-PBX. If a UA/IP-PBX has multiple
Kaplan Expires - June 2009 [Page 6]
Internet-Draft SIP Implicit Registrations December 2009
connection paths it can be reached through (e.g., multiple
transports or multiple interfaces), each one MUST be Registered
separately, in separate REGISTER transactions with their individual
respective Contact URIs.
The Contact header field of the REGISTER request MAY contain a 'q'
q-value parameter to indicate a relative preference for this
particular reachability information, as defined in [RFC3261] section
20.10. Note that only a single Contact URI is allowed in a single
REGISTER request based on this document's mechanism, and thus the q-
value is relative to all REGISTER requests for the same UA/IP-PBX.
The default q-value, if not explicitly indicated, is 0.5.
The Contact header field MUST contain an 'expires' parameter,
indicating how long the Contact URI is valid, as defined in
[RFC3261].
The Contact URI MUST contain an "lr" URI parameter, indicating the
URI is used as a loose-route. The option-tag defined for this
mechanism later is used to require the Registrar to support this
parameter in the Contact URI.
The procedures in [SIP-Outbound] SHOULD be followed, if both the SIP
UA and the SSP support Outbound. Using Outbound procedures does not
change the fundamental behavior of the mechanism described in this
document; it only provides additional procedures and fields for
Registering multiple flows using identifiers, with specific keep-
alive mechanisms and timers.
The REGISTER request MUST contain the new 'implicit' option-tag in a
Require header field. This option-tag indicates the Registrar must
support the mechanism identified in this document to process the
Register request successfully. In particular, it will require the
Registrar to detect the "lr" URI parameter in the Contact URI which
indicates the Contact URI is a loose-route for the AoR being
Registered, and detect the "multi=true" To header field parameter.
4.4. Registrar Behavior
This document uses the same logical location service database
concept of [RFC3261] residing in the Registrar, for the purpose of
describing the behavior of the mechanism in this document. Specific
implementations need not follow this data structure, so long as they
maintain the same logical external behavior.
4.4.1 Processing the REGISTER Request
All REGISTER processing rules for Registrars defined in section 10.3
of [RFC3261] apply, except as noted herein.
Kaplan Expires - June 2009 [Page 7]
Internet-Draft SIP Implicit Registrations December 2009
When receiving a REGISTER request with a Require header field
containing "implicit", and the Registrar supports this extension,
and assuming valid authentication, the Registrar MUST check the To
header field for the new "multi" parameter. The procedures below
apply only if this parameter is present and has the value "true".
The "multi=true" parameter indicates the AoR being Registered may
not be the only AoR being Registered, and that one or more mutually
pre-agreed-upon AoRs will also be Registered with the reachability
information of this REGISTER request. In such a case, each location
service database entry for the set of mutual agreed-upon AoRs is
updated with the reachability information (Contact and Path) and q-
value of the received REGISTER request.
If a matching entry is found in the database and the Contact URI
being Registered does not match any already in the database for the
entry, the Registrar MUST add the entry as a serial-forking entry
only. Parallel forking to multiple contacts of the same AoR does
not make sense in an SSP-to-IP-PBX model.
If a q-value is received, it MUST be added as well, otherwise the
default q-value of 0.5 MUST be used. The q-value affects the serial
forking decision for multiply registered Contacts.
The Registrar MUST indicate support for this mechanism by inserting
the new "implicit" option-tag in a Supported header field, and by
keeping the "multi=true" To-header parameter, in the REGISTER
response.
The Registrar SHOULD indicate all of the implicitly Registered AoRs
in a P-Associated-URI header field(s) in the 200 response to the
REGISTER, if it supports [RFC3455].
[OPEN ISSUE: should we mandate PAU support? Should we document a
legal/compliant means of indicating AoR username "wildcards"?]
4.4.2 Routing SIP Requests
If the SSP receives a SIP request containing a Request-URI that
identifies an AoR registered either explicitly or implicitly using a
REGISTER request with "multi=true" in the To header field, then the
SSP MUST NOT replace the Request-URI with the Registered Contact
URI. Instead, a Route header field(s) MUST be inserted with the
value of the Registered reachability information, after any other
Route header field values generated from local policies. Note the
Registered reachability information comprises any received Path URIs
and the entire Registered Contact URI, including any userinfo
portion, URI parameters, and embedded headers. As per [RFC3327],
the created Route header field values would be based on the
Kaplan Expires - June 2009 [Page 8]
Internet-Draft SIP Implicit Registrations December 2009
Registered Path URI list in received order, with the Registered
Contact URI appended as the last and final entry.
If multiple matching entries are found, for example due to multiple
Registered Contact URIs for the same explicit AoR, then the q-value
of each Registered Contact URI MUST be used to select the route set
for serial forking. The highest q-value is selected first, and only
if it fails is the next highest one attempted, and so on.
5. Examples
The following sections provide example cases of the mechanism
defined in this document. Each example includes more than one
concept being shown at the same time. The first example shows a
single Registrar-Proxy case, using an implicit q-value, where there
are no implicit AoRs. The second example shows a separate edge-
Proxy before the Registrar, with the Path header field mechanism
being used and an explicit q-value, with one implicit AoR. Both
examples show a REGISTER transaction and an initial INVITE request.
5.1. Example-1: Registrar only
As an example, assume the following scenario:
UA1----REG-----UA2
The node marked UA1 is the Registering IP-PBX; REG is a registrar
and a proxy, and serves as the authoritative proxy for
ssp.example.net; and UA2 is another UA trying to reach a user of
UA1.
Note that some header fields (e.g., Content-Length) and session
descriptions are omitted to provide a shorter and hopefully more
readable presentation.
Message sequence for REGISTER:
F1 Register UA1 -> REG
REGISTER sip:ssp.example.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7
To: <sip:pbx1234@ssp.example.net>;multi=true
From: <sip:pbx1234@ssp.example.net>;tag=456248
Call-ID: 843817637684230
CSeq: 1826 REGISTER
Contact: <sip:pbx-100@192.0.2.4:6000;lr>;expires=3600
Require: implicit
. . .
Kaplan Expires - June 2009 [Page 9]
Internet-Draft SIP Implicit Registrations December 2009
E2 REG executes Register
REGISTRAR Stores in location service database:
For AoR "pbx1234@ssp.example.net":
Contact: sip:pbx-100@192.0.2.4:6000;lr
Q-Value: 0.5
Expires: 3600
No other AoRs are implicitly Registered.
F3 200 Register response REG -> UA1
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7
To: <sip:pbx1234@ssp.example.net>;multi=true;tag=12345
From: <sip:pbx1234@ssp.example.net>;tag=456248
Call-ID: 843817637684230
CSeq: 1826 REGISTER
Contact: <sip:pbx-100@192.0.2.4:6000;lr>;expires=3600
Supported: path, implicit
. . .
Message sequence for INVITE to UA1:
F1 Invite UA2 -> REGISTRAR
INVITE sip:pbx1234@ssp.example.net SIP/2.0
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: <sip:pbx1234@ssp.example.net>
From: UA2 <sip:UA2@example.org>;tag=224497
Call-ID: 48273181116
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
. . .
E2 REGISTRAR processing
REGISTRAR looks up name "pbx1234" for its domain, and finds an
entry belonging to UA1:
Contact: <sip:pbx-100@192.0.2.4:6000;lr>
REGISTRAR performs route set creation based on this document's
mechanism, resulting in a route set of:
Route: <sip:pbx-100@192.0.2.4:6000;lr>
Kaplan Expires - June 2009 [Page 10]
Internet-Draft SIP Implicit Registrations December 2009
F3 Invite REGISTRAR -> UA1
INVITE sip:pbx1234@corp.ssp.example.net SIP/2.0
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Route: <sip:pbx-100@192.0.2.4:6000;lr>
To: <sip:pbx1234@ssp.example.net>
From: UA2 <sip:UA2@example.org>;tag=224497
Call-ID: 48273181116
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
. . .
5.2. Example-2: Registrar with Proxy
As an example, assume the following scenario:
UA1----P1-----REG-----UA2
The node marked UA1 is the Registering IP-PBX; P1 is the SSP's edge
proxy; REG is a registrar and a proxy, and serves as the
authoritative proxy for ssp.example.net; and UA2 is another UA
trying to reach a user of UA1.
In this example, there are implicitly registered AoRs.
Note that some header fields (e.g. Content-Length) and session
descriptions are omitted to provide a shorter and hopefully more
readable presentation.
Message sequence for REGISTER with Path:
F1 Register UA1 -> P1
REGISTER sip:ssp.example.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7
To: <sip:pbx1234@ssp.example.net>;multi=true
From: <sip:pbx1234@ssp.example.net>;tag=456248
Call-ID: 843817637684230
CSeq: 1826 REGISTER
Contact: <sip:admin@192.0.2.5;lr>;q=1.0;expires=3600
Require: implicit
. . .
F2 Register P1 -> REG
REGISTER sip:ssp.example.net SIP/2.0
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7
Kaplan Expires - June 2009 [Page 11]
Internet-Draft SIP Implicit Registrations December 2009
To: <sip:pbx1234@ssp.example.net>;multi=true
From: <sip:pbx1234@ssp.example.net>;tag=456248
Call-ID: 843817637684230
CSeq: 1826 REGISTER
Contact: <sip:admin@192.0.2.5;lr>;q=1.0;expires=3600
Require: implicit
Path: <sip:cookie@p1.ssp.example.net;lr>
. . .
Note: P1 has added itself to the Path.
E3 REG executes Register
REGISTRAR Stores in location service database:
For AoR "pbx1234@ssp.example.net":
Contact: sip:pbx-100@192.0.2.4:6000;lr
Path: <sip:cookie@p1.ssp.example.net;lr>
Q-Value: 1.0
Expires: 3600
For (implicit) AoR "+12125551212@ssp.example.net":
Contact: sip:pbx-100@192.0.2.4:6000;lr
Path: <sip:cookie@p1.ssp.example.net;lr>
Q-Value: 1.0
Expires: 3600
F4 200 Register response REG -> P1
SIP/2.0 200 OK
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7
To: <sip:pbx1234@ssp.example.net>;multi=true;tag=12345
From: <sip:pbx1234@ssp.example.net>;tag=456248
Call-ID: 843817637684230
CSeq: 1826 REGISTER
Contact: <sip:admin@192.0.2.5;lr>;q=1.0;expires=3600
Supported: path, implicit
Path: <sip:cookie@p1.ssp.example.net;lr>
P-Associated-URI: <sip:+12125551212@ssp.example.net>
. . .
Kaplan Expires - June 2009 [Page 12]
Internet-Draft SIP Implicit Registrations December 2009
F5 200 Register response P1 -> UA1
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4:6000;branch=z9hG4bKnashds7
To: <sip:pbx1234@corp.ssp.example.net>;multi=true;tag=12345
From: <sip:pbx1234@corp.ssp.example.net>;tag=456248
Call-ID: 843817637684230
CSeq: 1826 REGISTER
Contact: <sip:admin@192.0.2.5;lr>;q=1.0;expires=3600
Supported: path, implicit
Path: <sip:cookie@p1.ssp.example.net;lr>
P-Associated-URI: <sip:+12125551212@ssp.example.net>
. . .
Message sequence for INVITE to UA1:
F1 Invite UA2 -> REGISTRAR
INVITE sip:+12125551212@ssp.example.net;user=phone SIP/2.0
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: <sip:+12125551212@ssp.example.net;user=phone>
From: UA2 <sip:UA2@example.org>;tag=224497
Call-ID: 48273181116
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
. . .
F2 REGISTRAR processing
REGISTRAR looks up name "+12125551212" for its domain, and finds
an entry belonging to UA1:
Contact: sip:admin@192.0.2.5;lr
Path: <sip:cookie@p1.ssp.example.net;lr>
Q-Value: 1.0
REGISTRAR performs route set creation based on this document's
mechanism, resulting in a route set of:
Route: <sip:cookie@p1.ssp.example.net;lr>,
<sip:admin@192.0.2.5;lr>
Kaplan Expires - June 2009 [Page 13]
Internet-Draft SIP Implicit Registrations December 2009
F3 Invite REGISTRAR -> P1
INVITE sip:+12125551212@ssp.example.net;user=phone SIP/2.0
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Route: <sip:cookie@p1.ssp.example.net;lr>,
<sip:admin@192.0.2.5;lr>
To: <sip:+12125551212@ssp.example.net;user=phone>
From: UA2 <sip:UA2@example.org>;tag=224497
Call-ID: 48273181116
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
. . .
F4 Invite P1 -> UA1
INVITE sip:+12125551212@ssp.example.net;user=phone SIP/2.0
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
Route: <sip:admin@192.0.2.5;lr>
To: <sip:+12125551212@ssp.example.net;user=phone>
From: UA2 <sip:UA2@example.org>;tag=224497
Call-ID: 48273181116
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
. . .
6. IANA Considerations
This document will request IANA for a new SIP option-tag named
"implicit", for the purpose defined herein; a new header field
parameter named "multi" with a single value of "true", as defined
previously; and to update the applicability of the "lr" URI
parameter to apply to the Contact URI.
7. Acknowledgments
Thanks to a whole bunch of people to be named later.
8. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
Kaplan Expires - June 2009 [Page 14]
Internet-Draft SIP Implicit Registrations December 2009
[RFC3263] Rosenberg, J., Schulzrinne, H., "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, June
2002.
[RFC3327] Willis, D., and Hoeneisen, B., "Session Initiation
Protocol (SIP) Extension Header Field for Registering
Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3455] Garcia-Martin, M., Henrikson, E., and Mills, D., "Private
Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project
(3GPP)", RFC 3455, January 2003.
[RFC3608] Willis, D., and Hoeneisen, B., "Session Initiation
Protocol (SIP) Extension Header Field for Service Route
Discovery During Registration", RFC 3608, October 2003.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004.
[RFC5486] Malas, D., and Meyer, D., "Session Peering for Multimedia
Interconnect (SPEERMINT) Terminology", RFC 5486, March
2009.
Authors' Addresses
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803, USA
Email: hkaplan@acmepacket.com
David Hancock
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: d.hancock@cablelabs.com
John Elwell
Siemens Enterprise Communications
Email: john.elwell@siemens-enterprise.com
Kaplan Expires - June 2009 [Page 15]