Internet Engineering Task Force (IETF) M. Barnes
Request for Comments: 7044 Polycom
Obsoletes: 4244 F. Audet
Category: Standards Track Skype
ISSN: 2070-1721 S. Schubert
NTT
J. van Elburg
Detecon International Gmbh
C. Holmberg
Ericsson
February 2014
Internet Engineering Task Force (IETF) M. Barnes
Request for Comments: 7044 Polycom
Obsoletes: 4244 F. Audet
Category: Standards Track Skype
ISSN: 2070-1721 S. Schubert
NTT
J. van Elburg
Detecon International Gmbh
C. Holmberg
Ericsson
February 2014
An Extension to the Session Initiation Protocol (SIP) for Request History Information
会话启动协议（SIP）的扩展，用于请求历史信息
Abstract
摘要
This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244.
本文档定义了一种标准机制，用于捕获与会话启动协议（SIP）请求相关联的历史信息。此功能通过提供有关SIP请求如何以及为什么到达特定应用程序或用户的信息，实现了许多增强的服务。本文档定义了一个可选的SIP头字段History Info，用于捕获请求中的历史信息。该文档还为历史信息和联系人头字段定义了SIP头字段参数，以标记确定请求目标的方法。此外，本规范还为隐私标头字段定义了一个值，用于指导历史信息标头字段中值的匿名化。本文件淘汰了RFC 4244。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7044.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7044.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. History-Info Header Field Protocol Structure . . . . . . . . 7
5.1. History-Info Header Field Example Scenario . . . . . . . 10
6. User Agent Handling of the History-Info Header Field . . . . 12
6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . 12
6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . 12
6.3. Back-to-Back User Agent (B2BUA) Behavior . . . . . . . . 12
7. Proxy/Intermediary Handling of History-Info Header Fields . . 13
8. Redirect Server Handling of History-Info Header Fields . . . 13
9. Handling of History-Info Header Fields in Requests and
Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 14
9.2. Sending a Request with History-Info . . . . . . . . . . . 14
9.3. Receiving a Response with History-Info or Request
Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 15
9.4. Sending History-Info in Responses . . . . . . . . . . . . 16
10. Processing the History-Info Header Field . . . . . . . . . . 16
10.1. Privacy in the History-Info Header Field . . . . . . . . 16
10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 16
10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 17
10.2. Reason in the History-Info Header Field . . . . . . . . 18
10.3. Indexing in the History-Info Header Field . . . . . . . 19
10.4. Mechanism for Target Determination in the History-Info
Header Field . . . . . . . . . . . . . . . . . . . . . . 21
11. Application Considerations . . . . . . . . . . . . . . . . . 22
12. Application-Specific Usage . . . . . . . . . . . . . . . . . 24
12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . 24
12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14.1. Registration of New SIP History-Info Header Field . . . 26
14.2. Registration of "history" for SIP Privacy Header Field . 27
14.3. Registration of Header Field Parameters . . . . . . . . 27
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 28
16.1. Backwards Compatibility . . . . . . . . . . . . . . . . 29
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.1. Normative References . . . . . . . . . . . . . . . . . . 31
17.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Request History Requirements . . . . . . . . . . . . 33
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 34
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . 35
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. History-Info Header Field Protocol Structure . . . . . . . . 7
5.1. History-Info Header Field Example Scenario . . . . . . . 10
6. User Agent Handling of the History-Info Header Field . . . . 12
6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . 12
6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . 12
6.3. Back-to-Back User Agent (B2BUA) Behavior . . . . . . . . 12
7. Proxy/Intermediary Handling of History-Info Header Fields . . 13
8. Redirect Server Handling of History-Info Header Fields . . . 13
9. Handling of History-Info Header Fields in Requests and
Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 14
9.2. Sending a Request with History-Info . . . . . . . . . . . 14
9.3. Receiving a Response with History-Info or Request
Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 15
9.4. Sending History-Info in Responses . . . . . . . . . . . . 16
10. Processing the History-Info Header Field . . . . . . . . . . 16
10.1. Privacy in the History-Info Header Field . . . . . . . . 16
10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 16
10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 17
10.2. Reason in the History-Info Header Field . . . . . . . . 18
10.3. Indexing in the History-Info Header Field . . . . . . . 19
10.4. Mechanism for Target Determination in the History-Info
Header Field . . . . . . . . . . . . . . . . . . . . . . 21
11. Application Considerations . . . . . . . . . . . . . . . . . 22
12. Application-Specific Usage . . . . . . . . . . . . . . . . . 24
12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . 24
12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14.1. Registration of New SIP History-Info Header Field . . . 26
14.2. Registration of "history" for SIP Privacy Header Field . 27
14.3. Registration of Header Field Parameters . . . . . . . . 27
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 28
16.1. Backwards Compatibility . . . . . . . . . . . . . . . . 29
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.1. Normative References . . . . . . . . . . . . . . . . . . 31
17.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Request History Requirements . . . . . . . . . . . . 33
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 34
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . 35
Many services that SIP is anticipated to support require the ability to determine why and how a SIP request arrived at a specific application. Examples of such services include (but are not limited to) sessions initiated to call centers via "click to talk" SIP Uniform Resource Locators (URLs) on a web page, "call history/ logging"-style services within intelligent "call management" software for SIP user agents (UAs), and calls to voicemail servers. Although SIP implicitly provides the retarget capabilities that enable SIP requests to be routed to chosen applications, there is a need for a standard mechanism within SIP for communicating the retargeting history of the requests. This request history information allows the receiving application to obtain information about how and why the SIP request arrived at the application/user.
SIP预计支持的许多服务都需要能够确定SIP请求到达特定应用程序的原因和方式。此类服务的示例包括（但不限于）通过网页上的“点击通话”SIP统一资源定位器（URL）向呼叫中心发起的会话、“呼叫历史记录/日志记录”用于SIP用户代理（UAs）的智能“呼叫管理”软件中的服务，以及对语音邮件服务器的呼叫。尽管SIP隐式地提供重定目标功能，使SIP请求能够路由到选定的应用程序，但SIP中需要一种标准机制来通信请求的重定目标历史。此请求历史信息允许接收应用程序获取有关SIP请求如何以及为什么到达应用程序/用户的信息。
This document defines a SIP header field, History-Info, to provide a standard mechanism for capturing the request history information to enable a wide variety of services for networks and end-users. SIP header field parameters are defined for the History-Info and Contact header fields to tag the method by which the target of a request is determined. This specification also defines a value, "history", for the Privacy header field. In addition, a SIP option tag, "histinfo", is defined.
本文档定义了SIP头字段History Info，以提供一种标准机制来捕获请求历史信息，从而为网络和最终用户提供多种服务。SIP头字段参数是为历史信息和联系人头字段定义的，用于标记确定请求目标的方法。本规范还为隐私标头字段定义了一个值“历史”。此外，还定义了SIP选项标记“histinfo”。
The History-Info header field provides a building block for development of SIP-based applications and services. The requirements for the solution described in this specification are included in Appendix A. Example scenarios using the History-Info header field are available in [CALLFLOWS].
History Info header字段为基于SIP的应用程序和服务的开发提供了一个构建块。本规范中描述的解决方案要求包含在附录A中。使用历史信息标题字段的示例场景可在[CALLFLOWS]中找到。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The term "retarget" is used in this specification to refer to the process of a SIP entity changing the Request-URI (Section 7.1 of [RFC3261]) in a request based on the rules for determining request targets as described in Section 16.5 of [RFC3261] and of the subsequent forwarding of that request as described in step 2 in Section 16.6 of [RFC3261]. This includes changing the Request-URI due to a location service lookup and redirect processing. This also includes internal (to a proxy/SIP intermediary) changes of the URI prior to the forwarding of the request.
本规范中使用术语“重定目标”是指SIP实体根据[RFC3261]第16.5节中所述的确定请求目标的规则以及[RFC3261]第16.6节中步骤2中所述的后续转发请求中更改请求URI（RFC3261）的过程[RFC3261]。这包括由于位置服务查找和重定向处理而更改请求URI。这还包括在转发请求之前对URI的内部（到代理/SIP中介）更改。
The terms "location service", "forward", "redirect", and "AOR" (address-of-record) are used consistently with the terminology in [RFC3261].
术语“定位服务”、“转发”、“重定向”和“AOR”（记录地址）的使用与[RFC3261]中的术语一致。
The term "target user" is used in this specification as the human user associated with one or more particular AORs (in case the human user has multiple aliases).
术语“目标用户”在本规范中用作与一个或多个特定AOR关联的人工用户（如果人工用户有多个别名）。
The references to "domain for which the SIP entity/proxy/intermediary is responsible" are consistent with and intended to convey the same context as the usage of that terminology in [RFC3261]. The applicability of History-Info to architectures or models outside the context of [RFC3261] is outside the scope of this specification.
对“SIP实体/代理/中介机构负责的领域”的引用与[RFC3261]中该术语的使用一致，并旨在传达相同的上下文。[RFC3261]上下文之外的体系结构或模型的历史信息的适用性不在本规范的范围内。
SIP implicitly provides retargeting capabilities that enable SIP requests to be routed to specific applications as defined in [RFC3261]. The motivation for capturing the request history is that in the process of retargeting a request, old routing information can be forever lost. This lost information may be important history that allows elements to which the request is retargeted to process the request in a locally defined, application-specific manner. This document defines a mechanism for transporting the request history. Application-specific behavior is outside the scope of this specification.
SIP隐式提供重定目标功能，使SIP请求能够路由到[RFC3261]中定义的特定应用程序。捕获请求历史记录的动机是，在重新确定请求目标的过程中，旧的路由信息可能永远丢失。丢失的信息可能是重要的历史记录，它允许请求重定目标的元素以本地定义的特定于应用程序的方式处理请求。本文档定义了传输请求历史记录的机制。特定于应用程序的行为不在本规范的范围内。
Current network applications for other protocols provide the ability for elements involved with the request to obtain additional information relating to how and why the request was routed to a particular destination. The following are examples of such applications:
其他协议的当前网络应用程序为请求所涉及的元素提供了获取与请求路由到特定目的地的方式和原因相关的附加信息的能力。以下是此类应用的示例：
1. Web "referral" applications, whereby an application residing within a web server determines that a visitor to a website has arrived at the site via an "associate" site that will receive some "referral" commission for generating this traffic.
1. Web“转介”应用程序，其中驻留在Web服务器内的应用程序确定网站的访问者已通过“关联”网站到达该网站，该网站将收到一些“转介”佣金以生成此流量。
2. Email relaying whereby the recipient obtains a detailed "trace of the path" of the message from originator to receiver, including the time of each relay.
2. 通过电子邮件中继，收件人可以获得从发端到接收方的详细“路径跟踪”，包括每次中继的时间。
3. Traditional telephony services such as voicemail, call-center "automatic call distribution", and "follow me"-style services.
3. 传统电话服务，如语音邮件、呼叫中心“自动呼叫分配”和“跟我走”式服务。
Several of the aforementioned applications currently define application-specific mechanisms through which it is possible to obtain the necessary history information.
上述几个应用程序目前定义了特定于应用程序的机制，通过这些机制可以获得必要的历史信息。
In addition, request history information could be used to enhance basic SIP functionality by providing the following:
此外，请求历史信息可用于通过提供以下内容来增强基本SIP功能：
o Some diagnostic information for debugging SIP requests.
o 一些用于调试SIP请求的诊断信息。
o Capturing aliases and Globally Routable User Agent URIs (GRUUs) [RFC5627], which can be overwritten by a registrar or a "home proxy" (a proxy serving as the terminal point for routing an address-of-record) upon receipt of the initial request.
o 捕获别名和全局可路由用户代理URI（GROUS）[RFC5627]，在收到初始请求时，注册器或“主代理”（用作路由记录地址的终端点的代理）可以覆盖这些URI。
o Facilitating the use of limited use addresses (minted on demand) and sub-addressing.
o 促进有限使用地址（按需铸造）和子地址的使用。
o Preserving service-specific URIs that can be overwritten by a downstream proxy, such as those defined in [RFC3087], and control of network announcements and Interactive Voice Response (IVR) with a SIP URI [RFC4240].
o 保留可由下游代理覆盖的特定于服务的URI，如[RFC3087]中定义的URI，并使用SIP URI[RFC4240]控制网络公告和交互式语音响应（IVR）。
The fundamental functionality provided by the request history information is the ability to inform proxies and user agents (UAs) involved in processing a request about the history or progress of that request. The solution is to capture the Request-URIs, as a request is retargeted, in a SIP header field: History-Info. This allows for the capturing of the history of a request that would be lost with the normal SIP processing involved in the subsequent retargeting of the request.
请求历史记录信息提供的基本功能是能够将请求的历史记录或进度通知处理请求所涉及的代理和用户代理（UAs）。解决方案是在重新定位请求时，在SIP头字段：History Info中捕获请求URI。这允许捕获请求的历史记录，该历史记录将在请求的后续重定目标过程中涉及的正常SIP处理中丢失。
The History-Info header field is added to a request when a new request is created by a User Agent Client (UAC) or forwarded by a proxy, or when the target of a request is changed. It is possible for the target of a request to be changed by the same proxy/SIP intermediary multiple times (referred to as 'internal retargeting'). A SIP entity changing the target of a request in response to a redirect also propagates any History-Info header field from the initial request in the new request. The ABNF and detailed description of the History-Info header field parameters, along with examples, are provided in Section 5. Sections 6, 7, and 8 provide the detailed handling of the History-Info header field by SIP user agents, proxies, and redirect servers, respectively.
当用户代理客户端（UAC）创建新请求或代理转发新请求时，或者当请求的目标更改时，历史信息标头字段将添加到请求中。同一个代理/SIP中介可能多次更改请求的目标（称为“内部重定目标”）。为响应重定向而更改请求目标的SIP实体也会从新请求中的初始请求传播任何历史信息头字段。ABNF和历史信息标题字段参数的详细说明以及示例见第5节。第6、7和8节分别提供了SIP用户代理、代理和重定向服务器对历史信息头字段的详细处理。
This specification also defines three new SIP header field parameters, "rc", "mp", and "np", for the History-Info and Contact header fields to tag the method by which the target of a request is determined. Further detail on the use of these header field parameters is provided in Section 5.
本规范还为历史信息和联系人头字段定义了三个新的SIP头字段参数“rc”、“mp”和“np”，以标记确定请求目标的方法。第5节提供了有关使用这些标题字段参数的更多详细信息。
This specification also defines a priv-value for the Privacy header, "history"; it requires anonymization of all the History-Info header field entries in a request or to a specific History-Info header field value (hi-entry) as described below. Further detail is provided in Section 10.1.
本规范还定义了隐私头的priv值“history”；它需要匿名化请求中的所有历史信息头字段条目，或匿名化为特定的历史信息头字段值（hi条目），如下所述。更多详情见第10.1节。
In addition, a SIP option tag, "histinfo", is defined. The use of this option tag is described in Section 6.1.
此外，还定义了SIP选项标记“histinfo”。第6.1节介绍了该选项标签的使用。
The History-Info header field defined in this specification defines the usage in out-of-dialog requests or initial requests for a dialog (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) and any non-100 provisional or final responses to these requests.
本规范中定义的历史信息标题字段定义了对话外请求或对话初始请求（例如，邀请、注册、消息、引用和选项、发布和订阅等）以及对这些请求的任何非100临时或最终响应的用法。
The following provides details for the information that is captured in the History-Info header field entries for each target used for forwarding a request.
以下提供了用于转发请求的每个目标的历史信息标头字段条目中捕获的信息的详细信息。
o hi-targeted-to-uri: A mandatory parameter for capturing the Request-URI for the specific request as it is forwarded.
o hi targeted to uri：一个强制参数，用于在转发特定请求时捕获该请求的请求uri。
o hi-index: A mandatory parameter for History-Info reflecting the chronological order of the information, indexed to reflect the forking and retargeting of requests. The format for this parameter is a sequence of nonnegative integers, separated by dots to indicate the number of forward hops and retargets. This results in a tree representation of the history of the request, with the lowest-level index reflecting a leaf. By adding the new entries in chronological order (i.e., following existing entries per the details in Section 10.3), including the index and sending the messages using a secure transport, the ordering of the History-Info header fields in the request is assured. In addition, applications may extract a variety of metrics (total number of retargets, total number of retargets from a specific branch, etc.) based upon the index values.
o hi index：历史信息的一个必需参数，反映信息的时间顺序，索引以反映请求的分叉和重定目标。此参数的格式是一个非负整数序列，由点分隔，以指示向前跳跃和重定目标的数量。这将导致请求历史的树表示，最低级别的索引反映一个叶。通过按时间顺序添加新条目（即，根据第10.3节中的详细信息跟踪现有条目），包括索引和使用安全传输发送消息，可以确保请求中历史信息标头字段的顺序。此外，应用程序可以基于索引值提取各种度量（重定目标总数、来自特定分支的重定目标总数等）。
o hi-target-param: An optional parameter reflecting the mechanism by which the Request-URI captured in the hi-targeted-to-uri in the History-Info header field value (hi-entry) was determined. This parameter is either an "rc", "mp", or "np" header field parameter, which is interpreted as follows:
o hi target param：一个可选参数，反映了确定hi中捕获的请求URI的机制，hi target to URI位于历史信息头字段值（hi条目）中。此参数为“rc”、“mp”或“np”标题字段参数，解释如下：
"rc": The hi-targeted-to-URI represents a change in Request-URI, while the target user remains the same. This occurs, for example, when the user has multiple AORs as an alias. The "rc" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that reflects the Request-URI that was retargeted.
“rc”：针对URI的hi表示请求URI的更改，而目标用户保持不变。例如，当用户有多个AOR作为别名时，就会发生这种情况。“rc”header字段参数包含hi条目中hi索引的值，hi的目标uri反映了重定目标的请求uri。
"mp": The hi-targeted-to-URI represents a user other than the target user associated with the Request-URI in the incoming request that was retargeted. This occurs when a request is statically or dynamically retargeted to another user represented by an AOR unassociated with the AOR of the original target user. The "mp" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that reflects the Request-URI that was retargeted, thus identifying the "mapped from" target.
“mp”：hi targeted to URI表示与重定目标的传入请求中的请求URI关联的目标用户以外的用户。当一个请求被静态或动态地重定目标到另一个用户（由与原始目标用户的AOR无关的AOR表示）时，就会发生这种情况。“mp”header字段参数包含hi条目中的hi索引值，hi目标为uri，该uri反映了重定目标的请求uri，从而标识“映射自”目标。
"np": The hi-targeted-to-URI represents that there was no change in the Request-URI. This would apply, for example, when a proxy merely forwards a request to a next-hop proxy and loose routing is used. The "np" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that reflects the Request-URI that was copied unchanged into the request represented by this hi-entry. That value will usually be the hi-index of the parent hi-entry of this hi-entry.
“np”：指向URI的hi表示请求URI中没有更改。例如，当代理仅将请求转发给下一跳代理并使用松散路由时，这将适用。“np”header字段参数包含hi条目中的hi索引值，hi的目标uri反映了未更改地复制到此hi条目表示的请求中的请求uri。该值通常是该hi条目的父hi条目的hi索引。
o Extension (hi-extension): A parameter to allow for future optional extensions. As per [RFC3261], any implementation not understanding an extension MUST ignore it.
o 扩展（hi扩展）：一个允许将来可选扩展的参数。根据[RFC3261]，任何不理解扩展的实现都必须忽略它。
The ABNF syntax [RFC5234] for the History-Info header field and header field parameters is as follows:
历史信息标头字段和标头字段参数的ABNF语法[RFC5234]如下所示：
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
History Info=“History Info”HCOLON hi entry*（逗号hi entry）
hi-entry = hi-targeted-to-uri *(SEMI hi-param)
hi entry=hi针对uri*（半hi参数）
hi-targeted-to-uri = name-addr
hi-targeted-to-uri = name-addr
hi-param = hi-index / hi-target-param / hi-extension
hi-param = hi-index / hi-target-param / hi-extension
hi-index = "index" EQUAL index-val
hi index=“index”等于索引值
index-val = number *("." number)
索引值=编号*（“”编号）
number = [ %x31-39 *DIGIT ] DIGIT
number = [ %x31-39 *DIGIT ] DIGIT
hi-target-param = rc-param / mp-param / np-param
hi-target-param = rc-param / mp-param / np-param
rc-param = "rc" EQUAL index-val
rc param=“rc”相等索引值
mp-param = "mp" EQUAL index-val
mp param=“mp”相等索引值
np-param = "np" EQUAL index-val
np param=“np”相等索引值
hi-extension = generic-param
hi-extension = generic-param
The ABNF definitions for "generic-param", "name-addr", "HCOLON", "COMMA", "SEMI", and "EQUAL" are from [RFC3261].
ABNF对“通用参数”、“名称地址”、“HCOLON”、“逗号”、“半”和“相等”的定义来自[RFC3261]。
This document also extends the "contact-params" for the Contact header field as defined in [RFC3261] with the "rc", "mp", and "np" header field parameters defined above.
本文件还使用上文定义的“rc”、“mp”和“np”标题字段参数扩展了[RFC3261]中定义的联系人标题字段的“contact params”。
In addition to the parameters defined by the ABNF, an hi-entry may also include a Reason header field and/or a Privacy header field, which are both included in the "headers" component of the hi-targeted-to-uri as described below:
除了ABNF定义的参数外，hi条目还可以包括原因标头字段和/或隐私标头字段，这两个字段都包括在针对uri的hi的“标头”组件中，如下所述：
o Reason: An optional parameter for History-Info, reflected in the History-Info header field by including the Reason header field [RFC3326] included in the hi-targeted-to-uri. A reason is included in the hi-targeted-to-uri of an hi-entry to reflect information received in a response to the request sent to that URI.
o 原因：历史信息的可选参数，通过包括hi目标uri中包含的原因标头字段[RFC3326]，反映在历史信息标头字段中。原因包括在hi条目的hi目标uri中，以反映在响应发送到该uri的请求时接收到的信息。
o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy header [RFC3323] with a priv-value of "history", as defined in this document, included in the hi-targeted-to-uri or by adding the Privacy header field with a priv-value of "history" to the request. The latter case indicates that the History-Info entries for all History-Info entries whose hi-targeted-to-uri has the same domain as the domain for which the SIP entity processing the message is responsible MUST be anonymized prior to forwarding, whereas the use of the Privacy header field included in the hi -targeted-to-uri means that a specific hi-entry MUST be anonymized.
o Privacy（隐私）：历史信息的可选参数，通过将priv值为“History”（如本文档中定义）的Privacy header[RFC3323]包括在hi目标uri中，或通过将priv值为“History”的Privacy header字段添加到请求中，反映在历史信息标头字段值中。后一种情况表明，hi针对uri的所有历史信息条目的历史信息条目与处理消息的SIP实体负责的域具有相同的域，必须在转发之前匿名，然而，使用hi-targeted to uri中包含的Privacy header字段意味着特定的hi条目必须匿名化。
Note that since both the Reason and Privacy parameters are included in the hi-targeted-to-uri, these fields will not be available in the case that the hi-targeted-to-uri is a Tel-URI [RFC3966].
注意，由于原因和隐私参数都包含在hi目标uri中，因此在hi目标uri为Tel uri的情况下，这些字段将不可用[RFC3966]。
The following provides examples of the format for the History-Info header field. Note that the backslash, CRLF, and whitespace between the lines in the examples below are inserted for readability purposes only. Note, however, that History-Info can be broken into multiple lines due to the SWS (sep whitespace) that is part of HCOLON, COMMA, and SEMI, and there can be multiple History-Info header fields due to the rule of Section 7.3 of [RFC3261]. Additional detailed examples are available in [CALLFLOWS].
下面提供了历史信息标题字段格式的示例。请注意，下面示例中的行之间插入的反斜杠、CRLF和空格仅用于可读性目的。但是，请注意，由于SWS（sep空格）是HCOLON、逗号和半分隔符的一部分，历史信息可以分为多行，并且根据[RFC3261]第7.3节的规则，可以有多个历史信息标题字段。[CALLFLOWS]中提供了其他详细示例。
History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar
History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar
History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B\
cause%3D302>;index=1.1,\
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
cause%3D486>;index=1.2;mp=1.1,\
<sip:45432@192.168.0.3>;index=1.3;rc=1.2
History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B\
cause%3D302>;index=1.1,\
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
cause%3D486>;index=1.2;mp=1.1,\
<sip:45432@192.168.0.3>;index=1.3;rc=1.2
The following is an illustrative example of usage of History-Info.
下面是使用历史信息的示例。
In this example, Alice (sip:alice@atlanta.example.com) calls Bob (sip:bob@biloxi.example.com). Alice's proxy in her home domain (sip:atlanta.example.com) forwards the request to Bob's proxy (sip:biloxi.example.com). When the request arrives at sip:biloxi.example.com, it does a location service lookup for bob@biloxi.example.com and changes the target of the request to Bob's Contact URIs that were provided as part of normal SIP registration. In this example, Bob is simultaneously contacted on a PC client and on a phone, and Bob answers on the PC client.
在本例中，Alice（sip:alice@atlanta.example.com)打电话给鲍勃（sip:bob@biloxi.example.com). Alice在其主域（sip:atlanta.example.com）中的代理将请求转发给Bob的代理（sip:biloxi.example.com）。当请求到达sip:biloxi.example.com时，它会对bob@biloxi.example.com并将请求的目标更改为Bob的联系人URI，这些URI是作为正常SIP注册的一部分提供的。在本例中，通过PC客户端和电话同时联系Bob，Bob在PC客户端进行应答。
One important thing illustrated by this call flow is that without History-Info, Bob would "lose" the original target information or the initial Request-URI, including any parameters in the Request-URI. Bob can recover that information by locating the last hi-entry with an "rc" header field parameter. This "rc" header field parameter contains the index of the hi-entry containing the lost target information, i.e., the sip:bob@biloxi.example.com hi-entry with index=1.1. Note that in the 200 response to Alice, an hi-entry is not included for the fork to sip:bob@192.0.2.7 (index 1.1.1) since biloxi.example.com had not received a response from that fork at the time it sent the 200 OK that ultimately reached Alice.
这个调用流说明的一件重要事情是，如果没有历史信息，Bob将“丢失”原始目标信息或初始请求URI，包括请求URI中的任何参数。Bob可以通过使用“rc”头字段参数定位最后一个hi条目来恢复该信息。此“rc”头字段参数包含包含丢失目标信息的hi条目索引，即sip：bob@biloxi.example.com索引为1.1的hi条目。注意，在对Alice的200响应中，fork-to-sip不包括hi条目：bob@192.0.2.7（索引1.1.1）因为biloxi.example.com在发送最终到达Alice的200 OK时没有收到来自该fork的响应。
Additional detailed examples are available in [CALLFLOWS].
[CALLFLOWS]中提供了其他详细示例。
Note: This example uses loose routing procedures.
注意：此示例使用松散的路由过程。
Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone
| | | | |
| INVITE sip:bob@biloxi.example.com;p=x | |
|--------------->| | | |
| Supported: histinfo | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 |
| | | | |
| | INVITE sip:bob@biloxi.example.com;p=x |
| |--------------->| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 |
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| | | | |
| | | INVITE sip:bob@192.0.2.3|
| | |--------------->| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | | INVITE sip:bob@192.0.2.7|
| | |-------------------------->|
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.7>;index=1.1.2;rc=1.1
| | | 200 | |
| | |<---------------| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | 200 | | |
| |<---------------| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | | Proxy Cancels INVITE |
| | |<=========================>|
| 200 | | | |
|<---------------| | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| ACK | | | |
|--------------->| ACK | | |
| |--------------->| ACK | |
| | |--------------->| |
Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone
| | | | |
| INVITE sip:bob@biloxi.example.com;p=x | |
|--------------->| | | |
| Supported: histinfo | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 |
| | | | |
| | INVITE sip:bob@biloxi.example.com;p=x |
| |--------------->| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 |
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| | | | |
| | | INVITE sip:bob@192.0.2.3|
| | |--------------->| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | | INVITE sip:bob@192.0.2.7|
| | |-------------------------->|
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.7>;index=1.1.2;rc=1.1
| | | 200 | |
| | |<---------------| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | 200 | | |
| |<---------------| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | | Proxy Cancels INVITE |
| | |<=========================>|
| 200 | | | |
|<---------------| | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| ACK | | | |
|--------------->| ACK | | |
| |--------------->| ACK | |
| | |--------------->| |
Figure 1: Basic Call
图1：基本调用
This section describes the processing specific to UAs -- User Agent Clients (UACs), User Agent Servers (UASs), and Back-to-Back User Agents (B2BUAs) -- for the History-Info header.
本节描述了特定于UAs（用户代理客户端（UAC）、用户代理服务器（UAs）和背靠背用户代理（B2BUAs））的历史信息头的处理。
The UAC MUST include the "histinfo" option tag in the Supported header field in any out-of-dialog requests or initial requests for a dialog for which the UAC would like the History-Info header field in the response. When issuing a request, the UAC MUST follow the procedures in Section 9.2. In the case of an initial request, except where the UAC is part of a B2BUA, there is no cache of hi-entries with which to populate the History-Info header field, and the hi-index is set to 1 per Section 10.3. When receiving a response, the UAC MUST follow the procedures in Section 9.3.
UAC必须在任何对话框外请求或UAC希望在响应中包含历史信息标题字段的对话框初始请求中，在支持的标题字段中包含“histinfo”选项标记。在发出请求时，UAC必须遵循第9.2节中的程序。在初始请求的情况下，除了UAC是B2BUA的一部分外，没有用于填充历史信息标题字段的hi条目缓存，hi索引根据第10.3节设置为1。收到回复时，UAC必须遵循第9.3节中的程序。
If the UAC generates further forks of the initial request (either due to acting on a 3xx response or internally directed forking to multiple destinations), the successive requests will add hi-entries with hi-indexes of 2, 3, etc.
如果UAC生成初始请求的进一步分支（由于3xx响应或内部定向分支到多个目的地），则后续请求将添加hi索引为2、3等的hi条目。
When receiving a request, a UAS MUST follow the procedures defined in Section 9.2. When sending a response other than a 3xx response, a UAS MUST follows the procedures defined in Section 9.4. When sending a 3xx response, the UAS MUST follow the procedures defined for a redirect server per Section 8. An application at the UAS can make use of the cached hi-entries as described in Section 11.
收到请求时，UAS必须遵循第9.2节中规定的程序。当发送3xx响应以外的响应时，UAS必须遵循第9.4节中定义的程序。当发送3xx响应时，UAS必须遵循第8节为重定向服务器定义的程序。UAS上的应用程序可以使用缓存的hi条目，如第11节所述。
A B2BUA MAY follow the behavior of a SIP intermediary, per Section 7, as an alternative to following the behavior of a UAS per Section 6.2 or a UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries forward hi-entries received in requests at the UAS to requests being forwarded by the UAC, as well as carrying forward hi-entries in responses received at the UAC to the responses forwarded by the UAS, subject to privacy considerations per Section 10.1.
B2BUA可根据第7节遵循SIP中介机构的行为，作为第6.2节遵循UAS行为或第6.1节遵循UAC行为的替代方案。作为中介，B2BUA将在UAS收到的请求中的hi条目转发给UAC转发的请求，并将在UAC收到的响应中的hi条目转发给UAS转发的响应，但需遵守第10.1节的隐私考虑。
This section describes the procedures for proxies and other SIP intermediaries for the handling of the History-Info header fields for each of the following scenarios:
本节介绍代理和其他SIP中介机构处理以下每个场景的历史信息头字段的过程：
Receiving a Request: An intermediary MUST follow the procedures in Section 9.1 for the handling of hi-entries in incoming SIP requests.
接收请求：中介机构必须按照第9.1节中的程序处理传入SIP请求中的hi条目。
Sending a Request: For each outgoing request relating to a target in the target set, the intermediary MUST follow the procedures of Section 9.2.
发送请求：对于与目标集中的目标相关的每个传出请求，中介机构必须遵循第9.2节的程序。
Receiving a Response or Timeout: An intermediary MUST follow the procedures of Section 9.3 when a SIP response is received or a request times out.
接收响应或超时：当收到SIP响应或请求超时时，中介机构必须遵循第9.3节的程序。
Sending a Response: An intermediary MUST follow the procedures of Section 9.4 for the handling of the hi-entries when sending a SIP response.
发送响应：中间人在发送SIP响应时，必须遵循第9.4节中处理hi条目的程序。
In some cases, an intermediary may retarget a request more than once before forwarding, i.e., a request is retargeted to a SIP entity that is "internal" to the intermediary before the same intermediary retargets the request to an external target. A typical example would be a proxy that retargets a request first to a different user (i.e., it maps to a different AOR) and then forwards it to a registered contact bound to the same AOR. In this case, the intermediary MUST add an hi-entry for (each of) the internal target(s) per the procedures in Section 9.2. The intermediary MAY include a Reason header field in the hi-entry with the hi-targeted-to-uri that has been retargeted. Note that this is shown in the INVITE (F6) in the example entitled "Sequentially Forking (History-Info in Response)" in [CALLFLOWS].
在某些情况下，中介可以在转发之前多次重定目标请求，即，在同一中介将请求重定目标到外部目标之前，将请求重定目标到中介“内部”的SIP实体。一个典型的例子是代理，它首先将请求重定目标到不同的用户（即，它映射到不同的AOR），然后将其转发到绑定到同一AOR的注册联系人。在这种情况下，中介机构必须根据第9.2节中的程序为（每个）内部目标添加hi条目。中介可以在hi条目中包括原因头字段，hi的目标是已重定目标的uri。请注意，这在[CALLFLOWS]中题为“顺序分叉（响应中的历史信息）”的示例中的INVITE（F6）中显示。
A redirect server MUST follow the procedures in Section 9.1 when it receives a SIP request. A redirect server MUST follow the procedures in Section 9.4 when it sends a SIP response. When generating the Contact header field in a 3xx response, the redirect server MUST add the appropriate "mp", "np", or "rc" header field parameter to each Contact header field as described in Section 10.4, if applicable.
当重定向服务器收到SIP请求时，它必须遵循第9.1节中的过程。重定向服务器在发送SIP响应时必须遵循第9.4节中的步骤。在3xx响应中生成联系人标头字段时，重定向服务器必须向每个联系人标头字段添加适当的“mp”、“np”或“rc”标头字段参数，如第10.4节所述（如适用）。
This section describes the procedures for SIP entities for the handling of the History-Info header field in SIP requests and responses.
本节描述SIP实体处理SIP请求和响应中历史信息头字段的过程。
When receiving a request, a SIP entity MUST keep a copy of the hi-entries from the incoming request. This document describes this copy in terms of a cache containing the hi-entries associated with the request. The hi-entries MUST be added to the cache in the order in which they were received in the request.
当接收到请求时，SIP实体必须保留来自传入请求的hi条目的副本。本文档以包含与请求关联的hi条目的缓存的形式描述此副本。hi条目必须按照在请求中接收它们的顺序添加到缓存中。
If the Request-URI of the incoming request does not match the hi -targeted-to-uri in the last hi-entry (i.e., the previous SIP entity that sent the request did not include a History-Info header field), the SIP entity MUST add an hi-entry to the end of the cache, on behalf of the previous SIP entity. This is done as follows, before proceeding to Section 9.2.
如果传入请求的请求URI与最后一个hi条目中的hi目标URI不匹配（即，发送请求的前一个SIP实体不包括历史信息头字段），则SIP实体必须代表前一个SIP实体将hi条目添加到缓存的末尾。在继续进行第9.2节之前，按照以下步骤进行。
The SIP entity MUST set the hi-targeted-to-uri to the value of the Request-URI in the incoming request. If the Request-URI is a Tel-URI, it SHOULD be transformed into a SIP URI (per Section 19.1.6 of [RFC3261]) before being added as an hi-targeted-to-uri.
SIP实体必须将hi targeted to uri设置为传入请求中请求uri的值。如果请求URI是Tel URI，则应将其转换为SIP URI（根据[RFC3261]第19.1.6节），然后再添加为URI的hi目标。
If privacy is required, the SIP entity MUST follow the procedures of Section 10.1.
如果需要隐私，SIP实体必须遵守第10.1节的程序。
The SIP entity MUST set the hi-index parameter as described in Section 10.3.
SIP实体必须按照第10.3节所述设置hi索引参数。
The SIP entity MUST NOT include an "rc", "mp", or "np" header field parameter.
SIP实体不得包含“rc”、“mp”或“np”头字段参数。
When sending a request, a SIP entity MUST include all the hi-entries from the cache that was created per Section 9.1. In addition, the SIP entity MUST add a new hi-entry to the outgoing request, but the SIP entity MUST NOT add the hi-entry to the cache at this time. The hi-entries in the outgoing request's History-Info header field represent the preorder of the tree of hi-entries, that is, by the lexicographic ordering of the hi-indexes. The new hi-entry is populated as follows:
发送请求时，SIP实体必须包括根据第9.1节创建的缓存中的所有hi条目。此外，SIP实体必须将新的hi条目添加到传出请求中，但此时SIP实体不得将hi条目添加到缓存中。传出请求的历史信息标头字段中的hi条目表示hi条目树的前序，即hi索引的字典顺序。新的hi条目填充如下：
hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the value of the Request-URI of the current (outgoing) request. If the Request-URI is a Tel-URI, it SHOULD be transformed into a SIP URI (per Section 19.1.6 of [RFC3261]) before being added as an hi-targeted-to-uri.
hi targeted to uri：hi targeted to uri必须设置为当前（传出）请求的请求uri的值。如果请求URI是Tel URI，则应将其转换为SIP URI（根据[RFC3261]第19.1.6节），然后再添加为URI的hi目标。
privacy: If privacy is required, the procedures of Section 10.1 MUST be followed.
隐私：如果需要隐私，必须遵守第10.1节的程序。
hi-index: The SIP entity MUST include an hi-index for the hi-entry as described in Section 10.3.
hi索引：如第10.3节所述，SIP实体必须包括hi条目的hi索引。
rc/mp/np: The SIP entity MUST include an "rc", "mp", or "np" header field parameter in the hi-entry, if applicable, per the procedures in Section 10.4.
rc/mp/np：根据第10.4节中的程序，SIP实体必须在hi条目中包含“rc”、“mp”或“np”标题字段参数（如适用）。
When a SIP entity receives a non-100 response or a request times out, the SIP entity performs the following steps:
当SIP实体收到非100响应或请求超时时，SIP实体执行以下步骤：
Step 1: Add hi-entry to cache
步骤1：将hi条目添加到缓存
The SIP entity MUST add the hi-entry that was added to the request that received the non-100 response or timed out to the cache, if it was not already cached. The hi-entry MUST be added to the cache in ascending order as indicated by the values in the hi-index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 but before 1.2.2 or 1.3).
SIP实体必须将添加到接收非100响应的请求或超时的hi条目添加到缓存中（如果尚未缓存）。必须按照hi项的hi索引参数中的值所指示的升序将hi项添加到缓存中（例如，1.2.1在1.2之后，但在1.2.2或1.3之前）。
Step 2: Add Reason header field
步骤2：添加原因标题字段
If the response is not a 100 or 2xx response, the SIP entity adds one or more Reason header fields to the hi-targeted-to-uri in the (newly) cached hi-entry reflecting the SIP response code in the non-100 or non-2xx response, per the procedures of Section 10.2.
如果响应不是100或2xx响应，则根据第10.2节的过程，SIP实体将一个或多个原因头字段添加到（新）缓存的hi条目中以uri为目标的hi，以反映非100或非2xx响应中的SIP响应代码。
Step 3: Add additional hi-entries
步骤3：添加其他hi条目
The SIP entity MUST also add to the cache any hi-entries received in the response that are not already in the cache. This situation can occur when the entity that generated the non-100 response retargeted the request before generating the response. As per Step 1, the hi-entries MUST be added to the cache in ascending order as indicated by the values in the hi-index parameters of the hi-entries.
SIP实体还必须向缓存中添加响应中接收到的、尚未在缓存中的任何hi条目。当生成非100响应的实体在生成响应之前重新确定请求的目标时，可能会出现这种情况。按照步骤1，必须按照hi项的hi索引参数中的值所指示的升序将hi项添加到缓存中。
It is important to note that the cache (and the request or response) does not contain hi-entries for requests that have not yet received a non-100 response, so there can be gaps in indices (e.g., 1.2 and 1.4 could be present but not 1.3).
需要注意的是，对于尚未收到非100响应的请求，缓存（以及请求或响应）不包含hi条目，因此索引中可能存在差距（例如，可能存在1.2和1.4，但不存在1.3）。
Note that in the case that a request has traversed one or more intermediaries that do not support RFC 4244 or this document, there can be duplicate indices (due to forking), which would be added to the appropriate position in the cache in the order in which they are received.
请注意，如果请求已通过一个或多个不支持RFC 4244或本文档的中介，则可能存在重复索引（由于分叉），这些索引将按接收顺序添加到缓存中的适当位置。
When sending a response other than a 100, a SIP entity MUST include all the cached hi-entries in the response, subject to the privacy consideration in Section 10.1.2, and with the following exception: If the received request contained no hi-entries and there is no "histinfo" option tag in the Supported header field, the SIP entity MUST NOT include History-Info in the response.
当发送除100以外的响应时，SIP实体必须在响应中包含所有缓存的hi条目，这要符合第10.1.2节中的隐私考虑，但以下例外情况除外：如果接收到的请求不包含hi条目，并且支持的标头字段中没有“histinfo”选项标记，SIP实体不得在响应中包含历史信息。
The following subsections describe the procedures for processing the History-Info header field. These procedures are applicable to SIP entities such as proxies/intermediaries, redirect servers, or user agents.
以下小节描述了处理历史信息标题字段的过程。这些过程适用于SIP实体，如代理/中介、重定向服务器或用户代理。
The privacy requirements for this document are described in Appendix A.2. Section 10.1.1 describes the insertion of the Privacy header field (defined in [RFC3323]) to indicate the privacy to be applied to the History-Info header field entries. Section 10.1.2 describes how to apply privacy to a request or response that is being forwarded, based on the presence of the Privacy header field.
本文件的隐私要求见附录A.2。第10.1.1节描述了隐私标题字段（定义见[RFC3323]）的插入，以指示应用于历史信息标题字段条目的隐私。第10.1.2节描述了如何根据privacy header字段的存在，将隐私应用于正在转发的请求或响应。
As with other SIP headers described in [RFC3323], the hi-targeted-to-uris in the History-Info header field can inadvertently reveal information about the initiator of the request. Thus, the UAC needs a mechanism to indicate that the hi-targeted-to-uris in the hi-entries need to be privacy protected. The Privacy header field is used by the UAC to indicate that privacy is to be applied to all the hi-entries in the request as follows:
与[RFC3323]中描述的其他SIP报头一样，历史信息报头字段中针对URI的hi可能会无意中泄露有关请求发起方的信息。因此，UAC需要一种机制来指示hi条目中以URI为目标的hi需要受到隐私保护。UAC使用Privacy header字段指示隐私将应用于请求中的所有hi条目，如下所示：
o If the UAC is including a Privacy header field with a priv-value of "header" in the request, then the UAC SHOULD NOT include a priv-value of "history" in the Privacy header field in the request.
o 如果UAC在请求中包含priv值为“header”的隐私标头字段，则UAC不应在请求的隐私标头字段中包含priv值为“history”。
o If the UAC is including any priv-values other than "header" in the Privacy header field, then the UAC MUST also include a priv-value of "history" in the Privacy header field in the request.
o 如果UAC在Privacy header字段中包含除“header”之外的任何priv值，则UAC还必须在请求的Privacy header字段中包含priv值“history”。
o If the UAC is not including any priv-values in the Privacy header field in the request, then the UAC MUST add a Privacy header field, with a priv-value of "history", to the request. The UAC MUST NOT include a priv-value of "critical" in the Privacy header field in the request in this case.
o 如果UAC在请求的隐私标头字段中未包含任何priv值，则UAC必须向请求添加priv值为“历史”的隐私标头字段。在这种情况下，UAC不得在请求的隐私标头字段中包含priv值“critical”。
In addition, the History-Info header field can reveal general routing and diverting information that is within an intermediary and that the intermediary wants to privacy protect. In this case, the intermediary MUST construct a Privacy header field with the single priv-value of "history" and include the Privacy header field in the hi-targeted-to-uri, for each new hi-entry created by the intermediary whose hi-targeted-to-uri it wishes to privacy protect. Note that the priv-value in the Privacy header for the incoming request does not necessarily influence whether the intermediary includes a Privacy header field in the hi-entries. For example, even if the Privacy header for the incoming request contained a priv-value of "none", the proxy can still set a priv-value of "history" in the Privacy header field included in the hi-targeted-to-uri.
此外，History Info header字段可以显示一般路由和转移信息，这些信息位于中间层内，并且中间层希望保护隐私。在这种情况下，对于中介创建的每个新hi条目，中介必须构造一个隐私头字段，该字段的单个priv值为“history”，并将隐私头字段包含在hi targeted to uri中，该hi条目由中介创建，其hi target to uri是其希望隐私保护的。请注意，传入请求的隐私头中的priv值不一定会影响中介在hi条目中是否包括隐私头字段。例如，即使传入请求的隐私头包含priv值“none”，代理仍然可以在hi目标uri中包含的隐私头字段中设置priv值“history”。
Finally, the UAS may not want to reveal the final reached target to the originator. In this case, the UAS MUST include a Privacy header field with a priv-value of "history" in the hi-targeted-to-uri in the last hi-entry, in the response. As noted above, the UAS of the request MUST NOT use any other priv-values in the Privacy header field included in the hi-entry.
最后，UAS可能不想向发起人透露最终达成的目标。在这种情况下，UAS必须在响应中最后一个hi条目的uri目标hi中包含priv值为“history”的Privacy header字段。如上所述，请求的UAS不得在hi条目中包含的隐私头字段中使用任何其他priv值。
When a SIP message is forwarded to a domain for which the SIP intermediary is not responsible, a Privacy Service at the boundary of the domain applies the appropriate privacy based on the value of the Privacy header field in the message header or in the "headers" component of the hi-targeted-to-uri in the individual hi-entries.
当SIP消息被转发到SIP中介不负责的域时，域边界处的隐私服务基于消息报头中的隐私报头字段的值或单个hi条目中针对uri的hi的“报头”组件中的隐私报头字段的值应用适当的隐私。
If there is a Privacy header field in the message header of a request or response, with a priv-value of "header" or "history", then all the hi-targeted-to-uris (in the hi-entries associated with the domain for which the SIP intermediary is responsible) are anonymized by the
如果在请求或响应的消息头中有priv值为“header”或“history”的Privacy header字段，则所有以URI为目标的hi（在与SIP中介负责的域相关联的hi条目中）都由
Privacy Service. The Privacy Service MUST change any hi-targeted-to-uris in these hi-entries that have not been anonymized (evidenced by their domain not being "anonymous.invalid") to anonymous URIs containing a domain of anonymous.invalid as recommended in Section 4.1.1.3 of [RFC3323]. As defined in Section 4.1.1.2 of [RFC3323], the recommendations of [RFC3261] for anonymizing the URI Username SHOULD be followed (i.e., "anonymous" in the user portion of the URI). If there is a Privacy header field in the "headers" component of the hi-targeted-to-uri in the hi-entries, then the Privacy header field value MUST be removed from the hi-entry. Once all the appropriate hi-entries have been anonymized, the Privacy Service MUST remove the priv-value of "history" from the Privacy header field in the message header of the request or response. If there are no remaining priv-values in the Privacy header field, the Privacy Service MUST remove the Privacy header field from the request or response per [RFC3323].
隐私服务。隐私服务必须按照[RFC3323]第4.1.1.3节中的建议，将这些hi条目中未匿名化（其域不是“anonymous.invalid”）的任何针对URI的hi更改为包含anonymous.invalid域的匿名URI。如[RFC3323]第4.1.1.2节所定义，应遵循[RFC3261]关于匿名化URI用户名的建议（即，URI用户部分中的“匿名”）。如果hi的“headers”组件中有一个针对hi条目中uri的Privacy header字段，则必须从hi条目中删除Privacy header字段值。一旦所有适当的hi条目都被匿名化，隐私服务必须从请求或响应的消息头的隐私头字段中删除priv值“history”。如果隐私标头字段中没有剩余的priv值，隐私服务必须根据[RFC3323]从请求或响应中删除隐私标头字段。
If there is not a Privacy header field in the message header of the request or response that is being forwarded, but there is a Privacy header field with a priv-value of "history" in the "headers" component in any of the hi-targeted-uris in the hi-entries associated with the domain for which a SIP intermediary is responsible, then the Privacy Service MUST update those hi-targeted-to-uris as described above. Any other priv-values in the Privacy header field in the "headers" component of the hi-targeted-to-uris in the hi-entries MUST be ignored. In any case, the Privacy Service MUST remove the Privacy header field from the "headers" component of the hi-targeted-to-uris in the hi-entries prior to forwarding.
如果正在转发的请求或响应的消息标头中没有隐私标头字段，但在与SIP中介负责的域关联的hi条目中的任何hi目标URI的“标头”组件中存在priv值为“history”的隐私标头字段，然后隐私服务必须如上所述更新那些针对URI的hi。必须忽略hi条目中针对URI的hi的“headers”组件中Privacy header字段中的任何其他priv值。在任何情况下，在转发之前，隐私服务必须从hi条目中针对URI的hi的“headers”组件中删除Privacy header字段。
A Reason header field is added when the hi-entry is added to the cache based upon the receipt of a SIP response that is neither a 100 nor a 2xx response, as described in Section 9.3. The SIP entity MUST include a Reason header field, containing the SIP Response Code, in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. In addition, if the response contains any Reason header fields (see [RFC3326]), then the SIP entity MUST also include the Reason header fields in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache.
如第9.3节所述，当基于接收到既不是100也不是2xx响应的SIP响应将hi条目添加到缓存时，将添加原因标头字段。SIP实体必须在添加到缓存的最后一个hi条目中的hi目标uri的“headers”组件中包含包含SIP响应代码的Reason header字段，除非hi目标uri是Tel uri。此外，如果响应包含任何原因头字段（请参见[RFC3326]），则SIP实体还必须在添加到缓存的最后一个hi条目中针对uri的hi的“头”组件中包含原因头字段。
If a request has timed out (instead of being explicitly rejected), the SIP entity MUST update the cache as if the request received a SIP error response code of 408 "Request Timeout".
如果请求已超时（而不是被明确拒绝），则SIP实体必须更新缓存，如同该请求接收到SIP错误响应代码408“请求超时”。
A request can receive multiple responses that are neither 100 nor 2xx responses and that carry or imply (for responses without Reason headers, and for timeouts) multiple, possibly duplicated, reason-values to be applied to an hi-targeted-to-uri. In these situations, the SIP entity creating the History-Info header value would choose the appropriate Reason header field value.
一个请求可以接收多个响应，这些响应既不是100响应，也不是2xx响应，并且携带或暗示（对于没有原因头的响应，以及对于超时）多个（可能重复的）原因值，以应用于针对uri的hi。在这些情况下，创建历史信息头值的SIP实体将选择适当的原因头字段值。
A SIP entity MAY also include a Reason header field (in the "headers" component of an hi-targeted-to-uri) that contains the URI of a request that was retargeted as a result of internal retargeting.
SIP实体还可以包括原因标头字段（在针对uri的hi的“标头”组件中），该字段包含由于内部重定目标而重定目标的请求的uri。
If additional Reason header field parameters are defined in the future per [RFC3326], the use of these Reason header field parameters for the History-Info header field MUST follow the same rules as described above.
如果将来根据[RFC3326]定义了其他原因标题字段参数，则历史信息标题字段使用这些原因标题字段参数必须遵循上述相同规则。
In order to maintain ordering and accurately reflect the retargeting of the request, the SIP entity MUST add an hi-index to each hi-entry. Per the syntax in Section 5, the hi-index consists of a series of nonnegative integers separated by dots (e.g., 1.1.2). Each dot reflects a SIP forwarding hop. The nonnegative integer following each dot reflects the order in which a request was retargeted at the hop. The highest nonnegative integer at each hop reflects the number of entities to which the request has been retargeted at the specific hop (i.e., the number of branches) at the time that the request represented by this hi-entry was generated. Thus, the indexing results in a logical tree representation for the history of the request and the hi-entries are given in the preorder of the tree.
为了保持顺序并准确反映请求的重定目标，SIP实体必须向每个hi条目添加hi索引。根据第5节中的语法，hi索引由一系列由点分隔的非负整数组成（例如，1.1.2）。每个点反映一个SIP转发跳。每个点后面的非负整数反映了请求在跃点处重定目标的顺序。每个跃点处的最高非负整数反映了在生成此hi条目表示的请求时，请求在特定跃点处被重定目标的实体数（即分支数）。因此，索引结果是请求历史的逻辑树表示，hi条目在树的前序中给出。
The first index in a series of History-Info entries MUST be set to 1. In the case that a SIP entity (intermediary or UAS) adds a first hi-entry on behalf of the previous hop, the hi-index MUST be set to 1. For each forward hop (i.e., each new level of indexing), the last integers of the hi-indexes of the new requests MUST be generated starting at 1 and incrementing by 1 for each additional request.
一系列历史信息条目中的第一个索引必须设置为1。如果SIP实体（中介或UAS）代表前一个跃点添加第一个hi条目，则hi索引必须设置为1。对于每个前向跃点（即，每个新的索引级别），必须从1开始生成新请求的hi索引的最后整数，并为每个附加请求递增1。
The basic rules for adding the hi-index are summarized as follows:
添加hi索引的基本规则总结如下：
1. Forwarding a request without changing the target: In the case of a request that is being forwarded without changing the target, the hi-index reflects the increasing length of the branch. In this case, the SIP entity MUST read the value from the History-Info header field in the received request and MUST add another level of indexing by appending the dot delimiter followed by an initial value of 1 for the new level. For example, if the
1. 在不更改目标的情况下转发请求：如果在不更改目标的情况下转发请求，则hi索引反映分支长度的增加。在这种情况下，SIP实体必须从接收到的请求中的History Info header字段中读取值，并且必须通过添加点分隔符（后跟新级别的初始值1）来添加另一级别的索引。例如，如果
hi-index in the last History-Info header field in the received request is 1.1, a proxy would add an hi-entry with an hi-index of 1.1.1 and forward the request.
收到的请求中最后一个历史信息头字段中的hi索引为1.1，代理将添加hi索引为1.1.1的hi条目并转发请求。
2. Retargeting within a processing entity - first instance: For the first instance of retargeting within a processing entity, the SIP entity MUST calculate the hi-index as prescribed for basic forwarding.
2. 处理实体内的重定目标-第一个实例：对于处理实体内重定目标的第一个实例，SIP实体必须按照基本转发的规定计算hi索引。
3. Retargeting within a processing entity - subsequent instance: For each subsequent retargeting of a request by the same SIP entity, the SIP entity MUST calculate and add the hi-index for each new branch by incrementing the rightmost value from the hi-index in the last hi-entry. Per the example above, the hi-index in the next request forwarded by this same SIP entity would be 1.1.2.
3. 处理实体内的重定目标-后续实例：对于同一SIP实体对请求的每次后续重定目标，SIP实体必须计算并添加每个新分支的hi索引，方法是从最后一个hi条目中的hi索引中增加最右边的值。根据上面的示例，该SIP实体转发的下一个请求中的hi索引将为1.1.2。
4. Retargeting based upon a response: In the case of retargeting due to a specific response (e.g., 302), the SIP entity MUST calculate the hi-index calculated per rule 3. That is, the rightmost value of the hi-index MUST be incremented (i.e., a new branch is created). For example, if the hi-index in the History-Info header field of the sent request is 1.2 and the response to the request is a 302, then the hi-index in the History-Info header field for the new hi-targeted-to-URI would be 1.3.
4. 基于响应的重定目标：在由于特定响应（例如302）而重定目标的情况下，SIP实体必须计算根据规则3计算的hi索引。也就是说，hi索引的最右边的值必须递增（即，创建一个新分支）。例如，如果发送的请求的历史信息头字段中的hi索引为1.2，并且对请求的响应为302，则针对URI的新hi的历史信息头字段中的hi索引将为1.3。
5. Forking requests: If the request forwarding is done in multiple forks (sequentially or in parallel), the SIP entity MUST set the hi-index for each hi-entry for each forked request per the rules above, with each new request having a unique index. Each index MUST be sequentially assigned. For example, if the index in the last History-Info header field in the received request is 1.1, this processing entity would initialize its index to 1.1.1 for the first fork, 1.1.2 for the second, and so forth. (See Figure 1 for an example.) Note that, in the case of parallel forking, only the hi-entry corresponding to the fork is included in the request because no response can yet have been received for any of the parallel forked requests.
5. 分叉请求：如果请求转发在多个分叉中完成（顺序或并行），SIP实体必须根据上述规则为每个分叉请求的每个hi条目设置hi索引，每个新请求都有一个唯一的索引。每个索引必须按顺序分配。例如，如果接收到的请求中的last History Info header字段中的索引为1.1，则此处理实体将第一个fork的索引初始化为1.1.1，第二个fork的索引初始化为1.1.2，依此类推。（参见图1中的示例。）注意，在并行分叉的情况下，请求中只包含对应于分叉的hi条目，因为尚未收到任何并行分叉请求的响应。
6. Missing entry: If the request clearly has a gap in the hi-entry (i.e., the last hi-entry and Request-URI differ), the entity adding an hi-entry MUST add a single index with a value of "0" (i.e., the nonnegative integer zero) prior to adding the appropriate index for the action to be taken. For example, if the index of the last hi-entry in the request received was 1.1.2 and there was a missing hi-entry and the request was being forwarded to the next hop, the resulting index will be 1.1.2.0.1. In the case of requests that are forked by a proxy that does not support History-Info, it is possible for hi-entries generated by
6. 缺少条目：如果请求在hi条目中明显存在间隙（即，最后一个hi条目和请求URI不同），则添加hi条目的实体必须在添加要执行的操作的适当索引之前添加一个值为“0”（即，非负整数零）的索引。例如，如果接收到的请求中最后一个hi条目的索引为1.1.2，并且缺少hi条目，并且请求被转发到下一个跃点，则生成的索引将为1.1.2.0.1。如果请求由不支持历史记录信息的代理分叉，则可能由生成hi条目
different entities to have the same index, i.e., each entity supporting History-Info would receive a forked request with the same hi-index to which they would add the value of ".0" prior to adding the appropriate index. Thus, in the previous example, each of the next-hop entities would generate an hi-index of 1.1.2.0.1.
不同实体具有相同的索引，即，每个支持历史信息的实体将收到具有相同hi索引的分叉请求，在添加适当的索引之前，它们将向该索引添加值“.0”。因此，在前面的示例中，每个下一跳实体将生成1.1.2.0.1的hi索引。
10.4. Mechanism for Target Determination in the History-Info Header Field
10.4. 历史信息标题字段中的目标确定机制
This specification defines three header field parameters, "rc", "mp", and "np". The header field parameters "rc" and "mp" indicate the mechanism by which a new target for a request is determined. The header field "np" reflects that the target has not changed. All parameters contain an index whose value is the hi-index of the hi-entry with an hi-targeted-to-uri that represents the Request-URI that was retargeted.
本规范定义了三个标题字段参数，“rc”、“mp”和“np”。标头字段参数“rc”和“mp”表示确定请求新目标的机制。标题字段“np”反映目标未更改。所有参数都包含一个索引，其值是hi项的hi索引，hi的目标uri表示重定目标的请求uri。
The SIP entity MUST determine the specific parameter field to be included in the hi-target-param, in the History-Info header field, as the targets are added to the target set per the procedures in Section 16.5 of [RFC3261] or per Section 8.1.3.4 of [RFC3261] in the case of retargeting to a Contact URI received in a 3xx response. In the latter case, the specific header field parameter in the Contact header field becomes the header field parameter that is used in the hi-entry when the request is retargeted. If the Contact header field does not contain an "rc" or "mp" header field parameter, then the SIP entity MUST NOT include an "rc" or "mp" header field parameter in the hi-target-param in the hi-entry when the request is retargeted to a Contact URI received in a 3xx response. This is because the redirect server is the only element with any knowledge on how the target was determined. Note that the "np" header field parameter is not applicable in the case of redirection.
根据[RFC3261]第16.5节中的程序或[RFC3261]第8.1.3.4节中的程序将目标添加到目标集时，SIP实体必须在历史信息标题字段中确定hi target param中要包含的特定参数字段，如果目标是在3xx响应中接收的联系人URI。在后一种情况下，Contact header字段中的特定header字段参数成为重定目标请求时hi条目中使用的header字段参数。如果Contact header字段不包含“rc”或“mp”header字段参数，则当请求重定目标为3xx响应中接收的联系人URI时，SIP实体不得在hi条目的hi目标参数中包含“rc”或“mp”header字段参数。这是因为重定向服务器是唯一知道如何确定目标的元素。请注意，“np”头字段参数在重定向的情况下不适用。
Based on the following criteria, the SIP entity (intermediary or redirect server) determines the specific header field parameter ("rc", "mp", or "np") to be used.
根据以下标准，SIP实体（中间或重定向服务器）确定要使用的特定头字段参数（“rc”、“mp”或“np”）。
o "rc": The Request-URI has changed while the target user associated with the original Request-URI prior to retargeting has been retained.
o “rc”：请求URI已更改，而在重定目标之前与原始请求URI关联的目标用户已保留。
o "mp": The target was determined based on a mapping to a user other than the target user associated with the Request-URI being retargeted.
o “mp”：目标是根据与被重定目标的请求URI关联的目标用户以外的用户的映射确定的。
o "np": The target hasn't changed, and the associated Request-URI remained the same.
o “np”：目标没有改变，关联的请求URI保持不变。
Note that there are two scenarios by which the "mp" header field parameter can be derived.
请注意，有两种情况可以派生“mp”头字段参数。
o The mapping was done by the receiving entity on its own authority, in which case the mp-value is the parent index of the hi-entry's index.
o 映射是由接收实体根据自己的权限完成的，在这种情况下，mp值是hi条目索引的父索引。
o The mapping was done due to receiving a 3xx response, in which case the mp-value is an earlier sibling or descendant of an earlier sibling of the hi-entry's index; the index is that of the downstream request that received the 3xx response.
o 由于接收到3xx响应而完成映射，在这种情况下，mp值是hi条目索引的早期同级或后代；索引是接收3xx响应的下游请求的索引。
History-Info provides a very flexible building block that can be used by intermediaries and UAs for a variety of services. Prior to any application usage of the History-Info header field parameters, the SIP entity that processes the hi-entries MUST evaluate the hi-entries and determine if there are any gaps in the hi-entries. The SIP entity MUST be prepared to process effectively messages whose hi-entries show evidence of "gaps", that is, situations that reveal that not all of the forks of the request have been recorded in the hi-entries. Gaps are possible if the request is forwarded through intermediaries that do not support the History-Info header field and are reflected by the existence of hi-entries with a nonnegative integer of "0", e.g., "1.1.0.1". Gaps are also possible in the case of parallel forking if there is an outstanding request at the time the SIP entity sends a message. In addition, gaps may introduce the possibility of duplicate values for the hi-index in the case that a proxy that does not support History-Info forks a request. If gaps are detected, the SIP entity MUST NOT treat this as an error but SHOULD indicate to any applications that there are gaps. The interpretation of the information in the History-Info header field depends upon the specific application; an application might need to provide special handling in some cases where there are gaps.
历史信息提供了一个非常灵活的构建块，可供中介机构和UAs用于各种服务。在应用程序使用历史信息头字段参数之前，处理hi条目的SIP实体必须评估hi条目，并确定hi条目中是否存在任何间隙。SIP实体必须准备好有效地处理hi条目显示“间隙”证据的消息，即表明并非所有请求分支都已记录在hi条目中的情况。如果请求通过不支持History Info header字段的中介转发，并且通过存在非负整数为“0”（例如“1.1.0.1”）的hi条目来反映，则可能存在间隙。如果在SIP实体发送消息时存在未完成的请求，则在并行分叉的情况下也可能存在间隙。此外，在不支持历史信息的代理分叉请求的情况下，间隙可能会引入hi索引重复值的可能性。如果检测到间隙，SIP实体不得将其视为错误，但应向任何应用程序指示存在间隙。历史信息标题字段中信息的解释取决于具体应用；在某些存在间隙的情况下，应用程序可能需要提供特殊处理。
The following describes some categories of information that applications can use:
以下介绍了应用程序可以使用的某些类别的信息：
1. Complete history information, e.g., for debugging or other operational and management aspects, optimization of determining targets to avoid retargeting to the same URI, etc. This information is relevant to proxies, UACs, and UASs.
1. 完整的历史信息，例如，用于调试或其他操作和管理方面，优化确定目标以避免重定目标到同一URI等。此信息与代理、UAC和UAS相关。
2. Hi-entry with the index that matches the value of the "rc" header field parameter in the last hi-entry with an "rc" header field parameter in the request received by a UAS, i.e., the last AOR that was retargeted to a contact based on an AOR-to-contact binding.
2. Hi条目，其索引与UAS接收的请求中的“rc”头字段参数的“rc”头字段参数的值相匹配，即，根据AOR到联系人绑定重新定位到联系人的最后一个AOR。
3. Hi-entry with the index that matches the value of the "mp" header field parameter in the last hi-entry with an "mp" header field parameter in the hi-target-param in the request received by a UAS, i.e., the last Request-URI that was mapped to reach the destination.
3. Hi条目，其索引与UAS接收的请求中的Hi目标参数中的“mp”头字段参数与最后一个Hi条目中的“mp”头字段参数的值相匹配，即映射到目标的最后一个请求URI。
4. Hi-entry with the index that matches the value of the "rc" header field parameter in the first hi-entry with an "rc" header field parameter in the request received by a UAS. Note that this would be the original AOR if all the entities involved support the History-Info header field and there is an absence of an "mp" header field parameter prior to the "rc" header field parameter in the hi-target-param in the History-Info header field. However, there is no guarantee that all entities will support History-Info; thus, the hi-entry that matches the value of the "rc" header field parameter of the first hi-entry with an "rc" header field parameter in the hi-target-param within the domain associated with the target URI at the destination is more likely to be useful.
4. Hi条目，其索引与UAS接收的请求中的“rc”头字段参数的“rc”头字段参数的值相匹配。请注意，如果所有涉及的实体都支持历史信息标题字段，并且历史信息标题字段的hi目标参数中的“rc”标题字段参数之前没有“mp”标题字段参数，则这将是原始AOR。但是，不能保证所有实体都支持历史信息；因此，在与目的地的目标URI相关联的域中，将第一hi条目的“rc”头字段参数的值与hi目标参数中的“rc”头字段参数相匹配的hi条目更有可能是有用的。
5. Hi-entry with the index that matches the value of the "mp" header field parameter in the first hi-entry with an "mp" header field parameter in the request received by a UAS. Note that this would be the original mapped URI if all entities supported the History-Info header field. However, there is no guarantee that all entities will support History-Info; thus, the hi-entry that matches the value of the "mp" header field parameter of the first hi-entry with an "mp" header field parameter within the domain associated with the target URI at the destination is more likely to be useful.
5. Hi条目，其索引与UAS接收的请求中的“mp”头字段参数与第一个Hi条目中的“mp”头字段参数的值相匹配。请注意，如果所有实体都支持历史信息头字段，则这将是原始映射URI。但是，不能保证所有实体都支持历史信息；因此，将第一个hi条目的“mp”头字段参数的值与与与目的地的目标URI相关联的域中的“mp”头字段参数相匹配的hi条目更有可能是有用的。
In many cases, applications are most interested in the information within one or more particular domains; thus, only a subset of the information is required.
在许多情况下，应用程序对一个或多个特定域中的信息最感兴趣；因此，只需要信息的一个子集。
Some applications may use multiple types of information. For example, an Automatic Call Distribution (ACD) / call center application that utilizes the hi-entry with an index that matches the value of the "mp" header field parameter in the first hi-entry with an "mp" header field parameter may also display other agents, reflected by hi-entries prior to hi-entries with an "rc" header field parameter, to whom the call was targeted prior to its arrival at the
某些应用程序可能使用多种类型的信息。例如，自动呼叫分配（ACD）/呼叫中心应用程序利用hi条目，该条目的索引与第一个hi条目中的“mp”标题字段参数值与“mp”标题字段参数值相匹配，该应用程序也可以显示其他代理，由hi条目在hi条目之前与“rc”标题字段参数反映，在电话到达目的地之前，其目标是谁
current agent. This could allow the agent the ability to decide how they might forward or reroute the call if necessary (avoiding agents that were not previously available for whatever reason, etc.).
当前代理。这可以让代理决定在必要时如何转发或重新路由呼叫（避免使用以前因任何原因不可用的代理，等等）。
Since support for History-Info header field is optional, a service MUST define default behavior for requests and responses not containing History-Info header fields. For example, an entity may receive an incomplete set of hi-entries or hi-entries that are not tagged appropriately with an hi-target-param in the case of entries added by entities that are only compliant to RFC 4244. This may not impact some applications (e.g., debug); however, it could require some applications to make some default assumptions in this case. For example, in an ACD scenario, the application could select the oldest hi-entry with the domain associated with the ACD system and display that as the original called party. Depending upon how and where the request may have been retargeted, the complete list of agents to whom the call was targeted may not be available.
由于对历史信息头字段的支持是可选的，因此服务必须为不包含历史信息头字段的请求和响应定义默认行为。例如，实体可能会收到一组不完整的hi条目，或者在实体添加的条目仅符合RFC 4244的情况下，未使用hi目标参数适当标记的hi条目。这可能不会影响某些应用程序（例如调试）；但是，在这种情况下，可能需要一些应用程序做出一些默认假设。例如，在ACD场景中，应用程序可以选择与ACD系统关联的域中最早的hi条目，并将其显示为原始被叫方。根据请求的重定目标方式和位置，呼叫的目标代理的完整列表可能不可用。
The following are possible (non-normative) application-specific usages of History-Info.
以下是历史信息的可能（非规范）应用程序特定用法。
A voicemail system (VMS) typically requires the original called party information to determine the appropriate mailbox so an appropriate greeting can be provided and the appropriate party notified of the message.
语音邮件系统（VMS）通常需要原始被叫方信息来确定适当的邮箱，以便提供适当的问候语，并将消息通知适当的被叫方。
The original target is determined by finding the first hi-entry tagged with "rc" and using the hi-entry referenced by the index of the "rc" header field parameter as the target for determining the appropriate mailbox. This hi-entry is used to populate the "target" URI parameter as defined in [RFC4458]. The VMS can look at the last hi-entry and find the target of the mailbox by looking at the URI entry in the "target" URI parameter in the hi-entry.
通过查找标记为“rc”的第一个hi条目，并使用“rc”头字段参数的索引引用的hi条目作为确定适当邮箱的目标，来确定原始目标。此hi条目用于填充[RFC4458]中定义的“target”URI参数。VM可以查看最后一个hi条目，并通过查看hi条目中“target”URI参数中的URI条目找到邮箱的目标。
This example usage does not work properly in the presence of forwarding that takes place before the call reaches the company. In that case, not the first hi-entry with an "rc" value, but the first hi-entry with an "rc" value following an "mp" entry needs to be picked. Further detail for this example can be found in the call flow entitled "PBX Voicemail Example" in [CALLFLOWS].
此示例用法在呼叫到达公司之前发生的转发情况下无法正常工作。在这种情况下，需要拾取的不是第一个具有“rc”值的hi条目，而是在“mp”条目之后具有“rc”值的第一个hi条目。有关此示例的更多详细信息，请参见[CALLFLOWS]中标题为“PBX语音邮件示例”的呼叫流。
Note that in the case where there is no entry tagged with "rc", a VMS can follow the procedures, as defined in [RFC4458], for the "Interaction with Request History Information".
注意，在没有标记为“rc”的条目的情况下，VMS可以遵循[RFC4458]中定义的“与请求历史信息的交互”程序。
The voicemail system in this environment typically requires the last called party information to determine the appropriate mailbox so an appropriate greeting can be provided and the appropriate party notified of the message.
此环境中的语音邮件系统通常需要最后被叫方信息来确定适当的邮箱，以便可以提供适当的问候语并将消息通知适当的一方。
The last target is determined by finding the hi-entry referenced by the index of the last hi-entry tagged with "rc" for determining the appropriate mailbox. This hi-entry is used to populate the "target" URI parameter as defined in [RFC4458]. The VMS can look at the last hi-entry and find the target of the mailbox by looking for the "target" URI parameter in the hi-entry. Further detail for this example can be found in the call flow entitled "Consumer Voicemail Example" in [CALLFLOWS].
最后一个目标是通过查找由标记为“rc”的最后一个hi条目的索引引用的hi条目来确定的，以确定适当的邮箱。此hi条目用于填充[RFC4458]中定义的“target”URI参数。VM可以查看最后一个hi条目，并通过在hi条目中查找“target”URI参数来查找邮箱的目标。有关此示例的更多详细信息，请参见[CALLFLOWS]中标题为“消费者语音邮件示例”的呼叫流。
In the case where there is no entry tagged with "rc", a VMS can follow the procedures, as defined in [RFC4458], for the "Interaction with Request History Information".
在没有标记为“rc”的条目的情况下，VMS可以按照[RFC4458]中定义的程序进行“与请求历史信息的交互”。
The security requirements for this specification are specified in Appendix A.1.
本规范的安全要求见附录A.1。
This document defines a header field for SIP. The use of the Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the overall confidentiality of the History-Info header fields (SEC-req-4) is strongly RECOMMENDED. If TLS is NOT used, the intermediary MUST ensure that the messages are only sent within an environment that is secured by other means or that the messages don't leave the intermediary's domain. This results in History-Info's having at least the same level of security as other headers in SIP that are inserted by intermediaries. With TLS, History-Info header fields are no less, nor no more, secure than other SIP header fields, which generally have even more impact on the subsequent processing of SIP sessions than the History-Info header field.
本文档定义了SIP的标题字段。强烈建议使用传输层安全（TLS）协议[RFC5246]作为一种机制，以确保历史信息头字段（SEC-req-4）的整体机密性。如果未使用TLS，则中间层必须确保消息仅在通过其他方式保护的环境中发送，或者消息不会离开中间层的域。这导致历史信息的安全级别至少与中介插入的SIP中的其他头相同。使用TLS时，历史信息头字段的安全性不低于或不高于其他SIP头字段，这通常比历史信息头字段对SIP会话的后续处理有更大的影响。
Note that while using the SIPS scheme (as per [RFC5630]) protects History-Info from tampering by arbitrary parties outside the SIP message path, all the intermediaries on the path are trusted implicitly. A malicious intermediary could arbitrarily delete, rewrite, or modify History-Info. This specification does not attempt to prevent or detect attacks by malicious intermediaries.
注意，当使用SIPS方案（根据[RFC5630]）保护历史信息不被SIP消息路径之外的任意方篡改时，该路径上的所有中介都受到隐式信任。恶意中介可以任意删除、重写或修改历史信息。本规范不试图防止或检测恶意中介的攻击。
In terms of ensuring the privacy of hi-entries, the same security considerations as those described in [RFC3323] apply. The Privacy Service that's defined in [RFC3323] MUST also support the new Privacy header field priv-value of "history" and anonymize hi-entries in the case of a priv-value of "header" as described in Section 10.1.2.
在确保hi条目的隐私方面，与[RFC3323]中描述的安全注意事项相同。[RFC3323]中定义的隐私服务还必须支持新的隐私标头字段priv value“history”，并在priv value为“header”的情况下匿名化hi条目，如第10.1.2节所述。
IANA registrations have been implemented or updated as detailed in the following subsections.
IANA注册已实施或更新，详见以下小节。
This document obsoletes [RFC4244] but uses the same SIP header field name, Privacy header field, and Option tag. References to [RFC4244] in the IANA "Session Initiation Protocol (SIP) Parameters" registry (<http://www.iana.org/assignments/sip-parameters>) have been replaced with references to this document.
本文档废弃[RFC4244]，但使用相同的SIP头字段名称、隐私头字段和选项标记。IANA“会话启动协议（SIP）参数”注册表中对[RFC4244]的引用(<http://www.iana.org/assignments/sip-parameters>)已替换为对本文件的引用。
This document defines a SIP header field name, History-Info; and an option tag, histinfo. The following updates have been made to <http://www.iana.org/assignments/sip-parameters>.
本文档定义了SIP头字段名、历史信息；还有一个选项标签histinfo。已对进行了以下更新：<http://www.iana.org/assignments/sip-parameters>.
The following row has been updated in the "Header Fields" sub-registry:
“标题字段”子注册表中的以下行已更新：
Header Name Compact Form Reference
----------- ------------ ---------
History-Info none [RFC7044]
Header Name Compact Form Reference
----------- ------------ ---------
History-Info none [RFC7044]
The following has been updated in the "Option Tags" sub-registry:
“选项标签”子注册表中已更新以下内容：
Name Description Reference
---- ----------- ---------
histinfo When used with the Supported header field, [RFC7044]
this option tag indicates the UAC supports
the History Information to be captured for
requests and returned in subsequent
responses. This tag is not used in a
Proxy-Require or Require header field,
since support of History-Info is optional.
Name Description Reference
---- ----------- ---------
histinfo When used with the Supported header field, [RFC7044]
this option tag indicates the UAC supports
the History Information to be captured for
requests and returned in subsequent
responses. This tag is not used in a
Proxy-Require or Require header field,
since support of History-Info is optional.
This document defines a priv-value for the SIP Privacy header field: history. The following updates have been made to the "SIP Privacy Header Field Values" sub-registry in <http://www.iana.org/assignments /sip-parameters> for the registration of the SIP Privacy header field:
本文档为SIP隐私头字段定义priv值：历史。对中的“SIP隐私头字段值”子注册表进行了以下更新<http://www.iana.org/assignments /sip参数>用于注册sip隐私标头字段：
Privacy
Type Description Registrant Reference
------ ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC7044]
History-Info header mary.ietf.barnes@gmail.com
field(s)
Privacy
Type Description Registrant Reference
------ ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC7044]
History-Info header mary.ietf.barnes@gmail.com
field(s)
This specification defines the following new SIP header field parameters in the "Header Field Parameters and Parameter Values" sub-registry in <http:/www.iana.org/assignments/sip-parameters>.
本规范在<http:/www.iana.org/assignments/SIP parameters>中的“header field parameters and Parameter Values”子注册表中定义了以下新的SIP头字段参数。
Header Field Parameter Name Predefined Values Reference
------------- -------------- ----------------- ---------
History-Info mp No [RFC7044]
History-Info rc No [RFC7044]
History-Info np No [RFC7044]
Contact mp No [RFC7044]
Contact rc No [RFC7044]
Contact np No [RFC7044]
Header Field Parameter Name Predefined Values Reference
------------- -------------- ----------------- ---------
History-Info mp No [RFC7044]
History-Info rc No [RFC7044]
History-Info np No [RFC7044]
Contact mp No [RFC7044]
Contact rc No [RFC7044]
Contact np No [RFC7044]
Jonathan Rosenberg et al. produced the document that provided additional use cases precipitating the requirement for the new header parameters to capture the method by which a Request-URI is determined. The authors would like to acknowledge the constructive feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel Kaplan, Marianne Mohali, Brett Tate, and Dale Worley. John Elwell also provided excellent suggestions in terms of document structure. Dan Romascanu performed the Gen-ART review.
Jonathan Rosenberg等人编写了一份文档，其中提供了额外的用例，促使人们需要新的头参数来捕获确定请求URI的方法。作者要感谢Ian Elz、Paul Kyzivat、John Elwell、Hadriel Kaplan、Marianne Mohali、Brett Tate和Dale Worley提供的建设性反馈。John Elwell还在文档结构方面提供了极好的建议。Dan Romascanu主持了Gen艺术评论。
Mark Watson, Cullen Jennings, and Jon Peterson provided significant input into the initial work that resulted in the development of [RFC4244]. The authors would like to acknowledge the constructive feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin
马克·沃森、卡伦·詹宁斯和乔恩·彼得森为开发[RFC4244]的初始工作提供了重要的投入。作者希望感谢罗伯特·斯帕克斯、保罗·基齐瓦特、斯科特·奥尔顿、约翰·埃尔威尔、Nir陈、帕拉什·贾恩、布赖恩·斯图克、诺玛·吴、安东尼·布朗、杰瑞·巴拉蒂亚、乔纳森·罗森博格、埃里克·伯格、马丁提供的建设性反馈
Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and Sebastien Garcin in the development of [RFC4244].
Dolly、Roland Jeske、Takuya Sawada、Sebastien Prouvost和Sebastien Garcin参与[RFC4244]的开发。
The authors would like to acknowledge the significant input from Rohan Mahy on some of the normative aspects of the ABNF for [RFC4244], particularly regarding security and the index (the need for it as well as its format).
作者希望感谢Rohan Mahy对[RFC4244]ABNF的一些规范性方面的重要投入，特别是关于安全性和索引（对它的需求及其格式）。
This RFC replaces [RFC4244].
本RFC取代[RFC4244]。
Deployment experience with [RFC4244] over the years has shown a number of issues, warranting an update:
多年来[RFC4244]的部署经验表明存在许多问题，需要更新：
o In order to make [RFC4244] work in "real life", one needs to make "assumptions" on how History-Info is used. For example, numerous implementations filter out many entries and only leave specific entries corresponding, for example, to first and last redirection. Since vendors use different rules, this causes significant interoperability issues.
o 为了使[RFC4244]在“现实生活”中工作，需要对历史信息的使用方式进行“假设”。例如，许多实现过滤掉许多条目，只留下与第一个和最后一个重定向相对应的特定条目。由于供应商使用不同的规则，这会导致严重的互操作性问题。
o [RFC4244] is overly permissive and evasive about recording entries, causing interoperability issues.
o [RFC4244]对记录条目过于宽容和回避，导致互操作性问题。
o The examples in the call flows had errors and were confusing because they often assume "loose routing".
o 调用流中的示例有错误，令人困惑，因为它们通常假设“松散路由”。
o [RFC4244] has lots of repetitive and unclear text due to the combination of requirements with the solution.
o [RFC4244]由于需求与解决方案的结合，有大量重复和不清楚的文本。
o [RFC4244] gratuitously mandates the use of TLS on every hop. No existing implementation enforces this rule, and instead, whether to use TLS is a general SIP issue, not an issue with [RFC4244] per se.
o [RFC4244]免费要求在每个跃点上使用TLS。没有任何现有的实现强制执行此规则，相反，是否使用TLS是一个一般的SIP问题，而不是[RFC4244]本身的问题。
o [RFC4244] does not include clear procedures on how to deliver current target URI information to the UAS when the Request-URI is replaced with a contact.
o [RFC4244]未包括当请求URI替换为联系人时如何向UAS传递当前目标URI信息的明确程序。
o [RFC4244] does not allow for marking History-Info entries for easy processing by user agents.
o [RFC4244]不允许标记历史信息条目以便于用户代理处理。
The following summarizes the functional changes between this specification and [RFC4244]:
以下总结了本规范与[RFC4244]之间的功能变化：
1. Added header field parameters to capture the specific method by which a target is determined to facilitate processing by users of the History-Info header field entries. A specific header field parameter is captured for each of the target URIs as the target set is determined (per Section 16.5 of [RFC3261]). The header field parameter is used in both the History-Info and the Contact header fields.
1. 添加了标题字段参数，以捕获确定目标的特定方法，以便于用户处理历史信息标题字段条目。在确定目标集时（根据[RFC3261]第16.5节），为每个目标URI捕获特定的标头字段参数。header字段参数用于历史信息和联系人标题字段。
2. Added a way to indicate a gap in History-Info by adding a nonnegative integer of "0".
2. 添加了一种通过添加非负整数“0”来指示历史信息中的差距的方法。
3. Rather than recommending that entries be removed in the case of certain values of the Privacy header field, the entries are anonymized.
3. 对于隐私头字段的某些值，不建议删除条目，而是将条目匿名化。
4. Updated the security section to be equivalent to the security recommendations for other SIP header fields inserted by intermediaries.
4. 将安全部分更新为与中介插入的其他SIP头字段的安全建议等效。
5. Removed Appendix B ("Voicemail") since a separate call flow document is being published as a companion to this document.
5. 删除了附录B（“语音邮件”），因为单独的呼叫流程文档作为本文档的附件发布。
The first two changes are intended to facilitate application usage of the History-Info header field and eliminate the need to make assumptions based upon the order of the entries and ensure that the most complete set of information is available to the applications.
前两个更改旨在促进应用程序使用历史信息标题字段，消除根据条目顺序进行假设的需要，并确保应用程序可以使用最完整的信息集。
In addition, editorial changes were done to both condense and clarify the text, moving the requirements to an appendix and removing the inline references to the requirements. The examples were simplified and updated to reflect the protocol changes. Several of the call flows in the appendix were removed and put into a separate document that includes additional use cases that require the new header field parameters.
此外，还进行了编辑性修改，以精简和澄清文本，将需求移至附录，并删除对需求的内联引用。对示例进行了简化和更新，以反映协议的变化。附录中的几个调用流被删除并放入一个单独的文档中，该文档包括需要新的头字段参数的其他用例。
This specification is backwards compatible because [RFC4244] allows for the addition of new optional parameters. This specification adds an optional SIP header field parameter to the History-Info and Contact header fields. Entities that have not implemented this specification will ignore these parameters; however, per [RFC4244], an entity will not remove these parameters from an hi-entry. While entities compliant to this document and [RFC4244] must be able to recognize gaps in the hi-entries, this document requires that an
此规范向后兼容，因为[RFC4244]允许添加新的可选参数。此规范向历史信息和联系人标头字段添加可选的SIP标头字段参数。未实施本规范的实体将忽略这些参数；但是，根据[RFC4244]，实体不会从hi条目中删除这些参数。虽然符合本文件和[RFC4244]的实体必须能够识别hi条目中的缺口，但本文件要求
index of "0" be used in this case. In comparison, [RFC4244] recommended (but did not require) the use of "1". However, since the ABNF in [RFC4244] defines the index as a DIGIT, "0" would be a valid value; thus, an [RFC4244] implementation should not have an issue if it receives hi-entries added by intermediaries compliant to this document.
在这种情况下，将使用索引“0”。相比之下，[RFC4244]建议（但不要求）使用“1”。然而，由于[RFC4244]中的ABNF将索引定义为一个数字，“0”将是一个有效值；因此，[RFC4244]实现如果接收到由符合本文档的中介添加的hi条目，则不应出现问题。
As for the behavior of the UACs, UASs, and intermediaries, the following additional normative changes have been made:
对于UAC、UAS和中介机构的行为，已经进行了以下额外的规范性变更：
UAC behavior
UAC行为
1. Inclusion of option tag by UAC has changed from SHOULD to MUST.
1. UAC包含的选项标签已从“应该”更改为“必须”。
2. Inclusion of hi-target-entry along with hi-index has changed from MAY/RECOMMEND to MUST/MUST.
2. hi目标条目和hi索引的包含已从五月/推荐更改为必须/必须。
3. Behavior surrounding the addition of hi-target-entry based on a 3xx response has changed from MAY/SHOULD to MUST.
3. 基于3xx响应添加hi目标条目的行为已从五月/应当更改为必须。
None of the behavior changes will cause any backward or forward compatibility issues.
所有行为更改都不会导致任何向后或向前兼容性问题。
UAS behavior
无人机行为
1. Inclusion of hi-entry in response has changed from SHOULD to MUST.
1. 响应中包含的hi条目已从“应该”更改为“必须”。
As the entity receiving response with hi-entry expected it with SHOULD, this change will not cause any backward compatibility issues.
由于接收具有hi条目的响应的实体应具有hi条目，因此此更改不会导致任何向后兼容性问题。
Proxy/redirect server behavior
代理/重定向服务器行为
1. Inclusion of the History-Info header field when forwarding the request has changed from SHOULD to MUST.
1. 转发请求时包含的历史信息标头字段已从“应”更改为“必须”。
2. Association of Reason with timeout/internal reason has changed from MAY to MUST.
2. 原因与超时/内部原因的关联已从五月更改为必须。
3. Inclusion of hi-index has changed from RECOMMENDED to MUST.
3. hi索引的包含已从建议更改为必须。
4. Inclusion of hi-entries in the response has changed from SHOULD to MUST.
4. 响应中包含的hi条目已从“应该”更改为“必须”。
None of the above behavior changes impact backwards compatibility since they only strengthen normative behavior to improve interoperability.
上述行为更改都不会影响向后兼容性，因为它们只会加强规范行为以提高互操作性。
In cases where an entity that is compliant to this document receives a request that contains hi-entries compliant only to RFC 4244 (i.e., the hi-entries do not contain any of the new header field parameters), the entity MUST NOT add any of the new header field parameters to the hi-entries. The hi-entries MUST be cached and forwarded as any other entries are, as specified in Section 9.1. As with entities that are compliant to RFC 4244, applications must be able to function in cases of missing information, as specified in Section 11.
如果符合本文档要求的实体收到的请求包含仅符合RFC 4244要求的hi条目（即hi条目不包含任何新的标题字段参数），则该实体不得向hi条目添加任何新的标题字段参数。根据第9.1节的规定，hi条目必须像任何其他条目一样进行缓存和转发。与符合RFC 4244的实体一样，应用程序必须能够在信息缺失的情况下运行，如第11节所述。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[RFC3326]Schulzrinne，H.，Oran，D.，和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC 3326，2002年12月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244]Barnes，M.，“请求历史信息会话启动协议（SIP）的扩展”，RFC 4244，2005年11月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，2009年10月。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630]Audet，F.“会话启动协议（SIP）中SIPS URI方案的使用”，RFC 5630，2009年10月。
[RFC3087] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
[RFC3087]Campbell，B.和R.Sparks，“使用SIP请求URI控制服务上下文”，RFC 3087，2001年4月。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240]Burger，E.，Van Dyke，J.，和A.Spitzer，“具有SIP的基本网络媒体服务”，RFC 42402005年12月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006.
[RFC4458]Jennings，C.，Audet，F.，和J.Elwell，“语音邮件和交互式语音应答（IVR）等应用程序的会话启动协议（SIP）URI”，RFC 4458，2006年4月。
[CALLFLOWS] Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. Holmberg, "Session Initiation Protocol (SIP) History-Info Header Call Flow Examples", Work in Progress, November 2013.
[CALLFLOWS]Barnes，M.，Audet，F.，Schubert，S.，Elburg，H.，和C.Holmberg，“会话启动协议（SIP）历史信息头呼叫流示例”，正在进行的工作，2013年11月。
The following list constitutes a set of requirements for a "Request History" capability.
以下列表构成了“请求历史记录”功能的一组需求。
1. CAPABILITY-req: The "Request History" capability provides a capability to inform proxies and UAs involved in processing a request about the history/progress of that request. Although this is inherently provided when the retarget is in response to a SIP redirect, it is deemed useful for non-redirect retargeting scenarios, as well.
1. 能力需求：“请求历史记录”能力提供了将请求的历史记录/进度通知参与处理请求的代理和UAs的能力。虽然这是在重定目标响应SIP重定向时固有地提供的，但它被认为对于非重定向重定目标场景也是有用的。
2. GENERATION-req: "Request History" information is generated when the request is retargeted.
2. 生成请求：重新定位请求时生成“请求历史记录”信息。
A. In some scenarios, it might be possible for more than one instance of retargeting to occur within the same proxy. A proxy MUST also generate "Request History" information for the 'internal retargeting'.
A.在某些情况下，可能会在同一代理中发生多个重定目标实例。代理还必须为“内部重定目标”生成“请求历史记录”信息。
B. An entity (UA or proxy) retargeting in response to a redirect or REFER MUST include any "Request History" information from the redirect/REFER in the new request.
B.响应重定向或引用的实体（UA或代理）重定目标必须包括新请求中重定向/引用的任何“请求历史”信息。
3. ISSUER-req: "Request History" information can be generated by a UA or proxy. It can be passed in both requests and responses.
3. 发卡机构请求：“请求历史记录”信息可由UA或代理生成。它可以在请求和响应中传递。
4. CONTENT-req: The "Request History" information for each occurrence of retargeting shall include the following:
4. 内容请求：每次重定目标的“请求历史”信息应包括以下内容：
A. the new URI or address to which the request is in the process of being retargeted,
A.请求正被重定目标的新URI或地址，
B. the URI or address from which the request was retargeted, and whether the retarget URI was an AOR,
B.请求重定目标的URI或地址，以及重定目标URI是否为AOR，
C. the mechanism by which the new URI or address was determined,
C.确定新URI或地址的机制，
D. the reason for the Request-URI or address modification, and
D.请求URI或地址修改的原因，以及
E. chronological ordering of the "Request History" information.
E.“请求历史记录”信息的时间顺序。
5. REQUEST-VALIDITY-req: "Request History" is applicable to requests not sent within an early or established dialog (e.g., INVITE, REGISTER, MESSAGE, and OPTIONS).
5. 请求有效性请求：“请求历史记录”适用于未在早期或已建立的对话框中发送的请求（例如，邀请、注册、消息和选项）。
6. BACKWARDS-req: "Request History" information may be passed from the generating entity backwards towards the UAC. This is needed to enable services that inform the calling party about the dialog establishment attempts.
6. 向后请求：“请求历史记录”信息可以从生成实体向后传递到UAC。这是启用通知呼叫方对话建立尝试的服务所必需的。
7. FORWARDS-req: "Request History" information may also be included by the generating entity in the request, if it is forwarded onwards.
7. 转发请求：“请求历史记录”信息也可能由生成实体包含在请求中，如果它是向前转发的。
The "Request History" information is being inserted by a network element retargeting a request, resulting in a slightly different problem than the basic SIP header problem, thus requiring specific consideration. It is recognized that these security requirements can be generalized to a basic requirement of being able to secure information that is inserted by proxies.
“请求历史记录”信息由重新确定请求目标的网元插入，导致与基本SIP报头问题稍有不同的问题，因此需要具体考虑。人们认识到，这些安全要求可以概括为能够保护由代理插入的信息的基本要求。
The potential security problems include the following:
潜在的安全问题包括：
1. A rogue application could insert a bogus Request History-Info entry by either adding an additional hi-entry as a result of retargeting or entering invalid information.
1. 恶意应用程序可以通过添加额外的hi条目（作为重定目标的结果）或输入无效信息来插入虚假的请求历史信息条目。
2. A rogue application could rearrange the "Request History" information to change the nature of the end application or to mislead the receiver of the information.
2. 恶意应用程序可能会重新排列“请求历史记录”信息，以改变最终应用程序的性质或误导信息接收者。
3. A rogue application could delete some or all of the "Request History" information.
3. 恶意应用程序可以删除部分或全部“请求历史记录”信息。
Thus, a security solution for "Request History" must meet the following requirements:
因此，“请求历史记录”的安全解决方案必须满足以下要求：
1. SEC-req-1: The entity receiving the "Request History" must be able to determine whether any of the previously added "Request History" content has been altered.
1. SEC-req-1：接收“请求历史记录”的实体必须能够确定先前添加的“请求历史记录”内容是否已被更改。
2. SEC-req-2: The ordering of the "Request History" information must be preserved at each instance of retargeting.
2. SEC-req-2：“请求历史记录”信息的顺序必须在每个重定目标实例中保留。
3. SEC-req-3: The entity receiving the information conveyed by the "Request History" must be able to authenticate the entity providing the request.
3. SEC-req-3：接收“请求历史记录”传递的信息的实体必须能够验证提供请求的实体。
4. SEC-req-4: To ensure the confidentiality of the "Request History" information, only entities that process the request SHOULD have visibility to the information.
4. SEC-req-4：为确保“请求历史记录”信息的机密性，只有处理请求的实体才能查看信息。
It should be noted that these security requirements apply to any entity making use of the "Request History" information.
应注意，这些安全要求适用于使用“请求历史记录”信息的任何实体。
Since the Request-URI that is captured could inadvertently reveal information about the originator, there are general privacy requirements that MUST be met:
由于捕获的请求URI可能会无意中泄露有关发起人的信息，因此必须满足以下一般隐私要求：
1. PRIV-req-1: The entity retargeting the request must ensure that it maintains the network-provided privacy (as described in [RFC3323]) associated with the request as it is retargeted.
1. PRIV-req-1：重定请求目标的实体必须确保其在重定目标时维护与请求相关的网络提供的隐私（如[RFC3323]中所述）。
2. PRIV-req-2: The entity receiving the "Request History" must maintain the privacy associated with the information. In addition, local policy at a proxy may identify privacy requirements associated with the Request-URI being captured in the "Request History" information.
2. PRIV-req-2：接收“请求历史记录”的实体必须维护与信息相关的隐私。此外，代理的本地策略可以识别与在“请求历史”信息中捕获的请求URI相关联的隐私要求。
3. PRIV-req-3: "Request History" information subject to privacy shall not be included in outgoing messages unless it is protected as described in [RFC3323].
3. PRIV-req-3：“请求历史记录”受隐私保护的信息不得包含在传出消息中，除非按照[RFC3323]中的说明进行保护。
Authors' Addresses
作者地址
Mary Barnes Polycom TX US
玛丽·巴恩斯美国宝利通公司
EMail: mary.ietf.barnes@gmail.com
EMail: mary.ietf.barnes@gmail.com
Francois Audet Skype
弗朗索瓦·奥德特Skype
EMail: francois.audet@skype.net
EMail: francois.audet@skype.net
Shida Schubert NTT
Shida舒伯特NTT
EMail: shida@ntt-at.com
EMail: shida@ntt-at.com
Hans Erik van Elburg Detecon International Gmbh Sternengasse 14-16 Cologne Germany
Hans Erik van Elburg Detecon International Gmbh Sternegasse 14-16德国科隆
EMail: ietf.hanserik@gmail.com
EMail: ietf.hanserik@gmail.com
Christer Holmberg Ericsson Hirsalantie 11, Jorvas Finland
Christer Holmberg Ericsson Hirsalantie 11，芬兰约瓦斯
EMail: christer.holmberg@ericsson.com
EMail: christer.holmberg@ericsson.com