Network Working Group J. Elwell
Request for Comments: 4916 Siemens Enterprise Communications Limited
Updates: 3261 June 2007
Category: Standards Track
Network Working Group J. Elwell
Request for Comments: 4916 Siemens Enterprise Communications Limited
Updates: 3261 June 2007
Category: Standards Track
Connected Identity in the Session Initiation Protocol (SIP)
会话启动协议（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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP).
本文档提供了一种用于会话发起协议（SIP）用户代理（UA）的方法，该用户代理（UA）接收对话形成请求以通过反向请求向对等UA提供其身份，并且该身份将由认证服务签名。由于对形成对话框的请求进行重定目标（更改请求URI的值），因此接收该请求的UA（用户代理服务器，UAS）可以具有与To标头字段中不同的标识。相同的机制可用于指示对话期间身份的改变，例如，由于网关后面的公共交换电话网（PSTN）中的某些动作。本文件规范性地更新了RFC 3261（SIP）。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Solution . . . . . . . . . . . . . . . . . . . . . 4
4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Behaviour of a UA that Issues an INVITE Request
Outside the Context of an Existing Dialog . . . . . . . . 6
4.2. Behaviour of a UA that Receives an INVITE Request
outside the Context of an Existing Dialog . . . . . . . . 6
4.3. Behaviour of a UA Whose Identity Changes during an
Established INVITE-initiated Dialog . . . . . . . . . . . 7
4.4. General UA Behaviour . . . . . . . . . . . . . . . . . . . 7
4.4.1. Sending a Mid-Dialog Request . . . . . . . . . . . . . 7
4.4.2. Receiving a Mid-Dialog Request . . . . . . . . . . . . 8
4.5. Authentication Service Behaviour . . . . . . . . . . . . . 8
4.6. Verifier Behaviour . . . . . . . . . . . . . . . . . . . . 9
4.7. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Sending Connected Identity after Answering a Call . . . . 10
5.2. Sending Revised Connected Identity during a Call . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Security considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Solution . . . . . . . . . . . . . . . . . . . . . 4
4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Behaviour of a UA that Issues an INVITE Request
Outside the Context of an Existing Dialog . . . . . . . . 6
4.2. Behaviour of a UA that Receives an INVITE Request
outside the Context of an Existing Dialog . . . . . . . . 6
4.3. Behaviour of a UA Whose Identity Changes during an
Established INVITE-initiated Dialog . . . . . . . . . . . 7
4.4. General UA Behaviour . . . . . . . . . . . . . . . . . . . 7
4.4.1. Sending a Mid-Dialog Request . . . . . . . . . . . . . 7
4.4.2. Receiving a Mid-Dialog Request . . . . . . . . . . . . 8
4.5. Authentication Service Behaviour . . . . . . . . . . . . . 8
4.6. Verifier Behaviour . . . . . . . . . . . . . . . . . . . . 9
4.7. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Sending Connected Identity after Answering a Call . . . . 10
5.2. Sending Revised Connected Identity during a Call . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Security considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
The Session Initiation Protocol (SIP) (RFC 3261 [1]) initiates sessions but also provides information on the identities of the parties at both ends of a session. Users need this information to help determine how to deal with communications initiated by a SIP. The identity of the party who answers a call can differ from that of the initial called party for various reasons such as call forwarding, call distribution and call pick-up. Furthermore, once a call has been answered, a party can be replaced by a different party with a different identity for reasons such as call transfer, call park and retrieval, etc. Although in some cases there can be reasons for not disclosing these identities, it is desirable to have a mechanism for providing this information.
会话启动协议（SIP）（RFC 3261[1]）启动会话，但也提供会话两端各方身份的信息。用户需要这些信息来帮助确定如何处理SIP发起的通信。由于呼叫转接、呼叫分配和呼叫接听等多种原因，接听呼叫的一方的身份可能不同于初始被叫方的身份。此外，一旦呼叫被应答，由于呼叫转移、呼叫停止和检索等原因，一方可以被具有不同身份的另一方替换。尽管在某些情况下可能有不披露这些身份的原因，但希望有一种提供此信息的机制。
This document extends the use of the From header field to allow it to convey what is commonly called "connected identity" information (the identity of the connected user) in either direction within the context of an existing INVITE-initiated dialog. It can be used to convey:
本文档扩展了From header字段的使用，使其能够在现有INVITE启动对话框的上下文中以任意方向传递通常称为“已连接身份”的信息（已连接用户的身份）。它可以用来传达：
o the callee identity to a caller when a call is answered;
o 当呼叫被应答时，呼叫者的被呼叫者身份；
o the identity of a potential callee prior to answer; or
o 应答前潜在被叫方的身份；或
o the identity of a user that replaces the caller or callee following a call rearrangement such as call transfer carried out within the PSTN or within a back-to-back user agent (B2BUA) using third party call control techniques.
o 在PSTN内或使用第三方呼叫控制技术在背靠背用户代理（B2BUA）内执行呼叫转移等呼叫重新安排后，替换呼叫者或被呼叫者的用户标识。
Note that the use of standard SIP call transfer techniques, involving the REFER method, leads to the establishment of a new dialog and hence normal mechanisms for caller and callee identity apply.
请注意，使用标准SIP呼叫转移技术（包括REFER方法）会导致建立一个新的对话框，因此适用于呼叫者和被呼叫者身份的正常机制。
The provision of the identity of the responder in a response (commonly called "response identity") is outside the scope of this document.
在响应中提供响应者的身份（通常称为“响应身份”）不在本文件范围内。
Note that even if identity were to be conveyed somehow in a response, there would in general be difficulty authenticating the UAS. Providing identity in a separate request allows normal authentication techniques to be used.
请注意，即使在响应中以某种方式传递身份，通常也很难验证UAS。在单独的请求中提供身份允许使用正常的身份验证技术。
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 RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
This specification defines the following additional terms:
本规范定义了以下附加条款：
caller: the user of the UA that issues an INVITE request to initiate a call.
呼叫者：发出INVITE请求以发起呼叫的UA用户。
caller identity: the identity (Address of Record) of a caller.
呼叫者标识：呼叫者的标识（记录地址）。
callee: the user of the UA that answers a call by issuing a 2xx response to an INVITE request.
被呼叫方：UA的用户，通过对INVITE请求发出2xx响应来应答呼叫。
callee identity: the identity (Address of Record) of a callee.
被叫方标识：被叫方的标识（记录地址）。
potential callee: the user of any UA to which an INVITE request is targeted resulting in formation of an early dialog, but because of parallel or serial forking of the request, not necessarily the user that answers the call.
潜在被呼叫方：INVITE请求所针对的任何UA的用户，导致形成早期对话，但由于请求的并行或串行分叉，不一定是应答呼叫的用户。
connected user: any user involved in an established call, including the caller, the callee or any user that replaces the caller or callee following a call re-arrangement such as call transfer.
已连接用户：参与已建立呼叫的任何用户，包括呼叫者、被呼叫者或在呼叫重新安排（如呼叫转移）后替换呼叫者或被呼叫者的任何用户。
connected identity: the identity (Address of Record) of a connected user.
已连接标识：已连接用户的标识（记录地址）。
A mid-dialog request is used to provide connected identity. The User Agent Client (UAC) for that request inserts its identity in the From header field of the request. To provide authentication, the Identity header field (RFC 4474 [3]) is inserted by a suitable Authentication Service on the path of the mid-dialog request. Unless provided at the UAC, the Authentication Service is expected to be at a proxy that record routes and is able to authenticate the UAC.
mid对话框请求用于提供连接的标识。该请求的用户代理客户端（UAC）将其标识插入请求的From标头字段中。为了提供身份验证，适当的身份验证服务在mid对话请求的路径上插入标识头字段（RFC 4474[3]）。除非UAC提供身份验证服务，否则身份验证服务应位于记录路由并能够对UAC进行身份验证的代理上。
A request in the opposite direction to the INVITE request prior to or at the time the call is answered can indicate the identity of the potential callee or callee respectively. A request in the same direction as the INVITE request prior to answer can indicate a change of caller. A request in either direction after answering can indicate a change of the connected user. In all cases, a dialog (early or confirmed) has to be established before such a request can be sent.
在呼叫应答之前或应答时，与INVITE请求方向相反的请求可以分别指示潜在被叫方或被叫方的身份。与应答前的INVITE请求方向相同的请求可能表示呼叫者发生了变化。应答后向任一方向发出的请求都可能表示连接用户发生了变化。在所有情况下，在发送此类请求之前，必须建立一个对话框（提前或确认）。
This solution uses the UPDATE method (RFC 3311 [4]) for the request, or in some circumstances the re-INVITE method. To send the callee identity, the UAS for the INVITE request sends the UPDATE request after sending the 2xx response to the INVITE request and after receiving an ACK request. To send the potential callee identity, RFC 3262 [5] is expected to be supported. In this case, the UAS for the INVITE request sends the UPDATE request after receiving and responding to a PRACK request (which occurs after sending a reliable 1xx response to the INVITE request). The UPDATE request could conceivably be used for other purposes too, e.g., it could be used during an early dialog to send the potential callee identity at the same time as a Session Description Protocol (SDP) offer for early media. To indicate a connected identity change during an established call, either the UPDATE method or the re-INVITE method can be used. The re-INVITE method would be used if required for other purposes (e.g., when a B2BUA performs transfer using Third Party Call Control (3PCC) techniques it has to issue a re-INVITE request without an SDP offer to solicit an SDP offer from the UA).
此解决方案对请求使用更新方法（RFC 3311[4]），或者在某些情况下使用重新邀请方法。要发送被叫方标识，INVITE请求的UAS在向INVITE请求发送2xx响应和接收ACK请求后发送更新请求。要发送潜在被叫方标识，应支持RFC 3262[5]。在这种情况下，INVITE请求的UAS在接收并响应PRACK请求后发送更新请求（在向INVITE请求发送可靠的1x响应后发生）。可以想象，更新请求也可用于其他目的，例如，它可在早期对话期间用于在为早期媒体提供会话描述协议（SDP）的同时发送潜在被呼叫方身份。要在已建立的调用期间指示连接的标识更改，可以使用UPDATE方法或re INVITE方法。如果出于其他目的（例如，当B2BUA使用第三方呼叫控制（3PCC）技术执行传输时，它必须在没有SDP要约的情况下发出重新邀请请求，以从UA请求SDP要约），则可使用重新邀请方法。
This solution involves changing the URI (not the tags) in the To and From header fields of mid-dialog requests and their responses, compared with the corresponding values in the dialog forming request and response. Changing the To and From header field URIs was contemplated in Section 12.2.1.1 of RFC 3261 [1], which says:
此解决方案涉及将mid对话请求及其响应的“收件人”和“发件人”标题字段中的URI（而不是标记）与形成请求和响应的对话框中的相应值进行比较。RFC 3261[1]第12.2.1.1节中考虑了更改“往返”标题字段URI，其中规定：
"Usage of the URI from the To and From fields in the original request within subsequent requests is done for backwards compatibility with RFC 2543 [6], which used the URI for dialog identification. In this specification, only the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification."
“在后续请求中使用原始请求中的“收件人”和“发件人”字段的URI是为了向后兼容RFC 2543[6]，它使用URI进行对话框标识。在本规范中，仅标记用于对话框标识。在本规范的后续修订版中，预期在中间对话框请求中强制反射原始的往返URI将被弃用。”
This document therefore deprecates mandatory reflection of the original To and From URIs in mid-dialog requests and their responses, which constitutes a change to RFC 3261 [1]. This document makes no provision for proxies that are unable to tolerate a change of URI, since changing the URI has been expected for a considerable time. To cater for any UAs that are not able to tolerate a change of URI, a new option tag "from-change" is introduced for providing a positive indication of support in the Supported header field. By sending a request with a changed From header field URI only to targets that have indicated support for this option, there is no need to send this option tag in a Require header field.
因此，本文档不赞成在mid对话请求及其响应中强制反映原始URI和原始URI，这构成了对RFC 3261[1]的更改。本文档没有为不能容忍URI更改的代理做任何规定，因为更改URI已经有相当长的时间了。为了满足任何不能容忍URI更改的UAs的需要，引入了一个新的选项标记“from change”，用于在受支持的标头字段中提供支持的肯定指示。通过仅向已指示支持此选项的目标发送具有“已更改自”标题字段URI的请求，无需在“需要”标题字段中发送此选项标记。
In addition to allowing the From header field URI to change during a dialog to reflect the connected identity, this document also requires a UA that has received a connected identity in the URI of the From
除了允许在对话期间更改From标头字段URI以反映连接的标识外，本文档还要求UA在From的URI中接收到连接的标识
header field of a mid-dialog request to use that URI in the To header field of any subsequent mid-dialog request sent by that UA.
mid对话请求的标头字段，以在该UA发送的任何后续mid对话请求的to标头字段中使用该URI。
In the absence of a suitable Authentication Service on the path of the mid-dialog request, the UAS will receive an unauthenticated connected identity (i.e., without a corresponding Identity header field). The implications of this are discussed in Section 7
如果mid对话请求路径上没有合适的身份验证服务，UAS将收到未经身份验证的连接身份（即，没有相应的身份标头字段）。第7节讨论了这一点的影响
4.1. Behaviour of a UA that Issues an INVITE Request Outside the Context of an Existing Dialog
4.1. UA在现有对话框上下文之外发出邀请请求的行为
When issuing an INVITE request, a UA compliant with this specification MUST include the "from-change" option tag in the Supported header field.
发出INVITE请求时，符合此规范的UA必须在受支持的标头字段中包含“from change”选项标记。
Note that sending the "from-change" option tag does not guarantee that connected identity will be received in subsequent requests.
请注意，发送“fromchange”选项标记并不保证在后续请求中接收连接的标识。
4.2. Behaviour of a UA that Receives an INVITE Request outside the Context of an Existing Dialog
4.2. 在现有对话框的上下文之外接收INVITE请求的UA的行为
After receiving an INVITE request, a UA compliant with this specification MUST include the "from-change" option tag in the Supported header field of any dialog-forming response.
收到INVITE请求后，符合本规范的UA必须在任何对话框响应的受支持标题字段中包含“from change”选项标记。
Note that sending the "from-change" option tag does not guarantee that connected identity will be received in the event of a change of caller.
请注意，发送“fromchange”选项标记并不保证在呼叫者发生变化时会收到连接的标识。
After an early dialog has been formed, if the "from-change" option tag has been received in a Supported header field, the UA MAY issue an UPDATE request (RFC 3311 [4]) on the same dialog, subject to having sent a reliable provisional response to the INVITE request and having received and responded to a PRACK request. After a full dialog has been formed (after sending a 2xx final response to the INVITE request), if the "from-change" option tag has been received in a Supported header field and an UPDATE request has not already been sent on the early dialog, the UA MUST issue an UPDATE request on the same dialog. In either case, the UPDATE request MUST contain the callee's (or potential callee's) identity in the URI of the From header field (or an anonymous identity if anonymity is required).
在形成早期对话框之后，如果在支持的报头字段中接收到“from change”选项标记，UA可以在同一对话框上发出更新请求（RFC 3311[4]），前提是已经发送了对INVITE请求的可靠临时响应，并且已经接收并响应了PRACK请求。形成完整对话框后（向INVITE请求发送2xx最终响应后），如果在受支持的标题字段中收到“from change”选项标记，并且尚未在早期对话框上发送更新请求，UA必须在同一对话框上发出更新请求。在任何一种情况下，更新请求都必须在From头字段的URI中包含被调用方（或潜在被调用方）的标识（如果需要匿名，则包含匿名标识）。
Note that even if the URI does not differ from that in the To header field URI of the INVITE request, sending a new request allows the Authentication Service to assert authentication of this identity and confirms to the peer UA that the connected identity
注意，即使URI与INVITE请求的To header字段URI中的URI没有区别，发送新请求也允许认证服务断言该身份的认证，并向对等UA确认连接的身份
is the same as that in the To header field URI of the INVITE request.
与INVITE请求的To头字段URI中的相同。
4.3. Behaviour of a UA Whose Identity Changes during an Established INVITE-initiated Dialog
4.3. 身份在已建立的邀请发起对话期间发生变化的UA的行为
If the "from-change" option tag has been received in a Supported header field during an INVITE-initiated dialog and if the identity associated with the UA changes (e.g., due to transfer) compared to the last identity indicated in the From header field of a request sent by that UA, the UA MUST issue a request on the same dialog containing the new identity in the URI of the From header field (or an anonymous identity if anonymity is required). For this purpose the UA MUST use the UPDATE method unless for other reasons the re-INVITE method is being used at the same time.
如果在INVITE发起的对话期间在支持的标题字段中收到“from change”选项标记，并且如果与UA相关联的标识与该UA发送的请求的from标题字段中指示的最后一个标识相比发生了变化（例如，由于传输），UA必须在同一对话框上发出请求，该对话框在From头字段的URI中包含新标识（如果需要匿名，则为匿名标识）。为此，UA必须使用更新方法，除非出于其他原因，同时使用重新邀请方法。
When sending a mid-dialog request, a UA MUST observe the requirements of RFC 4474 [3] when populating the From header field URI, including provisions for achieving anonymity.
发送mid对话请求时，UA在填充From头字段URI时必须遵守RFC 4474[3]的要求，包括实现匿名性的规定。
This will allow an Authentication Service on the path of the mid-dialog request to insert an Identity header field.
这将允许mid对话框请求路径上的身份验证服务插入标识头字段。
When sending a mid-dialog request, a UA MUST populate the To header field URI with the current value of the remote URI for that dialog, where this is subject to update in accordance with the rules of Section 4.4.2 of this document rather than being fixed at the beginning of the dialog in accordance with RFC 3261 [1].
发送mid对话请求时，UA必须使用该对话的远程URI的当前值填充To报头字段URI，根据本文件第4.4.2节的规则进行更新，而不是根据RFC 3261[1]在对话开始时固定。
After sending a request with a revised From header field URI (i.e., revised compared to the URI sent in the From header field of the previous request on this dialog or in the To header field of the received dialog-forming INVITE request if no request has been sent), the UA MUST send the same URI in the From header field of any future requests on the same dialog, unless the identity changes again. Also, the UA MUST be prepared to receive the revised URI in the To header field of subsequent mid-dialog requests and MUST also continue to be prepared to receive the old URI at least until a request containing the revised URI in the To header field has been received.
发送带有修订的From header字段URI的请求后（即，与此对话框上的上一个请求的From header字段中发送的URI相比进行了修订，或者，如果未发送任何请求，则与已接收对话框的to header字段中发送的URI相比进行了修订），UA必须在同一对话框上的任何未来请求的From标头字段中发送相同的URI，除非标识再次更改。此外，UA必须准备接收后续mid对话请求的to报头字段中的修订URI，并且还必须继续准备接收旧URI，至少直到接收到to报头字段中包含修订URI的请求为止。
The mid-dialog request can be rejected in accordance with RFC 4474 [3] if the UAS does not accept the connected identity. If the UAC receives a 428, 436, 437, or 438 response to a mid-dialog request it SHOULD regard the dialog as terminated in the case of a dialog-
如果UAS不接受连接的标识，则可以根据RFC 4474[3]拒绝mid对话请求。如果UAC收到对mid对话请求的428、436、437或438响应，则应将对话视为在出现对话时终止-
terminating request and SHOULD take no action in the case of any other request.
终止请求，并且在任何其他请求的情况下不应采取任何行动。
Any attempt to repeat the request or send any other mid-dialog request is likely to result in the same response, since the UA has no control over actions of the Authentication Service.
任何重复请求或发送任何其他mid对话请求的尝试都可能导致相同的响应，因为UA无法控制身份验证服务的操作。
If a UA receives a mid-dialog request from the peer UA, the UA can make use of the identity in the From header field URI (e.g., by indicating to the user). The UA MAY discriminate between signed and unsigned identities. In the case of a signed identity, the UA SHOULD invoke a Verifier (see Section 4.6) if it cannot rely on the presence of a Verifier on the path of the request.
如果UA从对等UA接收到mid对话请求，则UA可以使用from报头字段URI中的标识（例如，通过向用户指示）。UA可以区分签名和未签名的身份。在签名身份的情况下，如果UA不能依赖请求路径上是否存在验证器，则UA应调用验证器（见第4.6节）。
If a UA receives a mid-dialog request from the peer UA in which the From header field URI differs from that received in the previous request on that dialog or that sent in the To header field of the original INVITE request and if the UA sends a 2xx response, the UA MUST update the remote URI for this dialog, as defined in RFC 3261 [1]. This will cause the new value to be used in the To header field of subsequent requests that the UA sends, in accordance with the rules of Section 4.4.1. If any other final response is sent the UA MUST NOT update the remote URI for this dialog.
如果UA收到来自对等UA的mid对话请求，其中from标头字段URI与该对话上的上一个请求中收到的URI或原始INVITE请求的To标头字段中发送的URI不同，并且如果UA发送2xx响应，UA必须更新此对话的远程URI，如RFC 3261[1]中所定义。这将导致根据第4.4.1节的规则，在UA发送的后续请求的to报头字段中使用新值。如果发送了任何其他最终响应，UA不得更新此对话框的远程URI。
An Authentication Service MUST behave in accordance with RFC 4474 [3] when dealing with mid-dialog requests.
在处理mid对话请求时，身份验证服务的行为必须符合RFC 4474[3]。
Note that RFC 4474 is silent on how to behave if the identity in the From header field is not one that the UAC is allowed to assert, and therefore it is a matter for local policy whether to reject the request or forward it without an Identity header field. Policy can be different for a mid-dialog request compared with other requests.
请注意，如果From头字段中的标识不是UAC允许断言的标识，则RFC 4474对如何操作没有说明，因此本地策略决定是拒绝请求还是转发请求而不使用标识头字段。与其他请求相比，mid对话请求的策略可能不同。
Note that when UAs conform with this specification the Authentication Service should (subject to the normal rules for authentication) be able to authenticate the sender of a request as being the entity identified in the From header field and hence will be able provide a signature for this identity. This is in contrast to UAs that do not support this specification, where retargeting and mid-dialog identity changes can render the From header field inaccurate as a means of identifying the sender of the request.
请注意，当UAs符合此规范时，身份验证服务应（根据身份验证的正常规则）能够将请求的发送者身份验证为在From标头字段中标识的实体，因此将能够为此身份提供签名。这与不支持此规范的UAs形成对比，在UAs中，重定目标和中间对话框标识更改会导致From标头字段不准确，从而无法识别请求的发送者。
When dealing with mid-dialog requests, an Authentication Service MUST behave in accordance with RFC 4474 [3] updated as stated below.
在处理mid对话框请求时，身份验证服务必须按照如下所述更新的RFC 4474[3]进行操作。
RFC 4474 [3] states that it is a matter of policy whether to reject a request with a 428 (Use Identity Header) response if there is no Identity header field in the request. A UA MAY adopt a different policy for mid-dialog requests compared with other requests.
RFC 4474[3]指出，如果请求中没有标识标头字段，是否使用428（使用标识标头）响应拒绝请求是一个政策问题。UA可能会对mid对话请求采用与其他请求不同的策略。
A proxy that receives a mid-dialog request MUST be prepared for the To header field URI and/or the From header field URI to differ from those that appeared in the dialog-forming request and response.
接收mid对话请求的代理必须准备好，以便To标头字段URI和/或From标头字段URI与形成请求和响应的对话中出现的URI不同。
A proxy that is able to provide an Authentication Service for mid-dialog requests MUST record route if Supported: from-change is indicated in the dialog forming request received by the proxy from the UAC.
如果支持，能够为mid对话请求提供身份验证服务的代理必须记录路由：代理从UAC接收到的对话形成请求中指示了from change。
In the examples below, several messages contain unfolded lines longer than 72 characters. These are captured between tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line-feeds or carriage returns).
在下面的示例中，有几条消息包含长度超过72个字符的展开行。这些是在标签之间捕获的。通过直接连接标签之间出现的所有行（丢弃任何换行或回车），可以重建单个展开行。
In the examples, the domain example.com is assumed to have the following private key (rendered in PEM format). The private key is used by the Authentication Service for generating the signature in the Identity header field.
在这些示例中，假定域example.com具有以下私钥（以PEM格式呈现）。身份验证服务使用私钥在标识头字段中生成签名。
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO
aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc
IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB
AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt
PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw
+rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30
tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H
0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0
J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C
DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r
xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU
6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK
Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk
-----END RSA PRIVATE KEY-----
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO
aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc
IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB
AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt
PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw
+rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30
tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H
0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0
J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C
DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r
xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU
6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK
Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk
-----END RSA PRIVATE KEY-----
In this example, Carol's UA has been reached by retargeting at the proxy and thus her identity (AoR) is not equal to that in the To header field of the received INVITE request (Bob). Carol's UA conveys Carol's identity in the From header field of an UPDATE request. The proxy also provides an Authentication Service and therefore adds Identity and Identity-Info header fields to the UPDATE request.
在本例中，Carol的UA是通过重新定位代理而到达的，因此她的身份（AoR）不等于收到的邀请请求（Bob）的to header字段中的身份（AoR）。Carol的UA在更新请求的From标头字段中传递Carol的身份。代理还提供身份验证服务，因此将标识和标识信息头字段添加到更新请求中。
Alice's UA PROXY + Carol's UA Authentication Service
Alice的UA代理+Carol的UA身份验证服务
INVITE(1) INVITE(2)
----------------> ---------------->
INVITE(1) INVITE(2)
----------------> ---------------->
200(4) 200(3)
<---------------- <----------------
200(4) 200(3)
<---------------- <----------------
ACK(5) ACK(6)
----------------> ---------------->
ACK(5) ACK(6)
----------------> ---------------->
UPDATE(8) UPDATE(7)
<---------------- <----------------
UPDATE(8) UPDATE(7)
<---------------- <----------------
200(9) 200(10)
----------------> ---------------->
200(9) 200(10)
----------------> ---------------->
INVITE (1):
邀请（1）：
INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154
INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
INVITE (2):
邀请（2）：
INVITE sip:Carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
</allOneLine>
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 69
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Record-Route: <sip:proxy.example.com;lr>
<allOneLine>
Identity: "xN6gCHR6KxGM+nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G+VwY1
3uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR/fFGBrpBSjztmfffLT
p6SFLxo9XQSVrkm1O4c/4UrKn2ejRz+5BULu9n9kWswzKDNjlYlmmc="
</allOneLine>
Identity-Info: <https://example.com/example.cer>;alg=rsa-sha1
Content-Type: application/sdp
Content-Length: 154
INVITE sip:Carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
</allOneLine>
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 69
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Record-Route: <sip:proxy.example.com;lr>
<allOneLine>
Identity: "xN6gCHR6KxGM+nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G+VwY1
3uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR/fFGBrpBSjztmfffLT
p6SFLxo9XQSVrkm1O4c/4UrKn2ejRz+5BULu9n9kWswzKDNjlYlmmc="
</allOneLine>
Identity-Info: <https://example.com/example.cer>;alg=rsa-sha1
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
200 (3):
200 (3):
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds;received=192.
0.2.2
</allOneLine>
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
<allOneLine>
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:carol@ua2.example.com>
Record-Route: <sip:proxy.example.com;lr>
Content-Type: application/sdp
Content-Length: 154
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds;received=192.
0.2.2
</allOneLine>
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
<allOneLine>
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:carol@ua2.example.com>
Record-Route: <sip:proxy.example.com;lr>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
200 (4):
200 (4):
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
</allOneLine>
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:carol@ua2.example.com>
Record-Route: <sip:proxy.example.com;lr>
Content-Type: application/sdp
Content-Length: 154
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
</allOneLine>
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:carol@ua2.example.com>
Record-Route: <sip:proxy.example.com;lr>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ACK (5):
确认（5）：
ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:proxy.example.com;lr>
Content-Length: 0
ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:proxy.example.com;lr>
Content-Length: 0
ACK (6):
确认（6）：
ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdt
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9;received=192.0.2.
1
</allOneLine>
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 69
Content-Length: 0
ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdt
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9;received=192.0.2.
1
</allOneLine>
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 69
Content-Length: 0
UPDATE (7):
更新（7）：
UPDATE sip:Alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:15 GMT
Route: <sip:proxy.example.com;lr>
Contact: <sip:Carol@ua2.example.com>
Content-Length: 0
UPDATE sip:Alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:15 GMT
Route: <sip:proxy.example.com;lr>
Contact: <sip:Carol@ua2.example.com>
Content-Length: 0
Note that the URI in the From header field differs from that in the To header field in the INVITE request/response. However, the tag is the same as that in the INVITE response.
请注意，From标头字段中的URI与INVITE请求/响应中To标头字段中的URI不同。但是，标记与INVITE响应中的标记相同。
UPDATE (8):
更新（8）：
UPDATE sip:Alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 69
Date: Thu, 21 Feb 2002 13:02:15 GMT
Contact: <sip:Carol@ua2.example.com>
<allOneLine>
Identity: "g8WJiVEzrbYum+z2lnS3pL+MIhuI439gDiMCHm01fwX5D8Ft5Ib9t
ewLfBT9mDOUSn6wkPSWVQfqdMF/QBPkpsIIROIi2sJOYBEMXZpNrhJd8/uboXMl9
KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0
UPDATE sip:Alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 69
Date: Thu, 21 Feb 2002 13:02:15 GMT
Contact: <sip:Carol@ua2.example.com>
<allOneLine>
Identity: "g8WJiVEzrbYum+z2lnS3pL+MIhuI439gDiMCHm01fwX5D8Ft5Ib9t
ewLfBT9mDOUSn6wkPSWVQfqdMF/QBPkpsIIROIi2sJOYBEMXZpNrhJd8/uboXMl9
KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0
200 (9):
200 (9):
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu;received=192.
0.2.2
</allOneLine>
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu;received=192.
0.2.2
</allOneLine>
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0
200 (10):
200 (10):
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0
In this example, a call is established between Alice and Bob, where Bob (not shown) lies behind a B2BUA. Bob's identity is conveyed by an UPDATE request. Then the B2BUA executes call transfer using third party call control (3PCC) techniques as described in RFC 3725 [7] (e.g., under the control of a click-to-dial application). As a result, Alice becomes connected to Carol (also not shown), and a re-INVITE request is issued allowing the session to be renegotiated. The B2BUA provides the Authentication Service and thus generates the Identity header field in the re-INVITE request to provide authentication of Carol's identity.
在本例中，Alice和Bob之间建立了一个调用，其中Bob（未显示）位于B2BUA后面。Bob的身份通过更新请求传递。然后，B2BUA使用第三方呼叫控制（3PCC）技术执行呼叫转移，如RFC 3725[7]中所述（例如，在点击拨号应用程序的控制下）。结果，Alice连接到Carol（也未显示），并发出重新邀请请求，允许重新协商会话。B2BUA提供身份验证服务，从而在重新邀请请求中生成身份标头字段，以提供Carol身份的身份验证。
Alice's UA B2BUA
艾丽丝的UA B2BUA
INVITE(1)
---------------->
INVITE(1)
---------------->
200(2)
<----------------
200(2)
<----------------
ACK(3)
---------------->
ACK(3)
---------------->
UPDATE(4)
<----------------
UPDATE(4)
<----------------
200(5)
---------------->
200(5)
---------------->
re-INVITE(6)
<----------------
re-INVITE(6)
<----------------
200(7)
---------------->
200(7)
---------------->
ACK(8)
<---------------
ACK(8)
<---------------
INVITE (1):
邀请（1）：
INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154
INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
200 (2)
200 (2)
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
</allOneLine>
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:xyz@b2bua.example.com>
Content-Type: application/sdp
Content-Length: 154
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
</allOneLine>
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:xyz@b2bua.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ACK (3)
确认（3）
ACK sip:xyz@b2bua.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0
ACK sip:xyz@b2bua.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0
UPDATE (4)
更新（4）
UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:12 GMT
Contact: <sip:xyz@b2bua.example.com>
<allOneLine>
Identity: "AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywO
UuObcwZI3qhJReZCN7ybMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5c
D26HrmitU+OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0
UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:12 GMT
Contact: <sip:xyz@b2bua.example.com>
<allOneLine>
Identity: "AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywO
UuObcwZI3qhJReZCN7ybMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5c
D26HrmitU+OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0
200 (5)
200 (5)
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1;received=192.0.
2.2
</allOneLine>
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1;received=192.0.
2.2
</allOneLine>
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0
re-INVITE (6)
重新邀请（6）
INVITE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:03:20 GMT
Contact: <sip:xyz@b2bua.example.com>
<allOneLine>
Identity: "KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gp
al8ckVM2vd1zqH/F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U
3kGg8To/6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0
INVITE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:03:20 GMT
Contact: <sip:xyz@b2bua.example.com>
<allOneLine>
Identity: "KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gp
al8ckVM2vd1zqH/F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U
3kGg8To/6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0
200 (7)
200 (7)
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy;received=192.0.
2.2
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 154
SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy;received=192.0.
2.2
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 154
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ACK (8)
确认（8）
ACK sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxz
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 ACK
Max-Forwards: 70
Content-Length: 154
ACK sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxz
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 ACK
Max-Forwards: 70
Content-Length: 154
v=0
o=UserC 2890844546 2890844546 IN IP4 ua3.example.com
s=Session SDP
c=IN IP4 ua3.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserC 2890844546 2890844546 IN IP4 ua3.example.com
s=Session SDP
c=IN IP4 ua3.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of RFC 3261 [1].
根据RFC 3261[1]第27.1节中的指南，本规范注册了一个新的SIP选项标签。
This document defines the SIP option tag "from-change".
本文档定义了SIP选项标签“from change”。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
以下行已添加到SIP参数注册表的“选项标记”部分：
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| from-change| This option tag is used to indicate that | [RFC4916] |
| | a UA supports changes to URIs in From | |
| | and To header fields during a dialog. | |
+------------+------------------------------------------+-----------+
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| from-change| This option tag is used to indicate that | [RFC4916] |
| | a UA supports changes to URIs in From | |
| | and To header fields during a dialog. | |
+------------+------------------------------------------+-----------+
RFC 4474 [3] discusses security considerations relating to the Identity header field in some detail. Those same considerations apply when using the Identity header field to authenticate a connected identity in the From header field URI of a mid-dialog request.
RFC 4474[3]详细讨论了与标识头字段相关的安全注意事项。当使用Identity header字段在mid对话请求的From header字段URI中对连接的标识进行身份验证时，这些注意事项同样适用。
A received From header field URI in a mid-dialog request for which no valid Identity header field (or other means of authentication) has been received either in this request or in an earlier request on this
从mid对话请求中的标头字段URI接收，在此请求中或在此服务器上的早期请求中未收到有效的标识标头字段（或其他身份验证手段）
dialog cannot be trusted (except in very closed environments) and is expected to be treated in a similar way to a From header field in a dialog-initiating request that is not backed up by a valid Identity header field. However, it is recommended not to reject a mid-dialog request on the grounds that the Identity header field is missing (since this would interfere with ongoing operation of the call). The absence of a valid Identity header field can influence the information given to the user. A UA can clear the call if policy or user preference dictates.
对话框不能被信任（除非在非常封闭的环境中），并且应该以与启动请求的对话框中的From头字段类似的方式处理，该请求未由有效的标识头字段备份。但是，建议不要以缺少标识标头字段为理由拒绝mid对话请求（因为这会干扰调用的持续操作）。缺少有效的标识标头字段可能会影响提供给用户的信息。如果策略或用户偏好要求，UA可以清除呼叫。
A signed connected identity in a mid-dialog request (URI in the From header field accompanied by a valid Identity header field) provides information about the peer UA in a dialog. In the case of the UA that was the UAS in the dialog-forming request, this identity is not necessarily the same as that in the To header field of the dialog-forming request. This is because of retargeting during the routing of the dialog-forming request. A signed connected identity says nothing about the legitimacy of such retargeting, but merely reflects the result of that retargeting. History information (RFC 4244 [8]) can provide additional hints as to how the connected user has been reached.
mid对话请求中的已签名连接标识（From头字段中的URI以及有效标识头字段）提供对话中对等UA的信息。如果UA是对话形成请求中的UAS，则该标识不一定与对话形成请求的To头字段中的标识相同。这是因为在对话框形成请求的路由过程中进行了重定目标。一个签名的连接身份并没有说明这种重定目标的合法性，只是反映了重定目标的结果。历史记录信息（RFC 4244[8]）可以提供关于如何联系已连接用户的额外提示。
Likewise, when a signed connected identity indicates a change of identity during a dialog, it conveys no information about the reason for such a change of identity or its legitimacy.
同样，当一个已签名的连接身份在对话过程中表示身份发生变化时，它不会传递有关身份发生变化的原因或合法性的信息。
Use of the sips URI scheme can minimize the chances of attacks in which inappropriate connected identity information is sent, either at call establishment time or during a call.
使用sips URI方案可以最大限度地减少在呼叫建立时或呼叫期间发送不适当连接身份信息的攻击机会。
Anonymity can be required by the user of a connected UA. For anonymity the UA is expected to populate the URI in the From header field of a mid-dialog request in the way described in RFC 4474 [3].
连接UA的用户可能需要匿名性。为了匿名，UA需要按照RFC 4474[3]中描述的方式在mid对话请求的From头字段中填充URI。
Thanks to Francois Audet, Frank Derks, Steffen Fries, Vijay Gurbani, Cullen Jennings, Paul Kyzivat, Hans Persson, Jon Peterson, Eric Rescorla, Jonathan Rosenberg, Shida Schubert, Ya-Ching Tan, and Dan Wing for providing valuable comments.
感谢Francois Audet、Frank Derks、Steffen Fries、Vijay Gurbani、Cullen Jennings、Paul Kyzivat、Hans Persson、Jon Peterson、Eric Rescorla、Jonathan Rosenberg、Shida Schubert、Ya Ching Tan和Dan Wing提供的宝贵意见。
[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] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[3] Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002.
[4] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年9月。
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[5] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[6] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[6] Handley，M.，Schulzrinne，H.，Schooler，E.，和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[7] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", RFC 3725, June 2002.
[7] Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，RFC 37252002年6月。
[8] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[8] Barnes，M.，“请求历史信息会话启动协议（SIP）的扩展”，RFC 4244，2005年11月。
Author's Address
作者地址
John Elwell Siemens Enterprise Communications Limited Technology Drive Beeston, Nottingham NG9 1LA UK
John Elwell西门子企业通信有限公司技术驱动英国诺丁汉州比斯顿NG9 1LA
Phone: +44 115 943 4989
EMail: john.elwell@siemens.com
Phone: +44 115 943 4989
EMail: john.elwell@siemens.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见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编辑功能的资金目前由互联网协会提供。