idnits 2.17.1 draft-ietf-sip-cc-transfer-01.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: ---------------------------------------------------------------------------- == 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 18 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 117: '... A REFER method MUST contain exactly ...' RFC 2119 keyword, line 119: '... Refer-To header MAY be encrypted as p...' RFC 2119 keyword, line 147: '... A REFER request MUST contain exactly ...' RFC 2119 keyword, line 149: '...ferred-By header SHOULD be signed to h...' RFC 2119 keyword, line 150: '...es. A signed Referred-By header SHOULD...' (19 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 (April 2001) is 8409 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) -- 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: 5 errors (**), 0 flaws (~~), 2 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 dynamicsoft 3 draft-ietf-sip-cc-transfer-01.txt 4 September 2000 5 Expires April 2001 7 SIP Call Control 8 Transfer 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This document defines a SIP extension within the Call Control 33 Framework to provide Call Transfer capabilities. 35 1 Overview...........................................................3 36 2 Changes from draft-sparks-sip-cc-transfer-01.......................4 37 3 The REFER Method...................................................5 38 3.1 The Refer-To Header............................................5 39 3.2 The Referred-By Header.........................................6 40 3.2.1 A PGP based signature-scheme.................................6 41 3.3 Header Field Support for the REFER Method......................7 42 3.4 Message Body Inclusion.........................................8 43 3.5 Responses to the REFER Method..................................8 44 3.6 Behavior of SIP User Agents....................................8 45 3.7 Behavior of SIP Registrars/Redirect Servers....................9 46 3.8 Behavior of SIP Proxies........................................9 47 3.9 Security Considerations........................................9 48 4 Call Transfer.....................................................10 49 4.1 Actors and Roles..............................................10 50 4.2 Requirements..................................................11 51 4.3 Using REFER to achieve Call Transfer..........................12 52 4.4 Unattended Transfer...........................................12 53 4.4.1 Successful Unattended Transfer..............................13 54 4.4.2 Failed Unattended Transfer..................................14 55 4.5 Unattended Transfer with Consultation Hold....................14 56 4.5.1 Variation 1 : Exposes transfer target.......................15 57 4.5.2 Variation 2 : Protects transfer target......................15 58 4.6 Attended Transfer.............................................16 59 4.7 Transfer with multiple parties................................16 60 5 Editor's Address..................................................18 61 6 Acknowledgments...................................................18 62 7 References........................................................18 63 1 Overview 65 This document defines a SIP [2] extension and details its use to 66 provide Call Transfer capabilities. This is part of a family of Call 67 Control extensions described in the Call Control Framework document 68 [3]. 70 The mechanisms discussed here are most closely related to traditional 71 unattended and consultation hold transfers. Discussion of attended 72 transfer (where all parties are briefly in a conference) is deferred 73 until the conferencing features in this framework are 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 through 77 a new method that does not terminate the original signaling 78 relationship. By disassociating transfers from the processing of BYE, 79 these changes facilitate recovery of failed transfers and clarify 80 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 Changes from draft-sparks-sip-cc-transfer-01 87 . Separated definition of the REFER method and headers from the 88 definition of its use to achieve transfer. 89 . Replaced the syntax of the Referred-By header to align with sip- 90 ietf-sip-guidelines. 91 . Added short forms of Refer-To and Referred-By as recommended by 92 sip-ietf-sip-guidelines. 93 . Allows REFERs outside the scope of an existing call-leg. 95 3 The REFER Method 97 REFER is a SIP method as defined by [2]. The REFER method indicates 98 that the recipient should contact a third party using the contact 99 information provided in the method. A success response indicates that 100 the recipient was able to contact the third party. The REFER method 101 follows the session's current signaling path. In particular, the 102 Request-URI of the REFER method identifies the recipient. 104 Unless stated otherwise, the protocol for emitting and responding to a 105 REFER request are identical to those for a BYE request in [2]. The 106 behavior of SIP entities not implementing the REFER (or any other 107 unknown) method is explicitly defined in [2] and is not discussed 108 further here. 110 3.1 The Refer-To Header 112 Refer-To is a request-header as defined by [2]. It may only appear in 113 a REFER request. 115 Refer-To = ("Refer-To" | "r") ":" URL 117 A REFER method MUST contain exactly one Refer-To header. 119 The Refer-To header MAY be encrypted as part of end-end encryption. 121 The Contact header is an important part of the 122 Route/Record-Route mechanism and is not available 123 for this task. 125 3.2 The Referred-By Header 127 Referred-By is a request-header as defined by [2]. It can appear in 128 any request. It conveys the identity of the original REFERrer to the 129 referred-to party, optionally proving the identity and that the 130 REFERrer actually issued this reference. 132 Referred-By = ("Referred-By" | "b") ":" referrer-url 133 ";" referenced-url 134 [";" ref-signature] 135 referrer-url = SIP-URL 136 referenced-url = "ref" "=" URL 137 ref-signature = signature-scheme *( ";" sig-scheme-params ) 138 signature-scheme = "scheme" "=" token 139 sig-scheme-parms = token "=" ( token | quoted-string ) 141 The referrer-url contains the SIP URL of the party sending the REFER 142 request. The referenced-url contains a copy of the URL placed in the 143 Refer-To: header. The ref-signature contains a signature over the 144 concatenation of referrer-url and referenced-url. An example 145 signature scheme is given in section 3.2.1. 147 A REFER request MUST contain exactly one Referred-By header. 149 The Referred-By header SHOULD be signed to help detection of REFERs 150 from unauthorized third parties. A signed Referred-By header SHOULD 151 include a Date header in the referrer-url to facilitate detection of 152 replay attacks. 154 A UA MAY reject a request containing an unsigned Referred-By header. A 155 UA SHOULD verify the signature on any Referred-By header it receives. 157 The Referred-By header MAY be encrypted as part of end-end encryption. 159 3.2.1 A PGP based signature-scheme 161 One signature-scheme for Referred-By headers uses PGP as follows: 162 signature-scheme = "scheme" "=" "pgp" 163 sig-scheme-parms = pgp-version | signed-by | pgp-signature 165 pgp-version, signed-by and pgp-signature are defined in section 15.1 166 of RFC2543, with the modification that the signature is computed 167 across the concatenation of the referrer-url and the referenced-url. 169 3.3 Header Field Support for the REFER Method 171 This table adds a column to tables 4 and 5 in [2], describing header 172 presence in a REFER method. See [2] for a key for the symbols used. A 173 row for the Refer-To: and Referred-By request-header should be 174 inferred, each mandatory for REFER. Refer-To is not applicable for all 175 other methods. Referred-By is a general Request header. The enc and e- 176 e columns in [2] apply to the REFER method unmodified. 178 Header Where REFER 179 Accept R - 180 Accept-Encoding R - 181 Accept-Language R o 182 Allow R - 183 Allow 405 m 184 Authorization R o 185 Call-ID gc m 186 Contact R o 187 Contact 1xx - 188 Contact 2-6xx o 189 Content-Encoding e - 190 Content-Length e o 191 Content-Type e - 192 CSeq gc m 193 Date g o 194 Encryption g o 195 Expires R o 196 From gc m 197 Hide R o 198 Max-Forwards R o 199 Organization g o 200 Priority R - 201 Proxy-Authenticate 407 o 202 Proxy-Authorization R o 203 Proxy-Require R o 204 Require R o 205 Retry-After R - 206 Retry-After 404,480,486 o 207 Retry-After 503 o 208 Retry-After 600,603 o 209 Response-Key R o 210 Record-Route R o 211 Record-Route 2xx o 212 Route R o 213 Server r o 214 Subject R - 215 Timestamp g o 216 To gc(1) m 217 Unsupported 420 o 218 User-Agent g o 219 Via gc(2) m 220 Warning r o 221 WWW-Authenticate 401 o 223 3.4 Message Body Inclusion 225 A REFER method may contain a body which SHOULD be processed according 226 to its Content-Type. 228 3.5 Responses to the REFER Method 230 An agent responding to a REFER Method MUST return a 400 Bad Request if 231 the request contained zero or more than one Refer-To headers. An agent 232 responding to a REFER Method MUST return a 400 Bad Request if the 233 request contained zero or more than one Referred-By headers. An agent 234 (including proxies generating local responses) MAY return a 100 Trying 235 or any appropriate 400-600 class response as prescribed by [2]. If the 236 recipient's agent decides to contact the resource in the Refer-To 237 header, a 200 OK response MUST be returned if it the contact was 238 successful, otherwise a 503 Service Unavailable MUST be returned. The 239 503 response MAY contain a Retry-After: header indicating when the 240 REFER may be attempted again. 242 3.6 Behavior of SIP User Agents 244 A UA receiving a well-formed REFER request SHOULD request approval 245 from the user to proceed (this request could be interactive or through 246 configuration). Upon receiving approval from the user, the UA MUST 247 contact the resource identified by the URL in the Refer-To: header. 248 Note that if the URL is a SIP URL, it could contain header fields such 249 as Call-Id that will be used to form the resulting request. If the URL 250 is a SIP URL, the Referred-By header in the REFER request should be 251 copied into the request sent to the referred-to resource. In 252 accordance with [2], the UA SHOULD issue a provisional response to the 253 REFER method if it cannot issue a final response within 200ms of its 254 receipt. The appropriate response to issue to the REFER on receipt of 255 a final response from the referred-to resource is discussed in 256 "Responses to the REFER Method". 258 3.7 Behavior of SIP Registrars/Redirect Servers 260 Registrars and Redirect Servers SHOULD return a 603 to a REFER 261 request, unless they are also playing some other SIP role. 263 3.8 Behavior of SIP Proxies 265 SIP Proxies do not require modification to support the REFER method. 266 Specifically, as required by [2], a proxy should process a REFER 267 request the same way it processes an OPTIONS request. 269 3.9 Security Considerations 271 The security requirements of [2] apply to the REFER method. 273 This mechanism relies on providing contact information for the 274 referred-to resource to the party being referred. Care should be taken 275 to provide a suitably restricted URI if the referred to resource 276 should be protected. 278 Care should be taken when implementing the logic that determines 279 whether or not to accept the REFER request. A UA not capable of 280 accessing non-SIP URLs SHOULD NOT accept REFER requests to them. 282 4 Call Transfer 284 4.1 Actors and Roles 286 There are three actors in a given transfer event, each playing one of 287 the following roles: 289 Transferee - the party being transferred to the Transfer 290 Target. 292 Transferor - the party initiating the transfer 294 Transfer Target - the new party being introduced into a call with 295 the Transferee. 297 The following roles are used to describe transfer requirements and 298 scenarios: 300 Originator - wishes to place a call to the Recipient. This actor 301 is the source of the first INVITE in a session, to 302 either a Facilitator or a Screener. 304 Facilitator - receives a call or out-of-band request from the 305 Originator, establishes a call to the Recipient 306 through the Screener, and connects the Originator to 307 the Recipient. 309 Screener - receives a call ultimately intended for the Recipient 310 and transfers the calling party to the Recipient if 311 appropriate. 313 Recipient - the party the Originator is ultimately connected to. 315 4.2 Requirements 317 1. Any party in a SIP session MUST be able to transfer any other 318 party in that session at any point in that session. 320 2. The Transferor and the Transferee MUST NOT be removed from a 321 session as part of a transfer transaction. 323 At first glance, requirement 2 may seem to indicate 324 that the user experience in a transfer must be 325 significantly different from what a current PBX or 326 Centrex user expects. As the call-flows in this 327 document show, this is not the case. A client MAY 328 preserve the current experience. In fact, without 329 this requirement, some forms of the current 330 experience (ringback on unattended transfer failure 331 for instance) will be lost. 333 3. The Transferor MUST know whether or not the transfer was 334 successful (this is significantly different from the requirements 335 of draft-ietf-sip-cc-01). 337 4.3 Using REFER to achieve Call Transfer 339 A REFER can be issued by the Transferor to cause the Transferee to 340 issue an INVITE to the Transfer-Target. Note that a successful REFER 341 transaction does not terminate the session between the Transferor and 342 the Transferee. If those parties wish to terminate their session, they 343 must do so with a subsequent BYE request. The media negotiated between 344 the transferee and the transfer target is not affected by the media 345 that had been negotiated between the transferor and the transferee. In 346 particular, the INVITE issued by the Transferee will have the same SDP 347 body it would have if he Transferee had initiated that INVITE on its 348 own. Further, the disposition of the media streams between the 349 Transferor and the Transferee is not altered by the REFER method. 350 Agents may alter a session's media through additional signaling. For 351 example, they may make use of the SIP hold re-INVITE [2] or the 352 conferencing extensions provided by this framework. 354 4.4 Unattended Transfer 356 Unattended Transfer consists of the Transferor providing the Transfer 357 Target's contact to the Transferee. The Transferee attempts to 358 establish a session using that contact and reports the results of that 359 attempt to the Transferor. The signaling relationship between the 360 Transferor and Transferee is not terminated, so the call is 361 recoverable if the Transfer Target cannot be reached. Note that the 362 Transfer Target's contact information has been exposed to the 363 Transferee. The provided contact can be used to make new calls in the 364 future. 366 The diagrams below show indicate the first line of each message. All 367 messages in a particular diagram share the same Call-ID. In these 368 diagrams, media is managed through reINVITE holds, but using other 369 mechanisms (mixing multiple media streams at the UA or using the 370 conferencing extensions for example) are valid. 372 4.4.1 Successful Unattended Transfer 374 Transferor Transferee Transfer 375 | | Target 376 | INVITE | | 377 |<-------------------| | 378 | 200 OK | | 379 |------------------->| | 380 | ACK | | 381 |<-------------------| | 382 | INVITE (hold) | | 383 |------------------->| | 384 | 200 OK | | 385 |<-------------------| | 386 | ACK | | 387 |------------------->| | 388 | REFER | | 389 |------------------->| | 390 | 100 Trying | | 391 |<-------------------| | 392 | | INVITE | 393 | |------------------->| 394 | | 200 OK | 395 | |<-------------------| 396 | | ACK | 397 | |------------------->| 398 | 200 OK | | 399 |<-------------------| | 400 | BYE | | 401 |------------------->| | 402 | 200 OK | | 403 |<-------------------| | 404 | | BYE | 405 | |<-------------------| 406 | | 200 OK | 407 | |------------------->| 409 4.4.2 Failed Unattended Transfer 411 Transferor Transferee Transfer 412 | | Target 413 | | | 414 | INVITE | | 415 |<-------------------| | 416 | 200 OK | | 417 |------------------->| | 418 | ACK | | 419 |<-------------------| | 420 | INVITE (hold) | | 421 |------------------->| | 422 | 200 OK | | 423 |<-------------------| | 424 | ACK | | 425 |------------------->| | 426 | REFER | | 427 |------------------->| | 428 | 100 Trying | | 429 |<-------------------| | 430 | | INVITE | 431 | |------------------->| 432 | | 486 Busy Here | 433 | |<-------------------| 434 | | ACK | 435 | |------------------->| 436 | 503 Service Unavailable | 437 |<-------------------| | 438 | INVITE (unhold) | | 439 |------------------->| | 440 | 200 OK | | 441 |<-------------------| | 442 | ACK | | 443 |------------------->| | 444 | BYE | | 445 |------------------->| | 446 | 200 OK | | 447 |<-------------------| | 449 4.5 Unattended Transfer with Consultation Hold 451 Transfer with Consultation Hold involves a session between the 452 transferor and the transfer target before the transfer actually takes 453 place. This is implemented with SIP Hold and Unattended Transfer as 454 described above. 456 4.5.1 Variation 1 : Exposes transfer target 458 The transferor places the transferee on hold, establishes a call with 459 the transfer target to alert them to the impending transfer, 460 terminates the connection with the transfer target, then proceeds with 461 unattended transfer as above. This variation can be used to provide an 462 experience similar to that expected by current PBX and Centrex users. 464 To (hopefully) improve clarity, non-REFER transactions have been 465 collapsed into one indicator with the arrow showing the direction of 466 the request. 468 Transferor Transferee Transfer 469 | | Target 470 | | | 471 Call-ID:1 | INVITE/200 OK/ACK | | 472 |<-------------------| | 473 Call-ID:1 | INVITE (hold)/200 OK/ACK | 474 |------------------->| | 475 Call-ID:2 | INVITE/200 OK/ACK | | 476 |---------------------------------------->| 477 Call-ID:2 | BYE/200 OK | | 478 |---------------------------------------->| 479 Call-ID:1 | REFER | | 480 |------------------->| | 481 | 100 Trying | | 482 |<-------------------| | 483 Call-ID:1 | | INVITE/200 OK/ACK | 484 | |------------------->| 485 | 200 OK | | 486 |<-------------------| | 487 Call-ID:1 | BYE/200 OK | | 488 |------------------->| | 489 Call-ID:1 | | BYE/200 OK | 490 | |<-------------------| 492 4.5.2 Variation 2 : Protects transfer target 494 The transferor places the transferee on hold, establishes a call with 495 the transfer target and then reverses their roles, transferring the 496 original transfer target to the original transferee. This has the 497 advantage of hiding information about the original transfer target 498 from the original transferee. On the other hand, the Transferee's 499 experience is different that in current systems. The Transferee is 500 effectively "called back" by the Transfer Target. 502 Transferor Transferee Transfer 503 | | Target 504 | | | 505 Call-ID:1 | INVITE/200 OK/ACK | | 506 |<-------------------| | 507 Call-ID:1 | INVITE (hold)/200 OK/ACK | 508 |------------------->| | 509 Call-ID:2 | INVITE/200 OK/ACK | | 510 |---------------------------------------->| 511 Call-ID:2 | INVITE (hold)/200 OK/ACK | 512 |---------------------------------------->| 513 Call-ID:2 | REFER | | 514 |---------------------------------------->| 515 | 100 Trying | | 516 |<----------------------------------------| 517 Call-ID:2 | | INVITE/200 OK/ACK | 518 | |<-------------------| 519 | 200 OK | | 520 |<----------------------------------------| 521 Call-ID:1 | BYE/200 OK | | 522 |------------------->| | 523 Call-ID:2 | BYE/200 OK | | 524 |---------------------------------------->| 525 Call-ID:2 | | BYE/200 OK | 526 | |------------------->| 528 4.6 Attended Transfer 530 In an attended transfer, the three actors participate in an ad-hoc 531 conference as part of the event. Discussion of the implementation of 532 attended transfer is thus deferred until the conferencing portion of 533 the Call Control framework has been addressed. 535 4.7 Transfer with multiple parties 537 In this example the Originator places call to the Facilitator who 538 reaches the Recipient through the Screener. The Recipient's contact 539 information is exposed to the Facilitator and the Originator. This 540 example is provided for clarification of the semantics of the REFER 541 method only and should not be used as the design of an 542 implementation. 544 Originator Facilitator Screener Recipient 545 Call-ID | | | | 546 1 |INVITE/200 OK/ACK | |"Get Fred for me!" 547 |----------->| | | "Right away!" 548 1 |INVITE (hold)/200 OK/ACK | | 549 |<-----------| | | 550 2 | |INVITE/200 OK/ACK |"I have a call 551 | |----------->| |from Mary for Fred" 552 2 | |INVITE (hold)/200 OK/ACK "Hold please" 553 | |<-----------| | 554 3 | | |INVITE/200 OK/ACK 555 | | |--------->|"You have a call 556 | | | |from Mary" 557 | | | | "Put her through" 558 3 | | |INVITE (hold)/200 OK/ACK 559 | | |--------->| 560 2 | |REFER | | 561 | |<-----------| | 562 | |100 Trying | | 563 | |----------->| | 564 2 | |INVITE/200 OK/ACK | 565 | |---------------------->|"This is Fred" 566 | |200 OK | | "Please hold for 567 | |----------->| | Mary" 568 2 | |BYE/200 OK | | 569 | |<-----------| | 570 3 | | |BYE/200 OK| 571 | | |--------->| 572 2 | |INVITE (hold)/200 OK/ACK 573 | |---------------------->| 574 1 |REFER | | | 575 |<-----------| | | 576 |100 Trying | | | 577 |----------->| | | 578 1 |INVITE/200 OK/ACK | | 579 |----------------------------------->| "Hey Fred" 580 |200 OK | | | "Hello Mary" 581 |----------->| | | 582 1 |BYE/200 OK | | | 583 |<-----------| | | 584 2 | |BYE/200 OK | | 585 | |---------------------->| 586 1 |BYE/200 OK | | | 587 |<-----------------------------------| "See you later" 589 5 Editor's Address 591 Robert Sparks 592 dynamicsoft 593 200 Executive Drive 594 Suite 120 595 West Orange, NJ 07052 596 email: rsparks@dynamicsoft.com 598 6 Acknowledgments 600 This draft is a collaborative product of the SIP working group. The 601 editor thanks the following for their early contributions to this 602 work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, 603 Kevin Summers and Dean Willis. 605 7 References 607 [1] S. Bradner, "The Internet Standards Process -- Revision 3", 608 BCP9, RFC2026, October 1996. 610 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 611 "SIP:Session Initiation Protocol", RFC 2543, March 1999. 613 [3] B. Campbell, "Framework for SIP Call Control Extensions", 614 Internet Draft draft-ietf-sip-cc-framework-00, Internet 615 Engineering Task Force, March 2000. Work in Progress. 617 [4] H. Schulzrinne, J. Rosenberg, "SIP Call Control Services", 618 Internet Draft draft-ietf-sip-cc-01, Internet Engineering Task 619 Force, June 17, 1999 Work in Progress (expired).