MARTINI WG A. B. Roach
Internet-Draft Tekelec
Intended status: Standards Track January 6, 2010
Expires: July 10, 2010
A Unified Proposal for Multiple AOR Registrations in the Session
Initiation Protocol (SIP)
draft-roach-martini-up-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 July 10, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
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.
Abstract
This document contains a unified proposal for solving the problems
related to providing dynamic SIP routing information for multiple
Roach Expires July 10, 2010 [Page 1]
Internet-Draft SIP HTTP Subscriptions January 2010
AORs with a single SIP transaction. The proposed solution is
designed to work both for subsets of URIs within a domain, and for
entire domains.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Publisher Behavior . . . . . . . . . . . . . . . . . . . . 4
4.2. Dynamic Routing Server Behavior . . . . . . . . . . . . . 5
5. Alternate Body Type for 'reg' Event Package . . . . . . . . . 5
6. Body Type for Indication of Allowed URIs . . . . . . . . . . . 8
7. Comparison of Simple Regular Expressions . . . . . . . . . . . 8
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Range of E.164 numbers . . . . . . . . . . . . . . . . . . 10
8.2. Entire Domain . . . . . . . . . . . . . . . . . . . . . . 10
8.3. Many Discrete AORs . . . . . . . . . . . . . . . . . . . . 11
9. Issues Solved . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Roach Expires July 10, 2010 [Page 2]
Internet-Draft SIP HTTP Subscriptions January 2010
1. Introduction
One of SIP's primary functions is providing rendezvous between users.
By design, this rendezvous has been provided through a combination of
the server look-up procedures defined in RFC 3263 [2], and the
registrar procedures described in RFC 3261 [1].
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.
In actual deployments, some SIP servers have been deployed in
architectures that, for various reasons, have requirements to provide
dynamic routing information for large blocks of AORs, where all of
the AORs in the block were to be handled by the same server. For
purposes of efficiency, many of these deployments do not wish to
maintain separate registrations for each of the AORs in the block.
This leads to the desire for an alternate mechanism for providing
dynamic routing information for blocks of AORs.
Because this problem has certain similarities with the REGISTER
operation, several non-standard, ad hoc extensions to REGISTER have
been developed to address this desire. The document "SIP IP-PBX
Registration Problems" [8] describes several deployed IP PBX
registration techniques, along with a number of problems that arise
from the approaches that have been implemented to date.
It should be noted that the similarities between bulk AOR dynamic
routability and the REGISTER operation are somewhat superficial. In
particular, with a REGISTER request, a UAC is establishing a binding
for a single user. Intermediaries (between the UAC and the
registrar) can make decisions about how to treat the request based on
the identity of that user. Extending the REGISTER method to operate
outside of this model -- as has been done by the ad hoc solutions
mentioned earlier -- can cause issues at such intermediaries that
assume the standard SIP registration model.
2. Terminology
This document uses the terms defined in section 2 of "SIP IP-PBX
Registration Problems" [8].
Roach Expires July 10, 2010 [Page 3]
Internet-Draft SIP HTTP Subscriptions January 2010
3. Mechanism Overview
The mechanism defined in this document takes advantage of the
observation that there are already two defined means for accessing
the Location Service Database defined by RFC 3261: the REGISTER
mechanism (also defined by RFC 3261) as well as the SIP Registrations
Event Package, defined in RFC 3680 [4]. Of these two mechanisms,
REGISTER is designed to operate on a single AOR at a time. By
contrast, the SIP Registrations Event Package was fundamentally
designed to carry registration information for potentially several
AORs simultaneously. This makes it a near perfect match for the
problem of maintaining dynamic routing information for multiple AORs.
Consumers of state information for event packages make use of the
SUBSCRIBE and NOTIFY methods, defined in RFC 3265 [3], to receive
updates whenever the state changes. Similarly, producers of state
information for event packages can use the PUBLISH method, defined in
RFC 3903 [5], to inform the network when state has been updated.
Based on the foregoing, we define a procedure whereby the node
responsible for registering dynamic routing information for several
AORs uses a PUBLISH request with the 'reg' event package. This
PUBLISH request indicates the AORs the dynamic routing information
applies to, as well as the routing URI associated with each AOR.
While the XML body defined in RFC 3680 is semantically suitable for
this use, it is somewhat cumbersome in practice to use for, e.g.,
large contiguous blocks of numbers. For example, if a PBX were
responsible for a block of 10,000 E.164-addressed endpoints, it would
require a application/reginfo+xml document containing 10,000
individual <registration> elements. To address this issue, we
propose an alternate body type for the 'reg' event package, which
allows for concise expression of this kind of AOR aggregation. This
alternate body type is described in Section 5.
4. Protocol
In general, the behavior for the elements involved in maintaining
dynamic routing information is that defined for maintaining event
state with the PUBLISH request, as described in RFC 3903. Behavior
specific to this specification is described below.
4.1. Publisher Behavior
This section describes behavior for the UAC responsible for
maintaining dynamic routing information. Note that this may or may
not be the element that the AORs will be associated with (such as an
Roach Expires July 10, 2010 [Page 4]
Internet-Draft SIP HTTP Subscriptions January 2010
IP PBX or a PSTN gateway) -- it might be an arbitrary third party
responsible for advertising dynamic routes associated with groups of
AORs.
To advertise a dynamic route associated with an AOR, the publisher
sends a PUBLISH request to the dynamic routing server. This PUBLISH
contains a body that conveys the AORs for which dynamic routing
information is being conveyed. This body may use either the
application/reginfo+xml format defined by RFC 3680, or using the
compact format defined in Section 5.
A successful (200-class) response to the PUBLISH indicates to the
publisher that the AOR dynamic routes have been successfully updated.
Any failure response indicates that none of the routes have been
accepted. If the failure response code is "403," then the body of
the response will contain a document indicating the AORs that the
publisher is authorized to provide dynamic routing information for.
This document is in the format described in Section 6.
4.2. Dynamic Routing Server Behavior
When a Dynamic Routing Server (such as a proxy/registrar found within
an SSP) receives a PUBLISH request for for the 'reg' event package,
it first authenticates the sending entity. This authentication may
be via Digest authentication, mutual TLS authentication, or some
other mechanism. After the sender is authenticated, the Dynamic
Routing Server validates the body of the PUBLISH request, by making
certain that the entries present are syntactically valid, complete,
and within any applicable policies. It then updates its local
routing tables with the information present in the body.
The Dynamic Routing Server applies the rules defined in Section 7 to
determine whether the requested AORs are within the set of AORs that
the publisher is authorized to provide routing information for.
Semantically, updating the local routing tables is identical to
updating a Location Service database (as RFC 3261 defines that term).
After updating its local routing tables with the information present
in the PUBLISH message, it responds to the PUBLISH request with a 200
(OK) response.
5. Alternate Body Type for 'reg' Event Package
To allow for compact specification of several AORs in a single "reg"
event package body, we define a new MIME body type. This MIME type
is designated "application/reginfo-bulk." Except as noted, the
Roach Expires July 10, 2010 [Page 5]
Internet-Draft SIP HTTP Subscriptions January 2010
meaning of the fields in this MIME body are identical to the fields
defined in RFC 3680. If omitted, the "state" field is assumed to
have the value of "active," and the "expires" field is assumed to be
identical to the "Expires" header value in the PUBLISH message
header.
This body is specified using the ABNF format defined in RFC 5234 [6].
reginfo-bulk-body = version HTAB doc-state CR *reginfo-bulk-entry
reginfo-bulk-entry = delim-char simple-regex delim-char contact
delim-char HTAB id HTAB event
[ HTAB state [ HTAB expires
[ HTAB [ qvalue ] [ HTAB [ retry-after ]
[ HTAB [ callid ] [ HTAB [ cseq ]
[ HTAB [ duration-reg]
[ HTAB [ unknown-params ]
[ HTAB display-name ] ] ] ] ] ] ] ] ] CR
version = 1 * DIGIT
doc-state = "full" / "partial"
delim-char = "/" / "!" / ... <Any non-digit or non-flag
character other than backslash '\'. All
occurances of a delim_char in a
reginfo-bulk-entry must be the same
character.>
utf8-display-str = * ( %x20-7F /
( %xC2-DF %x80-BF ) /
( %xE0-EF 2 ( %x80-BF ) ) /
( %xF0-F4 3 ( %x80-BF ) ) )
simple-regex = 1 * ( OCTET )
contact = 1 * ( OCTET / backref )
backref = "\" %x31-39
id = display-char
event = "registered" / "created" / "refreshed" /
"shortened" / "expired" / "deactivated" /
"probation" / "unregistered" / "rejected"
state = "init" / "active" / "terminated"
expires = 1 * DIGIT
qvalue = "1.0" / ( "0." 1*4 DIGIT)
retry-after = 1 * DIGIT
callid = 1 * VCHAR
cseq = 1 * DIGIT
duration-reg = 1 * DIGIT
unknown-params = 1 * VCHAR
display-name = utf8-display-str
The "simple-regex" field is used to indicate one or more AORs to
which the entry applies, and the "contact" field indicates the
Roach Expires July 10, 2010 [Page 6]
Internet-Draft SIP HTTP Subscriptions January 2010
routing information to be associated with the AORs that are matched
by the entry. The "simple-regex" is similar in spirit to POSIX
regular expressions (as defined in IEEE 1003-2 [7]). However, to
allow for trivial comparison between requested AORs and allowed AORs,
the syntax is intentionally very limited.
Characters in the simple-regex have the following properties:
o The regex characters "(" and ")" are used to indicate sections of
the matched string that can be used for backrefs. They are
ignored for the purposes of matching.
o The regex character "\" is used to escape the immediately
following character. Instead of taking its normal meaning, the
character simply matches itself. This includes the ability to
escape the delim-char.
o The regex sequence "[" followed by one or more characters and "]"
matches any of the characters between the "[" and "]" symbols.
o The regex character "." matches any character.
o The regex sequence "{" followed by one or more digits and "}"
indicates that the preceding character must be repeated exactly
the number of times indicated by the digit.
o As a special case, if a simple regex contains an "@" character,
then the portion of the regex preceding the first "@" character
may use the character "*" to mean "zero or more instances of the
preceding character." However, Dynamic Routing Servers MUST NOT
accept regular expressions of this format unless their policy
allows the authenticated publisher to control the routing of all
requests for the domain on the right-hand-side of the "@"
character. An unescaped "*" character after the first "@"
character in the simple regex is a syntax error.
o As with normal regular expressions, any other character matches
itself.
The simple regexes defined in this document must match a string in
its entirety -- that is, the matching string may not contain any
leading or trailing characters. For example, the simple regex
"x...y" would not match the string "axabcy," since the leading "a" is
not represented in the simple regex.
The preceding rules are carefully crafted to allow trivial expansion
of all simple regexes to a complete, exhaustive list of strings that
the regex can possibly match. In particular, they intentionally omit
Roach Expires July 10, 2010 [Page 7]
Internet-Draft SIP HTTP Subscriptions January 2010
the ability to indicate an arbitrary number of characters, as with
the POSIX regex "*" character (except in the special case of domain
registration).
OPEN ISSUE: we can achieve the same property even if we include
ranges of characters -- e.g., ".{2,4}" -- with a moderate increase in
the complexity of the operation. Do we want to do this?
The "contact" field contains a URI that the Location Service should
associate with the AOR. The "contact" field in this document format
may contain backref expressions of the form "\1" through "\9". If
present, these are replaced by the string of characters enclosed by
"(" and ")" in the simple regex portion of the reginfo-bulk-entry.
The string "\1" matches the first backref expression in the simple
regex (i.e., the one starting with the first parenthesis); the string
"\2" matches the second; and so on. For example, the simple regex:
(A(B(C)DE)(F)G)
has backref expressions:
\1 = ABCDEFG
\2 = BCDE
\3 = C
\4 = F
\5..\9 = error - no matching subexpression
6. Body Type for Indication of Allowed URIs
This needs more fleshing out. Basically, the format is a list of
simple-regexes that indicate which AORs the authenticated publisher
is authorized to provide routing information for.
reginfo-err-body = 1 * ( simple-regex CR )
7. Comparison of Simple Regular Expressions
In order to make policy decisions, a Dynamic Routing Server must be
able to trivially examine the simple regexes provided in a
application/reginfo-bulk body and determine whether they are a proper
subset of the AORs the publisher is authorized to publish.
To determine whether a first simple regex (e.g., from a publisher) is
a subset of second simple regex (e.g., a policy rule at a Dynamic
Routing Server), a server performs the following processing:
Roach Expires July 10, 2010 [Page 8]
Internet-Draft SIP HTTP Subscriptions January 2010
1. All unescaped instances of "(" and ")" are discarded from both
expressions.
2. All unescaped sequences of "{" followed by one or more digits
followed by "}" are expanded by repeating the preceding character
the number of times indicated by the digits (treating any
sequence of "[" .. "]" as a single character).
3. The two expressions are then compared character-by-character
(again treating any sequence of "[" .. "]" as a single
character), checking that each character in the first expression
is a subset of the corresponding character in the second
expression, using the following rules for determining subsets:
* An unescaped "." character is a subset only of an unescaped
character ".".
* A bracketed sequence is a subset of another bracketed sequence
containing the same list of characters (and potentially
others), or an unescaped character ".".
* Any other character is a subset of itself, a bracketed
sequence containing itself, or an unescaped character ".".
4. As a special case: if the first expression contains an unescaped
"*" character preceding the first "@" character in the
expression, then it is can only be a subset of a second
expression beginning with the character sequence ".*@". If the
second expression begins with ".*@", then the first expression is
a subset of the second expression if and only if the portion of
the first expression following the first "@" character is a
subset of the portion of the second expression following its
first "@" character (as determined by the foregoing rules).
The Dynamic Routing Server communicates policy regarding allowed AORs
using the format defined in Section 6. The matching steps defined
above are performed pairwise on each of the requested AORs (from the
publisher) and the allowed AORs (from the Dynamic Routing Server
policy). If each of the requested AORs are subsets of at least one
of the allowed AORs, then the request is within policy. Otherwise,
the request exceeds the authorization granted to the publisher, and
the Dynamic Routing Server MUST reject the PUBLISH with a 403
response.
Roach Expires July 10, 2010 [Page 9]
Internet-Draft SIP HTTP Subscriptions January 2010
8. Examples
Note that, for the sake of readability, these examples use sequences
of spaces instead of VTAB characters to delimit fields.
8.1. Range of E.164 numbers
The following request registers the sequence of E.164 numbers from
+12143290000@example.com through +12143290999@example.com. It
associates the AOR "sip:+12143290000@example.com" with the Contact
"sip:0000@pbx.example.net," the AOR "sip:+12143290001@example.com"
with the Contact "sip:0001@pbx.example.net," and so on.
PUBLISH sip:company@routing-server.example.com SIP/2.0
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
From: sip:pbx.example.com;tag=xyzygg
To: sip:company@routing-server.example.com
Call-ID: 9987@app.example.com
CSeq: 1288 PUBLISH
Max-Forwards: 70
Expires: 3600
Event: reg
Content-Type: application/reginfo-bulk
Content-Length: ...
1 full
/sip:+1214329(0...)@example.com/sip:\1@pbx.example.net/ 14 registered
8.2. Entire Domain
The following request associates all URIs in the domain "example.net"
with the IP address "192.0.2.5".
PUBLISH sip:company@routing-server.example.com SIP/2.0
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
From: sip:pbx.example.com;tag=xyzygg
To: sip:routing-server.example.com
Call-ID: 9987@app.example.com
CSeq: 1288 PUBLISH
Max-Forwards: 70
Expires: 3600
Event: reg
Content-Type: application/reginfo-bulk
Content-Length: ...
1 full
/sip:(.*)@example.net/sip:\1@192.0.2.5/ 14 registered
Roach Expires July 10, 2010 [Page 10]
Internet-Draft SIP HTTP Subscriptions January 2010
8.3. Many Discrete AORs
The following request associates several named URIs with the a set of
named URIs.
PUBLISH sip:company@routing-server.example.com SIP/2.0
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
From: sip:pbx.example.com;tag=xyzygg
To: sip:company@routing-server.example.com
Call-ID: 9987@app.example.com
CSeq: 1288 PUBLISH
Max-Forwards: 70
Expires: 3600
Event: reg
Content-Type: application/reginfo-bulk
Content-Length: ...
1 full
/sip:fsmith@example.net/sip:fsmith@192.0.2.5/ 1 registered
/sip:zjohnson@example.net/sip:zjohnson@192.0.2.5/ 2 registered
/sip:lwilliams@example.net/sip:lwilliams@192.0.2.5/ 3 registered
/sip:fjones@example.net/sip:fjones@192.0.2.5/ 4 registered
/sip:tbrown@example.net/sip:tbrown@192.0.2.5/ 5 registered
/sip:qdavis@example.net/sip:qdavis@192.0.2.5/ 6 registered
/sip:imiller@example.net/sip:imiller@192.0.2.5/ 7 registered
/sip:vwilson@example.net/sip:vwilson@192.0.2.5/ 8 registered
/sip:gmoore@example.net/sip:gmoore@192.0.2.5/ 9 registered
/sip:ataylor@example.net/sip:ataylor@192.0.2.5/ 10 registered
/sip:randerson@example.net/sip:randerson@192.0.2.5/ 11 registered
/sip:bthomas@example.net/sip:bthomas@192.0.2.5/ 12 registered
/sip:qjackson@example.net/sip:qjackson@192.0.2.5/ 13 registered
/sip:pwhite@example.net/sip:pwhite@192.0.2.5/ 14 registered
/sip:wharris@example.net/sip:wharris@192.0.2.5/ 15 registered
/sip:wmartin@example.net/sip:wmartin@192.0.2.5/ 16 registered
9. Issues Solved
The document "SIP IP-PBX Registration Problems" [8] 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.
No Explicit Indicator: The mechanism in this document cannot be
confused with the normal registration mechanism defined in RFC
3261, as it does not attempt to overload REGISTER to convey bulk
dynamic routing information.
Roach Expires July 10, 2010 [Page 11]
Internet-Draft SIP HTTP Subscriptions January 2010
Undefined Behavior on PAU Mismatch: By shifting the task of
specifying the AORs being registered from the server to the
client, there is no opportunity for mismatch. Policy errors may
arise when the client attempts to register for AORs other than
those it is authorized to register; however, procedures for
detecting and addressing these conditions are provided.
REGISTER Response Growth: By shifting the task of specifying the
AORs being registered from the server to the client, normal
response size is maintained. Circumstances under which a UDP
response is required, but size precludes sending a response, are
precluded.
Illegal Wildcarding Syntax: By defining a wildcarding syntax outside
the strictures of SIP, the issue of valid SIP syntax is
sidestepped.
Loss of Target Info: Because the binding from AOR to Contact URI is
under complete 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.
Request-URI vs. Loose-Route Mismatches: As before: because the
binding from AOR to Contact URI is under complete 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.
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.
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.
Roach Expires July 10, 2010 [Page 12]
Internet-Draft SIP HTTP Subscriptions January 2010
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.
10. References
10.1. Normative References
[1] 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.
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[4] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[5] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[7] Institute of Electrical and Electronics Engineers, "Information
Technology - Portable Operating System Interface (POSIX) - Part
2: Shell and Utilities (Vol. 1)", IEEE Standard 1003.2, 1992.
10.2. Informative References
[8] Kaplan, H., "SIP IP-PBX Registration Problems",
draft-kaplan-martini-mixing-problems-00 (work in progress),
December 2009.
Roach Expires July 10, 2010 [Page 13]
Internet-Draft SIP HTTP Subscriptions January 2010
Author's Address
Adam Roach
Tekelec
17210 Campbell Rd.
Suite 250
Dallas, TX 75252
US
Email: adam@nostrum.com
Roach Expires July 10, 2010 [Page 14]