Internet Draft Internet Engineering Task Force Robert Sparks Internet Draft dynamicsoft draft-ietf-sip-cc-transfer-00.txt July 2000 Expires February 2001 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. Robert Sparks [Page 1] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 1 Overview...........................................................3 2 Changes from draft-sparks-sip-cc-transfer-00.......................3 3 Actors and Roles...................................................4 4 Requirements.......................................................5 5 The REFER Method...................................................6 5.1 The Refer-To Header............................................6 5.2 The Referred-By Header.........................................7 5.2.1 A PGP based signature-scheme.................................7 5.3 Header Field Support for the REFER Method......................8 5.4 Message Body Inclusion.........................................9 5.5 Responses to the REFER Method..................................9 5.6 Behavior of SIP User Agents...................................10 5.7 Behavior of SIP Registrars/Redirect Servers...................10 5.8 Behavior of SIP Proxies.......................................10 5.9 Security Considerations.......................................11 6 Using REFER to achieve Call Transfer..............................11 6.1 Unattended Transfer...........................................11 6.1.1 Successful Unattended Transfer..............................12 6.1.2 Failed Unattended Transfer..................................13 6.2 Unattended Transfer with Consultation Hold....................14 6.2.1 Variation 1 : Exposes transfer target.......................14 6.3 Attended Transfer.............................................15 6.4 Transfer with multiple parties................................16 7 Author's Addresses................................................17 8 Acknowledgments...................................................17 9 References........................................................17 Robert Sparks [Page 2] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 1 Overview This document defines a SIP [2] extension and details its use to provide Call Transfer capabilities. This 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 that 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. 2 Changes from draft-sparks-sip-cc-transfer-00 . The method was renamed to reflect its function instead of this particular application of its function. TRANSFER and Transfer-To became REFER and Refer-To. REFER was generalized to support URLs beyond those indicating SIP INVITEs. . A Require header is no longer required. Bodies are allowed. . Copying Call-ID from the request was replaced by using a Refer-To: URL containing any headers that should be use. . Added a way for the identity specified in Refer-To: to know it has been referred to. . Added a mechanism to prove the identity of the issuer of the REFER to the identity specified in Refer-To. . The failure response returned to an attempted REFER has been changed from 603 to 503 to facilitate different behavior in the cases of "I won't accept that REFER" and "I tried that REFER and it failed" with Retry-After: support for the later. Robert Sparks [Page 3] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 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: 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. Robert Sparks [Page 4] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 4 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 unattended 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 draft-ietf-sip-cc-01). Robert Sparks [Page 5] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 5 The REFER Method REFER is a SIP method as defined by [2]. The REFER method indicates that the recipient should contact a third party using the contact information provided in the method. A success response indicates that the recipient was able to contact the third party. The REFER method follows the session's current signaling path. In particular, the Request-URI of the REFER method identifies the recipient. Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [2]. The behavior of SIP entities not implementing the REFER (or any other unknown) method is explicitly defined in [2] and is not discussed further here. 5.1 The Refer-To Header Refer-To is a request-header as defined by [2]. It may only appear in a REFER request. It identifies the transfer target. Refer-To = "Refer-To" ":" URL A REFER method MUST contain exactly one Refer-To header. The Refer-To header MAY be encrypted as part of end-end encryption. The Refer-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. Robert Sparks [Page 6] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 5.2 The Referred-By Header Referred-By is a request-header as defined by [2]. It can appear in any request. It conveys the identity of the original REFERrer to the referred-to party, optionally proving the identity and that the REFERrer actually issued this reference. Referred-By = "Referred-By" ":" referrer-url referenced-url [ref-signature] referrer-url = SIP-URL referenced-url = URL ref-signature = signature-scheme #sig-scheme-params signature-scheme = token sig-scheme-parms = token "=" ( token | quoted-string ) The referrer-url contains the SIP URL of the party sending the REFER request. The referenced-url contains a copy of the URL placed in the Refer-To: header. The ref-signature contains a signature over the concatenation of referrer-url and referenced-url. An example signature scheme is given in section 5.2.1. A REFER request MUST contain exactly one Referred-By header. The Referred-By header SHOULD be signed to help detection of REFERs from unauthorized third parties. A signed Referred-By header SHOULD include a Date header in the referrer-url to facilitate detection of replay attacks. A UA MAY reject a request containing an unsigned Referred-By header. A UA SHOULD verify the signature on any Referred-By header it receives. The Referred-By header MAY be encrypted as part of end-end encryption. The Referred-By header has no short form. 5.2.1 A PGP based signature-scheme One signature-scheme for Referred-By headers uses PGP as follows: Referred-By = "Referred-By" ":" referrer-url referenced-url "pgp" pgp-sig-scheme-parms pgp-sig-scheme-parms = pgp-version | signed-by | pgp-signature pgp-version, signed-by and pgp-signature are defined in section 15.1.2 of RFC2543, with the modification that the signature is computed across the concatenation of the referrer-url and the referenced-url. Robert Sparks [Page 7] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 5.3 Header Field Support for the REFER Method This table adds a column to tables 4 and 5 in [2], describing header presence in a REFER method. See [2] for a key for the symbols used. A row for the Refer-To: and Referred-By request-header should be inferred, each mandatory for REFER. Refer-To is not applicable for all other methods. Referred-By is a general Request header. The enc and e- e columns in [2] apply to the REFER method unmodified. Header Where REFER 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 - Robert Sparks [Page 8] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 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 5.4 Message Body Inclusion A REFER method may contain a body which SHOULD be processed according to its Content-Type. 5.5 Responses to the REFER Method An agent responding to a REFER Method MUST return a 400 Bad Request if the request contained zero or more than one Refer-To headers. An agent responding to a REFER Method MUST return a 400 Bad Request if the request contained zero or more than one Referred-By 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 recipient's agent decides to contact the resource in the Refer-To header, a 200 OK response MUST be returned if it the contact was successful, otherwise a 503 Service Unavailable MUST be returned. The 503 response MAY contain a Retry-After: header indicating when the REFER may be attempted again. The original proposal called for a 603 response if the REFER was attempted but failed. This left no way for the referrer to tell whether the recipient tried and failed, or just refused to try. A 603 Decline now means the recipient refuses to try. A 503 can mean either "I tried and failed" or "I'm broken and couldn't try". In either case, if a Retry-After header is present, the request can be attempted again. Robert Sparks [Page 9] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 5.6 Behavior of SIP User Agents A UA receiving a well-formed REFER request SHOULD request approval from the user to proceed (this request could be interactive or through configuration). Upon receiving approval from the user, the UA MUST contact the resource identified by the URL in the Refer-To: header. Note that if the URL is a SIP URL, it could contain header fields such as Call-Id that will be used to form the resulting request. If the URL is a SIP URL, the Referred-By header in the REFER request should be copied into the request sent to the referred-to resource. In accordance with [2], the UA SHOULD issue a provisional response to the REFER method if it cannot issue a final response within 200ms of its receipt. The appropriate response to issue to the REFER on receipt of a final response from the referred-to resource is discussed in "Responses to the REFER Method". A REFER request is meaningful only in the context of an existing session. A UA receiving a REFER request for an unknown call leg MUST return a 481 Call Leg/Transaction Does Not Exist and MUST NOT contact the resource identified by that request's Refer-To header as part of the REFER transaction. 5.7 Behavior of SIP Registrars/Redirect Servers Since REFER has meaning only in the context of an existing session, a Registrar or 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 REFER request with a 481 Call Leg/Transaction Does Not Exist. 5.8 Behavior of SIP Proxies SIP Proxies do not require modification to support the REFER method. Specifically, as required by [2], a proxy should process a REFER request the same way it processes an OPTIONS request. Robert Sparks [Page 10] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 5.9 Security Considerations The security requirements of [2] apply to the REFER method. This mechanism relies on providing contact information for the referred-to resource to the party being referred (the transfer-target and transferee in a transfer). Care should be taken to provide a suitably restricted URI if the referred to resource should be protected. Care should be taken when implementing the logic that determines whether or not to accept the REFER request. A UA not capable of accessing non-SIP URLs SHOULD NOT accept REFER requests to them. Unless the UA has good reason (perhaps as part of an as yet undefined application), it SHOULD NOT accept REFERences to SIP URLs for methods other than INVITE. 6 Using REFER to achieve Call Transfer A REFER 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 [2] or the conferencing extensions provided by this framework. 6.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 Robert Sparks [Page 11] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 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. 6.1.1 Successful Unattended Transfer Transferor Transferee Transfer | | Target | INVITE | | |<-------------------| | | 200 OK | | |------------------->| | | ACK | | |<-------------------| | | INVITE (hold) | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | REFER | | |------------------->| | | 100 Trying | | |<-------------------| | | | INVITE | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | 200 OK | | |<-------------------| | | BYE | | |------------------->| | | 200 OK | | |<-------------------| | | | BYE | | |<-------------------| | | 200 OK | | |------------------->| Robert Sparks [Page 12] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 6.1.2 Failed Unattended Transfer Transferor Transferee Transfer | | Target | | | | INVITE | | |<-------------------| | | 200 OK | | |------------------->| | | ACK | | |<-------------------| | | INVITE (hold) | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | REFER | | |------------------->| | | 100 Trying | | |<-------------------| | | | INVITE | | |------------------->| | | 486 Busy Here | | |<-------------------| | | ACK | | |------------------->| | 503 Service Unavailable | |<-------------------| | | INVITE (unhold) | | |------------------->| | | 200 OK | | |<-------------------| | | ACK | | |------------------->| | | BYE | | |------------------->| | | 200 OK | | |<-------------------| | Robert Sparks [Page 13] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 6.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. 6.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-REFER 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 | REFER | | |------------------->| | | 100 Trying | | |<-------------------| | Call-ID:1 | | INVITE/200 OK/ACK | | |------------------->| | 200 OK | | |<-------------------| | Call-ID:1 | BYE/200 OK | | |------------------->| | Call-ID:1 | | BYE/200 OK | | |<-------------------| Robert Sparks [Page 14] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 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 | REFER | | |---------------------------------------->| | 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 | | |------------------->| 6.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. Robert Sparks [Page 15] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 6.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 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 | | | |<-----------| | | |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 |REFER | | | |<-----------| | | |100 Trying | | | |----------->| | | 1 |INVITE/200 OK/ACK | | |----------------------------------->| "Hey Fred" |200 OK | | | "Hello Mary" |----------->| | | Robert Sparks [Page 16] Internet Draft draft-ietf-sip-cc-transfer-00.txt July 2000 1 |BYE/200 OK | | | |<-----------| | | 2 | |BYE/200 OK | | | |---------------------->| 1 |BYE/200 OK | | | |<-----------------------------------| "See you later" 7 Author's Addresses Robert Sparks dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: rsparks@dynamicsoft.com 8 Acknowledgments This draft is a collaborative product of the SIP working group. The author thanks the following for their early contributions to this work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan Johnston, Kevin Summers and Dean Willis. 9 References [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP9, 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-ietf-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). Robert Sparks [Page 17]