idnits 2.17.1 draft-ietf-sipping-cc-transfer-09.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 2394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2418. 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 (November 28, 2007) is 5992 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 (-01) exists of draft-sparks-sipping-dialogusage-00 Summary: 1 error (**), 0 flaws (~~), 4 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: May 31, 2008 D. Petrie 7 SIPez LLC 8 November 28, 2007 10 Session Initiation Protocol Call Control - Transfer 11 draft-ietf-sipping-cc-transfer-09 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 May 31, 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 . . . . . . . . . . . . . . . . . . 56 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 supports REFER[3] and Replaces[4] in addition to RFC 101 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 support 103 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 6.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;gr=3413kj2ha 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;gr=723jd2d 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;gr=723jd2d 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;gr=723jd2d 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;gr=723jd2d 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 568 6.3. Failed Transfer 570 This section shows examples of failed transfer attempts. After the 571 transfer failure occurs, the Transferor takes the Transferee off hold 572 and resumes the session. 574 6.3.1. Target Busy 575 Transferor Transferee Transfer 576 | | Target 577 | | | 578 | INVITE | | 579 dialog1 |<-------------------| | 580 | 200 OK | | 581 dialog1 |------------------->| | 582 | ACK | | 583 dialog1 |<-------------------| | 584 | INVITE (hold) | | 585 dialog1 |------------------->| | 586 | 200 OK | | 587 dialog1 |<-------------------| | 588 | ACK | | 589 dialog1 |------------------->| | 590 | REFER (Target-Dialog:1) | 591 dialog2 |------------------->| | 592 | 202 Accepted | | 593 dialog2 |<-------------------| | 594 | NOTIFY (100 Trying)| | 595 dialog2 |<-------------------| | 596 | 200 OK | | 597 dialog2 |------------------->| | 598 | | INVITE | 599 dialog3 | |------------------->| 600 | | 486 Busy Here | 601 dialog3 | |<-------------------| 602 | | ACK | 603 dialog3 | |------------------->| 604 | NOTIFY (503 Service Unavailable) | 605 | or NOTIFY (486 Busy Here) | 606 dialog2 |<-------------------| | 607 | 200 OK | | 608 dialog2 |------------------->| | 609 | INVITE (unhold) | | 610 dialog1 |------------------->| | 611 | 200 OK | | 612 dialog1 |<-------------------| | 613 | ACK | | 614 dialog1 |------------------->| | 615 | BYE | | 616 dialog1 |------------------->| | 617 | 200 OK | | 618 dialog1 |<-------------------| | 620 Figure 3. Failed Transfer - Target Busy 622 6.3.2. Transfer Target does not answer 624 Transferor Transferee Transfer 625 | | Target 626 | INVITE | | 627 dialog1 |<-------------------| | 628 | 200 OK | | 629 dialog1 |------------------->| | 630 | ACK | | 631 dialog1 |<-------------------| | 632 | INVITE (hold) | | 633 dialog1 |------------------->| | 634 | 200 OK | | 635 dialog1 |<-------------------| | 636 | ACK | | 637 dialog1 |------------------->| | 638 | REFER | | 639 dialog2 |------------------->| | 640 | 202 Accepted | | 641 dialog2 |<-------------------| | 642 | NOTIFY (100 Trying)| | 643 dialog2 |<-------------------| | 644 | 200 OK | | 645 dialog2 |------------------->| | 646 | | INVITE | 647 dialog3 | |------------------->| 648 | | 180 Ringing | 649 dialog3 | |<-------------------| 650 | (Transferee gets tired of waiting) 651 | | CANCEL | 652 dialog3 | |------------------->| 653 | | 200 OK (CANCEL) | 654 dialog3 | |<-------------------| 655 | 487 Request Cancelled (INVITE) 656 dialog3 | |<-------------------| 657 | | ACK | 658 dialog3 | |------------------->| 659 | NOTIFY (487 Request Cancelled) | 660 dialog2 |<-------------------| | 661 | 200 OK | | 662 dialog2 |------------------->| | 663 | INVITE (unhold) | | 664 dialog1 |------------------->| | 665 | 200 OK | | 666 dialog1 |<-------------------| | 667 | ACK | | 668 dialog1 |------------------->| | 669 | BYE | | 670 dialog1 |------------------->| | 671 | 200 OK | | 672 dialog1 |<-------------------| | 674 Figure 4. Failed Transfer - Target Does Not Answer. 676 7. Transfer with Consultation Hold 678 Transfer with Consultation Hold involves a session between the 679 transferor and the transfer target before the transfer actually takes 680 place. This is implemented with SIP Hold and Transfer as described 681 above. 683 A nice feature is for the transferor to let the target know that the 684 session relates to an intended transfer. Since many UAs render the 685 display name in the From header field to the user, a consultation 686 INVITE could contain a string such as "Incoming consultation from 687 Transferor with intent to transfer Transferee", where the display 688 names of the transferor and transferee are included in the string. 690 7.1. Exposing transfer target 692 The transferor places the transferee on hold, establishes a call with 693 the transfer target to alert them to the impending transfer, 694 terminates the connection with the transfer target, then proceeds 695 with transfer as above. This variation can be used to provide an 696 experience similar to that expected by current PBX and Centrex users. 698 To (hopefully) improve clarity, non-REFER transactions have been 699 collapsed into one indicator with the arrow showing the direction of 700 the request. 702 Transferor Transferee Transfer 703 | | Target 704 | | | 705 dialog1 | INVITE/200 OK/ACK | | 706 |<-------------------| | 707 dialog1 | INVITE (hold)/200 OK/ACK | 708 |------------------->| | 709 dialog2 | INVITE/200 OK/ACK | | 710 |---------------------------------------->| 711 dialog2 | BYE/200 OK | | 712 |---------------------------------------->| 713 dialog3 | REFER | | 714 |------------------->| | 715 dialog3 | 202 Accepted | | 716 |<-------------------| | 717 dialog3 | NOTIFY (100 Trying)| | 718 |<-------------------| | 719 dialog3 | 200 OK | | 720 |------------------->| | 721 dialog4 | | INVITE/200 OK/ACK | 722 | |------------------->| 723 dialog3 | NOTIFY (200 OK) | | 724 |<-------------------| | 725 dialog3 | 200 OK | | 726 |------------------->| | 727 dialog1 | BYE/200 OK | | 728 |------------------->| | 729 dialog4 | | BYE/200 OK | 730 | |<-------------------| 732 Figure 5. Transfer with Consultation Hold - Exposing Transfer 733 Target. 735 7.2. Protecting transfer target 737 The transferor places the transferee on hold, establishes a call with 738 the transfer target and then reverses their roles, transferring the 739 original transfer target to the original transferee. This has the 740 advantage of hiding information about the original transfer target 741 from the original transferee. On the other hand, the Transferee's 742 experience is different that in current systems. The Transferee is 743 effectively "called back" by the Transfer Target. 745 One of the problems with this simplest implementation of a target 746 protecting transfer is that the transferee is receiving a new call 747 from the transfer-target. Unless the transferee's agent has a 748 reliable way to associate this new call with the call it already has 749 with the transferor, it will have to alert the new call on another 750 appearance. If this, or some other call-waiting-like UI were not 751 available, the transferee might be stuck returning a Busy-Here to the 752 transfer target, effectively preventing the transfer. There are many 753 ways that that correlation could be provided. The dialog parameters 754 could be provided directly as header parameters in the Refer-To: URI 755 for example. The Replaces mechanism [4] uses this approach and 756 solves this problem nicely. 758 For the flow below, dialog1 means dialog identifier 1, and consists 759 of the parameters of the Replaces header for dialog 1. In [4] this 760 is the Call-ID, To-tag and From-tag. 762 Note that the transferee's agent emits a BYE to the transferor's 763 agent as an immediate consequence of processing the Replaces header. 765 The Transferor knows that both the Transferee and the Transfer Target 766 support the Replaces header from the Supported: replaces header 767 contained in the 200 OK responses from both. 769 In this scenario, the Transferee utilizes a GRUU as a Contact URI for 770 reasons discussed in Section 6.3. 772 Note that the conventions used in the SIP Torture Test Messages [9] 773 document are reused, specifically the tag. 775 Transferor Transferee Transfer 776 | | Target 777 | | | 778 dialog1 | INVITE/200 OK/ACK F1 F2 | 779 |<-------------------| | 780 dialog1 | INVITE (hold)/200 OK/ACK | 781 |------------------->| | 782 dialog2 | INVITE/200 OK/ACK F3 F4 | 783 |---------------------------------------->| 784 dialog2 | INVITE (hold)/200 OK/ACK | 785 |---------------------------------------->| 786 dialog3 | REFER (Target-Dialog:2, | 787 | Refer-To:sips:Transferee?Replaces=1) F5| 788 |---------------------------------------->| 789 dialog3 | 202 Accepted | | 790 |<----------------------------------------| 791 dialog3 | NOTIFY (100 Trying)| | 792 |<----------------------------------------| 793 dialog3 | | 200 OK | 794 |---------------------------------------->| 795 dialog4 | INVITE (Replaces:dialog1)/200 OK/ACK F6 796 | |<-------------------| 797 dialog1 | BYE/200 OK | | 798 |<-------------------| | 799 dialog3 | NOTIFY (200 OK) | | 800 |<----------------------------------------| 801 dialog3 | | 200 OK | 802 |---------------------------------------->| 803 dialog2 | BYE/200 OK | | 804 |---------------------------------------->| 805 | (transferee and target converse) 806 dialog4 | | BYE/200 OK | 807 | |------------------->| 809 Figure 6. Transfer Protecting Transfer Target. 811 F1 INVITE Transferee -> Transferor 813 INVITE sips:transferor@atlanta.example.com SIP/2.0 814 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 815 Max-Forwards: 70 816 To: 817 From: ;tag=7553452 818 Call-ID: 090459243588173445 819 CSeq: 29887 INVITE 820 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 821 Supported: replaces, gruu 822 Contact: 823 Content-Type: application/sdp 824 Content-Length: ... 826 F2 200 OK Transferor -> Transferee 828 SIP/2.0 200 OK 829 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 830 To: ;tag=31431 831 From: ;tag=7553452 832 Call-ID: 090459243588173445 833 CSeq: 29887 INVITE 834 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 835 Supported: replaces, gruu, tdialog 836 Contact: 837 Content-Type: application/sdp 838 Content-Length: ... 840 F3 INVITE Transferor -> Transfer Target 842 INVITE sips:transfertarget@chicago.example.com SIP/2.0 843 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 844 Max-Forwards: 70 845 To: 846 From: ;tag=763231 847 Call-ID: 592435881734450904 848 CSeq: 29887 INVITE 849 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 850 Supported: gruu, replaces, tdialog 851 Require: replaces 852 Contact: 853 Content-Type: application/sdp 854 Content-Length: ... 856 F4 200 OK Transfer Target -> Transferor 858 SIP/2.0 200 OK 859 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 860 ;received=192.0.2.1 861 To: ;tag=9m2n3wq 862 From: ;tag=763231 863 Call-ID: 592435881734450904 864 CSeq: 29887 INVITE 865 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 866 Supported: replaces, gruu, tdialog 867 Contact: 868 Content-Type: application/sdp 869 Content-Length: ... 871 F5 REFER Transferor -> Transfer Target 873 REFER sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 874 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 875 Max-Forwards: 70 876 To: 877 From: ;tag=1928301774 878 Call-ID: a84b4c76e66710 879 CSeq: 314159 REFER 880 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 881 Supported: gruu, replaces, tdialog 882 Require: tdialog 883 884 Refer-To: 886 887 Target-Dialog: 592435881734450904;local-tag=9m2n3wq 888 ;remote-tag=763231 889 Contact: 890 Content-Length: 0 892 F6 INVITE Transfer Target -> Transferee 894 INVITE sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 895 Via: SIP/2.0/TLS client.chicago.example.com;branch=z9hG4bKnaslu84 896 Max-Forwards: 70 897 To: 898 From: ;tag=341234 899 Call-ID: kmzwdle3dl3d08 900 CSeq: 41 INVITE 901 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 902 Supported: gruu, replaces, tdialog 903 Contact: 904 Replaces: 090459243588173445;to-tag=7553452;from-tag=31431 905 Content-Type: application/sdp 906 Content-Length: ... 908 7.3. Attended Transfer 910 The transferor places the transferee on hold, establishes a call with 911 the transfer target to alert them to the impending transfer, places 912 the target on hold, then proceeds with transfer using an escaped 913 Replaces header field in the Refer-To header. This is another common 914 service expected by current PBX and Centrex users. 916 The Contact URI of the Transfer Target SHOULD be used by the 917 Transferor as the Refer-To URI, unless the URI is suspected or known 918 to not be routable outside the dialog. Otherwise, the Address of 919 Record (AOR) of the Transfer Target should be used. That is, the 920 same URI that the Transferor used to establish the session with the 921 Transfer Target should be used. In case the triggered INVITE is 922 routed to a different User Agent than the Transfer Target, the 923 Require: replaces header field should be used in the triggered 924 INVITE. (This is to prevent an incorrect User Agent which does not 925 support Replaces from ignoring the Replaces and answering the INVITE 926 without a dialog match.) 928 It is possible that proxy/service routing may prevent the triggered 929 INVITE from reaching the same User Agent. If this occurs, the 930 triggered invite will fail with a timout, 403, 404, etc error. The 931 Transferee MAY then retry the transfer with the Refer-To URI set to 932 the Contact URI. 934 Transferor Transferee Transfer 935 | | Target 936 | | | 937 dialog1 | INVITE/200 OK/ACK F1 F2 | 938 |<-------------------| | 939 dialog1 | INVITE (hold)/200 OK/ACK | 940 |------------------->| | 941 dialog2 | INVITE/200 OK/ACK F3 F4 | 942 |---------------------------------------->| 943 dialog2 | INVITE (hold)/200 OK/ACK | 944 |---------------------------------------->| 945 dialog3 | REFER (Target-Dialog:1, | 946 | Refer-To:sips:TransferTarget?Replaces=2) F5 947 |------------------->| | 948 dialog3 | 202 Accepted | | 949 |<-------------------| | 950 dialog3 | NOTIFY (100 Trying)| | 951 |<-------------------| | 952 dialog3 | 200 OK | | 953 |------------------->| | 954 dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6 955 | |------------------->| 956 dialog2 | BYE/200 OK | | 957 |<----------------------------------------| 958 dialog3 | NOTIFY (200 OK) | | 959 |<-------------------| | 960 dialog3 | 200 OK | | 961 |------------------->| | 962 dialog1 | BYE/200 OK | | 963 |------------------->| | 964 dialog4 | | BYE/200 OK | 965 | |<-------------------| 967 Figure 7. Attended Transfer Call Flow. 969 F1 INVITE Transferee -> Transferor 971 INVITE sips:transferor@atlanta.example.com SIP/2.0 972 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 973 Max-Forwards: 70 974 To: 975 From: ;tag=7553452 976 Call-ID: 090459243588173445 977 CSeq: 29887 INVITE 978 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 979 Supported: replaces, gruu, tdialog 980 Contact: 981 Content-Type: application/sdp 982 Content-Length: ... 984 F2 200 OK Transferor -> Transferee 986 SIP/2.0 200 OK 987 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 988 To: ;tag=31431 989 From: ;tag=7553452 990 Call-ID: 090459243588173445 991 CSeq: 29887 INVITE 992 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 993 Supported: replaces, gruu, tdialog 994 Contact: 995 Content-Type: application/sdp 996 Content-Length: ... 998 F3 INVITE Transferor -> Transfer Target 1000 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1001 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1002 Max-Forwards: 70 1003 To: 1004 From: ;tag=763231 1005 Call-ID: 592435881734450904 1006 CSeq: 29887 INVITE 1007 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1008 Supported: gruu, replaces, tdialog 1009 Require: replaces 1010 Contact: 1011 Content-Type: application/sdp 1012 Content-Length: ... 1014 F4 200 OK Transfer Target -> Transferor 1016 SIP/2.0 200 OK 1017 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1018 ;received=192.0.2.1 1019 To: ;tag=9m2n3wq 1020 From: ;tag=763231 1021 Call-ID: 592435881734450904 1022 CSeq: 29887 INVITE 1023 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1024 Supported: replaces, gruu 1025 Contact: 1026 Content-Type: application/sdp 1027 Content-Length: ... 1029 F5 REFER Transferor -> Transferee 1031 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 1032 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1033 Max-Forwards: 70 1034 To: 1035 From: ;tag=1928301774 1036 Call-ID: a84b4c76e66710 1037 CSeq: 314159 REFER 1038 Require: tdialog 1039 1040 Refer-To: 1042 1043 Target-Dialog: 592435881734450904;local-tag=9m2n3wq 1044 ;remote-tag=763231 1045 Contact: 1046 Content-Length: 0 1048 F6 INVITE Transferee -> Transfer Target 1050 INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 1051 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 1052 Max-Forwards: 70 1053 To: 1054 From: ;tag=954 1055 Call-ID: kmzwdle3dl3d08 1056 CSeq: 41 INVITE 1057 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1058 Supported: gruu, replaces, tdialog 1059 Contact: 1060 Replaces: 592435881734450904;to-tag=9m2n3wq;from-tag=763231 1061 Content-Type: application/sdp 1062 Content-Length: ... 1064 7.4. Recovery when one party does not support REFER 1066 If protecting or exposing the transfer target is not a concern, it is 1067 possible to complete a transfer with consultation hold when only the 1068 transferor and one other party support REFER. Note that a 405 Method 1069 Not Allowed might be returned instead of the 501 Not Implemented 1070 response. 1072 Transferor Transferee Transfer 1073 | | Target 1074 | | | 1075 dialog1 | INVITE/200 OK/ACK | | 1076 |<-------------------| | 1077 dialog1 | INVITE (hold)/200 OK/ACK | 1078 |------------------->| | 1079 dialog2 | INVITE/200 OK/ACK | | 1080 |---------------------------------------->| 1081 dialog2 | INVITE (hold)/200 OK/ACK | 1082 |---------------------------------------->| 1083 dialog3 | REFER (Target-Dialog:1, | 1084 | Refer-To:sips:TransferTarget?Replaces=2) 1085 |------------------->| | 1086 dialog3 | 501 Not Implemented | 1087 |<-------------------| | 1088 dialog4 | REFER (Refer-To:sips:Transferee?Replaces=dialog1) 1089 |---------------------------------------->| 1090 dialog4 | 202 Accepted | | 1091 |<----------------------------------------| 1092 dialog4 | NOTIFY (100 Trying)| | 1093 |<----------------------------------------| 1094 dialog4 | | 200 OK | 1095 |---------------------------------------->| 1096 dialog5 | INVITE (Replaces:dialog1)/200 OK/ACK 1097 | |<-------------------| 1098 dialog4 | NOTIFY (200 OK) | | 1099 |<----------------------------------------| 1100 dialog4 | | 200 OK | 1101 |---------------------------------------->| 1102 dialog1 | BYE/200 OK | | 1103 |<-------------------| | 1104 dialog2 | BYE/200 OK | | 1105 |---------------------------------------->| 1106 dialog5 | | BYE/200 OK | 1107 | |------------------->| 1109 Figure 8. Recovery when one party does not support REFER. 1111 7.5. Attended transfer when Contact URI is not known to route to a 1112 unique user agent. 1114 It is a requirement of RFC3261 that a Contact URI be globally 1115 routable even outside the dialog. However, due to RFC2543 User 1116 Agents and some architectures (NAT/Firewall traversal, screening 1117 proxies, ALGs, etc.) this will not always be the case. As a result, 1118 the method of Attended Transfer shown in Figures 6, 7, and 8 should 1119 only be used if the Contact URI is known to be routable outside the 1120 dialog. 1122 Figure 9 shows such a scenario where the Transfer Target Contact URI 1123 is not routable outside the dialog, so the triggered INVITE is sent 1124 to the AOR of the Transfer Target. 1126 Transferor Transferee Screening Transfer 1127 | | Proxy Target 1128 | | | | 1129 dialog1 | INVITE/200 OK/ACK| | | 1130 |<-----------------| | | 1131 dialog1 | INVITE (hold)/200 OK/ACK | | 1132 |----------------->| | | 1133 dialog2 | INVITE/200 OK/ACK F1 F2 | | 1134 |--------------------------------|------------>| 1135 dialog2 | INVITE (hold)/200 OK/ACK | 1136 |--------------------------------|------------>| 1137 dialog1 | REFER (Refer-To:sips:TargetAOR | 1138 | ?Replaces=dialog2&Require=replaces) F3 1139 |----------------->| | | 1140 dialog1 | 202 Accepted | | | 1141 |<-----------------| | | 1142 dialog1 | NOTIFY (100 Trying) | | 1143 |<-----------------| | | 1144 dialog1 | 200 OK | | | 1145 |----------------->| | | 1146 dialog4 |INVITE (Replaces:dialog2,Require:replaces)/200 OK/ACK F6 1147 | |------------>|------------>| 1148 dialog2 | BYE/200 OK | | | 1149 |<-------------------------------|<------------| 1150 dialog1 | NOTIFY (200 OK) F7 | | 1151 |<-----------------| | | 1152 dialog1 | 200 OK | | | 1153 |----------------->| | | 1154 dialog1 | BYE/200 OK | | | 1155 |----------------->| | | 1156 dialog3 | | | BYE/200 OK | 1157 | |<------------|-------------| 1159 Figure 9. Attended Transfer Call Flow with a Contact URI not known 1160 to be Globally Routable 1162 F1 INVITE Transferor -> Transfer Target 1164 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1165 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76 1166 Max-Forwards: 70 1167 To: 1168 From: ;tag=763231 1169 Call-ID: 090459243588173445 1170 CSeq: 29887 INVITE 1171 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1172 Supported: replaces 1173 Contact: 1174 Content-Type: application/sdp 1175 Content-Length: ... 1177 F2 200 OK Transfer Target -> Transferee 1179 SIP/2.0 200 OK 1180 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1181 ;received=192.0.2.1 1182 To: ;tag=9m2n3wq 1183 From: ;tag=763231 1184 Call-ID: 090459243588173445 1185 CSeq: 29887 INVITE 1186 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1187 Supported: replaces 1188 Contact: 1189 Content-Type: application/sdp 1190 Content-Length: ... 1192 F3 REFER Transferor -> Transferee 1194 REFER sips:transferee@192.0.2.4 SIP/2.0 1195 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1196 Max-Forwards: 70 1197 To: ;tag=a6c85cf 1198 From: ;tag=1928301774 1199 Call-ID: a84b4c76e66710 1200 CSeq: 314160 REFER 1201 1202 Refer-To: 1205 1206 Contact: 1207 Content-Length: 0 1209 F4 INVITE Transferee -> Transfer Target 1211 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1212 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 1213 Max-Forwards: 70 1214 To: 1215 From: ;tag=954 1216 Call-ID: 20482817324945934422930 1217 CSeq: 42 INVITE 1218 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1219 Supported: replaces 1220 Contact: 1221 Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 1222 Require: replaces 1223 Content-Type: application/sdp 1224 Content-Length: ... 1226 F5 NOTIFY Transferee -> Transferor 1228 NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 1229 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 1230 Max-Forwards: 70 1231 To: ;tag=1928301774 1232 From: ;tag=a6c85cf 1233 Call-ID: a84b4c76e66710 1234 CSeq: 76 NOTIFY 1235 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1236 Supported: replaces 1237 Event: refer;id=98873867 1238 Subscription-State: terminated;reason=noresource 1239 Content-Type: message/sipfrag 1240 Content-Length: ... 1242 SIP/2.0 200 OK 1244 Figure 10 shows a failure case in which the AOR URI fails to reach 1245 the transfer Target. As a result, the transfer is retried with the 1246 Contact URI which succeeds. 1248 Note that there is still no guarantee that the correct endpoint will 1249 be reached, and the result of this second REFER may also be a 1250 failure. In that case, the Transferor could fall back to unattended 1251 transfer or give up on the transfer entirely. Since two REFERs are 1252 sent within the dialog creating two distinct subscriptions, the 1253 Transferee uses the 'id' parameter in the Event header field to 1254 distinguish notifications for the two subscriptions. 1256 Transferor Transferee Screening Transfer 1257 | | Proxy Target 1258 | | | | 1259 dialog1 | INVITE/200 OK/ACK| | | 1260 |<-----------------| | | 1261 dialog1 | INVITE (hold)/200 OK/ACK | | 1262 |----------------->| | | 1263 dialog2 | INVITE/200 OK/ACK F1 F2 | | 1264 |--------------------------------|------------>| 1265 dialog2 | INVITE (hold)/200 OK/ACK | 1266 |--------------------------------|------------>| 1267 dialog1 | REFER (Refer-To:sips:TargetAOR? | 1268 | Replaces=dialog2&Require=replaces) F3 | 1269 |----------------->| | | 1270 dialog1 | 202 Accepted | | | 1271 |<-----------------| | | 1272 dialog1 | NOTIFY (100 Trying) | | 1273 |<-----------------| | | 1274 dialog1 | 200 OK | | | 1275 |----------------->| | | 1276 dialog3 | |INVITE (Replaces:dialog2, | 1277 | | Require:replaces)/403/ACK | 1278 | |------------>| | 1279 dialog1 | NOTIFY (403 Forbidden) F4 | | 1280 |<-----------------| | | 1281 dialog1 | 200 OK | | | 1282 |----------------->| | | 1283 dialog1 |REFER(Refer-To:sips:TargetContact?Replaces=dialog2) F5 1284 |----------------->| | | 1285 dialog1 | 202 Accepted | | | 1286 |<-----------------| | | 1287 dialog1 | NOTIFY (100 Trying) | | 1288 |<-----------------| | | 1289 dialog1 | 200 OK | | | 1290 |----------------->| | | 1291 dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6 1292 | |------------>|------------>| 1293 dialog2 | BYE/200 OK | | | 1294 |<-------------------------------|<------------| 1295 dialog1 | NOTIFY (200 OK) F7 | | 1296 |<-----------------| | | 1297 dialog1 | 200 OK | | | 1298 |----------------->| | | 1299 dialog1 | BYE/200 OK | | | 1300 |----------------->| | | 1301 dialog3 | | | BYE/200 OK | 1302 | |<------------|-------------| 1304 Figure 10. Attended Transfer Call Flow with non-routable Contact URI 1305 and AOR Failure 1307 F1 INVITE Transferor -> Transfer Target 1309 INVITE sips:transfertarget@chicago.example.com SIP/2.0 1310 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76 1311 Max-Forwards: 70 1312 To: 1313 From: ;tag=763231 1314 Call-ID: 090459243588173445 1315 CSeq: 29887 INVITE 1316 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1317 Supported: replaces 1318 Contact: 1319 Content-Type: application/sdp 1320 Content-Length: ... 1322 F2 200 OK Transfer Target -> Transferee 1324 SIP/2.0 200 OK 1325 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432 1326 ;received=192.0.2.1 1327 To: ;tag=9m2n3wq 1328 From: ;tag=763231 1329 Call-ID: 090459243588173445 1330 CSeq: 29887 INVITE 1331 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1332 Supported: replaces 1333 Contact: 1334 Content-Type: application/sdp 1335 Content-Length: ... 1337 F3 REFER Transferor -> Transferee 1339 REFER sips:transferee@192.0.2.4 SIP/2.0 1340 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1341 Max-Forwards: 70 1342 To: ;tag=a6c85cf 1343 From: ;tag=1928301774 1344 Call-ID: a84b4c76e66710 1345 CSeq: 314159 REFER 1346 1347 Refer-To: 1350 1351 Contact: 1352 Content-Length: 0 1354 F4 NOTIFY Transferee -> Transferor 1356 NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 1357 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 1358 Max-Forwards: 70 1359 To: ;tag=1928301774 1360 From: ;tag=a6c85cf 1361 Call-ID: a84b4c76e66710 1362 CSeq: 74 NOTIFY 1363 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1364 Supported: replaces 1365 Event: refer;id=314159 1366 Subscription-State: terminated;reason=noresource 1367 Content-Type: message/sipfrag 1368 Content-Length: ... 1370 SIP/2.0 403 Forbidden 1372 F5 REFER Transferor -> Transferee 1374 REFER sips:transferee@192.0.2.4 SIP/2.0 1375 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 1376 Max-Forwards: 70 1377 To: ;tag=a6c85cf 1378 From: ;tag=1928301774 1379 Call-ID: a84b4c76e66710 1380 CSeq: 314160 REFER 1381 1382 Refer-To: 1385 1386 Contact: 1387 Content-Length: 0 1389 F6 INVITE Transferee -> Transfer Target 1391 INVITE sips:transfertarget@client.chicago.example.com SIP/2.0 1392 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82 1393 Max-Forwards: 70 1394 To: 1395 From: ;tag=954 1396 Call-ID: 20482817324945934422930 1397 CSeq: 42 INVITE 1398 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1399 Supported: replaces 1400 Contact: 1401 Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 1402 Content-Type: application/sdp 1403 Content-Length: ... 1405 F7 NOTIFY Transferee -> Transferor 1407 NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 1408 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 1409 Max-Forwards: 70 1410 To: ;tag=1928301774 1411 From: ;tag=a6c85cf 1412 Call-ID: a84b4c76e66710 1413 CSeq: 76 NOTIFY 1414 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1415 Supported: replaces 1416 Event: refer;id=314160 1417 Subscription-State: terminated;reason=noresource 1418 Content-Type: message/sipfrag 1419 Content-Length: ... 1421 SIP/2.0 200 OK 1423 To prevent this scenario from happening, the Transfer Target should 1424 use a Contact URI which is routable outside the dialog, which will 1425 result in the call flow of Figure 7. 1427 7.6. Semi-Attended Transfer 1429 In any of the consultation hold flows above, the Transferor may 1430 decide to terminate its attempt to contact the Transfer target before 1431 that session is established. Most frequently, that will be the end 1432 of the scenario, but in some circumstances, the transferor may wish 1433 to proceed with the transfer action. For example, the Transferor may 1434 wish to complete the transfer knowing that the transferee will end up 1435 eventually talking to the transfer-target's voice-mail service. Some 1436 PBX systems support this feature, sometimes called "semi-attended 1437 transfer", that is effectively a hybrid between a fully attended 1438 transfer and an unattended transfer. A call flow is shown in Figure 1439 11. In this flow, the Transferor's User Agent continues the transfer 1440 as an attended transfer even after the Transferor hangs up. Note 1441 that media must be played to the Transfer Target upon answer - 1442 otherwise, the Target may hang up and the resulting transfer 1443 operation will fail. 1445 Transferor Transferee Transfer 1446 | | Target 1447 | | | 1448 dialog1 | INVITE/200 OK/ACK F1 F2 | 1449 |<-------------------| | 1450 dialog1 | INVITE (hold)/200 OK/ACK | 1451 |------------------->| | 1452 dialog2 | INVITE | | 1453 |---------------------------------------->| 1454 dialog2 | | 180 Ringing | 1455 |<----------------------------------------| 1456 Transferor hangs up but wants transfer to continue 1457 | | | 1458 | User Agent continues transfer operation | 1459 | | | 1460 dialog2 | | 200 OK | 1461 |<----------------------------------------| 1462 dialog2 | ACK | | 1463 |---------------------------------------->| 1464 dialog2 | Media Played to keep Target from hanging up 1465 |========================================>| 1466 dialog3 | REFER (Target-Dialog:1, | 1467 | Refer-To:sips:TransferTarget?Replaces=2) 1468 |------------------->| | 1469 dialog3 | 202 Accepted | | 1470 |<-------------------| | 1471 dialog3 | NOTIFY (100 Trying)| | 1472 |<-------------------| | 1473 dialog3 | 200 OK | | 1474 |------------------->| | 1475 dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK 1476 | |------------------->| 1477 dialog2 | BYE/200 OK | | 1478 |<----------------------------------------| 1479 dialog3 | NOTIFY (200 OK) | | 1480 |<-------------------| | 1481 dialog3 | 200 OK | | 1482 |------------------->| | 1483 dialog1 | BYE/200 OK | | 1484 |------------------->| | 1485 dialog4 | | BYE/200 OK | 1486 | |<-------------------| 1488 Figure 11. Recommended Semi-Attended Transfer Call Flow. 1490 Two other possible semi-attended transfer call flows are shown in 1491 Figures 12 and 13. However, these call flows are NOT RECOMMENDED due 1492 to a race conditions. In both of these flows, when the Transferor 1493 hangs up, the User Agent attempts to revert to unattended transfer by 1494 sending a CANCEL to the Target. This can result in two race 1495 conditions. One is that the Target answers despite the CANCEL and 1496 the resulting unattended transfer fails. This race condition can be 1497 eliminated by the Transferor waiting to send the REFER until the 487 1498 response from the Target is returned. Instead of a 487, a 200 OK may 1499 return indicating that the Target has answered the consultation call. 1500 In this, case the call flow in Figure 13 must be followed. In this 1501 flow, the Transferor must play some kind of media to the Target to 1502 prevent the Target from hanging up, or the Transfer will fail. That 1503 is, the human at the Transfer Target will hear silence from when they 1504 answer (message F1) until the transfer completes (F3 and they are 1505 talking to the Transferee unless some media is played (F2). 1507 The second race condition occurs in Figure 12 if the Transfer Target 1508 goes "off hook" after the CANCEL is received and the 487 returned. 1509 This may result in a 486 Busy Here response to the unattended 1510 transfer. 1512 The recommended call flow of Figure 11 does not utilize a CANCEL and 1513 does not suffer from these race conditions. 1515 Transferor Transferee Transfer 1516 | | Target 1517 | | | 1518 dialog1 | INVITE/200 OK/ACK | | 1519 |<-------------------| | 1520 dialog1 | INVITE (hold)/200 OK/ACK | 1521 |------------------->| | 1522 dialog2 | INVITE | 1523 |---------------------------------------->| 1524 dialog2 | 180 Ringing | 1525 |<----------------------------------------| 1526 | | 1527 | Transferor gives up waiting | 1528 | | 1529 dialog2 | CANCEL | 1530 |---------------------------------------->| 1531 dialog2 | 200 OK | 1532 |<----------------------------------------| 1533 dialog2 | 487 Request Terminated | 1534 |<----------------------------------------| 1535 dialog2 | ACK | 1536 |---------------------------------------->| 1537 dialog3 | REFER (Target-Dialog:1) F3 | 1538 |------------------->| | 1539 dialog3 | 202 Accepted | | 1540 |<-------------------| | 1541 dialog3 | NOTIFY (100 Trying)| | 1542 |<-------------------| | 1543 dialog3 | 200 OK | | 1544 |------------------->| | 1545 dialog4 | INVITE/200 OK/ACK | 1546 | |------------------->| 1547 dialog3 | NOTIFY (200 OK) | | 1548 |<-------------------| | 1549 dialog3 | 200 OK | | 1550 |------------------->| | 1551 dialog1 | BYE/200 OK | | 1552 |------------------->| | 1553 dialog4 | | BYE/200 OK | 1554 | |<-------------------| 1556 Figure 12. Semi-Attended Transfer as Blind Transfer Call Flow. (Not 1557 Recommended) 1558 Transferor Transferee Transfer 1559 | | Target 1560 | | | 1561 dialog1 | INVITE/200 OK/ACK | | 1562 |<-------------------| | 1563 dialog1 | INVITE (hold)/200 OK/ACK | 1564 |------------------->| | 1565 dialog2 | INVITE | 1566 |---------------------------------------->| 1567 dialog2 | 180 Ringing | 1568 |<----------------------------------------| 1569 | | 1570 |Transferor gives up waiting but Target answers 1571 | | 1572 dialog2 | CANCEL | 1573 |---------------------------------------->| 1574 dialog2 | 200 OK (CANCEL) | 1575 |<----------------------------------------| 1576 dialog2 | 200 OK (INVITE) F1 | 1577 |<----------------------------------------| 1578 dialog2 | ACK | 1579 |---------------------------------------->| 1580 dialog2 | INVITE (hold)/200 OK/ACK | 1581 |---------------------------------------->| 1582 | Tones or media played avoid silence F2 | 1583 |========================================>| 1584 dialog1 |REFER (Refer-To:sips:TransferTarget | 1585 | ?Replaces=dialog2) | 1586 |------------------->| | 1587 dialog1 | 202 Accepted | | 1588 |<-------------------| | 1589 dialog1 | NOTIFY (100 Trying)| | 1590 |<-------------------| | 1591 dialog1 | 200 OK | | 1592 |------------------->| | 1593 dialog3 | INVITE (Replaces:dialog2)/200 OK/ACK F3 1594 | |------------------->| 1595 dialog2 | BYE/200 OK | | 1596 |<----------------------------------------| 1597 dialog1 | NOTIFY (200 OK) | | 1598 |<-------------------| | 1599 dialog1 | 200 OK | | 1600 |------------------->| | 1601 dialog1 | BYE/200 OK | | 1602 |------------------->| | 1603 dialog3 | | BYE/200 OK | 1604 | |<-------------------| 1606 Figure 13. Semi-Attended Transfer as Attended Transfer Call Flow. 1607 (Not Recommended) 1609 7.7. Attended Transfer Fallback to Basic Transfer 1611 In this flow, an attempted attended transfer fails so the transferor 1612 falls back to basic transfer. 1614 The call flow in Figure 14 shows the use of Require: replaces in the 1615 INVITE sent by the Transferor to the Transfer Target in which the 1616 Transferor's intention at the time of sending the INVITE to the 1617 Transfer Target was known to be to complete an attended transfer. 1618 Since the Target does not support Replaces, the INVITE is rejected 1619 with a 420 Bad Extension response, and the Transferor switches from 1620 attended transfer to basic transfer immediately. 1622 Transferor Transferee Transfer 1623 | | Target 1624 | | | 1625 dialog1 | INVITE/200 OK/ACK | | 1626 |<-------------------| | 1627 dialog1 | OPTIONS/200 OK | | 1628 |------------------->| | 1629 dialog1 | INVITE (hold)/200 OK/ACK | 1630 |------------------->| | 1631 dialog2 | INVITE (Require:replaces) | 1632 |---------------------------------------->| 1633 dialog2 | 420 Bad Extension | 1634 |<----------------------------------------| 1635 dialog2 | ACK | 1636 |---------------------------------------->| 1637 dialog1 | REFER (Refer-To:sips:TransferTarget) | 1638 |------------------->| | 1639 dialog1 | 202 Accepted | | 1640 |<-------------------| | 1641 dialog1 | NOTIFY (100 Trying)| | 1642 |<-------------------| | 1643 dialog1 | 200 OK | | 1644 |------------------->| | 1645 dialog3 | | INVITE/200 OK/ACK | 1646 | |------------------->| 1647 dialog1 | NOTIFY (200 OK) | | 1648 |<-------------------| | 1649 dialog1 | 200 OK | | 1650 |------------------->| | 1651 dialog1 | BYE/200 OK | | 1652 |------------------->| | 1653 dialog3 | | BYE/200 OK | 1654 | |<-------------------| 1656 Figure 14. Attended Transfer Fallback to Basic Transfer using 1657 Require:replaces. 1659 Figure 15 shows the use of OPTIONS when the Transferee and Transfer 1660 Target do not explicitly indicate support for the REFER method and 1661 Replaces header fields in Allow and Supported header fields and the 1662 Transferor did not have the intention of performing an attended 1663 transfer when the INVITE to the Target was sent. In dialog1, the 1664 Transferor determines using OPTIONS that the Transferee does support 1665 REFER and Replaces. As a result, the Transferor begins the attended 1666 transfer by placing the Transferee on hold and calling the Transfer 1667 Target. Using an OPTIONS in dialog2, the Transferor determines that 1668 the Target does not support either REFER or Replaces, making attended 1669 transfer impossible. The Transferor then ends dialog2 by sending a 1670 BYE then sends a REFER to the Transferee using the AOR URI of the 1671 Transfer Target. 1673 Transferor Transferee Transfer 1674 | | Target 1675 | | | 1676 dialog1 | INVITE/200 OK/ACK | | 1677 |<-------------------| | 1678 dialog1 | OPTIONS/200 OK | | 1679 |------------------->| | 1680 dialog1 | INVITE (hold)/200 OK/ACK | 1681 |------------------->| | 1682 dialog2 | INVITE/200 OK/ACK | | 1683 |---------------------------------------->| 1684 dialog2 | OPTIONS/200 OK | | 1685 |---------------------------------------->| 1686 dialog2 | BYE/200 OK | | 1687 |---------------------------------------->| 1688 dialog3 |REFER (Target-Dialog:1, | 1689 | Refer-To:sips:TransferTarget) | 1690 |------------------->| | 1691 dialog3 | 202 Accepted | | 1692 |<-------------------| | 1693 dialog3 | NOTIFY (100 Trying)| | 1694 |<-------------------| | 1695 dialog3 | 200 OK | | 1696 |------------------->| | 1697 dialog4 | | INVITE/200 OK/ACK | 1698 | |------------------->| 1699 dialog3 | NOTIFY (200 OK) | | 1700 |<-------------------| | 1701 dialog3 | 200 OK | | 1702 |------------------->| | 1703 dialog1 | BYE/200 OK | | 1704 |------------------->| | 1705 dialog4 | | BYE/200 OK | 1706 | |<-------------------| 1708 Figure 15. Attended Transfer Fallback to Basic Transfer. 1710 8. Transfer with Referred-By 1712 In the previous examples, the Transfer Target does not have 1713 definitive information about what party initiated the transfer, or, 1714 in some cases, even that transfer is taking place. The Referred-By 1715 mechanism [5] provides a way for the Transferor to provide the 1716 Transferee with a way to let the Transfer Target know what party 1717 initiated the transfer. 1719 The simplest and least secure approach just involves the inclusion of 1720 the Referred-By header field in the REFER which is then copied into 1721 the triggered INVITE. However, a more secure mechanism involving the 1722 Referred-By security token which is generated and signed by the 1723 Transferor and passed in a message body to the Transferee then to the 1724 Transfer Target. 1726 The call flow would be identical to Figure 7. However, the REFER and 1727 triggered INVITE messages for this flow showing the Referred-By 1728 mechanism are shown below. 1730 Note that the conventions used in the SIP Torture Test Messages [9] 1731 document are reused, specifically the and tags. 1733 F5 REFER Transferor -> Transferee 1735 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 1736 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK392039842 1737 Max-Forwards: 70 1738 To: 1739 From: ;tag=1928301774 1740 Call-ID: a84b4c76e66710 1741 CSeq: 314160 REFER 1742 1743 Refer-To: 1746 1747 Supported: gruu, replaces, tdialog 1748 Require: tdialog 1749 Referred-By: 1750 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1751 Target-Dialog: 592435881734450904;local-tag=9m2n3wq;remote-tag=763231 1752 Contact: 1753 Content-Type: multipart/mixed; boundary=unique-boundary-1 1754 Content-Length: 3267 1756 --unique-boundary-1 1757 Content-ID: <20398823.2UWQFN309shb3@atlanta.example.com> 1759 Content-Length: 2961 1760 Content-Type: multipart/signed; 1761 protocol="application/pkcs-7-signature"; 1762 micalg=sha1; 1763 boundary="----590F24D439B31E08745DEF0CD9397189" 1765 ------590F24D439B31E08745DEF0CD9397189 1766 Content-Type: message/sipfrag 1768 Date: Thu, 18 Sep 2003 13:07:43 GMT 1769 1770 Refer-To: 1773 1774 Referred-By: 1775 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1777 ------590F24D439B31E08745DEF0CD9397189 1778 Content-Type: application/pkcs-7-signature; name="smime.p7s" 1779 Content-Transfer-Encoding: binary 1780 Content-Disposition: attachment; filename="smime.p7s" 1782 3082088806092A86 1783 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 1784 0B06092A864886F70D010701A082067A30820339308202A2A003020102020800 1785 90008902240001300D06092A864886F70D01010505003070310B300906035504 1786 0613025553311330110603550408130A43616C69666F726E69613111300F0603 1787 550407130853616E4A6F7365310E300C060355040A1305736970697431293027 1788 060355040B135369706974546573744365727469666963617465417574686F72 1789 697479301E170D3033313032313134343332355A170D31333130313831343433 1790 32355A3062310B3009060355040613025553311330110603550408130A43616C 1791 69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355 1792 040A13057369706974311B30190603550403141273656E646572406578616D70 1793 6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902 1794 818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5 1795 56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD 1796 6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081 1797 D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387 1798 4E230203010001A381E93081E6301D0603551D1104163014811273656E646572 1799 406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416 1800 041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481 1801 9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070 1802 310B3009060355040613025553311330110603550408130A43616C69666F726E 1803 69613111300F0603550407130853616E4A6F7365310E300C060355040A130573 1804 6970697431293027060355040B13536970697454657374436572746966696361 1805 7465417574686F72697479820100300D06092A864886F70D0101050500038181 1806 006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2 1807 2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870 1808 102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153 1809 278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7 1810 5E30820339308202A2A00302010202080090008902240001300D06092A864886 1811 F70D01010505003070310B300906035504061302555331133011060355040813 1812 0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30 1813 0C060355040A1305736970697431293027060355040B13536970697454657374 1814 4365727469666963617465417574686F72697479301E170D3033313032313134 1815 343332355A170D3133313031383134343332355A3062310B3009060355040613 1816 025553311330110603550408130A43616C69666F726E69613111300F06035504 1817 07130853616E4A6F7365310E300C060355040A13057369706974311B30190603 1818 550403141273656E646572406578616D706C652E6F726730819F300D06092A86 1819 4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692 1820 2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79 1821 76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5 1822 FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9 1823 79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D 1824 0603551D1104163014811273656E646572406578616D706C652E6F7267300906 1825 03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70 1826 E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580 1827 546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113 1828 30110603550408130A43616C69666F726E69613111300F060355040713085361 1829 6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353 1830 69706974546573744365727469666963617465417574686F7269747982010030 1831 0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978 1832 7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E 1833 C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A 1834 C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972 1835 242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30 1836 70310B3009060355040613025553311330110603550408130A43616C69666F72 1837 6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305 1838 736970697431293027060355040B135369706974546573744365727469666963 1839 617465417574686F7269747902080090008902240001300906052B0E03021A05 1840 00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C 1841 06092A864886F70D010905310F170D3034303132363139313831345A30230609 1842 2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943 1843 95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E 1844 06082A864886F70D030202020080300D06082A864886F70D0302020140300706 1845 052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01 1846 010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C 1847 C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C 1848 822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087 1849 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 1850 79089AAD95767F 1852 ------590F24D439B31E08745DEF0CD9397189-- 1854 --unique_boundary-1 1856 F6 INVITE Transferee -> Transfer Target 1858 INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0 1859 Via: SIP/2.0/TLS referee.example;branch=z9hG4bKffe209934aac 1860 To: 1861 From: ;tag=2909034023 1862 Call-ID: fe9023940-a3465@referee.example 1863 CSeq: 889823409 INVITE 1864 Max-Forwards: 70 1865 Contact: 1866 Referred-By: 1867 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1868 Replaces:090459243588173445;to-tag=9m2n3wq;from- 1869 tag=76323 1870 Require: replaces 1871 Supported: gruu, replaces, tdialog 1872 Content-Type: multipart/mixed; boundary=my-boundary-9 1873 Content-Length: 3432 1875 --my-boundary-9 1876 Content-Type: application/sdp 1878 Content-Length: 156 1880 v=0 1881 o=referee 2890844526 2890844526 IN IP4 referee.example 1882 s=Session SDP 1883 c=IN IP4 referee.example 1884 t=0 0 1885 m=audio 49172 RTP/AVP 0 1886 a=rtpmap:0 PCMU/8000 1888 --my-boundary-9 1889 Content-Length: 2961 1890 Content-Type: multipart/signed; 1891 protocol="application/pkcs-7-signature"; 1892 micalg=sha1; 1893 boundary="----590F24D439B31E08745DEF0CD9397189" 1895 ------590F24D439B31E08745DEF0CD9397189 1896 Content-Type: message/sipfrag 1898 Date: Thu, 18 Sep 2003 13:07:43 GMT 1900 1901 Refer-To: 1904 1905 Referred-By: 1906 ;cid="20398823.2UWQFN309shb3@atlanta.example.com" 1908 ------590F24D439B31E08745DEF0CD9397189 1909 Content-Type: application/pkcs-7-signature; name="smime.p7s" 1910 Content-Transfer-Encoding: binary 1911 Content-Disposition: attachment; filename="smime.p7s" 1913 3082088806092A86 1915 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 1916 0B06092A864886F70D010701A082067A30820339308202A2A003020102020800 1917 90008902240001300D06092A864886F70D01010505003070310B300906035504 1918 0613025553311330110603550408130A43616C69666F726E69613111300F0603 1919 550407130853616E4A6F7365310E300C060355040A1305736970697431293027 1920 060355040B135369706974546573744365727469666963617465417574686F72 1921 697479301E170D3033313032313134343332355A170D31333130313831343433 1922 32355A3062310B3009060355040613025553311330110603550408130A43616C 1923 69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355 1924 040A13057369706974311B30190603550403141273656E646572406578616D70 1925 6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902 1926 818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5 1927 56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD 1928 6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081 1929 D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387 1930 4E230203010001A381E93081E6301D0603551D1104163014811273656E646572 1931 406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416 1932 041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481 1933 9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070 1934 310B3009060355040613025553311330110603550408130A43616C69666F726E 1935 69613111300F0603550407130853616E4A6F7365310E300C060355040A130573 1936 6970697431293027060355040B13536970697454657374436572746966696361 1937 7465417574686F72697479820100300D06092A864886F70D0101050500038181 1938 006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2 1939 2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870 1940 102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153 1941 278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7 1942 5E30820339308202A2A00302010202080090008902240001300D06092A864886 1943 F70D01010505003070310B300906035504061302555331133011060355040813 1944 0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30 1945 0C060355040A1305736970697431293027060355040B13536970697454657374 1946 4365727469666963617465417574686F72697479301E170D3033313032313134 1947 343332355A170D3133313031383134343332355A3062310B3009060355040613 1948 025553311330110603550408130A43616C69666F726E69613111300F06035504 1949 07130853616E4A6F7365310E300C060355040A13057369706974311B30190603 1950 550403141273656E646572406578616D706C652E6F726730819F300D06092A86 1951 4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692 1952 2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79 1953 76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5 1954 FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9 1955 79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D 1956 0603551D1104163014811273656E646572406578616D706C652E6F7267300906 1957 03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70 1958 E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580 1959 546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113 1960 30110603550408130A43616C69666F726E69613111300F060355040713085361 1961 6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353 1962 69706974546573744365727469666963617465417574686F7269747982010030 1963 0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978 1964 7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E 1965 C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A 1966 C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972 1967 242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30 1968 70310B3009060355040613025553311330110603550408130A43616C69666F72 1969 6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305 1970 736970697431293027060355040B135369706974546573744365727469666963 1971 617465417574686F7269747902080090008902240001300906052B0E03021A05 1972 00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C 1973 06092A864886F70D010905310F170D3034303132363139313831345A30230609 1974 2A864886F70D01090431160414408CCA5772916A968204FD24CC24EDAEAD3943 1975 95305206092A864886F70D01090F31453043300A06082A864886F70D0307300E 1976 06082A864886F70D030202020080300D06082A864886F70D0302020140300706 1977 052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01 1978 010105000481807795329BB23B8BB9F72526AB9CC22D93B9A37A2E69A0171D3C 1979 C417DD394F0A5FD4F8B082733CD9F2E26F6991031F7FF2EAD31640718502FB4C 1980 822771211E6228C793DA4DBBA2159227C221030FE9088CD659578EB862568087 1981 8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 1982 79089AAD95767F 1984 ------590F24D439B31E08745DEF0CD9397189-- 1986 --my-boundary-9-- 1988 9. Transfer as an Ad-Hoc Conference 1990 In this flow, shown in Figure 16, Bob does an attended transfer of 1991 Alice to Carol. In order to keep both Alice and Carol fully informed 1992 of the nature and state of the transfer operation, Bob acts as a 1993 focus[11] and hosts an ad-hoc conference involving Alice, Bob, and 1994 Carol. Alice and Carol subscribe to the conference package[12] of 1995 Bob's focus, which allows them to know the exact status of the 1996 operation. After the transfer operation is complete, Bob deletes the 1997 conference. 1999 This call flow meets requirement 6 of Section 3. NOTIFY messages 2000 related to the refer package are indicated as NOTIFY (refer), while 2001 NOTIFYs related to the Conference Info package are indicated as 2002 NOTIFY (Conf-Info). 2004 Note that any type of semi-attended transfer in which media mixing or 2005 relaying could be implemented using this model. In addition to 2006 simply mixing, the focus could introduce additional media signals 2007 such as simulated ring tone or on hold announcements to improve the 2008 user experience. 2010 Alice Bob Carol 2011 | | | 2012 | INVITE | | 2013 |------------------->| | 2014 | 180 Ringing | | 2015 |<-------------------| | 2016 | 200 OK | | 2017 |<-------------------| | 2018 | ACK | | 2019 |------------------->| | 2020 | RTP | | 2021 |<==================>| | 2022 | | | 2023 Bob places Alice on hold and begins acting like a focus 2024 | | | 2025 | INVITE (hold) Contact:Conf-ID;isfocus | 2026 |<-------------------| | 2027 | 200 OK | | 2028 |------------------->| | 2029 | ACK | | 2030 |<-------------------| | 2031 | | | 2032 | Alice subscribes to the conference package 2033 | | | 2034 | SUBSCRIBE sip:Conf-ID | 2035 |------------------->| | 2036 | 200 OK | | 2037 |<-------------------| | 2038 | NOTIFY (Conf-Info) | | 2039 |<-------------------| | 2040 | 200 OK | | 2041 |------------------->| | 2042 | | | 2043 | Bob begins consultation operation | 2044 | | | 2045 |INVITE Require:replaces Contact:Conf-ID;isfocus 2046 | |------------------->| 2047 | | 180 Ringing | 2048 | |<-------------------| 2049 | | 200 OK | 2050 | |<-------------------| 2051 | | ACK | 2052 | |------------------->| 2053 | | RTP | 2054 | |<==================>| 2055 | | | 2056 |Carol subscribes to the conference package 2057 | - learns Bob is on hold | 2058 | | | 2059 | |SUBSCRIBE sip:Conf-ID 2060 | |<-------------------| 2061 | | 200 OK | 2062 | |------------------->| 2063 | | NOTIFY (Conf-Info) | 2064 | |------------------->| 2065 | | 200 OK | 2066 | |<-------------------| 2067 | | | 2068 | Alice learns that Bob is talking to Carol 2069 | | | 2070 | NOTIFY (Conf-Info) | | 2071 |<-------------------| | 2072 | 200 OK | | 2073 |------------------->| | 2074 | | INVITE (hold) | 2075 | |------------------->| 2076 | | 200 OK | 2077 | |<-------------------| 2078 | | ACK | 2079 | |------------------->| 2080 | | | 2081 | Alice learns that Carol is now on hold | 2082 | | | 2083 | NOTIFY (Conf-Info) | | 2084 |<-------------------| | 2085 | 200 OK | | 2086 |------------------->| | 2087 | | | 2088 | Bob begins transfer operation | 2089 | | | 2090 | REFER Refer-To: Carol | 2091 |<-------------------| | 2092 | 202 Accepted | | 2093 |------------------->| | 2094 | NOTIFY (Refer) | | 2095 |------------------->| | 2096 | 200 OK | | 2097 |<-------------------| | 2098 | INVITE Replaces:B-C Contact:Alice | 2099 |---------------------------------------->| 2100 | 200 OK | 2101 |<----------------------------------------| 2102 | ACK | 2103 |---------------------------------------->| 2104 | RTP | 2105 |<=======================================>| 2106 | | BYE | 2107 | |<-------------------| 2108 | | 200 OK | 2109 | |------------------->| 2110 | NOTIFY (Refer) | | 2111 |------------------->| | 2112 | 200 OK | | 2113 |<-------------------| | 2114 | | | 2115 | Bob terminates the ad-hoc conference | 2116 | | | 2117 | BYE | | 2118 |<-------------------| | 2119 | 200 OK | | 2120 |------------------->| | 2121 | | NOTIFY (Conf-Info) | 2122 | |------------------->| 2123 | | 200 OK | 2124 | |<-------------------| 2125 | NOTIFY (Conf-Info) | | 2126 |<-------------------| | 2127 | 200 OK | | 2128 |------------------->| | 2130 Figure 16. Attended Transfer as an Ad-Hoc Conference. 2132 10. Transfer with multiple parties 2134 In this example shown in Figure 17, the Originator places call to the 2135 Facilitator who reaches the Recipient through the Screener. The 2136 Recipient's contact information is exposed to the Facilitator and the 2137 Originator. This example is provided for clarification of the 2138 semantics of the REFER method only and should not be used as the 2139 design of an implementation. 2141 Originator Facilitator Screener Recipient 2142 | | | | 2143 1 |INVITE/200 OK/ACK | |"Get Fred for me!" 2144 |----------->| | | "Right away!" 2145 2 |INVITE (hold)/200 OK/ACK | | 2146 |<-----------| | | 2147 2 | |INVITE/200 OK/ACK |"I have a call 2148 | |----------->| |from Mary for Fred" 2149 2 | |INVITE (hold)/200 OK/ACK "Hold please" 2150 | |<-----------| | 2151 3 | | |INVITE/200 OK/ACK 2152 | | |--------->|"You have a call 2153 | | | |from Mary" 2154 | | | | "Put her through" 2155 3 | | |INVITE (hold)/200 OK/ACK 2156 | | |--------->| 2157 4 | |REFER | | 2158 | |<-----------| | 2159 4 | |202 Accepted| | 2160 | |----------->| | 2161 4 | |NOTIFY (100 Trying) | 2162 | |----------->| | 2163 4 | |200 OK | | 2164 | |<-----------| | 2165 5 | |INVITE/200 OK/ACK | 2166 | |---------------------->|"This is Fred" 2167 4 | |NOTIFY (200 OK) | "Please hold for 2168 | |----------->| | Mary" 2169 4 | |200 OK | | 2170 | |<-----------| | 2171 2 | |BYE/200 OK | | 2172 | |<-----------| | 2173 3 | | |BYE/200 OK| 2174 | | |--------->| 2175 5 | |INVITE (hold)/200 OK/ACK 2176 | |---------------------->| 2177 6 |REFER | | | 2178 |<-----------| | | 2179 6 |202 Accepted| | | 2180 |----------->| | | 2181 6 |NOTIFY (100 Trying) | | 2182 |----------->| | | 2183 6 |200 OK | | | 2184 |<-----------| | | 2185 7 |INVITE/200 OK/ACK | | 2186 |----------------------------------->| "Hey Fred" 2187 6 |NOTIFY (200 OK) | | "Hello Mary" 2188 |----------->| | | 2190 6 |200 OK | | | 2191 |<-----------| | | 2192 1 |BYE/200 OK | | | 2193 |<-----------| | | 2194 5 | |BYE/200 OK | | 2195 | |---------------------->| 2196 7 |BYE/200 OK | | | 2197 |<-----------------------------------| "See you later" 2199 Figure 17. Transfer with Multiple Parties Example. 2201 11. Gateway Transfer Issues 2203 A gateway in SIP acts as a User Agent. As a result, the entire 2204 preceding discussion and call flows apply equally well to gateways as 2205 native SIP endpoints. However, there are some gateway specific 2206 issues that are documented in this section. While this discussion 2207 focuses on the common cases involving PSTN gateways, similar 2208 situations exist for other gateways, such as H.323/SIP gateways. 2210 11.1. Coerce Gateway Hairpins to the Same Gateway 2212 To illustrate how a hairpin situation can occur in transfer, consider 2213 this example. The original call dialog is setup with the transferee 2214 residing on the PSTN side of a SIP gateway. The transferor is a SIP 2215 phone purely in the IP space. The transfer target is on the PSTN 2216 side of a SIP gateway as well. After completing the transfer, 2217 (regardless of consultative or blind) the transferee is in a call 2218 with the transfer target (both on the PSTN side of a gateway). It is 2219 often desirable to remove the gateway(s) out of the loop. This is 2220 likely to only be possible if both legs of the target call are on the 2221 same gateway. With both legs on the same gateway, it may be able to 2222 invoke the analogous transfer on the PSTN side. Then the target call 2223 would not involve the gateway. 2225 So the problem is how to give the proxy enough information so that it 2226 knows to route the call to the same gateway. With a simple single 2227 call that hairpins, the incoming and outgoing leg have the same 2228 dialog. The proxy should have enough information to optimize the 2229 routing. 2231 In the consultative transfer scenario, it is desirable to coerce the 2232 consultative INVITE out the same gateway as the original call to be 2233 transferred. However there is no way to relate the consultation with 2234 the original call. In the consultative case the target call INVITE 2235 includes the Replaces header which contains dialog information that 2236 can be used to relate it to the consultation. However there is no 2237 information that relates the target call to the original. 2239 In the blind transfer scenario, it is desirable to coerce the target 2240 call onto the same gateway as the original call. However the same 2241 problem exists in that the target dialog cannot be related to the 2242 original dialog. 2244 In either transfer scenario, it may be desirable to push the transfer 2245 operation onto the non-SIP side of the gateway. Presumably this is 2246 not possible unless all of the legs go out the same gateway. If the 2247 gateway supports more than one truck group, it might also be 2248 necessary to get all of the legs on the same trunk group in order to 2249 perform the transfer on the non-SIP side of the gateway. 2251 Solutions to these gateway specific issues may involve new extensions 2252 to SIP in the future. 2254 11.2. Consultative Turned Blind Gateway Glare 2256 In the consultative transfer case turned blind, there is a glare-like 2257 problem. The transferor initiates the consultation INVITE, the user 2258 gets impatient and hangs up, transitioning this to a blind transfer. 2259 The transfer target on the gateway (connected through a PSTN switch 2260 to a single line or dumb analog phone) rings. The user answers the 2261 phone just after the CANCEL is received by the transfer target. The 2262 REFER and INVITE for the target call are sent. The transferee 2263 attempts to setup the call on the PSTN side, but gets either a busy 2264 or lands in the users voicemail as the user has the handset in hand 2265 and off hook. 2267 This is another example of a race condition that this call flow can 2268 cause. The recommended behavior is to use the approach described in 2269 Section 6.6. 2271 12. IANA Considerations 2273 None. 2275 13. Security Considerations 2277 The call transfer flows shown in this document are implemented using 2278 the REFER and Replaces call control primitives in SIP. As such, the 2279 attacks and security approaches are those detailed in the REFER and 2280 Replaces documents which are briefly summarized in the following 2281 paragraphs. This document addresses the issue of protecting the 2282 Address of Record URI of a transfer target in Sections 6.1 and 6.2. 2284 Any REFER request must be appropriately authenticated and authorized 2285 using standard SIP mechanisms or calls may be hijacked. A user agent 2286 may use local policy or human intervention in deciding whether or not 2287 to accept a REFER. In generating NOTIFY responses based on the 2288 outcome of the triggered request, care should be taken in 2289 constructing the message/sipfrag body to ensure that no private 2290 information is leaked. 2292 An INVITE containing a Replaces header field should only be accepted 2293 if it has been properly authenticated and authorized using standard 2294 SIP mechanisms, and the requestor is authorized to perform dialog 2295 replacement. 2297 14. Acknowledgments 2299 This draft is a collaborative product of the SIP working group. 2300 Thanks to Rohan Mahy for his input on the use of Replaces in 2301 transfer. 2303 15. References 2305 15.1. Normative References 2307 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2308 Levels", BCP 14, RFC 2119, March 1997. 2310 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2311 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2312 Session Initiation Protocol", RFC 3261, June 2002. 2314 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2315 Method", RFC 3515, April 2003. 2317 [4] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 2318 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 2320 [5] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By 2321 Mechanism", RFC 3892, September 2004. 2323 [6] Rosenberg, J., "Request Authorization through Dialog 2324 Identification in the Session Initiation Protocol (SIP)", 2325 RFC 4538, June 2006. 2327 15.2. Informative References 2329 [7] Mahy, R., "A Call Control and Multi-party usage framework for 2330 the Session Initiation Protocol (SIP)", 2331 draft-ietf-sipping-cc-framework-07 (work in progress), 2332 March 2007. 2334 [8] Rosenberg, J., "Obtaining and Using Globally Routable User 2335 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 2336 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 2337 October 2007. 2339 [9] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and 2340 H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test 2341 Messages", RFC 4475, May 2006. 2343 [10] Rosenberg, J., "A Framework for Conferencing with the Session 2344 Initiation Protocol (SIP)", RFC 4353, February 2006. 2346 [11] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) 2347 Call Control - Conferencing for User Agents", BCP 119, 2348 RFC 4579, August 2006. 2350 [12] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 2351 Initiation Protocol (SIP) Event Package for Conference State", 2352 RFC 4575, August 2006. 2354 [13] Sparks, R., "Multiple Dialog Usages in the Session Initiation 2355 Protocol", draft-sparks-sipping-dialogusage-00 (work in 2356 progress), July 2004. 2358 Authors' Addresses 2360 Robert J. Sparks 2361 Estacado Systems 2363 Email: RjS@estacado.net 2365 Alan Johnston (editor) 2366 Avaya 2367 St. Louis, MO 2369 Email: alan@sisptation.com 2370 Daniel Petrie 2371 SIPez LLC 2372 34 Robbins Rd. 2373 Arlington, MA 02476 2374 US 2376 Phone: +1 617 273 4000 2377 Email: dan.ietf AT SIPez DOT com 2378 URI: http://www.SIPez.com/ 2380 Full Copyright Statement 2382 Copyright (C) The IETF Trust (2007). 2384 This document is subject to the rights, licenses and restrictions 2385 contained in BCP 78, and except as set forth therein, the authors 2386 retain all their rights. 2388 This document and the information contained herein are provided on an 2389 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2390 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2391 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2392 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2393 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2394 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2396 Intellectual Property 2398 The IETF takes no position regarding the validity or scope of any 2399 Intellectual Property Rights or other rights that might be claimed to 2400 pertain to the implementation or use of the technology described in 2401 this document or the extent to which any license under such rights 2402 might or might not be available; nor does it represent that it has 2403 made any independent effort to identify any such rights. Information 2404 on the procedures with respect to rights in RFC documents can be 2405 found in BCP 78 and BCP 79. 2407 Copies of IPR disclosures made to the IETF Secretariat and any 2408 assurances of licenses to be made available, or the result of an 2409 attempt made to obtain a general license or permission for the use of 2410 such proprietary rights by implementers or users of this 2411 specification can be obtained from the IETF on-line IPR repository at 2412 http://www.ietf.org/ipr. 2414 The IETF invites any interested party to bring to its attention any 2415 copyrights, patents or patent applications, or other proprietary 2416 rights that may cover technology that may be required to implement 2417 this standard. Please address the information to the IETF at 2418 ietf-ipr@ietf.org. 2420 Acknowledgment 2422 Funding for the RFC Editor function is provided by the IETF 2423 Administrative Support Activity (IASA).