MARTINI WG H. Kaplan
Internet Draft Acme Packet
Intended status: Informational
Expires: October 8, 2011 April 8, 2010
SIP MARTINI with
Other Logical Identifier Values which are not E.164 (OLIVE)
draft-kaplan-martini-with-olive-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 October 8, 2011.
Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. 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.
Kaplan Expires October 18, 2010 [Page 1]
Internet-Draft SIP MARTINI with OLIVE April 2010
Abstract
The Martini Working Group is defining a mechanism for SIP IP-PBX
type devices to REGISTER and obtain SIP service for E.164-based
Address of Records. This document defines a means for other, non-
E.164 AoRs to be used with Martini-based IP-PBXs.
Table of Contents
1. Introduction................................................2
2. Definitions.................................................3
3. Background on Current Martini Mechanism.....................3
3.1. Why non-E.164 AoRs may need processing by SSPs.........4
3.2. The issues with non-E.164 Identifiers..................5
3.2.1 Globally unique AoR 5
3.2.2 Registered Contact Username 5
3.2.3 Avoiding syntax mismatches 6
4. The Solution - an Overview..................................7
5. Registering for AoRs........................................8
5.1. Registering Local Number AoRs..........................9
6. SSP Processing of Inbound Non-E.164 Requests...............10
6.1. Processing of Local-Number Requests...................10
7. Interaction with Other Mechanisms..........................10
7.1. Globally Routable User-Agent URIs (GRUU)..............10
7.2. Registration Event Package............................11
7.3. Non-Adjacent Contact Registration (Path) and Service Route
Discovery.....................................................11
8. Open Issues................................................11
9. Examples...................................................12
9.1. Usage Scenario: Basic Registration case 1.............12
9.2. Usage Scenario: Basic Registration case 2.............14
10. IANA Considerations........................................15
11. Security Considerations....................................15
12. Acknowledgements...........................................15
13. Informative References.....................................16
Author's Address.................................................17
1. Introduction
In many deployed SIP Service Provider (SSP) architectures, it is
common to use REGISTER requests to provide the reachability
information for IP-PBXs, instead of DNS-based resolution and
routing. An IETF-defined mechanism for doing so is being worked on
in the Martini Working Group, in [draft-gin].
The current Martini mechanism only supports E.164-based AoR's,
however in actual deployments private-extension or "local" numbers
are used for hosted and carrier-provided intra-Enterprise calling
Kaplan Expires - October 2009 [Page 2]
Internet-Draft SIP MARTINI with OLIVE April 2010
services, and domain-scoped "email-style" URIs may become more
popular in the near future. Neither of these forms of AoRs are
supported by the current Martini mechanism. This document defines a
means by which they can be supported, in a manner consistent with
[RFC3261] and [draft-gin].
2. Definitions
For brevity's sake, this document uses the word "request" instead of
"out-of-dialog request", but in all case 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, etc.).
Local-Number: an AoR which follows the form of local-number in
[RFC3966], but may be encoded in a SIP or TEL URI. The local-number
contains a 'phone-context' parameter identifying the scope of its
number.
Email-style URI: a SIP AoR which does not identify a global E.164
number or local-number.
Implicit Registration: implicitly providing the reachability
information for something other than the AoR explicitly indicated in
the Register transaction.
Reachability Information: a set of URI's identifying the host and
path of Proxies to reach that host; like any URI, these URI's 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 on Current Martini Mechanism
The current Martini mechanism, defined in [draft-gin], allows a SIP
UA such as an IP-PBX to Register a set of E.164 AoRs in "bulk".
Instead of creating a separate REGISTER transaction for every E.164
AoR, the IP-PBX sends one REGISTER request with a 'bnc' Contact URI
parameter which indicates the Contact URI needs to be expanded in
the Registrar's location service database. The expansion is such
that each E.164 user number becomes the user portion of the
Registered Contact URI, one for each implicitly Registered E.164
AoR.
Kaplan Expires - October 2009 [Page 3]
Internet-Draft SIP MARTINI with OLIVE April 2010
SIP Request routing to the Registered E.164 AoR then follows normal
[RFC3261] procedures, replacing the Request URI with the (expanded)
Registered Contact URI, and adding any Path information as a Route
set, etc.
3.1. Why non-E.164 AoRs may need processing by SSPs
There is some debate about how a non-E.164 AoR could even be
received by the SSP for processing to begin with. This section
describes how such could be the case.
It should be noted that this document only deals with SIP AoRs of
the same URI domain name as that of the REGISTER's To URI - namely
the SSP's domain.
A SIP Request targeted to a Local-number AoR could require
processing by the SSP because:
- The SSP provides IP-Centrex type services for some of the AoRs
of an Enterprise, for example for small branches, while
providing SIP-Trunk service to the main IP-PBX(s). Requests
from the IP-Centrex UAs will thus be targeted to Local-numbers
as they are received by the SSP Proxy on their way to the IP-
PBX.
- The SSP provides inbound extension dialing, for example by
offering private calling-card services, such that a E.164
number call is terminated by an Application Server of the SSP
which authenticates the caller belongs to an Enterprise and
then allows private extension dialing, as a UAC, thereby
originating a new SIP session Request using a Local-Number
target AoR.
A SIP Request targeted to an Email-style AoR could require
processing by an SSP because:
- The SSP provides Email-style AoRs for business customers - for
example "sip:bob@ssp.example.net".
- The SSP has a sub-division or sub-entity which uses IP-PBX
Martini trunks into the SSP main domain, for which the SSP
provides AoRs of the main SSP domain - for example, a sales
division IP-PBX in a sub-domain of sales.ssp.example.net, but
for which the SSP provides an AoR of
"sip:sales@ssp.example.net".
- The Email-style AoR is scoped to the Enterprise's domain, but
the Request originated from within the SSP - for example by one
of its subscriber SIP UAs. Since SIP UAs generally send their
Requests through their SSP's proxies, the Request will be
processed by them first. This type of AoR (i.e., one scoped
outside of the SSP's domain) is NOT in scope for this document.
Kaplan Expires - October 2009 [Page 4]
Internet-Draft SIP MARTINI with OLIVE April 2010
There are other possibilities as well, of course, but this section
is only intended to provide some basic rational for why it is
possible for a local-number or email-style AoR to be used and appear
in the SSP.
3.2. The issues with non-E.164 Identifiers
At the initial outset of Martini's work, the problem space to work
on was narrowed to E.164 numbers only, for several reasons. This
section attempts to identify the reasons in detail, and address
them.
3.2.1 Globally unique AoR
One of the initial benefits cited for only supporting E.164 is that
an E.164 user name is globally unique by itself, and thus changing
the host portion of the Request-URI does not impact the identity of
the intended target of the Request.
Fortunately, [draft-gin] does not in fact rely on that property of
the AoR username. What [draft-gin] does is emulate what would have
happened had the IP-PBX Registered each E.164 AoR separately. It is
not in fact Registering an "E.164 number" - it is Registering
typical [RFC3261] AoRs, which just happen to be formatted as E.164
numbers. For example, the IP-PBX is not implicitly Registering the
identity of "+12125551212", it is instead implicitly Registering for
the SIP AoR of "sip:+12125551212@ssp.example.net". The SSP may well
associate and route requests for "tel:+12125551212" to that AoR's
Registered contact, but in so doing it can be described as logically
performing a transformation of the TEL URI to a SIP URI and looking
up that SIP URI in its location service database.
Interestingly, the AoR that was implicitly Registered is globally
unique, *regardless* of the fact that the user portion happens to be
an E.164 number. It is globally unique, because the AoR is of the
domain "ssp.example.net" - just as any [RFC3261] SIP AoR is globally
unique due to its host domain portion.
3.2.2 Registered Contact Username
The other rational for needing a globally unique identifier is the
Registered Contact URI. Because the Martini model performs a bulk
Registration and uses a defined expansion rule for how to expand the
Registered Contact into a unique Contact URI per AoR, the rule's
output needs to be unambiguous and generate a unique Contact per
AoR. For example, if the IP-PBX has multiple SSPs it Registers
into, it can't just receive a request to
"sip:bob@pbx.enterprise.com", because it won't know if that's to
Kaplan Expires - October 2009 [Page 5]
Internet-Draft SIP MARTINI with OLIVE April 2010
"sip:bob@ssp1.example.net" or "sip:bob@ssp2.example.net", which may
be different users.
This is a real problem, but what it requires/needs is a globally
unique Contact URI, not a globally unique AoR user name. In fact,
[draft-gin] suffers from this problem as well, in some ways.
Although it is unambiguous what the target of the request may be
(because the username is globally unique), it still may be important
for the IP-PBX to know which implicitly Registered AoR the request
was resolved from, before being sent to it. For example, the IP-PBX
may want to know the request is for
"sip:+12125551212@ssp.example.net.uk" vs.
"sip:+12125551212@ssp.example.net.fr". The IP-PBX *would* have
Registered separately for each domain, but if its contact is the
same (and if it went through the same path, etc.), there would be no
unique identifier for inbound Requests.
This problem could be solved numerous ways. For one, this is a
similar issue to that solved by [RFC4244] or being worked on in
[draft-4244bis]. Secondly, and more importantly, the IP-PBX could
simply make the Contact unique by inserting a parameter in the
Contact URI it Registers, or inserting a Path header field with
unique information per Register target domain.
Regardless of the solution, it is solvable without impacting the
user portion of the AoR being implicitly Registered. Therefore,
there is no need to make the username portion globally unique, and
thus once again there is no need for [draft-gin] to only be used for
E.164 AoRs.
3.2.3 Avoiding syntax mismatches
Another issue with the Contact bulk-expansion rule and implicitly
Registering Contact URIs is guaranteeing the Registrar uses a
username the IP-PBX will accept/expect. In particular, there are
numerous syntactic forms a phone number can take in the user portion
of a SIP URI, for example with or without a leading "+", or with
visual-separators or not. Since the IP-PBX is not actually
Registering an explicit Contact URI user portion for each AoR, there
needs to be an assurance that the format of the expanded-to user
portion matches what it expects.
For Email-style URIs, this is actually quite straight-forward,
because there is only one form the user name can take: if the AoR is
"sip:bob@ssp.example.net", then a simple AoR-user-based expansion
rule would suffice because "bob" can only have one form. (e.g., even
case-sensitivity matters) Thus there is no syntax mismatch concern
for generic string names.
Kaplan Expires - October 2009 [Page 6]
Internet-Draft SIP MARTINI with OLIVE April 2010
Local-Numbers in TEL URIs, or SIP URIs formed from TEL URIs, are
more difficult, however. Like E.164 (i.e., global-number) formats,
they are not as well constrained. They may have visual-separators,
for example, and if their phone-context parameter value is a global-
number, it too has the same formatting "looseness" of E.164 number
user names.
To make matters worse, Local-Numbers are frequently NOT within the
scope of the SSP, or at least the SSP does not always have full
knowledge of all Local-Numbers it can route requests for.
This document will address this Local-Number issue, but for the case
of Local-Numbers scoped to the SSP's domain only. Local-Numbers
scoped to a phone-context that is an E.164 or not the same domain
name as the REGISTER transaction's explicit AoR are outside the
scope of this document.
This also remains an open issue for discussion, as discussed in
section 8.
4. The Solution - an Overview
The general concept proposed in this document is to simply apply
[draft-gin] for any set of AoRs of the Registered-to domain, for any
valid set of user strings as defined in [RFC3261]. The [draft-gin]
REGISTER request would cause the Registrar to populate the set of
AoRs to Contact bindings, as it did before.
The Contact URI user portion would also be "expanded", using the
same user portion as that of the implicitly Registered AoRs. In the
case of a Local-Number, for the specific scopes described later, the
username is "normalized" in the same manner as [draft-gin].
Note that the list of AoRs associated with a PBX is a matter of
local provisioning at the SSP and at the PBX, as it was in [draft-
gin]. 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 AoRs).
No new option-tag is required, because this document's mechanism
does not require any changes in Martini [draft-gin] Registration or
subsequent [RFC3261] routing behavior in the IP-PBX or any proxies
along the path. The routing follows the [RFC3261] Registered AoR-
contact resolution model, which is a basic function of SIP.
The only SIP devices affected by this document's mechanism is the
SSP's Registrar, which needs to update the appropriate AoR entries,
and any proxy/ies of the SSP which perform route resolution by
Kaplan Expires - October 2009 [Page 7]
Internet-Draft SIP MARTINI with OLIVE April 2010
looking up the contents of the (logical) location-service database.
Since such proxies may not even be in the path of the REGISTER
request, an option-tag will not help. And since the Registrar and
Proxies in question are all under control of the same administrative
entity (the SSP), it is reasonable to expect them all to support
this document's mechanism, if any do.
5. Registering for AoRs
This document's mechanism relies on the Martini [draft-gin]
Registration mechanism. The IP-PBX Registers into the SSP, using a
REGISTER request with the [draft-gin] option-tag in the Require and
Proxy-Require header fields, and a Contact URI containing the
[draft-gin] "bnc" URI parameter and no user portion. After the PBX
is authenticated, the registrar updates its location service so that
each of the AoRs 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:bob@ssp.example.com"), and the corresponding Contact will be
formed adding a user portion to the REGISTER's Contact URI
containing the AoR user name and removing the "bnc" parameter. For
example, if the "Contact" header field contains the URI
<sip:198.51.100.3:5060;foo=bar;bnc>, then the Contact value
associated with the aforementioned AOR will be
<sip:bob@198.51.100.3:5060;foo=bar>.
Local-Numbers have slightly different Contact URI expansion rules,
as defined later.
As in [draft-gin], aside from the "bnc" parameter, all URI
parameters present in the "Contact" URI in the REGISTER message MUST
be copied to the Contact value stored in the location service.
Note that the location service database, and any entry model
described here, is purely an abstract concept used by [RFC3261],
[draft-gin], and this document; an actual implementation may do
whatever it likes internally, so long as the external behavior
follows the model. For example, if an SSP does not maintain any
specific knowledge of the Local Number dial-plan, but simply
performs prefix or default routing for an Enterprise's private
extensions, the SSP could just route based on the E.164 phone-
context field value without having a separate physical "AoR"
database entry for each local number of that context.
Kaplan Expires - October 2009 [Page 8]
Internet-Draft SIP MARTINI with OLIVE April 2010
5.1. Registering Local Number AoRs
Local-Numbers present a complexity for AoR Registration, because
their user portion is scoped to the phone-context's value. In
practice the SSP domain identified by the entire AoR URI domain name
may not have specific knowledge of any user name within a given
phone-context's scope. In fact, the Local-Number TEL URI parameters
(which are URI user parameters in SIP URIs), likely only have
meaning to the ultimate target of the request, or some entity which
is authoritative for the phone-context's user names. Those
parameters cannot be removed by the SSP if it does not actually
process the user portions of the Local-Number. (i.e., if it does not
have the dial-plan, etc.)
With regard to this document's mechanism, what this means is that
such an SSP cannot physically instantiate an AoR in a database for
every possible Local-Number and cannot physically instantiate an
expanded Contact URI for every possible Local-Number user name with
every possible user parameter. That does not inhibit the mechanism
from working or being usable, however, because the location-service
database model is purely an abstract concept. What's important is
that the route-resolving Proxy be able to lookup and replace an AoR
it is authoritative for, to a Registered Contact URI, such that the
resultant Request URI matches what the IP-PBX expects to receive.
It is "safe" to do this because the explicitly Registered Contact
URI of the [draft-gin] REGISTER request had no user portion, and
thus no possible URI user parameters. As defined in [draft-gin],
the Contact URI parameters of the REGISTER are saved and reused, but
not URI user parameters.
There are multiple ways of describing the logical AoR instantiation
and Contact URI expansion rules. They could be described as
covering every possible ABNF expansion, such that every possible
user and parameter logically exists in the location-service database
(but obviously not physically exists). Or it could be described as
only the phone-context value itself being an "AoR" entry and Contact
URI expansion, with a policy to allow any and all user names and
parameters to be copied instead of replaced by the Contact URI.
This remains an open issue for discussion, as discussed in section
8.
Regardless, for an implicitly Registered SIP AoR with a URI user
portion matching the syntax outlined for "local-number" TEL URIs in
[RFC3966]: if the 'phone-context' URI user parameter value is the
same SSP domain as that in the REGISTER transaction's To URI, then
Contact is then formed following the other AoR models, EXCEPT that
Kaplan Expires - October 2009 [Page 9]
Internet-Draft SIP MARTINI with OLIVE April 2010
all URI user parameters are also included, other than the phone-
context parameter. For example, if the logically provisioned "AoR"
from the previous examples were: "sip:12345;ext=678;phone-
context=ssp.example.net@ssp.example.net", it would logically get an
automatically generated Contact URI of
<sip:12345;ext=678@198.51.100.3:5060;foo=bar>.
Note that in practice it is not uncommon to receive a SIP URI which
does not strictly comply with the formatting rules of [RFC3966], but
is processed as if it were, based on local policies. That is legal,
of course, but from a logical perspective the SIP URI is actually
retargeted or transformed into the syntactically valid form
following [RFC3966], and that form MUST be the one used for routing,
Contact URI expansions, etc. Likewise, if the URI were a TEL URI,
it would be logically transformed into a SIP URI of the SSP's domain
before executing the rules.
6. SSP Processing of Inbound Non-E.164 Requests
The SSP Proxy/Registrar (or equivalent entity) performs traditional
Proxy/Registrar behavior, based on the mapping described in Section
5 and [draft-gin]. For Local-Numbers in particular, the following
section provides additional detail.
6.1. Processing of Local-Number Requests
As discussed in section 5.1, Local-Numbers present a special case
which may need to be handled with more explicit rules than [RFC3261]
or [draft-gin] currently prescribe. If the location-service
database is described as having every possible expansion, then the
Request would be processed in the same manner as section 5 and
[draft-gin].
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)
The GRUU mechanism for this document's mechanism works exactly the
same way as defined in [draft-gin]. The [draft-gin] GRUU mechanism
Kaplan Expires - October 2009 [Page 10]
Internet-Draft SIP MARTINI with OLIVE April 2010
has no dependency on the global uniqueness of the AoR username, nor
on being digits or an E.164.
7.2. Registration Event Package
The Registration Event Packet behavior for this document's mechanism
works exactly the same way as defined in [draft-gin]. The [draft-
gin] reg-event model has no dependency on the global uniqueness of
the AoR username, nor on being digits or an E.164.
There is, however, an issue for Local-Numbers, if the SSP does not
actually know the full list of Local-Number user names in the given
phone-context scope. In such a case, it is TBD for how to handle
this. One obvious way would be to define a syntactic format for the
AoR and Contact URIs which only includes the phone-context value and
makes it clear the user portion and any other parameters are
unknown, such as "sip:!.*!;phone-
context=ssp.example.com@ssp.example.com". Since a "!" is not a
legal character in a Local-Number user name, but is legal in a SIP
URI user name, it would be both ABNF compliant and unambiguous from
Local-Numbers.
This remains an open issue for discussion, as discussed in section
8.
7.3. Non-Adjacent Contact Registration (Path) and Service Route
Discovery
The Path and Service-Route behavior and considerations for this
document's mechanism are exactly the same as defined in [draft-gin].
The [draft-gin] Path and Service-Route model has no dependency on
the global uniqueness of the AoR username, nor on being digits or an
E.164.
8. Open Issues
This document has several open issues, which were noted previously.
They center around the handling of Local-Numbers. Local-Numbers are
difficult because they are doubly-scoped: once at the URI level by
the domain name, and internally by the phone-context URI user
parameter. The authoritative system for the Local-Number user
portion (the system(s) which knows what they are and how to process
them) is not identified by the URI's domain name, but rather
identified by the phone-context's value.
If the phone-context identifies the SSP domain, all's well - but
that's rarely the case. More likely is that it identifies an E.164
number, or a sub-domain of the SSP, or another domain entirely.
Kaplan Expires - October 2009 [Page 11]
Internet-Draft SIP MARTINI with OLIVE April 2010
This document tries to propose a mechanism to support the case when
the phone-context identifies the SSP's domain, and which has a
matching SIP AoR implicitly Registered by the IP-PBX. However, even
in such a case, it does not imply the SSP has authoritative
information for the user name - typically the IP-PBX does. This
causes issues with certain functions such as the reg-event package.
In theory, this can probably be made to work as defined in this
document, but there is an alternative: if we had a model for using
the Registered reachability information of [draft-gin] for routing
of requests which are not AoRs of the Registered-to domain (e.g., to
an AoR of "sip:charlie@pbx.example.com"), then Local-Numbers could
follow that routing model instead. This would follow a more natural
[RFC3263] model, since effectively the phone-context indicates that
the authoritative administrative entity is not in fact the SSP.
A draft detailing how [draft-gin] can be used in such a model is
forthcoming.
9. 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.
9.1. Usage Scenario: Basic Registration case 1
This example shows a basic bulk REGISTER transaction, followed by an
INVITE addressed to one of the registered terminals.
Internet SSP PBX
| | |
| |REGISTER |
| |Contact:<sip:198.51.100.3;bnc> |
| |<--------------------------------|
| | |
| |200 OK |
| |-------------------------------->|
| | |
|INVITE | |
|sip:bob@ssp.example.com | |
|------------------------------->| |
| | |
| |INVITE |
| |sip:bob@198.51.100.3 |
| |-------------------------------->|
Kaplan Expires - October 2009 [Page 12]
Internet-Draft SIP MARTINI with OLIVE April 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
Contact: <sip:198.51.100.3:5060;user=phone;bnc>
Expires: 7200
Content-Length: 0
INVITE sip:bob@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:alice@rabbithole.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:bob@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:alice@rabbithole.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>
Kaplan Expires - October 2009 [Page 13]
Internet-Draft SIP MARTINI with OLIVE April 2010
9.2. Usage Scenario: Basic Registration case 2
This example shows a basic bulk REGISTER transaction, followed by an
INVITE addressed to one of the registered terminals, for a Local-
Number AoR.
Internet SSP PBX
| | |
| |REGISTER |
| |Contact:<sip:198.51.10.3;f=b;bnc>|
| |<--------------------------------|
| | |
| |200 OK |
| |-------------------------------->|
| | |
|INVITE | |
|sip:1234;ext=678 | |
| ; ssp.example.com | |
| @ssp.example.com | |
|------------------------------->| |
| | |
| |INVITE |
| |sip:1234;ext=678 |
| | @198.51.100.3;f=b |
| |-------------------------------->|
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.10.3:5060;f=b;bnc>
Expires: 7200
Content-Length: 0
Kaplan Expires - October 2009 [Page 14]
Internet-Draft SIP MARTINI with OLIVE April 2010
INVITE sip:1234;ext=678;phone-context=ssp.example.com
@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:alice@rabbithole.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:1234;ext=678@198.51.100.3;f=b 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:alice@rabbithole.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>
10. IANA Considerations
This document makes no request of IANA.
11. Security Considerations
This section is still TBD, but it should follow/have the same issues
as [draft-gin].
12. Acknowledgements
Thanks to Adam Roach for (unknowingly) providing text which I
stole^M^M^M copied from [draft-gin].
Kaplan Expires - October 2009 [Page 15]
Internet-Draft SIP MARTINI with OLIVE April 2010
13. 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.
[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.
[RFC4244] Barnes, M. (ed.), "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC
4244, November 2005.
[RFC5486] Malas, D., and Meyer, D., "Session Peering for Multimedia
Interconnect (SPEERMINT) Terminology", RFC 5486, March
2009.
[draft-gin] Roach, A. B., "Registration for Multiple Phone Numbers
in the Session Initiation Protocol (SIP)", draft-ietf-
martini-gin-00, March 2010.
[draft-4244bis] Barnes, M., et al, "An Extension to the Session
Initiation Protocol (SIP) for Request History
Information", draft-ietf-sipcore-rfc4244bis-00, February
2010.
Kaplan Expires - October 2009 [Page 16]
Internet-Draft SIP MARTINI with OLIVE April 2010
Author's Address
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803, USA
Email: hkaplan@acmepacket.com
Kaplan Expires - October 2009 [Page 17]