idnits 2.17.1 draft-sparks-sip-cc-transfer-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 120: '...in a SIP session MUST be able to trans...' RFC 2119 keyword, line 123: '...d the Transferee MUST NOT be removed f...' RFC 2119 keyword, line 126: '.... The Transferor MUST know whether or ...' RFC 2119 keyword, line 144: '...ot the case. A client MAY preserve the...' RFC 2119 keyword, line 180: '... TRANSFER method MUST contain exactly ...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 2000) is 8809 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) ** Obsolete normative reference: RFC 2543 (ref. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) == Outdated reference: A later version (-02) exists of draft-campbell-sip-cc-framework-00 -- Possible downref: Normative reference to a draft: ref. '3' -- No information found for draft-ietf-sip-cc - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Robert Sparks 2 Internet Draft MCI WorldCom 3 draft-sparks-sip-cc-transfer-00.txt 4 March 2000 6 SIP Call Control : Transfer 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as work in progress. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This document defines a SIP extension within the new Call Control 32 Framework to provide Call Transfer capabilities. 34 Table of Contents: 36 1 Overview ..........................................................3 38 2 Actors and Roles ..................................................4 40 3 Requirements ......................................................5 42 4 The TRANSFER Method ...............................................6 44 4.1 The Transfer-To Header...........................................6 45 4.2 Header Field Support for the TRANSFER Method.....................6 46 4.3 Message Body Inclusion...........................................7 47 4.4 Responses to the TRANSFER Method.................................8 48 4.5 Behavior of SIP User Agents......................................8 49 4.6 Behavior of SIP Registrars/Redirect Servers......................9 50 4.7 Behavior of SIP Proxies..........................................9 51 4.8 Security Considerations..........................................9 52 5 Example Uses ......................................................9 54 5.1 Unattended Transfer..............................................9 55 5.2 Unattended Transfer with Consultation Hold......................12 56 5.3 Attended Transfer...............................................13 57 5.4 Transfer with multiple parties..................................14 58 Author's Addresses...................................................16 60 6 Acknowledgments ..................................................16 62 7 References .......................................................16 63 1 Overview 65 This document defines a SIP [2] extension to provide Call Transfer 66 capabilities. It is part of a family of Call Control extensions 67 described in the Call Control Framework document [3]. 69 The mechanisms discussed here are most closely related to 70 traditional unattended and consultation hold transfers. Discussion 71 of attended transfer (where all parties are briefly in a conference) 72 is deferred until the conferencing features in this framework are 73 addressed. 75 This work has roots in draft-ietf-sip-cc-01 [4] but some basic 76 semantics are different. In particular, transfers are achieved 77 through a new method and does not terminate the original signaling 78 relationship. By disassociating transfers from the processing of 79 BYE, these changes facilitate recovery of failed transfers and 80 clarify state management in the participating entities. 82 Implementers that started with the sip-cc-01 BYE-ALSO technique for 83 blind-transfer should find it straightforward to migrate to the 84 mechanisms set forth here. 86 2 Actors and Roles 88 There are three actors in a given transfer event, each playing one 89 of the following roles: 91 Transferee - the party being transferred to the Transfer 92 Target. 94 Transferor - the party initiating the transfer (and leaving the 95 call). 97 Transfer Target - the new party being introduced into a call with 98 the Transferee. 100 The following roles are used to describe transfer requirements and 101 scenarios: 103 Originator - wishes to place a call to the Recipient. This actor is 104 the source of the first INVITE in a session, to either 105 a Facilitator or a Screener. 107 Facilitator - receives a call or out-of-band request from the 108 Originator, establishes a call to the Recipient 109 through the Screener, and connects the Originator to 110 the Recipient. 112 Screener - receives a call ultimately intended for the Recipient 113 and transfers the calling party to the Recipient if 114 appropriate. 116 Recipient - the party the Originator is ultimately connected to. 118 3 Requirements 120 1. Any party in a SIP session MUST be able to transfer any other 121 party in that session at any point in that session. 123 2. The Transferor and the Transferee MUST NOT be removed from a 124 session as part of a transfer transaction (see comment 1). 126 3. The Transferor MUST know whether or not the transfer was 127 successful (see comment 2). 129 Explicit non-Requirements 131 1. There is no requirement for the Transfer Target to be notified 132 that he is receiving an INVITE as the result of a TRANSFER request 133 (see comment 2). 135 2. Pending results from the SIP security infrastructure taskforce, 136 there is no requirement for the Transfer Target to receive secured 137 assurance of the Transferor's identity through SIP (see comment 2). 139 Comments on Requirements 141 1. At first glance, requirement 2 may seem to indicate that the user 142 experience in a transfer must be significantly different from what a 143 current PBX or Centrex user expects. As the call-flows in this 144 document show, this is not the case. A client MAY preserve the 145 current experience. In fact, without this requirement, some forms of 146 the current experience (ringback on unattended transfer failure for 147 instance) will be lost. 149 2. Those requirements and non-requirements referencing comment 2 are 150 significantly different from those in draft-ietf-sip-cc-01. 152 4 The TRANSFER Method 154 TRANSFER is a SIP method as defined by [2]. The TRANSFER method 155 indicates that the recipient (the transferee) should contact a third 156 party (the transfer target) using the contact information provided 157 in the method. A success response indicates that the transferee was 158 able to establish a session with the transfer target. The TRANSFER 159 method follows the session's current signaling path. In particular, 160 the Request-URI of the TRANSFER method identifies the transferee. 162 Unless stated otherwise, the protocol for emitting and responding to 163 a TRANSFER request are identical to those for a BYE request in [2]. 164 The behavior of SIP entities not implementing the TRANSFER (or any 165 other unknown) method is explicitly defined in [2] and is not 166 discussed further here. 168 A successful TRANSFER transaction does not terminate the session 169 between the transferor and the transferee. If those parties wish to 170 terminate their session, they must do so with a subsequent BYE 171 request. 173 4.1 The Transfer-To Header 175 Transfer-To is a request-header as defined by [2]. It may only 176 appear in a TRANSFER request. It identifies the transfer target. 178 Transfer-To = "Transfer-To" ":" ( name-addr | addr-spec ) 180 A TRANSFER method MUST contain exactly one Transfer-To header. 182 The Transfer-To header MAY be encrypted as part of end-end 183 encryption. 185 The Transfer-To header has no short form. 187 The Contact header is an important part 188 of the Route/Record-Route mechanism and 189 is not available for this task. 191 4.2 Header Field Support for the TRANSFER Method 193 This table adds a column to tables 4 and 5 in [2], describing header 194 presence in a TRANSFER method. See [2] for a key for the symbols 195 used. A row for the Transfer-To: request-header should be inferred, 196 mandatory for TRANSFER, not applicable for all other methods. The 197 enc and e-e columns in [2] apply to the TRANSFER method unmodified. 199 Header Where TRANSFER 200 Accept R - 201 Accept-Encoding R - 202 Accept-Language R o 203 Allow R - 204 Allow 405 m 205 Authorization R o 206 Call-ID gc m 207 Contact R o 208 Contact 1xx - 209 Contact 2-6xx o 210 Content-Encoding e - 211 Content-Length e o <-SHOULD be present and 212 Content-Type e - have a value of zero 213 CSeq gc m 214 Date g o 215 Encryption g o 216 Expires R o 217 From gc m 218 Hide R o 219 Max-Forwards R o 220 Organization g o 221 Priority R - 222 Proxy-Authenticate 407 o 223 Proxy-Authorization R o 224 Proxy-Require R o 225 Require R o 226 Retry-After R - 227 Retry-After 404,480,486 o 228 Retry-After 503 o 229 Retry-After 600,603 o 230 Response-Key R o 231 Record-Route R o 232 Record-Route 2xx o 233 Route R o 234 Server r o 235 Subject R - 236 Timestamp g o 237 To gc(1) m 238 Unsupported 420 o 239 User-Agent g o 240 Via gc(2) m 241 Warning r o 242 WWW-Authenticate 401 o 244 4.3 Message Body Inclusion 246 A TRANSFER method MUST NOT contain a body. 248 4.4 Extension Negotiation 250 A TRANSFER request MUST contain the header 252 Requires: cc.transfer 254 4.5 Responses to the TRANSFER Method 256 An agent responding to a TRANSFER Method MUST return a 400 Bad 257 Request if the request contained zero or more than one Transfer-To 258 headers. An agent (including proxies generating local responses) MAY 259 return a 100 Trying or any appropriate 400-600 class response as 260 prescribed by [2]. If the transferee's agent decides to attempt the 261 transfer, a 200 OK response MUST be returned by the if it was able 262 to establish a session with the transferor, otherwise a 603 Decline 263 MUST be returned. In particular, the transferee's agent MUST NOT 264 mirror the transfer targets response to the transferee's invite. 266 4.6 Behavior of SIP User Agents 268 UA receiving a well-formed TRANSFER request SHOULD request approval 269 from the user to proceed. In the absence of that request, or upon 270 receiving approval from the user, the UA MUST submit an INVITE to 271 the resource identified by the Transfer-To: header using the Call-ID 272 from the TRANSFER request. The remainder of that INVITE message is 273 formed exactly as if the UA were placing a new call to that 274 resource. In particular, media negotiation between the transferee 275 and the transfer target is not affected by the media that had been 276 negotiated between the transferor and the transferee. In accordance 277 with [2], the UA SHOULD issue a provisional response to the TRANSFER 278 method if it cannot issue a final response within 200ms of its 279 receipt. The appropriate response to issue on receipt of a final 280 response to the INVITE is discussed in "Responses to the TRANSFER 281 Method". 283 The TRANSFER transaction does not terminate the session between the 284 transferor and the transferee. When the UAs for those parties should 285 terminate that session, they must do so explicitly with a BYE 286 request. 288 A TRANSFER request is meaningful only in the context of an existing 289 session. A UA receiving a TRANSFER request for an unknown call leg 290 MUST return a 481 Call Leg/Transaction Does Not Exist and MUST NOT 291 issue an INVITE to resource identified by that request's Transfer-To 292 header as part of the TRANSFER transaction. 294 The disposition of the media streams between the transferor and the 295 transferee is not altered by the TRANSFER method. Agents may alter a 296 session's media through additional signaling. For example, they may 297 make use of the SIP hold re-INVITE [2] or the conferencing 298 extensions provided by this framework. 300 4.7 Behavior of SIP Registrars/Redirect Servers 302 Since TRANSFER has meaning only in the context of an existing 303 session, a Registrar/Redirect Server that is not also playing the 304 role of a User Agent (never issues a 200 OK in response to an 305 INVITE) MUST respond to a TRANSFER request with a 481 Call 306 Leg/Transaction Does Not Exist. 308 4.8 Behavior of SIP Proxies 310 SIP Proxies do not require modification to support the TRANSFER 311 method. Specifically, as required by [2], a proxy should process a 312 TRANSFER request the same way it processes an OPTIONS request. 314 4.9 Security Considerations 316 The security requirements of [2] apply to the TRANSFER method. 318 This draft does not provide a mechanism for the Transfer Target to 319 be alerted that this is a transferred call or to be assured of the 320 identity of the Transferor. 322 This mechanism relies on providing contact information for the 323 transfer target to the transferee. Care should be taken to provide a 324 suitably restricted URI if the transfer target is a protected 325 resource. 327 5 Example Uses 329 5.1 Unattended Transfer 331 Unattended Transfer consists of the Transferor providing the 332 Transfer Target's contact to the Transferee. The Transferee attempts 333 to establish a session using that contact and reports the results of 334 that attempt to the Transferor. The signaling relationship between 335 the Transferor and Transferee is not terminated, so the call is 336 recoverable if the Transfer Target cannot be reached. Note that the 337 Transfer Target's contact information has been exposed to the 338 Transferee. The provided contact can be used to make new calls in 339 the future. 341 The diagrams below show indicate the first line of each message. All 342 messages in a particular diagram share the same Call-ID. In these 343 diagrams, media is managed through reINVITE holds, but using other 344 mechanisms (mixing multiple media streams at the UA or using the 345 conferencing extensions for example) are valid. 347 5.1.1 Successful Unattended Transfer 349 Transferor Transferee Transfer 350 | | Target 351 | INVITE | | 352 |<-------------------| | 353 | 200 OK | | 354 |------------------->| | 355 | ACK | | 356 |<-------------------| | 357 | INVITE (hold) | | 358 |------------------->| | 359 | 200 OK | | 360 |<-------------------| | 361 | ACK | | 362 |------------------->| | 363 | TRANSFER | | 364 |------------------->| | 365 | 100 Trying | | 366 |<-------------------| | 367 | | INVITE | 368 | |------------------->| 369 | | 200 OK | 370 | |<-------------------| 371 | | ACK | 372 | |------------------->| 373 | 200 OK | | 374 |<-------------------| | 375 | BYE | | 376 |------------------->| | 377 | 200 OK | | 378 |<-------------------| | 379 | | BYE | 380 | |<-------------------| 381 | | 200 OK | 382 | |------------------->| 384 5.1.2 Failed Unattended Transfer 386 Transferor Transferee Transfer 387 | | Target 388 | | | 389 | INVITE | | 390 |<-------------------| | 391 | 200 OK | | 392 |------------------->| | 393 | ACK | | 394 |<-------------------| | 395 | INVITE (hold) | | 396 |------------------->| | 397 | 200 OK | | 398 |<-------------------| | 399 | ACK | | 400 |------------------->| | 401 | TRANSFER | | 402 |------------------->| | 403 | 100 Trying | | 404 |<-------------------| | 405 | | INVITE | 406 | |------------------->| 407 | | 486 Busy Here | 408 | |<-------------------| 409 | | ACK | 410 | |------------------->| 411 | 603 Decline | | 412 |<-------------------| | 413 | INVITE (unhold) | | 414 |------------------->| | 415 | 200 OK | | 416 |<-------------------| | 417 | ACK | | 418 |------------------->| | 419 | BYE | | 420 |------------------->| | 421 | 200 OK | | 422 |<-------------------| | 424 5.2 Unattended Transfer with Consultation Hold 426 Transfer with Consultation Hold involves a session between the 427 transferor and the transfer target before the transfer actually 428 takes place. This is implemented with SIP Hold and Unattended 429 Transfer as described above. 431 5.2.1 Variation 1 : Exposes transfer target 433 The transferor places the transferee on hold, establishes a call 434 with the transfer target to alert them to the impending transfer, 435 terminates the connection with the transfer target, then proceeds 436 with unattended transfer as above. This variation can be used to 437 provide an experience similar to that expected by current PBX and 438 Centrex users. 440 To (hopefully) improve clarity, non-TRANSFER transactions have been 441 collapsed into one indicator with the arrow showing the direction of 442 the request. 444 Transferor Transferee Transfer 445 | | Target 446 | | | 447 Call-ID:1 | INVITE/200 OK/ACK | | 448 |<-------------------| | 449 Call-ID:1 | INVITE (hold)/200 OK/ACK | 450 |------------------->| | 451 Call-ID:2 | INVITE/200 OK/ACK | | 452 |---------------------------------------->| 453 Call-ID:2 | BYE/200 OK | | 454 |---------------------------------------->| 455 Call-ID:1 | TRANSFER | | 456 |------------------->| | 457 | 100 Trying | | 458 |<-------------------| | 459 Call-ID:1 | | INVITE/200 OK/ACK | 460 | |------------------->| 461 | 200 OK | | 462 |<-------------------| | 463 Call-ID:1 | BYE/200 OK | | 464 |------------------->| | 465 Call-ID:1 | | BYE/200 OK | 466 | |<-------------------| 468 5.2.2 Variation 2 : Protects transfer target 470 The transferor places the transferee on hold, establishes a call 471 with the transfer target and then reverses their roles, transferring 472 the original transfer target to the original transferee. This has 473 the advantage of hiding information about the original transfer 474 target from the original transferee. On the other hand, the 475 Transferee's experience is different that in current systems. The 476 Transferee is effectively "called back" by the Transfer Target. 478 Transferor Transferee Transfer 479 | | Target 480 | | | 481 Call-ID:1 | INVITE/200 OK/ACK | | 482 |<-------------------| | 483 Call-ID:1 | INVITE (hold)/200 OK/ACK | 484 |------------------->| | 485 Call-ID:2 | INVITE/200 OK/ACK | | 486 |---------------------------------------->| 487 Call-ID:2 | INVITE (hold)/200 OK/ACK | 488 |---------------------------------------->| 489 Call-ID:2 | TRANSFER | | 490 |---------------------------------------->| 491 | 100 Trying | | 492 |<----------------------------------------| 493 Call-ID:2 | | INVITE/200 OK/ACK | 494 | |<-------------------| 495 | 200 OK | | 496 |<----------------------------------------| 497 Call-ID:1 | BYE/200 OK | | 498 |------------------->| | 499 Call-ID:2 | BYE/200 OK | | 500 |---------------------------------------->| 501 Call-ID:2 | | BYE/200 OK | 502 | |------------------->| 504 5.3 Attended Transfer 506 In an attended transfer, the three actors participate in an ad-hoc 507 conference as part of the event. Discussion of the implementation of 508 attended transfer is thus deferred until the conferencing portion of 509 the Call Control framework has been addressed. 511 5.4 Transfer with multiple parties 513 In this example the Originator places call to the Facilitator who 514 reaches the Recipient through the Screener. The Recipient's contact 515 information is exposed to the Facilitator and the Originator. This 516 example is provided for clarification of the semantics of the 517 TRANSFER method only and should not be used as the design of an 518 implementation. 520 Originator Facilitator Screener Recipient 521 Call-ID | | | | 522 1 |INVITE/200 OK/ACK | |"Get Fred for me!" 523 |----------->| | | "Right away!" 524 1 |INVITE (hold)/200 OK/ACK | | 525 |<-----------| | | 526 2 | |INVITE/200 OK/ACK |"I have a call 527 | |----------->| |from Mary for Fred" 528 2 | |INVITE (hold)/200 OK/ACK "Hold please" 529 | |<-----------| | 530 3 | | |INVITE/200 OK/ACK 531 | | |--------->|"You have a call 532 | | | |from Mary" 533 | | | | "Put her through" 534 3 | | |INVITE (hold)/200 OK/ACK 535 | | |--------->| 536 2 | |TRANSFER | | 537 | |<-----------| | 538 | |100 Trying | | 539 | |----------->| | 540 2 | |INVITE/200 OK/ACK | 541 | |---------------------->|"This is Fred" 542 | |200 OK | | "Please hold for 543 | |----------->| | Mary" 544 2 | |BYE/200 OK | | 545 | |<-----------| | 546 3 | | |BYE/200 OK| 547 | | |--------->| 548 2 | |INVITE (hold)/200 OK/ACK 549 | |---------------------->| 550 1 |TRANSFER | | | 551 |<-----------| | | 552 |100 Trying | | | 553 |----------->| | | 554 1 |INVITE/200 OK/ACK | | 555 |----------------------------------->| "Hey Fred" 556 |200 OK | | | "Hello Mary" 557 |----------->| | | 558 1 |BYE/200 OK | | | 559 |<-----------| | | 561 2 | |BYE/200 OK | | 562 | |---------------------->| 563 1 |BYE/200 OK | | | 564 |<-----------------------------------| "See you later" 566 Author's Addresses 568 Robert Sparks 569 MCI WorldCom 570 2400 N Glenville Drive Phone: +1-972-729-5241 571 Richardson, TX 75082 Email: Robert.Sparks@wcom.com 573 6 Acknowledgments 575 The author thanks the following for their contribution to this work: 576 Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, Kevin 577 Summers and Dean Willis. 579 7 References 581 [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 582 9, RFC2026, October 1996. 584 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 585 Session Initiation Protocol", RFC 2543, March 1999. 587 [3] B. Campbell, "Framework for SIP Call Control Extensions", 588 Internet Draft draft-campbell-sip-cc-framework-00, Internet 589 Engineering Task Force, March 2000. Work in Progress. 591 [4] H. Schulzrinne, J. Rosenberg, "SIP Call Control Services", 592 Internet Draft draft-ietf-sip-cc-01, Internet Engineering Task 593 Force, June 17, 1999 Work in Progress (expired).