idnits 2.17.1 draft-ietf-sipping-cc-transfer-02.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 23 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** 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 91: '... this document MUST support REFER[2] and Replaces[3] in addition to...' RFC 2119 keyword, line 127: '...in a SIP session MUST be able to trans...' RFC 2119 keyword, line 129: '...d the Transferee MUST NOT be removed f...' RFC 2119 keyword, line 136: '...ow, this is not the case. A client MAY...' RFC 2119 keyword, line 142: '... The Transferor MUST know whether or ...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 15, 2004) is 7373 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) == Outdated reference: A later version (-05) exists of draft-ietf-sip-replaces-04 == Outdated reference: A later version (-05) exists of draft-ietf-sip-referredby-03 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-00 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-03 == Outdated reference: A later version (-09) exists of draft-ietf-sipping-torture-tests-03 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG R. Sparks 3 Internet-Draft dynamicsoft 4 Expires: August 15, 2004 A. Johnston 5 MCI 6 February 15, 2004 8 Session Initiation Protocol Call Control - Transfer 9 draft-ietf-sipping-cc-transfer-02 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 15, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document describes providing Call Transfer capabilities in the 40 Session Initiation Protocol (SIP). This work is part of the SIP 41 Multiparty Call Control Framework. 43 Table of Contents 45 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Actors and Roles . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 48 4. Using REFER to achieve Call Transfer . . . . . . . . . . . . 4 49 5. Basic Transfer . . . . . . . . . . . . . . . . . . . . . . . 5 50 5.1 Successful Transfer . . . . . . . . . . . . . . . . . . . . 6 51 5.2 Failed Transfer . . . . . . . . . . . . . . . . . . . . . . 9 52 5.2.1 Target Busy . . . . . . . . . . . . . . . . . . . . . . . . 9 53 5.2.2 Transfer Target does not answer . . . . . . . . . . . . . . 10 54 6. Transfer with Consultation Hold . . . . . . . . . . . . . . 11 55 6.1 Exposing transfer target . . . . . . . . . . . . . . . . . . 11 56 6.2 Protecting transfer target . . . . . . . . . . . . . . . . . 13 57 6.3 Attended Transfer . . . . . . . . . . . . . . . . . . . . . 16 58 6.4 Recovery when one party does not support REFER . . . . . . . 19 59 6.5 Attended Transfer when Contact URI is Not Globally 60 Routable . . . . . . . . . . . . . . . . . . . . . . . . . . 20 61 6.6 Aborting a Consultation Hold . . . . . . . . . . . . . . . . 24 62 6.7 Attended Transfer Fallback to Basic Transfer . . . . . . . . 24 63 7. Transfer with Referred-By . . . . . . . . . . . . . . . . . 26 64 8. Transfer with multiple parties . . . . . . . . . . . . . . . 31 65 9. Changes from draft-sipping-cc-transfer-01 . . . . . . . . . 33 66 10. Changes from draft-sipping-cc-transfer-00 . . . . . . . . . 33 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 68 12. Security Considerations . . . . . . . . . . . . . . . . . . 33 69 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 33 70 Normative References . . . . . . . . . . . . . . . . . . . . 34 71 Informative References . . . . . . . . . . . . . . . . . . . 34 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 73 Intellectual Property and Copyright Statements . . . . . . . 36 75 1. Overview 77 This document describes providing Call Transfer capabilities and 78 requirements in SIP [1]. This work is part of the Multiparty Call 79 Control Framework [6]. 81 The mechanisms discussed here are most closely related to traditional 82 basic and consultation hold transfers. This document does not discuss 83 transfer scenarios involving ad-hoc conferences (where all parties 84 involved are briefly in a conference until this transferor drops 85 out). 87 This document details the use of REFER method [2] and Replaces [3] 88 header field to achieve call transfer. 90 A user agent that fully supports the transfer mechanisms described in 91 this document MUST support REFER[2] and Replaces[3] in addition to 92 RFC 3261 [1]. 94 2. Actors and Roles 96 There are three actors in a given transfer event, each playing one of 97 the following roles: 99 Transferee - the party being transferred to the Transfer 100 Target. 102 Transferor - the party initiating the transfer 104 Transfer Target - the new party being introduced into a call with 105 the Transferee. 107 The following roles are used to describe transfer requirements and 108 scenarios: 110 Originator - wishes to place a call to the Recipient. This actor 111 is the source of the first INVITE in a session, to 112 either a Facilitator or a Screener. 114 Facilitator - receives a call or out-of-band request from the 115 Originator, establishes a call to the Recipient 116 through the Screener, and connects the Originator to 117 the Recipient. 119 Screener - receives a call ultimately intended for the Recipient 120 and transfers the calling party to the Recipient if 121 appropriate. 123 Recipient - the party the Originator is ultimately connected to. 125 3. Requirements 127 1. Any party in a SIP session MUST be able to transfer any other 128 party in that session at any point in that session. 129 2. The Transferor and the Transferee MUST NOT be removed from a 130 session as part of a transfer transaction. 132 At first glance, requirement 2 may seem to indicate 133 that the user experience in a transfer must be 134 significantly different from what a current PBX or 135 Centrex user expects. As the call-flows in this 136 document show, this is not the case. A client MAY 137 preserve the current experience. In fact, without 138 this requirement, some forms of the current 139 experience (ringback on transfer failure 140 for instance) will be lost. 142 3. The Transferor MUST know whether or not the transfer was 143 successful (this is significantly different from the requirements 144 of the earlier BYE-Also approach to transfer). 145 4. The Transferee MUST be able to replace an existing dialog with a 146 new dialog. 147 5. The Transferor and Transferee SHOULD indicate their support for 148 the primitives required to achieve transfer. 150 4. Using REFER to achieve Call Transfer 152 A REFER [2] can be issued by the Transferor to cause the Transferee 153 to issue an INVITE to the Transfer-Target. Note that a successful 154 REFER transaction does not terminate the session between the 155 Transferor and the Transferee. If those parties wish to terminate 156 their session, they must do so with a subsequent BYE request. The 157 media negotiated between the transferee and the transfer target is 158 not affected by the media that had been negotiated between the 159 transferor and the transferee. In particular, the INVITE issued by 160 the Transferee will have the same SDP body it would have if he 161 Transferee had initiated that INVITE on its own. Further, the 162 disposition of the media streams between the Transferor and the 163 Transferee is not altered by the REFER method. Agents may alter a 164 session's media through additional signaling. For example, they may 165 make use of the SIP hold re-INVITE [1] or the conferencing extensions 166 provided by this framework. 168 5. Basic Transfer 170 Basic Transfer consists of the Transferor providing the Transfer 171 Target's contact to the Transferee. The Transferee attempts to 172 establish a session using that contact and reports the results of 173 that attempt to the Transferor. The signaling relationship between 174 the Transferor and Transferee is not terminated, so the call is 175 recoverable if the Transfer Target cannot be reached. Note that the 176 Transfer Target's contact information has been exposed to the 177 Transferee. The provided contact can be used to make new calls in the 178 future. 180 The participants in a basic transfer should indicate support for the 181 REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to 182 INVITE, and OPTIONS. 184 The diagrams below show indicate the first line of each message. The 185 first column of the figure shows the Call-ID used in that particular 186 message. In these diagrams, media is managed through re-INVITE holds, 187 but other mechanisms (mixing multiple media streams at the UA or 188 using the conferencing extensions for example) are valid. Selected 189 message details are shown labeled as message F1, F2, etc. 191 Each of the flows below shows the dialog between the Transferor and 192 the Transferee remaining connected (on hold) during the REFER 193 process. While this provides the greatest flexibility for recovery 194 from failure, it is not necessary. If the Transferor's agent does not 195 wish to participate in the remainder of the REFER process and has no 196 intention of assisting with recovery from transfer failure, it could 197 emit a BYE to the Transferee as soon as the REFER transaction 198 completes. This flow is sometimes known as "unattended transfer". 200 5.1 Successful Transfer 202 Transferor Transferee Transfer 203 | | Target 204 | INVITE | | 205 Call-ID:1 |<-------------------| | 206 | 200 OK | | 207 Call-ID:1 |------------------->| | 208 | ACK | | 209 Call-ID:1 |<-------------------| | 210 | INVITE (hold) | | 211 Call-ID:1 |------------------->| | 212 | 200 OK | | 213 Call-ID:1 |<-------------------| | 214 | ACK | | 215 Call-ID:1 |------------------->| | 216 | REFER F1 | | 217 Call-ID:1 |------------------->| | 218 | 202 Accepted | | 219 Call-ID:1 |<-------------------| | 220 | NOTIFY (100 Trying) F2 | 221 Call-ID:1 |<-------------------| | 222 | 200 OK | | 223 Call-ID:1 |------------------->| | 224 | | INVITE F3 | 225 Call-ID:2 | |------------------->| 226 | | 200 OK | 227 Call-ID:2 | |<-------------------| 228 | | ACK | 229 Call-ID:2 | |------------------->| 230 | NOTIFY (200 OK) F4| | 231 Call-ID:1 |<-------------------| | 232 | 200 OK | | 233 Call-ID:1 |------------------->| | 234 | BYE | | 235 Call-ID:1 |------------------->| | 236 | 200 OK | | 237 Call-ID:1 |<-------------------| | 238 | | BYE | 239 Call-ID:2 | |<-------------------| 240 | | 200 OK | 241 Call-ID:2 | |------------------->| 243 Figure 1. Basic Transfer Call Flow. 245 F1 REFER Transferor -> Transferee 246 REFER sip:transferee@192.0.2.4 SIP/2.0 247 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKna9 248 Max-Forwards: 70 249 To: ;tag=a6c85cf 250 From: ;tag=1928301774 251 Call-ID: a84b4c76e66710 252 CSeq: 314159 REFER 253 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 254 Supported: replaces 255 Refer-To: 256 Contact: 257 Content-Length: 0 259 F2 NOTIFY Transferee -> Transferor 261 NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 262 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 263 Max-Forwards: 70 264 To: ;tag=1928301774 265 From: ;tag=a6c85cf 266 Call-ID: a84b4c76e66710 267 CSeq: 73 NOTIFY 268 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 269 Supported: replaces 270 Event: refer 271 Subscription-State: active;expires=60 272 Content-Type: message/sipfrag 273 Content-Length: ... 275 SIP/2.0 100 Trying 277 F3 INVITE Transferee -> Transfer Target 279 INVITE sip:transfertarget@chicago.example.com SIP/2.0 280 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas41234 281 Max-Forwards: 70 282 To: 283 From: ;tag=j3kso3iqhq 284 Call-ID: 90422f3sd23m4g56832034 285 CSeq: 521 REFER 286 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 287 Supported: replaces 288 Contact: 289 Content-Type: application/sdp 290 Content-Length: ... 292 F4 NOTIFY Transferee -> Transferor 294 NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 295 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 296 Max-Forwards: 70 297 To: ;tag=1928301774 298 From: ;tag=a6c85cf 299 Call-ID: a84b4c76e66710 300 CSeq: 74 NOTIFY 301 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 302 Supported: replaces 303 Event: refer 304 Subscription-State: terminated;reason=noresource 305 Content-Type: message/sipfrag 306 Content-Length: ... 308 SIP/2.0 200 OK 310 5.2 Failed Transfer 312 This section shows examples of failed transfer attempts. After the 313 transfer failure occurs, the Transferor takes the Transferee off hold 314 and resumes the session. 316 5.2.1 Target Busy 318 Transferor Transferee Transfer 319 | | Target 320 | | | 321 | INVITE | | 322 Call-ID:1 |<-------------------| | 323 | 200 OK | | 324 Call-ID:1 |------------------->| | 325 | ACK | | 326 Call-ID:1 |<-------------------| | 327 | INVITE (hold) | | 328 Call-ID:1 |------------------->| | 329 | 200 OK | | 330 Call-ID:1 |<-------------------| | 331 | ACK | | 332 Call-ID:1 |------------------->| | 333 | REFER | | 334 Call-ID:1 |------------------->| | 335 | 202 Accepted | | 336 Call-ID:1 |<-------------------| | 337 | NOTIFY (100 Trying)| | 338 Call-ID:1 |<-------------------| | 339 | 200 OK | | 340 Call-ID:1 |------------------->| | 341 | | INVITE | 342 Call-ID:2 | |------------------->| 343 | | 486 Busy Here | 344 Call-ID:2 | |<-------------------| 345 | | ACK | 346 Call-ID:2 | |------------------->| 347 | NOTIFY (503 Service Unavailable) | 348 | or NOTIFY (486 Busy Here) | 349 Call-ID:1 |<-------------------| | 350 | 200 OK | | 351 Call-ID:1 |------------------->| | 352 | INVITE (unhold) | | 353 Call-ID:1 |------------------->| | 354 | 200 OK | | 355 Call-ID:1 |<-------------------| | 356 | ACK | | 358 Call-ID:1 |------------------->| | 359 | BYE | | 360 Call-ID:1 |------------------->| | 361 | 200 OK | | 362 Call-ID:1 |<-------------------| | 364 Figure 2. Failed Transfer - Target Busy 366 5.2.2 Transfer Target does not answer 368 Transferor Transferee Transfer 369 | | Target 370 | INVITE | | 371 Call-ID:1 |<-------------------| | 372 | 200 OK | | 373 Call-ID:1 |------------------->| | 374 | ACK | | 375 Call-ID:1 |<-------------------| | 376 | INVITE (hold) | | 377 Call-ID:1 |------------------->| | 378 | 200 OK | | 379 Call-ID:1 |<-------------------| | 380 | ACK | | 381 Call-ID:1 |------------------->| | 382 | REFER | | 383 Call-ID:1 |------------------->| | 384 | 202 Accepted | | 385 Call-ID:1 |<-------------------| | 386 | NOTIFY (100 Trying)| | 387 Call-ID:1 |<-------------------| | 388 | 200 OK | | 389 Call-ID:1 |------------------->| | 390 | | INVITE | 391 Call-ID:2 | |------------------->| 392 | | 180 Ringing | 393 Call-ID:2 | |<-------------------| 394 | | (Transferee gets tired of waiting) 395 | | CANCEL | 396 Call-ID:2 | |------------------->| 397 | | 200 OK (CANCEL) | 398 Call-ID:2 | |<-------------------| 399 | | 487 Request Cancelled (INVITE) 400 Call-ID:2 | |<-------------------| 401 | | ACK | 402 Call-ID:2 | |------------------->| 403 | NOTIFY (487 Request Cancelled) | 404 Call-ID:1 |<-------------------| | 405 | 200 OK | | 406 Call-ID:1 |------------------->| | 407 | INVITE (unhold) | | 408 Call-ID:1 |------------------->| | 409 | 200 OK | | 410 Call-ID:1 |<-------------------| | 411 | ACK | | 412 Call-ID:1 |------------------->| | 413 | BYE | | 414 Call-ID:1 |------------------->| | 415 | 200 OK | | 416 Call-ID:1 |<-------------------| | 418 Figure 3. Failed Transfer - Target Does Not Answer. 420 6. Transfer with Consultation Hold 422 Transfer with Consultation Hold involves a session between the 423 transferor and the transfer target before the transfer actually takes 424 place. This is implemented with SIP Hold and Transfer as described 425 above. 427 6.1 Exposing transfer target 429 The transferor places the transferee on hold, establishes a call with 430 the transfer target to alert them to the impending transfer, 431 terminates the connection with the transfer target, then proceeds 432 with transfer as above. This variation can be used to provide an 433 experience similar to that expected by current PBX and Centrex users. 435 To (hopefully) improve clarity, non-REFER transactions have been 436 collapsed into one indicator with the arrow showing the direction of 437 the request. 439 Transferor Transferee Transfer 440 | | Target 441 | | | 442 Call-ID:1 | INVITE/200 OK/ACK | | 443 |<-------------------| | 444 Call-ID:1 | INVITE (hold)/200 OK/ACK | 445 |------------------->| | 446 Call-ID:2 | INVITE/200 OK/ACK | | 447 |---------------------------------------->| 448 Call-ID:2 | BYE/200 OK | | 449 |---------------------------------------->| 450 Call-ID:1 | REFER | | 451 |------------------->| | 452 Call-ID:1 | 202 Accepted | | 453 |<-------------------| | 454 Call-ID:1 | NOTIFY (100 Trying)| | 455 |<-------------------| | 456 Call-ID:1 | 200 OK | | 457 |------------------->| | 458 Call-ID:3 | | INVITE/200 OK/ACK | 459 | |------------------->| 460 Call-ID:1 | NOTIFY (200 OK) | | 461 |<-------------------| | 462 Call-ID:1 | 200 OK | | 463 |------------------->| | 464 Call-ID:1 | BYE/200 OK | | 465 |------------------->| | 466 Call-ID:3 | | BYE/200 OK | 467 | |<-------------------| 469 Figure 4. Transfer with Consultation Hold - Exposing Transfer 470 Target. 472 6.2 Protecting transfer target 474 The transferor places the transferee on hold, establishes a call with 475 the transfer target and then reverses their roles, transferring the 476 original transfer target to the original transferee. This has the 477 advantage of hiding information about the original transfer target 478 from the original transferee. On the other hand, the Transferee's 479 experience is different that in current systems. The Transferee is 480 effectively "called back" by the Transfer Target. 482 One of the problems with this simplest implementation of a target 483 protecting transfer is that the transferee is receiving a new call 484 from the transfer-target. Unless the transferee's agent has a 485 reliable way to associate this new call with the call it already has 486 with the transferor, it will have to alert the new call on another 487 appearance. If this, or some other call-waiting-like UI were not 488 available, the transferee might be stuck returning a Busy-Here to the 489 transfer target, effectively preventing the transfer. There are many 490 ways that that correlation could be provided. The dialog parameters 491 could be provided directly as header parameters in the Refer-To: URI 492 for example. The Replaces mechanism [3] uses this approach and solves 493 this problem nicely. 495 For the flow below, dialog1 means dialog identifier 1, and consists 496 of the parameters of the Replaces header for dialog 1. In [3] this is 497 the Call-ID, To-tag and From-tag. 499 Note that the transferee's agent emits a BYE to the transferor's 500 agent as an immediate consequence of processing the Replaces header. 502 The Transferor knows that both the Transferee and the Transfer Target 503 support the Replaces header from the Supported: replaces header 504 contained in the 200 OK responses from both. 506 Transferor Transferee Transfer 507 | | Target 508 | | | 509 dialog1 | INVITE/200 OK/ACK F1 F2 | 510 |<-------------------| | 511 dialog1 | INVITE (hold)/200 OK/ACK | 512 |------------------->| | 513 dialog2 | INVITE/200 OK/ACK | | 514 |---------------------------------------->| 515 dialog2 | INVITE (hold)/200 OK/ACK | 516 |---------------------------------------->| 517 dialog2 | REFER (Refer-To:sip:Transferee?Replaces=dialog1) F3 518 |---------------------------------------->| 519 dialog2 | 202 Accepted | | 520 |<----------------------------------------| 521 dialog2 | NOTIFY (100 Trying)| | 522 |<----------------------------------------| 523 dialog2 | | 200 OK | 524 |---------------------------------------->| 525 dialog3 | INVITE (Replaces:dialog1)/200 OK/ACK F4 526 | |<-------------------| 527 dialog1 | BYE/200 OK | | 528 |<-------------------| | 529 dialog2 | NOTIFY (200 OK) | | 530 |<----------------------------------------| 531 dialog2 | | 200 OK | 532 |---------------------------------------->| 533 dialog2 | BYE/200 OK | | 534 |---------------------------------------->| 535 | | (transferee and target converse) 536 dialog3 | | BYE/200 OK | 537 | |------------------->| 539 Figure 5. Transfer Protecting Transfer Target. 541 F1 INVITE Transferee -> Transferor 543 INVITE sip:transferor@atlanta.example.com SIP/2.0 544 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 545 Max-Forwards: 70 546 To: 547 From: ;tag=7553452 548 Call-ID: 090459243588173445 549 CSeq: 29887 INVITE 550 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 551 Supported: replaces, gruu 552 Contact: 553 Content-Type: application/sdp 554 Content-Length: ... 556 F2 200 OK Transferor -> Transferee 558 SIP/2.0 200 OK 559 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 560 To: ;tag=31431 561 From: ;tag=7553452 562 Call-ID: 090459243588173445 563 CSeq: 29887 INVITE 564 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 565 Supported: replaces 566 Contact: 567 Content-Type: application/sdp 568 Content-Length: ... 570 F3 REFER Transferor -> Transfer Target 572 REFER sip:transfertarget@client.chicago.com SIP/2.0 573 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 574 Max-Forwards: 70 575 To: ;tag=a6c85cf 576 From: ;tag=1928301774 577 Call-ID: a84b4c76e66710 578 CSeq: 314159 REFER 579 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 580 Supported: replaces 581 Refer-To: 583 Contact: 584 Content-Length: 0 586 F4 INVITE Transfer Target -> Transferee 588 INVITE sip:transferee@192.0.2.4 SIP/2.0 589 Via: SIP/2.0/UDP client.chicago.com;branch=z9hG4bKnaslu84 590 Max-Forwards: 70 591 To: 592 From: ;tag=341234 593 Call-ID: kmzwdle3dl3d08 594 CSeq: 41 INVITE 595 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 596 Supported: replaces 597 Contact: 598 Replaces: 090459243588173445;to-tag=31431;from-tag=7553452 599 Content-Type: application/sdp 600 Content-Length: ... 602 6.3 Attended Transfer 604 The transferor places the transferee on hold, establishes a call with 605 the transfer target to alert them to the impending transfer, places 606 the target on hold, then proceeds with transfer using an escaped 607 Replaces header field in the Refer-To header. This is another common 608 service expected by current PBX and Centrex users. 610 In order to be sure that triggered INVITE (message F4) reaches the 611 Transfer Target, the Contact URI is used as the Refer-To URI. The 612 presence of a Supported: gruu header field in the 200 OK (message F3) 613 from the Transfer Target to the Transferee guarantees that this 614 Contact URI is a GRUU [5] (Globally Routable User Agent URI) and will 615 be routable outside this dialog. Without an indication that the 616 Contact URI is a GRUU, the Transferee should still use the Contact 617 URI as the Refer-To URI. However, the Transferee needs to be 618 prepared in the event that the transfer fails, as described in 619 Section 6.5. 621 Transferor Transferee Transfer 622 | | Target 623 | | | 624 dialog1 | INVITE/200 OK/ACK | | 625 |<-------------------| | 626 dialog1 | INVITE (hold)/200 OK/ACK | 627 |------------------->| | 628 dialog2 | INVITE/200 OK/ACK F1 F2 | 629 |---------------------------------------->| 630 dialog2 | INVITE (hold)/200 OK/ACK | 631 |---------------------------------------->| 632 dialog1 | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) F3 633 |------------------->| | 634 dialog1 | 202 Accepted | | 635 |<-------------------| | 636 dialog1 | NOTIFY (100 Trying)| | 637 |<-------------------| | 638 dialog1 | 200 OK | | 639 |------------------->| | 640 dialog3 | INVITE (Replaces:dialog2)/200 OK/ACK F4 641 | |------------------->| 642 dialog2 | BYE/200 OK | | 643 |<----------------------------------------| 644 dialog1 | NOTIFY (200 OK) | | 645 |<-------------------| | 646 dialog1 | 200 OK | | 647 |------------------->| | 648 dialog1 | BYE/200 OK | | 649 |------------------->| | 650 dialog3 | | BYE/200 OK | 651 | |<-------------------| 653 Figure 6. Attended Transfer Call Flow. 655 F1 INVITE Transferor -> Transfer Target 657 INVITE sip:transfertarget@chicago.example.com SIP/2.0 658 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432 659 Max-Forwards: 70 660 To: 661 From: ;tag=763231 662 Call-ID: 090459243588173445 663 CSeq: 29887 INVITE 664 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 665 Supported: replaces 666 Contact: 667 Content-Type: application/sdp 668 Content-Length: ... 670 F2 200 OK Transfer Target -> Transferee 672 SIP/2.0 200 OK 673 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432 674 ;received=192.0.2.1 675 To: ;tag=9m2n3wq 676 From: ;tag=763231 677 Call-ID: 090459243588173445 678 CSeq: 29887 INVITE 679 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 680 Supported: replaces, gruu 681 Contact: 682 Content-Type: application/sdp 683 Content-Length: ... 685 F3 REFER Transferor -> Transferee 687 REFER sip:transferee@192.0.2.4 SIP/2.0 688 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 689 Max-Forwards: 70 690 To: ;tag=a6c85cf 691 From: ;tag=1928301774 692 Call-ID: a84b4c76e66710 693 CSeq: 314159 REFER 694 Refer-To: 696 Contact: 697 Content-Length: 0 699 F4 INVITE Transferee -> Transfer Target 701 INVITE sip:transfertarget@client.chicago.example.com SIP/2.0 702 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnaslu82 703 Max-Forwards: 70 704 To: 705 From: ;tag=954 706 Call-ID: kmzwdle3dl3d08 707 CSeq: 41 INVITE 708 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 709 Supported: replaces 710 Contact: 711 Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 712 Content-Type: application/sdp 713 Content-Length: ... 715 6.4 Recovery when one party does not support REFER 717 If protecting or exposing the transfer target is not a concern, it is 718 possible to complete a transfer with consultation hold when only the 719 transferor and one other party support REFER. Note that a 405 Method 720 Not Allowed might be returned instead of the 501 Not Implemented 721 response. 723 Transferor Transferee Transfer 724 | | Target 725 | | | 726 dialog1 | INVITE/200 OK/ACK | | 727 |<-------------------| | 728 dialog1 | INVITE (hold)/200 OK/ACK | 729 |------------------->| | 730 dialog2 | INVITE/200 OK/ACK | | 731 |---------------------------------------->| 732 dialog2 | INVITE (hold)/200 OK/ACK | 733 |---------------------------------------->| 734 dialog1 | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) 735 |------------------->| | 736 dialog1 | 501 Not Implemented | 737 |<-------------------| | 738 dialog2 | REFER (Refer-To:sip:Transferee?Replaces=dialog1) 739 |---------------------------------------->| 740 dialog2 | 202 Accepted | | 741 |<----------------------------------------| 742 dialog2 | NOTIFY (100 Trying)| | 743 |<----------------------------------------| 744 dialog2 | | 200 OK | 745 |---------------------------------------->| 746 dialog3 | | INVITE (Replaces:dialog1)/200 OK/ACK 747 | |<-------------------| 748 dialog2 | NOTIFY (200 OK) | | 749 |<----------------------------------------| 750 | | 200 OK | 751 |---------------------------------------->| 752 dialog1 | BYE/200 OK | | 753 |<-------------------| | 754 dialog2 | BYE/200 OK | | 755 |---------------------------------------->| 756 dialog3 | | BYE/200 OK | 757 | |------------------->| 759 Figure 7. Recovery when one party does not support REFER. 761 6.5 Attended Transfer when Contact URI is Not Globally Routable 763 It is a requirement of RFC3261 that a Contact URI be globally 764 routable even outside the dialog. However, due to RFC2543 User 765 Agents and some architectures (NAT/Firewall traversal, screening 766 proxies, ALGs, etc.) this will not always be the case. As a result, 767 the method of Attended transfer shown in Figures 6 and 7 may fail 768 since they use the Contact URI in the Refer-To header field. 769 Participants in transfer scenarios should indicate if their Contact 770 URIs are GRUUs using the Supported: gruu header field. 772 Figure 8 shows such a scenario involving a Screening Proxy in which 773 the transfer initially fails but succeeds on a second try. The 774 failure (403 Forbidden, 404 Not Found, or a timeout after no 775 response) response is communicated back to the Transferor. Since 776 this may be caused by routing problems with the Contact URI, the 777 Transferor retries the REFER this time with Refer-To containing the 778 Address of Record (AOR) of the Target (the same URI the Transferor 779 used to reach the Target). However, the use of the AOR URI may 780 result in routing features being activated such as forking or 781 sequential searching which may result in the triggered INVITE 782 reaching the wrong UA. To prevent an incorrect UA answering the 783 INVITE, a Require: replaces header field is included in the Refer-To. 784 This ensures that only the UA which matches the Replaces dialog will 785 answer the INVITE, since any incorrect UA which supports Replaces 786 will reply with a 481 and a UA which does not support Replaces will 787 reply with a 420. 789 Note that there is still no guarantee that the correct endpoint will 790 be reached, and the result of this second REFER may also be a 791 failure. In that case, the Transferor could fall back to unattended 792 transfer or give up on the transfer entirely. Since two REFERs are 793 sent within the dialog creating two distinct subscriptions, the 794 Transferee uses the 'id' parameter in the Event header field to 795 distinguish notifications for the two subscriptions. 797 Transferor Transferee Screening Transfer 798 | | Proxy Target 799 | | | | 800 dialog1 | INVITE/200 OK/ACK| | | 801 |<-----------------| | | 802 dialog1 | INVITE (hold)/200 OK/ACK | | 803 |----------------->| | | 804 dialog2 | INVITE/200 OK/ACK F1 F2 | | 805 |--------------------------------|------------>| 806 dialog2 | INVITE (hold)/200 OK/ACK | 807 |--------------------------------|------------>| 808 dialog1 | REFER (Refer-To:sip:TargetContact?Replaces=dialog2) F3 809 |----------------->| | | 810 dialog1 | 202 Accepted | | | 811 |<-----------------| | | 812 dialog1 | NOTIFY (100 Trying) | | 813 |<-----------------| | | 814 dialog1 | 200 OK | | | 815 |----------------->| | | 816 dialog3 | | INVITE (Replaces:dialog2)/403/ACK 817 | |------------>| | 818 dialog1 | NOTIFY (403 Forbidden) F4 | | 819 |<-----------------| | | 820 dialog1 | 200 OK | | | 821 |----------------->| | | 822 dialog1 |REFER(Refer-To:sip:TargetAOR?Replaces=dialog2&Require=replaces) F5 823 |----------------->| | | 824 dialog1 | 202 Accepted | | | 825 |<-----------------| | | 826 dialog1 | NOTIFY (100 Trying) | | 827 |<-----------------| | | 828 dialog1 | 200 OK | | | 829 |----------------->| | | 830 dialog4 | INVITE (Replaces:dialog2, Require:replaces)/200 OK/ACK F6 831 | |------------>|------------>| 832 dialog2 | BYE/200 OK | | | 833 |<-------------------------------|<------------| 834 dialog1 | NOTIFY (200 OK) F7 | | 835 |<-----------------| | | 836 dialog1 | 200 OK | | | 837 |----------------->| | | 838 dialog1 | BYE/200 OK | | | 839 |----------------->| | | 840 dialog3 | | | BYE/200 OK | 841 | |<------------|-------------| 843 Figure 8. Attended Transfer Call Flow with non-routable Contact URI 845 F1 INVITE Transferor -> Transfer Target 847 INVITE sip:transfertarget@chicago.example.com SIP/2.0 848 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bK76 849 Max-Forwards: 70 850 To: 851 From: ;tag=763231 852 Call-ID: 090459243588173445 853 CSeq: 29887 INVITE 854 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 855 Supported: replaces 856 Contact: 857 Content-Type: application/sdp 858 Content-Length: ... 860 F2 200 OK Transfer Target -> Transferee 862 SIP/2.0 200 OK 863 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432 864 ;received=192.0.2.1 865 To: ;tag=9m2n3wq 866 From: ;tag=763231 867 Call-ID: 090459243588173445 868 CSeq: 29887 INVITE 869 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 870 Supported: replaces 871 Contact: 872 Content-Type: application/sdp 873 Content-Length: ... 875 F3 REFER Transferor -> Transferee 877 REFER sip:transferee@192.0.2.4 SIP/2.0 878 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 879 Max-Forwards: 70 880 To: ;tag=a6c85cf 881 From: ;tag=1928301774 882 Call-ID: a84b4c76e66710 883 CSeq: 314159 REFER 884 Refer-To: 886 Contact: 887 Content-Length: 0 889 F4 NOTIFY Transferee -> Transferor 891 NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 892 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 893 Max-Forwards: 70 894 To: ;tag=1928301774 895 From: ;tag=a6c85cf 896 Call-ID: a84b4c76e66710 897 CSeq: 74 NOTIFY 898 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 899 Supported: replaces 900 Event: refer;id=3112 901 Subscription-State: terminated;reason=noresource 902 Content-Type: message/sipfrag 903 Content-Length: ... 905 SIP/2.0 403 Forbidden 907 F5 REFER Transferor -> Transferee 909 REFER sip:transferee@192.0.2.4 SIP/2.0 910 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 911 Max-Forwards: 70 912 To: ;tag=a6c85cf 913 From: ;tag=1928301774 914 Call-ID: a84b4c76e66710 915 CSeq: 314160 REFER 916 Refer-To: 918 Contact: 919 Content-Length: 0 921 F6 INVITE Transferee -> Transfer Target 923 INVITE sip:transfertarget@chicago.example.com SIP/2.0 924 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnaslu82 925 Max-Forwards: 70 926 To: 927 From: ;tag=954 928 Call-ID: 20482817324945934422930 929 CSeq: 42 INVITE 930 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 931 Supported: replaces 932 Contact: 933 Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 934 Require: replaces 935 Content-Type: application/sdp 936 Content-Length: ... 938 F7 NOTIFY Transferee -> Transferor 940 NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 941 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 942 Max-Forwards: 70 943 To: ;tag=1928301774 944 From: ;tag=a6c85cf 945 Call-ID: a84b4c76e66710 946 CSeq: 76 NOTIFY 947 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 948 Supported: replaces 949 Event: refer;id=98873867 950 Subscription-State: terminated;reason=noresource 951 Content-Type: message/sipfrag 952 Content-Length: ... 954 SIP/2.0 200 OK 956 To prevent this scenario from happening, the Transfer Target should 957 obtain a GRUU and use it in the Contact header field, which will 958 result in the call flow of Figure 6. 960 6.6 Aborting a Consultation Hold 962 In any of the consultation hold flows above, the Transferor may 963 decide to terminate its attempt to contact the Transfer target before 964 that session is established. Most frequently, that will be the end of 965 the scenario, but in some circumstances, the transferor may wish to 966 proceed with the transfer action. For example, he may wish to 967 complete the transfer knowing that the transferee will end up 968 eventually talking to the transfer-target's voice-mail service. Some 969 PBX systems support this feature, sometimes called "semi-attended 970 transfer", that is effectively a hybrid between a fully attended 971 transfer and an unattended transfer. A true implementation of this 972 feature requires a short ad-hoc conference between all parties, which 973 ensures that no media clipping occurs. This flow is outside the 974 scope of this document. 976 For flows that expose the transfer target, this simply becomes a 977 basic transfer. 979 This scenario is far more complicated for flows that protect the 980 transfer target. Since no session is established between the 981 transferor and the transfer target, the transfer target's agent would 982 have to honor out-of-session REFERs, and somehow indicate what's 983 happening via its user interface (this scenario is most likely to 984 occur when the transfer-target is away from his agent). 986 6.7 Attended Transfer Fallback to Basic Transfer 988 In this flow, an attempted attended transfer fails so the transferor 989 falls back to basic transfer. The use of OPTIONS is shown when the 990 Transferee and Transfer Target do not explicitly indicate support for 991 the REFER method and Replaces header fields in Allow and Supported 992 header fields. In dialog1, the Transferor determines using OPTIONS 993 that the Transferee does support REFER and Replaces. As a result, 994 the Transferor begins the attended transfer by placing the Transferee 995 on hold and calling the Transfer Target. Using an OPTIONS in 996 dialog2, the Transferor determines that the Target does not support 997 either REFER or Replaces, making attended transfer impossible. (Note 998 that the same information could have been determined by including a 999 Require: replaces in the initial INVITE in dialog2, which would have 1000 failed with a 421 response.) The Transferor then ends dialog2 by 1001 sending a BYE then sends a REFER to the Transferee using the AOR URI 1002 of the Transfer Target. 1004 Transferor Transferee Transfer 1005 | | Target 1006 | | | 1007 dialog1 | INVITE/200 OK/ACK | | 1008 |<-------------------| | 1009 dialog1 | OPTIONS/200 OK | | 1010 |------------------->| | 1011 dialog1 | INVITE (hold)/200 OK/ACK | 1012 |------------------->| | 1013 dialog2 | INVITE/200 OK/ACK | | 1014 |---------------------------------------->| 1015 dialog2 | OPTIONS/200 OK | | 1016 |---------------------------------------->| 1017 dialog2 | BYE/200 OK | | 1018 |---------------------------------------->| 1019 dialog1 | REFER (Refer-To:sip:TransferTarget) | 1020 |------------------->| | 1021 dialog1 | 202 Accepted | | 1022 |<-------------------| | 1023 dialog1 | NOTIFY (100 Trying)| | 1024 |<-------------------| | 1025 dialog1 | 200 OK | | 1026 |------------------->| | 1027 dialog3 | | INVITE/200 OK/ACK | 1028 | |------------------->| 1029 dialog1 | NOTIFY (200 OK) | | 1030 |<-------------------| | 1031 dialog1 | 200 OK | | 1032 |------------------->| | 1033 dialog1 | BYE/200 OK | | 1034 |------------------->| | 1035 dialog3 | | BYE/200 OK | 1036 | |<-------------------| 1038 Figure 9. Attended Transfer Fallback to Basic Transfer. 1040 7. Transfer with Referred-By 1042 In the previous examples, the Transfer Target does not have 1043 definitive information about what party initiated the transfer, or, 1044 in some cases, even that transfer is taking place. The Referred-By 1045 mechanism [4] provides a way for the Transferor to provide the 1046 Transferee with a way to let the Transfer Target know what party 1047 initiated the transfer. 1049 The simplest and least secure approach just involves the inclusion of 1050 the Referred-By header field in the REFER which is then copied into 1051 the triggered INVITE. However, a more secure mechanism involving the 1052 Referred-By security token which is generated and signed by the 1053 Transferor and passed in a message body to the Transferee then to the 1054 Transfer Target. 1056 The call flow would be identical to Figure 6. However, the REFER and 1057 triggered INVITE messages for this flow showing the Referred-By 1058 mechanism are shown below. Note that the conventions used in the SIP 1059 Torture Test Messages [7] document are reused, specifically the 1060 <hex> and <allOneLine> tags. 1062 F3 REFER Transferor -> Transferee 1064 REFER sip:transferee@192.0.2.4 SIP/2.0 1065 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bK392039842 1066 Max-Forwards: 70 1067 To: ;tag=a6c85cf 1068 From: ;tag=1928301774 1069 Call-ID: a84b4c76e66710 1070 CSeq: 314160 REFER 1071 1072 Refer-To: 1075 1076 Referred-By: 1077 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1078 Contact: 1079 Content-Type: multipart/mixed; boundary=unique-boundary-1 1080 Content-Length: 3267 1082 --unique-boundary-1 1083 Content-ID: <20398823.2UWQFN309shb3@atlanta.example.com> 1085 Content-Length: 2961 1086 Content-Type: multipart/signed; 1087 protocol="application/pkcs-7-signature"; 1088 micalg=sha1; 1089 boundary="----590F24D439B31E08745DEF0CD9397189" 1091 ------590F24D439B31E08745DEF0CD9397189 1092 Content-Type: message/sipfrag 1094 Date: Thu, 18 Sep 2003 13:07:43 GMT 1095 1096 Refer-To: 1099 1100 Referred-By: 1101 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1103 ------590F24D439B31E08745DEF0CD9397189 1104 Content-Type: application/pkcs-7-signature; name="smime.p7s" 1105 Content-Transfer-Encoding: binary 1106 Content-Disposition: attachment; filename="smime.p7s" 1108 3082088806092A86 1109 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 1110 0B06092A864886F70D010701A082067A30820339308202A2A003020102020800 1111 90008902240001300D06092A864886F70D01010505003070310B300906035504 1112 0613025553311330110603550408130A43616C69666F726E69613111300F0603 1113 550407130853616E4A6F7365310E300C060355040A1305736970697431293027 1114 060355040B135369706974546573744365727469666963617465417574686F72 1115 697479301E170D3033313032313134343332355A170D31333130313831343433 1116 32355A3062310B3009060355040613025553311330110603550408130A43616C 1117 69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355 1118 040A13057369706974311B30190603550403141273656E646572406578616D70 1119 6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902 1120 818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5 1121 56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD 1122 6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081 1123 D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387 1124 4E230203010001A381E93081E6301D0603551D1104163014811273656E646572 1125 406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416 1126 041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481 1127 9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070 1128 310B3009060355040613025553311330110603550408130A43616C69666F726E 1129 69613111300F0603550407130853616E4A6F7365310E300C060355040A130573 1130 6970697431293027060355040B13536970697454657374436572746966696361 1131 7465417574686F72697479820100300D06092A864886F70D0101050500038181 1132 006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2 1133 2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870 1134 102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153 1135 278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7 1136 5E30820339308202A2A00302010202080090008902240001300D06092A864886 1137 F70D01010505003070310B300906035504061302555331133011060355040813 1138 0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30 1139 0C060355040A1305736970697431293027060355040B13536970697454657374 1140 4365727469666963617465417574686F72697479301E170D3033313032313134 1141 343332355A170D3133313031383134343332355A3062310B3009060355040613 1142 025553311330110603550408130A43616C69666F726E69613111300F06035504 1143 07130853616E4A6F7365310E300C060355040A13057369706974311B30190603 1144 550403141273656E646572406578616D706C652E6F726730819F300D06092A86 1145 4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692 1146 2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79 1147 76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5 1148 FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9 1149 79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D 1150 0603551D1104163014811273656E646572406578616D706C652E6F7267300906 1151 03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70 1152 E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580 1153 546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113 1154 30110603550408130A43616C69666F726E69613111300F060355040713085361 1155 6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353 1156 69706974546573744365727469666963617465417574686F7269747982010030 1157 0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978 1158 7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E 1159 C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A 1160 C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972 1161 242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30 1162 70310B3009060355040613025553311330110603550408130A43616C69666F72 1163 6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305 1164 736970697431293027060355040B135369706974546573744365727469666963 1165 617465417574686F7269747902080090008902240001300906052B0E03021A05 1166 00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C 1167 06092A864886F70D010905310F170D3034303132363139313831345A30230609 1168 2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943 1169 95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E 1170 06082A864886F70D030202020080300D06082A864886F70D0302020140300706 1171 052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01 1172 010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C 1173 C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C 1174 822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087 1175 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 1176 79089AAD95767F 1178 ------590F24D439B31E08745DEF0CD9397189-- 1180 --unique_boundary-1 1181 F4 INVITE Transferee -> Transfer Target 1183 INVITE sip:transfertarget@chicago.example.com SIP/2.0 1184 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac 1185 To: 1186 From: ;tag=2909034023 1187 Call-ID: fe9023940-a3465@referee.example 1188 CSeq: 889823409 INVITE 1189 Max-Forwards: 70 1190 Contact: 1191 Referred-By: 1192 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1193 Replaces:090459243588173445;to-tag=9m2n3wq;from- 1194 tag=76323 1195 Require:replaces 1196 Content-Type: multipart/mixed; boundary=my-boundary-9 1197 Content-Length: 3432 1199 --my-boundary-9 1200 Content-Type: application/sdp 1201 Content-Length: 156 1203 v=0 1204 o=referee 2890844526 2890844526 IN IP4 referee.example 1205 s=Session SDP 1206 c=IN IP4 referee.example 1207 t=0 0 1208 m=audio 49172 RTP/AVP 0 1209 a=rtpmap:0 PCMU/8000 1211 --my-boundary-9 1212 Content-Length: 2961 1213 Content-Type: multipart/signed; 1214 protocol="application/pkcs-7-signature"; 1215 micalg=sha1; 1216 boundary="----590F24D439B31E08745DEF0CD9397189" 1218 ------590F24D439B31E08745DEF0CD9397189 1219 Content-Type: message/sipfrag 1221 Date: Thu, 18 Sep 2003 13:07:43 GMT 1222 1223 Refer-To: 1226 1227 Referred-By: 1228 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1230 ------590F24D439B31E08745DEF0CD9397189 1231 Content-Type: application/pkcs-7-signature; name="smime.p7s" 1232 Content-Transfer-Encoding: binary 1233 Content-Disposition: attachment; filename="smime.p7s" 1235 3082088806092A86 1236 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 1237 0B06092A864886F70D010701A082067A30820339308202A2A003020102020800 1238 90008902240001300D06092A864886F70D01010505003070310B300906035504 1239 0613025553311330110603550408130A43616C69666F726E69613111300F0603 1240 550407130853616E4A6F7365310E300C060355040A1305736970697431293027 1241 060355040B135369706974546573744365727469666963617465417574686F72 1242 697479301E170D3033313032313134343332355A170D31333130313831343433 1243 32355A3062310B3009060355040613025553311330110603550408130A43616C 1244 69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355 1245 040A13057369706974311B30190603550403141273656E646572406578616D70 1246 6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902 1247 818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5 1248 56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD 1249 6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081 1250 D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387 1251 4E230203010001A381E93081E6301D0603551D1104163014811273656E646572 1252 406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416 1253 041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481 1254 9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070 1255 310B3009060355040613025553311330110603550408130A43616C69666F726E 1256 69613111300F0603550407130853616E4A6F7365310E300C060355040A130573 1257 6970697431293027060355040B13536970697454657374436572746966696361 1258 7465417574686F72697479820100300D06092A864886F70D0101050500038181 1259 006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2 1260 2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870 1261 102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153 1262 278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7 1263 5E30820339308202A2A00302010202080090008902240001300D06092A864886 1264 F70D01010505003070310B300906035504061302555331133011060355040813 1265 0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30 1266 0C060355040A1305736970697431293027060355040B13536970697454657374 1267 4365727469666963617465417574686F72697479301E170D3033313032313134 1268 343332355A170D3133313031383134343332355A3062310B3009060355040613 1269 025553311330110603550408130A43616C69666F726E69613111300F06035504 1270 07130853616E4A6F7365310E300C060355040A13057369706974311B30190603 1271 550403141273656E646572406578616D706C652E6F726730819F300D06092A86 1272 4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692 1273 2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79 1274 76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5 1275 FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9 1276 79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D 1277 0603551D1104163014811273656E646572406578616D706C652E6F7267300906 1278 03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70 1279 E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580 1280 546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113 1281 30110603550408130A43616C69666F726E69613111300F060355040713085361 1282 6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353 1283 69706974546573744365727469666963617465417574686F7269747982010030 1284 0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978 1285 7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E 1286 C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A 1287 C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972 1288 242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30 1289 70310B3009060355040613025553311330110603550408130A43616C69666F72 1290 6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305 1291 736970697431293027060355040B135369706974546573744365727469666963 1292 617465417574686F7269747902080090008902240001300906052B0E03021A05 1293 00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C 1294 06092A864886F70D010905310F170D3034303132363139313831345A30230609 1295 2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943 1296 95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E 1297 06082A864886F70D030202020080300D06082A864886F70D0302020140300706 1298 052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01 1299 010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C 1300 C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C 1301 822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087 1302 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 1303 79089AAD95767F 1305 ------590F24D439B31E08745DEF0CD9397189-- 1307 --my-boundary-9-- 1309 8. Transfer with multiple parties 1311 In this example the Originator places call to the Facilitator who 1312 reaches the Recipient through the Screener. The Recipient's contact 1313 information is exposed to the Facilitator and the Originator. This 1314 example is provided for clarification of the semantics of the REFER 1315 method only and should not be used as the design of an 1316 implementation. 1318 Originator Facilitator Screener Recipient 1319 Call-ID | | | | 1320 1 |INVITE/200 OK/ACK | |"Get Fred for me!" 1321 |----------->| | | "Right away!" 1322 1 |INVITE (hold)/200 OK/ACK | | 1323 |<-----------| | | 1325 2 | |INVITE/200 OK/ACK |"I have a call 1326 | |----------->| |from Mary for Fred" 1327 2 | |INVITE (hold)/200 OK/ACK "Hold please" 1328 | |<-----------| | 1329 3 | | |INVITE/200 OK/ACK 1330 | | |--------->|"You have a call 1331 | | | |from Mary" 1332 | | | | "Put her through" 1333 3 | | |INVITE (hold)/200 OK/ACK 1334 | | |--------->| 1335 2 | |REFER | | 1336 | |<-----------| | 1337 2 | |202 Accepted| | 1338 | |----------->| | 1339 2 | |NOTIFY (100 Trying) | 1340 | |----------->| | 1341 2 | |200 OK | | 1342 | |<-----------| | 1343 2 | |INVITE/200 OK/ACK | 1344 | |---------------------->|"This is Fred" 1345 2 | |NOTIFY (200 OK) | "Please hold for 1346 | |----------->| | Mary" 1347 2 | |200 OK | | 1348 | |<-----------| | 1349 2 | |BYE/200 OK | | 1350 | |<-----------| | 1351 3 | | |BYE/200 OK| 1352 | | |--------->| 1353 2 | |INVITE (hold)/200 OK/ACK 1354 | |---------------------->| 1355 1 |REFER | | | 1356 |<-----------| | | 1357 1 |202 Accepted| | | 1358 |----------->| | | 1359 1 |NOTIFY (100 Trying) | | 1360 |----------->| | | 1361 1 |200 OK | | | 1362 |<-----------| | | 1363 1 |INVITE/200 OK/ACK | | 1364 |----------------------------------->| "Hey Fred" 1365 1 |NOTIFY (200 OK) | | "Hello Mary" 1366 |----------->| | | 1367 1 |200 OK | | | 1368 |<-----------| | | 1369 1 |BYE/200 OK | | | 1370 |<-----------| | | 1371 2 | |BYE/200 OK | | 1372 | |---------------------->| 1374 1 |BYE/200 OK | | | 1375 |<-----------------------------------| "See you later" 1377 Figure 10. Transfer with Multiple Parties Example. 1379 9. Changes from draft-sipping-cc-transfer-01 1381 o Added example S/MIME messages in Referred-By section. 1382 o Added reference and discussion of GRUUs 1384 10. Changes from draft-sipping-cc-transfer-00 1386 o Added section on use of Referred-By header. 1387 o Added selected message details. 1388 o Added flow for attended transfer with non-globally routable 1389 Contact URI. 1390 o Added flow for attended transfer fallback to unattended transfer. 1391 o Added Security Considerations Section. 1393 11. IANA Considerations 1395 None. 1397 12. Security Considerations 1399 The call transfer flows shown in this document are implemented using 1400 the REFER and Replaces call control primitives in SIP. As such, the 1401 attacks and security approaches are those detailed in the REFER and 1402 Replaces documents which are briefly summarized in the following 1403 paragraphs. This document addresses the issue of protecting the 1404 Address of Record URI of a transfer target in Sections 6.1 and 6.2. 1406 Any REFER request must be appropriately authenticated and authorized 1407 using standard SIP mechanisms or calls may be hijacked. A user agent 1408 may use local policy or human intervention in deciding whether or not 1409 to accept a REFER. In generating NOTIFY responses based on the 1410 outcome of the triggered request, care should be taken in 1411 constructing the message/sipfrag body to ensure that no private 1412 information is leaked. 1414 An INVITE containing a Replaces header field should only be accepted 1415 if it has been properly authenticated and authorized using standard 1416 SIP mechanisms, and the requestor is authorized to perform dialog 1417 replacement. 1419 13. Acknowledgments 1421 This draft is a collaborative product of the SIP working group. 1423 Thanks to Rohan Mahy for his input on the use of Replaces in 1424 transfer. 1426 Normative References 1428 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1429 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1430 Session Initiation Protocol", RFC 3261, June 2002. 1432 [2] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1433 Method", RFC 3515, April 2003. 1435 [3] Biggs, B., Dean, R. and R. Mahy, "The Session Inititation 1436 Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-04 1437 (work in progress), August 2003. 1439 [4] Sparks, R., "The SIP Referred-By Mechanism", 1440 draft-ietf-sip-referredby-03 (work in progress), August 2003. 1442 [5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 1443 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 1444 draft-ietf-sip-gruu-00 (work in progress), January 2004. 1446 Informative References 1448 [6] Mahy, R., "A Call Control and Multi-party usage framework for 1449 the Session Initiation Protocol (SIP)", 1450 draft-ietf-sipping-cc-framework-03 (work in progress), October 1451 2003. 1453 [7] Sparks, R., "Session Initiation Protocol Torture Test Messages", 1454 draft-ietf-sipping-torture-tests-03 (work in progress), January 1455 2004. 1457 Authors' Addresses 1459 Robert J. Sparks 1460 dynamicsoft 1461 5100 Tennyson Parkway 1462 Suite 1200 1463 Plano, TX 75024 1465 EMail: rsparks@dynamicsoft.com 1466 Alan Johnston 1467 MCI 1468 100 South 4th Street 1469 St. Louis, MO 63102 1471 EMail: alan.johnston@mci.com 1473 Intellectual Property Statement 1475 The IETF takes no position regarding the validity or scope of any 1476 intellectual property or other rights that might be claimed to 1477 pertain to the implementation or use of the technology described in 1478 this document or the extent to which any license under such rights 1479 might or might not be available; neither does it represent that it 1480 has made any effort to identify any such rights. Information on the 1481 IETF's procedures with respect to rights in standards-track and 1482 standards-related documentation can be found in BCP-11. Copies of 1483 claims of rights made available for publication and any assurances of 1484 licenses to be made available, or the result of an attempt made to 1485 obtain a general license or permission for the use of such 1486 proprietary rights by implementors or users of this specification can 1487 be obtained from the IETF Secretariat. 1489 The IETF invites any interested party to bring to its attention any 1490 copyrights, patents or patent applications, or other proprietary 1491 rights which may cover technology that may be required to practice 1492 this standard. Please address the information to the IETF Executive 1493 Director. 1495 Full Copyright Statement 1497 Copyright (C) The Internet Society (2004). All Rights Reserved. 1499 This document and translations of it may be copied and furnished to 1500 others, and derivative works that comment on or otherwise explain it 1501 or assist in its implementation may be prepared, copied, published 1502 and distributed, in whole or in part, without restriction of any 1503 kind, provided that the above copyright notice and this paragraph are 1504 included on all such copies and derivative works. However, this 1505 document itself may not be modified in any way, such as by removing 1506 the copyright notice or references to the Internet Society or other 1507 Internet organizations, except as needed for the purpose of 1508 developing Internet standards in which case the procedures for 1509 copyrights defined in the Internet Standards process must be 1510 followed, or as required to translate it into languages other than 1511 English. 1513 The limited permissions granted above are perpetual and will not be 1514 revoked by the Internet Society or its successors or assignees. 1516 This document and the information contained herein is provided on an 1517 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1518 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1519 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1520 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1521 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1523 Acknowledgment 1525 Funding for the RFC Editor function is currently provided by the 1526 Internet Society.