idnits 2.17.1 draft-procter-bliss-call-park-extension-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 612. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2008) is 5880 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-13 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Procter 3 Internet-Draft Citel Technologies Ltd 4 Intended status: Informational February 21, 2008 5 Expires: August 24, 2008 7 Implementing Call Park and Retrieve using the Session Initiation 8 Protocol (SIP) 9 draft-procter-bliss-call-park-extension-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 24, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Call Park and Call Retrieve are useful telephony services that are 43 familiar to many users. Existing implementations using the Session 44 Initiation Protocol (SIP) show that a variety of approaches can be 45 taken, with varying degrees of interoperability. This draft 46 discusses a number of feature variations, and how they may be 47 implemented. 49 Table of Contents 51 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Parking a call . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Parking a call without an orbit . . . . . . . . . . . . . 4 54 2.2. Parking a call with a specified orbit . . . . . . . . . . 4 55 2.3. Parking a call with a Park-Server allocated orbit . . . . 6 56 2.4. A failed attempt to park a call . . . . . . . . . . . . . 8 57 2.5. Parking a call without a Park Server . . . . . . . . . . . 9 58 3. Retrieving a Parked Call . . . . . . . . . . . . . . . . . . . 9 59 3.1. Retrieving a call from a Park Server . . . . . . . . . . . 10 60 3.2. Retrieving a call from a User Agent . . . . . . . . . . . 12 61 4. User Agent Configuration . . . . . . . . . . . . . . . . . . . 13 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 Intellectual Property and Copyright Statements . . . . . . . . . . 16 71 1. Overview 73 Call Park is a feature that enables UAs to make a call inactive but 74 not terminated, in such a way as to allow the call to be resumed by 75 the UA that parked the call, or by a different UA. 77 This feature is typically used when User A wishes to transfer a call 78 in progress to User B, but doesn't necessarily know how to reach User 79 B's UA directly. In this situation, User A parks the call, and then 80 tells User B where the call is parked. User B may then retrieve the 81 call using a convenient UA. 83 Other uses include allowing multiple calls to be parked at the same 84 'location', and forming a queue. In this way, a simple 'ACD' system 85 can be implemented that permits calls to be initially sorted and 86 placed in one of a number of queues, ready to be handled when an 87 appropriate agent becomes available (and retrieves the next call from 88 the queue). 90 In all cases, the parked call is subsequently identifiable by a short 91 (typically 3 or 4 digit) label known as an 'orbit'. This orbit is 92 often allocated by the user parking the call, but some environments 93 favour allocation of the orbit by a Park Server. Both approaches are 94 described in this document. 96 Having a Park Server for parked calls is a useful approach, which 97 secures parked calls against User Agent rebooting and other losses of 98 service. However, being able to park and retrieve calls without a 99 Park Server is also a useful model, both in terms of decentralised 100 network design and also for smaller installations that don't 101 necessarily merit a separate Park Server. Therefore, parking with 102 and without a Park Server are discussed in this document. 104 2. Parking a call 106 A basic call flow for Call Park is given in [1] (section 2.15), and 107 this forms the basis of the feature. This approach uses the SIP 108 dialog ID between the parked endpoint and the park server itself as 109 the unique parked call identifier. Using the dialog ID has a number 110 of advantages since it is unique and allocated by both the parked 111 user and the Park Server. However, it is also long, which can lead 112 to problems when trying to identify parked calls by verbal or human- 113 written mechanisms. 115 Traditional PBX users have become accustomed to parking a call 116 against a short number (typically 3 or 4 digits), and then using this 117 identifier to communicate to the retrieving party which call to 118 retrieve. This information may be passed verbally, or by means of 119 small paper notes. Whilst collisions may occur, they are generally 120 avoided satisfactorily by administrative policies. 122 This draft attempts to reconcile these two models by allowing a short 123 label to be attached to a parked call (the 'orbit'). The retrieving 124 party can then use the same tag to locate the relevant dialog ID in 125 order to retrieve the parked call. 127 2.1. Parking a call without an orbit 129 Certain environments do not require an 'orbit' to be used, either 130 because calls are parked in a single queue, or the dialog identifiers 131 are readily passed between concerned UAs. In this scenario, the flow 132 described in [1] is followed without deviation. 134 2.2. Parking a call with a specified orbit 136 The message flow of parking a call in this scenario is identical to 137 that illustrated in [1]. The difference that this draft introduces 138 is in the REFER message to the Park Server. The details of the REFER 139 message changes are discussed below. 141 Alice Bob Park Server Carol 142 | | | | 143 | INVITE F1 | | | 144 |------------->| | | 145 |180 Ringing F2| | | 146 |<-------------| | | 147 | 200 OK F3 | | | 148 |<-------------| | | 149 | ACK F4 | | | 150 |------------->| | | 151 | RTP Media | | | 152 |<============>| | | 153 | Bob Parks Call | | 154 | | REFER Refer-To: A F5 | 155 | |------------->| | 156 | | 202 F6 | | 157 | |<-------------| | 158 | | NOTIFY F7 | | 159 | |<-------------| | 160 | | 200 F8 | | 161 | |------------->| | 162 | INVITE F9 Replaces: B | | 163 |<----------------------------| | 164 | 200 OK F10 | | 165 |---------------------------->| | 166 | ACK F11 | | 167 |<----------------------------| | 168 |(Music-on-Hold or other RTP?)| | 169 |<===========================>| | 170 | BYE F12 | | | 171 |------------->| NOTIFY F14 | | 172 | 200 OK F13 |<-------------| | 173 |<-------------| 200 OK F15 | | 174 | |------------->| | 176 The URI is used instead of 177 directing the request to the URI . The 178 addition of the orbit parameter effectively tags the parked call with 179 a short memorable code entered by the user. 181 F5 REFER Bob -> Park Server 183 REFER sips:park-server@example.com;orbit=1234 SIP/2.0 184 Via: SIP/2.0/TLS client.biloxi.example.com:5061 185 ;branch=z9hG4bKnashds9 186 Max-Forwards: 70 187 From: Bob ;tag=02134 188 To: Park Server 189 Call-ID: 4802029847@biloxi.example.com 190 CSeq: 1 REFER 191 192 Refer-To: 195 196 Referred-By: 197 Contact: 198 Content-Length: 0 200 2.3. Parking a call with a Park-Server allocated orbit 202 Sometimes an orbit number assignment policy needs to be implemented. 203 This may be to ensure that all orbit numbers are a particular length, 204 or have a form that means that they can be dialled directly (given 205 suitable extensions to an Application Server). It may also be 206 implemented to eliminate the problem of trying to park more than one 207 call on the same orbit. 209 To enforce a policy, we ensure that the orbit number is not allocated 210 by the UA (entered by the user, or by configuration etc.) but is 211 instead allocated by the Park Server, and relayed to the UA. The 212 approach taken here is analogous to the Conference Factory approach 213 described in [3]. Bob sends a REFER to the preconfigured Park Server 214 URI, but without any 'orbit' parameter added. The Park Server then 215 responds by redirecting Bob to the correct orbit by using a '302 216 Moved Temporarily' response. The orbit can then be found by 217 inspecting this new target. Note that an intermediate proxy may 218 recurse on this 302 response and Bob may never see the redirect. In 219 this scenario, Bob can still extract the orbit from Contact of 2xx 220 response to the original REFER. 222 Alice Bob Park Server Carol 223 | | | | 224 | INVITE F1 | | | 225 |------------->| | | 226 |180 Ringing F2| | | 227 |<-------------| | | 228 | 200 OK F3 | | | 229 |<-------------| | | 230 | ACK F4 | | | 231 |------------->| | | 232 | RTP Media | | | 233 |<============>| | | 234 | Bob Parks Call | | 235 | | REFER Refer-To: A F5 | 236 | |------------->| | 237 | |302 Orbit allocated F6 | 238 | |<-------------| | 239 | | REFER Refer-To: A F7 | 240 | |------------->| | 241 | |202 Accepted F8 | 242 | |<-------------| | 243 | | NOTIFY | | 244 | |<-------------| | 245 | | 200 OK | | 246 | |------------->| | 247 | INVITE Replaces: Bob | | 248 |<----------------------------| | 249 | 200 OK | | 250 |---------------------------->| | 251 | ACK | | 252 |<----------------------------| | 253 |(Music-on-Hold or other RTP?)| | 254 |<===========================>| | 255 | BYE | | | 256 |------------->| NOTIFY | | 257 | 200 OK |<-------------| | 258 |<-------------| 200 OK | | 259 | |------------->| | 261 F5 REFER Bob -> Park Server 263 REFER sips:park-server@example.com SIP/2.0 264 Via: SIP/2.0/TLS client.biloxi.example.com:5061 265 ;branch=z9hG4bKnashdsB 266 Max-Forwards: 70 267 From: Bob ;tag=22134 268 To: Park Server 269 Call-ID: 4802029847@biloxi.example.com 270 CSeq: 1 REFER 271 272 Refer-To: 275 276 Referred-By: 277 Contact: 278 Content-Length: 0 280 F6 302 Orbit Allocated Park Server -> Bob 282 SIP/2.0 202 Orbit Allocated 283 Via: SIP/2.0/TLS client.biloxi.example.com:5061 284 ;branch=z9hG4bKnashdsB 285 ;received=192.0.2.105 286 From: Bob ;tag=22134 287 To: Park Server ;tag=56324 288 Call-ID: 4802029848@biloxi.example.com 289 CSeq: 1 REFER 290 Contact: 291 Content-Length: 0 293 Once Bob's UA learns of the allocated orbit (either by finding it in 294 the 302 response, or by finding it in the Contact of the 202 response 295 to the REFER), it can be passed to the user (Bob) in an appropriate 296 manner. 298 2.4. A failed attempt to park a call 300 A Park Server may choose to reject a park attempt for many reasons, 301 including prohibiting multiple calls being parked against the same 302 orbit, or prohibiting certain users from parking calls on certain 303 orbits. Whatever the reason, the response sent to Bob will enable 304 Bob to take appropriate action. The following example shows the Park 305 Server rejecting a call due to the orbit already being in use. 307 Alice Bob Park Server Carol 308 | | | | 309 | INVITE F1 | | | 310 |------------->| | | 311 |180 Ringing F2| | | 312 |<-------------| | | 313 | 200 OK F3 | | | 314 |<-------------| | | 315 | ACK F4 | | | 316 |------------->| | | 317 | RTP Media | | | 318 |<============>| | | 319 | Bob Parks Call | | 320 | | REFER Refer-To: A F5 | 321 | |------------->| | 322 | |486 Busy Here | | 323 | |<-------------| | 325 When Bob's parking attempt is rejected, Bob may choose to attempt to 326 park the call again, but using a different orbit number. The ability 327 for Bob to recover from failed parking attempts such as this without 328 dropping the call to Alice is an important consequence of Bob sending 329 the REFER to the Park Server, rather than sending the REFER to Alice 330 so that she can park herself. 332 2.5. Parking a call without a Park Server 334 Sometimes, it is useful to be able to park a call without using a 335 Park Server. The original dialog between Alice and Bob is 336 maintained, even though Bob has notionally parked the call. As a 337 consequence, the only changes that occur may be within Bob's UA, and 338 will not necessarily involve any SIP signalling. 340 3. Retrieving a Parked Call 342 In order to retrieve a parked call, Carol needs to obtain the dialog 343 identifiers for the dialog between Alice and wherever Alice is 344 parked. 346 The dialog identifiers can be obtained by issuing a SUBSCRIBE for the 347 dialog event package [2]. The resulting NOTIFY will contain details 348 of all pertinent calls, including the dialog identifiers. Carol may 349 (if presented with multiple dialogs) choose which call to retrieve. 350 Many implementations choose the first dialog listed, although some 351 use the element to identify which call has been parked for 352 the longest time. 354 Once Carol has the necessary dialog identifiers, she can retrieve the 355 parked call using the flow descibed in [1]. 357 3.1. Retrieving a call from a Park Server 359 By subscribing to the dialog event package [2] at the same URI used 360 for parking the call, i.e. , 361 all the information that is required for the call to be retrieved by 362 C is delivered in the corresponding NOTIFY. 364 Similarly, if the call was parked in an environment that does not 365 require 'orbit' parameters, subscribing to the URI used for parking 366 the call, i.e. , will still result in 367 the necessary information being provided for the call to be 368 retrieved. 370 Alice Bob Park Server Carol 371 | | | | 372 | | | SUBSCRIBE F1 | 373 | | |<-------------| 374 | | | 200 OK F2 | 375 | | |------------->| 376 | | | NOTIFY F3 | 377 | | |------------->| 378 | | | 200 OK F4 | 379 | | |<-------------| 380 | | | | 381 | | | | 382 | INVITE Replaces: Park Server F5 | 383 |<-------------------------------------------| 384 | | | 200 F6 | 385 |------------------------------------------->| 386 | | | ACK F7 | 387 |<-------------------------------------------| 388 | RTP Media | 389 |<==========================================>| 390 | BYE F8 | | 391 |---------------------------->| | 392 | 200 OK F9 | | 393 |<----------------------------| | 395 F1 SUBSCRIBE Carol -> Park Server 397 SUBSCRIBE sips:park-server@example.com;orbit=1234 SIP/2.0 398 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK92bz 399 Max-Forwards: 70 400 From: Carol ;tag=8672349 401 To: 402 Call-ID: xt4653gs2ham@chicago.example.com 403 CSeq: 1 SUBSCRIBE 404 Contact: 405 Event: dialog 406 Subscription-State: active;expires=0 407 Accept: application/dialog-info+xml 408 Content-Length: 0 410 F2 200 OK Park Server -> Carol 412 SIP/2.0 200 OK 413 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK92bz 414 ;received=192.0.2.114 415 Max-Forwards: 70 416 From: Carol ;tag=8672349 417 To: ;tag=1234567 418 Call-ID: xt4653gs2ham@chicago.example.com 419 CSeq: 1 SUBSCRIBE 420 Content-Length: 0 422 F3 NOTIFY Park Server -> Carol 424 NOTIFY sips:carol@client.chicago.example.com SIP/2.0 425 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca 426 Max-Forwards: 70 427 To: Carol ;tag=8672349 428 From: ;tag=1234567 429 Call-ID: xt4653gs2ham@chicago.example.com 430 CSeq: 2 NOTIFY 431 Contact: 432 Event: dialog 433 Subscription-State: terminated 434 Content-Type: application/dialog-info+xml 435 Content-Length: ... 437 438 441 445 confirmed 446 447 449 F4 200 OK Carol -> Park Server 451 SIP/2.0 200 OK 452 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca 453 To: Carol ;tag=8672349 454 From: ;tag=1234567 455 Call-ID: xt4653gs2ham@chicago.example.com 456 CSeq: 2 NOTIFY 457 Contact: 458 Content-Length: 0 460 The remainder of the frames are the same as the corresponding frames 461 from [1], since the required dialog ID has been obtained through the 462 SUBSCRIBE / NOTIFY cycle from the Park Server. 464 3.2. Retrieving a call from a User Agent 466 Retrieving a parked call from a User Agent is very similar to 467 retrieving a call from a Park Server. The main difference is 468 identifying which URI should be used for the initial subscription, in 469 order to find the dialog identifiers for the parked call. 471 The URI most likely to be known for a particular User Agent is the 472 AoR. But this may correspond to multiple UAs. Therefore, if Carol 473 subscribes to the AoR, she should be prepared for multple NOTIFY 474 responses, should her SUBSCRIBE fork. 476 It is tempting to state that Carol should subscribe to the GRUU of 477 the UA with the parked call. This will work well if the GRUU is 478 known in advance (possibly by Carol having a long-lived subscription 479 to Bob's UA). If the GRUU is not known in advance, then it may prove 480 too onerous to expect it to be typed in on Carol's UA, just to 481 retrieve a parked call. 483 Open issue: Is subscribing to the AoR the best we can offer? 485 Using the 'orbit' parameter in conjunction with parking calls on User 486 Agents can lead to difficulties in ensuring that the 'orbit' 487 parameter is delivered to the User Agent. See [4] and [5] for the 488 currently debated approaches. 490 Open issue: I think either approach will serve our purposes here. 491 Presumably we can just wait and see which one is favoured. 493 If the 'orbit' parameter is not used, then Carol will eventually find 494 out about all the dialogs currently in progress at Bob's UA. 495 Distinguishing the parked call from other dialogs may prove 496 challenging (assuming that all calls marked as held is not 497 acceptable). There may be an opportunity to reuse some BLISS-MLA 498 work here, which permits dialogs to be marked as 'exclusive', which 499 indicates that other UAs should not attempt to pick them up. 501 Open issue: How should a parked call be identified when parked on a 502 UA with other (potentially non-parked) dialogs in progress? Does 503 this problem only exist when an orbit is not used? 505 4. User Agent Configuration 507 For Bob and Carol to be able to park and retrieve calls using a Park 508 Server, both need to be configured with the URI of the Park Server. 509 In addition, Bob and Carol should be configured to understand whether 510 or not an orbit will be required for park and retrieve. Finally, Bob 511 also needs to be configured to determine whether Bob should provide 512 the orbit or whether the orbit will be allocated by the Park Server. 514 5. Acknowledgements 516 The following individuals were part of the Call Park Design Team, and 517 have helped to shape this document: 519 Francois Audet 520 Jason Fischl 521 Derek Macdonald 522 Shida Schubert 523 Sanjay Sinha 524 Dale Worley 525 Theo Zourzouvillys 527 6. Security Considerations 529 None. 531 7. IANA Considerations 533 Open issue: presumably need to define the new uri-parameter 'orbit'. 535 8. References 537 8.1. Normative References 539 [1] Johnston, A., "Session Initiation Protocol Service Examples", 540 draft-ietf-sipping-service-examples-13 (work in progress), 541 July 2007. 543 [2] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 544 Initiated Dialog Event Package for the Session Initiation 545 Protocol (SIP)", RFC 4235, November 2005. 547 8.2. Informative References 549 [3] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) 550 Call Control - Conferencing for User Agents", BCP 119, RFC 4579, 551 August 2006. 553 [4] Rosenberg, J., "Applying Loose Routing to Session Initiation 554 Protocol (SIP) User Agents (UA)", 555 draft-rosenberg-sip-ua-loose-route-02 (work in progress), 556 January 2008. 558 [5] Holmberg, C. and H. Elburg, "Target URI delivery in the Session 559 Initiation Protocol (SIP)", 560 draft-holmberg-sip-target-uri-delivery-01 (work in progress), 561 January 2008. 563 Author's Address 565 Michael Procter 566 Citel Technologies Ltd 567 Wheatcroft Business Park 568 Landmere Lane, Edwalton 569 Nottingham NG12 4DG 570 UK 572 Email: michael.procter@citel.com 574 Full Copyright Statement 576 Copyright (C) The IETF Trust (2008). 578 This document is subject to the rights, licenses and restrictions 579 contained in BCP 78, and except as set forth therein, the authors 580 retain all their rights. 582 This document and the information contained herein are provided on an 583 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 584 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 585 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 586 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 587 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 588 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 590 Intellectual Property 592 The IETF takes no position regarding the validity or scope of any 593 Intellectual Property Rights or other rights that might be claimed to 594 pertain to the implementation or use of the technology described in 595 this document or the extent to which any license under such rights 596 might or might not be available; nor does it represent that it has 597 made any independent effort to identify any such rights. Information 598 on the procedures with respect to rights in RFC documents can be 599 found in BCP 78 and BCP 79. 601 Copies of IPR disclosures made to the IETF Secretariat and any 602 assurances of licenses to be made available, or the result of an 603 attempt made to obtain a general license or permission for the use of 604 such proprietary rights by implementers or users of this 605 specification can be obtained from the IETF on-line IPR repository at 606 http://www.ietf.org/ipr. 608 The IETF invites any interested party to bring to its attention any 609 copyrights, patents or patent applications, or other proprietary 610 rights that may cover technology that may be required to implement 611 this standard. Please address the information to the IETF at 612 ietf-ipr@ietf.org. 614 Acknowledgment 616 Funding for the RFC Editor function is provided by the IETF 617 Administrative Support Activity (IASA).