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