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