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