[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00 01
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
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/