idnits 2.17.1 draft-procter-bliss-call-park-extension-02.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 580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 604. 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 (August 15, 2008) is 5732 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 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 August 15, 2008 5 Expires: February 16, 2009 7 Implementing Call Park and Retrieve using the Session Initiation 8 Protocol (SIP) 9 draft-procter-bliss-call-park-extension-02 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 February 16, 2009. 36 Abstract 38 Call Park and Call Retrieve are useful telephony services that are 39 familiar to many users. Existing implementations using the Session 40 Initiation Protocol (SIP) show that a variety of approaches can be 41 taken, with varying degrees of interoperability. This draft 42 discusses a number of feature variations, and how they may be 43 implemented. 45 Table of Contents 47 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Parking a call . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.1. Parking a call without an orbit . . . . . . . . . . . . . 4 50 2.2. Parking a call with a specified orbit . . . . . . . . . . 4 51 2.3. Parking a call with a Park-Server allocated orbit . . . . 6 52 2.4. A failed attempt to park a call . . . . . . . . . . . . . 8 53 2.5. Parking a call without a Park Server . . . . . . . . . . . 9 54 3. Retrieving a Parked Call . . . . . . . . . . . . . . . . . . . 9 55 3.1. Retrieving a call from a Park Server . . . . . . . . . . . 10 56 3.2. Retrieving a call from a User Agent . . . . . . . . . . . 12 57 4. User Agent Configuration . . . . . . . . . . . . . . . . . . . 13 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 Intellectual Property and Copyright Statements . . . . . . . . . . 16 67 1. Overview 69 Call Park is a feature that enables UAs to make a call inactive but 70 not terminated, in such a way as to allow the call to be resumed by 71 the UA that parked the call, or by a different UA. 73 This feature is typically used when User A wishes to transfer a call 74 in progress to User B, but doesn't necessarily know how to reach User 75 B's UA directly. In this situation, User A parks the call, and then 76 tells User B where the call is parked. User B may then retrieve the 77 call using a convenient UA. 79 Other uses include allowing multiple calls to be parked at the same 80 'location', and forming a queue. In this way, a simple 'ACD' 81 (Automatic Call Distribution) system can be implemented that permits 82 calls to be initially sorted and placed in one of a number of queues, 83 ready to be handled when an appropriate agent becomes available (and 84 retrieves the next call from the queue). 86 In all cases, the parked call is subsequently identifiable by a short 87 (typically 3 or 4 digit) label known as an 'orbit'. This orbit is 88 often allocated by the user parking the call, but some environments 89 favour allocation of the orbit by a Park Server. Both approaches are 90 described in this document. 92 Having a Park Server for parked calls is a useful approach, which 93 secures parked calls against User Agent rebooting and other losses of 94 service. However, being able to park and retrieve calls without a 95 Park Server is also a useful model, both in terms of decentralised 96 network design and also for smaller installations that don't 97 necessarily merit a separate Park Server. Therefore, parking with 98 and without a Park Server are discussed in this document. 100 2. Parking a call 102 A basic call flow for Call Park is given in 103 [I-D.ietf-sipping-service-examples] (section 2.15), and this forms 104 the basis of the feature. This approach uses the SIP dialog ID 105 between the parked endpoint and the park server itself as the unique 106 parked call identifier. Using the dialog ID has a number of 107 advantages since it is unique and allocated by both the parked user 108 and the Park Server. However, it is also long, which can lead to 109 problems when trying to identify parked calls by verbal or human- 110 written mechanisms. 112 Traditional PBX users have become accustomed to parking a call 113 against a short number (typically 3 or 4 digits), and then using this 114 identifier to communicate to the retrieving party which call to 115 retrieve. This information may be passed verbally, or by means of 116 small paper notes. Whilst collisions may occur, they are generally 117 avoided satisfactorily by administrative policies. 119 This draft attempts to reconcile these two models by allowing a short 120 label to be attached to a parked call (the 'orbit'). The retrieving 121 party can then use the same tag to locate the relevant dialog ID in 122 order to retrieve the parked call. 124 2.1. Parking a call without an orbit 126 Certain environments do not require an 'orbit' to be used, either 127 because calls are parked in a single queue, or the dialog identifiers 128 are readily passed between concerned UAs. In this scenario, the flow 129 described in [I-D.ietf-sipping-service-examples] is followed without 130 deviation. 132 2.2. Parking a call with a specified orbit 134 The message flow of parking a call in this scenario is identical to 135 that illustrated in [I-D.ietf-sipping-service-examples]. The 136 difference that this draft introduces is in the REFER message to the 137 Park Server. The details of the REFER message changes are discussed 138 below. 140 Alice Bob Park Server Carol 141 | | | | 142 | INVITE F1 | | | 143 |------------->| | | 144 |180 Ringing F2| | | 145 |<-------------| | | 146 | 200 OK F3 | | | 147 |<-------------| | | 148 | ACK F4 | | | 149 |------------->| | | 150 | RTP Media | | | 151 |<============>| | | 152 | Bob Parks Call | | 153 | | REFER Refer-To: A F5 | 154 | |------------->| | 155 | | 202 F6 | | 156 | |<-------------| | 157 | | NOTIFY F7 | | 158 | |<-------------| | 159 | | 200 F8 | | 160 | |------------->| | 161 | INVITE F9 Replaces: B | | 162 |<----------------------------| | 163 | 200 OK F10 | | 164 |---------------------------->| | 165 | ACK F11 | | 166 |<----------------------------| | 167 |(Music-on-Hold or other RTP?)| | 168 |<===========================>| | 169 | BYE F12 | | | 170 |------------->| NOTIFY F14 | | 171 | 200 OK F13 |<-------------| | 172 |<-------------| 200 OK F15 | | 173 | |------------->| | 175 The URI is used instead of 176 directing the request to the URI . The 177 addition of the orbit parameter effectively tags the parked call with 178 a short memorable code entered by the user. 180 F5 REFER Bob -> Park Server 182 REFER sips:park-server@example.com;orbit=1234 SIP/2.0 183 Via: SIP/2.0/TLS client.biloxi.example.com:5061 184 ;branch=z9hG4bKnashds9 185 Max-Forwards: 70 186 From: Bob ;tag=02134 187 To: Park Server 188 Call-ID: 4802029847@biloxi.example.com 189 CSeq: 1 REFER 190 191 Refer-To: 194 195 Referred-By: 196 Contact: 197 Content-Length: 0 199 2.3. Parking a call with a Park-Server allocated orbit 201 Sometimes an orbit number assignment policy needs to be implemented. 202 This may be to ensure that all orbit numbers are a particular length, 203 or have a form that means that they can be dialled directly (given 204 suitable extensions to an Application Server). It may also be 205 implemented to eliminate the problem of trying to park more than one 206 call on the same orbit. 208 To enforce a policy, we ensure that the orbit number is not allocated 209 by the UA (entered by the user, or by configuration etc.) but is 210 instead allocated by the Park Server, and relayed to the UA. The 211 approach taken here is analogous to the Conference Factory approach 212 described in [RFC4579]. Bob sends a REFER to the preconfigured Park 213 Server URI, but without any 'orbit' parameter added. The Park Server 214 then responds by redirecting Bob to the correct orbit by using a '302 215 Moved Temporarily' response. The orbit can then be found by 216 inspecting this new target. Note that an intermediate proxy may 217 recurse on this 302 response and Bob may never see the redirect. In 218 this scenario, Bob can still extract the orbit from Contact of 2xx 219 response to the original REFER. 221 Alice Bob Park Server Carol 222 | | | | 223 | INVITE F1 | | | 224 |------------->| | | 225 |180 Ringing F2| | | 226 |<-------------| | | 227 | 200 OK F3 | | | 228 |<-------------| | | 229 | ACK F4 | | | 230 |------------->| | | 231 | RTP Media | | | 232 |<============>| | | 233 | Bob Parks Call | | 234 | | REFER Refer-To: A F5 | 235 | |------------->| | 236 | |302 Orbit allocated F6 | 237 | |<-------------| | 238 | | REFER Refer-To: A F7 | 239 | |------------->| | 240 | |202 Accepted F8 | 241 | |<-------------| | 242 | | NOTIFY | | 243 | |<-------------| | 244 | | 200 OK | | 245 | |------------->| | 246 | INVITE Replaces: Bob | | 247 |<----------------------------| | 248 | 200 OK | | 249 |---------------------------->| | 250 | ACK | | 251 |<----------------------------| | 252 |(Music-on-Hold or other RTP?)| | 253 |<===========================>| | 254 | BYE | | | 255 |------------->| NOTIFY | | 256 | 200 OK |<-------------| | 257 |<-------------| 200 OK | | 258 | |------------->| | 260 F5 REFER Bob -> Park Server 262 REFER sips:park-server@example.com SIP/2.0 263 Via: SIP/2.0/TLS client.biloxi.example.com:5061 264 ;branch=z9hG4bKnashdsB 265 Max-Forwards: 70 266 From: Bob ;tag=22134 267 To: Park Server 268 Call-ID: 4802029847@biloxi.example.com 269 CSeq: 1 REFER 270 271 Refer-To: 274 275 Referred-By: 276 Contact: 277 Content-Length: 0 279 F6 302 Orbit Allocated Park Server -> Bob 281 SIP/2.0 202 Orbit Allocated 282 Via: SIP/2.0/TLS client.biloxi.example.com:5061 283 ;branch=z9hG4bKnashdsB 284 ;received=192.0.2.105 285 From: Bob ;tag=22134 286 To: Park Server ;tag=56324 287 Call-ID: 4802029848@biloxi.example.com 288 CSeq: 1 REFER 289 Contact: 290 Content-Length: 0 292 Once Bob's UA learns of the allocated orbit (either by finding it in 293 the 302 response, or by finding it in the Contact of the 202 response 294 to the REFER), it can be passed to the user (Bob) in an appropriate 295 manner. 297 2.4. A failed attempt to park a call 299 A Park Server may choose to reject a park attempt for many reasons, 300 including prohibiting multiple calls being parked against the same 301 orbit, or prohibiting certain users from parking calls on certain 302 orbits. Whatever the reason, the response sent to Bob will enable 303 Bob to take appropriate action. The following example shows the Park 304 Server rejecting a call due to the orbit already being in use. 306 Alice Bob Park Server Carol 307 | | | | 308 | INVITE F1 | | | 309 |------------->| | | 310 |180 Ringing F2| | | 311 |<-------------| | | 312 | 200 OK F3 | | | 313 |<-------------| | | 314 | ACK F4 | | | 315 |------------->| | | 316 | RTP Media | | | 317 |<============>| | | 318 | Bob Parks Call | | 319 | | REFER Refer-To: A F5 | 320 | |------------->| | 321 | |486 Busy Here | | 322 | |<-------------| | 324 When Bob's parking attempt is rejected, Bob may choose to attempt to 325 park the call again, but using a different orbit number. The ability 326 for Bob to recover from failed parking attempts such as this without 327 dropping the call to Alice is an important consequence of Bob sending 328 the REFER to the Park Server, rather than sending the REFER to Alice 329 so that she can park herself. 331 2.5. Parking a call without a Park Server 333 Sometimes, it is useful to be able to park a call without using a 334 Park Server. The original dialog between Alice and Bob is 335 maintained, even though Bob has notionally parked the call. As a 336 consequence, the only changes that occur may be within Bob's UA, and 337 will not necessarily involve any SIP signalling. 339 3. Retrieving a Parked Call 341 In order to retrieve a parked call, Carol needs to obtain the dialog 342 identifiers for the dialog between Alice and wherever Alice is 343 parked. 345 The dialog identifiers can be obtained by issuing a SUBSCRIBE for the 346 dialog event package [RFC4235]. The resulting NOTIFY will contain 347 details of all pertinent calls, including the dialog identifiers. 348 Carol may (if presented with multiple dialogs) choose which call to 349 retrieve. Many implementations choose the first dialog listed, 350 although some use the element to identify which call has 351 been parked for the longest time. Obtaining the dialog information 352 in this way follows the flow described in 354 [I-D.ietf-sipping-service-examples]. 356 3.1. Retrieving a call from a Park Server 358 By subscribing to the dialog event package [RFC4235] at the same URI 359 used for parking the call, i.e. 360 , all the information that 361 is required for the call to be retrieved by C is delivered in the 362 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 421 F3 NOTIFY Park Server -> Carol 423 NOTIFY sips:carol@client.chicago.example.com SIP/2.0 424 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca 425 Max-Forwards: 70 426 To: Carol ;tag=8672349 427 From: ;tag=1234567 428 Call-ID: xt4653gs2ham@chicago.example.com 429 CSeq: 2 NOTIFY 430 Contact: 431 Event: dialog 432 Subscription-State: terminated 433 Content-Type: application/dialog-info+xml 434 Content-Length: ... 436 437 440 444 confirmed 445 446 448 F4 200 OK Carol -> Park Server 450 SIP/2.0 200 OK 451 Via: SIP/2.0/TLS chicago.example.com:5061;branch=z9hG4bK93ca 452 To: Carol ;tag=8672349 453 From: ;tag=1234567 454 Call-ID: xt4653gs2ham@chicago.example.com 455 CSeq: 2 NOTIFY 456 Contact: 457 Content-Length: 0 459 The remainder of the frames are the same as the corresponding frames 460 from [I-D.ietf-sipping-service-examples], since the required dialog 461 ID has been obtained through the SUBSCRIBE / NOTIFY cycle from the 462 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 multiple 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. Current thinking favours 488 an approach based upon [RFC4244]. 490 Open issue: Once this has moved on a little, we can ensure it meets 491 our needs. 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, Jason Fischl, Derek Macdonald, Shida Schubert, Sanjay 520 Sinha, Dale Worley and Theo Zourzouvillys. 522 6. Security Considerations 524 None. 526 7. IANA Considerations 528 Open issue: presumably need to define the new uri-parameter 'orbit'. 530 8. References 532 8.1. Normative References 534 [I-D.ietf-sipping-service-examples] 535 Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 536 K. Summers, "Session Initiation Protocol Service 537 Examples", draft-ietf-sipping-service-examples-15 (work in 538 progress), July 2008. 540 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 541 Initiated Dialog Event Package for the Session Initiation 542 Protocol (SIP)", RFC 4235, November 2005. 544 8.2. Informative References 546 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 547 (SIP) Call Control - Conferencing for User Agents", 548 BCP 119, RFC 4579, August 2006. 550 [RFC4244] Barnes, M., "An Extension to the Session Initiation 551 Protocol (SIP) for Request History Information", RFC 4244, 552 November 2005. 554 Author's Address 556 Michael Procter 557 VoIP.co.uk 558 Commerce House 559 Telford Road 560 Bicester, Oxfordshire OX26 4LD 561 UK 563 Email: michael@voip.co.uk 564 URI: http://voip.co.uk 566 Full Copyright Statement 568 Copyright (C) The IETF Trust (2008). 570 This document is subject to the rights, licenses and restrictions 571 contained in BCP 78, and except as set forth therein, the authors 572 retain all their rights. 574 This document and the information contained herein are provided on an 575 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 576 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 577 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 578 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 579 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 580 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 582 Intellectual Property 584 The IETF takes no position regarding the validity or scope of any 585 Intellectual Property Rights or other rights that might be claimed to 586 pertain to the implementation or use of the technology described in 587 this document or the extent to which any license under such rights 588 might or might not be available; nor does it represent that it has 589 made any independent effort to identify any such rights. Information 590 on the procedures with respect to rights in RFC documents can be 591 found in BCP 78 and BCP 79. 593 Copies of IPR disclosures made to the IETF Secretariat and any 594 assurances of licenses to be made available, or the result of an 595 attempt made to obtain a general license or permission for the use of 596 such proprietary rights by implementers or users of this 597 specification can be obtained from the IETF on-line IPR repository at 598 http://www.ietf.org/ipr. 600 The IETF invites any interested party to bring to its attention any 601 copyrights, patents or patent applications, or other proprietary 602 rights that may cover technology that may be required to implement 603 this standard. Please address the information to the IETF at 604 ietf-ipr@ietf.org.