idnits 2.17.1 draft-kaplan-martini-with-olive-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 374: '...tact" URI in the REGISTER message MUST...' RFC 2119 keyword, line 448: '... following [RFC3966], and that form MUST be the one used for routing,...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 8, 2010) is 5129 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3327' is defined on line 710, but no explicit reference was found in the text == Unused Reference: 'RFC3455' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'RFC3608' is defined on line 719, 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 (~~), 4 warnings (==), 3 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: Informational 5 Expires: October 8, 2011 April 8, 2010 7 SIP MARTINI with 8 Other Logical Identifier Values which are not E.164 (OLIVE) 9 draft-kaplan-martini-with-olive-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 October 8, 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 respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 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. This document defines a means for other, non- 54 E.164 AoRs to be used with 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 3.1. Why non-E.164 AoRs may need processing by SSPs.........4 62 3.2. The issues with non-E.164 Identifiers..................5 63 3.2.1 Globally unique AoR 5 64 3.2.2 Registered Contact Username 5 65 3.2.3 Avoiding syntax mismatches 6 66 4. The Solution - an Overview..................................7 67 5. Registering for AoRs........................................8 68 5.1. Registering Local Number AoRs..........................9 69 6. SSP Processing of Inbound Non-E.164 Requests...............10 70 6.1. Processing of Local-Number Requests...................10 71 7. Interaction with Other Mechanisms..........................10 72 7.1. Globally Routable User-Agent URIs (GRUU)..............10 73 7.2. Registration Event Package............................11 74 7.3. Non-Adjacent Contact Registration (Path) and Service Route 75 Discovery.....................................................11 76 8. Open Issues................................................11 77 9. Examples...................................................12 78 9.1. Usage Scenario: Basic Registration case 1.............12 79 9.2. Usage Scenario: Basic Registration case 2.............14 80 10. IANA Considerations........................................15 81 11. Security Considerations....................................15 82 12. Acknowledgements...........................................15 83 13. Informative References.....................................16 84 Author's Address.................................................17 86 1. Introduction 88 In many deployed SIP Service Provider (SSP) architectures, it is 89 common to use REGISTER requests to provide the reachability 90 information for IP-PBXs, instead of DNS-based resolution and 91 routing. An IETF-defined mechanism for doing so is being worked on 92 in the Martini Working Group, in [draft-gin]. 94 The current Martini mechanism only supports E.164-based AoR's, 95 however in actual deployments private-extension or "local" numbers 96 are used for hosted and carrier-provided intra-Enterprise calling 97 services, and domain-scoped "email-style" URIs may become more 98 popular in the near future. Neither of these forms of AoRs are 99 supported by the current Martini mechanism. This document defines a 100 means by which they can be supported, in a manner consistent with 101 [RFC3261] and [draft-gin]. 103 2. Definitions 105 For brevity's sake, this document uses the word "request" instead of 106 "out-of-dialog request", but in all case means out-of-dialog 107 request. 109 AoR: address-of-record, as defined by RFC 3261: a URI by which the 110 user is canonically known (e.g., on their business cards, in the 111 From header field of their requests, in the To header field of 112 REGISTER requests, etc.). 114 Local-Number: an AoR which follows the form of local-number in 115 [RFC3966], but may be encoded in a SIP or TEL URI. The local-number 116 contains a 'phone-context' parameter identifying the scope of its 117 number. 119 Email-style URI: a SIP AoR which does not identify a global E.164 120 number or local-number. 122 Implicit Registration: implicitly providing the reachability 123 information for something other than the AoR explicitly indicated in 124 the Register transaction. 126 Reachability Information: a set of URI's identifying the host and 127 path of Proxies to reach that host; like any URI, these URI's may 128 identify the specific connection transport, IP Address, and port 129 information, or they may only identify FQDN's. 131 SSP: SIP Service Provider, as defined by [RFC5486]. 133 3. Background on Current Martini Mechanism 135 The current Martini mechanism, defined in [draft-gin], allows a SIP 136 UA such as an IP-PBX to Register a set of E.164 AoRs in "bulk". 137 Instead of creating a separate REGISTER transaction for every E.164 138 AoR, the IP-PBX sends one REGISTER request with a 'bnc' Contact URI 139 parameter which indicates the Contact URI needs to be expanded in 140 the Registrar's location service database. The expansion is such 141 that each E.164 user number becomes the user portion of the 142 Registered Contact URI, one for each implicitly Registered E.164 143 AoR. 145 SIP Request routing to the Registered E.164 AoR then follows normal 146 [RFC3261] procedures, replacing the Request URI with the (expanded) 147 Registered Contact URI, and adding any Path information as a Route 148 set, etc. 150 3.1. Why non-E.164 AoRs may need processing by SSPs 152 There is some debate about how a non-E.164 AoR could even be 153 received by the SSP for processing to begin with. This section 154 describes how such could be the case. 156 It should be noted that this document only deals with SIP AoRs of 157 the same URI domain name as that of the REGISTER's To URI - namely 158 the SSP's domain. 160 A SIP Request targeted to a Local-number AoR could require 161 processing by the SSP because: 162 - The SSP provides IP-Centrex type services for some of the AoRs 163 of an Enterprise, for example for small branches, while 164 providing SIP-Trunk service to the main IP-PBX(s). Requests 165 from the IP-Centrex UAs will thus be targeted to Local-numbers 166 as they are received by the SSP Proxy on their way to the IP- 167 PBX. 168 - The SSP provides inbound extension dialing, for example by 169 offering private calling-card services, such that a E.164 170 number call is terminated by an Application Server of the SSP 171 which authenticates the caller belongs to an Enterprise and 172 then allows private extension dialing, as a UAC, thereby 173 originating a new SIP session Request using a Local-Number 174 target AoR. 176 A SIP Request targeted to an Email-style AoR could require 177 processing by an SSP because: 178 - The SSP provides Email-style AoRs for business customers - for 179 example "sip:bob@ssp.example.net". 180 - The SSP has a sub-division or sub-entity which uses IP-PBX 181 Martini trunks into the SSP main domain, for which the SSP 182 provides AoRs of the main SSP domain - for example, a sales 183 division IP-PBX in a sub-domain of sales.ssp.example.net, but 184 for which the SSP provides an AoR of 185 "sip:sales@ssp.example.net". 186 - The Email-style AoR is scoped to the Enterprise's domain, but 187 the Request originated from within the SSP - for example by one 188 of its subscriber SIP UAs. Since SIP UAs generally send their 189 Requests through their SSP's proxies, the Request will be 190 processed by them first. This type of AoR (i.e., one scoped 191 outside of the SSP's domain) is NOT in scope for this document. 193 There are other possibilities as well, of course, but this section 194 is only intended to provide some basic rational for why it is 195 possible for a local-number or email-style AoR to be used and appear 196 in the SSP. 198 3.2. The issues with non-E.164 Identifiers 200 At the initial outset of Martini's work, the problem space to work 201 on was narrowed to E.164 numbers only, for several reasons. This 202 section attempts to identify the reasons in detail, and address 203 them. 205 3.2.1 Globally unique AoR 207 One of the initial benefits cited for only supporting E.164 is that 208 an E.164 user name is globally unique by itself, and thus changing 209 the host portion of the Request-URI does not impact the identity of 210 the intended target of the Request. 212 Fortunately, [draft-gin] does not in fact rely on that property of 213 the AoR username. What [draft-gin] does is emulate what would have 214 happened had the IP-PBX Registered each E.164 AoR separately. It is 215 not in fact Registering an "E.164 number" - it is Registering 216 typical [RFC3261] AoRs, which just happen to be formatted as E.164 217 numbers. For example, the IP-PBX is not implicitly Registering the 218 identity of "+12125551212", it is instead implicitly Registering for 219 the SIP AoR of "sip:+12125551212@ssp.example.net". The SSP may well 220 associate and route requests for "tel:+12125551212" to that AoR's 221 Registered contact, but in so doing it can be described as logically 222 performing a transformation of the TEL URI to a SIP URI and looking 223 up that SIP URI in its location service database. 225 Interestingly, the AoR that was implicitly Registered is globally 226 unique, *regardless* of the fact that the user portion happens to be 227 an E.164 number. It is globally unique, because the AoR is of the 228 domain "ssp.example.net" - just as any [RFC3261] SIP AoR is globally 229 unique due to its host domain portion. 231 3.2.2 Registered Contact Username 233 The other rational for needing a globally unique identifier is the 234 Registered Contact URI. Because the Martini model performs a bulk 235 Registration and uses a defined expansion rule for how to expand the 236 Registered Contact into a unique Contact URI per AoR, the rule's 237 output needs to be unambiguous and generate a unique Contact per 238 AoR. For example, if the IP-PBX has multiple SSPs it Registers 239 into, it can't just receive a request to 240 "sip:bob@pbx.enterprise.com", because it won't know if that's to 241 "sip:bob@ssp1.example.net" or "sip:bob@ssp2.example.net", which may 242 be different users. 244 This is a real problem, but what it requires/needs is a globally 245 unique Contact URI, not a globally unique AoR user name. In fact, 246 [draft-gin] suffers from this problem as well, in some ways. 247 Although it is unambiguous what the target of the request may be 248 (because the username is globally unique), it still may be important 249 for the IP-PBX to know which implicitly Registered AoR the request 250 was resolved from, before being sent to it. For example, the IP-PBX 251 may want to know the request is for 252 "sip:+12125551212@ssp.example.net.uk" vs. 253 "sip:+12125551212@ssp.example.net.fr". The IP-PBX *would* have 254 Registered separately for each domain, but if its contact is the 255 same (and if it went through the same path, etc.), there would be no 256 unique identifier for inbound Requests. 258 This problem could be solved numerous ways. For one, this is a 259 similar issue to that solved by [RFC4244] or being worked on in 260 [draft-4244bis]. Secondly, and more importantly, the IP-PBX could 261 simply make the Contact unique by inserting a parameter in the 262 Contact URI it Registers, or inserting a Path header field with 263 unique information per Register target domain. 265 Regardless of the solution, it is solvable without impacting the 266 user portion of the AoR being implicitly Registered. Therefore, 267 there is no need to make the username portion globally unique, and 268 thus once again there is no need for [draft-gin] to only be used for 269 E.164 AoRs. 271 3.2.3 Avoiding syntax mismatches 273 Another issue with the Contact bulk-expansion rule and implicitly 274 Registering Contact URIs is guaranteeing the Registrar uses a 275 username the IP-PBX will accept/expect. In particular, there are 276 numerous syntactic forms a phone number can take in the user portion 277 of a SIP URI, for example with or without a leading "+", or with 278 visual-separators or not. Since the IP-PBX is not actually 279 Registering an explicit Contact URI user portion for each AoR, there 280 needs to be an assurance that the format of the expanded-to user 281 portion matches what it expects. 283 For Email-style URIs, this is actually quite straight-forward, 284 because there is only one form the user name can take: if the AoR is 285 "sip:bob@ssp.example.net", then a simple AoR-user-based expansion 286 rule would suffice because "bob" can only have one form. (e.g., even 287 case-sensitivity matters) Thus there is no syntax mismatch concern 288 for generic string names. 290 Local-Numbers in TEL URIs, or SIP URIs formed from TEL URIs, are 291 more difficult, however. Like E.164 (i.e., global-number) formats, 292 they are not as well constrained. They may have visual-separators, 293 for example, and if their phone-context parameter value is a global- 294 number, it too has the same formatting "looseness" of E.164 number 295 user names. 297 To make matters worse, Local-Numbers are frequently NOT within the 298 scope of the SSP, or at least the SSP does not always have full 299 knowledge of all Local-Numbers it can route requests for. 301 This document will address this Local-Number issue, but for the case 302 of Local-Numbers scoped to the SSP's domain only. Local-Numbers 303 scoped to a phone-context that is an E.164 or not the same domain 304 name as the REGISTER transaction's explicit AoR are outside the 305 scope of this document. 307 This also remains an open issue for discussion, as discussed in 308 section 8. 310 4. The Solution - an Overview 312 The general concept proposed in this document is to simply apply 313 [draft-gin] for any set of AoRs of the Registered-to domain, for any 314 valid set of user strings as defined in [RFC3261]. The [draft-gin] 315 REGISTER request would cause the Registrar to populate the set of 316 AoRs to Contact bindings, as it did before. 318 The Contact URI user portion would also be "expanded", using the 319 same user portion as that of the implicitly Registered AoRs. In the 320 case of a Local-Number, for the specific scopes described later, the 321 username is "normalized" in the same manner as [draft-gin]. 323 Note that the list of AoRs associated with a PBX is a matter of 324 local provisioning at the SSP and at the PBX, as it was in [draft- 325 gin]. The mechanism defined in this document does not provide any 326 means to detect or recover from provisioning mismatches (although 327 the registration event package can be used as a standardized means 328 for auditing such AoRs). 330 No new option-tag is required, because this document's mechanism 331 does not require any changes in Martini [draft-gin] Registration or 332 subsequent [RFC3261] routing behavior in the IP-PBX or any proxies 333 along the path. The routing follows the [RFC3261] Registered AoR- 334 contact resolution model, which is a basic function of SIP. 336 The only SIP devices affected by this document's mechanism is the 337 SSP's Registrar, which needs to update the appropriate AoR entries, 338 and any proxy/ies of the SSP which perform route resolution by 339 looking up the contents of the (logical) location-service database. 340 Since such proxies may not even be in the path of the REGISTER 341 request, an option-tag will not help. And since the Registrar and 342 Proxies in question are all under control of the same administrative 343 entity (the SSP), it is reasonable to expect them all to support 344 this document's mechanism, if any do. 346 5. Registering for AoRs 348 This document's mechanism relies on the Martini [draft-gin] 349 Registration mechanism. The IP-PBX Registers into the SSP, using a 350 REGISTER request with the [draft-gin] option-tag in the Require and 351 Proxy-Require header fields, and a Contact URI containing the 352 [draft-gin] "bnc" URI parameter and no user portion. After the PBX 353 is authenticated, the registrar updates its location service so that 354 each of the AoRs associated with the PBX creates a unique AOR to 355 Contact mapping. Semantically, each of these mappings will be 356 treated as a unique row in the location service. The actual 357 implementation may, of course, perform internal optimizations to 358 reduce the amount of memory used to store such information. 360 For each of these unique rows, the AOR will be in the format that 361 the SSP expects to receive from external parties (e.g. 362 "sip:bob@ssp.example.com"), and the corresponding Contact will be 363 formed adding a user portion to the REGISTER's Contact URI 364 containing the AoR user name and removing the "bnc" parameter. For 365 example, if the "Contact" header field contains the URI 366 , then the Contact value 367 associated with the aforementioned AOR will be 368 . 370 Local-Numbers have slightly different Contact URI expansion rules, 371 as defined later. 373 As in [draft-gin], aside from the "bnc" parameter, all URI 374 parameters present in the "Contact" URI in the REGISTER message MUST 375 be copied to the Contact value stored in the location service. 377 Note that the location service database, and any entry model 378 described here, is purely an abstract concept used by [RFC3261], 379 [draft-gin], and this document; an actual implementation may do 380 whatever it likes internally, so long as the external behavior 381 follows the model. For example, if an SSP does not maintain any 382 specific knowledge of the Local Number dial-plan, but simply 383 performs prefix or default routing for an Enterprise's private 384 extensions, the SSP could just route based on the E.164 phone- 385 context field value without having a separate physical "AoR" 386 database entry for each local number of that context. 388 5.1. Registering Local Number AoRs 390 Local-Numbers present a complexity for AoR Registration, because 391 their user portion is scoped to the phone-context's value. In 392 practice the SSP domain identified by the entire AoR URI domain name 393 may not have specific knowledge of any user name within a given 394 phone-context's scope. In fact, the Local-Number TEL URI parameters 395 (which are URI user parameters in SIP URIs), likely only have 396 meaning to the ultimate target of the request, or some entity which 397 is authoritative for the phone-context's user names. Those 398 parameters cannot be removed by the SSP if it does not actually 399 process the user portions of the Local-Number. (i.e., if it does not 400 have the dial-plan, etc.) 402 With regard to this document's mechanism, what this means is that 403 such an SSP cannot physically instantiate an AoR in a database for 404 every possible Local-Number and cannot physically instantiate an 405 expanded Contact URI for every possible Local-Number user name with 406 every possible user parameter. That does not inhibit the mechanism 407 from working or being usable, however, because the location-service 408 database model is purely an abstract concept. What's important is 409 that the route-resolving Proxy be able to lookup and replace an AoR 410 it is authoritative for, to a Registered Contact URI, such that the 411 resultant Request URI matches what the IP-PBX expects to receive. 413 It is "safe" to do this because the explicitly Registered Contact 414 URI of the [draft-gin] REGISTER request had no user portion, and 415 thus no possible URI user parameters. As defined in [draft-gin], 416 the Contact URI parameters of the REGISTER are saved and reused, but 417 not URI user parameters. 419 There are multiple ways of describing the logical AoR instantiation 420 and Contact URI expansion rules. They could be described as 421 covering every possible ABNF expansion, such that every possible 422 user and parameter logically exists in the location-service database 423 (but obviously not physically exists). Or it could be described as 424 only the phone-context value itself being an "AoR" entry and Contact 425 URI expansion, with a policy to allow any and all user names and 426 parameters to be copied instead of replaced by the Contact URI. 428 This remains an open issue for discussion, as discussed in section 429 8. 431 Regardless, for an implicitly Registered SIP AoR with a URI user 432 portion matching the syntax outlined for "local-number" TEL URIs in 433 [RFC3966]: if the 'phone-context' URI user parameter value is the 434 same SSP domain as that in the REGISTER transaction's To URI, then 435 Contact is then formed following the other AoR models, EXCEPT that 436 all URI user parameters are also included, other than the phone- 437 context parameter. For example, if the logically provisioned "AoR" 438 from the previous examples were: "sip:12345;ext=678;phone- 439 context=ssp.example.net@ssp.example.net", it would logically get an 440 automatically generated Contact URI of 441 . 443 Note that in practice it is not uncommon to receive a SIP URI which 444 does not strictly comply with the formatting rules of [RFC3966], but 445 is processed as if it were, based on local policies. That is legal, 446 of course, but from a logical perspective the SIP URI is actually 447 retargeted or transformed into the syntactically valid form 448 following [RFC3966], and that form MUST be the one used for routing, 449 Contact URI expansions, etc. Likewise, if the URI were a TEL URI, 450 it would be logically transformed into a SIP URI of the SSP's domain 451 before executing the rules. 453 6. SSP Processing of Inbound Non-E.164 Requests 455 The SSP Proxy/Registrar (or equivalent entity) performs traditional 456 Proxy/Registrar behavior, based on the mapping described in Section 457 5 and [draft-gin]. For Local-Numbers in particular, the following 458 section provides additional detail. 460 6.1. Processing of Local-Number Requests 462 As discussed in section 5.1, Local-Numbers present a special case 463 which may need to be handled with more explicit rules than [RFC3261] 464 or [draft-gin] currently prescribe. If the location-service 465 database is described as having every possible expansion, then the 466 Request would be processed in the same manner as section 5 and 467 [draft-gin]. 469 7. Interaction with Other Mechanisms 471 The following sections describe the means by which this mechanism 472 interacts with relevant REGISTER-related extensions currently 473 defined by the IETF. 475 Currently, the descriptions are somewhat informal, and omit some 476 details for the sake of brevity. If the MARTINI working group 477 expresses interest in furthering the mechanism described by this 478 document, they will be fleshed out with more detail and formality. 480 7.1. Globally Routable User-Agent URIs (GRUU) 482 The GRUU mechanism for this document's mechanism works exactly the 483 same way as defined in [draft-gin]. The [draft-gin] GRUU mechanism 484 has no dependency on the global uniqueness of the AoR username, nor 485 on being digits or an E.164. 487 7.2. Registration Event Package 489 The Registration Event Packet behavior for this document's mechanism 490 works exactly the same way as defined in [draft-gin]. The [draft- 491 gin] reg-event model has no dependency on the global uniqueness of 492 the AoR username, nor on being digits or an E.164. 494 There is, however, an issue for Local-Numbers, if the SSP does not 495 actually know the full list of Local-Number user names in the given 496 phone-context scope. In such a case, it is TBD for how to handle 497 this. One obvious way would be to define a syntactic format for the 498 AoR and Contact URIs which only includes the phone-context value and 499 makes it clear the user portion and any other parameters are 500 unknown, such as "sip:!.*!;phone- 501 context=ssp.example.com@ssp.example.com". Since a "!" is not a 502 legal character in a Local-Number user name, but is legal in a SIP 503 URI user name, it would be both ABNF compliant and unambiguous from 504 Local-Numbers. 506 This remains an open issue for discussion, as discussed in section 507 8. 509 7.3. Non-Adjacent Contact Registration (Path) and Service Route 510 Discovery 512 The Path and Service-Route behavior and considerations for this 513 document's mechanism are exactly the same as defined in [draft-gin]. 514 The [draft-gin] Path and Service-Route model has no dependency on 515 the global uniqueness of the AoR username, nor on being digits or an 516 E.164. 518 8. Open Issues 520 This document has several open issues, which were noted previously. 521 They center around the handling of Local-Numbers. Local-Numbers are 522 difficult because they are doubly-scoped: once at the URI level by 523 the domain name, and internally by the phone-context URI user 524 parameter. The authoritative system for the Local-Number user 525 portion (the system(s) which knows what they are and how to process 526 them) is not identified by the URI's domain name, but rather 527 identified by the phone-context's value. 529 If the phone-context identifies the SSP domain, all's well - but 530 that's rarely the case. More likely is that it identifies an E.164 531 number, or a sub-domain of the SSP, or another domain entirely. 533 This document tries to propose a mechanism to support the case when 534 the phone-context identifies the SSP's domain, and which has a 535 matching SIP AoR implicitly Registered by the IP-PBX. However, even 536 in such a case, it does not imply the SSP has authoritative 537 information for the user name - typically the IP-PBX does. This 538 causes issues with certain functions such as the reg-event package. 540 In theory, this can probably be made to work as defined in this 541 document, but there is an alternative: if we had a model for using 542 the Registered reachability information of [draft-gin] for routing 543 of requests which are not AoRs of the Registered-to domain (e.g., to 544 an AoR of "sip:charlie@pbx.example.com"), then Local-Numbers could 545 follow that routing model instead. This would follow a more natural 546 [RFC3263] model, since effectively the phone-context indicates that 547 the authoritative administrative entity is not in fact the SSP. 549 A draft detailing how [draft-gin] can be used in such a model is 550 forthcoming. 552 9. Examples 554 These will be fleshed out more in later versions of the draft, with 555 explanations of the processing performed at each step. For the time 556 being, they just show the basic syntax described above. 558 9.1. Usage Scenario: Basic Registration case 1 560 This example shows a basic bulk REGISTER transaction, followed by an 561 INVITE addressed to one of the registered terminals. 563 Internet SSP PBX 564 | | | 565 | |REGISTER | 566 | |Contact: | 567 | |<--------------------------------| 568 | | | 569 | |200 OK | 570 | |-------------------------------->| 571 | | | 572 |INVITE | | 573 |sip:bob@ssp.example.com | | 574 |------------------------------->| | 575 | | | 576 | |INVITE | 577 | |sip:bob@198.51.100.3 | 578 | |-------------------------------->| 579 REGISTER sip:ssp.example.com SIP/2.0 580 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 581 Max-Forwards: 70 582 To: 583 From: ;tag=a23589 584 Call-ID: 843817637684230@998sdasdh09 585 CSeq: 1826 REGISTER 586 Proxy-Require: bulknumbercontact 587 Require: bulknumbercontact 588 Contact: 589 Expires: 7200 590 Content-Length: 0 592 INVITE sip:bob@ssp.example.com SIP/2.0 593 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 594 Max-Forwards: 69 595 To: 596 From: ;tag=456248 597 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 598 CSeq: 24762 INVITE 599 Contact: 600 Content-Type: application/sdp 601 Content-Length: ... 603 605 INVITE sip:bob@198.51.100.3 SIP/2.0 606 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 607 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 608 Max-Forwards: 68 609 To: 610 From: ;tag=456248 611 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b 612 CSeq: 24762 INVITE 613 Contact: 614 Content-Type: application/sdp 615 Content-Length: ... 617 619 9.2. Usage Scenario: Basic Registration case 2 621 This example shows a basic bulk REGISTER transaction, followed by an 622 INVITE addressed to one of the registered terminals, for a Local- 623 Number AoR. 625 Internet SSP PBX 626 | | | 627 | |REGISTER | 628 | |Contact:| 629 | |<--------------------------------| 630 | | | 631 | |200 OK | 632 | |-------------------------------->| 633 | | | 634 |INVITE | | 635 |sip:1234;ext=678 | | 636 | ; ssp.example.com | | 637 | @ssp.example.com | | 638 |------------------------------->| | 639 | | | 640 | |INVITE | 641 | |sip:1234;ext=678 | 642 | | @198.51.100.3;f=b | 643 | |-------------------------------->| 645 REGISTER sip:ssp.example.com SIP/2.0 646 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 647 Max-Forwards: 70 648 To: 649 From: ;tag=a23589 650 Call-ID: 843817637684230@998sdasdh09 651 CSeq: 1826 REGISTER 652 Proxy-Require: bulknumbercontact 653 Require: bulknumbercontact 654 Contact: 655 Expires: 7200 656 Content-Length: 0 657 INVITE sip:1234;ext=678;phone-context=ssp.example.com 658 @ssp.example.com SIP/2.0 659 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 660 Max-Forwards: 69 661 To: 662 From: ;tag=456248 663 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 664 CSeq: 24762 INVITE 665 Contact: 666 Content-Type: application/sdp 667 Content-Length: ... 669 671 INVITE sip:1234;ext=678@198.51.100.3;f=b SIP/2.0 672 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 673 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 674 Max-Forwards: 68 675 To: 676 From: ;tag=456248 677 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b 678 CSeq: 24762 INVITE 679 Contact: 680 Content-Type: application/sdp 681 Content-Length: ... 683 685 10. IANA Considerations 687 This document makes no request of IANA. 689 11. Security Considerations 691 This section is still TBD, but it should follow/have the same issues 692 as [draft-gin]. 694 12. Acknowledgements 696 Thanks to Adam Roach for (unknowingly) providing text which I 697 stole^M^M^M copied from [draft-gin]. 699 13. Informative References 701 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 702 A., Peterson, J., Sparks, R., Handley, M., and E. 703 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 704 June 2002. 706 [RFC3263] Rosenberg, J., Schulzrinne, H., "Session Initiation 707 Protocol (SIP): Locating SIP Servers", RFC 3263, June 708 2002. 710 [RFC3327] Willis, D., and Hoeneisen, B., "Session Initiation 711 Protocol (SIP) Extension Header Field for Registering 712 Non-Adjacent Contacts", RFC 3327, December 2002. 714 [RFC3455] Garcia-Martin, M., Henrikson, E., and Mills, D., "Private 715 Header (P-Header) Extensions to the Session Initiation 716 Protocol (SIP) for the 3rd-Generation Partnership Project 717 (3GPP)", RFC 3455, January 2003. 719 [RFC3608] Willis, D., and Hoeneisen, B., "Session Initiation 720 Protocol (SIP) Extension Header Field for Service Route 721 Discovery During Registration", RFC 3608, October 2003. 723 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 724 3966, December 2004. 726 [RFC4244] Barnes, M. (ed.), "An Extension to the Session Initiation 727 Protocol (SIP) for Request History Information", RFC 728 4244, November 2005. 730 [RFC5486] Malas, D., and Meyer, D., "Session Peering for Multimedia 731 Interconnect (SPEERMINT) Terminology", RFC 5486, March 732 2009. 734 [draft-gin] Roach, A. B., "Registration for Multiple Phone Numbers 735 in the Session Initiation Protocol (SIP)", draft-ietf- 736 martini-gin-00, March 2010. 738 [draft-4244bis] Barnes, M., et al, "An Extension to the Session 739 Initiation Protocol (SIP) for Request History 740 Information", draft-ietf-sipcore-rfc4244bis-00, February 741 2010. 743 Author's Address 745 Hadriel Kaplan 746 Acme Packet 747 71 Third Ave. 748 Burlington, MA 01803, USA 749 Email: hkaplan@acmepacket.com