view Side-By-Side changes
SIPPING WG R. Sparks Internet-Draft dynamicsoft Expires:April 25,August 12, 2003 A. Johnston WorldComOctober 25, 2002February 11, 2003 Session Initiation Protocol Call Control - Transferdraft-ietf-sipping-cc-transfer-00draft-ietf-sipping-cc-transfer-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents asInternet- Drafts.Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onApril 25,August 12, 2003. Copyright Notice Copyright (C) The Internet Society(2002).(2003). All Rights Reserved. Abstract This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). This work is part of the SIP Multiparty Call Control Framework. Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page 1] Internet-Draft SIP CC TransferOctober 2002February 2003 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.Changes from draft-sparks-sip-cc-transfer-06 . . . . . . . . 3 3.Actors and Roles . . . . . . . . . . . . . . . . . . . . . . 34.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 45.4. Using REFER to achieve Call Transfer . . . . . . . . . . . .5 6.4 5. Basic Transfer . . . . . . . . . . . . . . . . . . . . . . . 56.15.1 Successful Transfer . . . . . . . . . . . . . . . . . . . . 66.25.2 Failed Transfer . . . . . . . . . . . . . . . . . . . . . .7 6.2.19 5.2.1 Target Busy . . . . . . . . . . . . . . . . . . . . . . . .7 6.2.29 5.2.2 Transfer Target does not answer . . . . . . . . . . . . . .8 7.10 6. Transfer with Consultation Hold . . . . . . . . . . . . . .9 7.111 6.1 Exposing transfer target . . . . . . . . . . . . . . . . . .9 7.211 6.2 Protecting transfer target . . . . . . . . . . . . . . . . .11 7.313 6.3 Attended Transfer . . . . . . . . . . . . . . . . . . . . .12 7.416 6.4 Recovery when one party does not support REFER . . . . . . .13 7.5 Consultation Hold in the presence of forking proxies19 6.5 Attended Transfer when Contact URI is Not Globally Routable . . . . . . . . . . . .14 7.6. . . . . . . . . . . . . . 20 6.6 Aborting a Consultation Hold . . . . . . . . . . . . . . . .16 8.24 6.7 Attended Transfer Fallback to Basic Transfer . . . . . . . . 25 7. Transfer withmultiple partiesReferred-By . . . . . . . . . . . . . . .16 9. Open Issues. . 26 8. Transfer with multiple parties . . . . . . . . . . . . . . . 27 9. Changes from draft-sipping-cc-transfer-00 . . . . . . . . .1828 10.To DoIANA Considerations . . . . . . . . . . . . . . . . . . . . 28 11. Security Considerations . . . . . . .18 11.. . . . . . . . . . . 28 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . .1829 Normative References . . . . . . . . . . . . . . . . . . . . 29 Informative References . . . . . . .18 Authors' Addresses. . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . .19 Full Copyright Statement. . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . .2031 Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page 2] Internet-Draft SIP CC TransferOctober 2002February 2003 1. Overview This document describes providing Call Transfer capabilities and requirements in SIP [1]. This work is part of the Multiparty Call Control Framework[2].[5]. The mechanisms discussed here are most closely related to traditional basic and consultation hold transfers. This document does not discuss transfer scenarios involving ad-hoc conferences (where all parties involved are briefly in a conference until this transferor drops out). This document details the use of REFER method[3][2] and Replaces[4][3] header field to achieve call transfer. A user agent that fully supports the transfer mechanisms described in this document MUST support REFER[2] and Replaces[3] in addition to RFC 3261 [1]. 2.Changes from draft-sparks-sip-cc-transfer-06 o Fixed Call-ID errors o Added Replaces requirement o Added Supported, Allow, etc requirement o Removed use of Accept-Contact header o Added language about creation of routable Contact URI o Updated flows for refer-06 behavior o Editorial cleanup 3.Actors and Roles There are three actors in a given transfer event, each playing one of the following roles: Transferee - the party being transferred to the Transfer Target. Transferor - the party initiating the transfer Transfer Target - the new party being introduced into a call with the Transferee. The following roles are used to describe transfer requirements and scenarios:Sparks & Johnston Expires April 25, 2003 [Page 3] Internet-Draft SIP CC Transfer October 2002Originator - wishes to place a call to the Recipient. This actor is the source of the first INVITE in a session, to either a Facilitator or a Screener. Facilitator - receives a call or out-of-band request from the Originator, establishes a call to the Recipient through the Screener, and connects the Originator to the Recipient. Screener - receives a call ultimately intended for the Recipient and transfers the calling party to the Recipient if appropriate. Sparks & Johnston Expires August 12, 2003 [Page 3] Internet-Draft SIP CC Transfer February 2003 Recipient - the party the Originator is ultimately connected to.4.3. Requirements 1. Any party in a SIP session MUST be able to transfer any other party in that session at any point in that session. 2. The Transferor and the Transferee MUST NOT be removed from a session as part of a transfer transaction. At first glance, requirement 2 may seem to indicate that the user experience in a transfer must be significantly different from what a current PBX or Centrex user expects. As the call-flows in this document show, this is not the case. A client MAY preserve the current experience. In fact, without this requirement, some forms of the current experience (ringback on transfer failure for instance) will be lost. 3. The Transferor MUST know whether or not the transfer was successful (this is significantly different from the requirements of the earlier BYE-Also approach to transfer). 4. The Transferee MUST be able to replace an existing dialog with a new dialog. 5. The Transferor and Transferee SHOULD indicate their support for the primitives required to achieve transfer.Sparks & Johnston Expires April 25, 2003 [Page 4] Internet-Draft SIP CC Transfer October 2002 5.4. Using REFER to achieve Call Transfer A REFER[3][2] can be issued by the Transferor to cause the Transferee to issue an INVITE to the Transfer-Target. Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request. The media negotiated between the transferee and the transfer target is not affected by the media that had been negotiated between the transferor and the transferee. In particular, the INVITE issued by the Transferee will have the same SDP body it would have if he Transferee had initiated that INVITE on its own. Further, the disposition of the media streams between the Transferor and the Transferee is not altered by the REFER method. Agents may alter a session's media through additional signaling. For example, they may make use of the SIP hold re-INVITE [1] or the conferencing extensions Sparks & Johnston Expires August 12, 2003 [Page 4] Internet-Draft SIP CC Transfer February 2003 provided by this framework.6.5. Basic Transfer Basic Transfer consists of the Transferor providing the Transfer Target's contact to the Transferee. The Transferee attempts to establish a session using that contact and reports the results of that attempt to the Transferor. The signaling relationship between the Transferor and Transferee is not terminated, so the call is recoverable if the Transfer Target cannot be reached. Note that the Transfer Target's contact information has been exposed to the Transferee. The provided contact can be used to make new calls in the future. The participants in a basic transfer should indicate support for the REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to INVITE, and OPTIONS. The diagrams below show indicate the first line of each message. The first column of the figure shows the Call-ID used in that particular message. In these diagrams, media is managed through re-INVITE holds, but other mechanisms (mixing multiple media streams at the UA or using the conferencing extensions for example) are valid. Selected message details are shown labeled as message F1, F2, etc. Each of the flows below shows the dialog between the Transferor and the Transferee remaining connected (on hold) during the REFER process. While this provides the greatest flexibility for recovery from failure, it is not necessary. If the Transferor's agent does not wish to participate in the remainder of the REFER process and has no intention of assisting with recovery from transfer failure, it could emit a BYE to the Transferee as soon as the REFER transaction completes. This flow is sometimes known as "unattended transfer". Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page 5] Internet-Draft SIP CC TransferOctober 2002 6.1February 2003 5.1 Successful Transfer Transferor Transferee Transfer | | Target | INVITE | | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | ACK | | Call-ID:1 |<-------------------| | | INVITE (hold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | REFER F1 | | Call-ID:1 |------------------->| | | 202 Accepted | | Call-ID:1 |<-------------------| | | NOTIFY (100Trying)|Trying) F2 | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | | INVITE F3 | Call-ID:2 | |------------------->| | | 200 OK | Call-ID:2 | |<-------------------| | | ACK | Call-ID:2 | |------------------->| | NOTIFY (200 OK)|F4| | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | BYE | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | | BYE | Call-ID:2 | |<-------------------| | | 200 OK | Call-ID:2 | |------------------->| Figure 1. Basic Transfer Call Flow.Sparks &F1 REFER Transferor -> Transferee Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page 6] Internet-Draft SIP CC TransferOctober 2002 6.2February 2003 REFER sip:transferee@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKna9 Max-Forwards: 70 To: <sip:transferee@biloxi.example.com>;tag=a6c85cf From: <sip:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Refer-To: <sip:transfertarget@chicago.example.com> Contact: <sip:transferor@pc33.atlanta.example.com> Content-Length: 0 F2 NOTIFY Transferee -> Transferor NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: <sip:transferor@atlanta.example.com>;tag=1928301774 From: <sip:transferee@biloxi.example.com>;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 73 NOTIFY Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Event: refer Subscription-State: active;expires=60 Content-Type: message/sipfrag Content-Length: ... SIP/2.0 100 Trying F3 INVITE Transferee -> Transfer Target INVITE sip:transfertarget@chicago.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas41234 Max-Forwards: 70 To: <sip:transfertarget@chicago.example.com> From: <sip:transferee@biloxi.example.com>;tag=j3kso3iqhq Call-ID: 90422f3sd23m4g56832034 CSeq: 521 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sip:transferee@192.0.2.4> Content-Type: application/sdp Content-Length: ... Sparks & Johnston Expires August 12, 2003 [Page 7] Internet-Draft SIP CC Transfer February 2003 F4 NOTIFY Transferee -> Transferor NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: <sip:transferor@atlanta.example.com>;tag=1928301774 From: <sip:transferee@biloxi.example.com>;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 74 NOTIFY Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Event: refer Subscription-State: terminated;reason=noresource Content-Type: message/sipfrag Content-Length: ... SIP/2.0 200 OK Sparks & Johnston Expires August 12, 2003 [Page 8] Internet-Draft SIP CC Transfer February 2003 5.2 Failed Transfer This section shows examples of failed transfer attempts. After the transfer failure occurs, the Transferor takes the Transferee off hold and resumes the session.6.2.15.2.1 Target Busy Transferor Transferee Transfer | | Target | | | | INVITE | | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | ACK | | Call-ID:1 |<-------------------| | | INVITE (hold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | REFER | | Call-ID:1 |------------------->| | | 202 Accepted | | Call-ID:1 |<-------------------| | | NOTIFY (100 Trying)| | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | | INVITE | Call-ID:2 | |------------------->| | | 486 Busy Here | Call-ID:2 | |<-------------------| | | ACK | Call-ID:2 | |------------------->| | NOTIFY (503 Service Unavailable) | | or NOTIFY (486 Busy Here) | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | INVITE (unhold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page7]9] Internet-Draft SIP CC TransferOctober 2002February 2003 Call-ID:1 |------------------->| | | BYE | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | Figure 2. Failed Transfer - Target Busy6.2.25.2.2 Transfer Target does not answer Transferor Transferee Transfer | | Target | INVITE | | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | ACK | | Call-ID:1 |<-------------------| | | INVITE (hold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | REFER | | Call-ID:1 |------------------->| | | 202 Accepted | | Call-ID:1 |<-------------------| | | NOTIFY (100 Trying)| | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | | INVITE | Call-ID:2 | |------------------->| | | 180 Ringing | Call-ID:2 | |<-------------------| | | (Transferee gets tired of waiting) | | CANCEL | Call-ID:2 | |------------------->| | | 200 OK (CANCEL) | Call-ID:2 | |<-------------------| | | 487 Request Cancelled (INVITE) Call-ID:2 | |<-------------------| | | ACK | Call-ID:2 | |------------------->| | NOTIFY (487 Request Cancelled) | Call-ID:1 |<-------------------| | Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page8]10] Internet-Draft SIP CC TransferOctober 2002 Call-ID:1 |<-------------------| |February 2003 | 200 OK | | Call-ID:1 |------------------->| | | INVITE (unhold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | BYE | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | Figure 3. Failed Transfer - Target Does Not Answer.7.6. Transfer with Consultation Hold Transfer with Consultation Hold involves a session between the transferor and the transfer target before the transfer actually takes place. This is implemented with SIP Hold and Transfer as described above.7.16.1 Exposing transfer target The transferor places the transferee on hold, establishes a call with the transfer target to alert them to the impending transfer, terminates the connection with the transfer target, then proceeds with transfer as above. This variation can be used to provide an experience similar to that expected by current PBX and Centrex users. To (hopefully) improve clarity, non-REFER transactions have been collapsed into one indicator with the arrow showing the direction of the request. Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page9]11] Internet-Draft SIP CC TransferOctober 2002February 2003 Transferor Transferee Transfer | | Target | | | Call-ID:1 | INVITE/200 OK/ACK | | |<-------------------| | Call-ID:1 | INVITE (hold)/200 OK/ACK | |------------------->| | Call-ID:2 | INVITE/200 OK/ACK | | |---------------------------------------->| Call-ID:2 | BYE/200 OK | | |---------------------------------------->| Call-ID:1 | REFER | | |------------------->| | Call-ID:1 | 202 Accepted | | |<-------------------| | Call-ID:1 | NOTIFY (100 Trying)| | |<-------------------| | Call-ID:1 | 200 OK | | |------------------->| | Call-ID:3 | | INVITE/200 OK/ACK | | |------------------->| Call-ID:1 | NOTIFY (200 OK) | | |<-------------------| | Call-ID:1 | 200 OK | | |------------------->| | Call-ID:1 | BYE/200 OK | | |------------------->| | Call-ID:3 | | BYE/200 OK | | |<-------------------| Figure 4. Transfer with Consultation Hold - Exposing Transfer Target. Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page10]12] Internet-Draft SIP CC TransferOctober 2002 7.2February 2003 6.2 Protecting transfer target The transferor places the transferee on hold, establishes a call with the transfer target and then reverses their roles, transferring the original transfer target to the original transferee. This has the advantage of hiding information about the original transfer target from the original transferee. On the other hand, the Transferee's experience is different that in current systems. The Transferee is effectively "called back" by the Transfer Target. One of the problems with this simplest implementation of a target protecting transfer is that the transferee is receiving a new call from the transfer-target. Unless the transferee's agent has a reliable way to associate this new call with the call it already has with the transferor, it will have to alert the new call on another appearance. If this, or some other call-waiting-like UI were not available, the transferee might be stuck returning a Busy-Here to the transfer target, effectively preventing the transfer. There are many ways that that correlation could be provided. The dialog parameters could be provided directly as header parameters in the Refer-To: URI for example. The Replaces mechanism[4][3] uses this approach and solves this problem nicely. For the flow below, dialog1 means dialog identifier 1, and consists of the parameters of the Replaces header for dialog 1. In[4][3] this is the Call-ID, To-tag and From-tag. Note that the transferee's agent emits a BYE to the transferor's agent as an immediate consequence of processing the Replaces header. The Transferor knows that both the Transferee and the Transfer Target support the Replaces header from the Supported: replaces header contained in the 200 OK responses from both. Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page11]13] Internet-Draft SIP CC TransferOctober 2002February 2003 Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK|F1 F2 | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK | | |---------------------------------------->| dialog2 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| dialog2 | REFER (Refer-To:sip:Transferee?Replaces=dialog1) F3 |---------------------------------------->| dialog2 | 202 Accepted | | |<----------------------------------------| dialog2 | NOTIFY (100 Trying)| | |<----------------------------------------| dialog2 | | 200 OK | |---------------------------------------->| dialog3 ||INVITE (Replaces:dialog1)/200 OK/ACK F4 | |<-------------------| dialog1 | BYE/200 OK | | |<-------------------| | dialog2 | NOTIFY (200 OK) | | |<----------------------------------------| dialog2 | | 200 OK | |---------------------------------------->| dialog2 | BYE/200 OK | | |---------------------------------------->| | | (transferee and target converse) dialog3 | | BYE/200 OK | | |------------------->| Figure 5. Transfer Protecting Transfer Target.7.3F1 INVITE Transferee -> Transferor INVITE sip:transferor@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: <sip:transferor@atlanta.example.com> From: <sip:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Sparks & Johnston Expires August 12, 2003 [Page 14] Internet-Draft SIP CC Transfer February 2003 Contact: <sip:transferee@92.0.2.4> Content-Type: application/sdp Content-Length: ... F2 200 OK Transferor -> Transferee SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 To: <sip:transferor@atlanta.example.com>;tag=31431 From: <sip:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sip:transferor@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: ... F3 REFER Transferor -> Transfer Target REFER sip:transfertarget@client.chicago.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: <sip:transfertarget@chicago.example.com>;tag=a6c85cf From: <sip:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Refer-To: <sip:transferee@192.0.2.4;Replaces= 090459243588173445%3Bto-tag%3D31431%3Bfrom-tag%3D7553452> Contact: <sip:transferor@pc33.atlanta.example.com> Content-Length: 0 F4 INVITE Transfer Target -> Transferee INVITE sip:transferee@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP client.chicago.com;branch=z9hG4bKnaslu84 Max-Forwards: 70 To: <sip:transferee@biloxi.example.com> From: <sip:transfertarget@chicago.example.com>;tag=341234 Call-ID: kmzwdle3dl3d08 CSeq: 41 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Sparks & Johnston Expires August 12, 2003 [Page 15] Internet-Draft SIP CC Transfer February 2003 Supported: replaces Contact: <sip:transfertarget@client.chicago.com> Replaces: 090459243588173445;to-tag=31431;from-tag=7553452 Content-Type: application/sdp Content-Length: ... 6.3 Attended Transfer The transferor places the transferee on hold, establishes a call with the transfer target to alert them to the impending transfer, places the target on hold, then proceeds with transfer using an escaped Replaces header field in the Refer-To header. This is another common service expected by current PBX and Centrex users. Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page12]16] Internet-Draft SIP CC TransferOctober 2002February 2003 Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK|F1 F2 | |---------------------------------------->| dialog2 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| dialog1 | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) F3 |------------------->| | dialog1 | 202 Accepted | | |<-------------------| | dialog1 | NOTIFY (100 Trying)| | |<-------------------| | dialog1 | 200 OK | | |------------------->| | dialog3 ||INVITE (Replaces:dialog2)/200 OK/ACK F4 | |------------------->| dialog2 | BYE/200 OK | | |<----------------------------------------| dialog1 | NOTIFY (200 OK) | | |<-------------------| | dialog1 | 200 OK | | |------------------->| | dialog1 | BYE/200 OK | | |------------------->| | dialog3 | | BYE/200 OK | | |<-------------------| Figure 6. Attended Transfer Call Flow.7.4F1 INVITE Transferor -> Transfer Target INVITE sip:transfertarget@chicago.example.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432 Max-Forwards: 70 To: <sip:transfertarget@chicago.example.com> From: <sip:transferor@atlanta.example.com>;tag=763231 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sip:transferor@pc33.atlanta.example.com> Content-Type: application/sdp Sparks & Johnston Expires August 12, 2003 [Page 17] Internet-Draft SIP CC Transfer February 2003 Content-Length: ... F2 200 OK Transfer Target -> Transferee SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432 ;received=192.0.2.1 To: <sip:transfertarget@chicago.example.com>;tag=9m2n3wq From: <sip:transferor@atlanta.example.com>;tag=763231 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sip:transfertarget@client.chicago.example.com> Content-Type: application/sdp Content-Length: ... F3 REFER Transferor -> Transferee REFER sip:transferee@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: <sip:transferee@biloxi.example.com>;tag=a6c85cf From: <sip:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER Refer-To: <sip:transfertarget@client.chicago.example.com;Replaces= 090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231> Contact: <sip:transferor@pc33.atlanta.example.com> Content-Length: 0 F4 INVITE Transferee -> Transfer Target INVITE sip:transfertarget@client.chicago.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnaslu82 Max-Forwards: 70 To: <sip:transfertarget@chicago.example.com> From: <sip:transferee@biloxi.example.com>;tag=954 Call-ID: kmzwdle3dl3d08 CSeq: 41 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sip:transferee@192.0.2.4> Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 Content-Type: application/sdp Sparks & Johnston Expires August 12, 2003 [Page 18] Internet-Draft SIP CC Transfer February 2003 Content-Length: ... 6.4 Recovery when one party does not support REFER If protecting or exposing the transfer target is not a concern, it is possible to complete a transfer with consultation hold when only the transferor and one other party support REFER. Note that a 405 Method Not Allowed might be returned instead of the 501 Not Implemented response.Sparks & Johnston Expires April 25, 2003 [Page 13] Internet-Draft SIP CC Transfer October 2002Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | INVITE (hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK | | |---------------------------------------->| dialog2 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| dialog1 | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) |------------------->| | dialog1 | 501 Not Implemented | |<-------------------| | dialog2 | REFER (Refer-To:sip:Transferee?Replaces=dialog1) |---------------------------------------->| dialog2 | 202 Accepted | | |<----------------------------------------| dialog2 | NOTIFY (100 Trying)| | |<----------------------------------------| dialog2 | | 200 OK | |---------------------------------------->| dialog3 | | INVITE (Replaces:dialog1)/200 OK/ACK | |<-------------------| dialog2 | NOTIFY (200 OK) | | |<----------------------------------------| | | 200 OK | |---------------------------------------->| dialog1 | BYE/200 OK | | |<-------------------| | dialog2 | BYE/200 OK | | |---------------------------------------->| dialog3 | | BYE/200 OK | | |------------------->|Figure 7. RecoverySparks & Johnston Expires August 12, 2003 [Page 19] Internet-Draft SIP CC Transfer February 2003 Figure 7. Recovery when one party does not support REFER.7.5 Consultation Hold in the presence of forking proxies6.5 Attended Transfer when Contact URI is Not Globally Routable It isworth notinga requirement of RFC3261 that a Contact URI be globally routable even outside theexamples given above abstract away any proxies that mightdialog. However, due to RFC2543 User Agents and some architectures (NAT/Firewall traversal, screening proxies, ALGs, etc.) this will not always bebetweenthethree parties. Incase. As a result, theexamplesmethod of Attended transfer shown in Figures4, 5,6 and6,7 may fail since they use the Contact URIused to reachin theTransfer Target may go throughRefer-To header field. Figure 8 shows such aforking proxy. There is no guarantee thatscenario involving a Screening Proxy in which theTransferee's and Transferor's invitationstransfer initially fails but succeeds on a second try. The failure (403 Forbidden, 404 Not Found, or a timeout after no response) response is communicated back to theTransfer Target will reachTransferor. Since this may be caused by routing problems with thesame endpoint. IfContact URI, theproxy forked in parallel, both invitations could cause multiple endpoints to ring. Sparks & Johnston Expires April 25, 2003 [Page 14] Internet-Draft SIP CC Transfer October 2002 To increaseTransferor retries theprobability ofREFER this time with Refer-To containing thedesired behaviorAddress of Record (AOR) ofhaving the referred invite reach and ring onlythe Target (the sameendpoint as the consultation invite,URI the TransferorSHOULD issueused to reach theREFER request withTarget). However, theRefer-To: header containinguse of theContactAOR URIthe Transfer Target providedmay result in routing features being activated such as forking or sequential searching which may result inits 200 OK to the Transferor's INVITE. If that REFER fails, the Transferor SHOULD issue another REFER withtheRefer-To: header containingtriggered INVITE reaching theURI it used to reachwrong UA. To prevent an incorrect UA answering theTransfer Target, augmented withINVITE, a Require: replaces headerfield.field is included in the Refer-To. This ensures that only theendpointUA whichhasmatches theactiveReplaces dialog willaccept the INVITE request. Note that the Require:replaces header is necessary so that a ifanswer therequest is forked toINVITE, since any incorrect UA which supports Replaces will reply with adifferent endpoint481 and a UA which does not supportReplaces, the endpointReplaces willrespondreply with a420 Bad Extension instead of accepting the INVITE.420. Note thatany RFC 3261 compliant will generate a Contact URI which is routable outside a dialog as per Section 8.1.1.8 of RFC 3261. For a UA which requires all request to be routed through a proxy (such as for NAT/firewall traversal or screening/feature reasons), special care must be taken in constructing the Contact URI. One approach is to construct a URI whichthere isunique for the device which resolves tostill no guarantee that theproxy. A registration would thencorrect endpoint will berequired to bindreached, and the result of thisURI tosecond REFER may also be aURI which resolves directlyfailure. In that case, the Transferor could fall back to unattended transfer or give up on thedevice. For example, consider a UA with a username carol and a hostname server51.chicago.com. A normal Contact would be automatically generated intransfer entirely. Since two REFERs are sent within theform: Contact: sip:carol@serv51.chicago.com However, if this UA requires that all requests come through a proxy server at p1.chicago.com then this Contact will not work asdialog creating two distinct subscriptions, theproxy will be bypassed. Another approach would involve a Contact ofTransferee uses theform: Contact: sip:serv51@chicago.com'id' parameter inwhich this sip:serv51@chicago.com URI would be registered bytheUA against a Contact: Contact: sip:carol@serv51.chicago.com which resolves directlyEvent header field to distinguish notifications for theUA. This means that a UA would first register a URI that corresponds to Sparks & Johnston Expires April 25, 2003 [Page 15] Internet-Draft SIP CCtwo subscriptions. Transferor Transferee Screening TransferOctober 2002 the device. Then, it would register a users URI (AOR) and use the device URI that it registered as the Contact URI. An alternative approach (which is not compatible| | Proxy Target | | | | dialog1 | INVITE/200 OK/ACK| | | |<-----------------| | | dialog1 | INVITE (hold)/200 OK/ACK | | |----------------->| | | dialog2 | INVITE/200 OK/ACK F1 F2 | | |--------------------------------|------------>| dialog2 | INVITE (hold)/200 OK/ACK | |--------------------------------|------------>| dialog1 | REFER (Refer-To:sip:TargetContact?Replaces=dialog2) F3 |----------------->| | | dialog1 | 202 Accepted | | | Sparks & Johnston Expires August 12, 2003 [Page 20] Internet-Draft SIP CC Transfer February 2003 |<-----------------| | | dialog1 | NOTIFY (100 Trying) | | |<-----------------| | | dialog1 | 200 OK | | | |----------------->| | | dialog3 | | INVITE (Replaces:dialog2)/403/ACK | |------------>| | dialog1 | NOTIFY (403 Forbidden) F4 | | |<-----------------| | | dialog1 | 200 OK | | | |----------------->| | | dialog1 |REFER(Refer-To:sip:TargetAOR?Replaces=dialog2&Require=replaces) F5 |----------------->| | | dialog1 | 202 Accepted | | | |<-----------------| | | dialog1 | NOTIFY (100 Trying) | | |<-----------------| | | dialog1 | 200 OK | | | |----------------->| | | dialog4 | INVITE (Replaces:dialog2, Require:replaces)/200 OK/ACK F6 | |------------>|------------>| dialog2 | BYE/200 OK | | | |<-------------------------------|<------------| dialog1 | NOTIFY (200 OK) F7 | | |<-----------------| | | dialog1 | 200 OK | | | |----------------->| | | dialog1 | BYE/200 OK | | | |----------------->| | | dialog3 | | | BYE/200 OK | | |<------------|-------------| Figure 8. Attended Transfer Call Flow with non-routable Contact URI F1 INVITE Transferor -> Transfer Target INVITE sip:transfertarget@chicago.example.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bK76 Max-Forwards: 70 To: <sip:transfertarget@chicago.example.com> From: <sip:transferor@atlanta.example.com>;tag=763231 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sip:transferor@pc33.atlanta.example.com> Content-Type: application/sdp Sparks & Johnston Expires August 12, 2003 [Page 21] Internet-Draft SIP CC Transfer February 2003 Content-Length: ... F2 200 OK Transfer Target -> Transferee SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnas432 ;received=192.0.2.1 To: <sip:transfertarget@chicago.example.com>;tag=9m2n3wq From: <sip:transferor@atlanta.example.com>;tag=763231 Call-ID: 090459243588173445 CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sip:transfertarget@client.chicago.example.com> Content-Type: application/sdp Content-Length: ... F3 REFER Transferor -> Transferee REFER sip:transferee@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: <sip:transferee@biloxi.example.com>;tag=a6c85cf From: <sip:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 REFER Refer-To: <sip:transfertarget@client.chicago.example.com;Replaces= 090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231> Contact: <sip:transferor@pc33.atlanta.example.com> Content-Length: 0 F4 NOTIFY Transferee -> Transferor NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: <sip:transferor@atlanta.example.com>;tag=1928301774 From: <sip:transferee@biloxi.example.com>;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 74 NOTIFY Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Event: refer;id=3112 Subscription-State: terminated;reason=noresource Content-Type: message/sipfrag Sparks & Johnston Expires August 12, 2003 [Page 22] Internet-Draft SIP CC Transfer February 2003 Content-Length: ... SIP/2.0 403 Forbidden F5 REFER Transferor -> Transferee REFER sip:transferee@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: <sip:transferee@biloxi.example.com>;tag=a6c85cf From: <sip:transferor@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 REFER Refer-To: <sip:transfertarget@chicago.example.com;Replaces= 090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces> Contact: <sip:transferor@pc33.atlanta.example.com> Content-Length: 0 F6 INVITE Transferee -> Transfer Target INVITE sip:transfertarget@chicago.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnaslu82 Max-Forwards: 70 To: <sip:transfertarget@chicago.example.com> From: <sip:transferee@biloxi.example.com>;tag=954 Call-ID: 20482817324945934422930 CSeq: 42 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Contact: <sip:transferee@192.0.2.4> Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231 Require: replaces Content-Type: application/sdp Content-Length: ... F7 NOTIFY Transferee -> Transferor NOTIFY sip:transferor@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnas432 Max-Forwards: 70 To: <sip:transferor@atlanta.example.com>;tag=1928301774 From: <sip:transferee@biloxi.example.com>;tag=a6c85cf Call-ID: a84b4c76e66710 CSeq: 76 NOTIFY Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Sparks & Johnston Expires August 12, 2003 [Page 23] Internet-Draft SIP CC Transfer February 2003 Supported: replaces Event: refer;id=98873867 Subscription-State: terminated;reason=noresource Content-Type: message/sipfrag Content-Length: ... SIP/2.0 200 OK For a UA which requires all request to be routed through a proxy (such as for NAT/firewall traversal or screening/feature reasons), special care must be taken in constructing a globally routable Contact URI. One approach is to construct a URI which is unique for the device which resolves to the proxy. A registration would then be required to bind this URI to a URI which resolves directly to the device. For example, consider a UA with a username carol and a hostname server51.example.com. A normal Contact would be automatically generated in the form: Contact: sip:carol@serv51.example.com However, if this UA requires that all requests come through a proxy server at p1.chicago.com then this Contact will not work as the proxy will be bypassed. Consider instead a Contact of the form: Contact: sip:serv51@example.com in which this sip:serv51@example.com URI would be registered by the UA against a Contact: Contact: sip:carol@serv51.example.com which resolves directly to the UA. This means that a UA would first register a URI that corresponds to the device. Then, it would register a users URI (AOR) and use the device URI that it registered as the Contact URI. Other approaches may also be used to generate a globally routable Contact URI. 6.6 Aborting a Consultation Hold In any of the consultation hold flows above, the Transferor may Sparks & Johnston Expires August 12, 2003 [Page 24] Internet-Draft SIP CC Transfer February 2003 decide to terminate its attempt to contact the Transfer target before that session is established. Most frequently, that will be the end of the scenario, but in some circumstances, the transferor may wish to proceed withunextended RFC 2543 or 3261)the transfer action. For example, he may wish to complete the transfer knowing that the transferee will end up eventually talking to the transfer-target's voice-mail service. Some PBX systems support this feature, sometimes called "semi-attended transfer", that is effectively a hybrid between a fully attended transfer and an unattended transfer. A true implementation of this feature requires a short ad-hoc conference between all parties, which ensures that no media clipping occurs. This flow is outside the scope of this document. For flows that expose the transfer target, this simply becomes a basic transfer. This scenario is far more complicated for flows that protect the transfer target. Since no session is established between the transferor and the transfer target, the transfer target's agent wouldbehave to honor out-of-session REFERs, and somehow indicate what's happening via its user interface (this scenario is most likely to occur when the transfer-target is away from his agent). 6.7 Attended Transfer Fallback toincludeBasic Transfer In this flow, anescaped loose Routeattempted attended transfer fails so the transferor falls back to basic transfer. The use of OPTIONS is shown when the Transferee and Transfer Target do not explicitly indicate support for the REFER method and Replaces headerfieldfields in Allow and Supported header fields. In dialog1, theContact URI: Contact: sip:carol@serv51.chicago.com?Route=sip:p1.chicago.com;lr This would resultTransferor determines using OPTIONS that the Transferee does support REFER and Replaces. As a result, the Transferor begins the attended transfer by placing the Transferee on hold and calling the Transfer Target. Using an OPTIONS in dialog2, the Transferor determines that the Target does not support either REFER or Replaces, making attended transfer impossible. (Note that the same information could have been determined by including arequest being sent to sip:carol@serv51.chicago.comRequire: replaces in the initial INVITE in dialog2, which would have failed with aloose Route header forcing routing to sip:p1.chicago.com first. Open Issue: This syntax, while allowed in421 response.) The Transferor then ends dialog2 by sending aredirection, is not permitted in anBYE then sends a REFER to the Transferee using the AOR URI of the Transfer Target. Sparks & Johnston Expires August 12, 2003 [Page 25] Internet-Draft SIP CC Transfer February 2003 Transferor Transferee Transfer | | Target | | | dialog1 | INVITE/200 OK/ACK | | |<-------------------| | dialog1 | OPTIONS/200 OK | | |------------------->| | dialog1 | INVITEor(hold)/200 OK/ACK | |------------------->| | dialog2 | INVITE/200 OK/ACK | | |---------------------------------------->| dialog2 | OPTIONS/200 OK | | |---------------------------------------->| dialog2 | BYE/200 OK | | |---------------------------------------->| dialog1 | REFER (Refer-To:sip:TransferTarget) | |------------------->| | dialog1 | 202 Accepted | | |<-------------------| | dialog1 | NOTIFY (100 Trying)| | |<-------------------| | dialog1 | 200 OKresponse per Table 1 in RFC 3261. Other approaches may also be used| | |------------------->| | dialog3 | | INVITE/200 OK/ACK | | |------------------->| dialog1 | NOTIFY (200 OK) | | |<-------------------| | dialog1 | 200 OK | | |------------------->| | dialog1 | BYE/200 OK | | |------------------->| | dialog3 | | BYE/200 OK | | |<-------------------| Figure 9. Attended Transfer Fallback togenerate this globally routable Contact URI. 7.6 Aborting a Consultation HoldBasic Transfer. 7. Transfer with Referred-By Inany of the consultation hold flows above,theTransferor may decide to terminate its attempt to contactprevious examples, the Transfertarget before that session is established. Most frequently, that will be the end ofTarget does not have definitive information about what party initiated thescenario, buttransfer, or, in somecircumstances,cases, even that transfer is taking place. The Referred-By mechanism [4] provides a way for thetransferor may wishTransferor toproceed withprovide thetransfer action. For example, he may wishTransferee with a way tocomplete the transfer knowing thatlet thetransferee will end up eventually talking toTransfer Target know what party initiated thetransfer-target's voice-mail service. Some PBX systems support this feature, sometimes called "semi-attended transfer", that is effectively a hybrid between a fully attended transfer and an unattendedtransfer.A true implementation of this feature requires a short ad-hoc conference between all parties, which ensures that no media clipping occurs. This flow is outsideThe simplest and least secure approach just involves thescopeinclusion ofthis document. For flows that exposethetransfer target, this simply becomes a basic transfer. This scenarioReferred-By header field in the REFER which isfarthen copied into the triggered INVITE. However, a morecomplicated for flows that protectsecure mechanism involving thetransfer target. Since no sessionSparks & Johnston Expires August 12, 2003 [Page 26] Internet-Draft SIP CC Transfer February 2003 Referred-By security token which isestablished between the transferorgenerated and signed by thetransfer target, the transfer target's agent would have to honor out-of-session REFERs,Transferor andsomehow indicate what's happening via its user interface (this scenario is most likelypassed in a message body tooccur whenthetransfer-targetTransferee then to the Transfer Target. A call flow showing the request isaway from his agent).in [4] 8. Transfer with multiple parties In this example the Originator places call to the Facilitator whoSparks & Johnston Expires April 25, 2003 [Page 16] Internet-Draft SIP CC Transfer October 2002reaches the Recipient through the Screener. The Recipient's contact information is exposed to the Facilitator and the Originator. This example is provided for clarification of the semantics of the REFER method only and should not be used as the design of an implementation. Originator Facilitator Screener Recipient Call-ID | | | | 1 |INVITE/200 OK/ACK | |"Get Fred for me!" |----------->| | | "Right away!" 1 |INVITE (hold)/200 OK/ACK | | |<-----------| | | 2 | |INVITE/200 OK/ACK |"I have a call | |----------->| |from Mary for Fred" 2 | |INVITE (hold)/200 OK/ACK "Hold please" | |<-----------| | 3 | | |INVITE/200 OK/ACK | | |--------->|"You have a call | | | |from Mary" | | | | "Put her through" 3 | | |INVITE (hold)/200 OK/ACK | | |--------->| 2 | |REFER | | | |<-----------| | 2 | |202 Accepted| | | |----------->| | 2 | |NOTIFY (100 Trying) | | |----------->| | 2 | |200 OK | | | |<-----------| | 2 | |INVITE/200 OK/ACK | | |---------------------->|"This is Fred" 2 | |NOTIFY (200 OK) | "Please hold for | |----------->| | Mary" 2 | |200 OK | | | |<-----------| | 2 | |BYE/200 OK | | | |<-----------| | 3 | | |BYE/200 OK| | | |--------->| 2 | |INVITE (hold)/200 OK/ACK Sparks & Johnston Expires August 12, 2003 [Page 27] Internet-Draft SIP CC Transfer February 2003 | |---------------------->| 1 |REFER | | | |<-----------| | | 1 |202 Accepted| | | |----------->| | | 1 |NOTIFY (100 Trying) | | |----------->| | |Sparks & Johnston Expires April 25, 2003 [Page 17] Internet-Draft SIP CC Transfer October 20021 |200 OK | | | |<-----------| | | 1 |INVITE/200 OK/ACK | | |----------------------------------->| "Hey Fred" 1 |NOTIFY (200 OK) | | "Hello Mary" |----------->| | | 1 |200 OK | | | |<-----------| | | 1 |BYE/200 OK | | | |<-----------| | | 2 | |BYE/200 OK | | | |---------------------->| 1 |BYE/200 OK | | | |<-----------------------------------| "See you later" Figure8.10. Transfer with Multiple Parties Example. 9.Open Issues The creationChanges from draft-sipping-cc-transfer-00 o Added section on use ofgloballyReferred-By header. o Added selected message details. o Added flow for attended transfer with non-globally routable ContactURIsURI. o Added flow for attended transfer fallback to unattended transfer. o Added Security Considerations Section. 10. IANA Considerations None. 11. Security Considerations The call transfer flows shown in this document are implemented using the REFER and Replaces call control primitives in SIP. As such, the attacks and security approaches are those detailed in the REFER and Replaces documents which are briefly summarized in the following Sparks & Johnston Expires August 12, 2003 [Page 28] Internet-Draft SIP CC Transfer February 2003 paragraphs. This document addresses the issue of protecting the Address of Record URI of a transfer target in Sections 6.1 and 6.2. Any REFER request must be appropriately authenticated and authorized using standard SIP mechanisms or calls may be hijacked. A user agent may useof escaped Route headerslocal policy or human intervention inContact header fieldsdeciding whether or not to accept a REFER. In generating NOTIFY responses based on the outcome of the triggered request, care should be taken in constructing the message/sipfrag body to ensure that no private information is leaked. An INVITE containing a Replaces header field should only be accepted if it has been properly authenticated and authorized using standard SIP mechanisms, and200 OK responses. 10. To Do Add message details to allthecall flows. 11.requestor is authorized to perform dialog replacement. 12. Acknowledgments This draft is a collaborative product of the SIP working group. Thanks to Rohan Mahy for his input on the use of Replaces in transfer. Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2]Mahy,Sparks, R.,Campbell, B., Johnston, A., Petrie, D., Rosenberg, J."The SIP Refer Method", draft-ietf-sip-refer-07 (work in progress), December 2002. [3] Dean, R., Biggs, B. and R.Sparks, "A Multi-party Application Framework for SIP", draft-ietf-sipping-cc-framework-01Mahy, "The Session Inititation Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-02 (work in progress),JuneMay 2002.[3][4] Sparks, R., "TheREFER Method", draft-ietf-sip-refer-06Referred-By Mechanism", draft-ietf-sip-referredby-00 (work in progress),JulyMay 2002.[4]Informative References [5] Mahy, R.,Biggs, B. and R. Dean, "The SIP Replaces Header","A Multi-party Application Framework for SIP", draft-ietf-sipping-cc-framework-01 (work in progress), July 2002. Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page18]29] Internet-Draft SIP CC TransferOctober 2002 draft-ietf-sipping-replaces-02 (work in progress), April 2002.February 2003 Authors' Addresses Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: rsparks@dynamicsoft.com Alan Johnston WorldCom 100 South 4th Street St. Louis, MO6310463102 EMail: alan.johnston@wcom.com Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page19]30] Internet-Draft SIP CC TransferOctober 2002February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society(2002).(2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors orassigns.assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Sparks & Johnston Expires August 12, 2003 [Page 31] Internet-Draft SIP CC Transfer February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sparks & Johnston ExpiresApril 25,August 12, 2003 [Page20]32] ----