idnits 2.17.1 draft-procter-bliss-call-park-extension-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 8, 2009) is 5435 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BLISS M. Procter 3 Internet-Draft VoIP.co.uk 4 Intended status: Informational June 8, 2009 5 Expires: December 10, 2009 7 Implementing Call Park and Retrieve using the Session Initiation 8 Protocol (SIP) 9 draft-procter-bliss-call-park-extension-05 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on December 10, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 Call Park and Call Retrieve are useful telephony services that are 58 familiar to many users. Existing implementations using the Session 59 Initiation Protocol (SIP) show that a variety of approaches can be 60 taken, with varying degrees of interoperability. This draft 61 discusses a number of feature variations, and how they may be 62 implemented using existing techniques. An additional URI parameter 63 is also described, which enables further common use-cases to be 64 implemented. 66 Table of Contents 68 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Parking a call . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. Parking a call without an orbit . . . . . . . . . . . . . 6 71 2.2. Parking a call with an orbit specified by the UA . . . . . 6 72 2.3. Parking a call with an orbit specified by the Park 73 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 2.4. A failed attempt to park a call . . . . . . . . . . . . . 10 75 3. Retrieving a Parked Call . . . . . . . . . . . . . . . . . . . 10 76 4. User Agent Considerations . . . . . . . . . . . . . . . . . . 13 77 5. Park Server Considerations . . . . . . . . . . . . . . . . . . 14 78 6. Other Implementations and Interoperability . . . . . . . . . . 15 79 6.1. Parking by blind transfer . . . . . . . . . . . . . . . . 15 80 6.2. Parking by blind transfer with central allocation . . . . 15 81 6.3. Parking with orbit parameters . . . . . . . . . . . . . . 16 82 6.4. Parking on the User Agent . . . . . . . . . . . . . . . . 16 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Overview 93 Call Park is a feature that enables User Agents (UA) to make a call 94 inactive but not terminated, in such a way as to allow the call to be 95 resumed by the UA that parked the call, or by a different UA. 97 This feature is typically used when User A wishes to transfer a call 98 in progress to User B, but doesn't necessarily know how to reach User 99 B's UA directly. In this situation, User A parks the call, and then 100 tells User B where the call is parked. User B may then retrieve the 101 call using a convenient UA. 103 Other uses include allowing multiple calls to be parked at the same 104 'location', and forming a queue. In this way, a simple 'ACD' 105 (Automatic Call Distribution) system can be implemented that permits 106 calls to be initially sorted and placed in one of a number of queues, 107 ready to be handled when an appropriate agent becomes available (and 108 retrieves the next call from the queue). 110 In all cases, the parked call is subsequently identifiable by a short 111 (typically 3 or 4 digit) label known as an 'orbit'. This orbit is 112 often allocated by the user parking the call, but some environments 113 favour allocation of the orbit by a Park Server. Both approaches are 114 described in this document. 116 Multiple Park Servers can be beneficial in some enviroments for a 117 variety of reasons including load-sharing and administrative 118 policies. This document shows how support for multiple servers can 119 easily be achieved whilst still permitting a single 'well-known' Park 120 Server URI to be advertised for configuration. 122 2. Parking a call 124 A basic call flow for Call Park is given in [RFC5359] (section 2.15), 125 and this forms the basis of the feature. The flow shows Alice and 126 Bob in a call, when Bob decides to park the call by sending a REFER 127 to the Park Server. 129 It is worth noting that whilst the flow is conceptually similar to an 130 Unattended Transfer [RFC5359] (section 2.4), the REFER is sent to 131 different endpoints in the two cases. For Unattended Transfer, the 132 Transferor sends the REFER to the Transferee, instructing him to call 133 the Transfer Target. For Call Park, the Transferor (Bob) sends the 134 REFER to the Transfer Target (Park Server), instructing it to call 135 the Transferee (Alice). 137 By following the Call Park model, we ensure that Bob has visibility 138 over the success or failure of the park attempt. We also ensure that 139 Bob does not rely on Alice to correctly pass the orbit parameter back 140 from the Park Server for the centrally-allocated orbit number 141 situation. Finally, because Bob sends the REFER to the Park Server, 142 we give the Park Server the opportunity to challenge Bob and ensure 143 that appropriate authorisation exists for the service. 145 Alice Bob Park Server Carol 146 | | | | 147 | INVITE F1 | | | 148 |------------->| | | 149 |180 Ringing F2| | | 150 |<-------------| | | 151 | 200 OK F3 | | | 152 |<-------------| | | 153 | ACK F4 | | | 154 |------------->| | | 155 | RTP Media | | | 156 |<============>| | | 157 | Bob Parks Call | | 158 | | REFER Refer-To: A F5 | 159 | |------------->| | 160 | | 202 F6 | | 161 | |<-------------| | 162 | | NOTIFY F7 | | 163 | |<-------------| | 164 | | 200 F8 | | 165 | |------------->| | 166 | INVITE F9 Replaces: B | | 167 |<----------------------------| | 168 | 200 OK F10 | | 169 |---------------------------->| | 170 | ACK F11 | | 171 |<----------------------------| | 172 |(optional Music-on-Hold RTP) | | 173 |<===========================>| | 174 | BYE F12 | | | 175 |------------->| NOTIFY F14 | | 176 | 200 OK F13 |<-------------| | 177 |<-------------| 200 OK F15 | | 178 | |------------->| | 180 The basic call flow described above uses the SIP dialog ID between 181 the parked endpoint and the Park Server itself as the unique parked 182 call identifier. Using the dialog ID has a number of advantages 183 since it is unique and allocated by both the parked user and the Park 184 Server. However, it is also long, which can lead to problems when 185 trying to identify parked calls by verbal or human-written 186 mechanisms. 188 Traditional PBX users have become accustomed to calls being parked 189 against a short number (typically 3 or 4 digits), and then using this 190 identifier to communicate to the retrieving party which call to 191 retrieve. This information may be passed verbally, or by means of 192 small paper notes. Whilst collisions may occur, they are generally 193 avoided satisfactorily by administrative policies. 195 This draft attempts to reconcile these two models by allowing a short 196 label to be attached to a parked call (the 'orbit'). The retrieving 197 party can then use the same label to locate the relevant dialog ID in 198 order to retrieve the parked call. Note that the orbit may be 199 allocated by the User Agent parking the call or centrally by the Park 200 Server. 202 2.1. Parking a call without an orbit 204 Certain environments do not require an 'orbit' to be used, either 205 because calls are parked in a single queue, or the dialog identifiers 206 are readily passed between concerned UAs. In this scenario, the flow 207 described in [RFC5359] (section 2.15) is followed without deviation. 209 2.2. Parking a call with an orbit specified by the UA 211 The message flow of parking a call in this scenario is identical to 212 that illustrated in [RFC5359] (section 2.15). The difference that 213 this document introduces is in the REFER message to the Park Server. 215 In this scenario, it is assumed that Bob has entered a parking orbit 216 in some manner appropriate to his UA. Once this is done, the REFER 217 is sent to the URI instead 218 of simply directing the request to the URI 219 . The addition of the orbit parameter 220 to the URI effectively labels the parked call with a short memorable 221 code entered by the user. 223 F5 REFER Bob -> Park Server 225 REFER sips:park@server.example.com;orbit=1234 SIP/2.0 226 Via: SIP/2.0/TLS client.biloxi.example.com:5061 227 ;branch=z9hG4bKnashds9 228 Max-Forwards: 70 229 From: Bob ;tag=02134 230 To: Park Server 231 Call-ID: 4802029847@biloxi.example.com 232 CSeq: 1 REFER 233 234 Refer-To: 237 238 Referred-By: 239 Contact: 240 Content-Length: 0 242 2.3. Parking a call with an orbit specified by the Park Server 244 Sometimes an orbit number assignment policy needs to be implemented. 245 This may be to ensure that all orbit numbers are a particular length, 246 or have a form that means that they can be dialled directly (given 247 suitable extensions to an Application Server). It may also be 248 implemented to eliminate the problem of trying to park more than one 249 call on the same orbit. 251 To enforce a policy, we ensure that the orbit number is not allocated 252 by the UA (entered by the user, or by configuration etc.) but is 253 instead allocated by the Park Server, and relayed to the UA. The 254 approach taken here is analogous to the Conference Factory approach 255 described in [RFC4579]. Bob sends a REFER to the preconfigured Park 256 Server URI, but without any 'orbit' parameter added. The Park Server 257 then responds by redirecting Bob to the correct orbit by using a '302 258 Moved Temporarily' response. The orbit can then be found by 259 inspecting this new target. 261 Alice Bob Park Server Carol 262 | | | | 263 | Active Call | | | 264 |<============>| | | 265 | Bob Parks Call | | 266 | | REFER Refer-To: A F5 | 267 | |------------->| | 268 | |302 Orbit allocated F6 | 269 | |<-------------| | 270 | | REFER Refer-To: A F7 | 271 | |------------->| | 272 | |202 Accepted F8 | 273 | |<-------------| | 274 | | NOTIFY | | 275 | |<-------------| | 276 | | 200 OK | | 277 | |------------->| | 279 F5 REFER Bob -> Park Server 281 REFER sips:park@server.example.com SIP/2.0 282 Via: SIP/2.0/TLS client.biloxi.example.com:5061 283 ;branch=z9hG4bKnashdsB 284 Max-Forwards: 70 285 From: Bob ;tag=22134 286 To: Park Server 287 Call-ID: 4802029847@biloxi.example.com 288 CSeq: 1 REFER 289 290 Refer-To: 293 294 Referred-By: 295 Contact: 296 Content-Length: 0 297 F6 302 Orbit Allocated Park Server -> Bob 299 SIP/2.0 202 Orbit Allocated 300 Via: SIP/2.0/TLS client.biloxi.example.com:5061 301 ;branch=z9hG4bKnashdsB 302 ;received=192.0.2.105 303 From: Bob ;tag=22134 304 To: Park Server ;tag=56324 305 Call-ID: 4802029848@biloxi.example.com 306 CSeq: 1 REFER 307 Contact: 308 Content-Length: 0 310 This is also the means by which multiple Park Servers can be 311 deployed. A REFER to might result in 312 a 302 response, nominating 313 as the desired target. 315 Different network architectures may result in different behaviours as 316 seen by Bob. In particular, whether Bob sees the 302 response will 317 depend on whether or not an intermediate proxy recurses on it. 318 Therefore, Bob's UA must be prepared to extract the orbit parameter 319 from either the 302 response (if one is seen) or the Contact header 320 of the 2xx response to his REFER. 322 Since this technique may also be used to resolve the problem of 323 parking multiple calls on the same orbit, Bob's UA must be prepared 324 to extract the orbit even if it provided one in the initial request. 325 If the orbit differs to the one requested, the extracted orbit should 326 be rendered to Bob in an appropriate manner. 328 F8 202 Accepted Park Server -> Bob 330 SIP/2.0 202 Accepted 331 Via: SIP/2.0/TLS client.biloxi.example.com:5061 332 ;branch=z9hG4bKnashds9 333 ;received=192.0.2.105 334 From: Bob ;tag=02134 335 To: Park Server ;tag=56323 336 Call-ID: 4802029847@biloxi.example.com 337 Contact: 338 CSeq: 1 REFER 339 Content-Length: 0 341 This variation is only possible on Park Servers capable of generating 342 Contact URIs of the correct form, i.e. with an 'orbit' URI parameter, 343 in either a 302 response, or in a 2xx response to the REFER. Park 344 Servers unable to generate URIs of this form are therefore confined 345 to environments that don't require centrally allocated parking 346 orbits. 348 2.4. A failed attempt to park a call 350 A Park Server may choose to reject a park attempt for many reasons, 351 including prohibiting multiple calls being parked against the same 352 orbit, or prohibiting certain users from parking calls on certain 353 orbits. Whatever the reason, the response sent to Bob will enable 354 Bob to take appropriate action. The following example shows the Park 355 Server rejecting a call due to the orbit already being in use. 357 Alice Bob Park Server Carol 358 | | | | 359 | INVITE F1 | | | 360 |------------->| | | 361 |180 Ringing F2| | | 362 |<-------------| | | 363 | 200 OK F3 | | | 364 |<-------------| | | 365 | ACK F4 | | | 366 |------------->| | | 367 | RTP Media | | | 368 |<============>| | | 369 | Bob Parks Call | | 370 | | REFER Refer-To: A F5 | 371 | |------------->| | 372 | |486 Busy Here | | 373 | |<-------------| | 375 When Bob's parking attempt is rejected, Bob may choose to attempt to 376 park the call again, but using a different orbit number. The ability 377 for Bob to recover from failed parking attempts such as this without 378 dropping the call to Alice is an important consequence of Bob sending 379 the REFER to the Park Server, rather than sending the REFER to Alice 380 so that she can park herself. 382 3. Retrieving a Parked Call 384 In order to retrieve a parked call, Carol needs to obtain the dialog 385 identifiers for the dialog between Alice and wherever Alice is 386 parked. 388 The dialog identifiers can be obtained by issuing a SUBSCRIBE for the 389 dialog event package [RFC4235]. The resulting NOTIFY will contain 390 details of all pertinent calls, including the dialog identifiers. 391 Carol may (if presented with multiple dialogs) choose which call to 392 retrieve. Many implementations choose the first dialog listed, 393 although some use the element to identify which call has 394 been parked for the longest time. Obtaining the dialog information 395 in this way follows the flow described in [RFC5359] (section 2.15). 397 By subscribing to the dialog event package [RFC4235] at the same URI 398 used for parking the call, i.e. 399 , all the information that 400 is required for the call to be retrieved by C is delivered in the 401 corresponding NOTIFY. 403 Similarly, if the call was parked in an environment that does not 404 require 'orbit' parameters, subscribing to the URI used for parking 405 the call, i.e. , will still result in 406 the necessary information being provided for the call to be 407 retrieved. 409 Alice Bob Park Server Carol 410 | | | | 411 | | | SUBSCRIBE F1 | 412 | | |<-------------| 413 | | | 200 OK F2 | 414 | | |------------->| 415 | | | NOTIFY F3 | 416 | | |------------->| 417 | | | 200 OK F4 | 418 | | |<-------------| 419 | | | | 420 | | | | 421 | INVITE Replaces: Park Server F5 | 422 |<-------------------------------------------| 423 | | | 200 F6 | 424 |------------------------------------------->| 425 | | | ACK F7 | 426 |<-------------------------------------------| 427 | RTP Media | 428 |<==========================================>| 429 | BYE F8 | | 430 |---------------------------->| | 431 | 200 OK F9 | | 432 |<----------------------------| | 434 F1 SUBSCRIBE Carol -> Park Server 436 SUBSCRIBE sips:park@server.example.com;orbit=1234 SIP/2.0 437 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK92bz 438 Max-Forwards: 70 439 From: Carol ;tag=8672349 440 To: 441 Call-ID: xt4653gs2ham@chicago.example.com 442 CSeq: 1 SUBSCRIBE 443 Contact: 444 Event: dialog 445 Subscription-State: active;expires=0 446 Accept: application/dialog-info+xml 447 Content-Length: 0 449 F2 200 OK Park Server -> Carol 451 SIP/2.0 200 OK 452 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK92bz 453 ;received=192.0.2.114 454 Max-Forwards: 70 455 From: Carol ;tag=8672349 456 To: ;tag=1234567 457 Call-ID: xt4653gs2ham@chicago.example.com 458 CSeq: 1 SUBSCRIBE 459 Content-Length: 0 460 F3 NOTIFY Park Server -> Carol 462 NOTIFY sips:carol@client.chicago.example.com SIP/2.0 463 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca 464 Max-Forwards: 70 465 To: Carol ;tag=8672349 466 From: ;tag=1234567 467 Call-ID: xt4653gs2ham@chicago.example.com 468 CSeq: 2 NOTIFY 469 Contact: 470 Event: dialog 471 Subscription-State: terminated 472 Content-Type: application/dialog-info+xml 473 Content-Length: ... 475 476 479 483 confirmed 484 485 487 F4 200 OK Carol -> Park Server 489 SIP/2.0 200 OK 490 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca 491 To: Carol ;tag=8672349 492 From: ;tag=1234567 493 Call-ID: xt4653gs2ham@chicago.example.com 494 CSeq: 2 NOTIFY 495 Contact: 496 Content-Length: 0 498 The remainder of the frames are the same as the corresponding frames 499 from [RFC5359], since the required dialog ID has been obtained 500 through the SUBSCRIBE / NOTIFY cycle from the Park Server. 502 4. User Agent Considerations 504 For Bob and Carol to be able to park and retrieve calls using a Park 505 Server, both need to be configured with the URI of the Park Server. 507 In addition, Bob and Carol should be configured to understand whether 508 or not an orbit will be required for park and retrieve. Finally, Bob 509 also needs to be configured to determine whether Bob should provide 510 the orbit or whether the orbit will be allocated by the Park Server. 512 Any orbit received from the Park Server, either in the Contact URI of 513 a 302 or 2xx response to REFER, should be rendered to the user in an 514 appropriate manner, especially if a different orbit was provided in 515 the initial REFER. This is to allow Park Servers to implement 516 various policy decisions and allocate orbits as required. Failure to 517 render the final orbit may lead to a call being parked on a different 518 orbit to the expected one, and hence being effectively lost. 520 If the UA provided an orbit in the REFER request, and no orbit is 521 received from the Park Server, then the UA may assume that the call 522 has been parked against the requested orbit correctly. 524 Alice's UA needs to support certain key pieces of protocol in order 525 to allow itself to be parked and retrieved. In addition to 526 [RFC3261], support for 'Replaces' is also required [RFC3891]. As 527 required by [RFC3261], the Contact URI should be globally routable, 528 so that an initial INVITE with a Replaces header may be received and 529 processed correctly. To help achieve this, [I-D.ietf-sip-gruu] may 530 be useful. Should the UA wish to mask the Contact URI for privacy 531 reasons, following the advice in [I-D.ietf-sip-ua-privacy] might 532 prove beneficial, although other solutions also exist. 534 5. Park Server Considerations 536 It is expected that Park Servers will not necessarily support all the 537 feature variations described in this document, at least not 538 simultaneously. Therefore Park Servers should offer the set that is 539 most appropriate for their target environment. For example, some 540 Park Servers may offer centrally allocated orbits, some may not, and 541 some may be configurable. 543 Park Servers will typically implement additional functionality at a 544 policy level. Examples of policy-related decisions include what 545 media to provide to parked calls, how to handle more than one call 546 being parked on a particular orbit, and how to handle a call that has 547 been parked for an excessive length of time. 549 If the Park Server chooses to allocate a parking orbit for a call, 550 consideration should be given to the format used in the target 551 environment. In particular, a short digit string should be used when 552 it is likely that the parked call will be retrieved by a UA with a 553 more limited user interface. This restriction may be relaxed for 554 more advanced parking applications. 556 6. Other Implementations and Interoperability 558 Several vendors already implement Call Park/Retrieve in different 559 ways. Many of these approaches use non-standard/proprietary 560 extensions to achieve some of the goals that this document addresses. 561 Interoperability is rarely a driving concern with proprietary 562 extensions, since a non-interoperable implementation is simply 563 regarded as not fully implemented. 565 This section describes some of the approaches that have been 566 implemented. It is not intended to be an exhaustive review of all 567 actual or possible implementations, nor is it intended to give 568 sufficient detail for new implementations. Instead, it aims to give 569 an overview sufficient to let the reader compare the different 570 tradeoffs that have been seen in the field. 572 6.1. Parking by blind transfer 574 Some implementations support call park by performing a Blind Transfer 575 to a URI of the form 'sip:xxxx@example.com', where 'xxxx' represents 576 the park number, or orbit. To retrieve a parked call, users 577 generally dial something of the form 'sip:*4xxxx@example.com'. The 578 park number and the retrieval code both exist in the local dialling 579 domain, and tend to be easy for UAs to dial. 581 This approach is generally supported by most UAs, since performing a 582 blind transfer is a commonly implemented feature. Dialling the 583 retrieval code is also commonly supported as it resembles a 'star 584 code', or 'Vertical Service Code'. 586 This approach doesn't permit park numbers to be centrally allocated, 587 as the user is required to select one when parking. The park numbers 588 must also be chosen so as to not clash with local extension numbers. 590 6.2. Parking by blind transfer with central allocation 592 At least one implementation supports parking a call by performing a 593 Blind Transfer to a preconfigured URI. The allocated parking orbit 594 is returned to the UA in the 202 response to the REFER, in a custom 595 header. The UA performing the park must understand this header, and 596 render the contents to the user. To retrieve the call, the park 597 number is simply dialled as though it were a local extension. 599 This approach requires explicit support in the UA used to park calls, 600 as the park number needs to be extracted from the response to the 601 REFER, and displayed to the user. Retrieving a call can be performed 602 by most UAs. 604 6.3. Parking with orbit parameters 606 Some implementations choose an approach that is similar to the one 607 described in this document. A Blind Transfer to a URI of the form 608 'sip:callpark@example.com;orbit=7001' is performed. Rather than 609 retrieving the call as described above, a call is made to the 610 corresponding URI 'sip:pickup@example.com;orbit=7001'. 612 This approach requires support in the UA used to park calls, since 613 the target of the Blind Transfer requires a uri parameter to be 614 added. Support is also required in the UA used to retrieve calls, 615 since again the URI in question requires a parameter. 617 No central allocation of park numbers is supported in this approach. 618 However, the parked numbers may overlap with the local extension plan 619 if desired, since calls are not directly placed to the park numbers. 621 6.4. Parking on the User Agent 623 Some implementations require the User Agents to perform all park- 624 related functionality. To do this, each UA that is expected to park 625 calls is configured with a range of park numbers. Should a UA wish 626 to park a call, it keeps the call on hold locally, and registers 627 itself against one of its park numbers. Any other UA can then 628 retrieve the call by dialling the park number. The call arrives at 629 the parking UA, which can connect it to the held call using 3rd party 630 call control. 632 This approach requires explicit support in the UA used to park calls. 633 Retrieving a call can be performed by most UAs. 635 Whilst attractive from the perspective of not needing any centralised 636 server support, this approach suffers from the requirement to 637 preconfigure all the UAs with park numbers, in case they need to park 638 a call. Failure to provision enough numbers will prevent calls from 639 being parked on a particular phone. Conversely, provisioning too 640 many numbers will rapidly deplete the local extension numbering 641 space. 643 7. Acknowledgements 645 The following individuals were part of the Call Park Design Team, and 646 have helped to shape this document: 648 Francois Audet, Jason Fischl, Derek Macdonald, Shida Schubert, Sanjay 649 Sinha, Dale Worley and Theo Zourzouvillys. 651 Additional feedback was received from Scott Orton, Andy Hutton and 652 John Elwell. 654 8. Security Considerations 656 None. 658 9. IANA Considerations 660 Open issue: According to [RFC3969], defining a URI parameter can only 661 be done in a standards-track RFC. That doesn't sound like the sort 662 of thing this document will do, nor the sort of thing BLISS will do 663 either. However, [RFC4240] ('netann') defines values that are 664 included in the current registry, and it is most definately 665 'Informational'. 667 This specification adds a new value to the IANA "SIP/SIPS URI 668 Parameters" registry as defined in [RFC3969]. 670 Parameter Name Predefined Values Reference 671 ____________________________________________ 672 orbit No RFCxxxx 674 The ABNF [RFC5234] grammar for this parameter is shown below. The 675 definition of 'pvalue' is given in [RFC3261]. 677 orbit-param = "orbit" EQUAL orbit-value 678 orbit-value = pvalue 680 10. References 682 10.1. Normative References 684 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 685 A., Peterson, J., Sparks, R., Handley, M., and E. 686 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 687 June 2002. 689 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 690 K. Summers, "Session Initiation Protocol Service 691 Examples", BCP 144, RFC 5359, October 2008. 693 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 694 Initiated Dialog Event Package for the Session Initiation 695 Protocol (SIP)", RFC 4235, November 2005. 697 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 698 Specifications: ABNF", STD 68, RFC 5234, January 2008. 700 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 701 (IANA) Uniform Resource Identifier (URI) Parameter 702 Registry for the Session Initiation Protocol (SIP)", 703 BCP 99, RFC 3969, December 2004. 705 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 706 Protocol (SIP) "Replaces" Header", RFC 3891, 707 September 2004. 709 10.2. Informative References 711 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 712 (SIP) Call Control - Conferencing for User Agents", 713 BCP 119, RFC 4579, August 2006. 715 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 716 Media Services with SIP", RFC 4240, December 2005. 718 [I-D.ietf-sip-gruu] 719 Rosenberg, J., "Obtaining and Using Globally Routable User 720 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 721 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 722 October 2007. 724 [I-D.ietf-sip-ua-privacy] 725 Munakata, M., Schubert, S., and T. Ohba, "UA-Driven 726 Privacy Mechanism for SIP", draft-ietf-sip-ua-privacy-08 727 (work in progress), May 2009. 729 Author's Address 731 Michael Procter 732 VoIP.co.uk 733 Commerce House 734 Telford Road 735 Bicester, Oxfordshire OX26 4LD 736 UK 738 Email: michael@voip.co.uk 739 URI: http://voip.co.uk