idnits 2.17.1 draft-kaplan-martini-with-olive-01.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 217: '...ntact URI in the REGISTER message MUST...' RFC 2119 keyword, line 221: '...ail-style" AoRs, it MUST NOT include a...' RFC 2119 keyword, line 227: '...ng", AoRs of "Email-style" MUST NOT be...' RFC 2119 keyword, line 302: '... following [RFC3966], and that form MUST be the one used for routing,...' RFC 2119 keyword, line 304: '... it MUST be logically transformed in...' (2 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 5099 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) == Unused Reference: 'RFC3263' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC3327' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC3455' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC3608' is defined on line 581, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3455 (Obsoleted by RFC 7315) -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MARTINI WG H. Kaplan 2 Internet Draft Acme Packet 3 Intended status: Standards-Track 4 Expires: November 3, 2011 May 3, 2010 6 SIP MARTINI with 7 Other Logical Identifier Values which are not E.164 (OLIVE) 8 draft-kaplan-martini-with-olive-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 3, 2011. 33 Copyright and License Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the BSD License. 48 Abstract 50 The Martini Working Group is defining a mechanism for SIP IP-PBX 51 type devices to REGISTER and obtain SIP service for E.164-based 52 Address of Records. This document defines a means for other, non- 53 E.164 AoRs of the Registered-to SSP's domain to be used with 54 Martini-based IP-PBXs. 56 Table of Contents 58 1. Introduction................................................2 59 2. Definitions.................................................3 60 3. Background on Current Martini Mechanism.....................3 61 4. The Solution - an Overview..................................4 62 5. Registering for AoRs........................................4 63 5.1. Registering Local Number AoRs...........................6 64 5.2. Registering for other domains...........................7 65 6. SSP Processing of Inbound Non-E.164 Requests................7 66 6.1. Processing of Local-Number Requests.....................8 67 7. Interaction with Other Mechanisms...........................8 68 7.1. Globally Routable User-Agent URIs (GRUU)................8 69 7.2. Registration Event Package..............................8 70 7.3. Non-Adjacent Contact Registration (Path) and Service Route 71 Discovery......................................................9 72 8. Open Issues.................................................9 73 9. Examples....................................................9 74 9.1. Usage Scenario: Basic Registration case 1..............10 75 9.2. Usage Scenario: Basic Registration case 2..............12 76 10. IANA Considerations........................................13 77 11. Security Considerations....................................13 78 12. Acknowledgements...........................................13 79 13. Informative References.....................................14 80 Author's Address.................................................15 81 Appendix A - Why non-E.164 AoRs may need processing by SSPs......15 82 Appendix B - Issues with non-E.164 Identifiers...................16 83 o Globally unique AoR...........................................16 84 o Registered Contact Username...................................16 85 o Avoiding syntax mismatches....................................17 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]. 95 The current Martini mechanism only supports E.164-based AoRs, 96 however in actual deployments private-extension or "local" numbers 97 are used for hosted and carrier-provided intra-Enterprise calling 98 services, and domain-scoped "email-style" URIs may become more 99 popular in the near future. Neither of these forms of AoRs are 100 supported by the current Martini mechanism. This document defines a 101 means by which they can be supported, in a manner consistent with 102 [RFC3261] and [draft-gin]. 104 Background information is provided in the Appendices. 106 2. Definitions 108 For brevity's sake, this document uses the word "request" instead of 109 "out-of-dialog request", but in all case means out-of-dialog 110 request. 112 AoR: address-of-record, as defined by RFC 3261: a URI by which the 113 user is canonically known (e.g., on their business cards, in the 114 From header field of their requests, in the To header field of 115 REGISTER requests, etc.). 117 Local-Number: an AoR which follows the form of local-number in 118 [RFC3966], but may be encoded in a SIP or TEL URI. The local-number 119 contains a 'phone-context' parameter identifying the scope of its 120 number. 122 Email-style URI: a SIP AoR which does not identify a global E.164 123 number or Local-Number. 125 Implicit Registration: implicitly providing the reachability 126 information for something other than the AoR explicitly indicated in 127 the Register transaction. 129 Reachability Information: a set of URI's identifying the host and 130 path of Proxies to reach that host; like any URI, these URI's may 131 identify the specific connection transport, IP Address, and port 132 information, or they may only identify FQDN's. 134 SSP: SIP Service Provider, as defined by [RFC5486]. 136 3. Background on Current Martini Mechanism 138 The current Martini mechanism, defined in [draft-gin], allows a SIP 139 UA such as an IP-PBX to Register a set of E.164 AoRs in "bulk". 140 Instead of creating a separate REGISTER transaction for every E.164 141 AoR, the IP-PBX sends one REGISTER request with a 'bnc' Contact URI 142 parameter which indicates the Contact URI needs to be expanded in 143 the Registrar's location service database. The expansion is such 144 that each E.164 user number becomes the user portion of the 145 Registered Contact URI, one for each implicitly Registered E.164 146 number-based AoR. 148 SIP Request routing to the Registered E.164 AoR then follows normal 149 [RFC3261] procedures, replacing the Request URI with the (expanded) 150 Registered Contact URI, and adding any Path information as a Route 151 set, etc. 153 4. The Solution - an Overview 155 The general concept proposed in this document is to simply apply 156 [draft-gin] for any set of AoRs of the Registered-to domain, for any 157 valid set of user strings as defined in [RFC3261]. The [draft-gin] 158 REGISTER request would cause the Registrar to populate the set of 159 AoRs to Contact bindings, as it did before. 161 The Contact URI user portion would also be "expanded", using the 162 same user portion as that of the implicitly Registered AoRs. In the 163 case of a Local-Number, the username is "normalized" in the same 164 manner as [draft-gin]. 166 Note that the list of AoRs associated with a PBX is a matter of 167 local provisioning at the SSP and at the PBX, as it was in [draft- 168 gin]. The mechanism defined in this document does not provide any 169 means to detect or recover from provisioning mismatches (although 170 the registration event package can be used as a standardized means 171 for auditing such AoRs). 173 No new option-tag is required, because this document's mechanism 174 does not require any changes in Martini [draft-gin] Registration or 175 subsequent [RFC3261] routing behavior in the IP-PBX or any proxies 176 along the path. The routing follows the [RFC3261] Registered AoR- 177 contact resolution model, which is a basic function of SIP. 179 The only SIP devices affected by this document's mechanism is the 180 SSP's Registrar, which needs to update the appropriate AoR entries, 181 and any proxy/ies of the SSP which perform route resolution by 182 looking up the contents of the (logical) location-service database. 183 Since such proxies may not even be in the path of the REGISTER 184 request, an option-tag will not help. And since the Registrar and 185 Proxies in question are all under control of the same administrative 186 entity (the SSP), it is reasonable to expect them all to support 187 this document's mechanism, if any do. 189 5. Registering for AoRs 191 This document's mechanism relies on the Martini [draft-gin] 192 Registration mechanism. The IP-PBX Registers into the SSP, using a 193 REGISTER request with the [draft-gin] option-tag in the Require and 194 Proxy-Require header fields, and a Contact URI containing the 195 [draft-gin] "bnc" URI parameter and no user portion. After the PBX 196 is authenticated, the registrar updates its location service so that 197 each of the AoRs associated with the PBX creates a unique AOR to 198 Contact mapping. Semantically, each of these mappings will be 199 treated as a unique row in the location service. The actual 200 implementation may, of course, perform internal optimizations to 201 reduce the amount of memory used to store such information. 203 For each of these unique rows, the AOR will be in the format that 204 the SSP expects to receive from external parties (e.g. 205 "sip:bob@ssp.example.com"), and the corresponding Contact will be 206 formed adding a user portion to the REGISTER's Contact URI 207 containing the AoR user name and removing the "bnc" parameter. For 208 example, if the Contact header field contains the URI 209 , then the Contact value 210 associated with the aforementioned AOR will be 211 . 213 Local-Numbers have slightly different Contact URI expansion rules, 214 as defined later. 216 As in [draft-gin], aside from the "bnc" parameter, all URI 217 parameters present in the Contact URI in the REGISTER message MUST 218 be copied to the Contact value stored in the location service. 220 If the SIP UA generating the REGISTER request (i.e., the IP-PBX) is 221 implicitly Registering for "Email-style" AoRs, it MUST NOT include a 222 "user=phone" URI parameter in the bulk Contact URI of the REGISTER 223 request. "Email-style" URI's are not phone numbers, and as such 224 their expanded Contact value cannot have a "user=phone" or 225 "user=dialstring" URI parameter. Therefore, if the REGISTER 226 request's Contact URI included a URI parameter named "user" with a 227 value of "phone" or "dialstring", AoRs of "Email-style" MUST NOT be 228 bound to the Contact of the REGISTER. In other words, the UA has 229 indicated it expects a phone or dialstring, and nothing else. 231 Note that the location service database, and any entry model 232 described here, is purely an abstract concept used by [RFC3261], 233 [draft-gin], and this document; an actual implementation may do 234 whatever it likes internally, so long as the external behavior 235 follows the model. For example, if an SSP does not maintain any 236 specific knowledge of the Local Number dial-plan, but simply 237 performs prefix or default routing for an Enterprise's private 238 extensions, the SSP could just route based on the E.164 phone- 239 context field value without having a separate physical "AoR" 240 database entry for each local number of that context. 242 5.1. Registering Local Number AoRs 244 Local-Numbers present a complexity for AoR Registration, because 245 their user portion is scoped to the phone-context's value. In 246 practice the SSP domain may not have specific knowledge of any or 247 all user names within a given phone-context's scope. In fact, the 248 Local-Number TEL URI parameters (which are URI user parameters in 249 SIP URIs), may only have meaning to the ultimate target of the 250 request, or some entity which is authoritative for the phone- 251 context's user names. Those parameters cannot be removed by the SSP 252 if it does not actually process the user portions of the Local- 253 Number. (i.e., if it does not have the dial-plan, etc.) 255 With regard to this document's mechanism, what this means is that 256 such an SSP cannot physically instantiate an AoR in a database for 257 every possible Local-Number and cannot physically instantiate an 258 expanded Contact URI for every possible Local-Number user name with 259 every possible user parameter. That does not inhibit the mechanism 260 from working or being usable, however, because the location-service 261 database model is purely an abstract concept. What's important is 262 that the route-resolving Proxy be able to lookup and replace an AoR 263 it is authoritative for, to a Registered Contact URI, such that the 264 resultant Request URI matches what the IP-PBX expects to receive. 266 It is "safe" to do this because the explicitly Registered Contact 267 URI of the [draft-gin] REGISTER request had no user portion, and 268 thus no possible URI user parameters. As defined in [draft-gin], 269 the Contact URI parameters of the REGISTER are saved and reused, but 270 not URI user parameters. 272 There are multiple ways of describing the logical AoR instantiation 273 and Contact URI expansion rules. They could be described as 274 covering every possible ABNF expansion, such that every possible 275 user and parameter logically exists in the location-service database 276 (but obviously not physically exists). Or it could be described as 277 only the phone-context value itself being an "AoR" entry and Contact 278 URI expansion, with a policy to allow any and all user names and 279 parameters to be copied instead of replaced by the Contact URI. 281 This remains an open issue for discussion, as discussed in section 282 8. 284 Regardless, for an implicitly Registered SIP AoR with a URI user 285 portion matching the syntax outlined for "local-number" TEL URIs in 286 [RFC3966]: the Contact is expanded following the other AoR models, 287 EXCEPT that all URI user parameters are also included. For example, 288 if the logically provisioned "AoR" from the previous examples were: 289 "sip:12345;ext=678;phone-context=+1212555@ssp.example.com", it would 290 logically get an automatically generated Contact value of 291 292 and if the AoR were "sip:12345;ext=678;phone- 293 context=ssp.example.com@ssp.example.com", the resultant Contact 294 value would be . 297 Note that in practice it is not uncommon to receive a SIP URI which 298 does not strictly comply with the formatting rules of [RFC3966], but 299 is processed as if it were, based on local policies. That is legal, 300 of course, but from a logical perspective the SIP URI is actually 301 retargeted or transformed into the syntactically valid form 302 following [RFC3966], and that form MUST be the one used for routing, 303 Contact URI expansions, etc. Likewise, if the URI were a TEL URI, 304 it MUST be logically transformed into a SIP URI of the SSP's domain 305 as defined in section 19.1.6 of [RFC3261], with an appropriate 306 phone-context, before executing the rules. 308 5.2. Registering for other domains 310 The mechanism defined herein only applies to AoRs of the Registered- 311 to domain, as it did for [draft-gin]. In other words, if the bulk 312 REGISTER had a To-URI of "sip:pbx123@ssp.example.com", then it is 313 bulk Registering AoRs scoped to the domain "ssp.example.com". This 314 follows the same model as [RFC3261], where the Registered AoR is 315 defined by the To-URI of the REGISTER. 317 Other AoRs of other domains, such as "sip:bob@foo.example.net", MAY 318 be routed to the Registered AoRs based on local policy provisioning, 319 but in so doing are effectively re-targeted to the Registered AoR. 320 Such SIP requests routed to the IP-PBX will have a Request-URI of 321 the expanded registered contact, and be indistinguishable from 322 requests which were originally for the registered AoR all along. 323 (except through [RFC4244] History-Info processing) 325 If the IP-PBX wishes to distinguish inbound requests among such AoRs 326 of different domains, it MUST Register to each domain separately, 327 using a unique Contact URI for the REGISTER request of each domain. 328 The Contact URI can be made unique by inserting a URI parameter. 329 This parameter will then be reflected in the Request-URI for inbound 330 requests to the IP-PBX, based on the expansion rules defined herein 331 and in [draft-gin]. 333 [Open issue: should we define a new parameter for this? Like ";user- 334 context=foo.example.net"?] 336 6. SSP Processing of Inbound Non-E.164 Requests 338 The SSP Proxy/Registrar (or equivalent entity) performs traditional 339 Proxy/Registrar behavior, based on the mapping described in Section 340 5 and [draft-gin]. For Local-Numbers in particular, the following 341 section provides additional detail. 343 6.1. Processing of Local-Number Requests 345 As discussed in section 5.1, Local-Numbers present a special case 346 which may need to be handled with more explicit rules than [RFC3261] 347 or [draft-gin] currently prescribe. If the location-service 348 database is described as having every possible expansion, then the 349 Request would be processed in the same manner as section 5 and 350 [draft-gin]. 352 7. Interaction with Other Mechanisms 354 The following sections describe the means by which this mechanism 355 interacts with relevant REGISTER-related extensions currently 356 defined by the IETF. 358 Currently, the descriptions are somewhat informal, and omit some 359 details for the sake of brevity. If the MARTINI working group 360 expresses interest in furthering the mechanism described by this 361 document, they will be fleshed out with more detail and formality. 363 7.1. Globally Routable User-Agent URIs (GRUU) 365 The GRUU mechanism for this document's mechanism works exactly the 366 same way as defined in [draft-gin]. The [draft-gin] GRUU mechanism 367 has no dependency on the global uniqueness of the AoR username, nor 368 on being digits or an E.164. 370 7.2. Registration Event Package 372 The Registration Event Packet behavior for this document's mechanism 373 works exactly the same way as defined in [draft-gin]. The [draft- 374 gin] reg-event model has no dependency on the global uniqueness of 375 the AoR username, nor on being digits or an E.164. 377 There is, however, an issue for Local-Numbers, if the SSP does not 378 actually know the full list of Local-Number user names in the given 379 phone-context scope. In such a case, it is TBD for how to handle 380 this. 382 This remains an open issue for discussion, as discussed in section 383 8. 385 7.3. Non-Adjacent Contact Registration (Path) and Service Route 386 Discovery 388 The Path and Service-Route behavior and considerations for this 389 document's mechanism are exactly the same as defined in [draft-gin]. 390 The [draft-gin] Path and Service-Route model has no dependency on 391 the global uniqueness of the AoR username, nor on being digits or an 392 E.164. 394 8. Open Issues 396 This document has several open issues, which were noted previously. 397 They center around the handling of Local-Numbers. Local-Numbers are 398 difficult because they are doubly-scoped: once at the URI level by 399 the domain name, and internally by the phone-context URI user 400 parameter. The authoritative system for the Local-Number user 401 portion (the system(s) which knows what they are and how to process 402 them) is not necessarily identified by the URI's domain name, but 403 rather may be identified by the phone-context's value. 405 If the phone-context identifies the SSP domain, all's well - but 406 that's rarely the case. More likely is that it identifies an E.164 407 number, or a sub-domain of the SSP, or another domain entirely. 408 This causes issues with certain functions such as the reg-event 409 package, which has been identified as an open issue. 411 9. Examples 413 These will be fleshed out more in later versions of the draft, with 414 explanations of the processing performed at each step. For the time 415 being, they just show the basic syntax described above. 417 9.1. Usage Scenario: Basic Registration case 1 419 This example shows a basic bulk REGISTER transaction, followed by an 420 INVITE addressed to one of the registered terminals. 422 Internet SSP PBX 423 | | | 424 | |REGISTER | 425 | |Contact: | 426 | |<--------------------------------| 427 | | | 428 | |200 OK | 429 | |-------------------------------->| 430 | | | 431 |INVITE | | 432 |sip:bob@ssp.example.com | | 433 |------------------------------->| | 434 | | | 435 | |INVITE | 436 | |sip:bob@198.51.100.3 | 437 | |-------------------------------->| 439 REGISTER sip:ssp.example.com SIP/2.0 440 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 441 Max-Forwards: 70 442 To: 443 From: ;tag=a23589 444 Call-ID: 843817637684230998sdasdh09 445 CSeq: 1826 REGISTER 446 Proxy-Require: gin 447 Require: gin 448 Supported: path 449 Contact: 450 Expires: 7200 451 Content-Length: 0 452 INVITE sip:bob@ssp.example.com SIP/2.0 453 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 454 Max-Forwards: 69 455 To: 456 From: ;tag=456248 457 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 458 CSeq: 24762 INVITE 459 Contact: 460 Content-Type: application/sdp 461 Content-Length: ... 463 465 INVITE sip:bob@198.51.100.3 SIP/2.0 466 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 467 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 468 Max-Forwards: 68 469 To: 470 From: ;tag=456248 471 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b 472 CSeq: 24762 INVITE 473 Contact: 474 Content-Type: application/sdp 475 Content-Length: ... 477 479 9.2. Usage Scenario: Basic Registration case 2 481 This example shows a basic bulk REGISTER transaction, followed by an 482 INVITE addressed to one of the registered terminals, for a Local- 483 Number AoR. 485 Internet SSP PBX 486 | | | 487 | |REGISTER | 488 | |Contact:| 489 | |<--------------------------------| 490 | | | 491 | |200 OK | 492 | |-------------------------------->| 493 | | | 494 |INVITE | | 495 |sip:1234;ext=678 | | 496 | ;phone-context=+1212555 | | 497 | @ssp.example.com | | 498 |------------------------------->| | 499 | | | 500 | |INVITE | 501 | |sip:1234;ext=678 | 502 | | ;phone-context=+1212555 | 503 | | @198.51.100.3;f=b | 504 | |-------------------------------->| 506 REGISTER sip:ssp.example.com SIP/2.0 507 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 508 Max-Forwards: 70 509 To: 510 From: ;tag=a23589 511 Call-ID: 843817637684230998sdasdh09 512 CSeq: 1826 REGISTER 513 Proxy-Require: gin 514 Require: gin 515 Supported: path 516 Contact: 517 Expires: 7200 518 Content-Length: 0 519 INVITE sip:1234;ext=678;phone-context=+1212555 520 @ssp.example.com SIP/2.0 521 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 522 Max-Forwards: 69 523 To: 524 From: ;tag=456248 525 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 526 CSeq: 24762 INVITE 527 Contact: 528 Content-Type: application/sdp 529 Content-Length: ... 531 533 INVITE sip:1234;ext=678;phone-context=+1212555 534 @198.51.100.3;f=b SIP/2.0 535 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 536 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 537 Max-Forwards: 68 538 To: 539 From: ;tag=456248 540 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b 541 CSeq: 24762 INVITE 542 Contact: 543 Content-Type: application/sdp 544 Content-Length: ... 546 548 10. IANA Considerations 550 This document makes no request of IANA. 552 11. Security Considerations 554 This section is still TBD, but it should follow/have the same issues 555 as [draft-gin]. 557 12. Acknowledgements 559 Thanks to Adam Roach for providing text copied from [draft-gin]. 561 13. Informative References 563 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 564 A., Peterson, J., Sparks, R., Handley, M., and E. 565 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 566 June 2002. 568 [RFC3263] Rosenberg, J., Schulzrinne, H., "Session Initiation 569 Protocol (SIP): Locating SIP Servers", RFC 3263, June 570 2002. 572 [RFC3327] Willis, D., and Hoeneisen, B., "Session Initiation 573 Protocol (SIP) Extension Header Field for Registering 574 Non-Adjacent Contacts", RFC 3327, December 2002. 576 [RFC3455] Garcia-Martin, M., Henrikson, E., and Mills, D., "Private 577 Header (P-Header) Extensions to the Session Initiation 578 Protocol (SIP) for the 3rd-Generation Partnership Project 579 (3GPP)", RFC 3455, January 2003. 581 [RFC3608] Willis, D., and Hoeneisen, B., "Session Initiation 582 Protocol (SIP) Extension Header Field for Service Route 583 Discovery During Registration", RFC 3608, October 2003. 585 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 586 3966, December 2004. 588 [RFC4244] Barnes, M. (ed.), "An Extension to the Session Initiation 589 Protocol (SIP) for Request History Information", RFC 590 4244, November 2005. 592 [RFC5486] Malas, D., and Meyer, D., "Session Peering for Multimedia 593 Interconnect (SPEERMINT) Terminology", RFC 5486, March 594 2009. 596 [draft-gin] Roach, A. B., "Registration for Multiple Phone Numbers 597 in the Session Initiation Protocol (SIP)", draft-ietf- 598 martini-gin-01, April 2010. 600 [draft-4244bis] Barnes, M., et al, "An Extension to the Session 601 Initiation Protocol (SIP) for Request History 602 Information", draft-ietf-sipcore-rfc4244bis-00, February 603 2010. 605 Author's Address 607 Hadriel Kaplan 608 Acme Packet 609 71 Third Ave. 610 Burlington, MA 01803, USA 611 Email: hkaplan@acmepacket.com 613 Appendix A - Why non-E.164 AoRs may need processing by SSPs 615 There is some debate about how a non-E.164 AoR could even be 616 received by the SSP for processing to begin with. This section 617 describes how such could be the case. 619 It should be noted that this document only deals with SIP AoRs of 620 the same URI domain name as that of the REGISTER's To URI - namely 621 the SSP's domain. 623 A SIP Request targeted to a Local-Number could require processing by 624 the SSP because: 625 - The SSP provides IP-Centrex type services for some of the AoRs 626 of an Enterprise, for example for small branches, while 627 providing SIP-Trunk service to the main IP-PBX(s). Requests 628 from the IP-Centrex UAs will thus be targeted to Local-numbers 629 as they are received by the SSP Proxy on their way to the IP- 630 PBX. 631 - The SSP provides inbound extension dialing, for example by 632 offering private calling-card services, such that a E.164 633 number call is terminated by an Application Server of the SSP 634 which authenticates the caller belongs to an Enterprise and 635 then allows private extension dialing, as a UAC, thereby 636 originating a new SIP session Request using a Local-Number 637 target. 639 A SIP Request targeted to an Email-style AoR could require 640 processing by an SSP because: 641 - The SSP provides Email-style AoRs for business customers - for 642 example "sip:bob@ssp.example.net". 643 - The SSP has a sub-division or sub-entity which uses IP-PBX 644 Martini trunks into the SSP main domain, for which the SSP 645 provides AoRs of the main SSP domain - for example, a sales 646 division IP-PBX in a sub-domain of sales.ssp.example.net, but 647 for which the SSP provides an AoR of 648 "sip:sales@ssp.example.net". 649 - The Email-style AoR is scoped to the Enterprise's domain, but 650 the Request originated from within the SSP - for example by one 651 of its subscriber SIP UAs. Since SIP UAs generally send their 652 Requests through their SSP's proxies, the Request will be 653 processed by them first. This type of AoR (i.e., one scoped 654 outside of the SSP's domain) is NOT in scope for this document. 656 There are other possibilities as well, of course, but this section 657 is only intended to provide some basic rational for why it is 658 possible for a local-number or email-style AoR to be used and appear 659 in the SSP. 661 Appendix B - Issues with non-E.164 Identifiers 663 At the initial outset of Martini's work, the problem space to work 664 on was narrowed to E.164 numbers only, for several reasons. This 665 section attempts to identify the reasons in detail, and address 666 them. 668 o Globally unique AoR 670 One of the initial benefits cited for only supporting E.164 is that 671 an E.164 user name is globally unique by itself, and thus changing 672 the host portion of the Request-URI does not impact the identity of 673 the intended target of the Request. 675 Fortunately, [draft-gin] does not in fact rely on that property of 676 the AoR username. What [draft-gin] does is emulate what would have 677 happened had the IP-PBX Registered each E.164-based AoR separately. 678 It is not in fact Registering an "E.164 number" - it is Registering 679 typical [RFC3261] AoRs, which just happen to be formatted as E.164 680 numbers. For example, the IP-PBX is not implicitly Registering the 681 identity of "+12125551212", it is instead implicitly Registering for 682 the SIP AoR of "sip:+12125551212@ssp.example.net". The SSP may well 683 associate and route requests for "tel:+12125551212" to that AoR's 684 Registered contact, but in so doing it can be described as logically 685 performing a transformation of the TEL URI to a SIP URI and looking 686 up that SIP URI in its location service database. 688 Interestingly, the AoR that was implicitly Registered is globally 689 unique, *regardless* of the fact that the user portion happens to be 690 an E.164 number. It is globally unique, because the AoR is of the 691 domain "ssp.example.net" - just as any [RFC3261] SIP AoR is globally 692 unique due to its host domain portion. 694 o Registered Contact Username 696 The other rational for needing a globally unique identifier is the 697 Registered Contact URI. Because the Martini model performs a bulk 698 Registration and uses a defined expansion rule for how to expand the 699 Registered Contact into a unique Contact URI per AoR, the rule's 700 output needs to be unambiguous and generate a unique Contact per 701 AoR. For example, if the IP-PBX has multiple SSPs it Registers 702 into, it can't just receive a request to "sip:bob@192.1.2.3", 703 because it won't know if that's to "sip:bob@ssp1.example.net" or 704 "sip:bob@ssp2.example.net", which may be different users. 706 This is a real problem, but what it requires/needs is a globally 707 unique Contact URI, not a globally unique AoR user name. In fact, 708 [draft-gin] suffers from this problem as well, in some ways. 709 Although it is unambiguous what the target of the request may be 710 (because the username is globally unique), it still may be important 711 for the IP-PBX to know which implicitly Registered AoR the request 712 was resolved from, before being sent to it. For example, the IP-PBX 713 may want to know the request is for 714 "sip:+12125551212@ssp.example.net.uk" vs. 715 "sip:+12125551212@ssp.example.net.fr". The IP-PBX *would* have 716 Registered separately for each domain, but if its contact is the 717 same (and if it went through the same path, etc.), there would be no 718 unique identifier for inbound Requests. 720 This problem could be solved numerous ways. For one, this is a 721 similar issue to that solved by [RFC4244] or being worked on in 722 [draft-4244bis]. Secondly, and more importantly, the IP-PBX could 723 simply make the Contact unique by inserting a parameter in the 724 Contact URI it Registers, or inserting a Path header field with 725 unique information per Register target domain. 727 Regardless of the solution, it is solvable without impacting the 728 user portion of the AoR being implicitly Registered. Therefore, 729 there is no need to make the username portion globally unique, and 730 thus once again there is no need for [draft-gin] to only be used for 731 E.164 AoRs. 733 o Avoiding syntax mismatches 735 Another issue with the Contact bulk-expansion rule and implicitly 736 Registering Contact URIs is guaranteeing the Registrar uses a 737 username the IP-PBX will accept/expect. In particular, there are 738 numerous syntactic forms a phone number can take in the user portion 739 of a SIP URI, for example with or without a leading "+", or with 740 visual-separators or not. Since the IP-PBX is not actually 741 Registering an explicit Contact URI user portion for each AoR, there 742 needs to be an assurance that the format of the expanded-to user 743 portion matches what it expects. 745 For Email-style URIs, this is actually quite straight-forward, 746 because there is only one form the user name can take: if the AoR is 747 "sip:bob@ssp.example.net", then a simple AoR-user-based expansion 748 rule would suffice because "bob" can only have one form. (e.g., even 749 case-sensitivity matters) Thus there is no syntax mismatch concern 750 for generic string names. 752 Local-Numbers in TEL URIs, or SIP URIs formed from TEL URIs, are 753 more difficult, however. Like E.164 (i.e., global-number) formats, 754 they are not as well constrained. They may have visual-separators, 755 for example, and if their phone-context parameter value is a global- 756 number, it too has the same formatting "looseness" of E.164 number 757 user names. 759 To make matters worse, the SSP does not always have full knowledge 760 of all Local-Numbers it can route requests for, nor of their URI 761 user-portion parameters.