A Unified Proposal for Multiple AOR Registrations in the Session Initiation Protocol (SIP)

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 , and the registrar procedures described in RFC 3261 . 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" 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.

This document uses the terms defined in section 2 of "SIP IP-PBX Registration Problems" .

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 . 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 , to receive updates whenever the state changes. Similarly, producers of state information for event packages can use the PUBLISH method, defined in RFC 3903 , 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 .

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.

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 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 . 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 .

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 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.

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 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 .

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 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 ). 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: 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. 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. The regex sequence "[" followed by one or more characters and "]" matches any of the characters between the "[" and "]" symbols. The regex character "." matches any character. 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. 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. 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 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:

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.

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: All unescaped instances of "(" and ")" are discarded from both expressions. 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). 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 ".". 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 . 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.

Note that, for the sake of readability, these examples use sequences of spaces instead of VTAB characters to delimit fields.

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.

The following request associates all URIs in the domain "example.net" with the IP address "192.0.2.5".

The following request associates several named URIs with the a set of named URIs.

The document "SIP IP-PBX Registration 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. 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. 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. 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. By defining a wildcarding syntax outside the strictures of SIP, the issue of valid SIP syntax is sidestepped. 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. 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. 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. 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. 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.