idnits 2.17.1 draft-ietf-sipping-cc-transfer-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2430. 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 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 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 (September 3, 2008) is 5713 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 (==), 8 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: March 7, 2009 Avaya 6 D. Petrie 7 SIPez LLC 8 September 3, 2008 10 Session Initiation Protocol Call Control - Transfer 11 draft-ietf-sipping-cc-transfer-10 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 7, 2009. 38 Abstract 40 This document describes providing Call Transfer capabilities in the 41 Session Initiation Protocol (SIP). SIP extensions such as REFER and 42 Replaces are used to provide a number of transfer services including 43 blind transfer, consultative transfer, and attended transfer. This 44 work is part of the SIP multiparty call control framework. 46 Table of Contents 48 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Actors and Roles . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 5. Using REFER to achieve Call Transfer . . . . . . . . . . . . . 5 53 6. Basic Transfer . . . . . . . . . . . . . . . . . . . . . . . . 6 54 6.1. Successful Transfer . . . . . . . . . . . . . . . . . . . 7 55 6.2. Transfer with Dialog Reuse . . . . . . . . . . . . . . . . 11 56 6.3. Failed Transfer . . . . . . . . . . . . . . . . . . . . . 15 57 6.3.1. Target Busy . . . . . . . . . . . . . . . . . . . . . 15 58 6.3.2. Transfer Target does not answer . . . . . . . . . . . 17 59 7. Transfer with Consultation Hold . . . . . . . . . . . . . . . 18 60 7.1. Exposing transfer target . . . . . . . . . . . . . . . . . 18 61 7.2. Protecting transfer target . . . . . . . . . . . . . . . . 19 62 7.3. Attended Transfer . . . . . . . . . . . . . . . . . . . . 24 63 7.4. Recovery when one party does not support REFER . . . . . . 27 64 7.5. Attended transfer when Contact URI is not known to 65 route to a unique user agent. . . . . . . . . . . . . . . 28 66 7.6. Semi-Attended Transfer . . . . . . . . . . . . . . . . . . 35 67 7.7. Attended Transfer Fallback to Basic Transfer . . . . . . . 40 68 8. Transfer with Referred-By . . . . . . . . . . . . . . . . . . 42 69 9. Transfer as an Ad-Hoc Conference . . . . . . . . . . . . . . . 48 70 10. Transfer with multiple parties . . . . . . . . . . . . . . . . 51 71 11. Gateway Transfer Issues . . . . . . . . . . . . . . . . . . . 53 72 11.1. Coerce Gateway Hairpins to the Same Gateway . . . . . . . 53 73 11.2. Consultative Turned Blind Gateway Glare . . . . . . . . . 54 74 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 75 13. Security Considerations . . . . . . . . . . . . . . . . . . . 54 76 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 77 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 78 15.1. Normative References . . . . . . . . . . . . . . . . . . . 55 79 15.2. Informative References . . . . . . . . . . . . . . . . . . 56 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 81 Intellectual Property and Copyright Statements . . . . . . . . . . 58 83 1. Overview 85 This document describes providing Call Transfer capabilities and 86 requirements in SIP [RFC3261]. This work is part of the Multiparty 87 Call Control Framework [I-D.ietf-sipping-cc-framework]. 89 The mechanisms discussed here are most closely related to traditional 90 basic and consultation hold transfers. 92 This document details the use of REFER method [RFC3515] and Replaces 93 [RFC3891] header field to achieve call transfer. 95 A user agent that fully supports the transfer mechanisms described in 96 this document supports REFER[RFC3515] and Replaces[RFC3891] in 97 addition to RFC 3261 [RFC3261]. A user agent should use a Contact 98 URI which meets the requirements in Section 8.1.1.8 of RFC 3261. A 99 compliant user agent supports the Target-Dialog header field 100 [RFC4538]. 102 2. Actors and Roles 104 There are three actors in a given transfer event, each playing one of 105 the following roles: 107 Transferee - the party being transferred to the Transfer 108 Target. 110 Transferor - the party initiating the transfer 112 Transfer Target - the new party being introduced into a 113 call with the Transferee. 115 The following roles are used to describe transfer requirements and 116 scenarios: 118 Originator - wishes to place a call to the Recipient. This 119 actor is the source of the first INVITE in a 120 session, to either a Facilitator or a Screener. 122 Facilitator - receives a call or out-of-band request from the 123 Originator, establishes a call to the Recipient 124 through the Screener, and connects the 125 Originator to the Recipient. Typically, a Facilitator 126 acts on behalf of the Originator. 128 Screener - receives a call ultimately intended for the 129 Recipient and transfers the calling party to 130 the Recipient if appropriate. Typically, a Screener 131 acts on behalf of the Recipient. 133 Recipient - the party the Originator is ultimately 134 connected to. 136 3. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in BCP 14, RFC 2119 141 [RFC2119]. 143 4. Requirements 145 1. Any party in a SIP session MUST be able to transfer any other 146 party in that session at any point in that session. 147 2. The Transferor and the Transferee MUST NOT be removed from a 148 session as part of a transfer transaction. 150 At first glance, requirement 2 may seem to indicate 151 that the user experience in a transfer must be 152 significantly different from what a current PBX or 153 Centrex user expects. As the call-flows in this 154 document show, this is not the case. A client MAY 155 preserve the current experience. In fact, without 156 this requirement, some forms of the current 157 experience (ringback on transfer failure 158 for instance) will be lost. 160 3. The Transferor MUST know whether or not the transfer was 161 successful. 163 4. The Transferee MUST be able to replace an existing dialog with a 164 new dialog. 165 5. The Transferor and Transferee SHOULD indicate their support for 166 the primitives required to achieve transfer. 167 6. The Transferor SHOULD provide the Transfer Target and Transferee 168 with information about the nature and progress of the transfer 169 operation being attempted. 171 To meet this requirement, the transfer operation can 172 be modeled as an ad-hoc conference between three 173 parties, as discussed in Section 8. 175 5. Using REFER to achieve Call Transfer 177 A REFER [RFC3515] can be issued by the Transferor to cause the 178 Transferee to issue an INVITE to the Transfer-Target. Note that a 179 successful REFER transaction does not terminate the session between 180 the Transferor and the Transferee. If those parties wish to 181 terminate their session, they must do so with a subsequent BYE 182 request. The media negotiated between the transferee and the 183 transfer target is not affected by the media that had been negotiated 184 between the transferor and the transferee. In particular, the INVITE 185 issued by the Transferee will have the same SDP body it would have if 186 he Transferee had initiated that INVITE on its own. Further, the 187 disposition of the media streams between the Transferor and the 188 Transferee is not altered by the REFER method. 190 Agents may alter a session's media through additional signaling. For 191 example, they may make use of the SIP hold re-INVITE [RFC3261] or 192 conferencing extensions described in the conferencing framework 193 [RFC4353]. 195 To perform the transfer, the transferor and transferee could reuse an 196 existing dialog established by an INVITE to send the REFER. This 197 would result in a single dialog shared by two uses - an invite usage 198 and a subscription usage. The call flows for this are shown in 199 detail in Section 6.2. However, the approach described in this 200 document is to avoid dialog reuse. The issues and difficulties 201 associated with dialog reuse are described in 202 [I-D.ietf-sipping-dialogusage]. 204 Motivations for reusing the existing dialog include: 205 1. There was no way to ensure that a REFER on a new dialog would 206 reach the particular endpoint involved in a transfer. Many 207 factors, including details of implementations and changes in 208 proxy routing between an INVITE and a REFER could cause the REFER 209 to be sent to the wrong place. Sending the REFER down the 210 existing dialog ensured it got to the endpoint we were already 211 talking to. 212 2. It was unclear how to associate an existing invite usage with a 213 REFER arriving on a new dialog, where it was completely obvious 214 what the association was when the REFER came on the invite 215 usage's dialog. 216 3. There were concerns with authorizing out-of-dialog REFERs. The 217 authorization policy for REFER in most implementations piggybacks 218 on the authorization policy for INVITE (which is, in most cases, 219 based simply on "I placed or answered this call"). 221 GRUUs [I-D.ietf-sip-gruu] can be used to address problem 1. Problem 222 2 can be addressed using the Target-Dialog header field defined in 223 [RFC4538]. In the immediate term, this solution to problem 2 allows 224 the existing REFER authorization policy to be reused. 226 As a result, if the Transferee supports the target-dialog extension 227 and the Transferor knows the Contact URI is routable outside the 228 dialog, the REFER SHOULD be sent in a new dialog. If the nature of 229 the Contact URI is not known or if support for the target-dialog 230 extension is not known, the REFER should be sent inside the existing 231 dialog. A Transferee must be prepared to receive a REFER either 232 inside or outside a dialog. One way that a Transferor could know 233 that a Contact URI is routable outside a dialog is by validation 234 (e.g. sending an OPTIONS and receiving a response) or if it satisfies 235 the properties described in the GRUU specification 236 [I-D.ietf-sip-gruu]. 238 In most of the following examples, the Transferor is in the 239 atlanta.example.com domain, the Transferee is in the 240 biloxi.example.com, and the Transfer Target is in the 241 chicago.example.com domain. 243 6. Basic Transfer 245 Basic Transfer consists of the Transferor providing the Transfer 246 Target's contact to the Transferee. The Transferee attempts to 247 establish a session using that contact and reports the results of 248 that attempt to the Transferor. The signaling relationship between 249 the Transferor and Transferee is not terminated, so the call is 250 recoverable if the Transfer Target cannot be reached. Note that the 251 Transfer Target's contact information has been exposed to the 252 Transferee. The provided contact can be used to make new calls in 253 the future. 255 The participants in a basic transfer should indicate support for the 256 REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to 257 INVITE, and OPTIONS messages. Participants should also indicate 258 support for Target-Dialog in the Supported header field. 260 The diagrams below show the first line of each message. The first 261 column of the figure shows the dialog used in that particular 262 message. In these diagrams, media is managed through re-INVITE 263 holds, but other mechanisms (mixing multiple media streams at the UA 264 or using the conferencing extensions for example) are valid. 265 Selected message details are shown labeled as message F1, F2, etc. 267 Each of the flows below shows the dialog between the Transferor and 268 the Transferee remaining connected (on hold) during the REFER 269 process. While this provides the greatest flexibility for recovery 270 from failure, it is not necessary. If the Transferor's agent does 271 not wish to participate in the remainder of the REFER process and has 272 no intention of assisting with recovery from transfer failure, it 273 could emit a BYE to the Transferee as soon as the REFER transaction 274 completes. This flow is sometimes known as "unattended transfer" or 275 "blind transfer". 277 Figure 1 shows transfer when the Transferee utilizes a GRUU and 278 supports the target-dialog extension and indicates this to the 279 Transferor. As a result, the Transferor sends the REFER outside the 280 INVITE dialog. The Transferee is able to match this REFER to the 281 existing dialog using the Target-Dialog header field in the refer 282 which references the existing dialog. 284 6.1. Successful Transfer 285 Transferor Transferee Transfer 286 | | Target 287 | INVITE F1 | | 288 dialog1 |<-------------------| | 289 | 200 OK F2 | | 290 dialog1 |------------------->| | 291 | ACK | | 292 dialog1 |<-------------------| | 293 | INVITE (hold) | | 294 dialog1 |------------------->| | 295 | 200 OK | | 296 dialog1 |<-------------------| | 297 | ACK | | 298 dialog1 |------------------->| | 299 | REFER F3 (Target-Dialog:1) | 300 dialog2 |------------------->| | 301 | 202 Accepted | | 302 dialog2 |<-------------------| | 303 | NOTIFY (100 Trying) F4 | 304 dialog2 |<-------------------| | 305 | 200 OK | | 306 dialog2 |------------------->| | 307 | | INVITE F5 | 308 dialog3 | |------------------->| 309 | | 200 OK | 310 dialog3 | |<-------------------| 311 | | ACK | 312 dialog3 | |------------------->| 313 | NOTIFY (200 OK) F6| | 314 dialog2 |<-------------------| | 315 | 200 OK | | 316 dialog2 |------------------->| | 317 | BYE | | 318 dialog1 |------------------->| | 319 | 200 OK | | 320 dialog1 |<-------------------| | 321 | | BYE | 322 dialog3 | |<-------------------| 323 | | 200 OK | 324 dialog3 | |------------------->| 326 Figure 1. Basic Transfer Call Flow. 328 F1 INVITE Transferee -> Transferor 330 INVITE sips:transferor@atlanta.example.com SIP/2.0 331 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 332 Max-Forwards: 70 333 To: 334 From: ;tag=7553452 335 Call-ID: 090459243588173445 336 CSeq: 29887 INVITE 337 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 338 Supported: replaces, gruu, tdialog 339 Contact: 340 Content-Type: application/sdp 341 Content-Length: ... 343 F2 200 OK Transferor -> Transferee 345 SIP/2.0 200 OK 346 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 347 To: ;tag=31kdl4i3k 348 From: ;tag=7553452 349 Call-ID: 090459243588173445 350 CSeq: 29887 INVITE 351 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 352 Supported: replaces, gruu, tdialog 353 Contact: 354 Content-Type: application/sdp 355 Content-Length: ... 357 F3 REFER Transferor -> Transferee 359 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 360 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9 361 Max-Forwards: 70 362 To: 363 From: ;tag=1928301774 364 Call-ID: a84b4c76e66710 365 CSeq: 314159 REFER 366 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 367 Supported: gruu, replaces, tdialog 368 Require: tdialog 369 Refer-To: 370 Target-Dialog: 090459243588173445;local-tag=7553452 371 ;remote-tag=31kdl4i3k 372 Contact: 373 Content-Length: 0 375 F4 NOTIFY Transferee -> Transferor 376 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 377 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 378 Max-Forwards: 70 379 To: ;tag=1928301774 380 From: 381 ;tag=a6c85cf 382 Call-ID: a84b4c76e66710 383 CSeq: 73 NOTIFY 384 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 385 Supported: replaces, tdialog 386 Event: refer 387 Subscription-State: active;expires=60 388 Content-Type: message/sipfrag 389 Content-Length: ... 391 SIP/2.0 100 Trying 393 F5 INVITE Transferee -> Transfer Target 395 INVITE sips:transfertarget@chicago.example.com SIP/2.0 396 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234 397 Max-Forwards: 70 398 To: 399 From: ;tag=j3kso3iqhq 400 Call-ID: 90422f3sd23m4g56832034 401 CSeq: 521 REFER 402 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 403 Supported: replaces, gruu, tdialog 404 Contact: 405 Content-Type: application/sdp 406 Content-Length: ... 408 F6 NOTIFY Transferee -> Transferor 410 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 411 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 412 Max-Forwards: 70 413 To: ;tag=1928301774 414 From: 415 ;tag=a6c85cf 416 Call-ID: a84b4c76e66710 417 CSeq: 74 NOTIFY 418 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 419 Supported: replaces, tdialog 420 Event: refer 421 Subscription-State: terminated;reason=noresource 422 Content-Type: message/sipfrag 423 Content-Length: ... 425 SIP/2.0 200 OK 427 6.2. Transfer with Dialog Reuse 429 In this scenario, the Transferor does not know the properties of the 430 Transferee's Contact URI or does not know that the Transferee 431 supports the Target-Dialog header field. As a result, the REFER is 432 sent inside the INVITE dialog. 434 Transferor Transferee Transfer 435 | | Target 436 | INVITE F1 | | 437 dialog1 |<-------------------| | 438 | 200 OK F2 | | 439 dialog1 |------------------->| | 440 | ACK | | 441 dialog1 |<-------------------| | 442 | INVITE (hold) | | 443 dialog1 |------------------->| | 444 | 200 OK | | 445 dialog1 |<-------------------| | 446 | ACK | | 447 dialog1 |------------------->| | 448 | REFER F3 | | 449 dialog1 |------------------->| | 450 | 202 Accepted | | 451 dialog1 |<-------------------| | 452 | NOTIFY (100 Trying) F4 | 453 dialog1 |<-------------------| | 454 | 200 OK | | 455 dialog1 |------------------->| | 456 | | INVITE F5 | 457 dialog2 | |------------------->| 458 | | 200 OK | 459 dialog2 | |<-------------------| 460 | | ACK | 461 dialog2 | |------------------->| 462 | NOTIFY (200 OK) F6| | 463 dialog1 |<-------------------| | 464 | 200 OK | | 465 dialog1 |------------------->| | 466 | BYE | | 467 dialog1 |------------------->| | 468 | 200 OK | | 469 dialog1 |<-------------------| | 470 | | BYE | 471 dialog2 | |<-------------------| 472 | | 200 OK | 473 dialog2 | |------------------->| 475 Figure 2. Transfer with Dialog Reuse. 477 F1 INVITE Transferee -> Transferor 479 INVITE sips:transferor@atlanta.example.com SIP/2.0 480 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 481 Max-Forwards: 70 482 To: 483 From: ;tag=7553452 484 Call-ID: 090459243588173445 485 CSeq: 29887 INVITE 486 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 487 Supported: replaces 488 Contact: 489 Content-Type: application/sdp 490 Content-Length: ... 492 F2 200 OK Transferor -> Transferee 494 SIP/2.0 200 OK 495 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 496 To: ;tag=31kdl4i3k 497 From: ;tag=7553452 498 Call-ID: 090459243588173445 499 CSeq: 29887 INVITE 500 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 501 Supported: gruu, replaces 502 Contact: 503 Content-Type: application/sdp 504 Content-Length: ... 506 F3 REFER Transferor -> Transferee 508 REFER sips:transferee@192.0.2.4 SIP/2.0 509 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9 510 Max-Forwards: 70 511 To: ;tag=7553452 512 From: ;tag=31kdl4i3k 513 Call-ID: 090459243588173445 514 CSeq: 314159 REFER 515 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 516 Supported: replaces 517 Refer-To: 518 Contact: 519 Content-Length: 0 521 F4 NOTIFY Transferee -> Transferor 523 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 524 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 525 Max-Forwards: 70 526 To: ;tag=31kdl4i3k 527 From: ;tag=7553452 528 Call-ID: 090459243588173445 529 CSeq: 29888 INVITE 530 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 531 Supported: replaces 532 Event: refer 533 Subscription-State: active;expires=60 534 Content-Type: message/sipfrag 535 Content-Length: ... 537 SIP/2.0 100 Trying 539 F5 INVITE Transferee -> Transfer Target 541 INVITE sips:transfertarget@chicago.example.com SIP/2.0 542 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234 543 Max-Forwards: 70 544 To: 545 From: ;tag=j3kso3iqhq 546 Call-ID: 90422f3sd23m4g56832034 547 CSeq: 521 REFER 548 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 549 Supported: replaces 550 Contact: 551 Content-Type: application/sdp 552 Content-Length: ... 554 F6 NOTIFY Transferee -> Transferor 556 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 557 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 558 Max-Forwards: 70 559 To: ;tag=31kdl4i3k 560 From: ;tag=7553452 561 Call-ID: 090459243588173445 562 CSeq: 29889 INVITE 563 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 564 Supported: replaces 565 Event: refer 566 Subscription-State: terminated;reason=noresource 567 Content-Type: message/sipfrag 568 Content-Length: ... 570 SIP/2.0 200 OK 572 6.3. Failed Transfer 574 This section shows examples of failed transfer attempts. After the 575 transfer failure occurs, the Transferor takes the Transferee off hold 576 and resumes the session. 578 6.3.1. Target Busy 579 Transferor Transferee Transfer 580 | | Target 581 | | | 582 | INVITE | | 583 dialog1 |<-------------------| | 584 | 200 OK | | 585 dialog1 |------------------->| | 586 | ACK | | 587 dialog1 |<-------------------| | 588 | INVITE (hold) | | 589 dialog1 |------------------->| | 590 | 200 OK | | 591 dialog1 |<-------------------| | 592 | ACK | | 593 dialog1 |------------------->| | 594 | REFER (Target-Dialog:1) | 595 dialog2 |------------------->| | 596 | 202 Accepted | | 597 dialog2 |<-------------------| | 598 | NOTIFY (100 Trying)| | 599 dialog2 |<-------------------| | 600 | 200 OK | | 601 dialog2 |------------------->| | 602 | | INVITE | 603 dialog3 | |------------------->| 604 | | 486 Busy Here | 605 dialog3 | |<-------------------| 606 | | ACK | 607 dialog3 | |------------------->| 608 | NOTIFY (486 Busy Here) | 609 dialog2 |<-------------------| | 610 | 200 OK | | 611 dialog2 |------------------->| | 612 | INVITE (unhold) | | 613 dialog1 |------------------->| | 614 | 200 OK | | 615 dialog1 |<-------------------| | 616 | ACK | | 617 dialog1 |------------------->| | 618 | BYE | | 619 dialog1 |------------------->| | 620 | 200 OK | | 621 dialog1 |<-------------------| | 623 Figure 3. Failed Transfer - Target Busy 625 6.3.2. Transfer Target does not answer 627 Transferor Transferee Transfer 628 | | Target 629 | INVITE | | 630 dialog1 |<-------------------| | 631 | 200 OK | | 632 dialog1 |------------------->| | 633 | ACK | | 634 dialog1 |<-------------------| | 635 | INVITE (hold) | | 636 dialog1 |------------------->| | 637 | 200 OK | | 638 dialog1 |<-------------------| | 639 | ACK | | 640 dialog1 |------------------->| | 641 | REFER | | 642 dialog2 |------------------->| | 643 | 202 Accepted | | 644 dialog2 |<-------------------| | 645 | NOTIFY (100 Trying)| | 646 dialog2 |<-------------------| | 647 | 200 OK | | 648 dialog2 |------------------->| | 649 | | INVITE | 650 dialog3 | |------------------->| 651 | | 180 Ringing | 652 dialog3 | |<-------------------| 653 | (Transferee gets tired of waiting) 654 | | CANCEL | 655 dialog3 | |------------------->| 656 | | 200 OK (CANCEL) | 657 dialog3 | |<-------------------| 658 | 487 Request Cancelled (INVITE) 659 dialog3 | |<-------------------| 660 | | ACK | 661 dialog3 | |------------------->| 662 | NOTIFY (487 Request Cancelled) | 663 dialog2 |<-------------------| | 664 | 200 OK | | 665 dialog2 |------------------->| | 666 | INVITE (unhold) | | 667 dialog1 |------------------->| | 668 | 200 OK | | 669 dialog1 |<-------------------| | 670 | ACK | | 671 dialog1 |------------------->| | 672 | BYE | | 673 dialog1 |------------------->| | 674 | 200 OK | | 675 dialog1 |<-------------------| | 677 Figure 4. Failed Transfer - Target Does Not Answer. 679 7. Transfer with Consultation Hold 681 Transfer with Consultation Hold involves a session between the 682 transferor and the transfer target before the transfer actually takes 683 place. This is implemented with SIP Hold and Transfer as described 684 above. 686 A nice feature is for the transferor to let the target know that the 687 session relates to an intended transfer. Since many UAs render the 688 display name in the From header field to the user, a consultation 689 INVITE could contain a string such as "Incoming consultation from 690 Transferor with intent to transfer Transferee", where the display 691 names of the transferor and transferee are included in the string. 693 7.1. Exposing transfer target 695 The transferor places the transferee on hold, establishes a call with 696 the transfer target to alert them to the impending transfer, 697 terminates the connection with the transfer target, then proceeds 698 with transfer as above. This variation can be used to provide an 699 experience similar to that expected by current PBX and Centrex users. 701 To (hopefully) improve clarity, non-REFER transactions have been 702 collapsed into one indicator with the arrow showing the direction of 703 the request. 705 Transferor Transferee Transfer 706 | | Target 707 | | | 708 dialog1 | INVITE/200 OK/ACK | | 709 |<-------------------| | 710 dialog1 | INVITE (hold)/200 OK/ACK | 711 |------------------->| | 712 dialog2 | INVITE/200 OK/ACK | | 713 |---------------------------------------->| 714 dialog2 | BYE/200 OK | | 715 |---------------------------------------->| 716 dialog3 | REFER | | 717 |------------------->| | 718 dialog3 | 202 Accepted | | 719 |<-------------------| | 720 dialog3 | NOTIFY (100 Trying)| | 721 |<-------------------| | 722 dialog3 | 200 OK | | 723 |------------------->| | 724 dialog4 | | INVITE/200 OK/ACK | 725 | |------------------->| 726 dialog3 | NOTIFY (200 OK) | | 727 |<-------------------| | 728 dialog3 | 200 OK | | 729 |------------------->| | 730 dialog1 | BYE/200 OK | | 731 |------------------->| | 732 dialog4 | | BYE/200 OK | 733 | |<-------------------| 735 Figure 5. Transfer with Consultation Hold - Exposing Transfer 736 Target. 738 7.2. Protecting transfer target 740 The transferor places the transferee on hold, establishes a call with 741 the transfer target and then reverses their roles, transferring the 742 original transfer target to the original transferee. This has the 743 advantage of hiding information about the original transfer target 744 from the original transferee. On the other hand, the Transferee's 745 experience is different that in current systems. The Transferee is 746 effectively "called back" by the Transfer Target. 748 One of the problems with this simplest implementation of a target 749 protecting transfer is that the transferee is receiving a new call 750 from the transfer-target. Unless the transferee's agent has a 751 reliable way to associate this new call with the call it already has 752 with the transferor, it will have to alert the new call on another 753 appearance. If this, or some other call-waiting-like UI were not 754 available, the transferee might be stuck returning a Busy-Here to the 755 transfer target, effectively preventing the transfer. There are many 756 ways that that correlation could be provided. The dialog parameters 757 could be provided directly as header parameters in the Refer-To: URI 758 for example. The Replaces mechanism [RFC3891] uses this approach and 759 solves this problem nicely. 761 For the flow below, dialog1 means dialog identifier 1, and consists 762 of the parameters of the Replaces header for dialog 1. In [RFC3891] 763 this is the Call-ID, To-tag and From-tag. 765 Note that the transferee's agent emits a BYE to the transferor's 766 agent as an immediate consequence of processing the Replaces header. 768 The Transferor knows that both the Transferee and the Transfer Target 769 support the Replaces header from the Supported: replaces header 770 contained in the 200 OK responses from both. 772 In this scenario, the Transferee utilizes a GRUU as a Contact URI for 773 reasons discussed in Section 6.3. 775 Note that the conventions used in the SIP Torture Test Messages 776 [RFC4475] document are reused, specifically the tag. 778 Transferor Transferee Transfer 779 | | Target 780 | | | 781 dialog1 | INVITE/200 OK/ACK F1 F2 | 782 |<-------------------| | 783 dialog1 | INVITE (hold)/200 OK/ACK | 784 |------------------->| | 785 dialog2 | INVITE/200 OK/ACK F3 F4 | 786 |---------------------------------------->| 787 dialog2 | INVITE (hold)/200 OK/ACK | 788 |---------------------------------------->| 789 dialog3 | REFER (Target-Dialog:2, | 790 | Refer-To:sips:Transferee?Replaces=1) F5| 791 |---------------------------------------->| 792 dialog3 | 202 Accepted | | 793 |<----------------------------------------| 794 dialog3 | NOTIFY (100 Trying)| | 795 |<----------------------------------------| 796 dialog3 | | 200 OK | 797 |---------------------------------------->| 798 dialog4 | INVITE (Replaces:dialog1)/200 OK/ACK F6 799 | |<-------------------| 800 dialog1 | BYE/200 OK | | 801 |<-------------------| | 802 dialog3 | NOTIFY (200 OK) | | 803 |<----------------------------------------| 804 dialog3 | | 200 OK | 805 |---------------------------------------->| 806 dialog2 | BYE/200 OK | | 807 |---------------------------------------->| 808 | (transferee and target converse) 809 dialog4 | | BYE/200 OK | 810 | |------------------->| 812 Figure 6. Transfer Protecting Transfer Target. 814 F1 INVITE Transferee -> Transferor 816 INVITE sips:transferor@atlanta.example.com SIP/2.0 817 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 818 Max-Forwards: 70 819 To: 820 From: ;tag=7553452 821 Call-ID: 090459243588173445 822 CSeq: 29887 INVITE 823 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 824 Supported: replaces, gruu 825 Contact: 826 Content-Type: application/sdp 827 Content-Length: ... 829 F2 200 OK Transferor -> Transferee 831 SIP/2.0 200 OK 832 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 833 To: ;tag=31431 834 From: ;tag=7553452 835 Call-ID: 090459243588173445 836 CSeq: 29887 INVITE 837 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 838 Supported: replaces, gruu, tdialog 839 Contact: 840 Content-Type: application/sdp 841 Content-Length: ... 843 F3 INVITE Transferor -> Transfer Target 845 INVITE sips:transfertarget@chicago.example.com SIP/2.0 846 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 847 Max-Forwards: 70 848 To: 849 From: ;tag=763231 850 Call-ID: 592435881734450904 851 CSeq: 29887 INVITE 852 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 853 Supported: gruu, replaces, tdialog 854 Require: replaces 855 Contact: 856 Content-Type: application/sdp 857 Content-Length: ... 859 F4 200 OK Transfer Target -> Transferor 861 SIP/2.0 200 OK 862 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 863 ;received=192.0.2.1 864 To: ;tag=9m2n3wq 865 From: ;tag=763231 866 Call-ID: 592435881734450904 867 CSeq: 29887 INVITE 868 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 869 Supported: replaces, gruu, tdialog 870 Contact: 871 Content-Type: application/sdp 872 Content-Length: ... 874 F5 REFER Transferor -> Transfer Target 876 REFER sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 877 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 878 Max-Forwards: 70 879 To: 880 From: ;tag=1928301774 881 Call-ID: a84b4c76e66710 882 CSeq: 314159 REFER 883 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 884 Supported: gruu, replaces, tdialog 885 Require: tdialog 886 887 Refer-To: 889 890 Target-Dialog: 592435881734450904;local-tag=9m2n3wq 891 ;remote-tag=763231 892 Contact: 893 Content-Length: 0 895 F6 INVITE Transfer Target -> Transferee 897 INVITE sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 898 Via: SIP/2.0/TLS client.chicago.example.com;branch=z9hG4bKnaslu84 899 Max-Forwards: 70 900 To: 901 From: ;tag=341234 902 Call-ID: kmzwdle3dl3d08 903 CSeq: 41 INVITE 904 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 905 Supported: gruu, replaces, tdialog 906 Contact: 907 Replaces: 090459243588173445;to-tag=7553452;from-tag=31431 908 Content-Type: application/sdp 909 Content-Length: ... 911 7.3. Attended Transfer 913 The transferor places the transferee on hold, establishes a call with 914 the transfer target to alert them to the impending transfer, places 915 the target on hold, then proceeds with transfer using an escaped 916 Replaces header field in the Refer-To header. This is another common 917 service expected by current PBX and Centrex users. 919 The Contact URI of the Transfer Target SHOULD be used by the 920 Transferor as the Refer-To URI, unless the URI is suspected or known 921 to not be routable outside the dialog. Otherwise, the Address of 922 Record (AOR) of the Transfer Target should be used. That is, the 923 same URI that the Transferor used to establish the session with the 924 Transfer Target should be used. In case the triggered INVITE is 925 routed to a different User Agent than the Transfer Target, the 926 Require: replaces header field should be used in the triggered 927 INVITE. (This is to prevent an incorrect User Agent which does not 928 support Replaces from ignoring the Replaces and answering the INVITE 929 without a dialog match.) 931 It is possible that proxy/service routing may prevent the triggered 932 INVITE from reaching the same User Agent. If this occurs, the 933 triggered invite will fail with a timout, 403, 404, etc error. The 934 Transferee MAY then retry the transfer with the Refer-To URI set to 935 the Contact URI. 937 Transferor Transferee Transfer 938 | | Target 939 | | | 940 dialog1 | INVITE/200 OK/ACK F1 F2 | 941 |<-------------------| | 942 dialog1 | INVITE (hold)/200 OK/ACK | 943 |------------------->| | 944 dialog2 | INVITE/200 OK/ACK F3 F4 | 945 |---------------------------------------->| 946 dialog2 | INVITE (hold)/200 OK/ACK | 947 |---------------------------------------->| 948 dialog3 | REFER (Target-Dialog:1, | 949 | Refer-To:sips:TransferTarget?Replaces=2) F5 950 |------------------->| | 951 dialog3 | 202 Accepted | | 952 |<-------------------| | 953 dialog3 | NOTIFY (100 Trying)| | 954 |<-------------------| | 955 dialog3 | 200 OK | | 956 |------------------->| | 957 dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6 958 | |------------------->| 959 dialog2 | BYE/200 OK | | 960 |<----------------------------------------| 961 dialog3 | NOTIFY (200 OK) | | 962 |<-------------------| | 963 dialog3 | 200 OK | | 964 |------------------->| | 965 dialog1 | BYE/200 OK | | 966 |------------------->| | 967 dialog4 | | BYE/200 OK | 968 | |<-------------------| 970 Figure 7. Attended Transfer Call Flow. 972 F1 INVITE Transferee -> Transferor 974 INVITE sips:transferor@atlanta.example.com SIP/2.0 975 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 976 Max-Forwards: 70 977 To: 978 From: ;tag=7553452 979 Call-ID: 090459243588173445 980 CSeq: 29887 INVITE 981 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 982 Supported: replaces, gruu, tdialog 983 Contact: 984 Content-Type: application/sdp 985 Content-Length: ... 987 F2 200 OK Transferor -> Transferee 989 SIP/2.0 200 OK 990 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 991 To: ;tag=31431 992 From: ;tag=7553452 993 Call-ID: 090459243588173445 994 CSeq: 29887 INVITE 995 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 996 Supported: replaces, gruu, tdialog 997 Contact: 998 Content-Type: application/sdp 999 Content-Length: ... 1001 F3 INVITE Transferor -> Transfer Target 1003 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1004 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1005 Max-Forwards: 70 1006 To: 1007 From: ;tag=763231 1008 Call-ID: 592435881734450904 1009 CSeq: 29887 INVITE 1010 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1011 Supported: gruu, replaces, tdialog 1012 Require: replaces 1013 Contact: 1014 Content-Type: application/sdp 1015 Content-Length: ... 1017 F4 200 OK Transfer Target -> Transferor 1019 SIP/2.0 200 OK 1020 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1021 ;received=192.0.2.1 1022 To: ;tag=9m2n3wq 1023 From: ;tag=763231 1024 Call-ID: 592435881734450904 1025 CSeq: 29887 INVITE 1026 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1027 Supported: replaces, gruu 1028 Contact: 1029 Content-Type: application/sdp 1030 Content-Length: ... 1032 F5 REFER Transferor -> Transferee 1034 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 1035 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1036 Max-Forwards: 70 1037 To: 1038 From: ;tag=1928301774 1039 Call-ID: a84b4c76e66710 1040 CSeq: 314159 REFER 1041 Require: tdialog 1042 1043 Refer-To: 1045 1046 Target-Dialog: 592435881734450904;local-tag=9m2n3wq 1047 ;remote-tag=763231 1048 Contact: 1049 Content-Length: 0 1051 F6 INVITE Transferee -> Transfer Target 1053 INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 1054 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 1055 Max-Forwards: 70 1056 To: 1057 From: ;tag=954 1058 Call-ID: kmzwdle3dl3d08 1059 CSeq: 41 INVITE 1060 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1061 Supported: gruu, replaces, tdialog 1062 Contact: 1063 Replaces: 592435881734450904;to-tag=9m2n3wq;from-tag=763231 1064 Content-Type: application/sdp 1065 Content-Length: ... 1067 7.4. Recovery when one party does not support REFER 1069 If protecting or exposing the transfer target is not a concern, it is 1070 possible to complete a transfer with consultation hold when only the 1071 transferor and one other party support REFER. Note that a 405 Method 1072 Not Allowed might be returned instead of the 501 Not Implemented 1073 response. 1075 Transferor Transferee Transfer 1076 | | Target 1077 | | | 1078 dialog1 | INVITE/200 OK/ACK | | 1079 |<-------------------| | 1080 dialog1 | INVITE (hold)/200 OK/ACK | 1081 |------------------->| | 1082 dialog2 | INVITE/200 OK/ACK | | 1083 |---------------------------------------->| 1084 dialog2 | INVITE (hold)/200 OK/ACK | 1085 |---------------------------------------->| 1086 dialog3 | REFER (Target-Dialog:1, | 1087 | Refer-To:sips:TransferTarget?Replaces=2) 1088 |------------------->| | 1089 dialog3 | 501 Not Implemented | 1090 |<-------------------| | 1091 dialog4 | REFER (Refer-To:sips:Transferee?Replaces=dialog1) 1092 |---------------------------------------->| 1093 dialog4 | 202 Accepted | | 1094 |<----------------------------------------| 1095 dialog4 | NOTIFY (100 Trying)| | 1096 |<----------------------------------------| 1097 dialog4 | | 200 OK | 1098 |---------------------------------------->| 1099 dialog5 | INVITE (Replaces:dialog1)/200 OK/ACK 1100 | |<-------------------| 1101 dialog4 | NOTIFY (200 OK) | | 1102 |<----------------------------------------| 1103 dialog4 | | 200 OK | 1104 |---------------------------------------->| 1105 dialog1 | BYE/200 OK | | 1106 |<-------------------| | 1107 dialog2 | BYE/200 OK | | 1108 |---------------------------------------->| 1109 dialog5 | | BYE/200 OK | 1110 | |------------------->| 1112 Figure 8. Recovery when one party does not support REFER. 1114 7.5. Attended transfer when Contact URI is not known to route to a 1115 unique user agent. 1117 It is a requirement of RFC3261 that a Contact URI be globally 1118 routable even outside the dialog. However, due to RFC2543 User 1119 Agents and some architectures (NAT/Firewall traversal, screening 1120 proxies, ALGs, etc.) this will not always be the case. As a result, 1121 the method of Attended Transfer shown in Figures 6, 7, and 8 should 1122 only be used if the Contact URI is known to be routable outside the 1123 dialog. 1125 Figure 9 shows such a scenario where the Transfer Target Contact URI 1126 is not routable outside the dialog, so the triggered INVITE is sent 1127 to the AOR of the Transfer Target. 1129 Transferor Transferee Screening Transfer 1130 | | Proxy Target 1131 | | | | 1132 dialog1 | INVITE/200 OK/ACK| | | 1133 |<-----------------| | | 1134 dialog1 | INVITE (hold)/200 OK/ACK | | 1135 |----------------->| | | 1136 dialog2 | INVITE/200 OK/ACK F1 F2 | | 1137 |--------------------------------|------------>| 1138 dialog2 | INVITE (hold)/200 OK/ACK | 1139 |--------------------------------|------------>| 1140 dialog1 | REFER (Refer-To:sips:TargetAOR | 1141 | ?Replaces=dialog2&Require=replaces) F3 1142 |----------------->| | | 1143 dialog1 | 202 Accepted | | | 1144 |<-----------------| | | 1145 dialog1 | NOTIFY (100 Trying) | | 1146 |<-----------------| | | 1147 dialog1 | 200 OK | | | 1148 |----------------->| | | 1149 dialog4 |INVITE (Replaces:dialog2,Require:replaces)/200 OK/ACK F6 1150 | |------------>|------------>| 1151 dialog2 | BYE/200 OK | | | 1152 |<-------------------------------|<------------| 1153 dialog1 | NOTIFY (200 OK) F7 | | 1154 |<-----------------| | | 1155 dialog1 | 200 OK | | | 1156 |----------------->| | | 1157 dialog1 | BYE/200 OK | | | 1158 |----------------->| | | 1159 dialog3 | | | BYE/200 OK | 1160 | |<------------|-------------| 1162 Figure 9. Attended Transfer Call Flow with a Contact URI not known 1163 to be Globally Routable 1165 F1 INVITE Transferor -> Transfer Target 1167 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1168 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76 1169 Max-Forwards: 70 1170 To: 1171 From: ;tag=763231 1172 Call-ID: 090459243588173445 1173 CSeq: 29887 INVITE 1174 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1175 Supported: replaces 1176 Contact: 1177 Content-Type: application/sdp 1178 Content-Length: ... 1180 F2 200 OK Transfer Target -> Transferee 1182 SIP/2.0 200 OK 1183 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1184 ;received=192.0.2.1 1185 To: ;tag=9m2n3wq 1186 From: ;tag=763231 1187 Call-ID: 090459243588173445 1188 CSeq: 29887 INVITE 1189 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1190 Supported: replaces 1191 Contact: 1192 Content-Type: application/sdp 1193 Content-Length: ... 1195 F3 REFER Transferor -> Transferee 1197 REFER sips:transferee@192.0.2.4 SIP/2.0 1198 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1199 Max-Forwards: 70 1200 To: ;tag=a6c85cf 1201 From: ;tag=1928301774 1202 Call-ID: a84b4c76e66710 1203 CSeq: 314160 REFER 1204 1205 Refer-To: 1208 1209 Contact: 1210 Content-Length: 0 1212 F4 INVITE Transferee -> Transfer Target 1214 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1215 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 1216 Max-Forwards: 70 1217 To: 1218 From: ;tag=954 1219 Call-ID: 20482817324945934422930 1220 CSeq: 42 INVITE 1221 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1222 Supported: replaces 1223 Contact: 1224 Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 1225 Require: replaces 1226 Content-Type: application/sdp 1227 Content-Length: ... 1229 F5 NOTIFY Transferee -> Transferor 1231 NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 1232 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 1233 Max-Forwards: 70 1234 To: ;tag=1928301774 1235 From: ;tag=a6c85cf 1236 Call-ID: a84b4c76e66710 1237 CSeq: 76 NOTIFY 1238 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1239 Supported: replaces 1240 Event: refer;id=98873867 1241 Subscription-State: terminated;reason=noresource 1242 Content-Type: message/sipfrag 1243 Content-Length: ... 1245 SIP/2.0 200 OK 1247 Figure 10 shows a failure case in which the AOR URI fails to reach 1248 the transfer Target. As a result, the transfer is retried with the 1249 Contact URI which succeeds. 1251 Note that there is still no guarantee that the correct endpoint will 1252 be reached, and the result of this second REFER may also be a 1253 failure. In that case, the Transferor could fall back to unattended 1254 transfer or give up on the transfer entirely. Since two REFERs are 1255 sent within the dialog creating two distinct subscriptions, the 1256 Transferee uses the 'id' parameter in the Event header field to 1257 distinguish notifications for the two subscriptions. 1259 Transferor Transferee Screening Transfer 1260 | | Proxy Target 1261 | | | | 1262 dialog1 | INVITE/200 OK/ACK| | | 1263 |<-----------------| | | 1264 dialog1 | INVITE (hold)/200 OK/ACK | | 1265 |----------------->| | | 1266 dialog2 | INVITE/200 OK/ACK F1 F2 | | 1267 |--------------------------------|------------>| 1268 dialog2 | INVITE (hold)/200 OK/ACK | 1269 |--------------------------------|------------>| 1270 dialog1 | REFER (Refer-To:sips:TargetAOR? | 1271 | Replaces=dialog2&Require=replaces) F3 | 1272 |----------------->| | | 1273 dialog1 | 202 Accepted | | | 1274 |<-----------------| | | 1275 dialog1 | NOTIFY (100 Trying) | | 1276 |<-----------------| | | 1277 dialog1 | 200 OK | | | 1278 |----------------->| | | 1279 dialog3 | |INVITE (Replaces:dialog2, | 1280 | | Require:replaces)/403/ACK | 1281 | |------------>| | 1282 dialog1 | NOTIFY (403 Forbidden) F4 | | 1283 |<-----------------| | | 1284 dialog1 | 200 OK | | | 1285 |----------------->| | | 1286 dialog1 |REFER(Refer-To:sips:TargetContact?Replaces=dialog2) F5 1287 |----------------->| | | 1288 dialog1 | 202 Accepted | | | 1289 |<-----------------| | | 1290 dialog1 | NOTIFY (100 Trying) | | 1291 |<-----------------| | | 1292 dialog1 | 200 OK | | | 1293 |----------------->| | | 1294 dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6 1295 | |------------>|------------>| 1296 dialog2 | BYE/200 OK | | | 1297 |<-------------------------------|<------------| 1298 dialog1 | NOTIFY (200 OK) F7 | | 1299 |<-----------------| | | 1300 dialog1 | 200 OK | | | 1301 |----------------->| | | 1302 dialog1 | BYE/200 OK | | | 1303 |----------------->| | | 1304 dialog3 | | | BYE/200 OK | 1305 | |<------------|-------------| 1307 Figure 10. Attended Transfer Call Flow with non-routable Contact URI 1308 and AOR Failure 1310 F1 INVITE Transferor -> Transfer Target 1312 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1313 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76 1314 Max-Forwards: 70 1315 To: 1316 From: ;tag=763231 1317 Call-ID: 090459243588173445 1318 CSeq: 29887 INVITE 1319 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1320 Supported: replaces 1321 Contact: 1322 Content-Type: application/sdp 1323 Content-Length: ... 1325 F2 200 OK Transfer Target -> Transferee 1327 SIP/2.0 200 OK 1328 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1329 ;received=192.0.2.1 1330 To: ;tag=9m2n3wq 1331 From: ;tag=763231 1332 Call-ID: 090459243588173445 1333 CSeq: 29887 INVITE 1334 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1335 Supported: replaces 1336 Contact: 1337 Content-Type: application/sdp 1338 Content-Length: ... 1340 F3 REFER Transferor -> Transferee 1342 REFER sips:transferee@192.0.2.4 SIP/2.0 1343 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1344 Max-Forwards: 70 1345 To: ;tag=a6c85cf 1346 From: ;tag=1928301774 1347 Call-ID: a84b4c76e66710 1348 CSeq: 314159 REFER 1349 1350 Refer-To: 1353 1354 Contact: 1355 Content-Length: 0 1357 F4 NOTIFY Transferee -> Transferor 1359 NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 1360 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 1361 Max-Forwards: 70 1362 To: ;tag=1928301774 1363 From: ;tag=a6c85cf 1364 Call-ID: a84b4c76e66710 1365 CSeq: 74 NOTIFY 1366 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1367 Supported: replaces 1368 Event: refer;id=314159 1369 Subscription-State: terminated;reason=noresource 1370 Content-Type: message/sipfrag 1371 Content-Length: ... 1373 SIP/2.0 403 Forbidden 1375 F5 REFER Transferor -> Transferee 1377 REFER sips:transferee@192.0.2.4 SIP/2.0 1378 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1379 Max-Forwards: 70 1380 To: ;tag=a6c85cf 1381 From: ;tag=1928301774 1382 Call-ID: a84b4c76e66710 1383 CSeq: 314160 REFER 1384 1385 Refer-To: 1388 1389 Contact: 1390 Content-Length: 0 1392 F6 INVITE Transferee -> Transfer Target 1394 INVITE sips:transfertarget@client.chicago.example.com SIP/2.0 1395 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 1396 Max-Forwards: 70 1397 To: 1398 From: ;tag=954 1399 Call-ID: 20482817324945934422930 1400 CSeq: 42 INVITE 1401 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1402 Supported: replaces 1403 Contact: 1404 Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 1405 Content-Type: application/sdp 1406 Content-Length: ... 1408 F7 NOTIFY Transferee -> Transferor 1410 NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 1411 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 1412 Max-Forwards: 70 1413 To: ;tag=1928301774 1414 From: ;tag=a6c85cf 1415 Call-ID: a84b4c76e66710 1416 CSeq: 76 NOTIFY 1417 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1418 Supported: replaces 1419 Event: refer;id=314160 1420 Subscription-State: terminated;reason=noresource 1421 Content-Type: message/sipfrag 1422 Content-Length: ... 1424 SIP/2.0 200 OK 1426 To prevent this scenario from happening, the Transfer Target should 1427 use a Contact URI which is routable outside the dialog, which will 1428 result in the call flow of Figure 7. 1430 7.6. Semi-Attended Transfer 1432 In any of the consultation hold flows above, the Transferor may 1433 decide to terminate its attempt to contact the Transfer target before 1434 that session is established. Most frequently, that will be the end 1435 of the scenario, but in some circumstances, the transferor may wish 1436 to proceed with the transfer action. For example, the Transferor may 1437 wish to complete the transfer knowing that the transferee will end up 1438 eventually talking to the transfer-target's voice-mail service. Some 1439 PBX systems support this feature, sometimes called "semi-attended 1440 transfer", that is effectively a hybrid between a fully attended 1441 transfer and an unattended transfer. A call flow is shown in Figure 1442 11. In this flow, the Transferor's User Agent continues the transfer 1443 as an attended transfer even after the Transferor hangs up. Note 1444 that media must be played to the Transfer Target upon answer - 1445 otherwise, the Target may hang up and the resulting transfer 1446 operation will fail. 1448 Transferor Transferee Transfer 1449 | | Target 1450 | | | 1451 dialog1 | INVITE/200 OK/ACK F1 F2 | 1452 |<-------------------| | 1453 dialog1 | INVITE (hold)/200 OK/ACK | 1454 |------------------->| | 1455 dialog2 | INVITE | | 1456 |---------------------------------------->| 1457 dialog2 | | 180 Ringing | 1458 |<----------------------------------------| 1459 Transferor hangs up but wants transfer to continue 1460 | | | 1461 | User Agent continues transfer operation | 1462 | | | 1463 dialog2 | | 200 OK | 1464 |<----------------------------------------| 1465 dialog2 | ACK | | 1466 |---------------------------------------->| 1467 dialog2 | Media Played to keep Target from hanging up 1468 |========================================>| 1469 dialog3 | REFER (Target-Dialog:1, | 1470 | Refer-To:sips:TransferTarget?Replaces=2) 1471 |------------------->| | 1472 dialog3 | 202 Accepted | | 1473 |<-------------------| | 1474 dialog3 | NOTIFY (100 Trying)| | 1475 |<-------------------| | 1476 dialog3 | 200 OK | | 1477 |------------------->| | 1478 dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK 1479 | |------------------->| 1480 dialog2 | BYE/200 OK | | 1481 |<----------------------------------------| 1482 dialog3 | NOTIFY (200 OK) | | 1483 |<-------------------| | 1484 dialog3 | 200 OK | | 1485 |------------------->| | 1486 dialog1 | BYE/200 OK | | 1487 |------------------->| | 1488 dialog4 | | BYE/200 OK | 1489 | |<-------------------| 1491 Figure 11. Recommended Semi-Attended Transfer Call Flow. 1493 Two other possible semi-attended transfer call flows are shown in 1494 Figures 12 and 13. However, these call flows are NOT RECOMMENDED due 1495 to a race conditions. In both of these flows, when the Transferor 1496 hangs up, the Transferor attempts to revert to unattended transfer by 1497 sending a CANCEL to the Target. This can result in two race 1498 conditions. One is that the Target answers despite the CANCEL and 1499 the resulting unattended transfer fails. This race condition can be 1500 eliminated by the Transferor waiting to send the REFER until the 487 1501 response from the Target is returned. Instead of a 487, a 200 OK may 1502 return indicating that the Target has answered the consultation call. 1503 In this, case the call flow in Figure 13 must be followed. In this 1504 flow, the Transferor must play some kind of media to the Target to 1505 prevent the Target from hanging up, or the Transfer will fail. That 1506 is, the human at the Transfer Target will hear silence from when they 1507 answer (message F1) until the transfer completes (F3 and they are 1508 talking to the Transferee unless some media is played (F2). 1510 The second race condition occurs in Figure 12 if the Transfer Target 1511 goes "off hook" after the CANCEL is received and the 487 returned. 1512 This may result in a 486 Busy Here response to the unattended 1513 transfer. 1515 The recommended call flow of Figure 11 does not utilize a CANCEL and 1516 does not suffer from these race conditions. 1518 Transferor Transferee Transfer 1519 | | Target 1520 | | | 1521 dialog1 | INVITE/200 OK/ACK | | 1522 |<-------------------| | 1523 dialog1 | INVITE (hold)/200 OK/ACK | 1524 |------------------->| | 1525 dialog2 | INVITE | 1526 |---------------------------------------->| 1527 dialog2 | 180 Ringing | 1528 |<----------------------------------------| 1529 | | 1530 | Transferor gives up waiting | 1531 | | 1532 dialog2 | CANCEL | 1533 |---------------------------------------->| 1534 dialog2 | 200 OK | 1535 |<----------------------------------------| 1536 dialog2 | 487 Request Terminated | 1537 |<----------------------------------------| 1538 dialog2 | ACK | 1539 |---------------------------------------->| 1540 dialog3 | REFER (Target-Dialog:1) F3 | 1541 |------------------->| | 1542 dialog3 | 202 Accepted | | 1543 |<-------------------| | 1544 dialog3 | NOTIFY (100 Trying)| | 1545 |<-------------------| | 1546 dialog3 | 200 OK | | 1547 |------------------->| | 1548 dialog4 | INVITE/200 OK/ACK | 1549 | |------------------->| 1550 dialog3 | NOTIFY (200 OK) | | 1551 |<-------------------| | 1552 dialog3 | 200 OK | | 1553 |------------------->| | 1554 dialog1 | BYE/200 OK | | 1555 |------------------->| | 1556 dialog4 | | BYE/200 OK | 1557 | |<-------------------| 1559 Figure 12. Semi-Attended Transfer as Blind Transfer Call Flow. (Not 1560 Recommended) 1561 Transferor Transferee Transfer 1562 | | Target 1563 | | | 1564 dialog1 | INVITE/200 OK/ACK | | 1565 |<-------------------| | 1566 dialog1 | INVITE (hold)/200 OK/ACK | 1567 |------------------->| | 1568 dialog2 | INVITE | 1569 |---------------------------------------->| 1570 dialog2 | 180 Ringing | 1571 |<----------------------------------------| 1572 | | 1573 |Transferor gives up waiting but Target answers 1574 | | 1575 dialog2 | CANCEL | 1576 |---------------------------------------->| 1577 dialog2 | 200 OK (CANCEL) | 1578 |<----------------------------------------| 1579 dialog2 | 200 OK (INVITE) F1 | 1580 |<----------------------------------------| 1581 dialog2 | ACK | 1582 |---------------------------------------->| 1583 dialog2 | INVITE (hold)/200 OK/ACK | 1584 |---------------------------------------->| 1585 | Tones or media played avoid silence F2 | 1586 |========================================>| 1587 dialog1 |REFER (Refer-To:sips:TransferTarget | 1588 | ?Replaces=dialog2) | 1589 |------------------->| | 1590 dialog1 | 202 Accepted | | 1591 |<-------------------| | 1592 dialog1 | NOTIFY (100 Trying)| | 1593 |<-------------------| | 1594 dialog1 | 200 OK | | 1595 |------------------->| | 1596 dialog3 | INVITE (Replaces:dialog2)/200 OK/ACK F3 1597 | |------------------->| 1598 dialog2 | BYE/200 OK | | 1599 |<----------------------------------------| 1600 dialog1 | NOTIFY (200 OK) | | 1601 |<-------------------| | 1602 dialog1 | 200 OK | | 1603 |------------------->| | 1604 dialog1 | BYE/200 OK | | 1605 |------------------->| | 1606 dialog3 | | BYE/200 OK | 1607 | |<-------------------| 1609 Figure 13. Semi-Attended Transfer as Attended Transfer Call Flow. 1610 (Not Recommended) 1612 7.7. Attended Transfer Fallback to Basic Transfer 1614 In this flow, an attempted attended transfer fails so the transferor 1615 falls back to basic transfer. 1617 The call flow in Figure 14 shows the use of Require: replaces in the 1618 INVITE sent by the Transferor to the Transfer Target in which the 1619 Transferor's intention at the time of sending the INVITE to the 1620 Transfer Target was known to be to complete an attended transfer. 1621 Since the Target does not support Replaces, the INVITE is rejected 1622 with a 420 Bad Extension response, and the Transferor switches from 1623 attended transfer to basic transfer immediately. 1625 Transferor Transferee Transfer 1626 | | Target 1627 | | | 1628 dialog1 | INVITE/200 OK/ACK | | 1629 |<-------------------| | 1630 dialog1 | OPTIONS/200 OK | | 1631 |------------------->| | 1632 dialog1 | INVITE (hold)/200 OK/ACK | 1633 |------------------->| | 1634 dialog2 | INVITE (Require:replaces) | 1635 |---------------------------------------->| 1636 dialog2 | 420 Bad Extension | 1637 |<----------------------------------------| 1638 dialog2 | ACK | 1639 |---------------------------------------->| 1640 dialog1 | REFER (Refer-To:sips:TransferTarget) | 1641 |------------------->| | 1642 dialog1 | 202 Accepted | | 1643 |<-------------------| | 1644 dialog1 | NOTIFY (100 Trying)| | 1645 |<-------------------| | 1646 dialog1 | 200 OK | | 1647 |------------------->| | 1648 dialog3 | | INVITE/200 OK/ACK | 1649 | |------------------->| 1650 dialog1 | NOTIFY (200 OK) | | 1651 |<-------------------| | 1652 dialog1 | 200 OK | | 1653 |------------------->| | 1654 dialog1 | BYE/200 OK | | 1655 |------------------->| | 1656 dialog3 | | BYE/200 OK | 1657 | |<-------------------| 1659 Figure 14. Attended Transfer Fallback to Basic Transfer using 1660 Require:replaces. 1662 Figure 15 shows the use of OPTIONS when the Transferee and Transfer 1663 Target do not explicitly indicate support for the REFER method and 1664 Replaces header fields in Allow and Supported header fields and the 1665 Transferor did not have the intention of performing an attended 1666 transfer when the INVITE to the Target was sent. In dialog1, the 1667 Transferor determines using OPTIONS that the Transferee does support 1668 REFER and Replaces. As a result, the Transferor begins the attended 1669 transfer by placing the Transferee on hold and calling the Transfer 1670 Target. Using an OPTIONS in dialog2, the Transferor determines that 1671 the Target does not support either REFER or Replaces, making attended 1672 transfer impossible. The Transferor then ends dialog2 by sending a 1673 BYE then sends a REFER to the Transferee using the AOR URI of the 1674 Transfer Target. 1676 Transferor Transferee Transfer 1677 | | Target 1678 | | | 1679 dialog1 | INVITE/200 OK/ACK | | 1680 |<-------------------| | 1681 dialog1 | OPTIONS/200 OK | | 1682 |------------------->| | 1683 dialog1 | INVITE (hold)/200 OK/ACK | 1684 |------------------->| | 1685 dialog2 | INVITE/200 OK/ACK | | 1686 |---------------------------------------->| 1687 dialog2 | OPTIONS/200 OK | | 1688 |---------------------------------------->| 1689 dialog2 | BYE/200 OK | | 1690 |---------------------------------------->| 1691 dialog3 |REFER (Target-Dialog:1, | 1692 | Refer-To:sips:TransferTarget) | 1693 |------------------->| | 1694 dialog3 | 202 Accepted | | 1695 |<-------------------| | 1696 dialog3 | NOTIFY (100 Trying)| | 1697 |<-------------------| | 1698 dialog3 | 200 OK | | 1699 |------------------->| | 1700 dialog4 | | INVITE/200 OK/ACK | 1701 | |------------------->| 1702 dialog3 | NOTIFY (200 OK) | | 1703 |<-------------------| | 1704 dialog3 | 200 OK | | 1705 |------------------->| | 1706 dialog1 | BYE/200 OK | | 1707 |------------------->| | 1708 dialog4 | | BYE/200 OK | 1709 | |<-------------------| 1711 Figure 15. Attended Transfer Fallback to Basic Transfer. 1713 8. Transfer with Referred-By 1715 In the previous examples, the Transfer Target does not have 1716 definitive information about what party initiated the transfer, or, 1717 in some cases, even that transfer is taking place. The Referred-By 1718 mechanism [RFC3892] provides a way for the Transferor to provide the 1719 Transferee with a way to let the Transfer Target know what party 1720 initiated the transfer. 1722 The simplest and least secure approach just involves the inclusion of 1723 the Referred-By header field in the REFER which is then copied into 1724 the triggered INVITE. However, a more secure mechanism involving the 1725 Referred-By security token which is generated and signed by the 1726 Transferor and passed in a message body to the Transferee then to the 1727 Transfer Target. 1729 The call flow would be identical to Figure 7. However, the REFER and 1730 triggered INVITE messages for this flow showing the Referred-By 1731 mechanism are shown below. 1733 Note that the conventions used in the SIP Torture Test Messages 1734 [RFC4475] document are reused, specifically the and 1735 tags. 1737 F5 REFER Transferor -> Transferee 1739 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 1740 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK392039842 1741 Max-Forwards: 70 1742 To: 1743 From: ;tag=1928301774 1744 Call-ID: a84b4c76e66710 1745 CSeq: 314160 REFER 1746 1747 Refer-To: 1750 1751 Supported: gruu, replaces, tdialog 1752 Require: tdialog 1753 Referred-By: 1754 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1755 Target-Dialog: 592435881734450904;local-tag=9m2n3wq;remote-tag=763231 1756 Contact: 1757 Content-Type: multipart/mixed; boundary=unique-boundary-1 1758 Content-Length: 3267 1760 --unique-boundary-1 1761 Content-ID: <20398823.2UWQFN309shb3@atlanta.example.com> 1763 Content-Length: 2961 1764 Content-Type: multipart/signed; 1765 protocol="application/pkcs-7-signature"; 1766 micalg=sha1; 1767 boundary="----590F24D439B31E08745DEF0CD9397189" 1769 ------590F24D439B31E08745DEF0CD9397189 1770 Content-Type: message/sipfrag 1772 Date: Thu, 18 Sep 2003 13:07:43 GMT 1773 1774 Refer-To: 1777 1778 Referred-By: 1779 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1781 ------590F24D439B31E08745DEF0CD9397189 1782 Content-Type: application/pkcs-7-signature; name="smime.p7s" 1783 Content-Transfer-Encoding: binary 1784 Content-Disposition: attachment; filename="smime.p7s" 1786 3082088806092A86 1787 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 1788 0B06092A864886F70D010701A082067A30820339308202A2A003020102020800 1789 90008902240001300D06092A864886F70D01010505003070310B300906035504 1790 0613025553311330110603550408130A43616C69666F726E69613111300F0603 1791 550407130853616E4A6F7365310E300C060355040A1305736970697431293027 1792 060355040B135369706974546573744365727469666963617465417574686F72 1793 697479301E170D3033313032313134343332355A170D31333130313831343433 1794 32355A3062310B3009060355040613025553311330110603550408130A43616C 1795 69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355 1796 040A13057369706974311B30190603550403141273656E646572406578616D70 1797 6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902 1798 818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5 1799 56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD 1800 6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081 1801 D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387 1802 4E230203010001A381E93081E6301D0603551D1104163014811273656E646572 1803 406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416 1804 041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481 1805 9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070 1806 310B3009060355040613025553311330110603550408130A43616C69666F726E 1807 69613111300F0603550407130853616E4A6F7365310E300C060355040A130573 1808 6970697431293027060355040B13536970697454657374436572746966696361 1809 7465417574686F72697479820100300D06092A864886F70D0101050500038181 1810 006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2 1811 2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870 1812 102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153 1813 278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7 1814 5E30820339308202A2A00302010202080090008902240001300D06092A864886 1815 F70D01010505003070310B300906035504061302555331133011060355040813 1816 0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30 1817 0C060355040A1305736970697431293027060355040B13536970697454657374 1818 4365727469666963617465417574686F72697479301E170D3033313032313134 1819 343332355A170D3133313031383134343332355A3062310B3009060355040613 1820 025553311330110603550408130A43616C69666F726E69613111300F06035504 1821 07130853616E4A6F7365310E300C060355040A13057369706974311B30190603 1822 550403141273656E646572406578616D706C652E6F726730819F300D06092A86 1823 4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692 1824 2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79 1825 76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5 1826 FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9 1827 79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D 1828 0603551D1104163014811273656E646572406578616D706C652E6F7267300906 1829 03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70 1830 E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580 1831 546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113 1832 30110603550408130A43616C69666F726E69613111300F060355040713085361 1833 6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353 1834 69706974546573744365727469666963617465417574686F7269747982010030 1835 0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978 1836 7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E 1837 C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A 1838 C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972 1839 242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30 1840 70310B3009060355040613025553311330110603550408130A43616C69666F72 1841 6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305 1842 736970697431293027060355040B135369706974546573744365727469666963 1843 617465417574686F7269747902080090008902240001300906052B0E03021A05 1844 00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C 1845 06092A864886F70D010905310F170D3034303132363139313831345A30230609 1846 2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943 1847 95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E 1848 06082A864886F70D030202020080300D06082A864886F70D0302020140300706 1849 052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01 1850 010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C 1851 C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C 1852 822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087 1853 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 1854 79089AAD95767F 1856 ------590F24D439B31E08745DEF0CD9397189-- 1858 --unique_boundary-1 1860 F6 INVITE Transferee -> Transfer Target 1862 INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 1863 Via: SIP/2.0/TLS referee.example;branch=z9hG4bKffe209934aac 1864 To: 1865 From: ;tag=2909034023 1866 Call-ID: fe9023940-a3465@referee.example 1867 CSeq: 889823409 INVITE 1868 Max-Forwards: 70 1869 Contact: 1870 Referred-By: 1871 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1872 Replaces:090459243588173445;to-tag=9m2n3wq;from- 1873 tag=76323 1874 Require: replaces 1875 Supported: gruu, replaces, tdialog 1876 Content-Type: multipart/mixed; boundary=my-boundary-9 1877 Content-Length: 3432 1879 --my-boundary-9 1880 Content-Type: application/sdp 1882 Content-Length: 156 1884 v=0 1885 o=referee 2890844526 2890844526 IN IP4 referee.example 1886 s=Session SDP 1887 c=IN IP4 referee.example 1888 t=0 0 1889 m=audio 49172 RTP/AVP 0 1890 a=rtpmap:0 PCMU/8000 1892 --my-boundary-9 1893 Content-Length: 2961 1894 Content-Type: multipart/signed; 1895 protocol="application/pkcs-7-signature"; 1896 micalg=sha1; 1897 boundary="----590F24D439B31E08745DEF0CD9397189" 1899 ------590F24D439B31E08745DEF0CD9397189 1900 Content-Type: message/sipfrag 1902 Date: Thu, 18 Sep 2003 13:07:43 GMT 1904 1905 Refer-To: 1908 1909 Referred-By: 1910 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1912 ------590F24D439B31E08745DEF0CD9397189 1913 Content-Type: application/pkcs-7-signature; name="smime.p7s" 1914 Content-Transfer-Encoding: binary 1915 Content-Disposition: attachment; filename="smime.p7s" 1917 3082088806092A86 1919 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 1920 0B06092A864886F70D010701A082067A30820339308202A2A003020102020800 1921 90008902240001300D06092A864886F70D01010505003070310B300906035504 1922 0613025553311330110603550408130A43616C69666F726E69613111300F0603 1923 550407130853616E4A6F7365310E300C060355040A1305736970697431293027 1924 060355040B135369706974546573744365727469666963617465417574686F72 1925 697479301E170D3033313032313134343332355A170D31333130313831343433 1926 32355A3062310B3009060355040613025553311330110603550408130A43616C 1927 69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355 1928 040A13057369706974311B30190603550403141273656E646572406578616D70 1929 6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902 1930 818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5 1931 56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD 1932 6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081 1933 D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387 1934 4E230203010001A381E93081E6301D0603551D1104163014811273656E646572 1935 406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416 1936 041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481 1937 9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070 1938 310B3009060355040613025553311330110603550408130A43616C69666F726E 1939 69613111300F0603550407130853616E4A6F7365310E300C060355040A130573 1940 6970697431293027060355040B13536970697454657374436572746966696361 1941 7465417574686F72697479820100300D06092A864886F70D0101050500038181 1942 006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2 1943 2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870 1944 102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153 1945 278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7 1946 5E30820339308202A2A00302010202080090008902240001300D06092A864886 1947 F70D01010505003070310B300906035504061302555331133011060355040813 1948 0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30 1949 0C060355040A1305736970697431293027060355040B13536970697454657374 1950 4365727469666963617465417574686F72697479301E170D3033313032313134 1951 343332355A170D3133313031383134343332355A3062310B3009060355040613 1952 025553311330110603550408130A43616C69666F726E69613111300F06035504 1953 07130853616E4A6F7365310E300C060355040A13057369706974311B30190603 1954 550403141273656E646572406578616D706C652E6F726730819F300D06092A86 1955 4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692 1956 2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79 1957 76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5 1958 FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9 1959 79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D 1960 0603551D1104163014811273656E646572406578616D706C652E6F7267300906 1961 03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70 1962 E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580 1963 546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113 1964 30110603550408130A43616C69666F726E69613111300F060355040713085361 1965 6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353 1966 69706974546573744365727469666963617465417574686F7269747982010030 1967 0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978 1968 7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E 1969 C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A 1970 C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972 1971 242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30 1972 70310B3009060355040613025553311330110603550408130A43616C69666F72 1973 6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305 1974 736970697431293027060355040B135369706974546573744365727469666963 1975 617465417574686F7269747902080090008902240001300906052B0E03021A05 1976 00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C 1977 06092A864886F70D010905310F170D3034303132363139313831345A30230609 1978 2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943 1979 95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E 1980 06082A864886F70D030202020080300D06082A864886F70D0302020140300706 1981 052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01 1982 010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C 1983 C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C 1984 822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087 1985 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 1986 79089AAD95767F 1988 ------590F24D439B31E08745DEF0CD9397189-- 1990 --my-boundary-9-- 1992 9. Transfer as an Ad-Hoc Conference 1994 In this flow, shown in Figure 16, Bob does an attended transfer of 1995 Alice to Carol. In order to keep both Alice and Carol fully informed 1996 of the nature and state of the transfer operation, Bob acts as a 1997 focus[RFC4579] and hosts an ad-hoc conference involving Alice, Bob, 1998 and Carol. Alice and Carol subscribe to the conference 1999 package[RFC4575] of Bob's focus, which allows them to know the exact 2000 status of the operation. After the transfer operation is complete, 2001 Bob deletes the conference. 2003 This call flow meets requirement 6 of Section 3. NOTIFY messages 2004 related to the refer package are indicated as NOTIFY (refer), while 2005 NOTIFYs related to the Conference Info package are indicated as 2006 NOTIFY (Conf-Info). 2008 Note that any type of semi-attended transfer in which media mixing or 2009 relaying could be implemented using this model. In addition to 2010 simply mixing, the focus could introduce additional media signals 2011 such as simulated ring tone or on hold announcements to improve the 2012 user experience. 2014 Alice Bob Carol 2015 | | | 2016 | INVITE | | 2017 |------------------->| | 2018 | 180 Ringing | | 2019 |<-------------------| | 2020 | 200 OK | | 2021 |<-------------------| | 2022 | ACK | | 2023 |------------------->| | 2024 | RTP | | 2025 |<==================>| | 2026 | | | 2027 Bob places Alice on hold and begins acting like a focus 2028 | | | 2029 | INVITE (hold) Contact:Conf-ID;isfocus | 2030 |<-------------------| | 2031 | 200 OK | | 2032 |------------------->| | 2033 | ACK | | 2034 |<-------------------| | 2035 | | | 2036 | Alice subscribes to the conference package 2037 | | | 2038 | SUBSCRIBE sip:Conf-ID | 2039 |------------------->| | 2040 | 200 OK | | 2041 |<-------------------| | 2042 | NOTIFY (Conf-Info) | | 2043 |<-------------------| | 2044 | 200 OK | | 2045 |------------------->| | 2046 | | | 2047 | Bob begins consultation operation | 2048 | | | 2049 |INVITE Require:replaces Contact:Conf-ID;isfocus 2050 | |------------------->| 2051 | | 180 Ringing | 2052 | |<-------------------| 2053 | | 200 OK | 2054 | |<-------------------| 2055 | | ACK | 2056 | |------------------->| 2057 | | RTP | 2058 | |<==================>| 2059 | | | 2060 |Carol subscribes to the conference package 2061 | - learns Bob is on hold | 2062 | | | 2063 | |SUBSCRIBE sip:Conf-ID 2064 | |<-------------------| 2065 | | 200 OK | 2066 | |------------------->| 2067 | | NOTIFY (Conf-Info) | 2068 | |------------------->| 2069 | | 200 OK | 2070 | |<-------------------| 2071 | | | 2072 | Alice learns that Bob is talking to Carol 2073 | | | 2074 | NOTIFY (Conf-Info) | | 2075 |<-------------------| | 2076 | 200 OK | | 2077 |------------------->| | 2078 | | INVITE (hold) | 2079 | |------------------->| 2080 | | 200 OK | 2081 | |<-------------------| 2082 | | ACK | 2083 | |------------------->| 2084 | | | 2085 | Alice learns that Carol is now on hold | 2086 | | | 2087 | NOTIFY (Conf-Info) | | 2088 |<-------------------| | 2089 | 200 OK | | 2090 |------------------->| | 2091 | | | 2092 | Bob begins transfer operation | 2093 | | | 2094 | REFER Refer-To: Carol | 2095 |<-------------------| | 2096 | 202 Accepted | | 2097 |------------------->| | 2098 | NOTIFY (Refer) | | 2099 |------------------->| | 2100 | 200 OK | | 2101 |<-------------------| | 2102 | INVITE Replaces:B-C Contact:Alice | 2103 |---------------------------------------->| 2104 | 200 OK | 2105 |<----------------------------------------| 2106 | ACK | 2107 |---------------------------------------->| 2108 | RTP | 2109 |<=======================================>| 2110 | | BYE | 2111 | |<-------------------| 2112 | | 200 OK | 2113 | |------------------->| 2114 | NOTIFY (Refer) | | 2115 |------------------->| | 2116 | 200 OK | | 2117 |<-------------------| | 2118 | | | 2119 | Bob terminates the ad-hoc conference | 2120 | | | 2121 | BYE | | 2122 |<-------------------| | 2123 | 200 OK | | 2124 |------------------->| | 2125 | | NOTIFY (Conf-Info) | 2126 | |------------------->| 2127 | | 200 OK | 2128 | |<-------------------| 2129 | NOTIFY (Conf-Info) | | 2130 |<-------------------| | 2131 | 200 OK | | 2132 |------------------->| | 2134 Figure 16. Attended Transfer as an Ad-Hoc Conference. 2136 10. Transfer with multiple parties 2138 In this example shown in Figure 17, the Originator places call to the 2139 Facilitator who reaches the Recipient through the Screener. The 2140 Recipient's contact information is exposed to the Facilitator and the 2141 Originator. This example is provided for clarification of the 2142 semantics of the REFER method only and should not be used as the 2143 design of an implementation. 2145 Originator Facilitator Screener Recipient 2146 | | | | 2147 1 |INVITE/200 OK/ACK | |"Get Fred for me!" 2148 |----------->| | | "Right away!" 2149 2 |INVITE (hold)/200 OK/ACK | | 2150 |<-----------| | | 2151 2 | |INVITE/200 OK/ACK |"I have a call 2152 | |----------->| |from Mary for Fred" 2153 2 | |INVITE (hold)/200 OK/ACK "Hold please" 2154 | |<-----------| | 2155 3 | | |INVITE/200 OK/ACK 2156 | | |--------->|"You have a call 2157 | | | |from Mary" 2158 | | | | "Put her through" 2159 3 | | |INVITE (hold)/200 OK/ACK 2160 | | |--------->| 2161 4 | |REFER | | 2162 | |<-----------| | 2163 4 | |202 Accepted| | 2164 | |----------->| | 2165 4 | |NOTIFY (100 Trying) | 2166 | |----------->| | 2167 4 | |200 OK | | 2168 | |<-----------| | 2169 5 | |INVITE/200 OK/ACK | 2170 | |---------------------->|"This is Fred" 2171 4 | |NOTIFY (200 OK) | "Please hold for 2172 | |----------->| | Mary" 2173 4 | |200 OK | | 2174 | |<-----------| | 2175 2 | |BYE/200 OK | | 2176 | |<-----------| | 2177 3 | | |BYE/200 OK| 2178 | | |--------->| 2179 5 | |INVITE (hold)/200 OK/ACK 2180 | |---------------------->| 2181 6 |REFER | | | 2182 |<-----------| | | 2183 6 |202 Accepted| | | 2184 |----------->| | | 2185 6 |NOTIFY (100 Trying) | | 2186 |----------->| | | 2187 6 |200 OK | | | 2188 |<-----------| | | 2189 7 |INVITE/200 OK/ACK | | 2190 |----------------------------------->| "Hey Fred" 2191 6 |NOTIFY (200 OK) | | "Hello Mary" 2192 |----------->| | | 2194 6 |200 OK | | | 2195 |<-----------| | | 2196 1 |BYE/200 OK | | | 2197 |<-----------| | | 2198 5 | |BYE/200 OK | | 2199 | |---------------------->| 2200 7 |BYE/200 OK | | | 2201 |<-----------------------------------| "See you later" 2203 Figure 17. Transfer with Multiple Parties Example. 2205 11. Gateway Transfer Issues 2207 A gateway in SIP acts as a User Agent. As a result, the entire 2208 preceding discussion and call flows apply equally well to gateways as 2209 native SIP endpoints. However, there are some gateway specific 2210 issues that are documented in this section. While this discussion 2211 focuses on the common cases involving PSTN gateways, similar 2212 situations exist for other gateways, such as H.323/SIP gateways. 2214 11.1. Coerce Gateway Hairpins to the Same Gateway 2216 To illustrate how a hairpin situation can occur in transfer, consider 2217 this example. The original call dialog is setup with the transferee 2218 residing on the PSTN side of a SIP gateway. The transferor is a SIP 2219 phone purely in the IP space. The transfer target is on the PSTN 2220 side of a SIP gateway as well. After completing the transfer, 2221 (regardless of consultative or blind) the transferee is in a call 2222 with the transfer target (both on the PSTN side of a gateway). It is 2223 often desirable to remove the gateway(s) out of the loop. This is 2224 likely to only be possible if both legs of the target call are on the 2225 same gateway. With both legs on the same gateway, it may be able to 2226 invoke the analogous transfer on the PSTN side. Then the target call 2227 would not involve the gateway. 2229 So the problem is how to give the proxy enough information so that it 2230 knows to route the call to the same gateway. With a simple single 2231 call that hairpins, the incoming and outgoing leg have the same 2232 dialog. The proxy should have enough information to optimize the 2233 routing. 2235 In the consultative transfer scenario, it is desirable to coerce the 2236 consultative INVITE out the same gateway as the original call to be 2237 transferred. However there is no way to relate the consultation with 2238 the original call. In the consultative case the target call INVITE 2239 includes the Replaces header which contains dialog information that 2240 can be used to relate it to the consultation. However there is no 2241 information that relates the target call to the original. 2243 In the blind transfer scenario, it is desirable to coerce the target 2244 call onto the same gateway as the original call. However the same 2245 problem exists in that the target dialog cannot be related to the 2246 original dialog. 2248 In either transfer scenario, it may be desirable to push the transfer 2249 operation onto the non-SIP side of the gateway. Presumably this is 2250 not possible unless all of the legs go out the same gateway. If the 2251 gateway supports more than one truck group, it might also be 2252 necessary to get all of the legs on the same trunk group in order to 2253 perform the transfer on the non-SIP side of the gateway. 2255 Solutions to these gateway specific issues may involve new extensions 2256 to SIP in the future. 2258 11.2. Consultative Turned Blind Gateway Glare 2260 In the consultative transfer case turned blind, there is a glare-like 2261 problem. The transferor initiates the consultation INVITE, the 2262 transferor gets impatient and hangs up, transitioning this to a blind 2263 transfer. The transfer target on the gateway (connected through a 2264 PSTN switch to a single line or dumb analog phone) rings. The user 2265 answers the phone just after the CANCEL is received by the transfer 2266 target. The REFER and INVITE for the target call are sent. The 2267 transferee attempts to setup the call on the PSTN side, but gets 2268 either a busy or lands in the users voicemail as the user has the 2269 handset in hand and off hook. 2271 This is another example of a race condition that this call flow can 2272 cause. The recommended behavior is to use the approach described in 2273 Section 6.6. 2275 12. IANA Considerations 2277 None. 2279 13. Security Considerations 2281 The call transfer flows shown in this document are implemented using 2282 the REFER and Replaces call control primitives in SIP. As such, the 2283 security considerations detailed in the REFER [RFC3515] and Replaces 2284 [RFC3891] documents MUST be followed, which are briefly summarized in 2285 the following paragraphs. This document addresses the issue of 2286 protecting the Address of Record URI of a transfer target in Sections 2287 7.1 and 7.2. 2289 Any REFER request must be appropriately authenticated and authorized 2290 using standard SIP mechanisms or calls may be hijacked. A user agent 2291 may use local policy or human intervention in deciding whether or not 2292 to accept a REFER. In generating NOTIFY responses based on the 2293 outcome of the triggered request, care should be taken in 2294 constructing the message/sipfrag body to ensure that no private 2295 information is leaked. 2297 An INVITE containing a Replaces header field should only be accepted 2298 if it has been properly authenticated and authorized using standard 2299 SIP mechanisms, and the requestor is authorized to perform dialog 2300 replacement. 2302 14. Acknowledgments 2304 This draft is a collaborative product of the SIP working group. 2305 Thanks to Rohan Mahy for his input on the use of Replaces in 2306 transfer. 2308 15. References 2310 15.1. Normative References 2312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2313 Requirement Levels", BCP 14, RFC 2119, March 1997. 2315 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2316 A., Peterson, J., Sparks, R., Handley, M., and E. 2317 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2318 June 2002. 2320 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2321 Method", RFC 3515, April 2003. 2323 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 2324 Protocol (SIP) "Replaces" Header", RFC 3891, 2325 September 2004. 2327 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 2328 Referred-By Mechanism", RFC 3892, September 2004. 2330 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 2331 Identification in the Session Initiation Protocol (SIP)", 2332 RFC 4538, June 2006. 2334 15.2. Informative References 2336 [I-D.ietf-sipping-cc-framework] 2337 Mahy, R., Sparks, R., Rosenberg, J., Petrie, D., and A. 2338 Johnston, "A Call Control and Multi-party usage framework 2339 for the Session Initiation Protocol (SIP)", 2340 draft-ietf-sipping-cc-framework-10 (work in progress), 2341 April 2008. 2343 [I-D.ietf-sip-gruu] 2344 Rosenberg, J., "Obtaining and Using Globally Routable User 2345 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 2346 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 2347 October 2007. 2349 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 2350 and H. Schulzrinne, "Session Initiation Protocol (SIP) 2351 Torture Test Messages", RFC 4475, May 2006. 2353 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 2354 Session Initiation Protocol (SIP)", RFC 4353, 2355 February 2006. 2357 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 2358 (SIP) Call Control - Conferencing for User Agents", 2359 BCP 119, RFC 4579, August 2006. 2361 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 2362 Initiation Protocol (SIP) Event Package for Conference 2363 State", RFC 4575, August 2006. 2365 [I-D.ietf-sipping-dialogusage] 2366 Sparks, R., "Multiple Dialog Usages in the Session 2367 Initiation Protocol", draft-ietf-sipping-dialogusage-06 2368 (work in progress), February 2007. 2370 Authors' Addresses 2372 Robert J. Sparks 2373 Estacado Systems 2375 Email: RjS@estacado.net 2376 Alan Johnston (editor) 2377 Avaya 2378 St. Louis, MO 2380 Email: alan@sipstation.com 2382 Daniel Petrie 2383 SIPez LLC 2384 34 Robbins Rd. 2385 Arlington, MA 02476 2386 US 2388 Phone: +1 617 273 4000 2389 Email: dan.ietf AT SIPez DOT com 2390 URI: http://www.SIPez.com/ 2392 Full Copyright Statement 2394 Copyright (C) The IETF Trust (2008). 2396 This document is subject to the rights, licenses and restrictions 2397 contained in BCP 78, and except as set forth therein, the authors 2398 retain all their rights. 2400 This document and the information contained herein are provided on an 2401 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2402 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2403 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2404 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2405 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2406 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2408 Intellectual Property 2410 The IETF takes no position regarding the validity or scope of any 2411 Intellectual Property Rights or other rights that might be claimed to 2412 pertain to the implementation or use of the technology described in 2413 this document or the extent to which any license under such rights 2414 might or might not be available; nor does it represent that it has 2415 made any independent effort to identify any such rights. Information 2416 on the procedures with respect to rights in RFC documents can be 2417 found in BCP 78 and BCP 79. 2419 Copies of IPR disclosures made to the IETF Secretariat and any 2420 assurances of licenses to be made available, or the result of an 2421 attempt made to obtain a general license or permission for the use of 2422 such proprietary rights by implementers or users of this 2423 specification can be obtained from the IETF on-line IPR repository at 2424 http://www.ietf.org/ipr. 2426 The IETF invites any interested party to bring to its attention any 2427 copyrights, patents or patent applications, or other proprietary 2428 rights that may cover technology that may be required to implement 2429 this standard. Please address the information to the IETF at 2430 ietf-ipr@ietf.org.