Network Working Group R. Mahy Request for Comments: 3891 Cisco Systems, Inc. Category: Standards Track B. Biggs R. Dean September 2004 The Session Initiation Protocol (SIP) "Replaces" Header
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for
improvements. Plea refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document defines a new header for u with Session Initiation
Protocol (SIP) multi-party applications and call control. The
Replaces header is ud to logically replace an existing SIP dialog
with a new SIP dialog. This primitive can be ud to enable a
variety of features, for example: "Attended Transfer" and "Call
Pickup". Note that the definition of the example features is non- normative.
Mahy, et al. Standards Track [Page 1]
Table of Contents
1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Ur Agent Server Behavior: Receiving a Replaces Header . . . 4
4. Ur Agent Client Behavior: Sending a Replaces Header . . . . 6
5. Proxy Behavior. . . . . . . . . . . . . . . . . . . . . . . . 7
6. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. The Replaces Header . . . . . . . . . . . . . . . . . . 7
6.2. New Option Tag for Require and Supported Headers. . . . 8
7. Usage Examples. . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Replacing an Early Dialog at the Originator . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. Registration of "Replaces" SIP Header . . . . . . . . . 13
幼儿园育儿心得9.2. Registration of "replaces" SIP Option-tag . . . . . . . 13射的成语
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References. . . . . . . . . . . . . . . . . . 13
11.2. Informative References. . . . . . . . . . . . . . . . . 14
12. Authors’ Address. . . . . . . . . . . . . . . . . . . . . . 15
13. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16 1. Overview
This document describes a SIP [1] extension header field as part of
the SIP multiparty applications architecture framework [10]. The
Replaces header is ud to logically replace an existing SIP dialog
with a new SIP dialog. This is especially uful in peer-to-peer
call control environments.
One u of the "Replaces" header is to replace one participant with
another in a multimedia conversation. While this functionality is
already available using 3rd party call control [11] style call
control, the 3pcc model requires a central point of control which may not be desirable in many environments. As such, a method of
performing the same call control primitives in a distributed,
peer-to-peer fashion is very desirable.
U of a new INVITE with a new header for dialog matching was chon over making implicit associations in an incoming INVITE bad on
call-id or other fields for the following reasons:
o An INVITE already has the correct mantics for a new call
o Using an explicit Replaces header in a new request makes the
intent of the request obvious.
Mahy, et al. Standards Track [Page 2]
o A unique call-id may be given to the replacement call. This
avoids dialog matching problems in any of the related Ur Agents. o There are no adver effects if the header is unsupported.
The Replaces header enables rvices such as attended call transfer, retrieve from park, and transition from locally mixed conferences to two party calls in a distributed peer-to-peer way. This list of
rvices is not exhaustive. Although the Replaces header is
frequently ud in combination with the REFER [8] method as ud in a Transfer [12], they may be ud independently.
十大央企For example, Alice is talking to Bob from phone1. She transfers Bob to a Parking Place while she goes to the lab. When she gets there
she retrieves the "parked" call from phone2 by nding an INVITE with a Replaces header field to Bob with the dialog information Bob shared with the Parking Place. Alice got this information using some out of band mechanism. Perhaps she subscribed to this information from the Parking Plac
e (using the ssion dialog package [13]), or went to a
website and clicked on a URI. A short call flow for this example欧贝诗
follows. (Via and Max-Forwards headers are omitted for clarity.)
Alice Alice Parking
phone1 phone2 Bob Place
| | | |苏步青故居
|<===============================>| |
| | | |
| Alice transfers Bob to Parking Place |
| | | |
|------------REFER/200----------->| *1 *2 |
|<--NOTIFY/200 (trying)-----------|--INVITE/200/ACK-->|
|<--NOTIFY/200 (success)----------|<=================>|
|------------BYE/200------------->| |
| | | |
| | | |
| Alice later retrieves call from another phone |
| | | |
| *3 |-INV w/Replaces->| |
| |<--200-----------| |
| |---ACK---------->|----BYE/200------->|
| |<===============>| |
| | | |
Mahy, et al. Standards Track [Page 3]
Message *1: Bob-> Parking Place
INVITE sip:parkingplace@example SIP/2.0
To: <sip:parkingplace@example>
From: <sip:bob@example>;tag=7743
Call-ID: ample
CSeq: 1 INVITE
Contact: <sip:ample>
Referred-By: <sip:ample>
Message *2: Parking Place -> Bob
SIP/2.0 200 OK
To: <sip:parkingplace@example>;tag=6472
From: <sip:bob@example>;tag=7743
Call-ID: ample
CSeq: 1 INVITE
Contact: <sip:ample>
Message *3: Alice@phone2 -> Bob
INVITE sip:ample
To: <sip:bob@example>
From: <sip:ample>;tag=8983
Call-ID: ample
CSeq: 1 INVITE
Contact: <sip:ample>
婴儿多大可以坐飞机
Require: replaces
Replaces: ample;to-tag=7743;from-tag=6472
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2]. This document refers frequently to the terms "confirmed dialog" and
"early dialog". The are defined in Section 12 of SIP [1].
3. Ur Agent Server Behavior: Receiving a Replaces Header
The Replaces header contains information ud to match an existing
SIP dialog (call-id, to-tag, and from-tag). Upon receiving an INVITE with a Replaces header, the Ur Agent (UA) attempts to match this
information with a confirmed or early dialog. The Ur Agent Server (UAS) matches the to-tag and from-tag parameters as if they were tags Mahy, et al. Standards Track [Page 4]
prent in an incoming request. In other words, the to-tag parameter is compared to the local tag, and the from-tag parameter is compared to the remote tag.
If more than one Replaces header field is prent in an INVITE, or if a Replaces header field is prent in a request other than INVITE,
the UAS MUST reject the request with a 400 Bad Request respon.
The Replaces header has specific call control mantics. If both a
Replaces header field and another header field with contradictory
mantics are prent in a request, the request MUST be rejected with a 400 "Bad Request" respon.
If the Replaces header field matches more than one dialog, the UA
MUST act as if no match is found.
If no match is found, the UAS rejects the INVITE and returns a 481
Call/Transaction Does Not Exist respon. Likewi, if the Replaces header field matches a dialog which was not created with an INVITE,
the UAS MUST reject the request with a 481 respon.
If the Replaces header field matches a dialog which has already
关于梦想的诗terminated, the UA SHOULD decline the request with a 603 Declined
respon. (If the matched invitation was just terminated, the
replacement request should fail as well. Declining the request with a 600-class respon prevents an irritating race-condition where the UA rings or alerts for a replacement call which is not wanted.)
If the Replaces header field matches an active dialog, the UA MUST
verify that the initiator of the new INVITE is authorized to replace the matched dialog. If the initiator of the new INVITE has been
successfully authenticated as equivalent to the ur who is being
replaced, then the replacement is authorized. For example, if the
ur being replaced and the initiator of the replacement dialog share the same credentials for Digest authentication [6], or they sign the replacement request with S/MIME [7] with the same private key and
prent the (same) corresponding certificate ud in the original
dialog, then the replacement is authorized.
Alternatively, the Referred-By mechanism [4] defines a mechanism that the UAS can u to verify that a replacement request was nt on
behalf of the other participant in the matched dialog (in this ca, triggered by a REFER request). If the replacement request contains a Referred-By header that corresponds to the ur being replaced, the
UA SHOULD treat the replacement as if the replacement was authorized by the replaced party. The Referred-By header SHOULD reference a
海带排骨汤的功效corresponding, valid Refererred-By Authenticated Identity Body [5]. Mahy, et al. Standards Track [Page 5]
