idnits 2.17.1 draft-ietf-sipping-cc-transfer-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2009) is 5526 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-10 Summary: 1 error (**), 0 flaws (~~), 3 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 Estacado Systems 4 Intended status: BCP A. Johnston, Ed. 5 Expires: September 4, 2009 Avaya 6 D. Petrie 7 SIPez LLC 8 March 3, 2009 10 Session Initiation Protocol Call Control - Transfer 11 draft-ietf-sipping-cc-transfer-12 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 4, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document describes providing Call Transfer capabilities in the 60 Session Initiation Protocol (SIP). SIP extensions such as REFER and 61 Replaces are used to provide a number of transfer services including 62 blind transfer, consultative transfer, and attended transfer. This 63 work is part of the SIP multiparty call control framework. 65 Table of Contents 67 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Actors and Roles . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Using REFER to achieve Call Transfer . . . . . . . . . . . . . 6 72 6. Basic Transfer . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6.1. Successful Transfer . . . . . . . . . . . . . . . . . . . 8 74 6.2. Transfer with Dialog Reuse . . . . . . . . . . . . . . . . 12 75 6.3. Failed Transfer . . . . . . . . . . . . . . . . . . . . . 16 76 6.3.1. Target Busy . . . . . . . . . . . . . . . . . . . . . 16 77 6.3.2. Transfer Target does not answer . . . . . . . . . . . 18 78 7. Transfer with Consultation Hold . . . . . . . . . . . . . . . 19 79 7.1. Exposing transfer target . . . . . . . . . . . . . . . . . 19 80 7.2. Protecting transfer target . . . . . . . . . . . . . . . . 20 81 7.3. Attended Transfer . . . . . . . . . . . . . . . . . . . . 25 82 7.4. Recovery when one party does not support REFER . . . . . . 28 83 7.5. Attended transfer when Contact URI is not known to 84 route to a unique user agent. . . . . . . . . . . . . . . 29 85 7.6. Semi-Attended Transfer . . . . . . . . . . . . . . . . . . 36 86 7.7. Attended Transfer Fallback to Basic Transfer . . . . . . . 41 87 8. Transfer with Referred-By . . . . . . . . . . . . . . . . . . 43 88 9. Transfer as an Ad-Hoc Conference . . . . . . . . . . . . . . . 47 89 10. Transfer with multiple parties . . . . . . . . . . . . . . . . 50 90 11. Gateway Transfer Issues . . . . . . . . . . . . . . . . . . . 52 91 11.1. Coerce Gateway Hairpins to the Same Gateway . . . . . . . 52 92 11.2. Consultative Turned Blind Gateway Glare . . . . . . . . . 53 93 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 94 13. Security Considerations . . . . . . . . . . . . . . . . . . . 53 95 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 96 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 97 15.1. Normative References . . . . . . . . . . . . . . . . . . . 54 98 15.2. Informative References . . . . . . . . . . . . . . . . . . 55 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 101 1. Overview 103 This document describes providing Call Transfer capabilities and 104 requirements in SIP [RFC3261]. This work is part of the Multiparty 105 Call Control Framework [I-D.ietf-sipping-cc-framework]. 107 The mechanisms discussed here are most closely related to traditional 108 basic and consultation hold transfers. 110 This document details the use of REFER method [RFC3515] and Replaces 111 [RFC3891] header field to achieve call transfer. 113 A user agent that fully supports the transfer mechanisms described in 114 this document supports REFER[RFC3515] and Replaces[RFC3891] in 115 addition to RFC 3261 [RFC3261]. A user agent should use a Contact 116 URI which meets the requirements in Section 8.1.1.8 of RFC 3261. A 117 compliant user agent supports the Target-Dialog header field 118 [RFC4538]. 120 2. Actors and Roles 122 There are three actors in a given transfer event, each playing one of 123 the following roles: 125 Transferee - the party being transferred to the Transfer 126 Target. 128 Transferor - the party initiating the transfer 130 Transfer Target - the new party being introduced into a 131 call with the Transferee. 133 The following roles are used to describe transfer requirements and 134 scenarios: 136 Originator - wishes to place a call to the Recipient. This 137 actor is the source of the first INVITE in a 138 session, to either a Facilitator or a Screener. 140 Facilitator - receives a call or out-of-band request from the 141 Originator, establishes a call to the Recipient 142 through the Screener, and connects the 143 Originator to the Recipient. Typically, a Facilitator 144 acts on behalf of the Originator. 146 Screener - receives a call ultimately intended for the 147 Recipient and transfers the calling party to 148 the Recipient if appropriate. Typically, a Screener 149 acts on behalf of the Recipient. 151 Recipient - the party the Originator is ultimately 152 connected to. 154 3. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in BCP 14, RFC 2119 159 [RFC2119]. 161 4. Requirements 163 1. Any party in a SIP session must be able to transfer any other 164 party in that session at any point in that session. 165 2. The Transferor and the Transferee must not be removed from a 166 session as part of a transfer transaction. 168 At first glance, requirement 2 may seem to indicate 169 that the user experience in a transfer must be 170 significantly different from what a current PBX or 171 Centrex user expects. As the call-flows in this 172 document show, this is not the case. A client may 173 preserve the current experience. In fact, without 174 this requirement, some forms of the current 175 experience (ringback on transfer failure 176 for instance) will be lost. 178 3. The Transferor must know whether or not the transfer was 179 successful. 181 4. The Transferee must be able to replace an existing dialog with a 182 new dialog. 183 5. The Transferor and Transferee should indicate their support for 184 the primitives required to achieve transfer. 185 6. The Transferor should provide the Transfer Target and Transferee 186 with information about the nature and progress of the transfer 187 operation being attempted. 189 To meet this requirement, the transfer operation can 190 be modeled as an ad-hoc conference between three 191 parties, as discussed in Section 8. 193 5. Using REFER to achieve Call Transfer 195 A REFER [RFC3515] can be issued by the Transferor to cause the 196 Transferee to issue an INVITE to the Transfer-Target. Note that a 197 successful REFER transaction does not terminate the session between 198 the Transferor and the Transferee. If those parties wish to 199 terminate their session, they must do so with a subsequent BYE 200 request. The media negotiated between the transferee and the 201 transfer target is not affected by the media that had been negotiated 202 between the transferor and the transferee. In particular, the INVITE 203 issued by the Transferee will have the same SDP body it would have if 204 he Transferee had initiated that INVITE on its own. Further, the 205 disposition of the media streams between the Transferor and the 206 Transferee is not altered by the REFER method. 208 Agents may alter a session's media through additional signaling. For 209 example, they may make use of the SIP hold re-INVITE [RFC3261] or 210 conferencing extensions described in the conferencing framework 211 [RFC4353]. 213 To perform the transfer, the transferor and transferee could reuse an 214 existing dialog established by an INVITE to send the REFER. This 215 would result in a single dialog shared by two uses - an invite usage 216 and a subscription usage. The call flows for this are shown in 217 detail in Section 6.2. However, the approach described in this 218 document is to avoid dialog reuse. The issues and difficulties 219 associated with dialog reuse are described in [RFC5057] 221 Motivations for reusing the existing dialog include: 222 1. There was no way to ensure that a REFER on a new dialog would 223 reach the particular endpoint involved in a transfer. Many 224 factors, including details of implementations and changes in 225 proxy routing between an INVITE and a REFER could cause the REFER 226 to be sent to the wrong place. Sending the REFER down the 227 existing dialog ensured it got to the endpoint we were already 228 talking to. 229 2. It was unclear how to associate an existing invite usage with a 230 REFER arriving on a new dialog, where it was completely obvious 231 what the association was when the REFER came on the invite 232 usage's dialog. 233 3. There were concerns with authorizing out-of-dialog REFERs. The 234 authorization policy for REFER in most implementations piggybacks 235 on the authorization policy for INVITE (which is, in most cases, 236 based simply on "I placed or answered this call"). 238 GRUUs [I-D.ietf-sip-gruu] can be used to address problem 1. Problem 239 2 can be addressed using the Target-Dialog header field defined in 240 [RFC4538]. In the immediate term, this solution to problem 2 allows 241 the existing REFER authorization policy to be reused. 243 As a result, if the Transferee supports the target-dialog extension 244 and the Transferor knows the Contact URI is routable outside the 245 dialog, the REFER SHOULD be sent in a new dialog. If the nature of 246 the Contact URI is not known or if support for the target-dialog 247 extension is not known, the REFER SHOULD be sent inside the existing 248 dialog. A Transferee MUST be prepared to receive a REFER either 249 inside or outside a dialog. One way that a Transferor could know 250 that a Contact URI is routable outside a dialog is by validation 251 (e.g. sending an OPTIONS and receiving a response) or if it satisfies 252 the properties described in the GRUU specification 253 [I-D.ietf-sip-gruu]. 255 This document does not prescribe the flows and examples precisely as 256 they are shown, but rather the flows illustrate the principles for 257 best practice for the transfer feature. The call flows represent 258 well-reviewed examples of SIP usage to implement transfer with REFER, 259 which are best common practice according to IETF consensus. 261 In most of the following examples, the Transferor is in the 262 atlanta.example.com domain, the Transferee is in the 263 biloxi.example.com, and the Transfer Target is in the 264 chicago.example.com domain. 266 6. Basic Transfer 268 Basic Transfer consists of the Transferor providing the Transfer 269 Target's contact to the Transferee. The Transferee attempts to 270 establish a session using that contact and reports the results of 271 that attempt to the Transferor. The signaling relationship between 272 the Transferor and Transferee is not terminated, so the call is 273 recoverable if the Transfer Target cannot be reached. Note that the 274 Transfer Target's contact information has been exposed to the 275 Transferee. The provided contact can be used to make new calls in 276 the future. 278 The participants in a basic transfer SHOULD indicate support for the 279 REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to 280 INVITE, and OPTIONS messages. Participants SHOULD also indicate 281 support for Target-Dialog in the Supported header field. 283 The diagrams below show the first line of each message. The first 284 column of the figure shows the dialog used in that particular 285 message. In these diagrams, media is managed through re-INVITE 286 holds, but other mechanisms (mixing multiple media streams at the UA 287 or using the conferencing extensions for example) are valid. 288 Selected message details are shown labeled as message F1, F2, etc. 290 Each of the flows below shows the dialog between the Transferor and 291 the Transferee remaining connected (on hold) during the REFER 292 process. While this provides the greatest flexibility for recovery 293 from failure, it is not necessary. If the Transferor's agent does 294 not wish to participate in the remainder of the REFER process and has 295 no intention of assisting with recovery from transfer failure, it 296 could emit a BYE to the Transferee as soon as the REFER transaction 297 completes. This flow is sometimes known as "unattended transfer" or 298 "blind transfer". 300 Figure 1 shows transfer when the Transferee utilizes a GRUU and 301 supports the target-dialog extension and indicates this to the 302 Transferor. As a result, the Transferor sends the REFER outside the 303 INVITE dialog. The Transferee is able to match this REFER to the 304 existing dialog using the Target-Dialog header field in the refer 305 which references the existing dialog. 307 6.1. Successful Transfer 308 Transferor Transferee Transfer 309 | | Target 310 | INVITE F1 | | 311 dialog1 |<-------------------| | 312 | 200 OK F2 | | 313 dialog1 |------------------->| | 314 | ACK | | 315 dialog1 |<-------------------| | 316 | INVITE (hold) | | 317 dialog1 |------------------->| | 318 | 200 OK | | 319 dialog1 |<-------------------| | 320 | ACK | | 321 dialog1 |------------------->| | 322 | REFER F3 (Target-Dialog:1) | 323 dialog2 |------------------->| | 324 | 202 Accepted | | 325 dialog2 |<-------------------| | 326 | NOTIFY (100 Trying) F4 | 327 dialog2 |<-------------------| | 328 | 200 OK | | 329 dialog2 |------------------->| | 330 | | INVITE F5 | 331 dialog3 | |------------------->| 332 | | 200 OK | 333 dialog3 | |<-------------------| 334 | | ACK | 335 dialog3 | |------------------->| 336 | NOTIFY (200 OK) F6| | 337 dialog2 |<-------------------| | 338 | 200 OK | | 339 dialog2 |------------------->| | 340 | BYE | | 341 dialog1 |------------------->| | 342 | 200 OK | | 343 dialog1 |<-------------------| | 344 | | BYE | 345 dialog3 | |<-------------------| 346 | | 200 OK | 347 dialog3 | |------------------->| 349 Figure 1. Basic Transfer Call Flow. 351 F1 INVITE Transferee -> Transferor 353 INVITE sips:transferor@atlanta.example.com SIP/2.0 354 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 355 Max-Forwards: 70 356 To: 357 From: ;tag=7553452 358 Call-ID: 090459243588173445 359 CSeq: 29887 INVITE 360 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 361 Supported: replaces, gruu, tdialog 362 Contact: 363 Content-Type: application/sdp 364 Content-Length: ... 366 F2 200 OK Transferor -> Transferee 368 SIP/2.0 200 OK 369 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 370 To: ;tag=31kdl4i3k 371 From: ;tag=7553452 372 Call-ID: 090459243588173445 373 CSeq: 29887 INVITE 374 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 375 Supported: replaces, gruu, tdialog 376 Contact: 377 Content-Type: application/sdp 378 Content-Length: ... 380 F3 REFER Transferor -> Transferee 382 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 383 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9 384 Max-Forwards: 70 385 To: 386 From: ;tag=1928301774 387 Call-ID: a84b4c76e66710 388 CSeq: 314159 REFER 389 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 390 Supported: gruu, replaces, tdialog 391 Require: tdialog 392 Refer-To: 393 Target-Dialog: 090459243588173445;local-tag=7553452 394 ;remote-tag=31kdl4i3k 395 Contact: 396 Content-Length: 0 398 F4 NOTIFY Transferee -> Transferor 399 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 400 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 401 Max-Forwards: 70 402 To: ;tag=1928301774 403 From: 404 ;tag=a6c85cf 405 Call-ID: a84b4c76e66710 406 CSeq: 73 NOTIFY 407 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 408 Supported: replaces, tdialog 409 Event: refer 410 Subscription-State: active;expires=60 411 Content-Type: message/sipfrag 412 Content-Length: ... 414 SIP/2.0 100 Trying 416 F5 INVITE Transferee -> Transfer Target 418 INVITE sips:transfertarget@chicago.example.com SIP/2.0 419 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234 420 Max-Forwards: 70 421 To: 422 From: ;tag=j3kso3iqhq 423 Call-ID: 90422f3sd23m4g56832034 424 CSeq: 521 REFER 425 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 426 Supported: replaces, gruu, tdialog 427 Contact: 428 Content-Type: application/sdp 429 Content-Length: ... 431 F6 NOTIFY Transferee -> Transferor 433 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 434 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 435 Max-Forwards: 70 436 To: ;tag=1928301774 437 From: 438 ;tag=a6c85cf 439 Call-ID: a84b4c76e66710 440 CSeq: 74 NOTIFY 441 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 442 Supported: replaces, tdialog 443 Event: refer 444 Subscription-State: terminated;reason=noresource 445 Content-Type: message/sipfrag 446 Content-Length: ... 448 SIP/2.0 200 OK 450 6.2. Transfer with Dialog Reuse 452 In this scenario, the Transferor does not know the properties of the 453 Transferee's Contact URI or does not know that the Transferee 454 supports the Target-Dialog header field. As a result, the REFER is 455 sent inside the INVITE dialog. 457 Transferor Transferee Transfer 458 | | Target 459 | INVITE F1 | | 460 dialog1 |<-------------------| | 461 | 200 OK F2 | | 462 dialog1 |------------------->| | 463 | ACK | | 464 dialog1 |<-------------------| | 465 | INVITE (hold) | | 466 dialog1 |------------------->| | 467 | 200 OK | | 468 dialog1 |<-------------------| | 469 | ACK | | 470 dialog1 |------------------->| | 471 | REFER F3 | | 472 dialog1 |------------------->| | 473 | 202 Accepted | | 474 dialog1 |<-------------------| | 475 | NOTIFY (100 Trying) F4 | 476 dialog1 |<-------------------| | 477 | 200 OK | | 478 dialog1 |------------------->| | 479 | | INVITE F5 | 480 dialog2 | |------------------->| 481 | | 200 OK | 482 dialog2 | |<-------------------| 483 | | ACK | 484 dialog2 | |------------------->| 485 | NOTIFY (200 OK) F6| | 486 dialog1 |<-------------------| | 487 | 200 OK | | 488 dialog1 |------------------->| | 489 | BYE | | 490 dialog1 |------------------->| | 491 | 200 OK | | 492 dialog1 |<-------------------| | 493 | | BYE | 494 dialog2 | |<-------------------| 495 | | 200 OK | 496 dialog2 | |------------------->| 498 Figure 2. Transfer with Dialog Reuse. 500 F1 INVITE Transferee -> Transferor 502 INVITE sips:transferor@atlanta.example.com SIP/2.0 503 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 504 Max-Forwards: 70 505 To: 506 From: ;tag=7553452 507 Call-ID: 090459243588173445 508 CSeq: 29887 INVITE 509 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 510 Supported: replaces 511 Contact: 512 Content-Type: application/sdp 513 Content-Length: ... 515 F2 200 OK Transferor -> Transferee 517 SIP/2.0 200 OK 518 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 519 To: ;tag=31kdl4i3k 520 From: ;tag=7553452 521 Call-ID: 090459243588173445 522 CSeq: 29887 INVITE 523 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 524 Supported: gruu, replaces 525 Contact: 526 Content-Type: application/sdp 527 Content-Length: ... 529 F3 REFER Transferor -> Transferee 531 REFER sips:transferee@192.0.2.4 SIP/2.0 532 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9 533 Max-Forwards: 70 534 To: ;tag=7553452 535 From: ;tag=31kdl4i3k 536 Call-ID: 090459243588173445 537 CSeq: 314159 REFER 538 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 539 Supported: replaces 540 Refer-To: 541 Contact: 542 Content-Length: 0 544 F4 NOTIFY Transferee -> Transferor 546 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 547 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 548 Max-Forwards: 70 549 To: ;tag=31kdl4i3k 550 From: ;tag=7553452 551 Call-ID: 090459243588173445 552 CSeq: 29888 INVITE 553 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 554 Supported: replaces 555 Event: refer 556 Subscription-State: active;expires=60 557 Content-Type: message/sipfrag 558 Content-Length: ... 560 SIP/2.0 100 Trying 562 F5 INVITE Transferee -> Transfer Target 564 INVITE sips:transfertarget@chicago.example.com SIP/2.0 565 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234 566 Max-Forwards: 70 567 To: 568 From: ;tag=j3kso3iqhq 569 Call-ID: 90422f3sd23m4g56832034 570 CSeq: 521 REFER 571 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 572 Supported: replaces 573 Contact: 574 Content-Type: application/sdp 575 Content-Length: ... 577 F6 NOTIFY Transferee -> Transferor 579 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 580 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 581 Max-Forwards: 70 582 To: ;tag=31kdl4i3k 583 From: ;tag=7553452 584 Call-ID: 090459243588173445 585 CSeq: 29889 INVITE 586 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 587 Supported: replaces 588 Event: refer 589 Subscription-State: terminated;reason=noresource 590 Content-Type: message/sipfrag 591 Content-Length: ... 593 SIP/2.0 200 OK 595 6.3. Failed Transfer 597 This section shows examples of failed transfer attempts. After the 598 transfer failure occurs, the Transferor takes the Transferee off hold 599 and resumes the session. 601 6.3.1. Target Busy 602 Transferor Transferee Transfer 603 | | Target 604 | | | 605 | INVITE | | 606 dialog1 |<-------------------| | 607 | 200 OK | | 608 dialog1 |------------------->| | 609 | ACK | | 610 dialog1 |<-------------------| | 611 | INVITE (hold) | | 612 dialog1 |------------------->| | 613 | 200 OK | | 614 dialog1 |<-------------------| | 615 | ACK | | 616 dialog1 |------------------->| | 617 | REFER (Target-Dialog:1) | 618 dialog2 |------------------->| | 619 | 202 Accepted | | 620 dialog2 |<-------------------| | 621 | NOTIFY (100 Trying)| | 622 dialog2 |<-------------------| | 623 | 200 OK | | 624 dialog2 |------------------->| | 625 | | INVITE | 626 dialog3 | |------------------->| 627 | | 486 Busy Here | 628 dialog3 | |<-------------------| 629 | | ACK | 630 dialog3 | |------------------->| 631 | NOTIFY (486 Busy Here) | 632 dialog2 |<-------------------| | 633 | 200 OK | | 634 dialog2 |------------------->| | 635 | INVITE (unhold) | | 636 dialog1 |------------------->| | 637 | 200 OK | | 638 dialog1 |<-------------------| | 639 | ACK | | 640 dialog1 |------------------->| | 641 | BYE | | 642 dialog1 |------------------->| | 643 | 200 OK | | 644 dialog1 |<-------------------| | 646 Figure 3. Failed Transfer - Target Busy 648 6.3.2. Transfer Target does not answer 650 Transferor Transferee Transfer 651 | | Target 652 | INVITE | | 653 dialog1 |<-------------------| | 654 | 200 OK | | 655 dialog1 |------------------->| | 656 | ACK | | 657 dialog1 |<-------------------| | 658 | INVITE (hold) | | 659 dialog1 |------------------->| | 660 | 200 OK | | 661 dialog1 |<-------------------| | 662 | ACK | | 663 dialog1 |------------------->| | 664 | REFER | | 665 dialog2 |------------------->| | 666 | 202 Accepted | | 667 dialog2 |<-------------------| | 668 | NOTIFY (100 Trying)| | 669 dialog2 |<-------------------| | 670 | 200 OK | | 671 dialog2 |------------------->| | 672 | | INVITE | 673 dialog3 | |------------------->| 674 | | 180 Ringing | 675 dialog3 | |<-------------------| 676 | (Transferee gets tired of waiting) 677 | | CANCEL | 678 dialog3 | |------------------->| 679 | | 200 OK (CANCEL) | 680 dialog3 | |<-------------------| 681 | 487 Request Cancelled (INVITE) 682 dialog3 | |<-------------------| 683 | | ACK | 684 dialog3 | |------------------->| 685 | NOTIFY (487 Request Cancelled) | 686 dialog2 |<-------------------| | 687 | 200 OK | | 688 dialog2 |------------------->| | 689 | INVITE (unhold) | | 690 dialog1 |------------------->| | 691 | 200 OK | | 692 dialog1 |<-------------------| | 693 | ACK | | 694 dialog1 |------------------->| | 695 | BYE | | 696 dialog1 |------------------->| | 697 | 200 OK | | 698 dialog1 |<-------------------| | 700 Figure 4. Failed Transfer - Target Does Not Answer. 702 7. Transfer with Consultation Hold 704 Transfer with Consultation Hold involves a session between the 705 transferor and the transfer target before the transfer actually takes 706 place. This is implemented with SIP Hold and Transfer as described 707 above. 709 A nice feature is for the transferor to let the target know that the 710 session relates to an intended transfer. Since many UAs render the 711 display name in the From header field to the user, a consultation 712 INVITE could contain a string such as "Incoming consultation from 713 Transferor with intent to transfer Transferee", where the display 714 names of the transferor and transferee are included in the string. 716 7.1. Exposing transfer target 718 The transferor places the transferee on hold, establishes a call with 719 the transfer target to alert them to the impending transfer, 720 terminates the connection with the transfer target, then proceeds 721 with transfer as above. This variation can be used to provide an 722 experience similar to that expected by current PBX and Centrex users. 724 To (hopefully) improve clarity, non-REFER transactions have been 725 collapsed into one indicator with the arrow showing the direction of 726 the request. 728 Transferor Transferee Transfer 729 | | Target 730 | | | 731 dialog1 | INVITE/200 OK/ACK | | 732 |<-------------------| | 733 dialog1 | INVITE (hold)/200 OK/ACK | 734 |------------------->| | 735 dialog2 | INVITE/200 OK/ACK | | 736 |---------------------------------------->| 737 dialog2 | BYE/200 OK | | 738 |---------------------------------------->| 739 dialog3 | REFER | | 740 |------------------->| | 741 dialog3 | 202 Accepted | | 742 |<-------------------| | 743 dialog3 | NOTIFY (100 Trying)| | 744 |<-------------------| | 745 dialog3 | 200 OK | | 746 |------------------->| | 747 dialog4 | | INVITE/200 OK/ACK | 748 | |------------------->| 749 dialog3 | NOTIFY (200 OK) | | 750 |<-------------------| | 751 dialog3 | 200 OK | | 752 |------------------->| | 753 dialog1 | BYE/200 OK | | 754 |------------------->| | 755 dialog4 | | BYE/200 OK | 756 | |<-------------------| 758 Figure 5. Transfer with Consultation Hold - Exposing Transfer 759 Target. 761 7.2. Protecting transfer target 763 The transferor places the transferee on hold, establishes a call with 764 the transfer target and then reverses their roles, transferring the 765 original transfer target to the original transferee. This has the 766 advantage of hiding information about the original transfer target 767 from the original transferee. On the other hand, the Transferee's 768 experience is different that in current systems. The Transferee is 769 effectively "called back" by the Transfer Target. 771 One of the problems with this simplest implementation of a target 772 protecting transfer is that the transferee is receiving a new call 773 from the transfer-target. Unless the transferee's agent has a 774 reliable way to associate this new call with the call it already has 775 with the transferor, it will have to alert the new call on another 776 appearance. If this, or some other call-waiting-like UI were not 777 available, the transferee might be stuck returning a Busy-Here to the 778 transfer target, effectively preventing the transfer. There are many 779 ways that that correlation could be provided. The dialog parameters 780 could be provided directly as header parameters in the Refer-To: URI 781 for example. The Replaces mechanism [RFC3891] uses this approach and 782 solves this problem nicely. 784 For the flow below, dialog1 means dialog identifier 1, and consists 785 of the parameters of the Replaces header for dialog 1. In [RFC3891] 786 this is the Call-ID, To-tag and From-tag. 788 Note that the transferee's agent emits a BYE to the transferor's 789 agent as an immediate consequence of processing the Replaces header. 791 The Transferor knows that both the Transferee and the Transfer Target 792 support the Replaces header from the Supported: replaces header 793 contained in the 200 OK responses from both. 795 In this scenario, the Transferee utilizes a GRUU as a Contact URI for 796 reasons discussed in Section 6.3. 798 Note that the conventions used in the SIP Torture Test Messages 799 [RFC4475] document are reused, specifically the tag. 801 Transferor Transferee Transfer 802 | | Target 803 | | | 804 dialog1 | INVITE/200 OK/ACK F1 F2 | 805 |<-------------------| | 806 dialog1 | INVITE (hold)/200 OK/ACK | 807 |------------------->| | 808 dialog2 | INVITE/200 OK/ACK F3 F4 | 809 |---------------------------------------->| 810 dialog2 | INVITE (hold)/200 OK/ACK | 811 |---------------------------------------->| 812 dialog3 | REFER (Target-Dialog:2, | 813 | Refer-To:sips:Transferee?Replaces=1) F5| 814 |---------------------------------------->| 815 dialog3 | 202 Accepted | | 816 |<----------------------------------------| 817 dialog3 | NOTIFY (100 Trying)| | 818 |<----------------------------------------| 819 dialog3 | | 200 OK | 820 |---------------------------------------->| 821 dialog4 | INVITE (Replaces:dialog1)/200 OK/ACK F6 822 | |<-------------------| 823 dialog1 | BYE/200 OK | | 824 |<-------------------| | 825 dialog3 | NOTIFY (200 OK) | | 826 |<----------------------------------------| 827 dialog3 | | 200 OK | 828 |---------------------------------------->| 829 dialog2 | BYE/200 OK | | 830 |---------------------------------------->| 831 | (transferee and target converse) 832 dialog4 | | BYE/200 OK | 833 | |------------------->| 835 Figure 6. Transfer Protecting Transfer Target. 837 F1 INVITE Transferee -> Transferor 839 INVITE sips:transferor@atlanta.example.com SIP/2.0 840 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 841 Max-Forwards: 70 842 To: 843 From: ;tag=7553452 844 Call-ID: 090459243588173445 845 CSeq: 29887 INVITE 846 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 847 Supported: replaces, gruu 848 Contact: 849 Content-Type: application/sdp 850 Content-Length: ... 852 F2 200 OK Transferor -> Transferee 854 SIP/2.0 200 OK 855 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 856 To: ;tag=31431 857 From: ;tag=7553452 858 Call-ID: 090459243588173445 859 CSeq: 29887 INVITE 860 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 861 Supported: replaces, gruu, tdialog 862 Contact: 863 Content-Type: application/sdp 864 Content-Length: ... 866 F3 INVITE Transferor -> Transfer Target 868 INVITE sips:transfertarget@chicago.example.com SIP/2.0 869 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 870 Max-Forwards: 70 871 To: 872 From: ;tag=763231 873 Call-ID: 592435881734450904 874 CSeq: 29887 INVITE 875 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 876 Supported: gruu, replaces, tdialog 877 Require: replaces 878 Contact: 879 Content-Type: application/sdp 880 Content-Length: ... 882 F4 200 OK Transfer Target -> Transferor 884 SIP/2.0 200 OK 885 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 886 ;received=192.0.2.1 887 To: ;tag=9m2n3wq 888 From: ;tag=763231 889 Call-ID: 592435881734450904 890 CSeq: 29887 INVITE 891 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 892 Supported: replaces, gruu, tdialog 893 Contact: 894 Content-Type: application/sdp 895 Content-Length: ... 897 F5 REFER Transferor -> Transfer Target 899 REFER sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 900 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 901 Max-Forwards: 70 902 To: 903 From: ;tag=1928301774 904 Call-ID: a84b4c76e66710 905 CSeq: 314159 REFER 906 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 907 Supported: gruu, replaces, tdialog 908 Require: tdialog 909 910 Refer-To: 912 913 Target-Dialog: 592435881734450904;local-tag=9m2n3wq 914 ;remote-tag=763231 915 Contact: 916 Content-Length: 0 918 F6 INVITE Transfer Target -> Transferee 920 INVITE sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 921 Via: SIP/2.0/TLS client.chicago.example.com;branch=z9hG4bKnaslu84 922 Max-Forwards: 70 923 To: 924 From: ;tag=341234 925 Call-ID: kmzwdle3dl3d08 926 CSeq: 41 INVITE 927 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 928 Supported: gruu, replaces, tdialog 929 Contact: 930 Replaces: 090459243588173445;to-tag=7553452;from-tag=31431 931 Content-Type: application/sdp 932 Content-Length: ... 934 7.3. Attended Transfer 936 The transferor places the transferee on hold, establishes a call with 937 the transfer target to alert them to the impending transfer, places 938 the target on hold, then proceeds with transfer using an escaped 939 Replaces header field in the Refer-To header. This is another common 940 service expected by current PBX and Centrex users. 942 The Contact URI of the Transfer Target SHOULD be used by the 943 Transferor as the Refer-To URI, unless the URI is suspected or known 944 to not be routable outside the dialog. Otherwise, the Address of 945 Record (AOR) of the Transfer Target SHOULD be used. That is, the 946 same URI that the Transferor used to establish the session with the 947 Transfer Target should be used. In case the triggered INVITE is 948 routed to a different User Agent than the Transfer Target, the 949 Require: replaces header field SHOULD be used in the triggered 950 INVITE. (This is to prevent an incorrect User Agent which does not 951 support Replaces from ignoring the Replaces and answering the INVITE 952 without a dialog match.) 954 It is possible that proxy/service routing may prevent the triggered 955 INVITE from reaching the same User Agent. If this occurs, the 956 triggered invite will fail with a timout, 403, 404, etc error. The 957 Transferee MAY then retry the transfer with the Refer-To URI set to 958 the Contact URI. 960 Transferor Transferee Transfer 961 | | Target 962 | | | 963 dialog1 | INVITE/200 OK/ACK F1 F2 | 964 |<-------------------| | 965 dialog1 | INVITE (hold)/200 OK/ACK | 966 |------------------->| | 967 dialog2 | INVITE/200 OK/ACK F3 F4 | 968 |---------------------------------------->| 969 dialog2 | INVITE (hold)/200 OK/ACK | 970 |---------------------------------------->| 971 dialog3 | REFER (Target-Dialog:1, | 972 | Refer-To:sips:TransferTarget?Replaces=2) F5 973 |------------------->| | 974 dialog3 | 202 Accepted | | 975 |<-------------------| | 976 dialog3 | NOTIFY (100 Trying)| | 977 |<-------------------| | 978 dialog3 | 200 OK | | 979 |------------------->| | 980 dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6 981 | |------------------->| 982 dialog2 | BYE/200 OK | | 983 |<----------------------------------------| 984 dialog3 | NOTIFY (200 OK) | | 985 |<-------------------| | 986 dialog3 | 200 OK | | 987 |------------------->| | 988 dialog1 | BYE/200 OK | | 989 |------------------->| | 990 dialog4 | | BYE/200 OK | 991 | |<-------------------| 993 Figure 7. Attended Transfer Call Flow. 995 F1 INVITE Transferee -> Transferor 997 INVITE sips:transferor@atlanta.example.com SIP/2.0 998 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 999 Max-Forwards: 70 1000 To: 1001 From: ;tag=7553452 1002 Call-ID: 090459243588173445 1003 CSeq: 29887 INVITE 1004 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1005 Supported: replaces, gruu, tdialog 1006 Contact: 1007 Content-Type: application/sdp 1008 Content-Length: ... 1010 F2 200 OK Transferor -> Transferee 1012 SIP/2.0 200 OK 1013 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 1014 To: ;tag=31431 1015 From: ;tag=7553452 1016 Call-ID: 090459243588173445 1017 CSeq: 29887 INVITE 1018 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1019 Supported: replaces, gruu, tdialog 1020 Contact: 1021 Content-Type: application/sdp 1022 Content-Length: ... 1024 F3 INVITE Transferor -> Transfer Target 1026 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1027 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1028 Max-Forwards: 70 1029 To: 1030 From: ;tag=763231 1031 Call-ID: 592435881734450904 1032 CSeq: 29887 INVITE 1033 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1034 Supported: gruu, replaces, tdialog 1035 Require: replaces 1036 Contact: 1037 Content-Type: application/sdp 1038 Content-Length: ... 1040 F4 200 OK Transfer Target -> Transferor 1042 SIP/2.0 200 OK 1043 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1044 ;received=192.0.2.1 1045 To: ;tag=9m2n3wq 1046 From: ;tag=763231 1047 Call-ID: 592435881734450904 1048 CSeq: 29887 INVITE 1049 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1050 Supported: replaces, gruu 1051 Contact: 1052 Content-Type: application/sdp 1053 Content-Length: ... 1055 F5 REFER Transferor -> Transferee 1057 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 1058 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1059 Max-Forwards: 70 1060 To: 1061 From: ;tag=1928301774 1062 Call-ID: a84b4c76e66710 1063 CSeq: 314159 REFER 1064 Require: tdialog 1065 1066 Refer-To: 1068 1069 Target-Dialog: 592435881734450904;local-tag=9m2n3wq 1070 ;remote-tag=763231 1071 Contact: 1072 Content-Length: 0 1074 F6 INVITE Transferee -> Transfer Target 1076 INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 1077 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 1078 Max-Forwards: 70 1079 To: 1080 From: ;tag=954 1081 Call-ID: kmzwdle3dl3d08 1082 CSeq: 41 INVITE 1083 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1084 Supported: gruu, replaces, tdialog 1085 Contact: 1086 Replaces: 592435881734450904;to-tag=9m2n3wq;from-tag=763231 1087 Content-Type: application/sdp 1088 Content-Length: ... 1090 7.4. Recovery when one party does not support REFER 1092 If protecting or exposing the transfer target is not a concern, it is 1093 possible to complete a transfer with consultation hold when only the 1094 transferor and one other party support REFER. Note that a 405 Method 1095 Not Allowed might be returned instead of the 501 Not Implemented 1096 response. 1098 Transferor Transferee Transfer 1099 | | Target 1100 | | | 1101 dialog1 | INVITE/200 OK/ACK | | 1102 |<-------------------| | 1103 dialog1 | INVITE (hold)/200 OK/ACK | 1104 |------------------->| | 1105 dialog2 | INVITE/200 OK/ACK | | 1106 |---------------------------------------->| 1107 dialog2 | INVITE (hold)/200 OK/ACK | 1108 |---------------------------------------->| 1109 dialog3 | REFER (Target-Dialog:1, | 1110 | Refer-To:sips:TransferTarget?Replaces=2) 1111 |------------------->| | 1112 dialog3 | 501 Not Implemented | 1113 |<-------------------| | 1114 dialog4 | REFER (Refer-To:sips:Transferee?Replaces=dialog1) 1115 |---------------------------------------->| 1116 dialog4 | 202 Accepted | | 1117 |<----------------------------------------| 1118 dialog4 | NOTIFY (100 Trying)| | 1119 |<----------------------------------------| 1120 dialog4 | | 200 OK | 1121 |---------------------------------------->| 1122 dialog5 | INVITE (Replaces:dialog1)/200 OK/ACK 1123 | |<-------------------| 1124 dialog4 | NOTIFY (200 OK) | | 1125 |<----------------------------------------| 1126 dialog4 | | 200 OK | 1127 |---------------------------------------->| 1128 dialog1 | BYE/200 OK | | 1129 |<-------------------| | 1130 dialog2 | BYE/200 OK | | 1131 |---------------------------------------->| 1132 dialog5 | | BYE/200 OK | 1133 | |------------------->| 1135 Figure 8. Recovery when one party does not support REFER. 1137 7.5. Attended transfer when Contact URI is not known to route to a 1138 unique user agent. 1140 It is a requirement of RFC3261 that a Contact URI be globally 1141 routable even outside the dialog. However, due to RFC2543 User 1142 Agents and some architectures (NAT/Firewall traversal, screening 1143 proxies, ALGs, etc.) this will not always be the case. As a result, 1144 the method of Attended Transfer shown in Figures 6, 7, and 8 SHOULD 1145 only be used if the Contact URI is known to be routable outside the 1146 dialog. 1148 Figure 9 shows such a scenario where the Transfer Target Contact URI 1149 is not routable outside the dialog, so the triggered INVITE is sent 1150 to the AOR of the Transfer Target. 1152 Transferor Transferee Screening Transfer 1153 | | Proxy Target 1154 | | | | 1155 dialog1 | INVITE/200 OK/ACK| | | 1156 |<-----------------| | | 1157 dialog1 | INVITE (hold)/200 OK/ACK | | 1158 |----------------->| | | 1159 dialog2 | INVITE/200 OK/ACK F1 F2 | | 1160 |--------------------------------|------------>| 1161 dialog2 | INVITE (hold)/200 OK/ACK | 1162 |--------------------------------|------------>| 1163 dialog1 | REFER (Refer-To:sips:TargetAOR | 1164 | ?Replaces=dialog2&Require=replaces) F3 1165 |----------------->| | | 1166 dialog1 | 202 Accepted | | | 1167 |<-----------------| | | 1168 dialog1 | NOTIFY (100 Trying) | | 1169 |<-----------------| | | 1170 dialog1 | 200 OK | | | 1171 |----------------->| | | 1172 dialog4 |INVITE (Replaces:dialog2,Require:replaces)/200 OK/ACK F6 1173 | |------------>|------------>| 1174 dialog2 | BYE/200 OK | | | 1175 |<-------------------------------|<------------| 1176 dialog1 | NOTIFY (200 OK) F7 | | 1177 |<-----------------| | | 1178 dialog1 | 200 OK | | | 1179 |----------------->| | | 1180 dialog1 | BYE/200 OK | | | 1181 |----------------->| | | 1182 dialog3 | | | BYE/200 OK | 1183 | |<------------|-------------| 1185 Figure 9. Attended Transfer Call Flow with a Contact URI not known 1186 to be Globally Routable 1188 F1 INVITE Transferor -> Transfer Target 1190 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1191 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76 1192 Max-Forwards: 70 1193 To: 1194 From: ;tag=763231 1195 Call-ID: 090459243588173445 1196 CSeq: 29887 INVITE 1197 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1198 Supported: replaces 1199 Contact: 1200 Content-Type: application/sdp 1201 Content-Length: ... 1203 F2 200 OK Transfer Target -> Transferee 1205 SIP/2.0 200 OK 1206 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1207 ;received=192.0.2.1 1208 To: ;tag=9m2n3wq 1209 From: ;tag=763231 1210 Call-ID: 090459243588173445 1211 CSeq: 29887 INVITE 1212 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1213 Supported: replaces 1214 Contact: 1215 Content-Type: application/sdp 1216 Content-Length: ... 1218 F3 REFER Transferor -> Transferee 1220 REFER sips:transferee@192.0.2.4 SIP/2.0 1221 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1222 Max-Forwards: 70 1223 To: ;tag=a6c85cf 1224 From: ;tag=1928301774 1225 Call-ID: a84b4c76e66710 1226 CSeq: 314160 REFER 1227 1228 Refer-To: 1231 1232 Contact: 1233 Content-Length: 0 1235 F4 INVITE Transferee -> Transfer Target 1237 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1238 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 1239 Max-Forwards: 70 1240 To: 1241 From: ;tag=954 1242 Call-ID: 20482817324945934422930 1243 CSeq: 42 INVITE 1244 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1245 Supported: replaces 1246 Contact: 1247 Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 1248 Require: replaces 1249 Content-Type: application/sdp 1250 Content-Length: ... 1252 F5 NOTIFY Transferee -> Transferor 1254 NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 1255 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 1256 Max-Forwards: 70 1257 To: ;tag=1928301774 1258 From: ;tag=a6c85cf 1259 Call-ID: a84b4c76e66710 1260 CSeq: 76 NOTIFY 1261 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1262 Supported: replaces 1263 Event: refer;id=98873867 1264 Subscription-State: terminated;reason=noresource 1265 Content-Type: message/sipfrag 1266 Content-Length: ... 1268 SIP/2.0 200 OK 1270 Figure 10 shows a failure case in which the AOR URI fails to reach 1271 the transfer Target. As a result, the transfer is retried with the 1272 Contact URI which succeeds. 1274 Note that there is still no guarantee that the correct endpoint will 1275 be reached, and the result of this second REFER may also be a 1276 failure. In that case, the Transferor could fall back to unattended 1277 transfer or give up on the transfer entirely. Since two REFERs are 1278 sent within the dialog creating two distinct subscriptions, the 1279 Transferee uses the 'id' parameter in the Event header field to 1280 distinguish notifications for the two subscriptions. 1282 Transferor Transferee Screening Transfer 1283 | | Proxy Target 1284 | | | | 1285 dialog1 | INVITE/200 OK/ACK| | | 1286 |<-----------------| | | 1287 dialog1 | INVITE (hold)/200 OK/ACK | | 1288 |----------------->| | | 1289 dialog2 | INVITE/200 OK/ACK F1 F2 | | 1290 |--------------------------------|------------>| 1291 dialog2 | INVITE (hold)/200 OK/ACK | 1292 |--------------------------------|------------>| 1293 dialog1 | REFER (Refer-To:sips:TargetAOR? | 1294 | Replaces=dialog2&Require=replaces) F3 | 1295 |----------------->| | | 1296 dialog1 | 202 Accepted | | | 1297 |<-----------------| | | 1298 dialog1 | NOTIFY (100 Trying) | | 1299 |<-----------------| | | 1300 dialog1 | 200 OK | | | 1301 |----------------->| | | 1302 dialog3 | |INVITE (Replaces:dialog2, | 1303 | | Require:replaces)/403/ACK | 1304 | |------------>| | 1305 dialog1 | NOTIFY (403 Forbidden) F4 | | 1306 |<-----------------| | | 1307 dialog1 | 200 OK | | | 1308 |----------------->| | | 1309 dialog1 |REFER(Refer-To:sips:TargetContact?Replaces=dialog2) F5 1310 |----------------->| | | 1311 dialog1 | 202 Accepted | | | 1312 |<-----------------| | | 1313 dialog1 | NOTIFY (100 Trying) | | 1314 |<-----------------| | | 1315 dialog1 | 200 OK | | | 1316 |----------------->| | | 1317 dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6 1318 | |------------>|------------>| 1319 dialog2 | BYE/200 OK | | | 1320 |<-------------------------------|<------------| 1321 dialog1 | NOTIFY (200 OK) F7 | | 1322 |<-----------------| | | 1323 dialog1 | 200 OK | | | 1324 |----------------->| | | 1325 dialog1 | BYE/200 OK | | | 1326 |----------------->| | | 1327 dialog3 | | | BYE/200 OK | 1328 | |<------------|-------------| 1330 Figure 10. Attended Transfer Call Flow with non-routable Contact URI 1331 and AOR Failure 1333 F1 INVITE Transferor -> Transfer Target 1335 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1336 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76 1337 Max-Forwards: 70 1338 To: 1339 From: ;tag=763231 1340 Call-ID: 090459243588173445 1341 CSeq: 29887 INVITE 1342 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1343 Supported: replaces 1344 Contact: 1345 Content-Type: application/sdp 1346 Content-Length: ... 1348 F2 200 OK Transfer Target -> Transferee 1350 SIP/2.0 200 OK 1351 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1352 ;received=192.0.2.1 1353 To: ;tag=9m2n3wq 1354 From: ;tag=763231 1355 Call-ID: 090459243588173445 1356 CSeq: 29887 INVITE 1357 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1358 Supported: replaces 1359 Contact: 1360 Content-Type: application/sdp 1361 Content-Length: ... 1363 F3 REFER Transferor -> Transferee 1365 REFER sips:transferee@192.0.2.4 SIP/2.0 1366 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1367 Max-Forwards: 70 1368 To: ;tag=a6c85cf 1369 From: ;tag=1928301774 1370 Call-ID: a84b4c76e66710 1371 CSeq: 314159 REFER 1372 1373 Refer-To: 1376 1377 Contact: 1378 Content-Length: 0 1380 F4 NOTIFY Transferee -> Transferor 1382 NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 1383 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 1384 Max-Forwards: 70 1385 To: ;tag=1928301774 1386 From: ;tag=a6c85cf 1387 Call-ID: a84b4c76e66710 1388 CSeq: 74 NOTIFY 1389 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1390 Supported: replaces 1391 Event: refer;id=314159 1392 Subscription-State: terminated;reason=noresource 1393 Content-Type: message/sipfrag 1394 Content-Length: ... 1396 SIP/2.0 403 Forbidden 1398 F5 REFER Transferor -> Transferee 1400 REFER sips:transferee@192.0.2.4 SIP/2.0 1401 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1402 Max-Forwards: 70 1403 To: ;tag=a6c85cf 1404 From: ;tag=1928301774 1405 Call-ID: a84b4c76e66710 1406 CSeq: 314160 REFER 1407 1408 Refer-To: 1411 1412 Contact: 1413 Content-Length: 0 1415 F6 INVITE Transferee -> Transfer Target 1417 INVITE sips:transfertarget@client.chicago.example.com SIP/2.0 1418 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 1419 Max-Forwards: 70 1420 To: 1421 From: ;tag=954 1422 Call-ID: 20482817324945934422930 1423 CSeq: 42 INVITE 1424 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1425 Supported: replaces 1426 Contact: 1427 Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 1428 Content-Type: application/sdp 1429 Content-Length: ... 1431 F7 NOTIFY Transferee -> Transferor 1433 NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 1434 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 1435 Max-Forwards: 70 1436 To: ;tag=1928301774 1437 From: ;tag=a6c85cf 1438 Call-ID: a84b4c76e66710 1439 CSeq: 76 NOTIFY 1440 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1441 Supported: replaces 1442 Event: refer;id=314160 1443 Subscription-State: terminated;reason=noresource 1444 Content-Type: message/sipfrag 1445 Content-Length: ... 1447 SIP/2.0 200 OK 1449 To prevent this scenario from happening, the Transfer Target SHOULD 1450 use a Contact URI which is routable outside the dialog, which will 1451 result in the call flow of Figure 7. 1453 7.6. Semi-Attended Transfer 1455 In any of the consultation hold flows above, the Transferor may 1456 decide to terminate its attempt to contact the Transfer target before 1457 that session is established. Most frequently, that will be the end 1458 of the scenario, but in some circumstances, the transferor may wish 1459 to proceed with the transfer action. For example, the Transferor may 1460 wish to complete the transfer knowing that the transferee will end up 1461 eventually talking to the transfer-target's voice-mail service. Some 1462 PBX systems support this feature, sometimes called "semi-attended 1463 transfer", that is effectively a hybrid between a fully attended 1464 transfer and an unattended transfer. A call flow is shown in Figure 1465 11. In this flow, the Transferor's User Agent continues the transfer 1466 as an attended transfer even after the Transferor hangs up. Note 1467 that media must be played to the Transfer Target upon answer - 1468 otherwise, the Target may hang up and the resulting transfer 1469 operation will fail. 1471 Transferor Transferee Transfer 1472 | | Target 1473 | | | 1474 dialog1 | INVITE/200 OK/ACK F1 F2 | 1475 |<-------------------| | 1476 dialog1 | INVITE (hold)/200 OK/ACK | 1477 |------------------->| | 1478 dialog2 | INVITE | | 1479 |---------------------------------------->| 1480 dialog2 | | 180 Ringing | 1481 |<----------------------------------------| 1482 Transferor hangs up but wants transfer to continue 1483 | | | 1484 | User Agent continues transfer operation | 1485 | | | 1486 dialog2 | | 200 OK | 1487 |<----------------------------------------| 1488 dialog2 | ACK | | 1489 |---------------------------------------->| 1490 dialog2 | Media Played to keep Target from hanging up 1491 |========================================>| 1492 dialog3 | REFER (Target-Dialog:1, | 1493 | Refer-To:sips:TransferTarget?Replaces=2) 1494 |------------------->| | 1495 dialog3 | 202 Accepted | | 1496 |<-------------------| | 1497 dialog3 | NOTIFY (100 Trying)| | 1498 |<-------------------| | 1499 dialog3 | 200 OK | | 1500 |------------------->| | 1501 dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK 1502 | |------------------->| 1503 dialog2 | BYE/200 OK | | 1504 |<----------------------------------------| 1505 dialog3 | NOTIFY (200 OK) | | 1506 |<-------------------| | 1507 dialog3 | 200 OK | | 1508 |------------------->| | 1509 dialog1 | BYE/200 OK | | 1510 |------------------->| | 1511 dialog4 | | BYE/200 OK | 1512 | |<-------------------| 1514 Figure 11. Recommended Semi-Attended Transfer Call Flow. 1516 Two other possible semi-attended transfer call flows are shown in 1517 Figures 12 and 13. However, these call flows are NOT RECOMMENDED due 1518 to a race conditions. In both of these flows, when the Transferor 1519 hangs up, the Transferor attempts to revert to unattended transfer by 1520 sending a CANCEL to the Target. This can result in two race 1521 conditions. One is that the Target answers despite the CANCEL and 1522 the resulting unattended transfer fails. This race condition can be 1523 eliminated by the Transferor waiting to send the REFER until the 487 1524 response from the Target is returned. Instead of a 487, a 200 OK may 1525 return indicating that the Target has answered the consultation call. 1526 In this, case the call flow in Figure 13 must be followed. In this 1527 flow, the Transferor must play some kind of media to the Target to 1528 prevent the Target from hanging up, or the Transfer will fail. That 1529 is, the human at the Transfer Target will hear silence from when they 1530 answer (message F1) until the transfer completes (F3 and they are 1531 talking to the Transferee unless some media is played (F2). 1533 The second race condition occurs in Figure 12 if the Transfer Target 1534 goes "off hook" after the CANCEL is received and the 487 returned. 1535 This may result in a 486 Busy Here response to the unattended 1536 transfer. 1538 The recommended call flow of Figure 11 does not utilize a CANCEL and 1539 does not suffer from these race conditions. 1541 Transferor Transferee Transfer 1542 | | Target 1543 | | | 1544 dialog1 | INVITE/200 OK/ACK | | 1545 |<-------------------| | 1546 dialog1 | INVITE (hold)/200 OK/ACK | 1547 |------------------->| | 1548 dialog2 | INVITE | 1549 |---------------------------------------->| 1550 dialog2 | 180 Ringing | 1551 |<----------------------------------------| 1552 | | 1553 | Transferor gives up waiting | 1554 | | 1555 dialog2 | CANCEL | 1556 |---------------------------------------->| 1557 dialog2 | 200 OK | 1558 |<----------------------------------------| 1559 dialog2 | 487 Request Terminated | 1560 |<----------------------------------------| 1561 dialog2 | ACK | 1562 |---------------------------------------->| 1563 dialog3 | REFER (Target-Dialog:1) F3 | 1564 |------------------->| | 1565 dialog3 | 202 Accepted | | 1566 |<-------------------| | 1567 dialog3 | NOTIFY (100 Trying)| | 1568 |<-------------------| | 1569 dialog3 | 200 OK | | 1570 |------------------->| | 1571 dialog4 | INVITE/200 OK/ACK | 1572 | |------------------->| 1573 dialog3 | NOTIFY (200 OK) | | 1574 |<-------------------| | 1575 dialog3 | 200 OK | | 1576 |------------------->| | 1577 dialog1 | BYE/200 OK | | 1578 |------------------->| | 1579 dialog4 | | BYE/200 OK | 1580 | |<-------------------| 1582 Figure 12. Semi-Attended Transfer as Blind Transfer Call Flow. (Not 1583 Recommended) 1584 Transferor Transferee Transfer 1585 | | Target 1586 | | | 1587 dialog1 | INVITE/200 OK/ACK | | 1588 |<-------------------| | 1589 dialog1 | INVITE (hold)/200 OK/ACK | 1590 |------------------->| | 1591 dialog2 | INVITE | 1592 |---------------------------------------->| 1593 dialog2 | 180 Ringing | 1594 |<----------------------------------------| 1595 | | 1596 |Transferor gives up waiting but Target answers 1597 | | 1598 dialog2 | CANCEL | 1599 |---------------------------------------->| 1600 dialog2 | 200 OK (CANCEL) | 1601 |<----------------------------------------| 1602 dialog2 | 200 OK (INVITE) F1 | 1603 |<----------------------------------------| 1604 dialog2 | ACK | 1605 |---------------------------------------->| 1606 dialog2 | INVITE (hold)/200 OK/ACK | 1607 |---------------------------------------->| 1608 | Tones or media played avoid silence F2 | 1609 |========================================>| 1610 dialog1 |REFER (Refer-To:sips:TransferTarget | 1611 | ?Replaces=dialog2) | 1612 |------------------->| | 1613 dialog1 | 202 Accepted | | 1614 |<-------------------| | 1615 dialog1 | NOTIFY (100 Trying)| | 1616 |<-------------------| | 1617 dialog1 | 200 OK | | 1618 |------------------->| | 1619 dialog3 | INVITE (Replaces:dialog2)/200 OK/ACK F3 1620 | |------------------->| 1621 dialog2 | BYE/200 OK | | 1622 |<----------------------------------------| 1623 dialog1 | NOTIFY (200 OK) | | 1624 |<-------------------| | 1625 dialog1 | 200 OK | | 1626 |------------------->| | 1627 dialog1 | BYE/200 OK | | 1628 |------------------->| | 1629 dialog3 | | BYE/200 OK | 1630 | |<-------------------| 1632 Figure 13. Semi-Attended Transfer as Attended Transfer Call Flow. 1633 (Not Recommended) 1635 7.7. Attended Transfer Fallback to Basic Transfer 1637 In this flow, an attempted attended transfer fails so the transferor 1638 falls back to basic transfer. 1640 The call flow in Figure 14 shows the use of Require: replaces in the 1641 INVITE sent by the Transferor to the Transfer Target in which the 1642 Transferor's intention at the time of sending the INVITE to the 1643 Transfer Target was known to be to complete an attended transfer. 1644 Since the Target does not support Replaces, the INVITE is rejected 1645 with a 420 Bad Extension response, and the Transferor switches from 1646 attended transfer to basic transfer immediately. 1648 Transferor Transferee Transfer 1649 | | Target 1650 | | | 1651 dialog1 | INVITE/200 OK/ACK | | 1652 |<-------------------| | 1653 dialog1 | OPTIONS/200 OK | | 1654 |------------------->| | 1655 dialog1 | INVITE (hold)/200 OK/ACK | 1656 |------------------->| | 1657 dialog2 | INVITE (Require:replaces) | 1658 |---------------------------------------->| 1659 dialog2 | 420 Bad Extension | 1660 |<----------------------------------------| 1661 dialog2 | ACK | 1662 |---------------------------------------->| 1663 dialog1 | REFER (Refer-To:sips:TransferTarget) | 1664 |------------------->| | 1665 dialog1 | 202 Accepted | | 1666 |<-------------------| | 1667 dialog1 | NOTIFY (100 Trying)| | 1668 |<-------------------| | 1669 dialog1 | 200 OK | | 1670 |------------------->| | 1671 dialog3 | | INVITE/200 OK/ACK | 1672 | |------------------->| 1673 dialog1 | NOTIFY (200 OK) | | 1674 |<-------------------| | 1675 dialog1 | 200 OK | | 1676 |------------------->| | 1677 dialog1 | BYE/200 OK | | 1678 |------------------->| | 1679 dialog3 | | BYE/200 OK | 1680 | |<-------------------| 1682 Figure 14. Attended Transfer Fallback to Basic Transfer using 1683 Require:replaces. 1685 Figure 15 shows the use of OPTIONS when the Transferee and Transfer 1686 Target do not explicitly indicate support for the REFER method and 1687 Replaces header fields in Allow and Supported header fields and the 1688 Transferor did not have the intention of performing an attended 1689 transfer when the INVITE to the Target was sent. In dialog1, the 1690 Transferor determines using OPTIONS that the Transferee does support 1691 REFER and Replaces. As a result, the Transferor begins the attended 1692 transfer by placing the Transferee on hold and calling the Transfer 1693 Target. Using an OPTIONS in dialog2, the Transferor determines that 1694 the Target does not support either REFER or Replaces, making attended 1695 transfer impossible. The Transferor then ends dialog2 by sending a 1696 BYE then sends a REFER to the Transferee using the AOR URI of the 1697 Transfer Target. 1699 Transferor Transferee Transfer 1700 | | Target 1701 | | | 1702 dialog1 | INVITE/200 OK/ACK | | 1703 |<-------------------| | 1704 dialog1 | OPTIONS/200 OK | | 1705 |------------------->| | 1706 dialog1 | INVITE (hold)/200 OK/ACK | 1707 |------------------->| | 1708 dialog2 | INVITE/200 OK/ACK | | 1709 |---------------------------------------->| 1710 dialog2 | OPTIONS/200 OK | | 1711 |---------------------------------------->| 1712 dialog2 | BYE/200 OK | | 1713 |---------------------------------------->| 1714 dialog3 |REFER (Target-Dialog:1, | 1715 | Refer-To:sips:TransferTarget) | 1716 |------------------->| | 1717 dialog3 | 202 Accepted | | 1718 |<-------------------| | 1719 dialog3 | NOTIFY (100 Trying)| | 1720 |<-------------------| | 1721 dialog3 | 200 OK | | 1722 |------------------->| | 1723 dialog4 | | INVITE/200 OK/ACK | 1724 | |------------------->| 1725 dialog3 | NOTIFY (200 OK) | | 1726 |<-------------------| | 1727 dialog3 | 200 OK | | 1728 |------------------->| | 1729 dialog1 | BYE/200 OK | | 1730 |------------------->| | 1731 dialog4 | | BYE/200 OK | 1732 | |<-------------------| 1734 Figure 15. Attended Transfer Fallback to Basic Transfer. 1736 8. Transfer with Referred-By 1738 In the previous examples, the Transfer Target does not have 1739 definitive information about what party initiated the transfer, or, 1740 in some cases, even that transfer is taking place. The Referred-By 1741 mechanism [RFC3892] provides a way for the Transferor to provide the 1742 Transferee with a way to let the Transfer Target know what party 1743 initiated the transfer. 1745 The simplest and least secure approach just involves the inclusion of 1746 the Referred-By header field in the REFER which is then copied into 1747 the triggered INVITE. However, a more secure mechanism involving the 1748 Referred-By security token which is generated and signed by the 1749 Transferor and passed in a message body to the Transferee then to the 1750 Transfer Target. 1752 The call flow is shown in Figure 16 showing the Referred-By header 1753 field and body in the REFER F5 and triggered INVITE F6. Note that 1754 the S/MIME signature is not shown in the example below. The 1755 conventions used in the SIP Torture Test Messages [RFC4475] document 1756 are reused, specifically the and tags. 1758 Transferor Transferee Transfer 1759 | | Target 1760 | | | 1761 dialog1 | INVITE/200 OK/ACK F1 F2 | 1762 |<-------------------| | 1763 dialog1 | INVITE (hold)/200 OK/ACK | 1764 |------------------->| | 1765 dialog2 | INVITE/200 OK/ACK F3 F4 | 1766 |---------------------------------------->| 1767 dialog2 | INVITE (hold)/200 OK/ACK | 1768 |---------------------------------------->| 1769 dialog3 | REFER (Target-Dialog:1, Referred-By:Transferor, 1770 | Refer-To:sips:TransferTarget?Replaces=2) F5 1771 |------------------->| | 1772 dialog3 | 202 Accepted | | 1773 |<-------------------| | 1774 dialog3 | NOTIFY (100 Trying)| | 1775 |<-------------------| | 1776 dialog3 | 200 OK | | 1777 |------------------->| | 1778 dialog4 | INVITE (Replaces:dialog2, | 1779 | Referred-By:Transferor )/200 OK/ACK F6 1780 | |------------------->| 1781 dialog2 | BYE/200 OK | | 1782 |<----------------------------------------| 1783 dialog3 | NOTIFY (200 OK) | | 1784 |<-------------------| | 1785 dialog3 | 200 OK | | 1786 |------------------->| | 1787 dialog1 | BYE/200 OK | | 1788 |------------------->| | 1789 dialog4 | | BYE/200 OK | 1790 | |<-------------------| 1792 Figure 16. Attended Transfer Call Flow with Referred-By. 1794 F5 REFER Transferor -> Transferee 1796 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 1797 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK392039842 1798 Max-Forwards: 70 1799 To: 1800 From: ;tag=1928301774 1801 Call-ID: a84b4c76e66710 1802 CSeq: 314160 REFER 1803 1804 Refer-To: 1807 1808 Supported: gruu, replaces, tdialog 1809 Require: tdialog 1810 Referred-By: 1811 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1812 Target-Dialog: 592435881734450904;local-tag=9m2n3wq;remote-tag=763231 1813 Contact: 1814 Content-Type: multipart/mixed; boundary=unique-boundary-1 1815 Content-Length: ... 1817 --unique-boundary-1 1818 Content-ID: <20398823.2UWQFN309shb3@atlanta.example.com> 1820 Content-Length: 2961 1821 Content-Type: multipart/signed; 1822 protocol="application/pkcs-7-signature"; 1823 micalg=sha1; 1824 boundary="----590F24D439B31E08745DEF0CD9397189" 1826 ------590F24D439B31E08745DEF0CD9397189 1827 Content-Type: message/sipfrag 1829 Date: Thu, 18 Sep 2003 13:07:43 GMT 1830 1831 Refer-To: 1834 1835 Referred-By: 1836 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1838 ------590F24D439B31E08745DEF0CD9397189 1839 Content-Type: application/pkcs-7-signature; name="smime.p7s" 1840 Content-Transfer-Encoding: binary 1841 Content-Disposition: attachment; filename="smime.p7s" 1843 3082088806092A86 1844 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 1846 . . . (Signature not shown) 1848 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 1849 79089AAD95767F 1851 ------590F24D439B31E08745DEF0CD9397189-- 1853 --unique_boundary-1 1855 F6 INVITE Transferee -> Transfer Target 1857 INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 1858 Via: SIP/2.0/TLS referee.example;branch=z9hG4bKffe209934aac 1859 To: 1860 From: ;tag=2909034023 1861 Call-ID: fe9023940-a3465@referee.example 1862 CSeq: 889823409 INVITE 1863 Max-Forwards: 70 1864 Contact: 1865 Referred-By: 1866 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1867 Replaces:090459243588173445;to-tag=9m2n3wq;from- 1868 tag=76323 1869 Require: replaces 1870 Supported: gruu, replaces, tdialog 1871 Content-Type: multipart/mixed; boundary=my-boundary-9 1872 Content-Length: ... 1874 --my-boundary-9 1875 Content-Type: application/sdp 1877 Content-Length: 156 1879 v=0 1880 o=referee 2890844526 2890844526 IN IP4 referee.example 1881 s=Session SDP 1882 c=IN IP4 referee.example 1883 t=0 0 1884 m=audio 49172 RTP/AVP 0 1885 a=rtpmap:0 PCMU/8000 1886 --my-boundary-9 1887 Content-Length: 2961 1888 Content-Type: multipart/signed; 1889 protocol="application/pkcs-7-signature"; 1890 micalg=sha1; 1891 boundary="----590F24D439B31E08745DEF0CD9397189" 1893 ------590F24D439B31E08745DEF0CD9397189 1894 Content-Type: message/sipfrag 1896 Date: Thu, 18 Sep 2003 13:07:43 GMT 1898 1899 Refer-To: 1902 1903 Referred-By: 1904 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1906 ------590F24D439B31E08745DEF0CD9397189 1907 Content-Type: application/pkcs-7-signature; name="smime.p7s" 1908 Content-Transfer-Encoding: binary 1909 Content-Disposition: attachment; filename="smime.p7s" 1911 3082088806092A86 1912 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 1914 . . . (Signature not shown) 1916 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 1917 79089AAD95767F 1919 ------590F24D439B31E08745DEF0CD9397189-- 1921 --my-boundary-9-- 1923 9. Transfer as an Ad-Hoc Conference 1925 In this flow, shown in Figure 17, Bob does an attended transfer of 1926 Alice to Carol. In order to keep both Alice and Carol fully informed 1927 of the nature and state of the transfer operation, Bob acts as a 1928 focus[RFC4579] and hosts an ad-hoc conference involving Alice, Bob, 1929 and Carol. Alice and Carol subscribe to the conference 1930 package[RFC4575] of Bob's focus, which allows them to know the exact 1931 status of the operation. After the transfer operation is complete, 1932 Bob deletes the conference. 1934 This call flow meets requirement 6 of Section 3. NOTIFY messages 1935 related to the refer package are indicated as NOTIFY (refer), while 1936 NOTIFYs related to the Conference Info package are indicated as 1937 NOTIFY (Conf-Info). 1939 Note that any type of semi-attended transfer in which media mixing or 1940 relaying could be implemented using this model. In addition to 1941 simply mixing, the focus could introduce additional media signals 1942 such as simulated ring tone or on hold announcements to improve the 1943 user experience. 1945 Alice Bob Carol 1946 | | | 1947 | INVITE | | 1948 |------------------->| | 1949 | 180 Ringing | | 1950 |<-------------------| | 1951 | 200 OK | | 1952 |<-------------------| | 1953 | ACK | | 1954 |------------------->| | 1955 | RTP | | 1956 |<==================>| | 1957 | | | 1958 Bob places Alice on hold and begins acting like a focus 1959 | | | 1960 | INVITE (hold) Contact:Conf-ID;isfocus | 1961 |<-------------------| | 1962 | 200 OK | | 1963 |------------------->| | 1964 | ACK | | 1965 |<-------------------| | 1966 | | | 1967 | Alice subscribes to the conference package 1968 | | | 1969 | SUBSCRIBE sip:Conf-ID | 1970 |------------------->| | 1971 | 200 OK | | 1972 |<-------------------| | 1973 | NOTIFY (Conf-Info) | | 1974 |<-------------------| | 1975 | 200 OK | | 1976 |------------------->| | 1977 | | | 1978 | Bob begins consultation operation | 1979 | | | 1980 |INVITE Require:replaces Contact:Conf-ID;isfocus 1981 | |------------------->| 1982 | | 180 Ringing | 1983 | |<-------------------| 1984 | | 200 OK | 1985 | |<-------------------| 1986 | | ACK | 1987 | |------------------->| 1988 | | RTP | 1989 | |<==================>| 1990 | | | 1991 |Carol subscribes to the conference package 1992 | - learns Bob is on hold | 1993 | | | 1994 | |SUBSCRIBE sip:Conf-ID 1995 | |<-------------------| 1996 | | 200 OK | 1997 | |------------------->| 1998 | | NOTIFY (Conf-Info) | 1999 | |------------------->| 2000 | | 200 OK | 2001 | |<-------------------| 2002 | | | 2003 | Alice learns that Bob is talking to Carol 2004 | | | 2005 | NOTIFY (Conf-Info) | | 2006 |<-------------------| | 2007 | 200 OK | | 2008 |------------------->| | 2009 | | INVITE (hold) | 2010 | |------------------->| 2011 | | 200 OK | 2012 | |<-------------------| 2013 | | ACK | 2014 | |------------------->| 2015 | | | 2016 | Alice learns that Carol is now on hold | 2017 | | | 2018 | NOTIFY (Conf-Info) | | 2019 |<-------------------| | 2020 | 200 OK | | 2021 |------------------->| | 2022 | | | 2023 | Bob begins transfer operation | 2024 | | | 2025 | REFER Refer-To: Carol | 2026 |<-------------------| | 2027 | 202 Accepted | | 2028 |------------------->| | 2029 | NOTIFY (Refer) | | 2030 |------------------->| | 2031 | 200 OK | | 2032 |<-------------------| | 2033 | INVITE Replaces:B-C Contact:Alice | 2034 |---------------------------------------->| 2035 | 200 OK | 2036 |<----------------------------------------| 2037 | ACK | 2038 |---------------------------------------->| 2039 | RTP | 2040 |<=======================================>| 2041 | | BYE | 2042 | |<-------------------| 2043 | | 200 OK | 2044 | |------------------->| 2045 | NOTIFY (Refer) | | 2046 |------------------->| | 2047 | 200 OK | | 2048 |<-------------------| | 2049 | | | 2050 | Bob terminates the ad-hoc conference | 2051 | | | 2052 | BYE | | 2053 |<-------------------| | 2054 | 200 OK | | 2055 |------------------->| | 2056 | | NOTIFY (Conf-Info) | 2057 | |------------------->| 2058 | | 200 OK | 2059 | |<-------------------| 2060 | NOTIFY (Conf-Info) | | 2061 |<-------------------| | 2062 | 200 OK | | 2063 |------------------->| | 2065 Figure 17. Attended Transfer as an Ad-Hoc Conference. 2067 10. Transfer with multiple parties 2069 In this example shown in Figure 18, the Originator places call to the 2070 Facilitator who reaches the Recipient through the Screener. The 2071 Recipient's contact information is exposed to the Facilitator and the 2072 Originator. This example is provided for clarification of the 2073 semantics of the REFER method only and should not be used as the 2074 design of an implementation. 2076 Originator Facilitator Screener Recipient 2077 | | | | 2078 1 |INVITE/200 OK/ACK | |"Get Fred for me!" 2079 |----------->| | | "Right away!" 2080 2 |INVITE (hold)/200 OK/ACK | | 2081 |<-----------| | | 2082 2 | |INVITE/200 OK/ACK |"I have a call 2083 | |----------->| |from Mary for Fred" 2084 2 | |INVITE (hold)/200 OK/ACK "Hold please" 2085 | |<-----------| | 2086 3 | | |INVITE/200 OK/ACK 2087 | | |--------->|"You have a call 2088 | | | |from Mary" 2089 | | | | "Put her through" 2090 3 | | |INVITE (hold)/200 OK/ACK 2091 | | |--------->| 2092 4 | |REFER | | 2093 | |<-----------| | 2094 4 | |202 Accepted| | 2095 | |----------->| | 2096 4 | |NOTIFY (100 Trying) | 2097 | |----------->| | 2098 4 | |200 OK | | 2099 | |<-----------| | 2100 5 | |INVITE/200 OK/ACK | 2101 | |---------------------->|"This is Fred" 2102 4 | |NOTIFY (200 OK) | "Please hold for 2103 | |----------->| | Mary" 2104 4 | |200 OK | | 2105 | |<-----------| | 2106 2 | |BYE/200 OK | | 2107 | |<-----------| | 2108 3 | | |BYE/200 OK| 2109 | | |--------->| 2110 5 | |INVITE (hold)/200 OK/ACK 2111 | |---------------------->| 2112 6 |REFER | | | 2113 |<-----------| | | 2114 6 |202 Accepted| | | 2115 |----------->| | | 2116 6 |NOTIFY (100 Trying) | | 2117 |----------->| | | 2118 6 |200 OK | | | 2119 |<-----------| | | 2120 7 |INVITE/200 OK/ACK | | 2121 |----------------------------------->| "Hey Fred" 2122 6 |NOTIFY (200 OK) | | "Hello Mary" 2123 |----------->| | | 2124 6 |200 OK | | | 2125 |<-----------| | | 2126 1 |BYE/200 OK | | | 2127 |<-----------| | | 2128 5 | |BYE/200 OK | | 2129 | |---------------------->| 2130 7 |BYE/200 OK | | | 2131 |<-----------------------------------| "See you later" 2133 Figure 18. Transfer with Multiple Parties Example. 2135 11. Gateway Transfer Issues 2137 A gateway in SIP acts as a User Agent. As a result, the entire 2138 preceding discussion and call flows apply equally well to gateways as 2139 native SIP endpoints. However, there are some gateway specific 2140 issues that are documented in this section. While this discussion 2141 focuses on the common cases involving PSTN gateways, similar 2142 situations exist for other gateways, such as H.323/SIP gateways. 2144 11.1. Coerce Gateway Hairpins to the Same Gateway 2146 To illustrate how a hairpin situation can occur in transfer, consider 2147 this example. The original call dialog is setup with the transferee 2148 residing on the PSTN side of a SIP gateway. The transferor is a SIP 2149 phone purely in the IP space. The transfer target is on the PSTN 2150 side of a SIP gateway as well. After completing the transfer, 2151 (regardless of consultative or blind) the transferee is in a call 2152 with the transfer target (both on the PSTN side of a gateway). It is 2153 often desirable to remove the gateway(s) out of the loop. This is 2154 likely to only be possible if both legs of the target call are on the 2155 same gateway. With both legs on the same gateway, it may be able to 2156 invoke the analogous transfer on the PSTN side. Then the target call 2157 would not involve the gateway. 2159 So the problem is how to give the proxy enough information so that it 2160 knows to route the call to the same gateway. With a simple single 2161 call that hairpins, the incoming and outgoing leg have the same 2162 dialog. The proxy should have enough information to optimize the 2163 routing. 2165 In the consultative transfer scenario, it is desirable to coerce the 2166 consultative INVITE out the same gateway as the original call to be 2167 transferred. However there is no way to relate the consultation with 2168 the original call. In the consultative case the target call INVITE 2169 includes the Replaces header which contains dialog information that 2170 can be used to relate it to the consultation. However there is no 2171 information that relates the target call to the original. 2173 In the blind transfer scenario, it is desirable to coerce the target 2174 call onto the same gateway as the original call. However the same 2175 problem exists in that the target dialog cannot be related to the 2176 original dialog. 2178 In either transfer scenario, it may be desirable to push the transfer 2179 operation onto the non-SIP side of the gateway. Presumably this is 2180 not possible unless all of the legs go out the same gateway. If the 2181 gateway supports more than one truck group, it might also be 2182 necessary to get all of the legs on the same trunk group in order to 2183 perform the transfer on the non-SIP side of the gateway. 2185 Solutions to these gateway specific issues may involve new extensions 2186 to SIP in the future. 2188 11.2. Consultative Turned Blind Gateway Glare 2190 In the consultative transfer case turned blind, there is a glare-like 2191 problem. The transferor initiates the consultation INVITE, the 2192 transferor gets impatient and hangs up, transitioning this to a blind 2193 transfer. The transfer target on the gateway (connected through a 2194 PSTN switch to a single line or dumb analog phone) rings. The user 2195 answers the phone just after the CANCEL is received by the transfer 2196 target. The REFER and INVITE for the target call are sent. The 2197 transferee attempts to setup the call on the PSTN side, but gets 2198 either a busy or lands in the users voicemail as the user has the 2199 handset in hand and off hook. 2201 This is another example of a race condition that this call flow can 2202 cause. The recommended behavior is to use the approach described in 2203 Section 6.6. 2205 12. IANA Considerations 2207 None. 2209 13. Security Considerations 2211 The call transfer flows shown in this document are implemented using 2212 the REFER and Replaces call control primitives in SIP. As such, the 2213 security considerations detailed in the REFER [RFC3515] and Replaces 2214 [RFC3891] documents MUST be followed, which are briefly summarized in 2215 the following paragraphs. This document addresses the issue of 2216 protecting the Address of Record URI of a transfer target in Sections 2217 7.1 and 7.2. 2219 Any REFER request MUST be appropriately authenticated and authorized 2220 using standard SIP mechanisms or calls may be hijacked. A user agent 2221 may use local policy or human intervention in deciding whether or not 2222 to accept a REFER. In generating NOTIFY responses based on the 2223 outcome of the triggered request, care should be taken in 2224 constructing the message/sipfrag body to ensure that no private 2225 information is leaked. 2227 An INVITE containing a Replaces header field SHOULD only be accepted 2228 if it has been properly authenticated and authorized using standard 2229 SIP mechanisms, and the requestor is authorized to perform dialog 2230 replacement. Special care is needed if the replaced dialog utilizes 2231 additional media streams compared to the original dialog. In this 2232 case, the user MUST authorize the addition of new media streams in a 2233 dialog replacement. For example, the same mechanism used to 2234 authorize the addition of a media stream in a re-INVITE could be 2235 used. 2237 14. Acknowledgments 2239 This draft is a collaborative product of the SIP working group. 2240 Thanks to Rohan Mahy for his input on the use of Replaces in 2241 transfer. 2243 15. References 2245 15.1. Normative References 2247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2248 Requirement Levels", BCP 14, RFC 2119, March 1997. 2250 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2251 A., Peterson, J., Sparks, R., Handley, M., and E. 2252 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2253 June 2002. 2255 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2256 Method", RFC 3515, April 2003. 2258 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 2259 Protocol (SIP) "Replaces" Header", RFC 3891, 2260 September 2004. 2262 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 2263 Referred-By Mechanism", RFC 3892, September 2004. 2265 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 2266 Identification in the Session Initiation Protocol (SIP)", 2267 RFC 4538, June 2006. 2269 15.2. Informative References 2271 [I-D.ietf-sipping-cc-framework] 2272 Mahy, R., Sparks, R., Rosenberg, J., Petrie, D., and A. 2273 Johnston, "A Call Control and Multi-party usage framework 2274 for the Session Initiation Protocol (SIP)", 2275 draft-ietf-sipping-cc-framework-10 (work in progress), 2276 April 2008. 2278 [I-D.ietf-sip-gruu] 2279 Rosenberg, J., "Obtaining and Using Globally Routable User 2280 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 2281 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 2282 October 2007. 2284 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 2285 and H. Schulzrinne, "Session Initiation Protocol (SIP) 2286 Torture Test Messages", RFC 4475, May 2006. 2288 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 2289 Session Initiation Protocol (SIP)", RFC 4353, 2290 February 2006. 2292 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 2293 (SIP) Call Control - Conferencing for User Agents", 2294 BCP 119, RFC 4579, August 2006. 2296 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 2297 Initiation Protocol (SIP) Event Package for Conference 2298 State", RFC 4575, August 2006. 2300 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 2301 Initiation Protocol", RFC 5057, November 2007. 2303 Authors' Addresses 2305 Robert J. Sparks 2306 Estacado Systems 2308 Email: RjS@estacado.net 2310 Alan Johnston (editor) 2311 Avaya 2312 St. Louis, MO 2314 Email: alan@sipstation.com 2316 Daniel Petrie 2317 SIPez LLC 2318 34 Robbins Rd. 2319 Arlington, MA 02476 2320 US 2322 Phone: +1 617 273 4000 2323 Email: dan.ietf AT SIPez DOT com 2324 URI: http://www.SIPez.com/