idnits 2.17.1 draft-roach-martini-gin-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 24, 2010) is 5146 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) == Outdated reference: A later version (-09) exists of draft-ietf-martini-reqs-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MARTINI WG A. B. Roach 3 Internet-Draft Tekelec 4 Intended status: Standards Track March 24, 2010 5 Expires: September 25, 2010 7 Registration for Multiple Phone Numbers in the Session Initiation 8 Protocol (SIP) 9 draft-roach-martini-gin-02 11 Abstract 13 This document defines a mechanism by which a SIP server acting as a 14 traditional Private Branch Exchange (PBX) can register with a SIP 15 Service Provider (SSP) to receive phone calls for extensions 16 designated by phone numbers. In order to function properly, this 17 mechanism relies on the fact that the phone numbers are fully 18 qualified and globally unique. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 25, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Registering for Multiple Phone Numbers . . . . . . . . . . . . 4 65 6. SSP Processing of Inbound Phone Number Requests . . . . . . . 6 66 7. Interaction with Other Mechanisms . . . . . . . . . . . . . . 6 67 7.1. Globally Routable User-Agent URIs (GRUU) . . . . . . . . . 6 68 7.1.1. Public GRUUs . . . . . . . . . . . . . . . . . . . . . 6 69 7.1.2. Temporary GRUUs . . . . . . . . . . . . . . . . . . . 8 70 7.2. Registration Event Package . . . . . . . . . . . . . . . . 9 71 7.2.1. PBX Aggregate Registration State . . . . . . . . . . . 9 72 7.2.2. Individual Extension Registration State . . . . . . . 10 73 7.3. Client-Initiated (Outbound) Connections . . . . . . . . . 10 74 7.4. Non-Adjacent Contact Registration (Path) . . . . . . . . . 10 75 7.5. Service Route Discovery . . . . . . . . . . . . . . . . . 10 76 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Usage Scenario: Basic Registration . . . . . . . . . . . . 10 78 8.2. Usage Scenario: Using Path to Control Request URI . . . . 12 79 9. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 13 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 10.1. New SIP Option Tag . . . . . . . . . . . . . . . . . . . . 17 82 10.2. New SIP URI Parameters . . . . . . . . . . . . . . . . . . 18 83 10.2.1. 'bnc' SIP URI paramter . . . . . . . . . . . . . . . . 18 84 10.2.2. 'sg' SIP URI paramter . . . . . . . . . . . . . . . . 18 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 88 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 One of SIP's primary functions is providing rendezvous between users. 94 By design, this rendezvous has been provided through a combination of 95 the server look-up procedures defined in RFC 3263 [3], and the 96 registrar procedures described in RFC 3261 [2]. 98 The intention of the original protocol design was that any user's AOR 99 would be handled by the authority indicated by the hostport portion 100 of the AOR. The users registered individual reachability information 101 with this authority, which would then route incoming requests 102 accordingly. 104 In actual deployments, some SIP servers have been deployed in 105 architectures that, for various reasons, have requirements to provide 106 dynamic routing information for large blocks of AORs, where all of 107 the AORs in the block were to be handled by the same server. For 108 purposes of efficiency, many of these deployments do not wish to 109 maintain separate registrations for each of the AORs in the block. 110 This leads to the desire for an alternate mechanism for providing 111 dynamic routing information for blocks of AORs. 113 Because this problem has certain similarities with the REGISTER 114 operation, several non-standard, ad hoc extensions to REGISTER have 115 been developed to address this desire. 117 Although the use of REGISTER to update reachability information for 118 multiple users simultaneously is somewhat beyond the original 119 semantics defined for REGISTER, this approach has seen significant 120 deployment in certain environments. In particular, deployments in 121 which small to medium SIP PBX servers are addressed using E.164 122 numbers have used this mechanism to avoid the need to maintain DNS 123 entries or static IP addresses for the PBX servers. 125 In recognition of the momentum that a REGISTER-based approach has 126 within that relatively narrow ecological niche, this document defines 127 a REGISTER-based approach that is tailored to E.164-addressed 128 extensions in a SIP PBX environment. It is not intended for general- 129 purpose registration of SIP URIs in which the user portion is non- 130 numeric or non-globally-unique. 132 2. Constraints 134 The following paragraph is perhaps the most important in 135 understanding the solution defined in this document. 137 Within the problem space that has been established for this work, 138 several constraints shape our solution. These are being defined in 139 the MARTINI requirements document [5]. In terms of impact to the 140 solution at hand, the following two constraints have the most 141 profound effect: (1) The PBX cannot be assumed to be assigned a 142 static IP address; and (2) No DNS entry can be relied upon to 143 consistently resolve to the IP address of the PBX. 145 3. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [1]. 151 Further, the term "SSP" is meant as an acronym for a "SIP Service 152 Provider," while the term "PBX" is used to indicate a SIP Private 153 Branch Exchange. 155 4. Mechanism Overview 157 The overall mechanism is achieved using a REGISTER request with a 158 specially-formatted Contact URI. This document also defines an 159 option tag that can be used to ensure a registrar and any 160 intermediaries understand the mechanism described herein. 162 The Contact URI itself is tagged with a URI parameter to indicate 163 that it actually represents a multitude of phone-number-associated 164 contacts. 166 We also define some lightweight extensions for GRUU to allow the use 167 of public and temporary GRUUs assigned by the SSP. 169 Aside from these extensions, the REGISTER message itself is processed 170 by a registrar in the same way as normal registrations: by updating 171 its location service with additional AOR to Contact bindings. 173 Note that the list of extensions associated with a PBX is a matter of 174 local provisioning at the SSP and at the PBX. The mechanism defined 175 in this document does not provide any means to detect or recover from 176 provisioning mismatches (although the registration event package can 177 be used as a standardized means for auditing such extensions; see 178 Section 7.2.1). 180 5. Registering for Multiple Phone Numbers 182 To register for multiple phone numbers, the PBX sends a REGISTER 183 message to the SSP. This REGISTER varies from a typical register in 184 two important ways. First, it must contain an option tag of 185 "bulknumbercontact" in both a "Require" header field and a "Proxy- 186 Require" header field. Second, in at least one "Contact" header 187 field, it must include a Contact URI that contains the URI parameter 188 "bnc", and no user portion (hence no "@" symbol). A URI with a "bnc" 189 parameter MUST NOT contain a user portion. 191 Because of the constraints discussed in Section 2, the host portion 192 of the Contact URI will generally contain an IP address, although 193 nothing in this mechanism enforces or relies upon that fact. If the 194 PBX operator chooses to maintain DNS entries that resolve to the IP 195 address of his PBX via RFC 3263 resolution procedures, then this 196 mechanism works just fine with domain names in the Contact header 197 field. 199 The URI parameter indicates that special interpretation of the 200 Contact URI is necessary: instead of representing a single, concrete 201 Contact URI to be inserted into the location service, it represents a 202 multitude of Contact URIs (one for each associated phone numbers), 203 semantically resulting in a multitude of AOR-to-Contact rows in the 204 location service. 206 The registrar, upon receipt of a REGISTER message in the foregoing 207 form, will use the value in the "To" header field to identify the PBX 208 for which registration is being requested. It then authenticates the 209 PBX (using, e.g., SIP Digest authentication, mutual TLS, or some 210 other authentication mechanism). After the PBX is authenticated, the 211 registrar updates its location service so that each of the phone 212 numbers associated with the PBX creates a unique AOR to Contact 213 mapping. Semantically, each of these mappings will be treated as a 214 unique row in the location service. The actual implementation may, 215 of course, perform internal optimizations to reduce the amount of 216 memory used to store such information. 218 For each of these unique rows, the AOR will be in the format that the 219 SSP expects to receive from external parties (e.g. 220 "sip:+12145550102@ssp.example.com"), and the corresponding Contact 221 will be formed adding a user portion to the REGISTER's Contact URI 222 containing the fully-qualified, E.164-formatted phone number 223 (including the preceding "+" symbol) and removing the "bnc" 224 parameter. For example, if the "Contact" header field contains the 225 URI , then the Contact value 226 associated with the aforementioned AOR will be 227 . 229 Aside from the "bnc" parameter, all URI parameters present on the 230 "Contact" URI in the REGISTER message MUST be copied to the Contact 231 value stored in the location service. 233 6. SSP Processing of Inbound Phone Number Requests 235 In general, after processing the AOR to Contact mapping described in 236 the preceding section, the SSP Proxy/Registrar (or equivalent entity) 237 performs traditional Proxy/Registrar behavior, based on the mapping. 238 For inbound SIP requests whose AOR indicates an E.164 number assigned 239 to one of the SSP's customers, this will generally involve setting 240 the target set to the registered contacts associated with that AOR, 241 and performing request forwarding as described in section 16.6 of RFC 242 3261 [2]. 244 7. Interaction with Other Mechanisms 246 The following sections describe the means by which this mechanism 247 interacts with relevant REGISTER-related extensions currently defined 248 by the IETF. 250 Currently, the descriptions are somewhat informal, and omit some 251 details for the sake of brevity. If the MARTINI working group 252 expresses interest in furthering the mechanism described by this 253 document, they will be fleshed out with more detail and formality. 255 7.1. Globally Routable User-Agent URIs (GRUU) 257 To enable advanced services to work with extensions behind a SIP PBX, 258 it is important that the GRUU mechanism defined by RFC 5627 [10] work 259 correctly with the mechanism defined by this document. 261 7.1.1. Public GRUUs 263 When a PBX registers a Bulk Number Contact (a Contact with a "bnc" 264 parameter), and also invokes GRUU procedures for that Contact during 265 registration, then the SSP will assign a public GRUU to the PBX in 266 the normal fashion. Because the URI being registered contains a 267 "bnc" parameter, the GRUU will also contain a "bnc" parameter. In 268 particular, this means that the GRUU will not contain a user portion. 270 When a terminal registers with the PBX using GRUU procedures for a 271 Contact, it adds an "sg" parameter to the GRUU parameter it received 272 from the SSP. This "sg" parameter contains a disambiguation token 273 that the SSP can use to route the request to the proper user agent. 275 So, for example, when the PBX registers with the following contact 276 header field: 278 Contact: ; 279 +sip.instance="" 281 Then the SSP may choose to respond with a Contact header field that 282 looks like this: 284 285 Contact: ; 286 pub-gruu="sip:ssp.example.com;gr=urn: 287 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"; 288 +sip.instance="" 289 ;expires=7200 290 292 When its own terminals register, the PBX can then add whatever device 293 identifier it feels appropriate in an "sg" parameter, and present 294 this value to its own terminals. For example, assume the extension 295 associated with the phone number "+12145550102" sent the following 296 Contact header field in its register: 298 Contact: ; 299 +sip.instance="" 301 The PBX will add an "sg" parameter to the pub-gruu it received from 302 the SSP with a token that uniquely identifies the device (possibly 303 the URN itself; possibly some other identifier); insert a user 304 portion containing the fully-qualified E.164 number associated with 305 the extension; and return the result to the terminal as its public 306 GRUU. The resulting Contact header field would look something like 307 this: 309 310 Contact: ; 311 pub-gruu="sip:+12145550102@ssp.example.com;gr=urn: 312 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6"; 313 +sip.instance="" 314 ;expires=3600 315 317 When an incoming request arrives at the SSP for a GRUU corresponding 318 to a bulk number contact ("bnc"), the SSP performs slightly different 319 processing for the GRUU than a Proxy/Registrar would. When the GRUU 320 is re-targeted to the registered bulk number contact, the SSP MUST 321 copy the "sg" parameter from the GRUU to the new target. The PBX can 322 then use this "sg" parameter to determine which user agent the 323 request should be routed to. 325 7.1.2. Temporary GRUUs 327 PBXes have two options for creating temporary GRUUs for use by its 328 terminals. 330 7.1.2.1. Approach 1 - Self Made GRUUs 332 If a PBX wishes to provide temporary GRUUs for its terminals, it may 333 do so by producing its own "Self-made GRUUs" (as defined in section 334 4.3 of RFC 5627 [10]). These GRUUs are produced using the PBX's own 335 IP address (or domain, if it maintains one in DNS). The temporary 336 GRUUs are then propagated to terminals using normal GRUU mechanism. 338 The ability to produce temporary GRUUs in this fashion is predicated 339 on the conditions described in section 4.3 of RFC 5627. In 340 particular, it requires PBX to be publicly routable, and willing to 341 accept requests destined for its own Self-made GRUUs from sources 342 other than the SSP. If these conditions cannot be satisfied (or the 343 PBX operator chooses not to satisfy them for policy reasons), then 344 the PBX users will not be able to make use of temporary GRUUs. 346 This mechanism is also predicated on the IP address for the PBX being 347 relatively stable over a long period of time. This is generally a 348 safe assumption to make, as frequent PBX IP address changes will 349 result in intermittent connectivity issues and interruptions to 350 ongoing calls. 352 On a related note: when used with this extension, the SSP will not 353 return a temporary GRUU in the registration response for any contacts 354 that include a "bnc" parameter in their URI. 356 For example, using the same setup as in the "Public GRUU" section 357 above, an extensions registering with the PBX might obtain a temp 358 gruu by receiving a Contact header field that looks like: 360 361 Contact: ; 362 pub-gruu="sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765- 363 00a0c91e6bf6;sg=a0471c99573b877b"; 364 +sip.instance="" 365 ;expires=3600 366 368 7.1.2.2. Approach 2 - Anonymous Public GRUUs 370 If a PBX does not satisfy the criteria for producing its own "Self- 371 made GRUUs," then it may create temporary GRUUs based on the public 372 GRUUs it received from the SSP at registration time. To create 373 Temporary GRUUs of this form, the PBX will add an opaque "sg" 374 parameter to the public GRUU it received from the SSP, and will omit 375 the user portion. 377 Note that, because these GRUUs are temporary GRUUs, a unique "sg" 378 parameter will be generated for each successful registration attempt. 379 The PBX tracks the various "sg" values associated with each user 380 agent, and can re-target to the correct instance when the request 381 arrives. 383 For this approach to function, the SSP must be able to resolve a GRUU 384 based solely on the value of its "gr" parameter, as the user portion 385 of the GRUU will not contain an E.164 number. Further, the SSP will 386 not know which actual extension the request is destined for, only 387 that it corresponds to an extension belonging to the PBX. 389 Using the same basic setup as the example for the public GRUU, a 390 terminal might receive a temporary GRUU by getting back a Contact 391 header field that looks like this: 393 394 Contact: ; 395 temp-gruu="sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765- 396 00a0c91e6bf6;sg=0UYYRV046P";+sip.instance="";expires=3600 398 400 7.2. Registration Event Package 402 As this mechanism inherently deals with REGISTER behavior, it is 403 imperative to consider its impact on the Registration Event Package 404 defined by RFC 3680 [8]. In practice, there will be two main use 405 cases for subscribing to registration data: learning about the 406 overall registration state for the PBX, and learning about the 407 registration state for a single PBX extension. 409 7.2.1. PBX Aggregate Registration State 411 If the PBX (or another interested and authorized party) wishes to 412 monitor or audit the registration state for all of the extensions 413 currently registered to that PBX, it can subscribe to the SIP 414 registration event package at the PBX's main URI -- that is, the URI 415 used in the "To" header field of the REGISTER message. 417 The NOTIFY messages for such a subscription will contain a body that 418 contains one record for each phone number associated with the PBX. 419 The AORs will be in the format expected to be received by the SSP 420 (e.g., "sip:+12145550105@ssp.example.com"), and the Contacts will 421 correspond to the mapped Contact created by the registration (e.g., 422 "sip:+12145550105@98.51.100.3"). 424 In particular, the "bnc" parameter is forbidden from appearing in the 425 body of a reg-event notify. 427 7.2.2. Individual Extension Registration State 429 If the SSP receives a SUBSCRIBE request for the registration event 430 package with a Request-URI that indicates a contact registered via 431 the "Bulk Number Contact" mechanism defined in this document, then it 432 MUST proxy that SUBSCRIBE to the PBX in the same way that is would 433 proxy an INVITE bound for that AOR. 435 Defining the behavior in this way is important, since the reg-event 436 subscriber is interested in finding out about the comprehensive list 437 of devices associated with the phone number. Only the PBX will have 438 authoritative access to this information. For example, if the user 439 has registered multiple terminals with differing capabilities, the 440 SSP will not know about the devices or their capabilities. By 441 contrast, the PBX will. 443 7.3. Client-Initiated (Outbound) Connections 445 RFC 5626 [9] -- needs analysis. Some people think it might "just 446 work." 448 7.4. Non-Adjacent Contact Registration (Path) 450 RFC 3327 [6] -- needs analysis. Some people think it might "just 451 work." 453 7.5. Service Route Discovery 455 RFC 3608 [7] -- needs analysis. Some people think it might "just 456 work." 458 8. Examples 460 These will be fleshed out more in later versions of the draft, with 461 explanations of the processing performed at each step. For the time 462 being, they just show the basic syntax described above. 464 8.1. Usage Scenario: Basic Registration 466 This example shows a basic bulk REGISTER transaction, followed by an 467 INVITE addressed to one of the registered terminals. 469 Internet SSP PBX 470 | | | 471 | |REGISTER | 472 | |Contact: | 473 | |<--------------------------------| 474 | | | 475 | |200 OK | 476 | |-------------------------------->| 477 | | | 478 |INVITE | | 479 |sip:+12145550105@ssp.example.com| | 480 |------------------------------->| | 481 | | | 482 | |INVITE | 483 | |sip:+12145550105@198.51.100.3 | 484 | |-------------------------------->| 486 REGISTER sip:ssp.example.com SIP/2.0 487 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 488 Max-Forwards: 70 489 To: 490 From: ;tag=a23589 491 Call-ID: 843817637684230@998sdasdh09 492 CSeq: 1826 REGISTER 493 Require: bulknumbercontact 494 Contact: 495 Expires: 7200 496 Content-Length: 0 498 INVITE sip:+12145550105@ssp.example.com;user=phone SIP/2.0 499 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 500 Max-Forwards: 69 501 To: 502 From: ;tag=456248 503 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 504 CSeq: 24762 INVITE 505 Contact: 506 Content-Type: application/sdp 507 Content-Length: ... 509 510 INVITE sip:+12145550105@198.51.100.3;user=phone SIP/2.0 511 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 512 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 513 Max-Forwards: 68 514 To: 515 From: ;tag=456248 516 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b 517 CSeq: 24762 INVITE 518 Contact: 519 Content-Type: application/sdp 520 Content-Length: ... 522 524 8.2. Usage Scenario: Using Path to Control Request URI 526 This example shows a bulk REGISTER transaction with the SSP making 527 use of the "Path" header field extension [6]. This allows the SSP to 528 designate a domain on the incoming Request URI that does not 529 necessarily resolve to the PBX from when the SSP applies RFC 3263 530 procedures to it. 532 Internet SSP PBX 533 | | | 534 | |REGISTER | 535 | |Path: | 536 | |Contact: | 537 | |<--------------------------------| 538 | | | 539 | |200 OK | 540 | |-------------------------------->| 541 | | | 542 |INVITE | | 543 |sip:+12145550105@ssp.example.com| | 544 |------------------------------->| | 545 | | | 546 | |INVITE | 547 | |sip:+12145550105@pbx.example | 548 | |Route: | 549 | |-------------------------------->| 550 REGISTER sip:ssp.example.com SIP/2.0 551 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 552 Max-Forwards: 70 553 To: 554 From: ;tag=a23589 555 Call-ID: 843817637684230@998sdasdh09 556 CSeq: 1826 REGISTER 557 Require: bulknumbercontact 558 Path: 559 Contact: 560 Expires: 7200 561 Content-Length: 0 563 INVITE sip:+12145550105@ssp.example.com;user=phone SIP/2.0 564 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 565 Max-Forwards: 69 566 To: 567 From: ;tag=456248 568 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 569 CSeq: 24762 INVITE 570 Contact: 571 Content-Type: application/sdp 572 Content-Length: ... 574 576 INVITE sip:+12145550105@pbx.example;user=phone SIP/2.0 577 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad 578 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 579 Route: 580 Max-Forwards: 68 581 To: 582 From: ;tag=456248 583 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b 584 CSeq: 24762 INVITE 585 Contact: 586 Content-Type: application/sdp 587 Content-Length: ... 589 591 9. Requirements Analysis 593 The document "Requirements for multiple address of record (AOR) 594 reachability information in the Session Initiation Protocol (SIP)" 596 [5] contains a list of requirements and desired properties for a 597 mechanism to register multiple AORs with a single SIP transaction. 598 This section evaluates those requirements against the mechanism 599 described in this document. 601 REQ1 - The mechanism MUST allow a SIP-PBX to enter into a trunking 602 arrangement with an SSP whereby the two parties have agreed on a set 603 of telephone numbers deemed to have been assigned to the SIP-PBX. 605 The requirement is satisfied. 607 REQ2 - The mechanism MUST allow a set of assigned telephone numbers 608 to comprise E.164 numbers, which can be in contiguous ranges, 609 discrete, or in any combination of the two. 611 The requirement is satisfied; the DIDs associated with a 612 registration is established by bilateral agreement between the SSP 613 and the PBX, and is not part of the mechanism described in this 614 document. 616 REQ3 - The mechanism MUST allow a SIP-PBX to register reachability 617 information with its SSP, in order to enable the SSP to route to the 618 SIP-PBX inbound requests targeted at assigned telephone numbers. 620 The requirement is satisfied. 622 REQ4 - The mechanism MUST NOT prevent UAs attached to a SIP-PBX 623 registering with the SIP-PBX on behalf of AORs based on assigned 624 telephone numbers in order to receive requests targeted at those 625 telephone numbers, without needing to involve the SSP in the 626 registration process. 628 The requirement is satisfied; in the presumed architecture, PBX 629 terminals register with the PBX, an require no interaction with 630 the SSP. 632 REQ5 - The mechanism MUST allow a SIP-PBX to handle internally 633 requests originating at its own UAs and targeted at its assigned 634 telephone numbers, without routing those requests to the SSP. 636 The requirement is satisfied; PBXes may recognize their own DID 637 and their own GRUUs, and perform on-PBX routing without sending 638 the requests to the SSP. 640 REQ6 - The mechanism MUST allow a SIP-PBX to receive requests to its 641 assigned telephone numbers originating outside the SIP-PBX and 642 arriving via the SSP, so that the PBX can route those requests 643 onwards to its UAs, as it would for internal requests to those 644 telephone numbers. 646 The requirement is satisfied 648 REQ7 - The mechanism MUST provide a means whereby a SIP-PBX knows 649 which of its assigned telephone numbers an inbound request from its 650 SSP is targeted at. 652 The requirement is satisfied. For ordinary calls and calls using 653 Public GRUUs, the DID is indicated in the user portion of the 654 Request-URI. For calls using Temp GRUUs constructed with the 655 mechanism described in Section 7.1.2.2, the "sg" parameter 656 provides a correlation token the PBX can use to identify which 657 terminal the call should be routed to. 659 REQ8 - The mechanism MUST provide a means of avoiding problems due to 660 one side using the mechanism and the other side not. 662 The requirement is satisfied through the 'bulknumbercontact' 663 option tag and the 'bnc' Contact parameter. 665 REQ9 - The mechanism MUST observe SIP backwards compatibility 666 principles. 668 The requirement is satisfied through the 'bulknumbercontact' 669 option tag. 671 REQ10 - The mechanism MUST work in the presence of intermediate SIP 672 entities on the SSP side of the SIP-PBX-to-SSP interface (i.e., 673 between the SIP-PBX and the SSP's domain proxy), where those 674 intermediate SIP entities need to be on the path of inbound requests 675 to the PBX. 677 The requirement is satisfied through the use of the Path mechanism 678 defined in RFC 3327 [6] 680 REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address 681 dynamically. 683 The requirement is satisfied by allowing the PBX to use an IP 684 address in the Bulk Number Contact URI contained in a REGISTER 685 Contact header field. 687 REQ12 - The mechanism MUST work without requiring the SIP-PBX to have 688 a domain name or the ability to publish its domain name in the DNS. 690 The requirement is satisfied by allowing the PBX to use an IP 691 address in the Bulk Number Contact URI contained in a REGISTER 692 Contact header field. 694 REQ13 - For a given SIP-PBX and its SSP, there MUST be no impact on 695 other domains, which are expected to be able to use normal RFC 3263 696 procedures to route requests, including requests needing to be routed 697 via the SSP in order to reach the SIP-PBX. 699 The requirement is satisfied by allowing the domain name in the 700 Request URI used by external entities to resolve to the SSP's 701 servers via normal RFC 3263 resolution procedures. 703 REQ14 - The mechanism MUST be able to operate over a transport that 704 provides integrity protection and confidentiality. 706 The requirement is satisfied; nothing in the proposed mechanism 707 prevent the use of TLS between the SSP and the PBX. 709 REQ15 - The mechanism MUST support authentication of the SIP-PBX by 710 the SSP and vice versa. 712 The requirement is satisfied; PBXes may employ either SIP digest 713 authentication or mutually-authenticated TLS for authentication 714 purposes. 716 REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with 717 public or temporary Globally Routable UA URIs (GRUUs) [10]. 719 The requirement is satisfied via the mechanisms detailed in 720 Section 7.1. 722 REQ17 - The mechanism MUST NOT preclude the ability of the SIP-PBX to 723 route on-PBX requests directly, without hair-pinning the signaling 724 through the SSP. 726 The requirement is satisfied; PBXes may recognize their own DID 727 and their own GRUUs, and perform on-PBX routing without sending 728 the requests to the SSP. (Note that this requirement duplicates 729 REQ5, and will probably be removed in a future version of the 730 requirements document.) 732 REQ18 - The mechanism MUST work over any existing transport specified 733 for SIP, including UDP. 735 The requirement is satisfied to the extent that UDP can be used 736 for REGISTER requests in general. The application of certain 737 extensions and/or network topologies may exceed UDP MTU sizes, but 738 such issues arise both with and without the mechanism described in 739 this document. This document does not exacerbate such issues. 741 DES1 - The mechanism SHOULD allow an SSP to exploit its mechanisms 742 for providing SIP service to ordinary subscribers in order to provide 743 a SIP trunking service to SIP-PBXes. 745 The desired property is satisfied; the routing mechanism described 746 in this document is identical to the routing performed for singly- 747 registered AORs. 749 DES2 - The mechanism SHOULD scale to SIP-PBX's of several thousand 750 assigned telephone numbers. 752 The desired property is satisfied; nothing in this document 753 precludes DID pools of arbitrary size. 755 DES3 - The mechanism SHOULD scale to support several thousand SIP- 756 PBX's on a single SSP. 758 The desired property is satisfied; nothing in this document 759 precludes an arbitrary number of PBXes from attaching to a single 760 SSP. 762 DES4 - The mechanism SHOULD require relatively modest changes to a 763 substantial population of existing SSP and SIP-PBX implementations, 764 in order to encourage a fast market adoption of the standardized 765 mechanism. 767 The desired property is difficult to evaluate in the context of 768 any solution. The mechanism proposed in this document uses the 769 REGISTER method, which is the method preferred by many existing 770 PBX deployments. The handling of request routing logic is nearly 771 identical to that of RFC 3261 proxy/registrars, allowing 772 implementors to leverage existing proxy/registrar code. 774 10. IANA Considerations 776 This document registers a new SIP option tag to indicate support for 777 the mechanism it defines, plus two new SIP URI parameters. 779 10.1. New SIP Option Tag 781 This section defines a new SIP option tag per the guidelines in 782 Section 27.1 of RFC 3261[2]. 784 Name: bulknumbercontact 785 Description: This option tag is used to identify the extension that 786 provides Registration for Multiple Phone Numbers in SIP. When 787 present in a Require or Proxy-Require header field of a REGISTER 788 request, it indicates that support for this extension is required 789 of registrars and proxies, respectively, that are a party to the 790 registration transaction. 791 Reference: RFCXXXX (this document) 793 10.2. New SIP URI Parameters 795 This specification defines two new SIP URI parameters, as per the 796 registry created by RFC 3969 [4]. 798 10.2.1. 'bnc' SIP URI paramter 800 Parameter Name: bnc 801 Predefined Values: No (no values are allowed) 802 Reference: RFCXXXX (this document) 804 10.2.2. 'sg' SIP URI paramter 806 Parameter Name: sg 807 Predefined Values: No 808 Reference: RFCXXXX (this document) 810 11. Security Considerations 812 There are certainly security implications associated with the 813 mechanisms described in this document, mostly dealing with the 814 unprecedented semantic inclusion of multiple AORs in a single 815 REGISTER request. This section will be formulated following an 816 analysis of the security impact of GIN on Path, Service-Route, and 817 Outbound. 819 12. References 821 12.1. Normative References 823 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 824 Levels", BCP 14, RFC 2119, March 1997. 826 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 827 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 828 Session Initiation Protocol", RFC 3261, June 2002. 830 [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 831 (SIP): Locating SIP Servers", RFC 3263, June 2002. 833 [4] Camarillo, G., "The Internet Assigned Number Authority (IANA) 834 Uniform Resource Identifier (URI) Parameter Registry for the 835 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 836 December 2004. 838 12.2. Informative References 840 [5] Elwell, J. and H. Kaplan, "Requirements for multiple address of 841 record (AOR) reachability information in the Session Initiation 842 Protocol (SIP)", draft-ietf-martini-reqs-02 (work in progress), 843 March 2010. 845 [6] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 846 Extension Header Field for Registering Non-Adjacent Contacts", 847 RFC 3327, December 2002. 849 [7] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 850 Extension Header Field for Service Route Discovery During 851 Registration", RFC 3608, October 2003. 853 [8] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 854 Package for Registrations", RFC 3680, March 2004. 856 [9] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 857 Initiated Connections in the Session Initiation Protocol 858 (SIP)", RFC 5626, October 2009. 860 [10] Rosenberg, J., "Obtaining and Using Globally Routable User 861 Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", 862 RFC 5627, October 2009. 864 Author's Address 866 Adam Roach 867 Tekelec 868 17210 Campbell Rd. 869 Suite 250 870 Dallas, TX 75252 871 US 873 Email: adam@nostrum.com