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