MARTINI WG H. Kaplan Internet Draft Acme Packet Intended status: Standards-Track Expires: November 3, 2011 May 3, 2010 SIP MARTINI Variant of 'Event-package for Registrations' for Managed Open-ended Username Target Handling (VERMOUTH) draft-kaplan-martini-vermouth-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 November 3, 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 November 18, 2010 [Page 1] Internet-Draft SIP MARTINI VERMOUTH May 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, in [draft-gin]. Another draft [draft-olive] proposes the same for non-E.164-based AoRs. This document defines a variant of the Registration Event-package [reg-event] for open-ended AoRs for either mechanisms, using a wildcard syntax and specific target handling rules. Table of Contents 1. Introduction................................................2 2. Definitions.................................................3 3. The Solution - an Overview..................................4 4. The Bulk-AoR................................................5 4.1. Bulk-AoR ABNF Rules.....................................5 4.2. Restrictions of Use.....................................6 5. Subscribing for Registration State Resources................6 5.1. Subscribing to AoRs.....................................7 5.2. Subscribing to state in the IP-PBX......................8 5.3. Subscribing for all implicitly registered AoRs..........8 5.4. Subscribing to a Bulk-AoR...............................9 6. Event Package registration information......................9 6.1. Constructing Bulk-AoR registration elements.............9 6.2. Processing Bulk-AoR registration elements..............10 7. Examples...................................................10 7.1. Example XML document...................................10 7.2. Usage Scenario: Subscribing to an AoR..................11 7.3. Usage Scenario: Subscribing to the AoRs off the IP-PBX.13 7.4. Usage Scenario: Subscribing to all AoRs................16 8. IANA Considerations........................................17 9. Security Considerations....................................17 10. Normative References.......................................18 11. Informative References.....................................18 Author's Address.................................................18 Appendix A - Rationale for Constraining the Expansion Pattern....19 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]. Another draft, [draft-olive] uses the [draft-gin] Martini mechanism for non-E.164 AoRs as well. Kaplan Expires - November 2009 [Page 2] Internet-Draft SIP MARTINI VERMOUTH May 2010 In both cases, the IP-PBX or other entity may wish to Subscribe to the Registration Event Package based on [RFC3680] for the Registration state information of the AoRs Registered by the [draft- gin] REGISTER transactions. For example, the IP-PBX may wish to learn about all of the AoRs which were implicitly Registered by [draft-gin] or [draft-olive], or to learn about changes in their provisioning. In theory, the [draft-gin] mechanism is simply a short-hand single REGISTER transaction for a bulk set of AoRs in lieu of multiple, separate REGISTER transactions for each AoR. In practice, however, the E.164 user numbers may be an "open" numbering plan/range, such that the SSP only really knows about a certain number of digits and the rest are only known to the IP-PBX. Likewise, when [draft-olive] is used, the Local-Number may be only partially known to the SSP. Therefore, it is not possible for the SSP to actually provide state information for each possible unique AoR instance. Instead, it needs to provide an indication for the registration state of the prefix or digit portion it does know about. This document proposes to provide such information using an agreed upon URI format: a "Bulk-AoR", which follows a specific AoR syntax indicating the number range, and is formatted such that it can be reasonably reserved for such use. This document also defines the rules for targeting SUBSCRIBE requests to reach specific resources for registration state information. 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.). Bulk-AoR: a SIP or SIPS address-of-record with a "range" URI user parameter which expands the user string based on a heuristic. 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. Kaplan Expires - November 2009 [Page 3] Internet-Draft SIP MARTINI VERMOUTH May 2010 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. The Solution - an Overview To handle the open-numbering-plan problem, the concept proposed in this document is to specify a specific URI syntax which is legal in SIP ABNF grammar, but highly unlikely to exist for anything but this document's purpose, by defining a new URI user parameter. This creates a "Bulk-AoR" URI, which is treated as any other AoR URI from the perspective of [RFC3680]. The specific Bulk-AoR format is similar but not identical to the "Wildcarded" AoR syntax already in use in certain deployments. The Bulk-AoR format is "sip:;range=@", where "" is similar to a regular expression pattern but has a very limited, specified syntax. The limited syntax is used to avoid ambiguities, make it compliant with [RFC3261] ABNF rules, and reduce confusion - rationale for this is provided in Appendix A. [Open issue: should a new URI parameter similar to "user=phone" be defined for such an AoR type?] Furthermore, this document assumes that the SSP's Registrar processes Subscriptions for the "reg" event package following [RFC3680], and thus that a SUBSCRIBE targeted to any of the implicitly Registered AoRs be processed by the SSP (not the IP-PBX). This document also provides a means, however, to Subscribe for the registration state for those same AoRs in the IP-PBX itself, by using the "bnc" parameter in the SUBSCRIBE target URI. Lastly, this document specifies that the To-URI used for the [draft- gin] REGISTER request, be usable as the target for the SUBSCRIBE request, for Subscribing to the registration event information for all implicitly registered AoRs of the [draft-gin] mechanism, any or all of which may be encoded using the Bulk-AoR syntax proposed in this document. Kaplan Expires - November 2009 [Page 4] Internet-Draft SIP MARTINI VERMOUTH May 2010 The Registration Event Packet behavior for this document's mechanism works exactly the same way as defined in [RFC3680]. This document does not update [RFC3680] or change its semantics. The only "changes" discussed in this document are (1) details of how to target a SUBSCRIBE for specific Registration state information resources in section 5, and (2) explanations about reginfo XML documents with Bulk-AoRs in section 6. Neither of these substantively changes [RFC3680] behavior. 4. The Bulk-AoR A "Bulk-AoR" is a SIP or SIPS URI Address-of-record containing a new URI user parameter named "range". The range parameter expands the user portion based on a specific heuristic, when the Bulk-AoR is processed by a SIP node which follows this document. When processed by any other node, it is just another SIP or SIPS URI. The primary use-case for a Bulk-AoR is for the "aor" attribute value of a "registration" element of a [RFC3680] reginfo XML document, as described in section 6. Using the Bulk-AoR as a target for generic SIP requests is outside the scope of this document. Using it as the target for a SUBSCRIBE request is discussed in section 5.4. 4.1. Bulk-AoR ABNF Rules A Bulk-AoR follows [RFC3261] ABNF rules as a specific form of the 'user' token field of a SIP or SIP URI userinfo portion in [RFC3261]: bulk-aor-user = user ";range=" expansion expansion = exp-char-set exp-char-count exp-char-set = digit-char-set / any-char-set digit-char-set = dsc-begin "-" dsc-end dsc-begin = DIGIT dsc-end = DIGIT any-char-set = "." exp-char-count = "(" exp-min "," exp-max ")" exp-min = DIGIT exp-max = DIGIT The "digit-char-set" defines a range of digit characters, for example 0-9 or 3-5, inclusive. The "dsc-begin" digit value must be less than or equal to the "dsc-end" digit value. The "any-char-set" defines any character allowed in the 'user' token field of [RFC3261]. Kaplan Expires - November 2009 [Page 5] Internet-Draft SIP MARTINI VERMOUTH May 2010 The "exp-char-count" defines a minimum and maximum number of times a character within the exp-char-set may be repeated, inclusive. The "exp-min" digit value must be less than or equal to the "exp-max" digit value. An example SIP Bulk-AoR is "sip:1234;range=0-9(1,8)@ssp.example.com" Note that the ABNF rules are written such that the digit-char-set could be wrapped in a '[' and ']' characters, and the parenthesis in exp-char-count could be converted to '{' and '}', and the resultant would then be a regex pattern with the same semantics. Furthermore, although the syntax does not support '*' and '+' regex command characters, they are logically equivalent to a {0,} and {1,} albeit with some specified maximum bound. 4.2. Restrictions of Use The mechanism proposed in this document is based on [RFC3680], but creates a specific URI syntax for indicating Registration event information for bulk groups of AoRs. In other words, it is semantically equivalent to multiple, individual AoR state information. Since the URI used represents multiple AoRs, certain implementation details are constricted beyond what [RFC3680] would have required. In particular, with separate AoR Registration state it is possible to distribute the Subscription processing across multiple servers, for different AoRs. Such is not possible for the AoRs covered by a Bulk-AoR range - the Registration state information, and the state machine described in [RFC3680] MUST be the same and available to the same SIP entity which processes the Subscription. Furthermore, the Bulk-AoR syntax does not have an "exclude" semantic - it is wholly inclusive, meaning that any specific AoR within its range is included. For example, if an AoR within the range has multiple Contacts, but not all AoRs of the range have the same multiple Contact values, then the Bulk-AoR state is in addition to any separate AoR entries. Once again, this requires the same SIP entity which processes the Subscription to have such information available to it for all of the AoRs included within the Bulk-AoR range. 5. Subscribing for Registration State Resources As per [RFC3680], when a UAC Subscribes to a SIP URI for the "reg" Event Package, the entity responsible for the Registration state of the SIP URI processes the SUBSCRIBE and returns a Registration information document with the details of the URI's registration state, including Registered Contacts and such. The target of the Kaplan Expires - November 2009 [Page 6] Internet-Draft SIP MARTINI VERMOUTH May 2010 Registration event package Subscription (the Request URI used for the SUBSCRIBE request) identifies the AoR for which the "registration state" is requested. In other words, although the target of the SUSBCRIBE identifies a Registered AoR, it is not routed to the Registered contacts of that AoR, but rather to the entity responsible for the AoR's Registration state: the SSP. In a [draft-gin] or [draft-olive] context, the bulk Registration implicitly Registers multiple AoRs of the SSP. As such, this document proposes that [RFC3680] continue to be followed, and that a SUBSCRIBE targeted to one of the implicitly Registered AoRs be processed by the SSP and return the registration state information *of that AoR* - namely, the expanded Contact, Path information, etc. of the IP-PBX as the "User Agent". In a [draft-gin] or [draft-olive] context, however, there is a need to handle Subscriptions for other resources as well. There is a need to be able to Subscribe to the registration information of AoRs within the IP-PBX (the IP-PBX's internal registration state); and to be able to Subscribe for registration information of all implicitly registered AoRs of the IP-PBX without knowing what they are in advance. This section defines how one Subscribes to such target resources. 5.1. Subscribing to AoRs A SUBSCRIBE for any specific AoR URI, including any implicitly Registered by [draft-gin], MUST be processed and handled as if there had been an explicit REGISTER transaction and associated state for that specific AoR. In other words, assuming local policies allow it, a SUBSCRIBE for "sip:+123456@ssp.example.com" would get the Registration state for that AoR, with the *expanded* [draft-gin] Contact URI, the remaining expires value from the 'bnc' REGISTER, etc. From a logical perspective, the [draft-gin] REGISTER was simply a short-hand for multiple, separate REGISTERs. Any internal optimization performed by the SSP location-service database for handling Bulk-AoRs MUST NOT change this external behavior. In particular, although local policy MAY simply not provide Registration status for the specific AoR, it MUST NOT respond to such with the Bulk-AoR form of the Registration information. Doing so would lead to backwards-compatibility problems, and is also not consistent with the resource targeted for the SUBSCRIBE. If a UAC is Subscribing for a specific AoR's event information, that is what it should get, or nothing at all. Kaplan Expires - November 2009 [Page 7] Internet-Draft SIP MARTINI VERMOUTH May 2010 5.2. Subscribing to state in the IP-PBX To Subscribe to the registration state *within* the IP-PBX (i.e., for the IP-PBX's User Agents), one could send a subsequent SUBSCRIBE to the IP-PBX based on the information learned from the Subscription to the SSP's AoRs. For example, subscribing to "sip:+1234567890@ssp.example.com" could return the expanded Registered Contact "sip:+1234567890@192.1.2.3" and Path information for that AoR; and sending another SUBSCRIBE with the target "sip:+1234567890@192.1.2.3" and a Route set of the registered Path information could reach the IP-PBX and retrieve registration information for that resource. To avoid such complexity, however, this document proposes that a SUBSCRIBE targeted to a URI with a "bnc" URI parameter appended, be usable to target the resource of the IP-PBX to begin with, and not be processed for the event package by the SSP. In other words, given the example above, if the SUBSCRIBE were targeted to "sip:+1234567890@ssp.example.com;bnc" then the SSP would route the request to the registered Contact of that AoR, using the normal request routing rules in [draft-gin]. This would result in the SUBSCRIBE being routed to the IP-PBX with a Request URI of "sip:+1234567890@192.1.2.3" for the "reg" event package, instead of being locally processed by the SSP. 5.3. Subscribing for all implicitly registered AoRs In order to be useful for provisioning checks, it needs to be possible for an IP-PBX which Registered in bulk using [draft-gin] to learn all of its implicitly Registered AoRs, without knowing them in advance. To do so, this document defines that the Registered AoR of the IP-PBX (the To URI used in the bulk [draft-gin] REGISTER), return all of the Registered AoRs of the IP-PBX. In other words, that the explicitly Registered AoR be used in the target URI of a SUBSCRIBE for the "reg" Event Package, to Subscribe to the Registration Event status of all implicitly Registered AoRs of the IP-PBX. For example, if the IP-PBX had Registered with a To-URI of "sip:pbx1@ssp.example.com" in its REGISTER request, then it (or any authorized UA) can send a SUBSCRIBE with a Request-URI of "sip:pbx1@ssp.example.com" for the "reg" Event-package and receive Notifications of all of the implicitly Registered AoRs. One or more of those Registered AoRs MAY be expressed in the NOTIFY using the Bulk-AoR format defined in this document. Kaplan Expires - November 2009 [Page 8] Internet-Draft SIP MARTINI VERMOUTH May 2010 5.4. Subscribing to a Bulk-AoR Generally it is not expected that a Bulk-AoR URI itself be Subscribed to directly, simply because it is unlikely to be known in advance by other entities and because it provides limited value to do so. For example, an IP-PBX wishing to verify its provisioned AoRs match what the SSP believes SHOULD NOT subscribe to a Bulk-AoR directly, since it will only learn about that one AoR group and not others which the SSP may incorrectly think the IP-PBX implicitly Registered. From a logical perspective, however, a Bulk-AoR is a real URI. If a SUBSCRIBE is targeted at a Bulk-AoR URI in its Request-URI, then the Registration state information returned MUST be for all of the AoRs matching the range's format. For example, if a UA SUBSCRIBEs to "sip:+1234;range=0-9(1,8)@@ssp.com", and the authoritative server for "ssp.com" has both Registered AoR information for "sip:+1234;range=0-9(1,8)@ssp.com" as well as for "sip:+123456@ssp.com", both AoRs are returned in the resulting NOTIFY reginfo document. [OPEN ISSUE: perhaps we should leave this section out, and only define "Bulk-AoRs" for Notification results but not as legitimate targets of Subscriptions themselves] 6. Event Package registration information The Registration Information provided by the Subscription as an XML document is as per [RFC3680], with the additional rules defined in this section. Note that the structure and schema of the XML document does not change, nor the information contained therein - the document contains Registration information for URIs, as before. The "changes" are simply the rules for when to provide a Bulk-AoR URI entry in particular, and how to process it. A Bulk-AoR entry MUST NOT be used for a reginfo XML document unless the Registration state, including Contacts and such, are identical for all AoRs within the indicated range. Generally, this is only possible when the range of AoRs was implicitly registered through a [draft-gin] type REGISTER mechanism. This does not mean that a specific AoR within the range cannot have additional Registered Contacts that the other AoRs of the range do not - it can, but those other Contacts are not included in the specific Bulk-AoR XML entry. 6.1. Constructing Bulk-AoR registration elements As per [RFC3680], each "registration" element within a reginfo document has three attributes: an "aor", an "id", and a "state" attribute. For a Bulk-AoR registration element, the "aor" attribute Kaplan Expires - November 2009 [Page 9] Internet-Draft SIP MARTINI VERMOUTH May 2010 value MUST be of the Bulk-AoR form, including the "range" URI user parameter as previously defined. The "id" MUST be unique, as defined for any registration element in [RFC3680]. A "contact" element's "uri" attribute value within a Bulk-AoR registration element MUST be the *unexpanded* Contact URI learned from the REGISTER transaction. In other words, it is without a user portion and with a "bnc" URI parameter, as defined in [draft-gin]. An important property of the [RFC3680] reginfo document is the "id" attribute of elements, which provides a unique index for the URIs, usable in logical tables. The "id" attribute of the "registration" element is unique per AoR URI, and the "id" of the "contact" element is unique per unique Contact URI. A Bulk-AoR is just another URI, and as such gets its own registration "id" value. A Bulk-AoR with the same user name but a different "range" URI user parameter value is a different Bulk-AoR URI, and thus gets a different ID. For example, if the range of AoRs is changed, a Notification reginfo document would use a new "id" value for the new Bulk-AoR registration element, and the previous one would be replaced (assuming the reginfo document "state" attribute value was "full"). 6.2. Processing Bulk-AoR registration elements A SIP subscriber following [RFC3680] receives notifications, with partial or full state information, for registration state of AoRs and their Contacts. This document follows that same model for a Bulk-AoR, as if it were any other registration AoR URI. Note that the registration tables and rows described in [RFC3680] are purely logical, and do not describe a specific internal implementation. 7. 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. 7.1. Example XML document The following is an example registration information document with a Bulk-AoR entry: sip:192.1.2.3;bnc sip:192.4.5.6;bnc 7.2. Usage Scenario: Subscribing to an AoR This example shows a basic bulk REGISTER transaction, followed by a SUBSCRIBE addressed to one of the implicitly registered AoRs. Internet SSP PBX | | | | | REGISTER| | | Contact:| | |<--------------------------------| | |200 OK | | |-------------------------------->| |SUBSCRIBE | | |sip:+1234567@ssp.example.com | | |------------------------------->| | | 200 OK| | |<-------------------------------| | | | | | NOTIFY| | |<-------------------------------| | |200 OK | | |------------------------------->| | Kaplan Expires - November 2009 [Page 11] Internet-Draft SIP MARTINI VERMOUTH May 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: From: ;tag=a23589 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Proxy-Require: gin Require: gin Supported: path Contact: Expires: 7200 Content-Length: 0 SUBSCRIBE sip:+1234567@ssp.example.com SIP/2.0 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad Max-Forwards: 70 To: From: ;tag=456248 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 CSeq: 24762 SUBSCRIBE Contact: Event: reg Content-Length: 0 NOTIFY sip:line-1@192.0.2.178:2081 SIP/2.0 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 Max-Forwards: 70 From: ;tag=991411 To: ;tag=456248 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b CSeq: 36123 NOTIFY Contact: Event: reg Content-Type: application/reginfo+xml Content-Length: ... sip:+1234567@198.51.100.3 Kaplan Expires - November 2009 [Page 12] Internet-Draft SIP MARTINI VERMOUTH May 2010 7.3. Usage Scenario: Subscribing to the AoRs off the IP-PBX This example shows a basic bulk REGISTER transaction, followed by a SUBSCRIBE addressed to one of the implicitly registered AoRs' state in the IP-PBX. Internet SSP PBX | | | | | REGISTER| | | Contact:| | |<--------------------------------| | |200 OK | | |-------------------------------->| |SUBSCRIBE | | |sip:+1234567@ssp.example.com;bnc| | |------------------------------->| | | |SUBSCRIBE | | |sip:+1234567@198.51.100.3 | | |-------------------------------->| | | 200 OK| | |<--------------------------------| | 200 OK| | |<-------------------------------| | | | NOTIFY| | |<--------------------------------| | NOTIFY| | |<-------------------------------| | |200 OK | | |------------------------------->| | | |200 OK | | |-------------------------------->| Kaplan Expires - November 2009 [Page 13] Internet-Draft SIP MARTINI VERMOUTH May 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: From: ;tag=a23589 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Proxy-Require: gin Require: gin Supported: path Contact: Expires: 7200 Content-Length: 0 SUBSCRIBE sip:+1234567@ssp.example.com;bnc SIP/2.0 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad Max-Forwards: 70 To: From: ;tag=456248 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 CSeq: 24762 SUBSCRIBE Contact: Event: reg Content-Length: 0 SUBSCRIBE sip:+1234567@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: 69 To: From: ;tag=456248 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 CSeq: 24762 SUBSCRIBE Contact: Event: reg Content-Length: 0 Kaplan Expires - November 2009 [Page 14] Internet-Draft SIP MARTINI VERMOUTH May 2010 NOTIFY sip:line-1@192.0.2.178:2081 SIP/2.0 Via: SIP/2.0/UDP 198.51.100.3;branch=z9hG4bKaplan123 Max-Forwards: 70 From: ;tag=991411 To: ;tag=456248 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b CSeq: 36123 NOTIFY Contact: Event: reg Content-Type: application/reginfo+xml Content-Length: ... sip:priv-user@198.51.2.33 Kaplan Expires - November 2009 [Page 15] Internet-Draft SIP MARTINI VERMOUTH May 2010 7.4. Usage Scenario: Subscribing to all AoRs This example shows a basic bulk REGISTER transaction, followed by a SUBSCRIBE addressed to all of the implicitly registered AoRs, returned as a Bulk-AoR. Internet SSP PBX | | | | | REGISTER| | | Contact:| | |<--------------------------------| | |200 OK | | |-------------------------------->| |SUBSCRIBE | | |sip:pbx123@ssp.example.com | | |------------------------------->| | | 200 OK| | |<-------------------------------| | | | | | NOTIFY| | |<-------------------------------| | |200 OK | | |------------------------------->| | REGISTER sip:ssp.example.com SIP/2.0 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: From: ;tag=a23589 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Proxy-Require: gin Require: gin Supported: path Contact: Expires: 7200 Content-Length: 0 Kaplan Expires - November 2009 [Page 16] Internet-Draft SIP MARTINI VERMOUTH May 2010 SUBSCRIBE sip:pbx123@ssp.example.com SIP/2.0 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad Max-Forwards: 70 To: From: ;tag=456248 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 CSeq: 24762 SUBSCRIBE Contact: Event: reg Content-Length: 0 NOTIFY sip:line-1@192.0.2.178:2081 SIP/2.0 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 Max-Forwards: 70 From: ;tag=991411 To: ;tag=456248 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b CSeq: 36123 NOTIFY Contact: Event: reg Content-Type: application/reginfo+xml Content-Length: ... sip:198.51.100.3;bnc 8. IANA Considerations This document makes no request of IANA. 9. Security Considerations This section is still TBD, but it should follow/have the same issues as [draft-gin]. Kaplan Expires - November 2009 [Page 17] Internet-Draft SIP MARTINI VERMOUTH May 2010 10. Normative 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. [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [draft-gin] Roach, A. B., "Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)", draft-ietf- martini-gin-01, April 2010. 11. Informative References [RFC3327] Willis, D., and Hoeneisen, B., "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. [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. Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Kaplan Expires - November 2009 [Page 18] Internet-Draft SIP MARTINI VERMOUTH May 2010 Appendix A - Rationale for Constraining the Expansion Pattern This document's mechanism defines a limited set of patterns which may be used in the "" portion of the Bulk-AoR. This is in contrast to the "Wildcarded AoR" mechanism used in some deployments, which use any regular expressions (regex) for the pattern. One of the reasons this document restricts the regex syntax is to maintain [RFC3261] compliance, which does not allow common regex characters such as '^', '[', ']','{', and '}' to appear in SIP URIs. The other reason this document does not use any arbitrary regex is that one of the goals of this document is to be useful for an IP-PBX to determine provisioning mismatches. An arbitrary regex is typically useful for verifying a given input string matches the pattern, and not for actually determining the complete set of strings the regex pattern implies. In other words, a regex is useful for authenticating a given number matches the pattern, but not for determining what all of the provisioned numbers are. For example, a regex syntax model for "sip:1234![5-9][0- 9]*!@example.com" is useful for checking if "sip:123456@example.com" is a matching number, but is extremely difficult for an IP-PBX to verify that the SSP does not include numbers the PBX does not have provisioned. The IP-PBX could check each of its locally provisioned numbers against the regex pattern, but has no clean way to determine if the set allowed by the regex is not *greater* than its locally provisioned set. Furthermore, numerous regex patterns can be used to mean the exact same set. For example "sip:1234!(5|6|7|8|9)[0-9]*!@example.com", "sip:1234![5-9][0-9]{0,}!@example.com", "sip:1234![5- 9][[:digits:]]*!@example.com", and "sip:123!4[5-9][0- 9]*!@example.com" all represent the same set of user strings as the first regex example. Therefore, to avoid such issues, this document uses a very narrow set of possible "patterns", which can be used for both matching and provisioning verification. Kaplan Expires - November 2009 [Page 19]