Network Working Group R. Mahy
Request for Comments: 3891 Cisco Systems, Inc.
Category: Standards Track B. Biggs
R. Dean
September 2004
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
会话启动协议（SIP）“替换”标头
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please 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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non-normative.
本文档定义了一个新的头，用于会话发起协议（SIP）多方应用程序和呼叫控制。Replaces标头用于在逻辑上将现有SIP对话框替换为新的SIP对话框。此原语可用于启用多种功能，例如：“有人值守转接”和“呼叫接听”。请注意，这些示例特征的定义是非规范性的。
Table of Contents
目录
1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. User Agent Server Behavior: Receiving a Replaces Header . . . 4
4. User 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' Addresses. . . . . . . . . . . . . . . . . . . . . . 15
13. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16
1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. User Agent Server Behavior: Receiving a Replaces Header . . . 4
4. User 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' Addresses. . . . . . . . . . . . . . . . . . . . . . 15
13. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16
This document describes a SIP [1] extension header field as part of the SIP multiparty applications architecture framework [10]. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This is especially useful in peer-to-peer call control environments.
本文档描述了SIP[1]扩展头字段，作为SIP多方应用程序体系结构框架[10]的一部分。Replaces标头用于在逻辑上将现有SIP对话框替换为新的SIP对话框。这在对等呼叫控制环境中特别有用。
One use 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 these same call control primitives in a distributed, peer-to-peer fashion is very desirable.
“替换”标题的一个用途是在多媒体对话中用另一个参与者替换一个参与者。虽然使用第三方呼叫控制[11]样式的呼叫控制已经可以使用此功能，但3pcc模型需要一个中心控制点，这在许多环境中可能并不理想。因此，以分布式对等方式执行这些相同的呼叫控制原语的方法是非常可取的。
Use of a new INVITE with a new header for dialog matching was chosen over making implicit associations in an incoming INVITE based on call-id or other fields for the following reasons:
选择使用带有新标题的新邀请进行对话匹配，而不是基于呼叫id或其他字段在传入邀请中进行隐式关联，原因如下：
o An INVITE already has the correct semantics for a new call
o INVITE已具有新调用的正确语义
o Using an explicit Replaces header in a new request makes the intent of the request obvious.
o 在新请求中使用显式替换头可以使请求的意图显而易见。
o A unique call-id may be given to the replacement call. This avoids dialog matching problems in any of the related User Agents.
o 可以为替换呼叫提供唯一的呼叫id。这避免了任何相关用户代理中的对话框匹配问题。
o There are no adverse effects if the header is unsupported.
o 如果标头不受支持，则不会产生不利影响。
The Replaces header enables services 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 services is not exhaustive. Although the Replaces header is frequently used in combination with the REFER [8] method as used in a Transfer [12], they may be used independently.
Replaces报头以分布式对等方式支持有人值守呼叫转接、从公园检索以及从本地混合会议过渡到双方呼叫等服务。此服务列表并非详尽无遗。尽管Replaces标头经常与传输[12]中使用的refere[8]方法结合使用，但它们可以单独使用。
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 sending 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 Place (using the session 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正在phone1与Bob通话。当她去实验室时，她将Bob转移到一个停车场。当她到达那里时，她通过向Bob发送一个带有替换标题字段的邀请，并使用Bob与停车场共享的对话框信息，从phone2中检索“停驻”呼叫。Alice通过一些带外机制获得了这些信息。也许她从停车场订阅了这些信息（使用会话对话框包[13]），或者去了一个网站并点击了一个URI。下面是本例的简短调用流。（为清晰起见，省略了Via和Max FORWARD标头。）
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------->|
| |<===============>| |
| | | |
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------->|
| |<===============>| |
| | | |
Message *1: Bob-> Parking Place
Message *1: Bob-> Parking Place
INVITE sip:parkingplace@example.org SIP/2.0
To: <sip:parkingplace@example.org>
From: <sip:bob@example.org>;tag=7743
Call-ID: 425928@bobster.example.org
CSeq: 1 INVITE
Contact: <sip:bob@bobster.example.org>
Referred-By: <sip:alice@phone1.example.org>
INVITE sip:parkingplace@example.org SIP/2.0
To: <sip:parkingplace@example.org>
From: <sip:bob@example.org>;tag=7743
Call-ID: 425928@bobster.example.org
CSeq: 1 INVITE
Contact: <sip:bob@bobster.example.org>
Referred-By: <sip:alice@phone1.example.org>
Message *2: Parking Place -> Bob
Message *2: Parking Place -> Bob
SIP/2.0 200 OK
To: <sip:parkingplace@example.org>;tag=6472
From: <sip:bob@example.org>;tag=7743
Call-ID: 425928@bobster.example.org
CSeq: 1 INVITE
Contact: <sip:parkplace@monopoly.example.org>
SIP/2.0 200 OK
To: <sip:parkingplace@example.org>;tag=6472
From: <sip:bob@example.org>;tag=7743
Call-ID: 425928@bobster.example.org
CSeq: 1 INVITE
Contact: <sip:parkplace@monopoly.example.org>
Message *3: Alice@phone2 -> Bob
Message *3: Alice@phone2 -> Bob
INVITE sip:bob@bobster.example.org
To: <sip:bob@example.org>
From: <sip:alice@phone2.example.org>;tag=8983
Call-ID: 09870@phone2.example.org
CSeq: 1 INVITE
Contact: <sip:alice@phone2.example.org>
Require: replaces
Replaces: 425928@bobster.example.org;to-tag=7743;from-tag=6472
INVITE sip:bob@bobster.example.org
To: <sip:bob@example.org>
From: <sip:alice@phone2.example.org>;tag=8983
Call-ID: 09870@phone2.example.org
CSeq: 1 INVITE
Contact: <sip:alice@phone2.example.org>
Require: replaces
Replaces: 425928@bobster.example.org;to-tag=7743;from-tag=6472
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
This document refers frequently to the terms "confirmed dialog" and "early dialog". These are defined in Section 12 of SIP [1].
本文件经常提及术语“确认对话”和“早期对话”。这些在SIP[1]第12节中定义。
The Replaces header contains information used to match an existing SIP dialog (call-id, to-tag, and from-tag). Upon receiving an INVITE with a Replaces header, the User Agent (UA) attempts to match this information with a confirmed or early dialog. The User Agent Server (UAS) matches the to-tag and from-tag parameters as if they were tags
Replaces标头包含用于匹配现有SIP对话框（呼叫id、to标记和from标记）的信息。在收到带有替换标头的邀请后，用户代理（UA）会尝试将此信息与确认的或早期的对话框相匹配。用户代理服务器（UAS）将to标记和from标记参数匹配为标记
present 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.
出现在传入请求中。换句话说，to-tag参数与本地标记进行比较，from-tag参数与远程标记进行比较。
If more than one Replaces header field is present in an INVITE, or if a Replaces header field is present in a request other than INVITE, the UAS MUST reject the request with a 400 Bad Request response.
如果INVITE中存在多个Replaces header字段，或者如果INVITE以外的请求中存在Replaces header字段，UAS必须以400错误请求响应拒绝该请求。
The Replaces header has specific call control semantics. If both a Replaces header field and another header field with contradictory semantics are present in a request, the request MUST be rejected with a 400 "Bad Request" response.
Replaces头具有特定的调用控制语义。如果请求中同时存在替换头字段和另一个语义矛盾的头字段，则必须以400“坏请求”响应拒绝该请求。
If the Replaces header field matches more than one dialog, the UA MUST act as if no match is found.
如果Replaces header字段与多个对话框匹配，UA必须表现为未找到匹配项。
If no match is found, the UAS rejects the INVITE and returns a 481 Call/Transaction Does Not Exist response. Likewise, if the Replaces header field matches a dialog which was not created with an INVITE, the UAS MUST reject the request with a 481 response.
如果未找到匹配项，UAS将拒绝邀请并返回481呼叫/事务不存在响应。类似地，如果Replaces header字段与未使用INVITE创建的对话框匹配，UAS必须使用481响应拒绝该请求。
If the Replaces header field matches a dialog which has already terminated, the UA SHOULD decline the request with a 603 Declined response. (If the matched invitation was just terminated, the replacement request should fail as well. Declining the request with a 600-class response prevents an irritating race-condition where the UA rings or alerts for a replacement call which is not wanted.)
如果Replaces header字段与已终止的对话框匹配，UA应使用603拒绝响应拒绝请求。（如果匹配的邀请刚刚终止，则替换请求也应失败。以600级响应拒绝请求可防止出现令人不快的竞态情况，即UA拨打或提醒不需要的替换呼叫。）
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 user who is being replaced, then the replacement is authorized. For example, if the user 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 present the (same) corresponding certificate used in the original dialog, then the replacement is authorized.
如果Replaces header字段与活动对话框匹配，UA必须验证新邀请的发起人是否有权替换匹配的对话框。如果新邀请的发起人已成功验证为与被替换的用户等效，则该替换被授权。例如，如果被替换的用户和替换对话框的发起人共享相同的摘要身份验证凭据[6]，或者他们使用相同的私钥使用S/MIME[7]签署替换请求，并提供原始对话框中使用的（相同）相应证书，则替换被授权。
Alternatively, the Referred-By mechanism [4] defines a mechanism that the UAS can use to verify that a replacement request was sent on behalf of the other participant in the matched dialog (in this case, triggered by a REFER request). If the replacement request contains a Referred-By header that corresponds to the user 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].
或者，refered By机制[4]定义了一种机制，UAS可以使用该机制来验证替换请求是否代表匹配对话框中的其他参与者发送（在这种情况下，由refered请求触发）。如果替换请求包含与被替换用户相对应的Referenced By标头，UA应将替换视为被替换方授权的替换。Referred By标头应引用经过身份验证的标识体[5]所引用的相应有效Referred。
The UA MAY apply other local policy to authorize the remainder of the request. In other words, the UAS may apply a different policy to the replacement dialog than was applied to the replaced dialog.
UA可以应用其他本地策略来授权请求的其余部分。换句话说，UAS可能对替换对话框应用与被替换对话框不同的策略。
In addition, the UA MAY use other authorization mechanisms defined for this purpose in standards track extensions. Extensions could define other mechanisms for transitively asserting authorization of a replacement.
此外，UA可以使用标准跟踪扩展中为此目的定义的其他授权机制。扩展可以定义其他机制，以传递方式断言替换的授权。
If authorization is successful, the UA attempts to accept the new INVITE, reassign the user interface and other resources of the matched dialog to the new INVITE, and shut down the replaced dialog. If the UA cannot accept the new INVITE (for example: it cannot establish required QoS or keying, or it has incompatible media), the UA MUST return an appropriate error response and MUST leave the matched dialog unchanged.
如果授权成功，UA将尝试接受新邀请，将匹配对话框的用户界面和其他资源重新分配给新邀请，并关闭替换的对话框。如果UA不能接受新的邀请（例如：它不能建立所需的QoS或密钥，或者它有不兼容的媒体），UA必须返回适当的错误响应，并且必须保持匹配的对话框不变。
If the Replaces header field matches a confirmed dialog, it checks for the presence of the "early-only" flag in the Replaces header field. (This flag allows the UAC to prevent a potentially undesirable race condition described in Section 7.1.) If the flag is present, the UA rejects the request with a 486 Busy response. Otherwise, it accepts the new INVITE by sending a 200-class response, and shuts down the replaced dialog by sending a BYE. If the Replaces header field matches an early dialog that was initiated by the UA, it accepts the new INVITE by sending a 200-class response, and shuts down the replaced dialog by sending a CANCEL.
如果Replaces header字段与确认的对话框匹配，它将检查Replaces header字段中是否存在“仅早期”标志。（该标志允许UAC防止第7.1节中描述的潜在不希望出现的竞争情况。）如果该标志存在，UA将以486忙响应拒绝请求。否则，它通过发送200类响应来接受新的INVITE，并通过发送BYE来关闭替换的对话框。如果Replaces header字段与UA启动的早期对话框相匹配，它将通过发送200类响应来接受新的邀请，并通过发送取消来关闭被替换的对话框。
If the Replaces header field matches an early dialog that was not initiated by this UA, it returns a 481 (Call/Transaction Does Not Exist) response to the new INVITE, and leaves the matched dialog unchanged. Note that since Replaces matches only a single dialog, the replacement dialog will not be retargeted according to the same forking logic as the original request which created the early dialog.
如果Replaces header字段与此UA未启动的早期对话框匹配，则它将返回对新邀请的481（调用/事务不存在）响应，并保持匹配的对话框不变。请注意，由于Replaces只匹配一个对话框，因此不会根据与创建早期对话框的原始请求相同的分叉逻辑来重定替换对话框的目标。
(Currently, no use cases have been identified for replacing just a single dialog in this circumstance.)
（目前，还没有确定在这种情况下仅替换单个对话框的用例。）
A User Agent that wishes to replace a single existing early or confirmed dialog with a new dialog of its own, MAY send the target User Agent an INVITE request containing a Replaces header field. The User Agent Client (UAC) places the Call-ID, to-tag, and from-tag information for the target dialog in a single Replaces header field and sends the new INVITE to the target. If the user agent only wishes to replace an early dialog (as in the Call Pickup example in Section 7.1), the UAC MAY also include the "early-only" parameter in
希望用自己的新对话框替换单个现有的早期或已确认对话框的用户代理可以向目标用户代理发送包含Replaces标头字段的INVITE请求。用户代理客户端（UAC）将目标对话框的Call ID、to tag和from tag信息放置在单个Replaces标头字段中，并向目标发送新的邀请。如果用户代理仅希望替换早期对话框（如第7.1节中的呼叫接听示例），UAC还可以在中包含“仅早期”参数
the Replaces header field. A UAC MUST NOT send an INVITE with a Replaces header field that attempts to replace an early dialog which was not originated by the target of the INVITE with a Replaces header field.
替换标题字段。UAC不得发送带有Replaces标头字段的邀请，该字段试图用Replaces标头字段替换不是由邀请目标发起的早期对话框。
Note that use of this mechanism does not provide a way to match multiple dialogs, nor does it provide a way to match an entire call, an entire transaction, or to follow a chain of proxy forking logic. For example, if Alice replaces Cathy in an early dialog with Bob, but Bob does not answer, Alice's replacement request will not match other dialogs to which Bob's UA redirects, nor other branches to which his proxy forwards. Although this specification takes reasonable precautions to prevent unexpected behavior in the face of forking, implementations SHOULD only address replacement requests (i.e., set the Request-URI of the replacement request) to the SIP Contact URI of the target.
请注意，使用此机制不会提供匹配多个对话框的方法，也不会提供匹配整个调用、整个事务或遵循代理分叉逻辑链的方法。例如，如果Alice在早期对话中用Bob替换Cathy，但Bob没有回答，Alice的替换请求将与Bob的UA重定向到的其他对话或其代理转发到的其他分支不匹配。尽管本规范采取了合理的预防措施，以防止在面临分叉时出现意外行为，但实现应仅将替换请求（即，设置替换请求的请求URI）处理为目标的SIP联系人URI。
Proxy Servers do not require any new behavior to support this extension. They simply pass the Replaces header field transparently as described in the SIP specification.
代理服务器不需要任何新的行为来支持此扩展。它们只是像SIP规范中描述的那样透明地传递Replaces报头字段。
Note that it is possible for a proxy (especially when forking based on some application layer logic, such as caller screening or time-of-day routing) to forward an INVITE request containing a Replaces header field to a completely orthogonal set of Contacts other than the original request it was intended to replace. In this case, the INVITE request with the Replaces header field will fail.
请注意，代理（特别是在基于某些应用层逻辑进行分叉时，如呼叫方筛选或时间路由）可以将包含Replaces标头字段的INVITE请求转发给一组完全正交的联系人，而不是它要替换的原始请求。在这种情况下，带有Replaces标头字段的INVITE请求将失败。
The Replaces header field indicates that a single dialog identified by the header field 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 only for INVITE requests. The Replaces header field MAY be encrypted as part of end-to-end encryption. Only a single Replaces header field value may be present in a SIP request.
Replaces header字段表示由header字段标识的单个对话框将被关闭，并在逻辑上被包含该对话框的传入INVITE替换。它只是一个请求头，仅为INVITE请求定义。替换标头字段可以作为端到端加密的一部分进行加密。SIP请求中只能存在一个替换头字段值。
This document adds the following entry to Table 2 of [1]. Additions to this table are also provided for extension methods defined at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way. MESSAGE, SUBSCRIBE and NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined respectively in [15], [16], [8], [17], [18], [19], and [20].
本文件将以下条目添加到[1]的表2中。本表还提供了本文件发布时定义的扩展方法的补充内容。这是出于对读者的礼貌，在任何方面都不规范。[15]、[16]、[8]、[17]、[18]、[19]和[20]分别定义了消息、订阅和通知、参考、信息、更新、PRACK和发布。
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
Replaces R - - - o - - -
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
Replaces R - - - o - - -
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
Replaces R - - - - - - -
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
Replaces R - - - - - - -
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 [3]. The syntax below relies on a number of productions from SIP [1].
以下语法规范使用RFC 2234[3]中所述的增广巴科斯诺尔形式（BNF）。下面的语法依赖于SIP[1]中的许多产品。
Replaces = "Replaces" HCOLON callid *(SEMI replaces-param)
replaces-param = to-tag / from-tag / early-flag / generic-param
to-tag = "to-tag" EQUAL token
from-tag = "from-tag" EQUAL token
early-flag = "early-only"
Replaces = "Replaces" HCOLON callid *(SEMI replaces-param)
replaces-param = to-tag / from-tag / early-flag / generic-param
to-tag = "to-tag" EQUAL token
from-tag = "from-tag" EQUAL token
early-flag = "early-only"
A Replaces header field MUST contain exactly one to-tag and exactly one from-tag, as they are required for unique dialog matching. For compatibility with dialogs initiated by RFC 2543 [9] compliant UAs, a tag of zero matches both tags of zero and null. A Replaces header field MAY contain the early-flag.
替换标头字段必须包含一个to标记和一个from标记，因为它们是唯一对话框匹配所必需的。为了与RFC 2543[9]兼容UAs启动的对话框兼容，零标记与零和空标记匹配。替换标头字段可能包含早期标志。
Examples:
示例：
Replaces: 98732@sip.example.com
;from-tag=r33th4x0r
;to-tag=ff87ff
Replaces: 98732@sip.example.com
;from-tag=r33th4x0r
;to-tag=ff87ff
Replaces: 12adf2f34456gs5;to-tag=12345;from-tag=54321;early-only
Replaces: 12adf2f34456gs5;to-tag=12345;from-tag=54321;early-only
Replaces: 87134@171.161.34.23;to-tag=24796;from-tag=0
Replaces: 87134@171.161.34.23;to-tag=24796;from-tag=0
This specification defines a new Require/Supported header option tag "replaces". UAs which support the Replaces header MUST include the "replaces" option tag in a Supported header field. UAs that want explicit failure notification if Replaces is not supported MAY include the "replaces" option in a Require header field.
本规范定义了一个新的Require/Supported标题选项标记“replaces”。支持Replaces标头的UAs必须在支持的标头字段中包含“Replaces”选项标记。如果不支持替换，则需要显式故障通知的UAs可能会在Require标头字段中包含“Replaces”选项。
Example:
例子：
Require: replaces, 100rel
要求：替换，100rel
The following non-normative examples are not intended to enumerate all the possibilities for the usage of this extension, but rather to provide examples or ideas only. For more examples, please see SIP Service Examples [14]. Via and Max-Forwards headers are omitted for clarity and brevity.
以下非规范性示例并非旨在列举使用此扩展的所有可能性，而是仅提供示例或想法。有关更多示例，请参阅SIP服务示例[14]。为了清晰和简洁，省略了Via和Max FORWARD标头。
In this example, Bob just arrived in the lab and hasn't registered there yet. He hears his desk phone ring. He quickly logs into a software UA on a nearby computer. Among other things, the software UA has access to the dialog state of his desk phone. When it notices that his phone is ringing, it offers him the choice of taking the call there. The software UA sends an INVITE with Replaces to Alice. When Alice's UA receives this new INVITE, it CANCELs her original INVITE and connects Alice to Bob.
在这个例子中，Bob刚到实验室，还没有在那里注册。他听到桌上的电话铃响了。他迅速登录到附近电脑上的软件UA。除此之外，软件UA可以访问其桌面电话的对话状态。当它注意到他的电话正在响时，它会让他选择在那里接电话。软件UA向Alice发送带有替换项的邀请。当Alice的UA收到这个新邀请时，它会取消她的原始邀请并将Alice连接到Bob。
Bob Bob
Alice desk lab
| | |
*1 |-----INVITE----------->| |
*2 |<----180---------------| Bob hears desk phone |
| | ringing from lab but |
| | isn't REGISTERed yet |
| | |
| |<--fetch dialog state --|
| |---response ----------->|
*3/4 |<-----INVITE with Replaces/200/ACK--------------|
*5/6 |------CANCEL/200------>| |
*7 |<-----487--------------| |
|------ACK------------->| |
| | |
| | |
Bob Bob
Alice desk lab
| | |
*1 |-----INVITE----------->| |
*2 |<----180---------------| Bob hears desk phone |
| | ringing from lab but |
| | isn't REGISTERed yet |
| | |
| |<--fetch dialog state --|
| |---response ----------->|
*3/4 |<-----INVITE with Replaces/200/ACK--------------|
*5/6 |------CANCEL/200------>| |
*7 |<-----487--------------| |
|------ACK------------->| |
| | |
| | |
Message *1: Alice -> Bob's desk phone
Message *1: Alice -> Bob's desk phone
INVITE sip:bob@example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 INVITE
Contact: <sip:alice@phone.example.org>
INVITE sip:bob@example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 INVITE
Contact: <sip:alice@phone.example.org>
Message *2: Bob's desk phone -> Alice
Message *2: Bob's desk phone -> Alice
SIP/2.0 180 Ringing
To: <sip:bob@example.org>;tag=6472
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 INVITE
Contact: <sip:bob@bobster.example.org>
SIP/2.0 180 Ringing
To: <sip:bob@example.org>;tag=6472
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 INVITE
Contact: <sip:bob@bobster.example.org>
Message *3: Bob in lab -> Alice
Message *3: Bob in lab -> Alice
INVITE sip:alice@phone.example.org
To: <sip:alice@example.org>
From: <sip:bob@example.org>;tag=8983
Call-ID: 09870@labpc.example.org
CSeq: 1 INVITE
Contact: <sip:bob@labpc.example.org>
Replaces: 425928@phone.example.org
;to-tag=7743;from-tag=6472;early-only
INVITE sip:alice@phone.example.org
To: <sip:alice@example.org>
From: <sip:bob@example.org>;tag=8983
Call-ID: 09870@labpc.example.org
CSeq: 1 INVITE
Contact: <sip:bob@labpc.example.org>
Replaces: 425928@phone.example.org
;to-tag=7743;from-tag=6472;early-only
Message *4: Alice -> Bob in lab
Message *4: Alice -> Bob in lab
SIP/2.0 200 OK
To: <sip:alice@example.org>;tag=9232
From: <sip:bob@example.org>;tag=8983
Call-ID: 09870@labpc.example.org
CSeq: 1 INVITE
Contact: <sip:alice@phone.example.org>
SIP/2.0 200 OK
To: <sip:alice@example.org>;tag=9232
From: <sip:bob@example.org>;tag=8983
Call-ID: 09870@labpc.example.org
CSeq: 1 INVITE
Contact: <sip:alice@phone.example.org>
Message *5: Alice -> Bob's desk
Message *5: Alice -> Bob's desk
CANCEL sip:bob@example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 CANCEL
Contact: <sip:alice@phone.example.org>
CANCEL sip:bob@example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 CANCEL
Contact: <sip:alice@phone.example.org>
Message *6: Bob's desk -> Alice
Message *6: Bob's desk -> Alice
SIP/2.0 200 OK
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 CANCEL
Contact: <sip:bob@bobster.example.org>
SIP/2.0 200 OK
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 CANCEL
Contact: <sip:bob@bobster.example.org>
Message *7: Bob's desk -> Alice
Message *7: Bob's desk -> Alice
SIP/2.0 487 Request Terminated
To: <sip:bob@example.org>;tag=6472
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 INVITE
SIP/2.0 487 Request Terminated
To: <sip:bob@example.org>;tag=6472
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 INVITE
The extension specified in this document significantly changes the relative security of SIP devices. Currently in SIP, even if an eavesdropper learns the Call-ID, To, and From headers of a dialog, they cannot easily modify or destroy that dialog if Digest authentication or end-to-end message integrity are used.
本文档中指定的扩展显著改变了SIP设备的相对安全性。目前在SIP中，即使窃听者从对话的标题中了解到呼叫ID、到和，如果使用摘要身份验证或端到端消息完整性，他们也无法轻松修改或破坏该对话。
This extension can be used to disconnect participants or replace participants in a multimedia conversation. As such, invitations with the Replaces header MUST only be accepted if the peer requesting replacement has been properly authenticated using a standard SIP mechanism (Digest or S/MIME), and authorized to request a replacement of the target dialog. All SIP implementations are already required to support Digest Authentication. In addition, implementations which support the Replaces header SHOULD also implement the Referred-By mechanism.
此扩展可用于断开多媒体会话中的参与者连接或替换参与者。因此，只有当请求替换的对等方已使用标准SIP机制（摘要或S/MIME）进行了正确的身份验证，并且有权请求替换目标对话框时，才必须接受带有Replaces标头的邀请。已经需要所有SIP实现来支持摘要身份验证。此外，支持Replaces报头的实现还应该实现referenceby机制。
How a User Agent determines which requests are legitimately authorized to make dialog replacements is non-trivial and depends on a considerable amount of local policy configuration. In general, there are four cases when an authorization for a replacement is reasonable or warranted.
用户代理如何确定哪些请求被合法授权进行对话框替换是非常重要的，并且取决于大量的本地策略配置。一般来说，有四种情况下，更换授权是合理的或有保证的。
1. Replacement made by a party considered equivalent to the replaced party
1. 由被替换方视为等同于被替换方的一方进行的替换
2. Replacement made on behalf of the replaced party (perhaps transitively)
2. 代表被替换方进行的替换（可能是过渡的）
3. Replacement made by a former participant
3. 由前参与者进行的替换
4. Replacement made by a specifically authorized party
4. 由特别授权方进行的替换
Starting with #1 for example, if an executive and an assistant both receive requests for a shared address-of-record, if so configured, either should be able to replace dialogs of the other for the shared identity. Both could even share the same keying material (Digest or S/MIME), or one could hold an authorization document signed by the
例如，从#1开始，如果一名主管和一名助理都收到了共享记录地址的请求，如果这样配置，则任何一方都应该能够替换另一方的共享标识对话框。两者甚至可以共享相同的密钥材料（摘要或S/MIME），也可以持有由
other expressing this relationship. Likewise, in a call center environment, each call center agent could possess credentials to which supervisors also have access.
其他人表达了这种关系。同样，在呼叫中心环境中，每个呼叫中心代理都可以拥有主管也可以访问的凭据。
The most common use case of a replacement is on the request of the replaced participant (who no longer wants to be involved). This is the case in many features, such as completing an Attended Transfer and converting a 3-way call to a point-to-point call. Such replacements are typically triggered by a REFER [8] request from the replaced participant. The Referred-By [4] mechanism defines one way to identify the apparent original requester and can point to a SIP Authenticated Identity Body [5] (an S/MIME-based signed assertion) to secure this information.
替换最常见的用例是根据被替换参与者（不再希望参与）的请求进行的。在许多功能中都是如此，例如完成有人值守转接和将三路呼叫转换为点对点呼叫。此类替换通常由被替换参与者的“参考[8]请求”触发。[4]所指的机制定义了一种识别明显原始请求者的方法，并可以指向SIP身份验证主体[5]（基于S/MIME的签名断言）以保护该信息。
In the example in section 1, Alice sends an INVITE with Replaces to Bob. Alice was a former participant in the conversation and had a previous dialog relationship with Bob. Alice can use the same Digest or S/MIME credentials she used to authenticate with Bob during the original call to prove that she was a former participant. Note that this justification for replacing calls is more dangerous than the others, and in most cases is another way to authorize that the replacing participant is available. Implementations SHOULD NOT rely on this method as an authorization mechanism.
在第1节的示例中，Alice向Bob发送了一个带有替换项的邀请。Alice曾是对话的参与者，并与Bob有过对话关系。Alice可以使用她在最初通话中与Bob进行身份验证时使用的相同摘要或S/MIME凭据来证明她是以前的参与者。请注意，这种替换呼叫的理由比其他理由更危险，并且在大多数情况下是授权替换参与者可用的另一种方式。实现不应依赖此方法作为授权机制。
The last scenario is the easiest to secure but the least likely to be useful in practice. It is unlikely that an arbitrary host in the Internet is aware of any special authorization relationship between the replaced and the replacing parties. However, this use case may be useful in some environments. Since this usage does not effectively degrade the security of the solution, it is still allowed.
最后一个场景最容易保护，但在实践中最不可能有用。互联网上的任意主机不太可能知道被替换方和替换方之间的任何特殊授权关系。但是，此用例在某些环境中可能很有用。由于这种用法不会有效地降低解决方案的安全性，因此仍然允许这样做。
Some mechanisms for obtaining the dialog information needed by the Replaces header (Call-ID, to-tag, and from-tag) include URIs on a web page, subscriptions to an appropriate event package, and notifications after a REFER request. Since manipulating this dialog information could cause User Agents to replace the wrong dialog, use of message integrity protection for this information is STRONGLY RECOMMENDED. Use of end-to-end security mechanisms to encrypt this information is also RECOMMENDED.
用于获取Replaces标头所需的对话框信息（调用ID、to标记和from标记）的一些机制包括网页上的URI、对适当事件包的订阅以及REFER请求后的通知。由于操纵此对话框信息可能会导致用户代理替换错误的对话框，因此强烈建议对此信息使用消息完整性保护。还建议使用端到端安全机制加密此信息。
This extension was designed to take advantage of future signature or authorization schemes defined in standards track extensions. In general, call control features benefit considerably from such work.
此扩展旨在利用标准跟踪扩展中定义的未来签名或授权方案。一般来说，呼叫控制功能从这类工作中受益匪浅。
Name of Header: Replaces
标题名称：替换
Short form: none
简表：无
Normative description: section 6.1 of this document
规范性说明：本文件第6.1节
Name of option: replaces
选项名称：替换
Description: Support for the SIP Replaces header
描述：对SIP头的支持
SIP headers defined: Replaces
定义的SIP头：替换
Normative description: This document
规范性说明：本文件
Thanks to Robert Sparks, Alan Johnston, Dan Petrie, Ben Campbell, and many other members of the SIP WG for their continued support of the cause of distributed call control in SIP.
感谢Robert Sparks、Alan Johnston、Dan Petrie、Ben Campbell和SIP工作组的许多其他成员对SIP中分布式呼叫控制事业的持续支持。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[4] Sparks，R.，“机制引用的会话启动协议（SIP）”，RFC 38922004年9月。
[5] Peterson, J., "The Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[5] Peterson，J.，“会话发起协议（SIP）认证身份主体（AIB）格式”，RFC 3893，2004年9月。
[6] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[6] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[7] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[8] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[8] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[9] Handley，M.，Schulzrinne，H.，Schooler，E.，和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[10] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[10] Mahy，R.，“会话启动协议（SIP）的呼叫控制和多方使用框架”，正在进行的工作，2003年3月。
[11] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[11] Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 37252004年4月。
[12] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", Work in Progress, February 2003.
[12] Sparks，R.和A.Johnston，“会话启动协议呼叫控制-传输”，正在进行的工作，2003年2月。
[13] Rosenberg, J. and H. Schulzrinne, "An INVITE Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[13] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）的邀请启动对话事件包”，正在进行的工作，2003年3月。
[14] Johnston, A. and S. Donovan, "Session Initiation Protocol Service Examples", Work in Progress, March 2003.
[14] Johnston，A.和S.Donovan，“会话启动协议服务示例”，正在进行的工作，2003年3月。
[15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[15] Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[16] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[16] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[17] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[18] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[19] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[19] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[20] Campbell, B., "SIMPLE Presence Publication Mechanism", Work in Progress, February 2003.
[20] 坎贝尔，B.，“简单存在-发布机制”，正在进行的工作，2003年2月。
Rohan Mahy Cisco Systems, Inc. 5617 Scotts Valley Dr Scotts Valley, CA 95066 USA
Rohan Mahy Cisco Systems，Inc.美国加利福尼亚州斯科茨谷博士5617斯科茨谷95066
EMail: rohan@cisco.com
EMail: rohan@cisco.com
Billy Biggs
工程师毕格兹
EMail: bbiggs@dumbterm.net
EMail: bbiggs@dumbterm.net
Rick Dean
瑞克·迪恩
EMail: rfc@fdd.com
EMail: rfc@fdd.com
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。