Internet Engineering Task Force Robert Sparks Internet Draft MCI WorldCom draft-sparks-sip-cc-transfer-00.txt March 2000 SIP Call Control : Transfer STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 as 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 Abstract This document defines a SIP extension within the new Call Control Framework to provide Call Transfer capabilities. Sparks [Page 1]
Internet Draft CC Transfer March 2000 Table of Contents: 1 Overview ..........................................................3 2 Actors and Roles ..................................................4 3 Requirements ......................................................5 4 The TRANSFER Method ...............................................6 4.1 The Transfer-To Header...........................................6 4.2 Header Field Support for the TRANSFER Method.....................6 4.3 Message Body Inclusion...........................................7 4.4 Responses to the TRANSFER Method.................................8 4.5 Behavior of SIP User Agents......................................8 4.6 Behavior of SIP Registrars/Redirect Servers......................9 4.7 Behavior of SIP Proxies..........................................9 4.8 Security Considerations..........................................9 5 Example Uses ......................................................9 5.1 Unattended Transfer..............................................9 5.2 Unattended Transfer with Consultation Hold......................12 5.3 Attended Transfer...............................................13 5.4 Transfer with multiple parties..................................14 Author's Addresses...................................................16 6 Acknowledgments ..................................................16 7 References .......................................................16 MCI WorldCom [Page 2]
Internet Draft CC Transfer March 2000 1 Overview This document defines a SIP [2] extension to provide Call Transfer capabilities. It is part of a family of Call Control extensions described in the Call Control Framework document [3]. The mechanisms discussed here are most closely related to traditional unattended and consultation hold transfers. Discussion of attended transfer (where all parties are briefly in a conference) is deferred until the conferencing features in this framework are addressed. This work has roots in draft-ietf-sip-cc-01 [4] but some basic semantics are different. In particular, transfers are achieved through a new method and does not terminate the original signaling relationship. By disassociating transfers from the processing of BYE, these changes facilitate recovery of failed transfers and clarify state management in the participating entities. Implementers that started with the sip-cc-01 BYE-ALSO technique for blind-transfer should find it straightforward to migrate to the mechanisms set forth here. MCI WorldCom [Page 3]
Internet Draft CC Transfer March 2000 2 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 (and leaving the call). Transfer Target - the new party being introduced into a call with the Transferee. The following roles are used to describe transfer requirements and scenarios: Originator - 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. Recipient - the party the Originator is ultimately connected to. MCI WorldCom [Page 4]
Internet Draft CC Transfer March 2000 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 (see comment 1). 3. The Transferor MUST know whether or not the transfer was successful (see comment 2). Explicit non-Requirements 1. There is no requirement for the Transfer Target to be notified that he is receiving an INVITE as the result of a TRANSFER request (see comment 2). 2. Pending results from the SIP security infrastructure taskforce, there is no requirement for the Transfer Target to receive secured assurance of the Transferor's identity through SIP (see comment 2). Comments on Requirements 1. 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 unattended transfer failure for instance) will be lost. 2. Those requirements and non-requirements referencing comment 2 are significantly different from those in draft-ietf-sip-cc-01. MCI WorldCom [Page 5]
Internet Draft CC Transfer March 2000 4 The TRANSFER Method TRANSFER is a SIP method as defined by [2]. The TRANSFER method indicates that the recipient (the transferee) should contact a third party (the transfer target) using the contact information provided in the method. A success response indicates that the transferee was able to establish a session with the transfer target. The TRANSFER method follows the session's current signaling path. In particular, the Request-URI of the TRANSFER method identifies the transferee. Unless stated otherwise, the protocol for emitting and responding to a TRANSFER request are identical to those for a BYE request in [2]. The behavior of SIP entities not implementing the TRANSFER (or any other unknown) method is explicitly defined in [2] and is not discussed further here. A successful TRANSFER 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. 4.1 The Transfer-To Header Transfer-To is a request-header as defined by [2]. It may only appear in a TRANSFER request. It identifies the transfer target. Transfer-To = "Transfer-To" ":" ( name-addr | addr-spec ) A TRANSFER method MUST contain exactly one Transfer-To header. The Transfer-To header MAY be encrypted as part of end-end encryption. The Transfer-To header has no short form. The Contact header is an important part of the Route/Record-Route mechanism and is not available for this task. 4.2 Header Field Support for the TRANSFER Method This table adds a column to tables 4 and 5 in [2], describing header presence in a TRANSFER method. See [2] for a key for the symbols used. A row for the Transfer-To: request-header should be inferred, mandatory for TRANSFER, not applicable for all other methods. The enc and e-e columns in [2] apply to the TRANSFER method unmodified. MCI WorldCom [Page 6]
Internet Draft CC Transfer March 2000 Header Where TRANSFER Accept R - Accept-Encoding R - Accept-Language R o Allow R - Allow 405 m Authorization R o Call-ID gc m Contact R o Contact 1xx - Contact 2-6xx o Content-Encoding e - Content-Length e o <-SHOULD be present and Content-Type e - have a value of zero CSeq gc m Date g o Encryption g o Expires R o From gc m Hide R o Max-Forwards R o Organization g o Priority R - Proxy-Authenticate 407 o Proxy-Authorization R o Proxy-Require R o Require R o Retry-After R - Retry-After 404,480,486 o Retry-After 503 o Retry-After 600,603 o Response-Key R o Record-Route R o Record-Route 2xx o Route R o Server r o Subject R - Timestamp g o To gc(1) m Unsupported 420 o User-Agent g o Via gc(2) m Warning r o WWW-Authenticate 401 o 4.3 Message Body Inclusion A TRANSFER method MUST NOT contain a body. MCI WorldCom [Page 7]
Internet Draft CC Transfer March 2000 4.4 Extension Negotiation A TRANSFER request MUST contain the header Requires: cc.transfer 4.5 Responses to the TRANSFER Method An agent responding to a TRANSFER Method MUST return a 400 Bad Request if the request contained zero or more than one Transfer-To headers. An agent (including proxies generating local responses) MAY return a 100 Trying or any appropriate 400-600 class response as prescribed by [2]. If the transferee's agent decides to attempt the transfer, a 200 OK response MUST be returned by the if it was able to establish a session with the transferor, otherwise a 603 Decline MUST be returned. In particular, the transferee's agent MUST NOT mirror the transfer targets response to the transferee's invite. 4.6 Behavior of SIP User Agents UA receiving a well-formed TRANSFER request SHOULD request approval from the user to proceed. In the absence of that request, or upon receiving approval from the user, the UA MUST submit an INVITE to the resource identified by the Transfer-To: header using the Call-ID from the TRANSFER request. The remainder of that INVITE message is formed exactly as if the UA were placing a new call to that resource. In particular, media negotiation between the transferee and the transfer target is not affected by the media that had been negotiated between the transferor and the transferee. In accordance with [2], the UA SHOULD issue a provisional response to the TRANSFER method if it cannot issue a final response within 200ms of its receipt. The appropriate response to issue on receipt of a final response to the INVITE is discussed in "Responses to the TRANSFER Method". The TRANSFER transaction does not terminate the session between the transferor and the transferee. When the UAs for those parties should terminate that session, they must do so explicitly with a BYE request. A TRANSFER request is meaningful only in the context of an existing session. A UA receiving a TRANSFER request for an unknown call leg MUST return a 481 Call Leg/Transaction Does Not Exist and MUST NOT issue an INVITE to resource identified by that request's Transfer-To header as part of the TRANSFER transaction. MCI WorldCom [Page 8]
Internet Draft CC Transfer March 2000 The disposition of the media streams between the transferor and the transferee is not altered by the TRANSFER method. Agents may alter a session's media through additional signaling. For example, they may make use of the SIP hold re-INVITE [2] or the conferencing extensions provided by this framework. 4.7 Behavior of SIP Registrars/Redirect Servers Since TRANSFER has meaning only in the context of an existing session, a Registrar/Redirect Server that is not also playing the role of a User Agent (never issues a 200 OK in response to an INVITE) MUST respond to a TRANSFER request with a 481 Call Leg/Transaction Does Not Exist. 4.8 Behavior of SIP Proxies SIP Proxies do not require modification to support the TRANSFER method. Specifically, as required by [2], a proxy should process a TRANSFER request the same way it processes an OPTIONS request. 4.9 Security Considerations The security requirements of [2] apply to the TRANSFER method. This draft does not provide a mechanism for the Transfer Target to be alerted that this is a transferred call or to be assured of the identity of the Transferor. This mechanism relies on providing contact information for the transfer target to the transferee. Care should be taken to provide a suitably restricted URI if the transfer target is a protected resource. 5 Example Uses 5.1 Unattended Transfer Unattended 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 MCI WorldCom [Page 9]
Internet Draft CC Transfer March 2000 Transferee. The provided contact can be used to make new calls in the future. The diagrams below show indicate the first line of each message. All messages in a particular diagram share the same Call-ID. In these diagrams, media is managed through reINVITE holds, but using other mechanisms (mixing multiple media streams at the UA or using the conferencing extensions for example) are valid. 5.1.1 Successful Unattended Transfer Transferor Transferee Transfer | | Target | INVITE | | |<-------------------| | | 200 OK | | |------------------->| | | ACK | | |<-------------------| | | INVITE (hold) | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | TRANSFER | | |------------------->| | | 100 Trying | | |<-------------------| | | | INVITE | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | 200 OK | | |<-------------------| | | BYE | | |------------------->| | | 200 OK | | |<-------------------| | | | BYE | | |<-------------------| | | 200 OK | | |------------------->| MCI WorldCom [Page 10]
Internet Draft CC Transfer March 2000 5.1.2 Failed Unattended Transfer Transferor Transferee Transfer | | Target | | | | INVITE | | |<-------------------| | | 200 OK | | |------------------->| | | ACK | | |<-------------------| | | INVITE (hold) | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | TRANSFER | | |------------------->| | | 100 Trying | | |<-------------------| | | | INVITE | | |------------------->| | | 486 Busy Here | | |<-------------------| | | ACK | | |------------------->| | 603 Decline | | |<-------------------| | | INVITE (unhold) | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | BYE | | |------------------->| | | 200 OK | | |<-------------------| | MCI WorldCom [Page 11]
Internet Draft CC Transfer March 2000 5.2 Unattended 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 Unattended Transfer as described above. 5.2.1 Variation 1 : Exposes 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 unattended 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-TRANSFER transactions have been collapsed into one indicator with the arrow showing the direction of the request. 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 | TRANSFER | | |------------------->| | | 100 Trying | | |<-------------------| | Call-ID:1 | | INVITE/200 OK/ACK | | |------------------->| | 200 OK | | |<-------------------| | Call-ID:1 | BYE/200 OK | | |------------------->| | Call-ID:1 | | BYE/200 OK | | |<-------------------| MCI WorldCom [Page 12]
Internet Draft CC Transfer March 2000 5.2.2 Variation 2 : Protects 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. 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 | INVITE (hold)/200 OK/ACK | |---------------------------------------->| Call-ID:2 | TRANSFER | | |---------------------------------------->| | 100 Trying | | |<----------------------------------------| Call-ID:2 | | INVITE/200 OK/ACK | | |<-------------------| | 200 OK | | |<----------------------------------------| Call-ID:1 | BYE/200 OK | | |------------------->| | Call-ID:2 | BYE/200 OK | | |---------------------------------------->| Call-ID:2 | | BYE/200 OK | | |------------------->| 5.3 Attended Transfer In an attended transfer, the three actors participate in an ad-hoc conference as part of the event. Discussion of the implementation of attended transfer is thus deferred until the conferencing portion of the Call Control framework has been addressed. MCI WorldCom [Page 13]
Internet Draft CC Transfer March 2000 5.4 Transfer with multiple parties In this example the Originator places call to the Facilitator who reaches 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 TRANSFER 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 | |TRANSFER | | | |<-----------| | | |100 Trying | | | |----------->| | 2 | |INVITE/200 OK/ACK | | |---------------------->|"This is Fred" | |200 OK | | "Please hold for | |----------->| | Mary" 2 | |BYE/200 OK | | | |<-----------| | 3 | | |BYE/200 OK| | | |--------->| 2 | |INVITE (hold)/200 OK/ACK | |---------------------->| 1 |TRANSFER | | | |<-----------| | | |100 Trying | | | |----------->| | | 1 |INVITE/200 OK/ACK | | |----------------------------------->| "Hey Fred" |200 OK | | | "Hello Mary" |----------->| | | 1 |BYE/200 OK | | | |<-----------| | | MCI WorldCom [Page 14]
Internet Draft CC Transfer March 2000 2 | |BYE/200 OK | | | |---------------------->| 1 |BYE/200 OK | | | |<-----------------------------------| "See you later" MCI WorldCom [Page 15]
Internet Draft CC Transfer March 2000 Author's Addresses Robert Sparks MCI WorldCom 2400 N Glenville Drive Phone: +1-972-729-5241 Richardson, TX 75082 Email: Robert.Sparks@wcom.com 6 Acknowledgments The author thanks the following for their contribution to this work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, Kevin Summers and Dean Willis. 7 References [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC2026, October 1996. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [3] B. Campbell, "Framework for SIP Call Control Extensions", Internet Draft draft-campbell-sip-cc-framework-00, Internet Engineering Task Force, March 2000. Work in Progress. [4] H. Schulzrinne, J. Rosenberg, "SIP Call Control Services", Internet Draft draft-ietf-sip-cc-01, Internet Engineering Task Force, June 17, 1999 Work in Progress (expired). MCI WorldCom [Page 16]