idnits 2.17.1 draft-kaplan-martini-vermouth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 270: '... machine described in [RFC3680] MUST be the same and available to the...' RFC 2119 keyword, line 317: '... by [draft-gin], MUST be processed and...' RFC 2119 keyword, line 327: '...ndling Bulk-AoRs MUST NOT change this ...' RFC 2119 keyword, line 328: '..., although local policy MAY simply not...' RFC 2119 keyword, line 329: '...atus for the specific AoR, it MUST NOT...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended status: Standards-Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (May 3, 2010) is 5106 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '5-9' is mentioned on line 810, but not defined == Missing Reference: '0-9' is mentioned on line 810, but not defined == Unused Reference: 'RFC3327' is defined on line 755, but no explicit reference was found in the text == Unused Reference: 'RFC4244' is defined on line 762, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MARTINI WG H. Kaplan 3 Internet Draft Acme Packet 4 Intended status: Standards-Track 5 Expires: November 3, 2011 May 3, 2010 7 SIP MARTINI Variant of 'Event-package for Registrations' 8 for Managed Open-ended Username Target Handling (VERMOUTH) 9 draft-kaplan-martini-vermouth-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 3, 2011. 34 Copyright and License Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the BSD License. 49 Abstract 51 The Martini Working Group is defining a mechanism for SIP IP-PBX 52 type devices to REGISTER and obtain SIP service for E.164-based 53 Address of Records, in [draft-gin]. Another draft [draft-olive] 54 proposes the same for non-E.164-based AoRs. This document defines a 55 variant of the Registration Event-package [reg-event] for open-ended 56 AoRs for either mechanisms, using a wildcard syntax and specific 57 target handling rules. 59 Table of Contents 61 1. Introduction................................................2 62 2. Definitions.................................................3 63 3. The Solution - an Overview..................................4 64 4. The Bulk-AoR................................................5 65 4.1. Bulk-AoR ABNF Rules.....................................5 66 4.2. Restrictions of Use.....................................6 67 5. Subscribing for Registration State Resources................6 68 5.1. Subscribing to AoRs.....................................7 69 5.2. Subscribing to state in the IP-PBX......................8 70 5.3. Subscribing for all implicitly registered AoRs..........8 71 5.4. Subscribing to a Bulk-AoR...............................9 72 6. Event Package registration information......................9 73 6.1. Constructing Bulk-AoR registration elements.............9 74 6.2. Processing Bulk-AoR registration elements..............10 75 7. Examples...................................................10 76 7.1. Example XML document...................................10 77 7.2. Usage Scenario: Subscribing to an AoR..................11 78 7.3. Usage Scenario: Subscribing to the AoRs off the IP-PBX.13 79 7.4. Usage Scenario: Subscribing to all AoRs................16 80 8. IANA Considerations........................................17 81 9. Security Considerations....................................17 82 10. Normative References.......................................18 83 11. Informative References.....................................18 84 Author's Address.................................................18 85 Appendix A - Rationale for Constraining the Expansion Pattern....19 87 1. Introduction 89 In many deployed SIP Service Provider (SSP) architectures, it is 90 common to use REGISTER requests to provide the reachability 91 information for IP-PBXs, instead of DNS-based resolution and 92 routing. An IETF-defined mechanism for doing so is being worked on 93 in the Martini Working Group, in [draft-gin]. Another draft, 94 [draft-olive] uses the [draft-gin] Martini mechanism for non-E.164 95 AoRs as well. 97 In both cases, the IP-PBX or other entity may wish to Subscribe to 98 the Registration Event Package based on [RFC3680] for the 99 Registration state information of the AoRs Registered by the [draft- 100 gin] REGISTER transactions. For example, the IP-PBX may wish to 101 learn about all of the AoRs which were implicitly Registered by 102 [draft-gin] or [draft-olive], or to learn about changes in their 103 provisioning. 105 In theory, the [draft-gin] mechanism is simply a short-hand single 106 REGISTER transaction for a bulk set of AoRs in lieu of multiple, 107 separate REGISTER transactions for each AoR. In practice, however, 108 the E.164 user numbers may be an "open" numbering plan/range, such 109 that the SSP only really knows about a certain number of digits and 110 the rest are only known to the IP-PBX. Likewise, when [draft-olive] 111 is used, the Local-Number may be only partially known to the SSP. 113 Therefore, it is not possible for the SSP to actually provide state 114 information for each possible unique AoR instance. Instead, it 115 needs to provide an indication for the registration state of the 116 prefix or digit portion it does know about. 118 This document proposes to provide such information using an agreed 119 upon URI format: a "Bulk-AoR", which follows a specific AoR syntax 120 indicating the number range, and is formatted such that it can be 121 reasonably reserved for such use. 123 This document also defines the rules for targeting SUBSCRIBE 124 requests to reach specific resources for registration state 125 information. 127 2. Definitions 129 For brevity's sake, this document uses the word "request" instead of 130 "out-of-dialog request", but in all case means out-of-dialog 131 request. 133 AoR: address-of-record, as defined by RFC 3261: a URI by which the 134 user is canonically known (e.g., on their business cards, in the 135 From header field of their requests, in the To header field of 136 REGISTER requests, etc.). 138 Bulk-AoR: a SIP or SIPS address-of-record with a "range" URI user 139 parameter which expands the user string based on a heuristic. 141 Local-Number: an AoR which follows the form of local-number in 142 [RFC3966], but may be encoded in a SIP or TEL URI. The local-number 143 contains a 'phone-context' parameter identifying the scope of its 144 number. 146 Email-style URI: a SIP AoR which does not identify a global E.164 147 number or Local-Number. 149 Implicit Registration: implicitly providing the reachability 150 information for something other than the AoR explicitly indicated in 151 the Register transaction. 153 Reachability Information: a set of URI's identifying the host and 154 path of Proxies to reach that host; like any URI, these URI's may 155 identify the specific connection transport, IP Address, and port 156 information, or they may only identify FQDN's. 158 SSP: SIP Service Provider, as defined by [RFC5486]. 160 3. The Solution - an Overview 162 To handle the open-numbering-plan problem, the concept proposed in 163 this document is to specify a specific URI syntax which is legal in 164 SIP ABNF grammar, but highly unlikely to exist for anything but this 165 document's purpose, by defining a new URI user parameter. This 166 creates a "Bulk-AoR" URI, which is treated as any other AoR URI from 167 the perspective of [RFC3680]. 169 The specific Bulk-AoR format is similar but not identical to the 170 "Wildcarded" AoR syntax already in use in certain deployments. The 171 Bulk-AoR format is "sip:;range=@", where 172 "" is similar to a regular expression pattern but has a 173 very limited, specified syntax. The limited syntax is used to avoid 174 ambiguities, make it compliant with [RFC3261] ABNF rules, and reduce 175 confusion - rationale for this is provided in Appendix A. [Open 176 issue: should a new URI parameter similar to "user=phone" be defined 177 for such an AoR type?] 179 Furthermore, this document assumes that the SSP's Registrar 180 processes Subscriptions for the "reg" event package following 181 [RFC3680], and thus that a SUBSCRIBE targeted to any of the 182 implicitly Registered AoRs be processed by the SSP (not the IP-PBX). 183 This document also provides a means, however, to Subscribe for the 184 registration state for those same AoRs in the IP-PBX itself, by 185 using the "bnc" parameter in the SUBSCRIBE target URI. 187 Lastly, this document specifies that the To-URI used for the [draft- 188 gin] REGISTER request, be usable as the target for the SUBSCRIBE 189 request, for Subscribing to the registration event information for 190 all implicitly registered AoRs of the [draft-gin] mechanism, any or 191 all of which may be encoded using the Bulk-AoR syntax proposed in 192 this document. 194 The Registration Event Packet behavior for this document's mechanism 195 works exactly the same way as defined in [RFC3680]. This document 196 does not update [RFC3680] or change its semantics. The only 197 "changes" discussed in this document are (1) details of how to 198 target a SUBSCRIBE for specific Registration state information 199 resources in section 5, and (2) explanations about reginfo XML 200 documents with Bulk-AoRs in section 6. Neither of these 201 substantively changes [RFC3680] behavior. 203 4. The Bulk-AoR 205 A "Bulk-AoR" is a SIP or SIPS URI Address-of-record containing a new 206 URI user parameter named "range". The range parameter expands the 207 user portion based on a specific heuristic, when the Bulk-AoR is 208 processed by a SIP node which follows this document. When processed 209 by any other node, it is just another SIP or SIPS URI. 211 The primary use-case for a Bulk-AoR is for the "aor" attribute value 212 of a "registration" element of a [RFC3680] reginfo XML document, as 213 described in section 6. Using the Bulk-AoR as a target for generic 214 SIP requests is outside the scope of this document. Using it as the 215 target for a SUBSCRIBE request is discussed in section 5.4. 217 4.1. Bulk-AoR ABNF Rules 219 A Bulk-AoR follows [RFC3261] ABNF rules as a specific form of the 220 'user' token field of a SIP or SIP URI userinfo portion in 221 [RFC3261]: 222 bulk-aor-user = user ";range=" expansion 223 expansion = exp-char-set exp-char-count 225 exp-char-set = digit-char-set / any-char-set 226 digit-char-set = dsc-begin "-" dsc-end 227 dsc-begin = DIGIT 228 dsc-end = DIGIT 229 any-char-set = "." 231 exp-char-count = "(" exp-min "," exp-max ")" 232 exp-min = DIGIT 233 exp-max = DIGIT 235 The "digit-char-set" defines a range of digit characters, for 236 example 0-9 or 3-5, inclusive. The "dsc-begin" digit value must be 237 less than or equal to the "dsc-end" digit value. 239 The "any-char-set" defines any character allowed in the 'user' token 240 field of [RFC3261]. 242 The "exp-char-count" defines a minimum and maximum number of times a 243 character within the exp-char-set may be repeated, inclusive. The 244 "exp-min" digit value must be less than or equal to the "exp-max" 245 digit value. 247 An example SIP Bulk-AoR is "sip:1234;range=0-9(1,8)@ssp.example.com" 248 Note that the ABNF rules are written such that the digit-char-set 249 could be wrapped in a '[' and ']' characters, and the parenthesis in 250 exp-char-count could be converted to '{' and '}', and the resultant 251 would then be a regex pattern with the same semantics. Furthermore, 252 although the syntax does not support '*' and '+' regex command 253 characters, they are logically equivalent to a {0,} and {1,} albeit 254 with some specified maximum bound. 256 4.2. Restrictions of Use 258 The mechanism proposed in this document is based on [RFC3680], but 259 creates a specific URI syntax for indicating Registration event 260 information for bulk groups of AoRs. In other words, it is 261 semantically equivalent to multiple, individual AoR state 262 information. Since the URI used represents multiple AoRs, certain 263 implementation details are constricted beyond what [RFC3680] would 264 have required. 266 In particular, with separate AoR Registration state it is possible 267 to distribute the Subscription processing across multiple servers, 268 for different AoRs. Such is not possible for the AoRs covered by a 269 Bulk-AoR range - the Registration state information, and the state 270 machine described in [RFC3680] MUST be the same and available to the 271 same SIP entity which processes the Subscription. 273 Furthermore, the Bulk-AoR syntax does not have an "exclude" semantic 274 - it is wholly inclusive, meaning that any specific AoR within its 275 range is included. For example, if an AoR within the range has 276 multiple Contacts, but not all AoRs of the range have the same 277 multiple Contact values, then the Bulk-AoR state is in addition to 278 any separate AoR entries. Once again, this requires the same SIP 279 entity which processes the Subscription to have such information 280 available to it for all of the AoRs included within the Bulk-AoR 281 range. 283 5. Subscribing for Registration State Resources 285 As per [RFC3680], when a UAC Subscribes to a SIP URI for the "reg" 286 Event Package, the entity responsible for the Registration state of 287 the SIP URI processes the SUBSCRIBE and returns a Registration 288 information document with the details of the URI's registration 289 state, including Registered Contacts and such. The target of the 290 Registration event package Subscription (the Request URI used for 291 the SUBSCRIBE request) identifies the AoR for which the 292 "registration state" is requested. In other words, although the 293 target of the SUSBCRIBE identifies a Registered AoR, it is not 294 routed to the Registered contacts of that AoR, but rather to the 295 entity responsible for the AoR's Registration state: the SSP. 297 In a [draft-gin] or [draft-olive] context, the bulk Registration 298 implicitly Registers multiple AoRs of the SSP. As such, this 299 document proposes that [RFC3680] continue to be followed, and that a 300 SUBSCRIBE targeted to one of the implicitly Registered AoRs be 301 processed by the SSP and return the registration state information 302 *of that AoR* - namely, the expanded Contact, Path information, etc. 303 of the IP-PBX as the "User Agent". 305 In a [draft-gin] or [draft-olive] context, however, there is a need 306 to handle Subscriptions for other resources as well. There is a 307 need to be able to Subscribe to the registration information of AoRs 308 within the IP-PBX (the IP-PBX's internal registration state); and to 309 be able to Subscribe for registration information of all implicitly 310 registered AoRs of the IP-PBX without knowing what they are in 311 advance. This section defines how one Subscribes to such target 312 resources. 314 5.1. Subscribing to AoRs 316 A SUBSCRIBE for any specific AoR URI, including any implicitly 317 Registered by [draft-gin], MUST be processed and handled as if there 318 had been an explicit REGISTER transaction and associated state for 319 that specific AoR. In other words, assuming local policies allow 320 it, a SUBSCRIBE for "sip:+123456@ssp.example.com" would get the 321 Registration state for that AoR, with the *expanded* [draft-gin] 322 Contact URI, the remaining expires value from the 'bnc' REGISTER, 323 etc. From a logical perspective, the [draft-gin] REGISTER was 324 simply a short-hand for multiple, separate REGISTERs. 326 Any internal optimization performed by the SSP location-service 327 database for handling Bulk-AoRs MUST NOT change this external 328 behavior. In particular, although local policy MAY simply not 329 provide Registration status for the specific AoR, it MUST NOT 330 respond to such with the Bulk-AoR form of the Registration 331 information. Doing so would lead to backwards-compatibility 332 problems, and is also not consistent with the resource targeted for 333 the SUBSCRIBE. If a UAC is Subscribing for a specific AoR's event 334 information, that is what it should get, or nothing at all. 336 5.2. Subscribing to state in the IP-PBX 338 To Subscribe to the registration state *within* the IP-PBX (i.e., 339 for the IP-PBX's User Agents), one could send a subsequent SUBSCRIBE 340 to the IP-PBX based on the information learned from the Subscription 341 to the SSP's AoRs. For example, subscribing to 342 "sip:+1234567890@ssp.example.com" could return the expanded 343 Registered Contact "sip:+1234567890@192.1.2.3" and Path information 344 for that AoR; and sending another SUBSCRIBE with the target 345 "sip:+1234567890@192.1.2.3" and a Route set of the registered Path 346 information could reach the IP-PBX and retrieve registration 347 information for that resource. 349 To avoid such complexity, however, this document proposes that a 350 SUBSCRIBE targeted to a URI with a "bnc" URI parameter appended, be 351 usable to target the resource of the IP-PBX to begin with, and not 352 be processed for the event package by the SSP. In other words, 353 given the example above, if the SUBSCRIBE were targeted to 354 "sip:+1234567890@ssp.example.com;bnc" then the SSP would route the 355 request to the registered Contact of that AoR, using the normal 356 request routing rules in [draft-gin]. This would result in the 357 SUBSCRIBE being routed to the IP-PBX with a Request URI of 358 "sip:+1234567890@192.1.2.3" for the "reg" event package, instead of 359 being locally processed by the SSP. 361 5.3. Subscribing for all implicitly registered AoRs 363 In order to be useful for provisioning checks, it needs to be 364 possible for an IP-PBX which Registered in bulk using [draft-gin] to 365 learn all of its implicitly Registered AoRs, without knowing them in 366 advance. To do so, this document defines that the Registered AoR of 367 the IP-PBX (the To URI used in the bulk [draft-gin] REGISTER), 368 return all of the Registered AoRs of the IP-PBX. In other words, 369 that the explicitly Registered AoR be used in the target URI of a 370 SUBSCRIBE for the "reg" Event Package, to Subscribe to the 371 Registration Event status of all implicitly Registered AoRs of the 372 IP-PBX. 374 For example, if the IP-PBX had Registered with a To-URI of 375 "sip:pbx1@ssp.example.com" in its REGISTER request, then it (or any 376 authorized UA) can send a SUBSCRIBE with a Request-URI of 377 "sip:pbx1@ssp.example.com" for the "reg" Event-package and receive 378 Notifications of all of the implicitly Registered AoRs. One or more 379 of those Registered AoRs MAY be expressed in the NOTIFY using the 380 Bulk-AoR format defined in this document. 382 5.4. Subscribing to a Bulk-AoR 384 Generally it is not expected that a Bulk-AoR URI itself be 385 Subscribed to directly, simply because it is unlikely to be known in 386 advance by other entities and because it provides limited value to 387 do so. For example, an IP-PBX wishing to verify its provisioned 388 AoRs match what the SSP believes SHOULD NOT subscribe to a Bulk-AoR 389 directly, since it will only learn about that one AoR group and not 390 others which the SSP may incorrectly think the IP-PBX implicitly 391 Registered. 393 From a logical perspective, however, a Bulk-AoR is a real URI. If a 394 SUBSCRIBE is targeted at a Bulk-AoR URI in its Request-URI, then the 395 Registration state information returned MUST be for all of the AoRs 396 matching the range's format. For example, if a UA SUBSCRIBEs to 397 "sip:+1234;range=0-9(1,8)@@ssp.com", and the authoritative server 398 for "ssp.com" has both Registered AoR information for 399 "sip:+1234;range=0-9(1,8)@ssp.com" as well as for 400 "sip:+123456@ssp.com", both AoRs are returned in the resulting 401 NOTIFY reginfo document. 403 [OPEN ISSUE: perhaps we should leave this section out, and only 404 define "Bulk-AoRs" for Notification results but not as legitimate 405 targets of Subscriptions themselves] 407 6. Event Package registration information 409 The Registration Information provided by the Subscription as an XML 410 document is as per [RFC3680], with the additional rules defined in 411 this section. Note that the structure and schema of the XML 412 document does not change, nor the information contained therein - 413 the document contains Registration information for URIs, as before. 414 The "changes" are simply the rules for when to provide a Bulk-AoR 415 URI entry in particular, and how to process it. 417 A Bulk-AoR entry MUST NOT be used for a reginfo XML document unless 418 the Registration state, including Contacts and such, are identical 419 for all AoRs within the indicated range. Generally, this is only 420 possible when the range of AoRs was implicitly registered through a 421 [draft-gin] type REGISTER mechanism. This does not mean that a 422 specific AoR within the range cannot have additional Registered 423 Contacts that the other AoRs of the range do not - it can, but those 424 other Contacts are not included in the specific Bulk-AoR XML entry. 426 6.1. Constructing Bulk-AoR registration elements 428 As per [RFC3680], each "registration" element within a reginfo 429 document has three attributes: an "aor", an "id", and a "state" 430 attribute. For a Bulk-AoR registration element, the "aor" attribute 431 value MUST be of the Bulk-AoR form, including the "range" URI user 432 parameter as previously defined. The "id" MUST be unique, as 433 defined for any registration element in [RFC3680]. 435 A "contact" element's "uri" attribute value within a Bulk-AoR 436 registration element MUST be the *unexpanded* Contact URI learned 437 from the REGISTER transaction. In other words, it is without a user 438 portion and with a "bnc" URI parameter, as defined in [draft-gin]. 439 An important property of the [RFC3680] reginfo document is the "id" 440 attribute of elements, which provides a unique index for the URIs, 441 usable in logical tables. The "id" attribute of the "registration" 442 element is unique per AoR URI, and the "id" of the "contact" element 443 is unique per unique Contact URI. A Bulk-AoR is just another URI, 444 and as such gets its own registration "id" value. 446 A Bulk-AoR with the same user name but a different "range" URI user 447 parameter value is a different Bulk-AoR URI, and thus gets a 448 different ID. For example, if the range of AoRs is changed, a 449 Notification reginfo document would use a new "id" value for the new 450 Bulk-AoR registration element, and the previous one would be 451 replaced (assuming the reginfo document "state" attribute value was 452 "full"). 454 6.2. Processing Bulk-AoR registration elements 456 A SIP subscriber following [RFC3680] receives notifications, with 457 partial or full state information, for registration state of AoRs 458 and their Contacts. This document follows that same model for a 459 Bulk-AoR, as if it were any other registration AoR URI. 461 Note that the registration tables and rows described in [RFC3680] 462 are purely logical, and do not describe a specific internal 463 implementation. 465 7. Examples 467 These will be fleshed out more in later versions of the draft, with 468 explanations of the processing performed at each step. For the time 469 being, they just show the basic syntax described above. 471 7.1. Example XML document 473 The following is an example registration information document with a 474 Bulk-AoR entry: 476 477 480 482 485 sip:192.1.2.3;bnc 486 487 490 sip:192.4.5.6;bnc 491 492 493 495 7.2. Usage Scenario: Subscribing to an AoR 497 This example shows a basic bulk REGISTER transaction, followed by a 498 SUBSCRIBE addressed to one of the implicitly registered AoRs. 500 Internet SSP PBX 501 | | | 502 | | REGISTER| 503 | | Contact:| 504 | |<--------------------------------| 505 | |200 OK | 506 | |-------------------------------->| 507 |SUBSCRIBE | | 508 |sip:+1234567@ssp.example.com | | 509 |------------------------------->| | 510 | 200 OK| | 511 |<-------------------------------| | 512 | | | 513 | NOTIFY| | 514 |<-------------------------------| | 515 |200 OK | | 516 |------------------------------->| | 517 REGISTER sip:ssp.example.com SIP/2.0 518 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 519 Max-Forwards: 70 520 To: 521 From: ;tag=a23589 522 Call-ID: 843817637684230@998sdasdh09 523 CSeq: 1826 REGISTER 524 Proxy-Require: gin 525 Require: gin 526 Supported: path 527 Contact: 528 Expires: 7200 529 Content-Length: 0 531 SUBSCRIBE sip:+1234567@ssp.example.com SIP/2.0 532 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 533 Max-Forwards: 70 534 To: 535 From: ;tag=456248 536 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 537 CSeq: 24762 SUBSCRIBE 538 Contact: 539 Event: reg 540 Content-Length: 0 542 NOTIFY sip:line-1@192.0.2.178:2081 SIP/2.0 543 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 544 Max-Forwards: 70 545 From: ;tag=991411 546 To: ;tag=456248 547 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b 548 CSeq: 36123 NOTIFY 549 Contact: 550 Event: reg 551 Content-Type: application/reginfo+xml 552 Content-Length: ... 554 555 557 559 561 sip:+1234567@198.51.100.3 563 564 565 567 7.3. Usage Scenario: Subscribing to the AoRs off the IP-PBX 569 This example shows a basic bulk REGISTER transaction, followed by a 570 SUBSCRIBE addressed to one of the implicitly registered AoRs' state 571 in the IP-PBX. 573 Internet SSP PBX 574 | | | 575 | | REGISTER| 576 | | Contact:| 577 | |<--------------------------------| 578 | |200 OK | 579 | |-------------------------------->| 580 |SUBSCRIBE | | 581 |sip:+1234567@ssp.example.com;bnc| | 582 |------------------------------->| | 583 | |SUBSCRIBE | 584 | |sip:+1234567@198.51.100.3 | 585 | |-------------------------------->| 586 | | 200 OK| 587 | |<--------------------------------| 588 | 200 OK| | 589 |<-------------------------------| | 590 | | NOTIFY| 591 | |<--------------------------------| 592 | NOTIFY| | 593 |<-------------------------------| | 594 |200 OK | | 595 |------------------------------->| | 596 | |200 OK | 597 | |-------------------------------->| 598 REGISTER sip:ssp.example.com SIP/2.0 599 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 600 Max-Forwards: 70 601 To: 602 From: ;tag=a23589 603 Call-ID: 843817637684230@998sdasdh09 604 CSeq: 1826 REGISTER 605 Proxy-Require: gin 606 Require: gin 607 Supported: path 608 Contact: 609 Expires: 7200 610 Content-Length: 0 612 SUBSCRIBE sip:+1234567@ssp.example.com;bnc SIP/2.0 613 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 614 Max-Forwards: 70 615 To: 616 From: ;tag=456248 617 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 618 CSeq: 24762 SUBSCRIBE 619 Contact: 620 Event: reg 621 Content-Length: 0 623 SUBSCRIBE sip:+1234567@198.51.100.3 SIP/2.0 624 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 625 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 626 Max-Forwards: 69 627 To: 628 From: ;tag=456248 629 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 630 CSeq: 24762 SUBSCRIBE 631 Contact: 632 Event: reg 633 Content-Length: 0 634 NOTIFY sip:line-1@192.0.2.178:2081 SIP/2.0 635 Via: SIP/2.0/UDP 198.51.100.3;branch=z9hG4bKaplan123 636 Max-Forwards: 70 637 From: ;tag=991411 638 To: ;tag=456248 639 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b 640 CSeq: 36123 NOTIFY 641 Contact: 642 Event: reg 643 Content-Type: application/reginfo+xml 644 Content-Length: ... 646 647 649 651 653 sip:priv-user@198.51.2.33 654 655 656 658 7.4. Usage Scenario: Subscribing to all AoRs 660 This example shows a basic bulk REGISTER transaction, followed by a 661 SUBSCRIBE addressed to all of the implicitly registered AoRs, 662 returned as a Bulk-AoR. 664 Internet SSP PBX 665 | | | 666 | | REGISTER| 667 | | Contact:| 668 | |<--------------------------------| 669 | |200 OK | 670 | |-------------------------------->| 671 |SUBSCRIBE | | 672 |sip:pbx123@ssp.example.com | | 673 |------------------------------->| | 674 | 200 OK| | 675 |<-------------------------------| | 676 | | | 677 | NOTIFY| | 678 |<-------------------------------| | 679 |200 OK | | 680 |------------------------------->| | 682 REGISTER sip:ssp.example.com SIP/2.0 683 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 684 Max-Forwards: 70 685 To: 686 From: ;tag=a23589 687 Call-ID: 843817637684230@998sdasdh09 688 CSeq: 1826 REGISTER 689 Proxy-Require: gin 690 Require: gin 691 Supported: path 692 Contact: 693 Expires: 7200 694 Content-Length: 0 695 SUBSCRIBE sip:pbx123@ssp.example.com SIP/2.0 696 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 697 Max-Forwards: 70 698 To: 699 From: ;tag=456248 700 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 701 CSeq: 24762 SUBSCRIBE 702 Contact: 703 Event: reg 704 Content-Length: 0 706 NOTIFY sip:line-1@192.0.2.178:2081 SIP/2.0 707 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 708 Max-Forwards: 70 709 From: ;tag=991411 710 To: ;tag=456248 711 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b 712 CSeq: 36123 NOTIFY 713 Contact: 714 Event: reg 715 Content-Type: application/reginfo+xml 716 Content-Length: ... 718 719 721 723 725 sip:198.51.100.3;bnc 726 727 728 730 8. IANA Considerations 732 This document makes no request of IANA. 734 9. Security Considerations 736 This section is still TBD, but it should follow/have the same issues 737 as [draft-gin]. 739 10. Normative References 741 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 742 A., Peterson, J., Sparks, R., Handley, M., and E. 743 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 744 June 2002. 746 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 747 Package for Registrations", RFC 3680, March 2004. 749 [draft-gin] Roach, A. B., "Registration for Multiple Phone Numbers 750 in the Session Initiation Protocol (SIP)", draft-ietf- 751 martini-gin-01, April 2010. 753 11. Informative References 755 [RFC3327] Willis, D., and Hoeneisen, B., "Session Initiation 756 Protocol (SIP) Extension Header Field for Registering 757 Non-Adjacent Contacts", RFC 3327, December 2002. 759 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 760 3966, December 2004. 762 [RFC4244] Barnes, M. (ed.), "An Extension to the Session Initiation 763 Protocol (SIP) for Request History Information", RFC 764 4244, November 2005. 766 [RFC5486] Malas, D., and Meyer, D., "Session Peering for Multimedia 767 Interconnect (SPEERMINT) Terminology", RFC 5486, March 768 2009. 770 Author's Address 772 Hadriel Kaplan 773 Acme Packet 774 71 Third Ave. 775 Burlington, MA 01803, USA 776 Email: hkaplan@acmepacket.com 778 Appendix A - Rationale for Constraining the Expansion Pattern 780 This document's mechanism defines a limited set of patterns which 781 may be used in the "" portion of the Bulk-AoR. This is 782 in contrast to the "Wildcarded AoR" mechanism used in some 783 deployments, which use any regular expressions (regex) for the 784 pattern. One of the reasons this document restricts the regex 785 syntax is to maintain [RFC3261] compliance, which does not allow 786 common regex characters such as '^', '[', ']','{', and '}' to appear 787 in SIP URIs. 789 The other reason this document does not use any arbitrary regex is 790 that one of the goals of this document is to be useful for an IP-PBX 791 to determine provisioning mismatches. An arbitrary regex is 792 typically useful for verifying a given input string matches the 793 pattern, and not for actually determining the complete set of 794 strings the regex pattern implies. In other words, a regex is 795 useful for authenticating a given number matches the pattern, but 796 not for determining what all of the provisioned numbers are. 798 For example, a regex syntax model for "sip:1234![5-9][0- 799 9]*!@example.com" is useful for checking if "sip:123456@example.com" 800 is a matching number, but is extremely difficult for an IP-PBX to 801 verify that the SSP does not include numbers the PBX does not have 802 provisioned. The IP-PBX could check each of its locally provisioned 803 numbers against the regex pattern, but has no clean way to determine 804 if the set allowed by the regex is not *greater* than its locally 805 provisioned set. 807 Furthermore, numerous regex patterns can be used to mean the exact 808 same set. For example "sip:1234!(5|6|7|8|9)[0-9]*!@example.com", 809 "sip:1234![5-9][0-9]{0,}!@example.com", "sip:1234![5- 810 9][[:digits:]]*!@example.com", and "sip:123!4[5-9][0- 811 9]*!@example.com" all represent the same set of user strings as the 812 first regex example. 814 Therefore, to avoid such issues, this document uses a very narrow 815 set of possible "patterns", which can be used for both matching and 816 provisioning verification.