idnits 2.17.1 draft-ietf-sipping-cc-transfer-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 23 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. -- 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 90: '... this document MUST support REFER[2] and Replaces[3] in addition to...' RFC 2119 keyword, line 126: '...in a SIP session MUST be able to trans...' RFC 2119 keyword, line 129: '...d the Transferee MUST NOT be removed f...' RFC 2119 keyword, line 136: '...ow, this is not the case. A client MAY...' RFC 2119 keyword, line 142: '... The Transferor MUST know whether or ...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 11, 2003) is 7745 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 (-05) exists of draft-ietf-sip-replaces-02 == Outdated reference: A later version (-05) exists of draft-ietf-sip-referredby-00 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-01 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG R. Sparks 3 Internet-Draft dynamicsoft 4 Expires: August 12, 2003 A. Johnston 5 WorldCom 6 February 11, 2003 8 Session Initiation Protocol Call Control - Transfer 9 draft-ietf-sipping-cc-transfer-01 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 12, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document describes providing Call Transfer capabilities in the 40 Session Initiation Protocol (SIP). This work is part of the SIP 41 Multiparty Call Control Framework. 43 Table of Contents 45 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Actors and Roles . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 48 4. Using REFER to achieve Call Transfer . . . . . . . . . . . . 4 49 5. Basic Transfer . . . . . . . . . . . . . . . . . . . . . . . 5 50 5.1 Successful Transfer . . . . . . . . . . . . . . . . . . . . 6 51 5.2 Failed Transfer . . . . . . . . . . . . . . . . . . . . . . 9 52 5.2.1 Target Busy . . . . . . . . . . . . . . . . . . . . . . . . 9 53 5.2.2 Transfer Target does not answer . . . . . . . . . . . . . . 10 54 6. Transfer with Consultation Hold . . . . . . . . . . . . . . 11 55 6.1 Exposing transfer target . . . . . . . . . . . . . . . . . . 11 56 6.2 Protecting transfer target . . . . . . . . . . . . . . . . . 13 57 6.3 Attended Transfer . . . . . . . . . . . . . . . . . . . . . 16 58 6.4 Recovery when one party does not support REFER . . . . . . . 19 59 6.5 Attended Transfer when Contact URI is Not Globally 60 Routable . . . . . . . . . . . . . . . . . . . . . . . . . . 20 61 6.6 Aborting a Consultation Hold . . . . . . . . . . . . . . . . 24 62 6.7 Attended Transfer Fallback to Basic Transfer . . . . . . . . 25 63 7. Transfer with Referred-By . . . . . . . . . . . . . . . . . 26 64 8. Transfer with multiple parties . . . . . . . . . . . . . . . 27 65 9. Changes from draft-sipping-cc-transfer-00 . . . . . . . . . 28 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 67 11. Security Considerations . . . . . . . . . . . . . . . . . . 28 68 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 69 Normative References . . . . . . . . . . . . . . . . . . . . 29 70 Informative References . . . . . . . . . . . . . . . . . . . 29 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 72 Intellectual Property and Copyright Statements . . . . . . . 31 74 1. Overview 76 This document describes providing Call Transfer capabilities and 77 requirements in SIP [1]. This work is part of the Multiparty Call 78 Control Framework [5]. 80 The mechanisms discussed here are most closely related to traditional 81 basic and consultation hold transfers. This document does not discuss 82 transfer scenarios involving ad-hoc conferences (where all parties 83 involved are briefly in a conference until this transferor drops 84 out). 86 This document details the use of REFER method [2] and Replaces [3] 87 header field to achieve call transfer. 89 A user agent that fully supports the transfer mechanisms described in 90 this document MUST support REFER[2] and Replaces[3] in addition to 91 RFC 3261 [1]. 93 2. Actors and Roles 95 There are three actors in a given transfer event, each playing one of 96 the following roles: 98 Transferee - the party being transferred to the Transfer 99 Target. 101 Transferor - the party initiating the transfer 103 Transfer Target - the new party being introduced into a call with 104 the Transferee. 106 The following roles are used to describe transfer requirements and 107 scenarios: 109 Originator - wishes to place a call to the Recipient. This actor 110 is the source of the first INVITE in a session, to 111 either a Facilitator or a Screener. 113 Facilitator - receives a call or out-of-band request from the 114 Originator, establishes a call to the Recipient 115 through the Screener, and connects the Originator to 116 the Recipient. 118 Screener - receives a call ultimately intended for the Recipient 119 and transfers the calling party to the Recipient if 120 appropriate. 122 Recipient - the party the Originator is ultimately connected to. 124 3. Requirements 126 1. Any party in a SIP session MUST be able to transfer any other 127 party in that session at any point in that session. 129 2. The Transferor and the Transferee MUST NOT be removed from a 130 session as part of a transfer transaction. 132 At first glance, requirement 2 may seem to indicate 133 that the user experience in a transfer must be 134 significantly different from what a current PBX or 135 Centrex user expects. As the call-flows in this 136 document show, this is not the case. A client MAY 137 preserve the current experience. In fact, without 138 this requirement, some forms of the current 139 experience (ringback on transfer failure 140 for instance) will be lost. 142 3. The Transferor MUST know whether or not the transfer was 143 successful (this is significantly different from the requirements 144 of the earlier BYE-Also approach to transfer). 146 4. The Transferee MUST be able to replace an existing dialog with a 147 new dialog. 149 5. The Transferor and Transferee SHOULD indicate their support for 150 the primitives required to achieve transfer. 152 4. Using REFER to achieve Call Transfer 154 A REFER [2] can be issued by the Transferor to cause the Transferee 155 to issue an INVITE to the Transfer-Target. Note that a successful 156 REFER transaction does not terminate the session between the 157 Transferor and the Transferee. If those parties wish to terminate 158 their session, they must do so with a subsequent BYE request. The 159 media negotiated between the transferee and the transfer target is 160 not affected by the media that had been negotiated between the 161 transferor and the transferee. In particular, the INVITE issued by 162 the Transferee will have the same SDP body it would have if he 163 Transferee had initiated that INVITE on its own. Further, the 164 disposition of the media streams between the Transferor and the 165 Transferee is not altered by the REFER method. Agents may alter a 166 session's media through additional signaling. For example, they may 167 make use of the SIP hold re-INVITE [1] or the conferencing extensions 168 provided by this framework. 170 5. Basic Transfer 172 Basic Transfer consists of the Transferor providing the Transfer 173 Target's contact to the Transferee. The Transferee attempts to 174 establish a session using that contact and reports the results of 175 that attempt to the Transferor. The signaling relationship between 176 the Transferor and Transferee is not terminated, so the call is 177 recoverable if the Transfer Target cannot be reached. Note that the 178 Transfer Target's contact information has been exposed to the 179 Transferee. The provided contact can be used to make new calls in the 180 future. 182 The participants in a basic transfer should indicate support for the 183 REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to 184 INVITE, and OPTIONS. 186 The diagrams below show indicate the first line of each message. The 187 first column of the figure shows the Call-ID used in that particular 188 message. In these diagrams, media is managed through re-INVITE holds, 189 but other mechanisms (mixing multiple media streams at the UA or 190 using the conferencing extensions for example) are valid. Selected 191 message details are shown labeled as message F1, F2, etc. 193 Each of the flows below shows the dialog between the Transferor and 194 the Transferee remaining connected (on hold) during the REFER 195 process. While this provides the greatest flexibility for recovery 196 from failure, it is not necessary. If the Transferor's agent does not 197 wish to participate in the remainder of the REFER process and has no 198 intention of assisting with recovery from transfer failure, it could 199 emit a BYE to the Transferee as soon as the REFER transaction 200 completes. This flow is sometimes known as "unattended transfer". 202 5.1 Successful Transfer 204 Transferor Transferee Transfer 205 | | Target 206 | INVITE | | 207 Call-ID:1 |<-------------------| | 208 | 200 OK | | 209 Call-ID:1 |------------------->| | 210 | ACK | | 211 Call-ID:1 |<-------------------| | 212 | INVITE (hold) | | 213 Call-ID:1 |------------------->| | 214 | 200 OK | | 215 Call-ID:1 |<-------------------| | 216 | ACK | | 217 Call-ID:1 |------------------->| | 218 | REFER F1 | | 219 Call-ID:1 |------------------->| | 220 | 202 Accepted | | 221 Call-ID:1 |<-------------------| | 222 | NOTIFY (100 Trying) F2 | 223 Call-ID:1 |<-------------------| | 224 | 200 OK | | 225 Call-ID:1 |------------------->| | 226 | | INVITE F3 | 227 Call-ID:2 | |------------------->| 228 | | 200 OK | 229 Call-ID:2 | |<-------------------| 230 | | ACK | 231 Call-ID:2 | |------------------->| 232 | NOTIFY (200 OK) F4| | 233 Call-ID:1 |<-------------------| | 234 | 200 OK | | 235 Call-ID:1 |------------------->| | 236 | BYE | | 237 Call-ID:1 |------------------->| | 238 | 200 OK | | 239 Call-ID:1 |<-------------------| | 240 | | BYE | 241 Call-ID:2 | |<-------------------| 242 | | 200 OK | 243 Call-ID:2 | |------------------->| 245 Figure 1. Basic Transfer Call Flow. 247 F1 REFER Transferor -> Transferee 248 REFER sip:transferee@192.0.2.4 SIP/2.0 249 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKna9 250 Max-Forwards: 70 251 To: ;tag=a6c85cf 252 From: ;tag=1928301774 253 Call-ID: a84b4c76e66710 254 CSeq: 314159 REFER 255 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 256 Supported: replaces 257 Refer-To: 258 Contact: 259 Content-Length: 0 261 F2 NOTIFY Transferee -> Transferor 263 NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 264 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 265 Max-Forwards: 70 266 To: ;tag=1928301774 267 From: ;tag=a6c85cf 268 Call-ID: a84b4c76e66710 269 CSeq: 73 NOTIFY 270 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 271 Supported: replaces 272 Event: refer 273 Subscription-State: active;expires=60 274 Content-Type: message/sipfrag 275 Content-Length: ... 277 SIP/2.0 100 Trying 279 F3 INVITE Transferee -> Transfer Target 281 INVITE sip:transfertarget@chicago.example.com SIP/2.0 282 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas41234 283 Max-Forwards: 70 284 To: 285 From: ;tag=j3kso3iqhq 286 Call-ID: 90422f3sd23m4g56832034 287 CSeq: 521 REFER 288 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 289 Supported: replaces 290 Contact: 291 Content-Type: application/sdp 292 Content-Length: ... 294 F4 NOTIFY Transferee -> Transferor 296 NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 297 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 298 Max-Forwards: 70 299 To: ;tag=1928301774 300 From: ;tag=a6c85cf 301 Call-ID: a84b4c76e66710 302 CSeq: 74 NOTIFY 303 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 304 Supported: replaces 305 Event: refer 306 Subscription-State: terminated;reason=noresource 307 Content-Type: message/sipfrag 308 Content-Length: ... 310 SIP/2.0 200 OK 312 5.2 Failed Transfer 314 This section shows examples of failed transfer attempts. After the 315 transfer failure occurs, the Transferor takes the Transferee off hold 316 and resumes the session. 318 5.2.1 Target Busy 320 Transferor Transferee Transfer 321 | | Target 322 | | | 323 | INVITE | | 324 Call-ID:1 |<-------------------| | 325 | 200 OK | | 326 Call-ID:1 |------------------->| | 327 | ACK | | 328 Call-ID:1 |<-------------------| | 329 | INVITE (hold) | | 330 Call-ID:1 |------------------->| | 331 | 200 OK | | 332 Call-ID:1 |<-------------------| | 333 | ACK | | 334 Call-ID:1 |------------------->| | 335 | REFER | | 336 Call-ID:1 |------------------->| | 337 | 202 Accepted | | 338 Call-ID:1 |<-------------------| | 339 | NOTIFY (100 Trying)| | 340 Call-ID:1 |<-------------------| | 341 | 200 OK | | 342 Call-ID:1 |------------------->| | 343 | | INVITE | 344 Call-ID:2 | |------------------->| 345 | | 486 Busy Here | 346 Call-ID:2 | |<-------------------| 347 | | ACK | 348 Call-ID:2 | |------------------->| 349 | NOTIFY (503 Service Unavailable) | 350 | or NOTIFY (486 Busy Here) | 351 Call-ID:1 |<-------------------| | 352 | 200 OK | | 353 Call-ID:1 |------------------->| | 354 | INVITE (unhold) | | 355 Call-ID:1 |------------------->| | 356 | 200 OK | | 357 Call-ID:1 |<-------------------| | 358 | ACK | | 360 Call-ID:1 |------------------->| | 361 | BYE | | 362 Call-ID:1 |------------------->| | 363 | 200 OK | | 364 Call-ID:1 |<-------------------| | 366 Figure 2. Failed Transfer - Target Busy 368 5.2.2 Transfer Target does not answer 370 Transferor Transferee Transfer 371 | | Target 372 | INVITE | | 373 Call-ID:1 |<-------------------| | 374 | 200 OK | | 375 Call-ID:1 |------------------->| | 376 | ACK | | 377 Call-ID:1 |<-------------------| | 378 | INVITE (hold) | | 379 Call-ID:1 |------------------->| | 380 | 200 OK | | 381 Call-ID:1 |<-------------------| | 382 | ACK | | 383 Call-ID:1 |------------------->| | 384 | REFER | | 385 Call-ID:1 |------------------->| | 386 | 202 Accepted | | 387 Call-ID:1 |<-------------------| | 388 | NOTIFY (100 Trying)| | 389 Call-ID:1 |<-------------------| | 390 | 200 OK | | 391 Call-ID:1 |------------------->| | 392 | | INVITE | 393 Call-ID:2 | |------------------->| 394 | | 180 Ringing | 395 Call-ID:2 | |<-------------------| 396 | | (Transferee gets tired of waiting) 397 | | CANCEL | 398 Call-ID:2 | |------------------->| 399 | | 200 OK (CANCEL) | 400 Call-ID:2 | |<-------------------| 401 | | 487 Request Cancelled (INVITE) 402 Call-ID:2 | |<-------------------| 403 | | ACK | 404 Call-ID:2 | |------------------->| 405 | NOTIFY (487 Request Cancelled) | 406 Call-ID:1 |<-------------------| | 407 | 200 OK | | 408 Call-ID:1 |------------------->| | 409 | INVITE (unhold) | | 410 Call-ID:1 |------------------->| | 411 | 200 OK | | 412 Call-ID:1 |<-------------------| | 413 | ACK | | 414 Call-ID:1 |------------------->| | 415 | BYE | | 416 Call-ID:1 |------------------->| | 417 | 200 OK | | 418 Call-ID:1 |<-------------------| | 420 Figure 3. Failed Transfer - Target Does Not Answer. 422 6. Transfer with Consultation Hold 424 Transfer with Consultation Hold involves a session between the 425 transferor and the transfer target before the transfer actually takes 426 place. This is implemented with SIP Hold and Transfer as described 427 above. 429 6.1 Exposing transfer target 431 The transferor places the transferee on hold, establishes a call with 432 the transfer target to alert them to the impending transfer, 433 terminates the connection with the transfer target, then proceeds 434 with transfer as above. This variation can be used to provide an 435 experience similar to that expected by current PBX and Centrex users. 437 To (hopefully) improve clarity, non-REFER transactions have been 438 collapsed into one indicator with the arrow showing the direction of 439 the request. 441 Transferor Transferee Transfer 442 | | Target 443 | | | 444 Call-ID:1 | INVITE/200 OK/ACK | | 445 |<-------------------| | 446 Call-ID:1 | INVITE (hold)/200 OK/ACK | 447 |------------------->| | 448 Call-ID:2 | INVITE/200 OK/ACK | | 449 |---------------------------------------->| 450 Call-ID:2 | BYE/200 OK | | 451 |---------------------------------------->| 452 Call-ID:1 | REFER | | 453 |------------------->| | 454 Call-ID:1 | 202 Accepted | | 455 |<-------------------| | 456 Call-ID:1 | NOTIFY (100 Trying)| | 457 |<-------------------| | 458 Call-ID:1 | 200 OK | | 459 |------------------->| | 460 Call-ID:3 | | INVITE/200 OK/ACK | 461 | |------------------->| 462 Call-ID:1 | NOTIFY (200 OK) | | 463 |<-------------------| | 464 Call-ID:1 | 200 OK | | 465 |------------------->| | 466 Call-ID:1 | BYE/200 OK | | 467 |------------------->| | 468 Call-ID:3 | | BYE/200 OK | 469 | |<-------------------| 471 Figure 4. Transfer with Consultation Hold - Exposing Transfer 472 Target. 474 6.2 Protecting transfer target 476 The transferor places the transferee on hold, establishes a call with 477 the transfer target and then reverses their roles, transferring the 478 original transfer target to the original transferee. This has the 479 advantage of hiding information about the original transfer target 480 from the original transferee. On the other hand, the Transferee's 481 experience is different that in current systems. The Transferee is 482 effectively "called back" by the Transfer Target. 484 One of the problems with this simplest implementation of a target 485 protecting transfer is that the transferee is receiving a new call 486 from the transfer-target. Unless the transferee's agent has a 487 reliable way to associate this new call with the call it already has 488 with the transferor, it will have to alert the new call on another 489 appearance. If this, or some other call-waiting-like UI were not 490 available, the transferee might be stuck returning a Busy-Here to the 491 transfer target, effectively preventing the transfer. There are many 492 ways that that correlation could be provided. The dialog parameters 493 could be provided directly as header parameters in the Refer-To: URI 494 for example. The Replaces mechanism [3] uses this approach and solves 495 this problem nicely. 497 For the flow below, dialog1 means dialog identifier 1, and consists 498 of the parameters of the Replaces header for dialog 1. In [3] this is 499 the Call-ID, To-tag and From-tag. 501 Note that the transferee's agent emits a BYE to the transferor's 502 agent as an immediate consequence of processing the Replaces header. 504 The Transferor knows that both the Transferee and the Transfer Target 505 support the Replaces header from the Supported: replaces header 506 contained in the 200 OK responses from both. 508 Transferor Transferee Transfer 509 | | Target 510 | | | 511 dialog1 | INVITE/200 OK/ACK F1 F2 | 512 |<-------------------| | 513 dialog1 | INVITE (hold)/200 OK/ACK | 514 |------------------->| | 515 dialog2 | INVITE/200 OK/ACK | | 516 |---------------------------------------->| 517 dialog2 | INVITE (hold)/200 OK/ACK | 518 |---------------------------------------->| 519 dialog2 | REFER (Refer-To:sip:Transferee?Replaces=dialog1) F3 520 |---------------------------------------->| 521 dialog2 | 202 Accepted | | 522 |<----------------------------------------| 523 dialog2 | NOTIFY (100 Trying)| | 524 |<----------------------------------------| 525 dialog2 | | 200 OK | 526 |---------------------------------------->| 527 dialog3 | INVITE (Replaces:dialog1)/200 OK/ACK F4 528 | |<-------------------| 529 dialog1 | BYE/200 OK | | 530 |<-------------------| | 531 dialog2 | NOTIFY (200 OK) | | 532 |<----------------------------------------| 533 dialog2 | | 200 OK | 534 |---------------------------------------->| 535 dialog2 | BYE/200 OK | | 536 |---------------------------------------->| 537 | | (transferee and target converse) 538 dialog3 | | BYE/200 OK | 539 | |------------------->| 541 Figure 5. Transfer Protecting Transfer Target. 543 F1 INVITE Transferee -> Transferor 545 INVITE sip:transferor@atlanta.example.com SIP/2.0 546 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 547 Max-Forwards: 70 548 To: 549 From: ;tag=7553452 550 Call-ID: 090459243588173445 551 CSeq: 29887 INVITE 552 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 553 Supported: replaces 554 Contact: 555 Content-Type: application/sdp 556 Content-Length: ... 558 F2 200 OK Transferor -> Transferee 560 SIP/2.0 200 OK 561 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 562 To: ;tag=31431 563 From: ;tag=7553452 564 Call-ID: 090459243588173445 565 CSeq: 29887 INVITE 566 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 567 Supported: replaces 568 Contact: 569 Content-Type: application/sdp 570 Content-Length: ... 572 F3 REFER Transferor -> Transfer Target 574 REFER sip:transfertarget@client.chicago.com SIP/2.0 575 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 576 Max-Forwards: 70 577 To: ;tag=a6c85cf 578 From: ;tag=1928301774 579 Call-ID: a84b4c76e66710 580 CSeq: 314159 REFER 581 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 582 Supported: replaces 583 Refer-To: 585 Contact: 586 Content-Length: 0 588 F4 INVITE Transfer Target -> Transferee 590 INVITE sip:transferee@192.0.2.4 SIP/2.0 591 Via: SIP/2.0/UDP client.chicago.com;branch=z9hG4bKnaslu84 592 Max-Forwards: 70 593 To: 594 From: ;tag=341234 595 Call-ID: kmzwdle3dl3d08 596 CSeq: 41 INVITE 597 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 598 Supported: replaces 599 Contact: 600 Replaces: 090459243588173445;to-tag=31431;from-tag=7553452 601 Content-Type: application/sdp 602 Content-Length: ... 604 6.3 Attended Transfer 606 The transferor places the transferee on hold, establishes a call with 607 the transfer target to alert them to the impending transfer, places 608 the target on hold, then proceeds with transfer using an escaped 609 Replaces header field in the Refer-To header. This is another common 610 service expected by current PBX and Centrex users. 612 Transferor Transferee Transfer 613 | | Target 614 | | | 615 dialog1 | INVITE/200 OK/ACK | | 616 |<-------------------| | 617 dialog1 | INVITE (hold)/200 OK/ACK | 618 |------------------->| | 619 dialog2 | INVITE/200 OK/ACK F1 F2 | 620 |---------------------------------------->| 621 dialog2 | INVITE (hold)/200 OK/ACK | 622 |---------------------------------------->| 623 dialog1 | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) F3 624 |------------------->| | 625 dialog1 | 202 Accepted | | 626 |<-------------------| | 627 dialog1 | NOTIFY (100 Trying)| | 628 |<-------------------| | 629 dialog1 | 200 OK | | 630 |------------------->| | 631 dialog3 | INVITE (Replaces:dialog2)/200 OK/ACK F4 632 | |------------------->| 633 dialog2 | BYE/200 OK | | 634 |<----------------------------------------| 635 dialog1 | NOTIFY (200 OK) | | 636 |<-------------------| | 637 dialog1 | 200 OK | | 638 |------------------->| | 639 dialog1 | BYE/200 OK | | 640 |------------------->| | 641 dialog3 | | BYE/200 OK | 642 | |<-------------------| 644 Figure 6. Attended Transfer Call Flow. 646 F1 INVITE Transferor -> Transfer Target 648 INVITE sip:transfertarget@chicago.example.com SIP/2.0 649 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432 650 Max-Forwards: 70 651 To: 652 From: ;tag=763231 653 Call-ID: 090459243588173445 654 CSeq: 29887 INVITE 655 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 656 Supported: replaces 657 Contact: 658 Content-Type: application/sdp 659 Content-Length: ... 661 F2 200 OK Transfer Target -> Transferee 663 SIP/2.0 200 OK 664 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432 665 ;received=192.0.2.1 666 To: ;tag=9m2n3wq 667 From: ;tag=763231 668 Call-ID: 090459243588173445 669 CSeq: 29887 INVITE 670 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 671 Supported: replaces 672 Contact: 673 Content-Type: application/sdp 674 Content-Length: ... 676 F3 REFER Transferor -> Transferee 678 REFER sip:transferee@192.0.2.4 SIP/2.0 679 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 680 Max-Forwards: 70 681 To: ;tag=a6c85cf 682 From: ;tag=1928301774 683 Call-ID: a84b4c76e66710 684 CSeq: 314159 REFER 685 Refer-To: 687 Contact: 688 Content-Length: 0 690 F4 INVITE Transferee -> Transfer Target 692 INVITE sip:transfertarget@client.chicago.example.com SIP/2.0 693 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnaslu82 694 Max-Forwards: 70 695 To: 696 From: ;tag=954 697 Call-ID: kmzwdle3dl3d08 698 CSeq: 41 INVITE 699 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 700 Supported: replaces 701 Contact: 702 Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 703 Content-Type: application/sdp 704 Content-Length: ... 706 6.4 Recovery when one party does not support REFER 708 If protecting or exposing the transfer target is not a concern, it is 709 possible to complete a transfer with consultation hold when only the 710 transferor and one other party support REFER. Note that a 405 Method 711 Not Allowed might be returned instead of the 501 Not Implemented 712 response. 714 Transferor Transferee Transfer 715 | | Target 716 | | | 717 dialog1 | INVITE/200 OK/ACK | | 718 |<-------------------| | 719 dialog1 | INVITE (hold)/200 OK/ACK | 720 |------------------->| | 721 dialog2 | INVITE/200 OK/ACK | | 722 |---------------------------------------->| 723 dialog2 | INVITE (hold)/200 OK/ACK | 724 |---------------------------------------->| 725 dialog1 | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) 726 |------------------->| | 727 dialog1 | 501 Not Implemented | 728 |<-------------------| | 729 dialog2 | REFER (Refer-To:sip:Transferee?Replaces=dialog1) 730 |---------------------------------------->| 731 dialog2 | 202 Accepted | | 732 |<----------------------------------------| 733 dialog2 | NOTIFY (100 Trying)| | 734 |<----------------------------------------| 735 dialog2 | | 200 OK | 736 |---------------------------------------->| 737 dialog3 | | INVITE (Replaces:dialog1)/200 OK/ACK 738 | |<-------------------| 739 dialog2 | NOTIFY (200 OK) | | 740 |<----------------------------------------| 741 | | 200 OK | 742 |---------------------------------------->| 743 dialog1 | BYE/200 OK | | 744 |<-------------------| | 745 dialog2 | BYE/200 OK | | 746 |---------------------------------------->| 747 dialog3 | | BYE/200 OK | 748 | |------------------->| 750 Figure 7. Recovery when one party does not support REFER. 752 6.5 Attended Transfer when Contact URI is Not Globally Routable 754 It is a requirement of RFC3261 that a Contact URI be globally 755 routable even outside the dialog. However, due to RFC2543 User 756 Agents and some architectures (NAT/Firewall traversal, screening 757 proxies, ALGs, etc.) this will not always be the case. As a result, 758 the method of Attended transfer shown in Figures 6 and 7 may fail 759 since they use the Contact URI in the Refer-To header field. Figure 760 8 shows such a scenario involving a Screening Proxy in which the 761 transfer initially fails but succeeds on a second try. The failure 762 (403 Forbidden, 404 Not Found, or a timeout after no response) 763 response is communicated back to the Transferor. Since this may be 764 caused by routing problems with the Contact URI, the Transferor 765 retries the REFER this time with Refer-To containing the Address of 766 Record (AOR) of the Target (the same URI the Transferor used to reach 767 the Target). However, the use of the AOR URI may result in routing 768 features being activated such as forking or sequential searching 769 which may result in the triggered INVITE reaching the wrong UA. To 770 prevent an incorrect UA answering the INVITE, a Require: replaces 771 header field is included in the Refer-To. This ensures that only the 772 UA which matches the Replaces dialog will answer the INVITE, since 773 any incorrect UA which supports Replaces will reply with a 481 and a 774 UA which does not support Replaces will reply with a 420. 776 Note that there is still no guarantee that the correct endpoint will 777 be reached, and the result of this second REFER may also be a 778 failure. In that case, the Transferor could fall back to unattended 779 transfer or give up on the transfer entirely. Since two REFERs are 780 sent within the dialog creating two distinct subscriptions, the 781 Transferee uses the 'id' parameter in the Event header field to 782 distinguish notifications for the two subscriptions. 784 Transferor Transferee Screening Transfer 785 | | Proxy Target 786 | | | | 787 dialog1 | INVITE/200 OK/ACK| | | 788 |<-----------------| | | 789 dialog1 | INVITE (hold)/200 OK/ACK | | 790 |----------------->| | | 791 dialog2 | INVITE/200 OK/ACK F1 F2 | | 792 |--------------------------------|------------>| 793 dialog2 | INVITE (hold)/200 OK/ACK | 794 |--------------------------------|------------>| 795 dialog1 | REFER (Refer-To:sip:TargetContact?Replaces=dialog2) F3 796 |----------------->| | | 797 dialog1 | 202 Accepted | | | 798 |<-----------------| | | 799 dialog1 | NOTIFY (100 Trying) | | 800 |<-----------------| | | 801 dialog1 | 200 OK | | | 802 |----------------->| | | 803 dialog3 | | INVITE (Replaces:dialog2)/403/ACK 804 | |------------>| | 805 dialog1 | NOTIFY (403 Forbidden) F4 | | 806 |<-----------------| | | 807 dialog1 | 200 OK | | | 808 |----------------->| | | 809 dialog1 |REFER(Refer-To:sip:TargetAOR?Replaces=dialog2&Require=replaces) F5 810 |----------------->| | | 811 dialog1 | 202 Accepted | | | 812 |<-----------------| | | 813 dialog1 | NOTIFY (100 Trying) | | 814 |<-----------------| | | 815 dialog1 | 200 OK | | | 816 |----------------->| | | 817 dialog4 | INVITE (Replaces:dialog2, Require:replaces)/200 OK/ACK F6 818 | |------------>|------------>| 819 dialog2 | BYE/200 OK | | | 820 |<-------------------------------|<------------| 821 dialog1 | NOTIFY (200 OK) F7 | | 822 |<-----------------| | | 823 dialog1 | 200 OK | | | 824 |----------------->| | | 825 dialog1 | BYE/200 OK | | | 826 |----------------->| | | 827 dialog3 | | | BYE/200 OK | 828 | |<------------|-------------| 830 Figure 8. Attended Transfer Call Flow with non-routable Contact URI 832 F1 INVITE Transferor -> Transfer Target 834 INVITE sip:transfertarget@chicago.example.com SIP/2.0 835 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bK76 836 Max-Forwards: 70 837 To: 838 From: ;tag=763231 839 Call-ID: 090459243588173445 840 CSeq: 29887 INVITE 841 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 842 Supported: replaces 843 Contact: 844 Content-Type: application/sdp 845 Content-Length: ... 847 F2 200 OK Transfer Target -> Transferee 849 SIP/2.0 200 OK 850 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432 851 ;received=192.0.2.1 852 To: ;tag=9m2n3wq 853 From: ;tag=763231 854 Call-ID: 090459243588173445 855 CSeq: 29887 INVITE 856 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 857 Supported: replaces 858 Contact: 859 Content-Type: application/sdp 860 Content-Length: ... 862 F3 REFER Transferor -> Transferee 864 REFER sip:transferee@192.0.2.4 SIP/2.0 865 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 866 Max-Forwards: 70 867 To: ;tag=a6c85cf 868 From: ;tag=1928301774 869 Call-ID: a84b4c76e66710 870 CSeq: 314159 REFER 871 Refer-To: 873 Contact: 874 Content-Length: 0 876 F4 NOTIFY Transferee -> Transferor 878 NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 879 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 880 Max-Forwards: 70 881 To: ;tag=1928301774 882 From: ;tag=a6c85cf 883 Call-ID: a84b4c76e66710 884 CSeq: 74 NOTIFY 885 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 886 Supported: replaces 887 Event: refer;id=3112 888 Subscription-State: terminated;reason=noresource 889 Content-Type: message/sipfrag 890 Content-Length: ... 892 SIP/2.0 403 Forbidden 894 F5 REFER Transferor -> Transferee 896 REFER sip:transferee@192.0.2.4 SIP/2.0 897 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 898 Max-Forwards: 70 899 To: ;tag=a6c85cf 900 From: ;tag=1928301774 901 Call-ID: a84b4c76e66710 902 CSeq: 314160 REFER 903 Refer-To: 905 Contact: 906 Content-Length: 0 908 F6 INVITE Transferee -> Transfer Target 910 INVITE sip:transfertarget@chicago.example.com SIP/2.0 911 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnaslu82 912 Max-Forwards: 70 913 To: 914 From: ;tag=954 915 Call-ID: 20482817324945934422930 916 CSeq: 42 INVITE 917 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 918 Supported: replaces 919 Contact: 920 Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 921 Require: replaces 922 Content-Type: application/sdp 923 Content-Length: ... 925 F7 NOTIFY Transferee -> Transferor 927 NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 928 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 929 Max-Forwards: 70 930 To: ;tag=1928301774 931 From: ;tag=a6c85cf 932 Call-ID: a84b4c76e66710 933 CSeq: 76 NOTIFY 934 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 935 Supported: replaces 936 Event: refer;id=98873867 937 Subscription-State: terminated;reason=noresource 938 Content-Type: message/sipfrag 939 Content-Length: ... 941 SIP/2.0 200 OK 943 For a UA which requires all request to be routed through a proxy 944 (such as for NAT/firewall traversal or screening/feature reasons), 945 special care must be taken in constructing a globally routable 946 Contact URI. One approach is to construct a URI which is unique for 947 the device which resolves to the proxy. A registration would then be 948 required to bind this URI to a URI which resolves directly to the 949 device. 951 For example, consider a UA with a username carol and a hostname 952 server51.example.com. A normal Contact would be automatically 953 generated in the form: 955 Contact: sip:carol@serv51.example.com 957 However, if this UA requires that all requests come through a proxy 958 server at p1.chicago.com then this Contact will not work as the proxy 959 will be bypassed. 961 Consider instead a Contact of the form: 963 Contact: sip:serv51@example.com 965 in which this sip:serv51@example.com URI would be registered by the 966 UA against a Contact: 968 Contact: sip:carol@serv51.example.com 970 which resolves directly to the UA. 972 This means that a UA would first register a URI that corresponds to 973 the device. Then, it would register a users URI (AOR) and use the 974 device URI that it registered as the Contact URI. 976 Other approaches may also be used to generate a globally routable 977 Contact URI. 979 6.6 Aborting a Consultation Hold 981 In any of the consultation hold flows above, the Transferor may 982 decide to terminate its attempt to contact the Transfer target before 983 that session is established. Most frequently, that will be the end of 984 the scenario, but in some circumstances, the transferor may wish to 985 proceed with the transfer action. For example, he may wish to 986 complete the transfer knowing that the transferee will end up 987 eventually talking to the transfer-target's voice-mail service. Some 988 PBX systems support this feature, sometimes called "semi-attended 989 transfer", that is effectively a hybrid between a fully attended 990 transfer and an unattended transfer. A true implementation of this 991 feature requires a short ad-hoc conference between all parties, which 992 ensures that no media clipping occurs. This flow is outside the 993 scope of this document. 995 For flows that expose the transfer target, this simply becomes a 996 basic transfer. 998 This scenario is far more complicated for flows that protect the 999 transfer target. Since no session is established between the 1000 transferor and the transfer target, the transfer target's agent would 1001 have to honor out-of-session REFERs, and somehow indicate what's 1002 happening via its user interface (this scenario is most likely to 1003 occur when the transfer-target is away from his agent). 1005 6.7 Attended Transfer Fallback to Basic Transfer 1007 In this flow, an attempted attended transfer fails so the transferor 1008 falls back to basic transfer. The use of OPTIONS is shown when the 1009 Transferee and Transfer Target do not explicitly indicate support for 1010 the REFER method and Replaces header fields in Allow and Supported 1011 header fields. In dialog1, the Transferor determines using OPTIONS 1012 that the Transferee does support REFER and Replaces. As a result, 1013 the Transferor begins the attended transfer by placing the Transferee 1014 on hold and calling the Transfer Target. Using an OPTIONS in 1015 dialog2, the Transferor determines that the Target does not support 1016 either REFER or Replaces, making attended transfer impossible. (Note 1017 that the same information could have been determined by including a 1018 Require: replaces in the initial INVITE in dialog2, which would have 1019 failed with a 421 response.) The Transferor then ends dialog2 by 1020 sending a BYE then sends a REFER to the Transferee using the AOR URI 1021 of the Transfer Target. 1023 Transferor Transferee Transfer 1024 | | Target 1025 | | | 1026 dialog1 | INVITE/200 OK/ACK | | 1027 |<-------------------| | 1028 dialog1 | OPTIONS/200 OK | | 1029 |------------------->| | 1030 dialog1 | INVITE (hold)/200 OK/ACK | 1031 |------------------->| | 1032 dialog2 | INVITE/200 OK/ACK | | 1033 |---------------------------------------->| 1034 dialog2 | OPTIONS/200 OK | | 1035 |---------------------------------------->| 1036 dialog2 | BYE/200 OK | | 1037 |---------------------------------------->| 1038 dialog1 | REFER (Refer-To:sip:TransferTarget) | 1039 |------------------->| | 1040 dialog1 | 202 Accepted | | 1041 |<-------------------| | 1042 dialog1 | NOTIFY (100 Trying)| | 1043 |<-------------------| | 1044 dialog1 | 200 OK | | 1045 |------------------->| | 1046 dialog3 | | INVITE/200 OK/ACK | 1047 | |------------------->| 1048 dialog1 | NOTIFY (200 OK) | | 1049 |<-------------------| | 1050 dialog1 | 200 OK | | 1051 |------------------->| | 1052 dialog1 | BYE/200 OK | | 1053 |------------------->| | 1054 dialog3 | | BYE/200 OK | 1055 | |<-------------------| 1057 Figure 9. Attended Transfer Fallback to Basic Transfer. 1059 7. Transfer with Referred-By 1061 In the previous examples, the Transfer Target does not have 1062 definitive information about what party initiated the transfer, or, 1063 in some cases, even that transfer is taking place. The Referred-By 1064 mechanism [4] provides a way for the Transferor to provide the 1065 Transferee with a way to let the Transfer Target know what party 1066 initiated the transfer. 1068 The simplest and least secure approach just involves the inclusion of 1069 the Referred-By header field in the REFER which is then copied into 1070 the triggered INVITE. However, a more secure mechanism involving the 1071 Referred-By security token which is generated and signed by the 1072 Transferor and passed in a message body to the Transferee then to the 1073 Transfer Target. A call flow showing the request is in [4] 1075 8. Transfer with multiple parties 1077 In this example the Originator places call to the Facilitator who 1078 reaches the Recipient through the Screener. The Recipient's contact 1079 information is exposed to the Facilitator and the Originator. This 1080 example is provided for clarification of the semantics of the REFER 1081 method only and should not be used as the design of an 1082 implementation. 1084 Originator Facilitator Screener Recipient 1085 Call-ID | | | | 1086 1 |INVITE/200 OK/ACK | |"Get Fred for me!" 1087 |----------->| | | "Right away!" 1088 1 |INVITE (hold)/200 OK/ACK | | 1089 |<-----------| | | 1090 2 | |INVITE/200 OK/ACK |"I have a call 1091 | |----------->| |from Mary for Fred" 1092 2 | |INVITE (hold)/200 OK/ACK "Hold please" 1093 | |<-----------| | 1094 3 | | |INVITE/200 OK/ACK 1095 | | |--------->|"You have a call 1096 | | | |from Mary" 1097 | | | | "Put her through" 1098 3 | | |INVITE (hold)/200 OK/ACK 1099 | | |--------->| 1100 2 | |REFER | | 1101 | |<-----------| | 1102 2 | |202 Accepted| | 1103 | |----------->| | 1104 2 | |NOTIFY (100 Trying) | 1105 | |----------->| | 1106 2 | |200 OK | | 1107 | |<-----------| | 1108 2 | |INVITE/200 OK/ACK | 1109 | |---------------------->|"This is Fred" 1110 2 | |NOTIFY (200 OK) | "Please hold for 1111 | |----------->| | Mary" 1112 2 | |200 OK | | 1113 | |<-----------| | 1114 2 | |BYE/200 OK | | 1115 | |<-----------| | 1116 3 | | |BYE/200 OK| 1117 | | |--------->| 1118 2 | |INVITE (hold)/200 OK/ACK 1119 | |---------------------->| 1120 1 |REFER | | | 1121 |<-----------| | | 1122 1 |202 Accepted| | | 1123 |----------->| | | 1124 1 |NOTIFY (100 Trying) | | 1125 |----------->| | | 1126 1 |200 OK | | | 1127 |<-----------| | | 1128 1 |INVITE/200 OK/ACK | | 1129 |----------------------------------->| "Hey Fred" 1130 1 |NOTIFY (200 OK) | | "Hello Mary" 1131 |----------->| | | 1132 1 |200 OK | | | 1133 |<-----------| | | 1134 1 |BYE/200 OK | | | 1135 |<-----------| | | 1136 2 | |BYE/200 OK | | 1137 | |---------------------->| 1138 1 |BYE/200 OK | | | 1139 |<-----------------------------------| "See you later" 1141 Figure 10. Transfer with Multiple Parties Example. 1143 9. Changes from draft-sipping-cc-transfer-00 1145 o Added section on use of Referred-By header. 1147 o Added selected message details. 1149 o Added flow for attended transfer with non-globally routable 1150 Contact URI. 1152 o Added flow for attended transfer fallback to unattended transfer. 1154 o Added Security Considerations Section. 1156 10. IANA Considerations 1158 None. 1160 11. Security Considerations 1162 The call transfer flows shown in this document are implemented using 1163 the REFER and Replaces call control primitives in SIP. As such, the 1164 attacks and security approaches are those detailed in the REFER and 1165 Replaces documents which are briefly summarized in the following 1166 paragraphs. This document addresses the issue of protecting the 1167 Address of Record URI of a transfer target in Sections 6.1 and 6.2. 1169 Any REFER request must be appropriately authenticated and authorized 1170 using standard SIP mechanisms or calls may be hijacked. A user agent 1171 may use local policy or human intervention in deciding whether or not 1172 to accept a REFER. In generating NOTIFY responses based on the 1173 outcome of the triggered request, care should be taken in 1174 constructing the message/sipfrag body to ensure that no private 1175 information is leaked. 1177 An INVITE containing a Replaces header field should only be accepted 1178 if it has been properly authenticated and authorized using standard 1179 SIP mechanisms, and the requestor is authorized to perform dialog 1180 replacement. 1182 12. Acknowledgments 1184 This draft is a collaborative product of the SIP working group. 1185 Thanks to Rohan Mahy for his input on the use of Replaces in 1186 transfer. 1188 Normative References 1190 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1191 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1192 Session Initiation Protocol", RFC 3261, June 2002. 1194 [2] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-07 1195 (work in progress), December 2002. 1197 [3] Dean, R., Biggs, B. and R. Mahy, "The Session Inititation 1198 Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-02 1199 (work in progress), May 2002. 1201 [4] Sparks, R., "The Referred-By Mechanism", 1202 draft-ietf-sip-referredby-00 (work in progress), May 2002. 1204 Informative References 1206 [5] Mahy, R., "A Multi-party Application Framework for SIP", 1207 draft-ietf-sipping-cc-framework-01 (work in progress), July 1208 2002. 1210 Authors' Addresses 1212 Robert J. Sparks 1213 dynamicsoft 1214 5100 Tennyson Parkway 1215 Suite 1200 1216 Plano, TX 75024 1218 EMail: rsparks@dynamicsoft.com 1220 Alan Johnston 1221 WorldCom 1222 100 South 4th Street 1223 St. Louis, MO 63102 1225 EMail: alan.johnston@wcom.com 1227 Intellectual Property Statement 1229 The IETF takes no position regarding the validity or scope of any 1230 intellectual property or other rights that might be claimed to 1231 pertain to the implementation or use of the technology described in 1232 this document or the extent to which any license under such rights 1233 might or might not be available; neither does it represent that it 1234 has made any effort to identify any such rights. Information on the 1235 IETF's procedures with respect to rights in standards-track and 1236 standards-related documentation can be found in BCP-11. Copies of 1237 claims of rights made available for publication and any assurances of 1238 licenses to be made available, or the result of an attempt made to 1239 obtain a general license or permission for the use of such 1240 proprietary rights by implementors or users of this specification can 1241 be obtained from the IETF Secretariat. 1243 The IETF invites any interested party to bring to its attention any 1244 copyrights, patents or patent applications, or other proprietary 1245 rights which may cover technology that may be required to practice 1246 this standard. Please address the information to the IETF Executive 1247 Director. 1249 Full Copyright Statement 1251 Copyright (C) The Internet Society (2003). All Rights Reserved. 1253 This document and translations of it may be copied and furnished to 1254 others, and derivative works that comment on or otherwise explain it 1255 or assist in its implementation may be prepared, copied, published 1256 and distributed, in whole or in part, without restriction of any 1257 kind, provided that the above copyright notice and this paragraph are 1258 included on all such copies and derivative works. However, this 1259 document itself may not be modified in any way, such as by removing 1260 the copyright notice or references to the Internet Society or other 1261 Internet organizations, except as needed for the purpose of 1262 developing Internet standards in which case the procedures for 1263 copyrights defined in the Internet Standards process must be 1264 followed, or as required to translate it into languages other than 1265 English. 1267 The limited permissions granted above are perpetual and will not be 1268 revoked by the Internet Society or its successors or assignees. 1270 This document and the information contained herein is provided on an 1271 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1272 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1273 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1274 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1275 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1277 Acknowledgement 1279 Funding for the RFC Editor function is currently provided by the 1280 Internet Society.