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