Internet Engineering Task Force Biggs/Dean Internet Draft 3Com draft-biggs-sip-replaces-00.txt November 2000 Expires May 2001 The SIP Replaces Header 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 This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This document describes an extension to the Session Initiation Protocol (SIP) [2]. The purpose of this extension is to provide a method for allowing an active call-leg to be replaced by a new incoming call-leg for the purposes of call handoff. 1 Overview This document defines a SIP [2] extension to help provide attended transfer or call handoff capabilities. This header has its roots in [3], however both the syntax and semantics are changed. Call handoff occurs when a SIP user agent which is involved in a 3-way call conference wishes to silently leave the call by requesting the two remote parties to establish a direct signalling relationship. While the transfer functionality provided by REFER [4] allows the conference initiator to connect the two remote parties, there is no standard way for the target of the transfer to associate the incoming call with the active one. The header defined here is intended to provide a simple and backwards compatible method to allow this association to occur. We also define a signature scheme which allows the replacement request to be authenticated by the target user agent. 2 Rationale 1. Using a Replaces header in the request makes the intent obvious. 2. A unique call-id may be given to the replacement call, which helps call leg matching. 3. No adverse effects if the header is unsupported. 3 The Replaces Header The Replaces header is used to indicate that the call leg identified in the header is to be shut down and logically replaced by the incoming INVITE in which it is contained. It is a request header only, and defined here only for INVITEs. The syntax is: Replaces = "Replaces" ":" 1#replaces-values replaces-values = callid *( ";" replaces-param ) callid = token [ "@" token ] replaces-param = to-tag | from-tag | rep-signature | extension-param to-tag = "to-tag=" UUID from-tag = "from-tag=" UUID rep-signature = signature-scheme *( ";" sig-scheme-params ) signature-scheme = "scheme" "=" token sig-scheme-parms = token "=" ( token | quoted-string ) 3.1 Examples Replaces: 98732@sip.billybiggs.com Replaces: 12345@149.112.118.3;to-tag=12345;from-tag=54321 3.2 A PGP based signature-scheme One signature-scheme for Replaces headers uses PGP as follows: signature-scheme = "scheme" "=" "pgp" sig-scheme-parms = pgp-version | signed-by | pgp-signature pgp-version, signed-by and pgp-signature are defined in section 15.1 of RFC2543, with the modification that the signature is computed across the concatenation of the callid, to-tag, and from-tag in that order. 4 Behavior of SIP User Agents The Replaces header contains matching information for a call-leg, identified by the call-id and related tags. Upon receiving an INVITE with a Replaces header, the user agent will attempt to match the information with any active call legs. If no match is found, the Replaces header MUST be ignored. The to tag and from tag should be matched as if they were present in an incoming request, that is, the to tag should match the local tag for the call leg, and the from tag should match the remote tag. If the replaces header matches more than one call-leg, the user agent MAY use the Referred-By header if present to attempt to match the call with an appropriate call-leg, but should otherwise ignore the header. If a matching call-leg is found and the signature checked, the user agent SHOULD silently accept the new call, replacing the old call in the user interface. The user agent SHOULD also shut down the replaced call leg by sending a BYE. 5 Attended Call Transfer to a Supporting Target In these examples, the names of the actors are taken from [4]. In this scenario, the transferor is in a 3-way call with both the transferee and the transfer target and wishes to leave the call. The transferor REFERs the transferee to the transfer target, using the Replaces header to signify to the target that the incoming call should replace its current call to the transferor. The replaces header is placed as a header parameter in the SIP URI used in the Refer-To header. After accepting the call, the target's BYE is received by the transferor before it has a chance to send its own BYE. Transferor Transferee Transfer | | Target | | | Call-ID:1 | INVITE/200 OK/ACK | | |<----------------------->| | | | | Call-ID:2 | INVITE/200 OK/ACK | | |<--------------------------------------------->| | | | | REFER target?Replaces=1 | | |------------------------>| | | 100 Trying | | |<------------------------| | | | INVITE Replaces:1 | | |-------------------->| Immediate | | 200 OK/ACK | Acceptance | |<------------------->| | | BYE/200 OK | |<--------------------------------------------->| | 200 OK (to the REFER) | | |<------------------------| | | BYE/200 OK | | |<----------------------->| | | | | 6 Attended Call Transfer to an Unsupporting Target In this scenario, the transfer target ignores the Replaces header. In this case, the transferor sends a BYE to confirm shutdown of the replaced call. Transferor Transferee Transfer | | Target | | | Call-ID:1 | INVITE/200 OK/ACK | | |<----------------------->| | | | | Call-ID:2 | INVITE/200 OK/ACK | | |<--------------------------------------------->| | | | | REFER target?Replaces=1 | | |------------------------>| | | 100 Trying | | |<------------------------| | | | INVITE Replaces:1 | | |-------------------->| User | | 200 OK/ACK | Accepts | |<------------------->| Call | 200 OK (to the REFER) | | |<------------------------| | | BYE/200 OK | | |<--------------------------------------------->| | BYE/200 OK | | |<----------------------->| | | | | 7 Author's Addresses Billy Biggs 3Com 3800 Golf Rd Rolling Meadows, IL USA Phone: sip:Billy_Biggs@sip.3com.com Email: Billy_Biggs@3com.com Rick Dean 3Com 3800 Golf Rd Rolling Meadows, IL USA Phone: sip:Rick_Dean@sip.3com.com Email: Rick_Dean@3com.com 8 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] 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). [4] R. Sparks, "SIP Call Control: Transfer", Internet Draft draft-ietf-sip-cc-transfer-02.txt, Internet Engineering Task Force, November 2000, Work in Progress. Internet Draft draft-biggs-sip-replaces-00.txt November 2000