Independent Submission M. Mohali
Request for Comments: 7544 Orange
Obsoletes: 6044 August 2015
Category: Informational
ISSN: 2070-1721
Independent Submission M. Mohali
Request for Comments: 7544 Orange
Obsoletes: 6044 August 2015
Category: Informational
ISSN: 2070-1721
Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中的转移和历史信息头字段之间的转移信息映射和互通
Abstract
摘要
Although the SIP History-Info header field described in RFC 7044 is the solution adopted in IETF, the non-standard Diversion header field described, as Historic, in RFC 5806 is nevertheless already implemented and used for conveying call-diversion-related information in Session Initiation Protocol (SIP) signaling.
尽管RFC 7044中描述的SIP历史信息报头字段是IETF中采用的解决方案，但是RFC 5806中描述为历史的非标准转移报头字段已经实现并用于在会话发起协议（SIP）信令中传送呼叫转移相关信息。
RFC 7044 obsoletes the original RFC 4244 and redefines the History-Info header field for capturing the history information in requests.
RFC 7044废弃了原始RFC 4244，并重新定义了历史信息报头字段，用于捕获请求中的历史信息。
Since the Diversion header field is used in existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This document describes a recommended interworking guideline between the Diversion header field and the History-Info header field to handle call diversion information. This work is intended to enable the migration from non-standard implementations toward IETF specification-based implementations.
由于转接头字段在现有网络实现中用于传输呼叫转接信息，因此需要它与SIP历史信息标准化解决方案进行交互。本文档描述了转接头字段和历史信息头字段之间的推荐互通指南，以处理呼叫转接信息。这项工作旨在实现从非标准实现向基于IETF规范的实现的迁移。
This document obsoletes RFC 6044, which describes the interworking between the Diversion header field defined in RFC 5806 and the obsoleted History-Info header field defined on RFC 4244.
本文件废弃了RFC 6044，该文件描述了RFC 5806中定义的分流标头字段与RFC 4244中定义的废弃历史信息标头字段之间的互通。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc7544.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7544.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Overview ...................................................4
1.2. Background .................................................4
1.3. From RFC 4244 to RFC 7044 ..................................5
2. Problem Statement ...............................................5
3. Interworking Recommendations ....................................7
3.1. General Recommendations ....................................7
3.2. Privacy Considerations .....................................8
3.3. Headers in SIP Method .....................................10
3.4. SIP Network/Terminal Using Diversion Header Field
to SIP Network/Terminal Using History-Info Header Field ...10
3.5. SIP Network/Terminal Using History-Info Header
Field to SIP Network/Terminal Using Diversion
Header Field ..............................................12
4. Reminder of the Syntax for Header Fields .......................13
4.1. History-Info Header Field Syntax ..........................13
4.2. Diversion Header Field Syntax .............................16
5. Diversion Header Field to History-Info Header Field ............16
6. History-Info Header Field to Diversion Header Field ............20
7. Examples .......................................................22
7.1. Example with Diversion Header Field Changed into
History-Info Header Field .................................22
7.2. Example with History-Info Header Field Changed into
Diversion Header Field ....................................22
7.3. Example with Two SIP Networks Using History-Info Header
Field Interworking with a SIP Network Using Diversion
Header Field ..............................................22
7.4. Additional Interworking Cases .............................24
8. Backward Compatibility .........................................26
9. Security Considerations ........................................26
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
Appendix A. Interworking between Diversion Header Field and
Voicemail URI ........................................29
A.1. Diversion Header Field to Voicemail URI ...................29
A.2. Voicemail URI to Diversion Header Field ...................29
Acknowledgements ..................................................30
Author's Address ..................................................30
1. Introduction ....................................................4
1.1. Overview ...................................................4
1.2. Background .................................................4
1.3. From RFC 4244 to RFC 7044 ..................................5
2. Problem Statement ...............................................5
3. Interworking Recommendations ....................................7
3.1. General Recommendations ....................................7
3.2. Privacy Considerations .....................................8
3.3. Headers in SIP Method .....................................10
3.4. SIP Network/Terminal Using Diversion Header Field
to SIP Network/Terminal Using History-Info Header Field ...10
3.5. SIP Network/Terminal Using History-Info Header
Field to SIP Network/Terminal Using Diversion
Header Field ..............................................12
4. Reminder of the Syntax for Header Fields .......................13
4.1. History-Info Header Field Syntax ..........................13
4.2. Diversion Header Field Syntax .............................16
5. Diversion Header Field to History-Info Header Field ............16
6. History-Info Header Field to Diversion Header Field ............20
7. Examples .......................................................22
7.1. Example with Diversion Header Field Changed into
History-Info Header Field .................................22
7.2. Example with History-Info Header Field Changed into
Diversion Header Field ....................................22
7.3. Example with Two SIP Networks Using History-Info Header
Field Interworking with a SIP Network Using Diversion
Header Field ..............................................22
7.4. Additional Interworking Cases .............................24
8. Backward Compatibility .........................................26
9. Security Considerations ........................................26
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
Appendix A. Interworking between Diversion Header Field and
Voicemail URI ........................................29
A.1. Diversion Header Field to Voicemail URI ...................29
A.2. Voicemail URI to Diversion Header Field ...................29
Acknowledgements ..................................................30
Author's Address ..................................................30
For some services based on VoIP (Voice over IP) services (e.g., voicemail, Interactive Voice Recognition (IVR), or automatic call distribution), it is helpful for the called SIP user agent to identify from whom and why the session was diverted. For this information to be used by various service providers or by applications, it needs to pass through the network. This is possible with two different SIP header fields: the History-Info header field defined in [RFC7044] and the historic Diversion header field defined in [RFC5806]. Both of these header fields are able to transport diversion information in SIP signaling.
对于基于VoIP（IP语音）服务的某些服务（例如，语音邮件、交互式语音识别（IVR）或自动呼叫分配），被呼叫的SIP用户代理可以识别会话从谁处转移以及转移的原因。要使这些信息被各种服务提供商或应用程序使用，它需要通过网络。这可以通过两个不同的SIP头字段实现：在[RFC7044]中定义的历史信息头字段和在[RFC5806]中定义的历史分流头字段。这两个报头字段都能够在SIP信令中传输转移信息。
Although the Diversion header field is not standardized, it has been widely implemented. Therefore, it is useful to have guidelines to make this header field interwork with the standard History-Info header field.
尽管导流总管字段未标准化，但已广泛实施。因此，有指导方针使此标题字段与标准历史信息标题字段相互作用是很有用的。
Note that new implementation and deployment of the Diversion header field are strongly discouraged.
请注意，强烈反对改道总管字段的新实施和部署。
This document provides a mechanism for the translation of header field content between the Diversion header field and the History-Info header field.
本文档提供了一种在分流标题字段和历史信息标题字段之间转换标题字段内容的机制。
This document obsoletes [RFC6044].
本文件废除了[RFC6044]。
The obsoleted History-Info header field [RFC4244] and its extension for forming SIP service URIs (including Voicemail URI) [RFC4458] used to be recommended by IETF to convey redirection information. They also used to be recommended in the Communication Diversion (CDIV) 3GPP specification [TS_24.604].
IETF曾建议使用废弃的历史信息报头字段[RFC4244]及其用于形成SIP服务URI（包括语音邮件URI）[RFC4458]的扩展来传递重定向信息。它们也曾在通信转移（CDIV）3GPP规范[TS_24.604]中被推荐。
The Diversion header field was originally described in a document that was submitted to the SIP Working Group and was eventually published as an Independent Submission as [RFC5806] for the historical record; it serves as a reference for this RFC.
引水总管字段最初在提交给SIP工作组的文件中描述，并最终作为独立提交文件发布为[RFC5806]，用于历史记录；它可作为本RFC的参考。
This header field contains a list of diverting URIs and associated information providing specific information as the reason for the call diversion. Most of the first SIP-based implementations have implemented the Diversion header field when no standard solution was ready to deploy. The IETF has standardized the History-Info header field partly because it can transport general history information.
此标头字段包含转移URI和相关信息的列表，这些信息提供了作为呼叫转移原因的特定信息。大多数最初基于SIP的实现都在没有标准解决方案准备部署时实现了转移头字段。IETF已经标准化了历史信息头字段，部分原因是它可以传输一般历史信息。
This allows the receiving party to determine how and why the session is received. As the History-Info header field may contain further information than call diversion information, it is critical to avoid losing information and to be able to extract the relevant data using the retargeting cause URI parameter described in [RFC4458] for the transport of the call forwarding reason.
这允许接收方确定如何以及为什么接收会话。由于历史信息报头字段可能包含比呼叫转移信息更多的信息，因此避免信息丢失并能够使用[RFC4458]中描述的用于呼叫转发原因传输的重定目标原因URI参数提取相关数据至关重要。
The Diversion header field and the History-Info header field have different syntaxes, which are described in this document. Note that the main difference is that the History-Info header field is a chronological writing header whereas the Diversion header field applies a reverse chronology (i.e., the first diversion entry read corresponds to the last diverting user).
分流标题字段和历史信息标题字段具有不同的语法，本文档对此进行了描述。请注意，主要区别在于历史信息标题字段是按时间顺序写入的标题，而转移标题字段应用反向时间顺序（即，读取的第一个转移条目对应于最后一个转移用户）。
Appendix A provides an interworking guideline between the Diversion header field and the Voicemail URI, which is another way to convey diversion information without using the History-Info header field. The Voicemail URI is defined in [RFC4458].
附录A提供了分流头字段和语音邮件URI之间的互通指南，这是在不使用历史信息头字段的情况下传递分流信息的另一种方式。语音邮件URI在[RFC4458]中定义。
The details of why and how [RFC4244] was obsoleted by [RFC7044] are provided in Section 16 of [RFC7044].
[RFC7044]淘汰[RFC4244]的原因和方式详见[RFC7044]第16节。
The main changes for implementation of the History-Info header field are as follows:
实现历史信息标题字段的主要更改如下：
1. The header field parameters "mp", "rc", and "np" were added to capture the specific method by which a target is determined.
1. 添加了标题字段参数“mp”、“rc”和“np”，以捕获确定目标的特定方法。
2. A way to indicate a gap in the History-Info header field was added by using a "0" in the index.
2. 通过在索引中使用“0”，添加了一种在历史信息标题字段中指示差距的方法。
3. To apply privacy, entries were anonymized rather than removed.
3. 为了应用隐私，条目被匿名化，而不是删除。
4. Many SHOULDs were changed into MUSTs to have a more reliable header.
4. 许多should被改为must，以获得更可靠的header。
Backward-compatibility aspects are discussed in Section 8 of this document.
本文档第8节讨论了向后兼容性方面。
This section provides the baseline terminology used in the rest of the document and defines the scope of interworking between the Diversion header field and the History-Info header field.
本节提供了文档其余部分中使用的基线术语，并定义了分流标题字段和历史信息标题字段之间的互通范围。
There are many ways in which SIP signaling can be used to modify a session destination before it is established and many reasons for doing so. The behavior of the SIP entities that will have to further process the session downstream will sometimes vary depending on the reasons that led to changing the destination, for example, whether it is for a simple proxy to route the session or for an application server (AS) to provide a supplementary service. The Diversion header field and the History-Info header field differ in the approach and scope of addressing this problem.
在会话目的地建立之前，可以通过多种方式使用SIP信令来修改会话目的地，并且有许多这样做的原因。需要进一步处理会话下游的SIP实体的行为有时会根据导致更改目的地的原因而有所不同，例如，是简单代理路由会话还是应用服务器（AS）提供补充服务。分流标题字段和历史信息标题字段在解决此问题的方法和范围上有所不同。
For clarity, the following vocabulary is used in this document:
为清楚起见，本文件中使用了以下词汇：
o Retarget/redirect: these terms refer to the process of a Proxy Server/User Agent Client (UAC) changing a Request-URI (Section 7.1 of [RFC3261]) in a request and thus changing the target of the request. 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 forwarding of the request. The term "retarget" is defined in [RFC7044].
o 重定目标/重定向：这些术语指代理服务器/用户代理客户端（UAC）更改请求中的请求URI（RFC3261第7.1节）从而更改请求目标的过程。这包括由于位置服务查找和重定向处理而更改请求URI。这还包括在转发请求之前对URI的内部（到代理/SIP中介）更改。术语“重定目标”在[RFC7044]中定义。
o Call forwarding/call diversion/communication diversion: these terms are equivalent and refer to the Communications Diversion (CDIV) supplementary services, based on the ISDN Communication diversion supplementary services and defined in 3GPP [TS_24.604]. They are applicable to entities that are intended to modify the original destination of an IP multimedia session during or prior to the session establishment.
o 呼叫转移/呼叫转移/通信转移：这些术语相当于通信转移（CDIV）补充业务，基于ISDN通信转移补充业务，并在3GPP[TS_24.604]中定义。它们适用于拟在会话建立期间或之前修改IP多媒体会话的原始目的地的实体。
This document does not intend to describe when or how History-Info or Diversion header fields should be used. Hereafter is provided clarification on the context in which the interworking is required.
本文档不打算描述何时或如何使用历史信息或分流标题字段。下文对需要互通的上下文进行了澄清。
The Diversion header field has exactly the same scope as the call diversion service, and each header field entry reflects a call diversion invocation. The Diversion header field is used for recording call forwarding information that could be useful to network entities downstream. Today, this SIP header field is implemented by several manufacturers and deployed in networks.
转移头字段的作用域与呼叫转移服务的作用域完全相同，每个头字段条目都反映了呼叫转移调用。转移头字段用于记录可能对下游网络实体有用的呼叫转移信息。今天，这个SIP头字段由几个制造商实现并部署在网络中。
The History-Info header field is used to store all retargeting information, including call diversion information. As such, the History-Info header field [RFC7044] is used to convey call-diversion-related information by using a cause URI parameter [RFC4458] in the relevant entry.
历史信息标头字段用于存储所有重定目标信息，包括呼叫转移信息。因此，历史信息报头字段[RFC7044]用于通过在相关条目中使用原因URI参数[RFC4458]来传递呼叫转移相关信息。
Note, however, that the use of cause URI parameter [RFC4458] in a History-Info entry for a call diversion is specific to the 3GPP specification [TS_24.604]. [RFC4458] focuses on retargeting toward a voicemail server and does not specify whether the cause URI parameter should be added in a URI for other cases. As a consequence, implementations that do not use the cause URI parameter for call forwarding information are not considered for the mapping described in this document. Nevertheless, some recommendations are given in the next sections on how to avoid the loss of non-mapped information at the boundary between a network region using the History-Info header field and one using the Diversion header field.
然而，请注意，在呼叫转移的历史信息条目中使用原因URI参数[RFC4458]特定于3GPP规范[TS_24.604]。[RFC4458]重点关注语音邮件服务器的重定目标，不指定是否应在其他情况下的URI中添加原因URI参数。因此，对于本文档中描述的映射，不考虑对呼叫转发信息不使用cause URI参数的实现。尽管如此，下一节将给出一些建议，说明如何避免在使用历史信息标头字段的网络区域和使用分流标头字段的网络区域之间的边界处丢失未映射信息。
[RFC7044] 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 refers to the hi-index of the hi-entry, which contains a hi-targeted-to-uri that represents the Request-URI that was retargeted.
[RFC7044]定义了三个标头字段参数：“rc”、“mp”和“np”。标头字段参数“rc”和“mp”表示确定请求新目标的机制。标题字段“np”反映目标未更改。所有参数都包含一个索引，其值引用hi项的hi索引，该索引包含一个hi目标uri，该uri表示已重定目标的请求uri。
Since both header fields address call forwarding needs, diverting information could be mixed up or be inconsistent if both are present in an uncoordinated fashion in the INVITE request. So, Diversion and History-Info header fields must not independently coexist in the same session signaling. This document addresses how to convert information between the Diversion header field and the History-Info header field and when and how to preserve both header fields to cover additional cases.
由于这两个报头字段都满足呼叫转发需求，因此如果在INVITE请求中两者都以不协调的方式存在，则转移信息可能会混淆或不一致。因此，转移和历史信息头字段不能独立地共存于同一会话信令中。本文档介绍了如何在分流标题字段和历史信息标题字段之间转换信息，以及何时和如何保留两个标题字段以涵盖其他情况。
For the transportation of consistent diversion information downstream, it is necessary to make the two header fields interwork. Interworking between the Diversion header field and the History-Info header field is introduced in Sections 5 and 6. Since the coexistence scenario may vary from one use case to another, guidelines regarding interaction of header fields are proposed in Section 3.
为了向下游传输一致的分流信息，有必要使两个标题字段相互作用。第5节和第6节介绍了导流总管字段和历史信息总管字段之间的互通。由于共存场景可能因用例而异，因此第3节中提出了有关头字段交互的指南。
Interworking function (IWF):
互通功能（IWF）：
In a normal case, the network topology assumption is that the interworking described in this document should be performed by a specific SIP border device that is aware, by configuration, that it is at the border between two regions, one using the History-Info header field and one using the Diversion header field.
在正常情况下，网络拓扑假设本文档中描述的互通应由特定的SIP边界设备执行，该设备通过配置知道它位于两个区域之间的边界，一个使用历史信息报头字段，另一个使用转移报头字段。
As the History-Info header field is a standard solution, a network using the Diversion header field must be able to provide information to a network using the History-Info header field. In this case, to avoid coexistence of header fields, it is required to replace, as often as possible, the Diversion header field with the History-Info header field in the INVITE request during the interworking.
由于历史信息标题字段是标准解决方案，因此使用分流标题字段的网络必须能够使用历史信息标题字段向网络提供信息。在这种情况下，为了避免报头字段共存，需要在互通期间尽可能经常地将INVITE请求中的转移报头字段替换为历史信息报头字段。
Since, the History-Info header field has a wider scope than the Diversion header field, it may be used for needs and services other than call diversion. In addition, to trace call diversion information, the History-Info header field also acts as a session history and can store all successive Request-URI values. Consequently, even if it should be better to remove the History-Info header field after the creation of the Diversion header field to avoid confusion, the History-Info header field must remain unmodified in the SIP signaling if it contains supplementary (non-diversion) information. It is possible to have History-Info header fields that do not have values that can be mapped into the Diversion header field. In this case, no interworking with the Diversion header field should be performed, and it must be defined per implementation what to do in this case. This point is out of the scope of this document.
由于历史信息标头字段的范围比转接标头字段的范围更广，因此它可用于呼叫转接以外的需求和服务。此外，为了跟踪呼叫转移信息，History Info header字段还充当会话历史，可以存储所有后续请求URI值。因此，即使在创建分流头字段之后最好删除历史信息头字段以避免混淆，但如果历史信息头字段包含补充（非分流）信息，则它必须在SIP信令中保持不变。历史信息标题字段可能不具有可映射到分流标题字段的值。在这种情况下，不应执行与分流总管字段的互通，并且必须根据实施情况定义在这种情况下的操作。这一点超出了本文件的范围。
In conclusion, it is recommended to have local policies minimizing the loss of information and find the best way to keep it up to the terminating user agent.
总之，建议制定本地策略，最大限度地减少信息丢失，并找到让终止用户代理了解信息的最佳方式。
The following sections describe the basic use cases. Additional interworking cases are described in Section 7.4.
以下部分描述了基本用例。第7.4节描述了其他互通情况。
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 privacy parameter within the concerned header:
当SIP消息被转发到SIP中介机构不负责的域时，域边界处的隐私服务基于消息头中的隐私头字段的值或相关头中的隐私参数应用适当的隐私：
1. For the History-Info header field, it is the Privacy header field included as the "headers" component of the hi-targeted-to-uri in the individual hi-entries with the priv-value "history".
1. 对于History Info header字段，它是作为hi的“headers”组件包含的Privacy header字段，该hi以uri为目标，位于priv值为“History”的各个hi条目中。
2. For the Diversion header field, it is the diversion-privacy parameter "privacy" in each Diversion header field.
2. 对于分流头字段，它是每个分流头字段中的分流隐私参数“隐私”。
For the History-Info header field, as recommended in [RFC7044]:
对于[RFC7044]中建议的历史信息标题字段：
o If there is a Privacy header field in the message header of a request 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 Privacy Service. The Privacy Service must change any hi-targeted-to-uri in these hi-entries that have not been anonymized to the anonymous SIP URI "anonymous@anonymous.invalid" as recommended in Sections 4.1.1.2 and 4.1.1.3 of [RFC3323].
o 如果请求的消息头中存在priv值为“header”或“history”的Privacy header字段，则隐私服务将匿名化所有针对URI的hi（在与SIP中介负责的域相关联的hi条目中）。隐私服务必须将这些hi条目中未匿名化的uri目标hi更改为匿名SIP uri“anonymous@anonymous.invalid“按照[RFC3323]第4.1.1.2节和第4.1.1.3节的建议。
o If there is a Privacy header field in the "headers" component of a hi-targeted-to-uri with a priv-value of "history", then all the concerned hi-entries must be anonymized as described above prior to forwarding.
o 如果针对uri的hi的“headers”组件中存在priv值为“history”的Privacy header字段，则所有相关hi条目在转发之前必须如上所述进行匿名化。
The Privacy Service must remove the Privacy header field from the "headers" component of the hi-targeted-to-uris of the concerned hi-entries and the priv-value of "history" from the Privacy header field in the message header of the request prior to forwarding. If there are no remaining priv-values in the Privacy header field, the Privacy Service must remove the Privacy header field from the request.
在转发之前，隐私服务必须从针对相关hi条目URI的hi的“headers”组件中删除Privacy header字段，并从请求的消息头中的Privacy header字段中删除priv值“history”。如果隐私标头字段中没有剩余的priv值，隐私服务必须从请求中删除隐私标头字段。
For the Diversion header field:
对于导流总管字段：
o If there is a Privacy header field in the message header of a request with a priv-value of "header", then all the addresses in the Diversion header fields (associated with the domain for which the SIP intermediary is responsible) are anonymized by the Privacy Service by changing the address to the anonymous SIP URI "anonymous@anonymous.invalid" as recommended in Sections 4.1.1.2 and 4.1.1.3 of [RFC3323] prior to forwarding.
o 如果请求的消息头中存在priv值为“header”的隐私头字段，则隐私服务通过将地址更改为匿名SIP URI来匿名化转移头字段中的所有地址（与SIP中介机构负责的域相关）anonymous@anonymous.invalid"转发前，按照[RFC3323]第4.1.1.2节和第4.1.1.3节的建议。
o For each Diversion header field or each entry in the Diversion header field, if there is a diversion-privacy parameter with a value set to "full", "uri", or "name", then the concerned Diversion header field address must be anonymized as described above prior to forwarding.
o 对于每个分流头字段或分流头字段中的每个条目，如果存在一个值设置为“full”、“uri”或“name”的分流隐私参数，则在转发之前，必须如上所述对相关分流头字段地址进行匿名化。
In the concerned Diversion header field entries, the diversion-privacy parameter must be removed from the header.
在相关的分流标头字段条目中，必须从标头中删除分流隐私参数。
The privacy information interworking as described in Sections 5 and 6 must only be considered within a trusted domain that ensures correct application of the privacy requirements.
第5节和第6节所述的隐私信息互通只能在确保正确应用隐私要求的受信任域内考虑。
The recommended interworking presented in this document should apply only for INVITE requests.
本文档中推荐的互通仅适用于邀请请求。
In 3xx responses:
在3xx响应中：
Both History-Info and Diversion header fields could be present in 3xx responses.
历史信息和分流标题字段都可以出现在3xx响应中。
When a proxy wants to interwork with a network supporting the other header field, it should apply the interworking between Diversion header field and History-Info header field in the 3xx response.
当代理想要与支持其他报头字段的网络互通时，它应该在3xx响应中应用分流报头字段和历史信息报头字段之间的互通。
When a recursing proxy redirects an initial INVITE after receiving a 3xx response, it should add as a last entry either a Diversion header field or a History-Info header field (according to its capabilities) in the forwarded INVITE. Local policies could apply regarding whether or not to send the received header field in the next INVITE.
当递归代理在收到3xx响应后重定向初始INVITE时，它应该在转发的INVITE中添加一个转移头字段或历史信息头字段（根据其功能）作为最后一个条目。关于是否在下一次邀请中发送接收的标头字段，可以应用本地策略。
In SIP responses other than 100:
在除100以外的SIP响应中：
All SIP responses where the History-Info header field could be present are not used for the call forwarding service and should not be changed into the Diversion header field. The destination network must be transparent to the received History-Info header field.
可能存在历史信息头字段的所有SIP响应不用于呼叫转移服务，不应更改为转移头字段。目标网络必须对接收的历史信息标头字段透明。
Note: The following mapping is inspired by the ISDN User Part (ISUP) to SIP interworking described in [TS_29.163].
注：以下映射受[TS_29.163]中描述的ISDN用户部分（ISUP）到SIP互通的启发。
3.4. SIP Network/Terminal Using Diversion Header Field to SIP Network/ Terminal Using History-Info Header Field
3.4. 使用转移头字段的SIP网络/终端到使用历史信息头字段的SIP网络/终端
When the Diversion header field is used to create a History-Info header field, the Diversion header field must be removed in the outgoing INVITE. It is assumed that all the information present in the Diversion header field is transferred in the History-Info header field.
当改道标题字段用于创建历史信息标题字段时，必须在传出邀请中删除改道标题字段。假设分流头字段中的所有信息都在历史信息头字段中传输。
If a History-Info header field is also present in the incoming INVITE (in addition to the Diversion header field), the Diversion header field and History-Info header field present must be mixed, and only the diversion information not yet present in the History-Info header
如果传入邀请中还存在历史信息标题字段（除了转移标题字段），则转移标题字段和历史信息标题字段必须混合，并且只有历史信息标题中尚未存在的转移信息
field must be inserted as a last entry (most recent) in the existing History-Info header field, following the creation process recommended in [RFC7044].
必须按照[RFC7044]中建议的创建过程，将字段作为现有历史信息标题字段中的最后一个条目（最新）插入。
As an example, this could be the case of an INVITE coming from network_2 using the Diversion header field but previously passed through network_1 using the History-Info header field (or the network_2 uses History-Info header field to transport successive URI information) and going to network_3 using the History-Info header field.
例如，这可能是来自网络_2的邀请使用转移标头字段，但之前通过网络_1使用历史信息标头字段（或网络_2使用历史信息标头字段传输连续URI信息）并使用历史信息标头字段到达网络_3的情况。
IWF* IWF*
network_1 | network_2 |network_3
History-Info | Diversion |using
| |History-
| |Info
UA A P1 AS B | P2 AS C UA C AS D | UA E
| | | | | | | | | |
|INVITE | | | | | | | | |
|------>| | | | | | | | |
| | | | | | | | | |
| |INVITE | | | | | | | |
| |------>| | | | | | | |
| |Supported: histinfo | | | | | |
| | History-Info: | | | | | |
| | <sip:proxyP1>;index=1,| | | | | |
| | <sip:userB>;index=1.1;rc=1 | | | | |
| | | | | | | | | |
| | |INVITE | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | |<sip:proxyP1>;index=1, | | | | |
| | |<sip:userB>;index=1.1;rc=1, | | | |
| | |<sip:userC;cause=302>;index=1.1.1;mp=1.1 | |
IWF* IWF*
network_1 | network_2 |network_3
History-Info | Diversion |using
| |History-
| |Info
UA A P1 AS B | P2 AS C UA C AS D | UA E
| | | | | | | | | |
|INVITE | | | | | | | | |
|------>| | | | | | | | |
| | | | | | | | | |
| |INVITE | | | | | | | |
| |------>| | | | | | | |
| |Supported: histinfo | | | | | |
| | History-Info: | | | | | |
| | <sip:proxyP1>;index=1,| | | | | |
| | <sip:userB>;index=1.1;rc=1 | | | | |
| | | | | | | | | |
| | |INVITE | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | |<sip:proxyP1>;index=1, | | | | |
| | |<sip:userB>;index=1.1;rc=1, | | | |
| | |<sip:userC;cause=302>;index=1.1.1;mp=1.1 | |
In this case, the incoming INVITE contains a Diversion header field and a History-Info header field. Therefore, as recommended in this document, it is necessary to create, for network_3, a single History-Info header field gathering existing information from both the History-Info and the Diversion header fields received. Anyway, it is required that network_2 (i.e., IWF) remove the Diversion header field when the message is going to a network not using the Diversion header field. Then, network_3 could use call forwarding information that is present in a single header field and add its own diversion information if necessary.
在这种情况下，传入的INVITE包含一个转移标题字段和一个历史信息标题字段。因此，根据本文件的建议，有必要为网络_3创建一个历史信息标题字段，该字段从接收到的历史信息和分流标题字段中收集现有信息。无论如何，当消息发送到不使用转移头字段的网络时，要求network_2（即IWF）删除转移头字段。然后，网络_3可以使用存在于单个报头字段中的呼叫转发信息，并在必要时添加其自己的转移信息。
Notes:
笔记：
1. If a network is not able either to use only one header field each time or to maintain both header fields up to date, the chronological order cannot be certified.
1. 如果网络不能每次仅使用一个标题字段，或者不能将两个标题字段保持最新，则无法验证时间顺序。
2. It is not possible to have only a Diversion header field when the History-Info header field contains more than call diversion information. If previous policy recommendations are applied, the chronological order is respected as Diversion entries are inserted at the end of the History-Info header field taking into account the Diversion internal chronology.
2. 当历史信息标题字段包含多个呼叫转移信息时，不可能只有转移标题字段。如果应用了以前的政策建议，则会遵循时间顺序，因为考虑到分流内部时间顺序，分流条目会插入到历史信息标题字段的末尾。
3.5. SIP Network/Terminal Using History-Info Header Field to SIP Network/Terminal Using Diversion Header Field
3.5. SIP网络/终端使用历史信息头字段到SIP网络/终端使用转移头字段
When the History-Info header field is interpreted to create a Diversion header field, some precautions must be taken.
当解释历史信息标题字段以创建分流标题字段时，必须采取一些预防措施。
If the History-Info header field contains only call forwarding information, then it must be deleted after the interworking.
如果历史信息标头字段仅包含呼叫转移信息，则必须在互通后将其删除。
If the History-Info header field contains other information, then only the information of concern to the diverting user must be used to create entries in the Diversion header field, and the History-Info header field must be kept as received in the INVITE and forwarded downstream.
如果历史信息标题字段包含其他信息，则只有分流用户关心的信息才能用于在分流标题字段中创建条目，并且历史信息标题字段必须保持在INVITE中接收并转发到下游。
Note: The History-Info header field could be used for reasons other than call diversion services, for example, by a service that needs to know if a specific AS has yet been invoked in the signaling path. If the call is later forwarded to a network using the History-Info header field, it would be better not to lose history information due to passing though the network that only supports the Diversion header field. A recommended solution must not disrupt the standard behavior, and networks that do not implement the History-Info header field must be transparent to a received History-Info header field.
注意：History Info header字段可用于呼叫转移服务以外的原因，例如，需要知道特定AS是否已在信令路径中被调用的服务。如果稍后使用历史信息报头字段将呼叫转发到网络，则最好不要因为通过仅支持转移报头字段的网络而丢失历史信息。推荐的解决方案不得破坏标准行为，并且未实现历史信息标头字段的网络必须对接收到的历史信息标头字段透明。
If a Diversion header field is present in the incoming INVITE (in addition to the History-Info header field), only diversion information present in the History-Info header field but not in the Diversion header field must be inserted from the last entry (most recent) into the existing Diversion header field as recommended in [RFC5806].
如果传入的INVITE中存在分流头字段（除历史信息头字段外），则必须按照[RFC5806]中的建议，仅将历史信息头字段中存在但分流头字段中不存在的分流信息从最后一个条目（最近）插入现有分流头字段。
Note that the chronological order could not be certified. If previous policy recommendations are respected, this case should not happen.
请注意，无法证明时间顺序。如果以前的政策建议得到尊重，这种情况就不会发生。
Forking case:
叉箱：
The History-Info header field enables the recording of sequential forking for the same served user. During an interworking from the History-Info header field to the Diversion header field, the History-Info entries containing a forking situation (with an incremented "index" parameter) could possibly be mapped if they contain a call forwarding "cause" parameter. The interworking entity could choose to create only a Diversion entry or not apply the interworking. The choice could be done according a local policy.
历史信息标题字段允许记录同一服务用户的顺序分叉。在从历史信息标题字段到转移标题字段的互通过程中，如果历史信息条目包含呼叫转移“原因”参数，则可能会映射包含分叉情况（具有递增的“索引”参数）的历史信息条目。互通实体可以选择仅创建分流条目或不应用互通。可以根据当地政策进行选择。
The same logic is applied for an interworking with Voicemail URI (see Appendix A).
同样的逻辑也适用于与语音邮件URI的互通（参见附录A）。
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)
hi-entry = hi-targeted-to-uri *(SEMI hi-param)
hi-targeted-to-uri = name-addr
hi-param = hi-index/hi-target-param/hi-extension
hi-index = "index" EQUAL index-val
index-val = number *("." number)
number = [ %x31-39 *DIGIT ] DIGIT
hi-target-param = rc-param / mp-param / np-param
rc-param = "rc" EQUAL index-val
mp-param = "mp" EQUAL index-val
np-param = "np" EQUAL index-val
hi-extension = generic-param
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
hi-entry = hi-targeted-to-uri *(SEMI hi-param)
hi-targeted-to-uri = name-addr
hi-param = hi-index/hi-target-param/hi-extension
hi-index = "index" EQUAL index-val
index-val = number *("." number)
number = [ %x31-39 *DIGIT ] DIGIT
hi-target-param = rc-param / mp-param / np-param
rc-param = "rc" EQUAL index-val
mp-param = "mp" EQUAL index-val
np-param = "np" EQUAL index-val
hi-extension = generic-param
The ABNF definitions for "generic-param", "name-addr", "HCOLON", "COMMA", "SEMI", and "EQUAL" are from [RFC3261].
ABNF对“通用参数”、“名称地址”、“HCOLON”、“逗号”、“半”和“相等”的定义来自[RFC3261]。
The History-Info header field is specified in [RFC7044]. The top-most History-Info entry (first in the list) corresponds to the oldest history information.
[RFC7044]中指定了历史信息标题字段。最早的历史信息条目（列表中的第一个）对应最早的历史信息。
Cause URI parameter:
原因URI参数：
A hi-entry may contain a cause URI parameter expressing the diversion reason. This cause URI parameter is defined in [RFC4458]. The ABNF grammar [RFC5234] for the cause-param parameter is shown below as it has been subject to Erratum ID 1409 [Err1409] for [RFC4458]. The Status-Code is defined in [RFC3261].
hi条目可能包含表示转移原因的原因URI参数。此原因URI参数在[RFC4458]中定义。原因参数的ABNF语法[RFC5234]如下所示，因为[RFC4458]的勘误表ID 1409[Err1409]。状态代码在[RFC3261]中定义。
cause-param = "cause=" Status-Code
原因参数=“原因=“状态代码
The cause-param parameter is a SIP/SIPS URI parameter and should be inserted in the History-Info entry (URI) of the diverted-to user in case of call diversion as recommended in the 3GPP CDIV specification [TS_24.604]. The cause values used in the cause-param for the diverting reason are listed in [RFC4458]. Because it is a parameter dedicated to call forwarding service, its presence is used to determine that a hi-entry is a diverting user. More precisely, each diverting user is located in the hi-entry before the one containing a cause-param with cause value as listed in [RFC4458].
cause param参数是SIP/SIPS URI参数，在3GPP CDIV规范[TS_24.604]中建议的呼叫转移情况下，应将其插入转移到用户的历史信息条目（URI）中。[RFC4458]中列出了分流原因的原因参数中使用的原因值。因为它是专用于呼叫转移服务的参数，所以它的存在用于确定hi条目是转移用户。更准确地说，每个分流用户位于hi条目中，位于包含原因参数（原因值如[RFC4458]所列）的用户之前。
Reason header field:
原因标题字段：
The Reason header field defined in [RFC3326] should be escaped in the hi-entry of the diverting user when the call diversion is due to a received SIP response. The Reason header field contains a cause parameter set to the true SIP response code received (Status-Code).
[RFC3326]中定义的原因报头字段应在转接用户的hi条目中转义，因为呼叫转接是由于接收到SIP响应引起的。原因标头字段包含一个原因参数，该参数设置为收到的真实SIP响应代码（状态代码）。
Therefore, in case of call diversion due to a SIP response, both cause parameters should be used. The complexity is that these parameters could be used at the same time in the History-Info header field but not in the same hi-entry and not with the same meaning. Only the cause-param is dedicated to call diversion service. The 'cause' Reason header field parameter is not taken into account in the mapping with a Diversion header field.
因此，在SIP响应导致呼叫转移的情况下，应使用两个原因参数。复杂的是，这些参数可以在历史信息标题字段中同时使用，但不能在同一hi条目中使用，也不能具有相同的含义。只有原因参数专用于呼叫转移服务。“原因”原因标题字段参数在与分流标题字段的映射中不被考虑。
Target URI parameter:
目标URI参数：
[RFC4458] also defines the 'target' URI parameter, which could be inserted in a Request-URI and consequently in the hi-targeted-to-uri. This parameter is used to keep the diverting user address in the downstream INVITE request in Voicemail URI implementation. As this information is already present in the hi-entries, the 'target' URI parameter is not taken into account regarding the interworking with the Diversion header field. From the Diversion header field, it could be possible to create the
[RFC4458]还定义了“target”URI参数，该参数可以插入到请求URI中，从而插入到以URI为目标的hi中。此参数用于在语音邮件URI实现中保持下游INVITE请求中的转移用户地址。由于此信息已存在于hi条目中，“target”URI参数不考虑与分流头字段的交互。从分流总管字段，可以创建
'target' URI parameter in the hi-entries and/or in the Request-URI, but this possibility is based on local policies not described in this document.
hi条目和/或请求URI中的'target'URI参数，但这种可能性基于本文档中未描述的本地策略。
Privacy header field:
隐私标头字段：
A Privacy header field as defined in [RFC3323] could also be embedded in hi-entries with the 'history' value defined in [RFC7044].
[RFC3323]中定义的隐私标头字段也可以嵌入hi条目中，hi条目的“历史”值在[RFC7044]中定义。
Index header field parameter:
索引头字段参数：
The index parameter is a string of digits, separated by dots, to indicate the number of forward hops and retargets.
索引参数是一个由点分隔的数字字符串，用于指示向前跳跃和重定目标的数量。
Note: A history entry could contain the "gr" parameter. Regardless of the rules concerning the "gr" parameter defined in [TS_24.604], which must be applied, this parameter has no impact on the mapping and must only be copied with the served user address.
注意：历史记录条目可能包含“gr”参数。无论[TS_24.604]中定义的关于“gr”参数的规则如何（必须应用），该参数对映射没有影响，只能与服务用户地址一起复制。
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 a hi-entry must add a single index with a value of "0" (i.e., the non-negative integer zero) prior to adding the appropriate index for the action to be taken (e.g., Index=1.1.2.0.1). 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 them.
如果请求在hi条目中明显存在间隙（即，最后一个hi条目和请求URI不同），则添加hi条目的实体必须在添加要采取的操作的适当索引（例如，索引=1.1.2.0.1）之前添加一个值为“0”（即非负整数零）的索引。在应用程序使用History Info header字段参数之前，处理hi条目的SIP实体必须评估hi条目，并确定其中是否存在任何间隙。
"histinfo" option tag:
“histinfo”选项标签：
According to [RFC7044], a proxy that receives a Request with the "histinfo" option tag in the Supported header field should return captured History-Info in subsequent, provisional, and final responses to the Request. The behavior depends upon whether or not the local policy supports the capture of History-Info.
根据[RFC7044]，在受支持的标头字段中接收带有“histinfo”选项标记的请求的代理应在对请求的后续、临时和最终响应中返回捕获的历史信息。该行为取决于本地策略是否支持捕获历史信息。
Example:
例子：
History-Info:
<sip:diverting_user1_addr?Privacy=none&Reason=SIP%3Bcause%3D302>;
index=1,
<sip:diverting_user2_addr;cause=480?Privacy=history>;index=1.1;mp=1,
<sip:last_diversion_target;cause=486>;index=1.1.1;mp=1.1
History-Info:
<sip:diverting_user1_addr?Privacy=none&Reason=SIP%3Bcause%3D302>;
index=1,
<sip:diverting_user2_addr;cause=480?Privacy=history>;index=1.1;mp=1,
<sip:last_diversion_target;cause=486>;index=1.1.1;mp=1.1
The following text is restating the exact syntax that the production rules in [RFC5806] define, but using ABNF [RFC5234]:
下面的文本重新说明了[RFC5806]中的产生式规则定义的确切语法，但使用了ABNF[RFC5234]：
Diversion = "Diversion" HCOLON diversion-params
*(COMMA diversion-params)
diversion-params = name-addr *(SEMI (diversion-reason /
diversion-counter / diversion-limit /
diversion-privacy / diversion-screen /
diversion-extension))
diversion-reason = "reason" EQUAL ("unknown" / "user-busy" /
"no-answer" / "unavailable" / "unconditional"
/ "time-of-day" / "do-not-disturb" /
"deflection" / "follow-me" / "out-of-service"
/ "away" / token / quoted-string)
diversion-counter = "counter" EQUAL 1*2DIGIT
diversion-limit = "limit" EQUAL 1*2DIGIT
diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" /
"off" / token / quoted-string)
diversion-screen = "screen" EQUAL ("yes" / "no" / token /
quoted-string)
diversion-extension = token [EQUAL (token / quoted-string)]
Diversion = "Diversion" HCOLON diversion-params
*(COMMA diversion-params)
diversion-params = name-addr *(SEMI (diversion-reason /
diversion-counter / diversion-limit /
diversion-privacy / diversion-screen /
diversion-extension))
diversion-reason = "reason" EQUAL ("unknown" / "user-busy" /
"no-answer" / "unavailable" / "unconditional"
/ "time-of-day" / "do-not-disturb" /
"deflection" / "follow-me" / "out-of-service"
/ "away" / token / quoted-string)
diversion-counter = "counter" EQUAL 1*2DIGIT
diversion-limit = "limit" EQUAL 1*2DIGIT
diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" /
"off" / token / quoted-string)
diversion-screen = "screen" EQUAL ("yes" / "no" / token /
quoted-string)
diversion-extension = token [EQUAL (token / quoted-string)]
Note: The Diversion header field could be used in the comma-separated format as described below and in a header-separated format. Both formats could be combined in a received INVITE as recommended in [RFC3261].
注：分流标题字段可采用下文所述的逗号分隔格式和标题分隔格式。按照[RFC3261]中的建议，这两种格式可以组合在收到的邀请中。
Example:
例子：
Diversion:
<sip:diverting_user2_addr>;reason=user-busy;counter=1;privacy=full,
<sip:diverting_user1_addr>;reason=unconditional;counter=1;privacy=off
Diversion:
<sip:diverting_user2_addr>;reason=user-busy;counter=1;privacy=full,
<sip:diverting_user1_addr>;reason=unconditional;counter=1;privacy=off
The following text is valid only if no History-Info header field is present in the INVITE request. If at least one History-Info header field is present, the interworking function must adapt its behavior to respect the chronological order. For more information, see Section 3.
仅当邀请请求中不存在历史信息标题字段时，以下文本才有效。如果至少存在一个历史信息标题字段，则互通功能必须调整其行为以遵守时间顺序。有关更多信息，请参见第3节。
Concerning the privacy information in the Diversion header field, the following mapping only applies within a trusted domain; for other domains, see the privacy considerations in Section 3.2.
关于转移头字段中的隐私信息，以下映射仅适用于受信任域；对于其他域，请参见第3.2节中的隐私注意事项。
For N Diversion entries, N+1 History-Info entries must be created. To create the History-Info entries in the same order as during a session establishment, the Diversion entries must be mapped from the bottom-most to the top-most. Each Diversion entry shall be mapped into a History-Info entry. An additional History-Info entry (the last one) must be created with the diverted-to party address present in the Request-URI of the received INVITE. The mapping is described in the table below.
对于N个分流条目，必须创建N+1个历史信息条目。要按照会话建立期间相同的顺序创建历史信息条目，必须将转移条目从最底部映射到最顶部。每个分流条目应映射到历史信息条目中。必须创建一个附加的历史信息条目（最后一个），并在接收到的邀请的请求URI中显示转移到参与方的地址。下表描述了映射。
The first entry created in the History-Info header field contains:
在历史信息标题字段中创建的第一个条目包含：
o a hi-targeted-to-uri with the name-addr parameter of the bottom-most Diversion header field.
o 以uri为目标的hi，其名称addr参数位于最底部的标题字段中。
o if a privacy parameter is present in the bottom-most Diversion entry, then a Privacy header field must be escaped in the History-Info header field as described in the table below.
o 如果最底部的分流条目中存在隐私参数，则必须在历史信息标题字段中转义隐私标题字段，如下表所述。
o a hi-index set to 1.
o 将hi索引设置为1。
For each of the following Diversion entries (from bottom to top), the History-Info entries are created as follows (from top to bottom):
对于以下每个分流条目（从下到上），历史信息条目的创建如下（从上到下）：
Source Destination
Diversion header component: History-Info header component:
=======================================================================
name-addr hi-targeted-to-uri
Source Destination
Diversion header component: History-Info header component:
=======================================================================
name-addr hi-targeted-to-uri
=======================================================================
reason of the previous cause URI parameter
Diversion entry A cause-param "cause" is
added in each hi-entry
(except the first one)
"unknown"----------------------------------404 (default 'cause' value)
"unconditional"----------------------------302
"user-busy"--------------------------------486
"no-answer"--------------------------------408
"deflection "------------------------------480 or 487
"unavailable"------------------------------503
"time-of-day"------------------------------404 (default)
"do-not-disturb"---------------------------404 (default)
"follow-me"--------------------------------404 (default)
"out-of-service"---------------------------404 (default)
"away"-------------------------------------404 (default)
=======================================================================
reason of the previous cause URI parameter
Diversion entry A cause-param "cause" is
added in each hi-entry
(except the first one)
"unknown"----------------------------------404 (default 'cause' value)
"unconditional"----------------------------302
"user-busy"--------------------------------486
"no-answer"--------------------------------408
"deflection "------------------------------480 or 487
"unavailable"------------------------------503
"time-of-day"------------------------------404 (default)
"do-not-disturb"---------------------------404 (default)
"follow-me"--------------------------------404 (default)
"out-of-service"---------------------------404 (default)
"away"-------------------------------------404 (default)
======================================================================
counter hi-index
"1" or parameter ------------------------The previous created index
not present is extended with ".1"
Superior to "1" -------------------------Create N-1 placeholder History
(i.e., N) entry with the previous index
extended with ".1"
Then the History-Info header
created with the Diversion
entry with the previous index
extended with ".1"
======================================================================
privacy Privacy header escaped in the
hi-targeted-to-uri
"full"-----------------------------------"history"
"Off"------------------------------------Privacy header field
absent or "none"
"name"-----------------------------------"history"
"uri"------------------------------------"history"
======================================================================
hi-target-param
An mp-param "mp" is added in
each created hi-entry
(except the first one)
The "mp" parameter is set to
the index value of the
preceding hi-entry.
=======================================================================
======================================================================
counter hi-index
"1" or parameter ------------------------The previous created index
not present is extended with ".1"
Superior to "1" -------------------------Create N-1 placeholder History
(i.e., N) entry with the previous index
extended with ".1"
Then the History-Info header
created with the Diversion
entry with the previous index
extended with ".1"
======================================================================
privacy Privacy header escaped in the
hi-targeted-to-uri
"full"-----------------------------------"history"
"Off"------------------------------------Privacy header field
absent or "none"
"name"-----------------------------------"history"
"uri"------------------------------------"history"
======================================================================
hi-target-param
An mp-param "mp" is added in
each created hi-entry
(except the first one)
The "mp" parameter is set to
the index value of the
preceding hi-entry.
=======================================================================
A last History-Info entry is created and contains:
将创建最后一个历史信息条目，其中包含：
o a hi-targeted-to-uri with the Request-URI of the INVITE request.
o hi指向具有INVITE请求的请求uri的uri。
o a cause-param from the top-most Diversion entry, mapped from the diversion-reason as described above.
o 来自最顶部分流条目的原因参数，如上所述从分流原因映射。
o an index set to the previous created index extended with a new level ".1" added at the end.
o 为先前创建的索引设置的索引，在末尾添加了一个新级别“.1”。
o a hi-target-param set to "mp" equals to the index value of the previous hi-entry.
o hi目标参数设置为“mp”等于上一个hi条目的索引值。
Notes:
笔记：
1. For other optional Diversion parameters, there is no recommendation as the History-Info header field does not provide equivalent parameters.
1. 对于其他可选的改道参数，没有建议，因为历史信息标题字段不提供等效参数。
2. For values of the diversion-reason that are mapped with a recommended default value, it could also be possible to choose another value. The cause-param URI parameter offers fewer possible values than the diversion-reason parameter. However, it has been considered that the cause-param values list was sufficient to implement CDIV service as defined in 3GPP [TS_24.604] as it covers a large portion of cases.
2. 对于使用推荐默认值映射的分流原因值，也可以选择其他值。cause param URI参数提供的可能值少于division reason参数。然而，已经认为原因参数值列表足以实现3GPP[TS_24.604]中定义的CDIV服务，因为它涵盖了大部分情况。
3. The Diversion header field can contain a "tel" URI as defined in [RFC3966] in the name-addr parameter. The History-Info header field can also contain an address that is a "tel" URI, but if this hi-entry has to be completed with either a SIP header field (e.g., Reason or Privacy) or a SIP URI parameter (e.g., 'cause' or 'target'), the "tel" URI must be converted into a SIP URI. [RFC3261] gives an indication as to the mapping between sip: and tel: URIs, but in this particular case, it is difficult to assign a valid hostport as the diversion occurred in a previous network and a valid hostport is difficult to determine. So, it is suggested that in case of "tel" URI in the Diversion header field, the History-Info header field should be created with a SIP URI with user=phone and a domain set to "unknown.invalid".
3. 分流标头字段可以包含名称addr参数中[RFC3966]中定义的“tel”URI。历史信息头字段还可以包含一个地址，该地址是“tel”URI，但如果此hi条目必须使用SIP头字段（例如，原因或隐私）或SIP URI参数（例如，“原因”或“目标”）完成，则“tel”URI必须转换为SIP URI。[RFC3261]给出了sip:和tel:URI之间映射的指示，但在这种特殊情况下，很难分配有效的主机端口，因为转移发生在以前的网络中，并且很难确定有效的主机端口。因此，建议在分流头字段中出现“tel”URI的情况下，应使用user=phone的SIP URI和设置为“unknown.invalid”的域创建历史信息头字段。
4. The Diversion header field allows carrying of a counter that retains the information about the number of successive redirections. History-Info does not have an equivalent because to trace and count the number of diversions, it is necessary to count the cause parameter containing a value associated to a call diversion listed in [RFC4458]. Reading the index value is not enough. With the use of the "placeholder" entry the History-Info header field, entries can reflect the real number of diversions that occurred, thanks to the cause-param.
4. 分流标头字段允许携带保留有关连续重定向次数信息的计数器。历史信息没有等效项，因为要跟踪和统计转接次数，必须统计包含[RFC4458]中所列呼叫转接相关值的原因参数。读取索引值是不够的。通过使用历史信息标题字段中的“占位符”条目，由于原因参数，条目可以反映实际发生的改道次数。
Example of placeholder entry in the History-Info header field:
历史信息标题字段中的占位符条目示例：
<sip:unknown@unknown.invalid;cause=xxx>;index=1.1
<sip:unknown@unknown.invalid;cause=xxx>;index=1.1
<sip:bob_addr;cause=404>;index=1.1.1;mp=1.1
<sip:bob_addr;cause=404>;index=1.1.1;mp=1.1
"cause=xxx" reflects the diverting reason of a previous diverting user. For a placeholder hi-entry, the value "404" must be taken for the cause-param and so, located in the next hi-entry.
“原因=xxx”反映了先前转移用户的转移原因。对于占位符hi条目，必须将值“404”作为位于下一hi条目中的原因参数so。
For recommendations for local policies regarding the coexistence of header fields in the INVITE request, see Sections 3 and 7.4.
有关INVITE请求中标题字段共存的本地策略的建议，请参阅第3节和第7.4节。
Concerning the privacy information for the History-Info header field, the following mapping only applies within a trusted domain; for other domains, see the privacy considerations in Section 3.2.
关于历史信息头字段的隐私信息，以下映射仅适用于受信任域；对于其他域，请参见第3.2节中的隐私注意事项。
To create the Diversion entries in the same order as during a session establishment, the History-Info entries must be mapped from the top-most to the bottom-most. The first History-Info header field entry selected will be mapped into the last Diversion header field entry and so on. One Diversion header field entry must be created for each History-Info entry that has cause-param with a value listed in [RFC4458].
要按照会话建立期间相同的顺序创建转移条目，历史信息条目必须从最顶端映射到最底端。选择的第一个历史信息标题字段条目将映射到最后一个分流标题字段条目，依此类推。必须为具有[RFC4458]中所列值的原因参数的每个历史信息条目创建一个分流标题字段条目。
Diversion information:
改道信息：
The definitions of "Target_entry" and "Diverting_entry" are included below to help readers understand the mapping of the History-Info header field.
下面包含了“Target_entry”和“Diverting_entry”的定义，以帮助读者理解历史信息标题字段的映射。
The diversion information can be identified by finding the following hi-entries:
可通过查找以下hi条目来识别分流信息：
o Target_entry: hi-entries containing a cause-param URI parameter with a value listed in [RFC4458] will contain the diversion reason and the address of the target of the concerned call forwarding. Per [RFC7044], these hi-entries may also contain a hi-target-param set to "mp".
o Target_entry:hi条目包含[RFC4458]中列出的值的cause param URI参数，它将包含转移原因和相关呼叫转移目标的地址。根据[RFC7044]，这些hi条目还可能包含设置为“mp”的hi目标参数。
o Diverting_entry: For each previously identified hi-entry:
o 分流入口：对于每个先前确定的hi入口：
* If there is an "mp" header field parameter, the hi-entry whose hi-index matches the value of the hi-target-param "mp" will contain the diverting party address, its possible privacy, and/ or SIP reason when the retargeting has been caused by a received SIP response.
* 如果存在“mp”头字段参数，则hi索引与hi目标参数“mp”值匹配的hi条目将包含转移方地址、其可能的隐私和/或SIP原因（当接收到的SIP响应导致重定目标时）。
* If there is no "mp" header field parameter, the information of the diverting party address, privacy and/or SIP reason will be found in the hi-entry that precede this identified hi-entry.
* 如果没有“mp”标头字段参数，则在该标识的hi条目之前的hi条目中会找到转移方地址、隐私和/或SIP原因的信息。
Note: Per [RFC7044], all retargeting entries must point to a hi-entry that contains an "mp" parameter, but for backward-compatibility reasons, it may be absent from some of the received hi-entries. See Section 8 for more information on backward compatibility.
注意：根据[RFC7044]，所有重定目标条目必须指向包含“mp”参数的hi条目，但出于向后兼容性的原因，在某些接收到的hi条目中可能没有该参数。有关向后兼容性的更多信息，请参见第8节。
The History-Info header field must be mapped into the Diversion header field as follows:
历史信息标题字段必须映射到分流标题字段，如下所示：
Source Destination
History-Info header component: Diversion header component:
=====================================================================
hi-targeted-to-uri name-addr
of the Diverting_entry.
Source Destination
History-Info header component: Diversion header component:
=====================================================================
hi-targeted-to-uri name-addr
of the Diverting_entry.
=====================================================================
cause-param reason
of the Target_entry
404---------------------------------------"unknown" (default value)
302---------------------------------------"unconditional"
486---------------------------------------"user-busy"
408---------------------------------------"no-answer"
480 or 487--------------------------------"deflection "
503---------------------------------------"unavailable"
=====================================================================
hi-index counter
Mandatory parameter for-------------------The counter is set to "1".
History-Info reflecting
the chronological order
of the information.
=====================================================================
Privacy header field escaped privacy
in the hi-targeted-to-uri
of the Diverting_entry
"history"----------------------------------"full"
Privacy header field ----------------------"Off"
Absent or "none"
=====================================================================
=====================================================================
cause-param reason
of the Target_entry
404---------------------------------------"unknown" (default value)
302---------------------------------------"unconditional"
486---------------------------------------"user-busy"
408---------------------------------------"no-answer"
480 or 487--------------------------------"deflection "
503---------------------------------------"unavailable"
=====================================================================
hi-index counter
Mandatory parameter for-------------------The counter is set to "1".
History-Info reflecting
the chronological order
of the information.
=====================================================================
Privacy header field escaped privacy
in the hi-targeted-to-uri
of the Diverting_entry
"history"----------------------------------"full"
Privacy header field ----------------------"Off"
Absent or "none"
=====================================================================
Note: For other optional History-Info parameters, there is no recommendation as the Diversion header field does not provide equivalent parameters.
注意：对于其他可选的历史信息参数，不推荐使用，因为“分流头”字段不提供等效参数。
For recommendations for local policies regarding the coexistence of header fields in the INVITE request, see Section 3.
有关INVITE请求中头字段共存的本地策略的建议，请参阅第3节。
7.1. Example with Diversion Header Field Changed into History-Info Header Field
7.1. 改道标题字段更改为历史信息标题字段的示例
INVITE sip:last_diverting_target
Diversion:
<sip:diverting_user3_address>;reason=unconditional;counter=1;
privacy=off,
<sip:diverting_user2_address>;reason=user-busy;counter=1;
privacy=full,
<sip:diverting_user1_address>;reason=no-answer;counter=1;
privacy=off
INVITE sip:last_diverting_target
Diversion:
<sip:diverting_user3_address>;reason=unconditional;counter=1;
privacy=off,
<sip:diverting_user2_address>;reason=user-busy;counter=1;
privacy=full,
<sip:diverting_user1_address>;reason=no-answer;counter=1;
privacy=off
Mapped into:
映射到：
History-Info:
<sip:diverting_user1_address?Privacy=none>;index=1,
<sip:diverting_user2_address;
cause=408?Privacy=history>;index=1.1;mp=1,
<sip:diverting_user3_address;
cause=486?Privacy=none>;index=1.1.1;mp=1.1,
<sip:last_diverting_target;cause=302>;index=1.1.1.1;mp=1.1.1
History-Info:
<sip:diverting_user1_address?Privacy=none>;index=1,
<sip:diverting_user2_address;
cause=408?Privacy=history>;index=1.1;mp=1,
<sip:diverting_user3_address;
cause=486?Privacy=none>;index=1.1.1;mp=1.1,
<sip:last_diverting_target;cause=302>;index=1.1.1.1;mp=1.1.1
7.2. Example with History-Info Header Field Changed into Diversion Header Field
7.2. 历史信息标题字段更改为分流标题字段的示例
INVITE sip:last_diverting_target; cause=486
History-Info:
<sip:diverting_user1_address?Privacy=history>;index=1,
<sip:diverting_user2_address;cause=302?Privacy=none>;index=1.1;mp=1,
<sip:last_diverting_target;cause=486>;index=1.1.1;mp=1.1
INVITE sip:last_diverting_target; cause=486
History-Info:
<sip:diverting_user1_address?Privacy=history>;index=1,
<sip:diverting_user2_address;cause=302?Privacy=none>;index=1.1;mp=1,
<sip:last_diverting_target;cause=486>;index=1.1.1;mp=1.1
Mapped into:
映射到：
Diversion:
<sip:diverting_user2_address>;reason=user-busy;counter=1;privacy=off,
<sip:diverting_user1_address>;reason=unconditional;counter=1;privacy=
full
Diversion:
<sip:diverting_user2_address>;reason=user-busy;counter=1;privacy=off,
<sip:diverting_user1_address>;reason=unconditional;counter=1;privacy=
full
7.3. Example with Two SIP Networks Using History-Info Header Field Interworking with a SIP Network Using Diversion Header Field
7.3. 使用历史信息头字段的两个SIP网络与使用转移头字段的SIP网络交互的示例
A -> P1 -> B -> C -> P2 -> D-> E A, B, C, D and E are users. B, C and D have call forwarding service invoked. P1 and P2 are proxies. Only relevant information is shown on the following call flow.
A->P1->B->C->P2->D->E A、B、C、D和E是用户。B、 C和D调用了呼叫转移服务。P1和P2是代理。以下调用流中仅显示相关信息。
IWF* IWF*
SIP network using | SIP network using |SIP net.
History-Info | Diversion |using
| History-Info
| |
UA A P1 AS B | P2 AS C UA C AS D | UA E
| | | | | | | | | |
|INV B | | | | | | | | |
|------>| | | | | | | | |
| | | | | | | | | |
| |INV B | | | | | | | |
| |------>| | | | | | | |
| |Supported: histinfo | | | | | |
| | History-Info: | | | | | |
| | <sip:proxyP1>;index=1, | | | | |
| | <sip:userB>;index=1.1;rc=1 | | | | |
| | | | | | | | | |
| | |INV C | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | <sip:proxyP1>;index=1, | | | | |
| | <sip:userB>;index=1.1;rc=1, | | | |
| | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 | |
| | | | | | | | | |
| | | |INV C | | | | | |
| | | |----->| | | | | |
| | | Diversion: | | | | | |
| | <sip:userB>;reason=unconditional;counter=1;privacy=off|
| | | |History-Info: | | | | |
| | | <sip:proxyP1>;index=1, | | | |
| | | <sip:userB>;index=1.1;rc=1, | | |
| | | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 |
| | | | | | | | | |
| | | | |INV C | | | | |
| | | | |------>| | | | |
| | | | No modification of Diversion header |
| | | | | | | | | |
| | | | | |INV C | | | |
| | | | | |------>| | | |
| | | | | | | | | |
| | | | | |<--180-| | | |
| | | | | | | | | |
| | | | | No response timer expires | |
| | | | | |---INV D --->| | |
| | |Diversion: | | |
| | <sip:userC>;reason=no-answer;counter=1;privacy=full, |
| | <sip:userB>;reason=unconditional;counter=1;privacy=off|
| | | History-Info: | | |
IWF* IWF*
SIP network using | SIP network using |SIP net.
History-Info | Diversion |using
| History-Info
| |
UA A P1 AS B | P2 AS C UA C AS D | UA E
| | | | | | | | | |
|INV B | | | | | | | | |
|------>| | | | | | | | |
| | | | | | | | | |
| |INV B | | | | | | | |
| |------>| | | | | | | |
| |Supported: histinfo | | | | | |
| | History-Info: | | | | | |
| | <sip:proxyP1>;index=1, | | | | |
| | <sip:userB>;index=1.1;rc=1 | | | | |
| | | | | | | | | |
| | |INV C | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | <sip:proxyP1>;index=1, | | | | |
| | <sip:userB>;index=1.1;rc=1, | | | |
| | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 | |
| | | | | | | | | |
| | | |INV C | | | | | |
| | | |----->| | | | | |
| | | Diversion: | | | | | |
| | <sip:userB>;reason=unconditional;counter=1;privacy=off|
| | | |History-Info: | | | | |
| | | <sip:proxyP1>;index=1, | | | |
| | | <sip:userB>;index=1.1;rc=1, | | |
| | | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 |
| | | | | | | | | |
| | | | |INV C | | | | |
| | | | |------>| | | | |
| | | | No modification of Diversion header |
| | | | | | | | | |
| | | | | |INV C | | | |
| | | | | |------>| | | |
| | | | | | | | | |
| | | | | |<--180-| | | |
| | | | | | | | | |
| | | | | No response timer expires | |
| | | | | |---INV D --->| | |
| | |Diversion: | | |
| | <sip:userC>;reason=no-answer;counter=1;privacy=full, |
| | <sip:userB>;reason=unconditional;counter=1;privacy=off|
| | | History-Info: | | |
| | | <sip:proxyP1>;index=1, | | |
| | | <sip:userB>;index=1.1;rc=1, | | |
| | | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 |
| | | | | | | | | |
| | | | | | | |INV E | |
| | | | | | | |----->| |
| | |Diversion: | |
| | <sip:userD>;reason=time-of-day;counter=1;privacy=off, |
| | <sip:userC>;reason=no-answer;counter=1;privacy=full, |
| | <sip:userB>;reason=unconditional;counter=1;privacy=off|
| | | History-Info: | |
| | | <sip:proxyP1>;index=1, | |
| | | <sip:userB>;index=1.1;rc=1, | |
| | | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 |
| | | | | | | | | |
| | | | | | | | | INV E |
| | | | | | | | |------>|
| | History-Info: | | | | | |
| | <sip:proxyP1>;index=1, | | | | |
| | <sip:userB>;index=1.1;rc=1, | | | |
| | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1, | |
| | <sip:userC ?Privacy=history>;index=1.1.1.0.1, | |
|<sip:userD;cause=408?Privacy=none>;index=1.1.1.0.1.1;mp=1.1.1.0.1, |
| |<sip:userE;cause=404>;index=1.1.1.0.1.1.1;mp=1.1.1.0.1.1 |
| | | | | | | | | |
| | | | | | | | | |
| | | <sip:proxyP1>;index=1, | | |
| | | <sip:userB>;index=1.1;rc=1, | | |
| | | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 |
| | | | | | | | | |
| | | | | | | |INV E | |
| | | | | | | |----->| |
| | |Diversion: | |
| | <sip:userD>;reason=time-of-day;counter=1;privacy=off, |
| | <sip:userC>;reason=no-answer;counter=1;privacy=full, |
| | <sip:userB>;reason=unconditional;counter=1;privacy=off|
| | | History-Info: | |
| | | <sip:proxyP1>;index=1, | |
| | | <sip:userB>;index=1.1;rc=1, | |
| | | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 |
| | | | | | | | | |
| | | | | | | | | INV E |
| | | | | | | | |------>|
| | History-Info: | | | | | |
| | <sip:proxyP1>;index=1, | | | | |
| | <sip:userB>;index=1.1;rc=1, | | | |
| | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1, | |
| | <sip:userC ?Privacy=history>;index=1.1.1.0.1, | |
|<sip:userD;cause=408?Privacy=none>;index=1.1.1.0.1.1;mp=1.1.1.0.1, |
| |<sip:userE;cause=404>;index=1.1.1.0.1.1.1;mp=1.1.1.0.1.1 |
| | | | | | | | | |
| | | | | | | | | |
Note: The IWF is an interworking function that could be a stand-alone equipment not defined in this document (it could be a proxy).
注：IWF是一种互通功能，可以是本文件中未定义的独立设备（可以是代理）。
Even for particular cases in which both header fields could coexist, it should be the responsibility of the network local policy to make it work together. This section describes some situations and some recommendations on behavior.
即使在两个报头字段可以共存的特定情况下，网络本地策略也应负责使其协同工作。本节描述了一些情况和一些行为建议。
In the case where there is one network that includes different nodes, some of them supporting the Diversion header field and other ones supporting the History-Info header field, there is a problem when any node handling a message does not know the next node that will handle the message. This case can occur when the network has new and old nodes, the older ones using the Diversion header field and the most recent using the History-Info header field.
如果有一个网络包含不同的节点，其中一些节点支持转移头字段，另一些节点支持历史信息头字段，则当处理消息的任何节点不知道将处理消息的下一个节点时，就会出现问题。当网络具有新节点和旧节点时，可能会发生这种情况，旧节点使用分流标头字段，最近节点使用历史信息标头字段。
While a network replacement may be occurring, there will be a time when both nodes coexist in the network. If the different nodes are being used to support different subscriber types due to different
虽然可能会发生网络替换，但会有一段时间两个节点在网络中共存。如果由于不同的原因使用不同的节点来支持不同的订户类型
node capabilities, then the problem is more important. In this case, there is a need to pass both the History-Info header field and the Diversion header field within the core network.
节点能力，那么问题就更重要了。在这种情况下，需要在核心网络内传递历史信息报头字段和分流报头字段。
These header fields need to be equivalent to ensure that, whatever the node receiving the message, the correct diversion information is received. This requires that, whatever the received header field, there is a requirement to be able to compare the header fields and to convert the header fields. Depending upon the node capability, it may be possible to make assumptions as to how this is handled.
这些头字段需要等效，以确保无论接收消息的节点是什么，都能接收到正确的转移信息。这就要求，无论接收到的头字段是什么，都需要能够比较头字段并转换头字段。根据节点的能力，可以对如何处理这一问题做出假设。
o If it is known that the older Diversion header field supporting nodes does not pass on any received History-Info header field, then the interworking becomes easier. If a message is received with only Diversion header fields, then it has originated from an old node. The equivalent History-Info entries can be created, and these can then be passed as well as the Diversion header field.
o 如果已知支持节点的旧分流头字段没有传递任何接收到的历史信息头字段，则互通变得更容易。如果接收到的消息仅包含转移头字段，则该消息来自旧节点。可以创建等效的历史信息条目，然后可以传递这些条目以及分流标题字段。
o If the node creates a new History-Info header field for a call diversion, then an additional Diversion header field must be created.
o 如果节点为呼叫转接创建一个新的历史信息头字段，则必须创建一个额外的转接头字段。
o If the next node is an old node, then the Diversion header field will be used by that node, and the History-Info entries will be removed from the message when it is passed on.
o 如果下一个节点是旧节点，则该节点将使用“转移头”字段，并且在传递消息时将从消息中删除历史信息条目。
o If the next node is a new node, then the presence of both the Diversion header field and History-Info header field means that interworking has already occurred and the Diversion and History-Info entries must be considered equivalent.
o 如果下一个节点是新节点，则“分流头”字段和“历史信息头”字段的存在意味着互通已经发生，且分流和历史信息条目必须视为等效。
o If both nodes pass on both the History-Info header field and Diversion header field but only actively use one, then both types of nodes need to perform the interworking and must maintain equivalence between the header fields. This will eventually result in the use of the Diversion header field being deprecated when all nodes in the network support the History-Info header field.
o 如果两个节点同时传递历史信息报头字段和分流报头字段，但仅主动使用一个，则两种类型的节点都需要执行互通，并且必须保持报头字段之间的等效性。当网络中的所有节点都支持历史信息标头字段时，这最终将导致不推荐使用“分流标头”字段。
o If a gap is identified in the History-Info header field by a node that would create a new entry, it shall add a single index with a value of "0" prior to adding the appropriate index for the action to be taken.
o 如果将创建新条目的节点在历史信息标题字段中识别出差距，则应在为要采取的行动添加适当的索引之前，添加一个值为“0”的索引。
Issues with backward compatibility are due to the evolution of the History-Info header field from [RFC4244] to [RFC7044], as described in Section 1.3 of this document. Backward compatibility is taken into account throughout this document for the interworking with the Diversion header field. More details are provided in the "Backwards Compatibility" section of [RFC7044].
向后兼容性问题是由于历史信息标题字段从[RFC4244]演变为[RFC7044]所致，如本文件第1.3节所述。在本文件中，为了与导流总管字段进行交互，考虑了向后兼容性。[RFC7044]的“向后兼容性”部分提供了更多详细信息。
The security considerations in [RFC7044] and [RFC5806] apply.
[RFC7044]和[RFC5806]中的安全注意事项适用。
The privacy considerations described in Section 3.2 apply.
第3.2节所述的隐私注意事项适用。
The use of the Diversion header field or History-Info header field requires application of the requested privacy and integrity requested by each diverting user or entity. Without integrity, the requested privacy functions could be downgraded or eliminated, potentially exposing identity information. Without confidentiality, eavesdroppers on the network (or any intermediaries between the user and the Privacy Service) could see the very personal information that the user has asked the Privacy Service to obscure. Unauthorized insertion and deletion/modification of those header fields can provide misleading information to users and applications. A SIP entity that can provide a redirection reason in a History-Info header field or Diversion header field should be able to suppress this in accordance with privacy requirements of the user concerned.
使用转移头字段或历史信息头字段需要应用每个转移用户或实体请求的隐私和完整性。如果没有完整性，请求的隐私功能可能被降级或删除，从而可能暴露身份信息。在没有保密性的情况下，网络上的窃听者（或用户与隐私服务之间的任何中间人）可以看到用户要求隐私服务掩盖的非常私人的信息。未经授权插入和删除/修改这些标题字段可能会向用户和应用程序提供误导性信息。能够在历史信息报头字段或转移报头字段中提供重定向原因的SIP实体应能够根据相关用户的隐私要求抑制这种情况。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <http://www.rfc-editor.org/info/rfc3323>.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC 3323，DOI 10.17487/RFC3323，2002年11月<http://www.rfc-editor.org/info/rfc3323>.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, <http://www.rfc-editor.org/info/rfc3326>.
[RFC3326]Schulzrinne，H.，Oran，D.，和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC 3326，DOI 10.17487/RFC3326，2002年12月<http://www.rfc-editor.org/info/rfc3326>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，DOI 10.17487/RFC3966，2004年12月<http://www.rfc-editor.org/info/rfc3966>.
[RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, DOI 10.17487/RFC4244, November 2005, <http://www.rfc-editor.org/info/rfc4244>.
[RFC4244]Barnes，M.，Ed.“请求历史信息会话启动协议（SIP）的扩展”，RFC 4244，DOI 10.17487/RFC4244，2005年11月<http://www.rfc-editor.org/info/rfc4244>.
[RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, <http://www.rfc-editor.org/info/rfc5806>.
[RFC5806]Levy，S.和M.Mohali，编辑，“SIP中的分流指示”，RFC 5806，DOI 10.17487/RFC5806，2010年3月<http://www.rfc-editor.org/info/rfc5806>.
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, DOI 10.17487/RFC7044, February 2014, <http://www.rfc-editor.org/info/rfc7044>.
[RFC7044]Barnes，M.，Audet，F.，Schubert，S.，van Elburg，J.，和C.Holmberg，“请求历史信息会话启动协议（SIP）的扩展”，RFC 7044，DOI 10.17487/RFC70442014年2月<http://www.rfc-editor.org/info/rfc7044>.
[Err1409] RFC Errata, Erratum ID 1409, RFC 4458.
[Err1409]RFC勘误表，勘误表ID 1409，RFC 4458。
[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, DOI 10.17487/RFC4458, April 2006, <http://www.rfc-editor.org/info/rfc4458>.
[RFC4458]Jennings，C.，Audet，F.，和J.Elwell，“语音邮件和交互式语音应答（IVR）等应用程序的会话启动协议（SIP）URI”，RFC 4458，DOI 10.17487/RFC4458，2006年4月<http://www.rfc-editor.org/info/rfc4458>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC6044] Mohali, M., "Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", RFC 6044, DOI 10.17487/RFC6044, October 2010, <http://www.rfc-editor.org/info/rfc6044>.
[RFC6044]Mohali，M.“会话启动协议（SIP）中转移和历史信息头之间转移信息的映射和互通”，RFC 6044，DOI 10.17487/RFC60442010年10月<http://www.rfc-editor.org/info/rfc6044>.
[TS_24.604] 3rd Generation Partnership Project, "Communication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification", Release 13.1, 3GPP TS 24.604, June 2015.
[TS_24.604]第三代合作项目，“使用IP多媒体（IM）核心网络（CN）子系统的通信转移（CDIV）；协议规范”，第13.1版，3GPP TS 24.6042015年6月。
[TS_29.163] 3rd Generation Partnership Project, "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks", Release 13.2, 3GPP TS 29.163, June 2015.
[TS_29.163]第三代合作项目，“IP多媒体（IM）核心网络（CN）子系统与电路交换（CS）网络之间的互通”，第13.2版，3GPP TS 29.163，2015年6月。
Appendix A. Interworking between Diversion Header Field and Voicemail URI
附录A.分流头字段和语音邮件URI之间的互通
Voicemail URI is a mechanism described in [RFC4458] to provide a simple way to transport only one redirecting user address and the reason why the diversion occurred in the Request-URI of the INVITE request. This mechanism is mainly used for call diversion to a voicemail.
语音邮件URI是[RFC4458]中描述的一种机制，提供了一种只传输一个重定向用户地址的简单方法，以及在INVITE请求的请求URI中发生转移的原因。此机制主要用于呼叫转移到语音邮件。
Received:
Diversion: userA-address;reason=user-busy;counter=1;privacy=full
Received:
Diversion: userA-address;reason=user-busy;counter=1;privacy=full
Sent (Voicemail URI created in the R-URI line of the INVITE):
sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0
Sent (Voicemail URI created in the R-URI line of the INVITE):
sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0
Mapping of the Redirection Reason is the same as for History-Info header field with a default value set to 404.
重定向原因的映射与历史信息头字段的映射相同，默认值设置为404。
If the Diversion header field contains more than one Diversion entry, the choice of the redirecting user information inserted in the URI is in charge of the network local policy. For example, the choice criterion of the redirecting information inserted in the URI could be the destination of forwarded INVITE request (whether or note the voicemail serves this user).
如果转移头字段包含多个转移条目，则URI中插入的重定向用户信息的选择由网络本地策略负责。例如，URI中插入的重定向信息的选择标准可以是转发的INVITE请求的目的地（无论语音邮件是否为该用户服务）。
Note: This interworking could be done in addition to the interworking of the Diversion header field into the History-Info header field.
注：除了分流头字段与历史信息头字段的互通之外，还可以进行此互通。
In case of real voicemail, this way of interworking should not happen. However, if for any reason it occurs, it is recommended to do it as follows:
对于真正的语音邮件，这种互通方式不应该发生。但是，如果出于任何原因发生这种情况，建议按以下方式进行：
Received:
INVITE sip: voicemail@example.com;\
target=sip:+33145454500%40example.com;user=phone;\
cause=302 SIP/2.0
Received:
INVITE sip: voicemail@example.com;\
target=sip:+33145454500%40example.com;user=phone;\
cause=302 SIP/2.0
Sent in the forwarded INVITE:
Diversion: sip:+33145454500%40example.com;user=phone;
reason=unconditional;counter=1
Sent in the forwarded INVITE:
Diversion: sip:+33145454500%40example.com;user=phone;
reason=unconditional;counter=1
Acknowledgements
致谢
The author would like to acknowledge the constructive feedback and support provided by Steve Norreys, Jan Van Geel, Martin Dolly, Francisco Silva, Guiseppe Sciortino, Cinza Amenta, Christer Holmberg, Ian Elz, Jean-Francois Mule, Mary Barnes, Francois Audet, Erick Sasaki, Shida Schubert, Joel M. Halpern, Bob Braden, Robert Sparks, Merci a Lionel Morand, and Xavier Marjou et Philippe Fouquart.
作者要感谢史蒂夫·诺里斯、扬·范吉尔、马丁·多利、弗朗西斯科·席尔瓦、吉塞佩·肖尔蒂诺、辛扎·阿曼达、克里斯特·霍姆伯格、伊恩·埃尔兹、让·弗朗索瓦·穆勒、玛丽·巴恩斯、弗朗索瓦·奥德特、埃里克·萨斯基、实达·舒伯特、乔尔·M·哈尔彭、鲍勃·布莱登、罗伯特·斯帕克斯、，谢谢你，莱昂内尔·莫兰德，泽维尔·马约和菲利普·福夸特。
Author's Address
作者地址
Marianne Mohali Orange 38-40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France
Marianne Mohali Orange Leclerc Issy Les Moulineaux Cedex路38-40号法国9 92794
Phone: +33 1 45 29 45 14
Email: marianne.mohali@orange.com
Phone: +33 1 45 29 45 14
Email: marianne.mohali@orange.com