Independent Submission M. Mohali
Request for Comments: 6044 France Telecom Orange
Category: Informational October 2010
ISSN: 2070-1721
Independent Submission M. Mohali
Request for Comments: 6044 France Telecom Orange
Category: Informational October 2010
ISSN: 2070-1721
Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中转移和历史信息头之间转移信息的映射和互通
Abstract
摘要
Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.
尽管SIP历史信息报头是IETF中采用的解决方案，但非标准转移报头仍然被广泛地实现并用于在SIP信令中传送呼叫转移相关信息。
This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806.
本文档描述了转接头和历史信息头之间处理呼叫转接信息的推荐互通指南。此外，还提出了一种互通策略来管理报头的共存。历史信息标题在RFC 4244中描述，非标准导流标题在RFC 5806中描述为历史。
Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non-standard implementations and deployment toward IETF specification-based implementations and deployment.
由于转接头在许多现有网络实现中用于传输呼叫转接信息，因此需要将其与SIP历史信息标准化解决方案进行互通。这项工作旨在实现从非标准实现和部署到基于IETF规范的实现和部署的迁移。
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/rfc6044.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6044.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 ....................................................3
1.1. Overview ...................................................3
1.2. Background .................................................3
2. Problem Statement ...............................................4
2.1. Interworking Requirements and Scope ........................4
2.2. Interworking Recommendations ...............................6
2.2.1. SIP Network/Terminal Using Diversion to SIP
Network/Terminal Using History-Info Header ..........6
2.2.2. SIP Network/Terminal Using History-Info
Header to SIP Network/terminal Using Diversion
Header ..............................................8
3. Headers Syntaxes Reminder .......................................9
3.1. History-Info Header Syntax .................................9
3.2. Diversion Header Syntax ...................................11
4. Headers in SIP Method ..........................................11
5. Diversion Header to History-Info Header ........................12
6. History-Info Header to Diversion Header ........................15
7. Examples .......................................................17
7.1. Example with Diversion Header Changed into
History-Info Header .......................................17
7.2. Example with History-Info Header Changed into
Diversion Header ..........................................17
7.3. Example with Two SIP Networks Using History-Info Header ...17
7.4. Additional Interworking Cases .............................19
8. Security Considerations ........................................20
9. Acknowledgements ...............................................21
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................21
Appendix A. Interworking between Diversion Header and
Voicemail URI ........................................23
1. Introduction ....................................................3
1.1. Overview ...................................................3
1.2. Background .................................................3
2. Problem Statement ...............................................4
2.1. Interworking Requirements and Scope ........................4
2.2. Interworking Recommendations ...............................6
2.2.1. SIP Network/Terminal Using Diversion to SIP
Network/Terminal Using History-Info Header ..........6
2.2.2. SIP Network/Terminal Using History-Info
Header to SIP Network/terminal Using Diversion
Header ..............................................8
3. Headers Syntaxes Reminder .......................................9
3.1. History-Info Header Syntax .................................9
3.2. Diversion Header Syntax ...................................11
4. Headers in SIP Method ..........................................11
5. Diversion Header to History-Info Header ........................12
6. History-Info Header to Diversion Header ........................15
7. Examples .......................................................17
7.1. Example with Diversion Header Changed into
History-Info Header .......................................17
7.2. Example with History-Info Header Changed into
Diversion Header ..........................................17
7.3. Example with Two SIP Networks Using History-Info Header ...17
7.4. Additional Interworking Cases .............................19
8. Security Considerations ........................................20
9. Acknowledgements ...............................................21
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................21
Appendix A. Interworking between Diversion Header and
Voicemail URI ........................................23
For some VoIP-based (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 headers: the History-Info header defined in [RFC4244] and the historic Diversion header defined in [RFC5806], which are both able to transport diversion information in SIP signaling.
对于一些基于VoIP的（IP语音）服务（例如，语音邮件、交互式语音识别（IVR）或自动呼叫分配），被呼叫的SIP用户代理可以识别会话从谁处转移以及转移的原因。要使这些信息被各种服务提供商或应用程序使用，它需要通过网络。这可以通过两个不同的SIP头实现：在[RFC4244]中定义的历史信息头和在[RFC5806]中定义的历史转移头，这两个头都能够在SIP信令中传输转移信息。
Although the Diversion header is not standardized, it is widely used. Therefore, it is useful to have guidelines to make this header interwork with the standard History-Info header.
尽管导流集管没有标准化，但它被广泛使用。因此，有指导方针使此标头与标准历史信息标头相互作用是很有用的。
Note that the new implementation and deployment of the Diversion header is strongly discouraged.
请注意，强烈反对新实施和部署分流总管。
This document provides a mechanism for header-content translation between the Diversion header and the History-Info header.
本文档提供了一种在分流标题和历史信息标题之间进行标题内容转换的机制。
The History-Info header [RFC4244] and its extension for forming SIP service URIs (including Voicemail URI) [RFC4458] are recommended by the IETF to convey redirection information. They are also recommended in the "Communication Diversion (CDIV) service" Third Generation Partnership Project (3GPP) specification [TS_24.604].
IETF建议使用历史信息头[RFC4244]及其用于形成SIP服务URI（包括语音邮件URI）[RFC4458]的扩展来传递重定向信息。在“通信转移（CDIV）服务”第三代合作伙伴关系项目（3GPP）规范[TS_24.604]中也推荐了它们。
Originally, the Diversion header was described in a document that was submitted to the SIP Working Group. It has been published now as [RFC5806] for the historical record and to provide a reference for this RFC.
最初，在提交给SIP工作组的文件中描述了分流总管。它现在已作为[RFC5806]出版，用于历史记录，并为本RFC提供参考。
This header contains a list of diverting URIs and associated information providing specific information as the reason for the call diversion. Most existing SIP-based implementations have implemented the Diversion header when no standard solution was ready to deploy. The IETF has finally standardized the History-Info header, partly because it can transport general history information. This allows the receiving part to determine how and why the session is received. As the History-Info header may contain further information than call diversion information, it is critical to avoid losing information and
此标头包含转移URI和相关信息的列表，这些信息提供了作为呼叫转移原因的特定信息。大多数现有的基于SIP的实现都在没有标准解决方案可供部署时实现了分流头。IETF最终对历史信息头进行了标准化，部分原因是它可以传输一般历史信息。这允许接收部分确定如何以及为什么接收会话。由于历史信息标头可能包含比呼叫转移信息更多的信息，因此避免丢失信息和
be able to extract the relevant data using the retargeting cause URI parameter described in [RFC4458] for the transport of the diversion reason.
能够使用[RFC4458]中描述的重定目标原因URI参数提取用于转移原因传输的相关数据。
The Diversion header and the History-Info header have different syntaxes, described below. Note that the main difference is that the History-Info header is a chronological writing header whereas the Diversion header 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 and the Voicemail URI, which is another way to convey diversion information. The Voicemail URI is defined in [RFC4458].
附录A提供了分流头和语音邮件URI之间的互通指南，这是传递分流信息的另一种方式。语音邮件URI在[RFC4458]中定义。
This section provides the baseline terminology used in the rest of the document and defines the scope of interworking between the Diversion header and the History-Info header.
本节提供了文档其余部分中使用的基线术语，并定义了分流标题和历史信息标题之间的互通范围。
There are many ways in which SIP signaling can be used to modify a session destination before it is established, and there are 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 lead to changing the destination. For example, whether it is for a simple proxy to route the session or for an application server to provide a supplementary service. The Diversion header and the History-Info header differ in the approach and scope of addressing this problem.
在会话目的地建立之前，可以通过多种方式使用SIP信令修改会话目的地，这样做的原因很多。需要进一步处理会话下游的SIP实体的行为有时会因导致更改目的地的原因而有所不同。例如，无论是简单代理路由会话，还是应用服务器提供补充服务。分流标题和历史信息标题在解决此问题的方法和范围上有所不同。
For clarity, the following vocabulary is used in this document:
为清楚起见，本文件中使用了以下词汇：
o Retargeting/redirecting: retargeting/redirecting refers to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request and thus changing the target of the request. These terms are defined in [RFC4244]. The History-Info header is used to capture retargeting information.
o 重定目标/重定向：重定目标/重定向是指代理服务器/用户代理客户端（UAC）更改请求中的统一资源标识符（URI），从而更改请求目标的过程。这些术语的定义见[RFC4244]。历史信息标头用于捕获重定目标信息。
o Call forwarding/call diversion/communication diversion: these terms are equivalent and refer to the Communications Diversion (CDIV) supplementary services, based on the Integrated Services Digital Network (ISDN) Communication diversion supplementary
o 呼叫转移/呼叫转移/通信转移：这些术语相当于通信转移（CDIV）补充业务，基于综合业务数字网（ISDN）通信转移补充业务
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.
3GPP[TS_24.604]中定义的服务和服务。它们适用于拟在会话建立期间或之前修改IP多媒体会话的原始目的地的实体。
This document does not intend to describe when or how History-Info or Diversion headers should be used. Hereafter is provided clarification on the context in which the interworking is required.
本文档不打算描述何时或如何使用历史信息或分流标题。下文对需要互通的上下文进行了澄清。
The Diversion header has exactly the same scope as the call diversion service and each header entry reflects a call diversion invocation. The Diversion header is used for recording call forwarding information, which could be useful to network entities downstream. Today, this SIP header is implemented by several manufacturers and deployed in networks.
转移头与调用转移服务的作用域完全相同，每个头条目都反映了调用转移调用。转移报头用于记录呼叫转移信息，这对下游网络实体可能有用。今天，这个SIP头由几个制造商实现并部署在网络中。
The History-Info header is used to store all retargeting information including call diversion information. In practice, the History-Info header [RFC4244] is used to convey call-diversion-related information by using a cause URI parameter [RFC4458] in the relevant entry. 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 History-Info header and one using the Diversion header.
历史信息头用于存储所有重定目标信息，包括呼叫转移信息。实际上，历史信息报头[RFC4244]通过在相关条目中使用原因URI参数[RFC4458]来传递呼叫转移相关信息。然而，请注意，在呼叫转移的历史信息条目中使用原因URI参数[RFC4458]特定于3GPP规范[TS_24.604]。[RFC4458]重点关注语音邮件服务器的重定目标，不指定是否应在其他情况下的URI中添加原因URI参数。因此，对于本文档中描述的映射，不考虑对呼叫转发信息不使用cause URI参数的实现。尽管如此，下一节将给出一些建议，说明如何避免在使用历史信息标头的网络区域和使用分流标头的网络区域之间的边界处丢失非映射信息。
Since both headers 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 headers must not independently coexist in the same session signaling. This document addresses how to convert information between the Diversion header and the History-Info header, and when and how to preserve both headers to cover additional cases.
由于这两个报头都满足呼叫转发需求，因此如果两个报头在INVITE请求中以不协调的方式出现，则转移信息可能会混淆或不一致。因此，转移和历史信息头不能独立地共存于同一会话信令中。本文档介绍如何在分流标题和历史信息标题之间转换信息，以及何时和如何保留这两个标题以涵盖其他情况。
For the transportation of consistent diversion information downstream, it is necessary to make the two headers interwork. Interworking between the Diversion header and the History-Info header is introduced in sections 5 and 6. Since the coexistence scenario may vary from one use case to another one, guidelines regarding headers interaction are proposed.
为了向下游输送一致的分流信息，有必要使两个总管互通。第5节和第6节介绍了导流总管和历史信息总管之间的互通。由于共存场景可能因用例而异，因此提出了关于头交互的指导原则。
Interworking function:
互通功能：
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 History-Info header and one using Diversion header.
在正常情况下，网络拓扑假设本文档中描述的互通应由特定SIP边界设备执行，该设备通过配置知道它位于两个区域之间的边界，一个使用历史信息报头，另一个使用转移报头。
As History-Info header is a standard solution, a network using the Diversion header must be able to provide information to a network using the History-Info header. In this case, to avoid header coexistence, it is required to replace, as often as possible, the Diversion header with the History-Info header in the INVITE request during the interworking.
由于历史信息报头是一种标准解决方案，使用分流报头的网络必须能够使用历史信息报头向网络提供信息。在这种情况下，为了避免报头共存，需要在互通过程中尽可能经常地在INVITE请求中用History Info报头替换分流报头。
Since, the History-Info header has a wider scope than the Diversion header, it may be used for other needs and services than call diversion. In addition to trace call diversion information, the History-Info header also acts as a session history and can store all successive R-URI values. Consequently, even if it should be better to remove the History-Info header after the creation of the Diversion header to avoid confusion, the History-Info header must remain unmodified in the SIP signaling if it contains supplementary (non-diversion) information. It is possible to have History-Info headers that do not have values that can be mapped into the Diversion header. In this case, no interworking with Diversion header should be performed, and it must be defined per implementation what to do in this case. This point is left out of the scope of this document.
由于历史信息标头的范围比转接标头更广，因此它可能用于呼叫转接以外的其他需求和服务。除了跟踪呼叫转移信息外，History-Info报头还充当会话历史，可以存储所有连续的R-URI值。因此，即使最好在创建转移头之后删除历史信息头以避免混淆，如果历史信息头包含补充（非转移）信息，则它必须在SIP信令中保持未修改。历史信息标题可能没有可映射到分流标题中的值。在这种情况下，不应执行与导流总管的互通，并且必须根据实施情况定义在这种情况下的操作。这一点不在本文件的范围之内。
As a 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 common use case. Additional interworking cases are described in section 7.5.
以下部分描述了基本的通用用例。第7.5节描述了其他互通情况。
2.2.1. SIP Network/Terminal Using Diversion to SIP Network/Terminal Using History-Info Header
2.2.1. 使用转移到SIP网络的SIP网络/终端/使用历史信息头的终端
When the Diversion header is used to create a History-Info header, the Diversion header must be removed in the outgoing INVITE. It is considered that all of the information present in the Diversion header is transferred in the History-Info header.
当分流标头用于创建历史信息标头时，必须在传出邀请中删除分流标头。可以认为，分流标头中存在的所有信息都在历史信息标头中传输。
If a History-Info header is present in the incoming INVITE (in addition to Diversion header), the Diversion header and History-Info header present must be mixed and only the diversion information not yet present in the History-Info header must be inserted as a last entry (more recent) in the existing History-Info header, as recommended in [RFC4244].
如果传入邀请中存在历史信息标头（除了转移标头），则转移标头和存在的历史信息标头必须混合，并且只有历史信息标头中尚未存在的转移信息必须作为现有历史信息标头中的最后一项（较新）插入，如[RFC4244]中所建议.
As an example, this could be the case of an INVITE coming from network_2 using the Diversion header but previously passed through network_1 using the History-Info header (or the network_2 uses History-Info header to transport successive URI information) and going to network_3 using the History-Info header.
例如，这可能是这样的情况：一个邀请来自使用转移头的网络_2，但之前通过使用历史信息头的网络_1（或网络_2使用历史信息头传输连续的URI信息），然后使用历史信息头到达网络_3。
IWF* IWF*
network1 | network_2 |network_3
History-Info | Diversion |using
| |Hist-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 | | | | |
| | | | | | | | | |
| | |INVITE | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | |<sip:proxyP1>; index=1,| | | | |
| | |<sip:userB>; index=1.1 | | | | |
| | |<sip:userC>; cause=302; index=1.1.1 | | |
IWF* IWF*
network1 | network_2 |network_3
History-Info | Diversion |using
| |Hist-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 | | | | |
| | | | | | | | | |
| | |INVITE | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | |<sip:proxyP1>; index=1,| | | | |
| | |<sip:userB>; index=1.1 | | | | |
| | |<sip:userC>; cause=302; index=1.1.1 | | |
In this case, the incoming INVITE contains a Diversion header and a History-Info header. Therefore, as recommended in this document, it is necessary to create, for network_3, a single History-Info header gathering existing information from both the History-Info and the Diversion headers received. Anyway, it is required from network_2 (i.e., IWF) to remove the Diversion header when the message is going to a network not using the Diversion header. Then, network_3 could use call forwarding information that is present in a single header and add its own diversion information if necessary.
在这种情况下，传入的INVITE包含一个转移头和一个历史信息头。因此，根据本文件的建议，有必要为网络_3创建一个历史信息头，从接收到的历史信息和分流头收集现有信息。无论如何，当消息发送到不使用转移头的网络时，需要从网络2（即IWF）删除转移头。然后，网络_3可以使用存在于单个报头中的呼叫转发信息，并在必要时添加其自己的转移信息。
Notes:
笔记：
1. If a network is not able either to use only one header each time or to maintain both headers up to date, the chronological order cannot be certified.
1. 如果网络不能每次仅使用一个标头，或者不能将两个标头都保持为最新，则无法验证时间顺序。
2. It is not possible to have only a Diversion header when the History-Info header 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 taking into account the Diversion internal chronology.
2. 当历史信息标头包含的呼叫转移信息超过个时，不可能只有转移标头。如果应用了以前的政策建议，则将遵循时间顺序，因为考虑到转移内部时间顺序，将在历史信息标题的末尾插入转移条目。
2.2.2. SIP Network/Terminal Using History-Info Header to SIP Network/Terminal Using Diversion Header
2.2.2. 使用历史信息头的SIP网络/终端到使用转移头的SIP网络/终端
When the History-Info header is interpreted to create a Diversion header, some precautions must be taken.
当解释历史信息标题以创建分流标题时，必须采取一些预防措施。
If the History-Info header contains only call forwarding information, then it must be deleted after the interworking.
如果历史信息头仅包含呼叫转移信息，则必须在互通后将其删除。
If the History-Info header contains other information, then only the information of concern to the diverting user must be used to create entries in the Diversion header and the History-Info header must be kept as received in the INVITE and forwarded downstream.
如果历史信息标头包含其他信息，则只有分流用户关心的信息才能用于在分流标头中创建条目，并且历史信息标头必须保持在INVITE中接收并转发到下游。
Note: The History-Info header could be used for other reasons than call diversion services, for example, by a service that needs to know if a specific Application Server (AS) had yet been invoked in the signaling path. If the call is later forwarded to a network using the History-Info header, it would be better not to lose history information due to passing though the network that only supports Diversion headers. A recommended solution must not disrupt the standard behavior and networks that do not implement the History-Info header must be transparent to a received History-Info header.
注意：历史信息头可用于呼叫转移服务以外的其他原因，例如，需要知道特定应用程序服务器（AS）是否已在信令路径中被调用的服务。如果稍后使用历史信息报头将呼叫转发到网络，则最好不要因为通过仅支持转移报头的网络而丢失历史信息。推荐的解决方案不得破坏标准行为，并且未实现历史信息标头的网络必须对接收到的历史信息标头透明。
If a Diversion header is present in the incoming INVITE (in addition to History-Info header), only diversion information present in the History-Info header but not in the Diversion header must be inserted from the last entry (more recent) into the existing Diversion header, 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 enables the recording of sequential forking for the same served user. During an interworking, from the History-Info header to Diversion header, the History-Info entries containing a forking situation (with an incremented "index" parameter) could possibly be mapped if it contains 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 the Appendix).
同样的逻辑也适用于与语音邮件URI的交互（见附录）。
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-targeted-to-uri = name-addr
hi-param = hi-index / hi-extension
hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)
hi-extension = generic-param
hi-entry = hi-targeted-to-uri *( SEMI hi-param )
hi-targeted-to-uri = name-addr
hi-param = hi-index / hi-extension
hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)
hi-extension = generic-param
The History-Info header is specified in [RFC4244]. The top-most History-Info entry (first in the list) corresponds to the oldest history information.
[RFC4244]中指定了历史信息标头。最早的历史信息条目（列表中的第一个）对应最早的历史信息。
A hi-entry may contain a cause URI parameter expressing the diversion reason. This optional cause URI parameter is defined in [RFC4458] with the following syntax:
hi条目可能包含表示转移原因的原因URI参数。[RFC4458]中使用以下语法定义了此可选原因URI参数：
cause-param = "cause" EQUAL Status-Code
原因参数=“原因”相等状态代码
This parameter is also named cause-param 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 the RFC 4458, and 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 a cause value as listed in RFC 4458.
该参数也被命名为cause param，在3GPP CDIV规范[TS_24.604]中建议的呼叫转移情况下，应将其插入转移到用户的历史信息条目（URI）中。RFC 4458中列出了用于转接原因的原因参数中使用的原因值，并且由于它是专用于呼叫转接服务的参数，因此它的存在用于确定hi条目是转接用户。更准确地说，每个分流用户位于hi条目中，位于包含原因参数和原因值的条目之前，如RFC 4458中所列。
Moreover, the Reason header 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 contains a cause parameter set to the true SIP response code received (Status-Code). 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 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 parameter is not taken into account in the mapping with a Diversion header.
此外，当呼叫转移是由于接收到的SIP响应引起时，[RFC3326]中定义的原因报头应在转移用户的hi条目中转义。原因标头包含设置为接收到的真实SIP响应代码（状态代码）的原因参数。因此，在SIP响应导致呼叫转移的情况下，应使用两个原因参数。复杂的是，这些参数可以在历史信息头中同时使用，但不能在同一hi条目中使用，也不能具有相同的含义。只有原因参数专用于呼叫转移服务。“原因”原因标题参数在与分流标题的映射中未被考虑。
[RFC4458] also defines the 'target' URI parameter, which could be inserted in a R-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. From the Diversion header, it could be possible to create the 'target' URI parameter in the hi-entries and/or in the R-URI, but this possibility is based on local policies not described in this document.
[RFC4458]还定义了“target”URI参数，该参数可以插入到R-URI中，从而插入到以URI为目标的hi中。此参数用于在语音邮件URI实现中保持下游INVITE请求中的转移用户地址。由于此信息已存在于hi条目中，“target”URI参数不考虑与分流标头的交互。从分流头，可以在hi条目和/或R-URI中创建“target”URI参数，但这种可能性基于本文档中未描述的本地策略。
A Privacy header, as defined in [RFC3323], could also be included in hi-entries with the 'history' value defined in the [RFC4244].
[RFC3323]中定义的隐私头也可以包含在hi条目中，hi条目的“历史”值在[RFC4244]中定义。
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”参数的规则如何（必须应用），该参数对映射没有影响，只能与服务用户地址一起复制。
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,
<sip:last_diversion_target;cause=486>; index=1.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,
<sip:last_diversion_target;cause=486>; index=1.1.1
Policy concerning "histinfo" option tag in Supported header: According to [RFC4244], a proxy that receives a Request with the "histinfo" option tag in the Supported header 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.
有关受支持标头中“histinfo”选项标记的策略：根据[RFC4244]，接收受支持标头中带有“histinfo”选项标记的请求的代理应在对请求的后续、临时和最终响应中返回捕获的历史信息。该行为取决于本地策略是否支持捕获历史信息。
The following text is restating the exact syntax that the production rules in [RFC5806] define, but using [RFC5234] ABNF:
下面的文本重新说明了[RFC5806]中的产生式规则定义的确切语法，但使用了[RFC5234]ABNF：
Diversion = "Diversion" HCOLON diversion-params *(COMMA diversion-params)
Diversion=“Diversion”HCOLON分流参数*（逗号分流参数）
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-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 could be used in the comma-separated format, as described below, and in a header-separated format. Both formats could be combined a received INVITE as recommended in [RFC3261].
注：导流总管可采用逗号分隔格式（如下所述）和表头分隔格式。按照[RFC3261]中的建议，这两种格式可以组合为收到的邀请。
Example:
例子：
Diversion:
改道：
diverting_user2_addr; reason="user-busy"; counter=1; privacy=full,
diverting_user1_addr; reason="unconditional"; counter=1; privacy=off
diverting_user2_addr; reason="user-busy"; counter=1; privacy=full,
diverting_user1_addr; reason="unconditional"; counter=1; privacy=off
The recommended interworking presented in this document should apply only for INVITE requests.
本文档中推荐的互通仅适用于邀请请求。
In 3xx responses, both headers could be present.
在3xx响应中，两个标头都可能存在。
When a proxy wants to interwork with a network supporting the other header field, it should apply the interworking between Diversion header and History-Info header 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 or a History-Info header (according to its capabilities) in the forwarded INVITE. Local policies could apply to send the received header in the next INVITE.
当递归代理在收到3xx响应后重定向初始邀请时，它应该在转发的邀请中添加一个转移头或历史信息头（根据其功能）作为最后一个条目。可以应用本地策略在下一次邀请中发送收到的标头。
Other messages where History-Info could be present are not used for the call forwarding service and should not be changed into Diversion header. The destination network must be transparent to the received History-Info header.
可能存在历史信息的其他消息不用于呼叫转接服务，不应更改为转接头。目标网络必须对接收到的历史信息头透明。
Note: the following mapping is inspired from the ISDN User Part (ISUP) to the SIP interworking described in [TS_29.163].
注：以下映射源于[TS_29.163]中描述的ISDN用户部分（ISUP）到SIP互通。
The following text is valid only if no History-Info is present in the INVITE request. If at least one History-Info header is present, the interworking function must adapt its behavior to respect the chronological order. See section 2.2.
仅当INVITE请求中不存在历史记录信息时，以下文本才有效。如果至少存在一个历史信息头，则互通功能必须调整其行为以遵守时间顺序。见第2.2节。
For N Diversion entries, N+1 History-Info entries must be created. To create the History-Info entries in the same order than during a session establishment, the Diversion entries must be mapped from the bottom-most until 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 R-URI of the received INVITE. The mapping is described below.
对于N个分流条目，必须创建N+1个历史信息条目。要以与会话建立期间相同的顺序创建历史信息条目，必须从最底部映射到最顶部。每个分流条目应映射到历史信息条目中。必须创建一个附加的历史信息条目（最后一个），并在接收到的邀请的R-URI中显示转移到参与方的地址。映射描述如下。
The first entry created in the History-Info header contains:
在历史信息标题中创建的第一个条目包含：
- a hi-targeted-to-uri with the name-addr parameter of the bottom-most Diversion header.
- 以uri为目标的hi，其名称addr参数为最底部的标题。
- if a privacy parameter is present in the bottom-most Diversion entry, then a Privacy header could be escaped in the History-Info header as described below.
- 如果最底部的转移条目中存在隐私参数，则可以在历史信息头中转义隐私头，如下所述。
- an index set to 1.
- 设置为1的索引。
For each following Diversion entry (from bottom to top), the History-info entries are created as following (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-param (not present in
Diversion entry the first created hi-entry)
"unknown"---------------------------------404 (default 'cause' value)
"unconditional"---------------------------302
"user-busy"-------------------------------486
"no-answer"-------------------------------408
"deflection "-----------------------------480 or 487
"unavailable"-----------------------------404
"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-param (not present in
Diversion entry the first created hi-entry)
"unknown"---------------------------------404 (default 'cause' value)
"unconditional"---------------------------302
"user-busy"-------------------------------486
"no-answer"-------------------------------408
"deflection "-----------------------------480 or 487
"unavailable"-----------------------------404
"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 incremented with ".1"
Superior to "1" --------------------------Create N-1 placeholder History
(i.e., N) entry with the previous index
incremented with ".1"
Then the History-Info header
created with the Diversion
entry with the previous index
incremented 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"
=======================================================================
=======================================================================
Counter hi-index
"1" or parameter -------------------------The previous created index
not present is incremented with ".1"
Superior to "1" --------------------------Create N-1 placeholder History
(i.e., N) entry with the previous index
incremented with ".1"
Then the History-Info header
created with the Diversion
entry with the previous index
incremented 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"
=======================================================================
A last History-Info entry is created and contains:
将创建最后一个历史信息条目，其中包含：
- a hi-targeted-to-uri with the Request-URI of the INVITE request.
- hi指向具有INVITE请求的请求uri的uri。
- a cause-param from the top-most Diversion entry, mapped from the diversion-reason as described above.
- 来自最顶部分流条目的原因参数，如上所述从分流原因映射。
- if a privacy parameter is present in the top-most Diversion entry, then a Privacy header could be escaped in the History-Info header as described above.
- 如果隐私参数出现在最顶端的转移条目中，则可以如上所述在历史信息头中转义隐私头。
- an index set to the previous created index and incremented with ".1"
- 设置为以前创建的索引并以“.1”递增的索引
Notes:
笔记：
1. For other optional Diversion parameters, there is no recommendation as History-Info header does not provide equivalent parameters.
1. 对于其他可选的改道参数，没有建议，因为历史信息标题未提供等效参数。
2. For values of the diversion-reason values that are mapped with a recommended default value, it could also be possible to choose another value. The cause-param URI parameter offers less possible values than the diversion-reason parameter. However, it has been considered that 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参数提供的可能值少于diversion-reason参数。然而，已经认为原因参数值列表足以实现3GPP[TS_24.604]中定义的CDIV服务，因为它涵盖了大部分情况。
3. The Diversion header could contain a Tel:URI in the name-addr parameter, but it seems not possible to have a Tel:URI in the History-Info header. [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 has 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, the History-Info header should be created with a SIP URI with user=phone.
3. 转移头可以在name addr参数中包含Tel:URI，但在History Info头中似乎不可能包含Tel:URI。[RFC3261]给出了sip:和Tel:URI之间映射的指示，但在这种特殊情况下，很难分配有效的主机端口，因为转移发生在以前的网络中，并且很难确定有效的主机端口。因此，建议在分流头中存在Tel:URI的情况下，应使用user=phone的SIP URI创建历史信息头。
4. The Diversion header allows the carrying of a counter that retains the information about the number of successive redirections. The History-Info header does not have an equivalent because to trace and count the number of diversion it is necessary to count cause parameter containing a value associated to a call diversion. Read the index value is not enough. With the use of the "placeholder" entry, the History-Info header entries could reflect the real number of diversion occurred.
4. 分流标头允许携带保留有关连续重定向次数信息的计数器。历史信息标头没有等效项，因为要跟踪和统计转接次数，必须统计包含与呼叫转接关联的值的原因参数。读取索引值是不够的。通过使用“占位符”条目，历史信息标题条目可以反映实际发生的分流数量。
Example of placeholder entry in the History-Info header:
历史信息标题中的占位符条目示例：
<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
<sip:bob_addr;cause=404>;index=1.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。
Concerning local policies recommendations about headers coexistence in the INVITE request, see sections 2.2 and 7.5.
关于INVITE请求中头共存的本地策略建议，请参见第2.2节和第7.5节。
To create the Diversion entries in the same order than during a session establishment, the History-Info entries must be mapped from the top-most until the bottom-most. The first History-Info header entry selected will be mapped into the last Diversion header entry and so on. One Diversion header entry must be created for each History-Info entry, with a cause-param reflecting a diverting reason as listed in the [RFC4458].
要以与会话建立期间相同的顺序创建转移条目，历史信息条目必须从最顶端映射到最底端。选择的第一个历史信息标题条目将映射到最后一个分流标题条目，依此类推。必须为每个历史信息条目创建一个分流标题条目，其中的原因参数反映了[RFC4458]中列出的分流原因。
In this case, the History-Info header must be mapped into the Diversion header as following:
在这种情况下，历史信息标题必须映射到分流标题中，如下所示：
Source Destination
History-Info header component: Diversion header component:
=====================================================================
hi-targeted-to-uri of the name-addr
History-Info that precedes the one
containing a diverting cause-param.
Source Destination
History-Info header component: Diversion header component:
=====================================================================
hi-targeted-to-uri of the name-addr
History-Info that precedes the one
containing a diverting cause-param.
=====================================================================
cause-param Reason
404---------------------------------------"unknown" (default value)
302---------------------------------------"unconditional"
486---------------------------------------"user-busy"
408---------------------------------------"no-answer"
480 or 487--------------------------------"deflection "
503---------------------------------------"unavailable"
=====================================================================
cause-param Reason
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 [RFC3323] escaped in the Privacy
hi-targeted-to-uri of the
History-Info, which precedes the one
containing a diverting cause-param.
Optional parameter for History-Info,
this Privacy indicates that this
specific History-Info header should
not be forwarded.
"history"----------------------------------"full"
Privacy header field ----------------------"Off"
Absent or "none"
=====================================================================
hi-index Counter
Mandatory parameter for--------------------The counter is set to "1".
History-Info reflecting
the chronological order
of the information.
=====================================================================
Privacy header [RFC3323] escaped in the Privacy
hi-targeted-to-uri of the
History-Info, which precedes the one
containing a diverting cause-param.
Optional parameter for History-Info,
this Privacy indicates that this
specific History-Info header should
not be forwarded.
"history"----------------------------------"full"
Privacy header field ----------------------"Off"
Absent or "none"
=====================================================================
=====================================================================
Note: For other optional History-Info parameters, there is no recommendation as Diversion header does not provide equivalent parameters.
注：对于其他可选的历史信息参数，不建议使用，因为分流总管不提供等效参数。
Concerning local policies recommendations about headers coexistence in the INVITE request, see section 2.2.
关于INVITE请求中头共存的本地策略建议，请参见第2.2节。
INVITE last_diverting_target
Diversion:
diverting_user3_address;reason=unconditional;counter=1;privacy=off,
diverting_user2_address;reason=user-busy;counter=1;privacy=full,
diverting_user1_address;reason=no-answer;counter=1;privacy=off
INVITE last_diverting_target
Diversion:
diverting_user3_address;reason=unconditional;counter=1;privacy=off,
diverting_user2_address;reason=user-busy;counter=1;privacy=full,
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,
<sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
<sip: last_diverting_target; cause=302>;index=1.1.1.1
History-Info:
<sip: diverting_user1_address; privacy=none >; index=1,
<sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
<sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
<sip: last_diverting_target; cause=302>;index=1.1.1.1
History-Info:
<sip: diverting_user1_address?privacy=history >; index=1,
<sip: diverting_user2_address; cause=302? privacy=none>;index=1.1,
<sip: last_diverting_target; cause=486>;index=1.1.1
History-Info:
<sip: diverting_user1_address?privacy=history >; index=1,
<sip: diverting_user2_address; cause=302? privacy=none>;index=1.1,
<sip: last_diverting_target; cause=486>;index=1.1.1
Mapped into:
映射到：
Diversion:
diverting_user2_address; reason=user-busy; counter=1; privacy=off,
diverting_user1_address; reason=unconditional; counter=1;
privacy=full
Diversion:
diverting_user2_address; reason=user-busy; counter=1; privacy=off,
diverting_user1_address; reason=unconditional; counter=1;
privacy=full
7.3. Example with Two SIP Networks Using History-Info Header Interworking with a SIP Network Using Diversion Header
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
| Hist-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 | | | | |
| | | | | | | | | |
| | |INV C | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | <sip:proxyP1>; index=1,| | | | |
| | <sip:userB>; index=1.1 | | | | |
| | <sip:userC; cause=302>; index=1.1.1 | | |
| | | | | | | | | |
| | | |INV C | | | | | |
| | | |----->| | | | | |
| | | |Diversion: | | | | |
| | | |B reason= unconditional counter=1 | |
| | | |History-Info: | | | | |
| | | <sip:proxyP1>; index=1,| | | |
| | | <sip:userB>; index=1.1 | | | |
| | | <sip:proxyP2; cause=302>; index=1.1.1 |
| | | | | | | | | |
| | | | |INV C | | | | |
| | | | |------>| | | | |
| | | | No modification of Diversion due to P2|
| | | | | | | | | |
| | | | | |INV C | | | |
| | | | | |------>| | | |
| | | | | | | | | |
| | | | | |<--180-| | | |
| | | | | | | | | |
| | | | | No response timer expire | |
| | | | | |---INV D --->| | |
IWF* IWF*
SIP network using | SIP network using |SIP net.
History-Info | Diversion |using
| Hist-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 | | | | |
| | | | | | | | | |
| | |INV C | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | <sip:proxyP1>; index=1,| | | | |
| | <sip:userB>; index=1.1 | | | | |
| | <sip:userC; cause=302>; index=1.1.1 | | |
| | | | | | | | | |
| | | |INV C | | | | | |
| | | |----->| | | | | |
| | | |Diversion: | | | | |
| | | |B reason= unconditional counter=1 | |
| | | |History-Info: | | | | |
| | | <sip:proxyP1>; index=1,| | | |
| | | <sip:userB>; index=1.1 | | | |
| | | <sip:proxyP2; cause=302>; index=1.1.1 |
| | | | | | | | | |
| | | | |INV C | | | | |
| | | | |------>| | | | |
| | | | No modification of Diversion due to P2|
| | | | | | | | | |
| | | | | |INV C | | | |
| | | | | |------>| | | |
| | | | | | | | | |
| | | | | |<--180-| | | |
| | | | | | | | | |
| | | | | No response timer expire | |
| | | | | |---INV D --->| | |
| | |Diversion: | | |
| | |userC; reason=no-answer; counter=1; privacy=full, |
| | |userB; reason=unconditional; counter=1; privacy=off,
| | | History-Info: | | |
| | | <sip:proxyP1>; index=1, | | |
| | | <sip:userB>; index=1.1 | | |
| | | <sip:proxyP2; cause=302>; index=1.1.1 | |
| | | | | | | | | |
| | | | | | | |INV E | |
| | | | | | | |----->| |
| | |Diversion: | |
| | |userD; reason=time-of-day; counter=1; privacy=off |
| | |userC; reason=no-answer; counter=1; privacy=full, |
| | |userB; reason=unconditional; counter=1; privacy=off,
| | | History-Info: | |
| | | <sip:proxyP1>; index=1, | |
| | | <sip:userB>; index=1.1 | |
| | | <sip:proxyP2; cause=302>; index=1.1.1 | |
| | | | | | | | | |
| | | | | | | | | INV E |
| | | | | | | | |------>|
| | | History-Info: |
| | | <sip:proxyP1>; index=1, |
| | | <sip:userB ?privacy=none>; index=1.1, |
| | | <sip:proxyP2; cause=302>; index=1.1.1, |
| | | <sip:userC ?privacy=history>; index=1.1.1.1, |
| | <sip:userD; cause=408 ?privacy=none>; index=1.1.1.1.1,
| | | <sip:userE; cause=404>; index=1.1.1.1.1.1 |
| | | | | | | | | |
| | | | | | | | | |
| | |Diversion: | | |
| | |userC; reason=no-answer; counter=1; privacy=full, |
| | |userB; reason=unconditional; counter=1; privacy=off,
| | | History-Info: | | |
| | | <sip:proxyP1>; index=1, | | |
| | | <sip:userB>; index=1.1 | | |
| | | <sip:proxyP2; cause=302>; index=1.1.1 | |
| | | | | | | | | |
| | | | | | | |INV E | |
| | | | | | | |----->| |
| | |Diversion: | |
| | |userD; reason=time-of-day; counter=1; privacy=off |
| | |userC; reason=no-answer; counter=1; privacy=full, |
| | |userB; reason=unconditional; counter=1; privacy=off,
| | | History-Info: | |
| | | <sip:proxyP1>; index=1, | |
| | | <sip:userB>; index=1.1 | |
| | | <sip:proxyP2; cause=302>; index=1.1.1 | |
| | | | | | | | | |
| | | | | | | | | INV E |
| | | | | | | | |------>|
| | | History-Info: |
| | | <sip:proxyP1>; index=1, |
| | | <sip:userB ?privacy=none>; index=1.1, |
| | | <sip:proxyP2; cause=302>; index=1.1.1, |
| | | <sip:userC ?privacy=history>; index=1.1.1.1, |
| | <sip:userD; cause=408 ?privacy=none>; index=1.1.1.1.1,
| | | <sip:userE; cause=404>; index=1.1.1.1.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 if for particular cases in which both headers could coexist, it should be the network local policy responsibility to make it work together. Here are described some situations and some recommendations on the behavior to follow.
即使在两个报头可以共存的特定情况下，网络本地策略也应负责使其协同工作。这里描述了一些情况，并就应遵循的行为提出了一些建议。
In the case where there is one network that includes different nodes, some of them supporting the Diversion header and other ones supporting the History-Info header, 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 Diversion header and the more recent History-Info header.
如果有一个网络包含不同的节点，其中一些节点支持转移报头，另一些节点支持历史信息报头，那么当处理消息的任何节点不知道将处理消息的下一个节点时，就会出现问题。当网络有新的和旧的节点，旧的节点使用转移头和最近的历史信息头时，可能会发生这种情况。
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 History-Info header and Diversion header within the core network.
虽然可能会发生网络替换，但会有一段时间两个节点在网络中共存。如果由于不同的节点功能，使用不同的节点来支持不同的订户类型，那么问题就更重要了。在这种情况下，需要在核心网络内传递历史信息报头和分流报头。
These headers 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, there is a requirement to be able to compare the headers and to convert the headers. Depending upon the node capability, it may be possible to make assumptions as to how this is handled.
These headers 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, there is a requirement to be able to compare the headers and to convert the headers. Depending upon the node capability, it may be possible to make assumptions as to how this is handled.translate error, please retry
o If it is known that the older Diversion header supporting nodes do not pass on any received History-Info header, then the interworking becomes easier. If a message is received with only Diversion headers, 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.
o 如果已知较旧的分流头支持节点不传递任何接收到的历史信息头，则互通变得更容易。如果接收到的消息仅包含转移头，则该消息来自“旧”节点。可以创建等效的历史信息条目，然后可以传递这些条目以及分流标题。
o If the node creates a new History-Info header for a call diversion, then an additional Diversion header must be created.
o 如果节点为呼叫转接创建新的历史信息标头，则必须创建其他转接标头。
o If the next node is an 'old' node, then the Diversion header 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 Diversion header and History-Info header 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 History-Info header and Diversion header, but only actively use one, then both types of nodes need to perform the interworking and must maintain equivalence between the headers. This will eventually result in the use of Diversion header being deprecated when all nodes in the network support History-Info header.
o 如果两个节点同时传递历史信息报头和分流报头，但仅主动使用其中一个，则两种类型的节点都需要执行互通，并且必须保持报头之间的等效性。当网络中的所有节点都支持历史信息头时，这将最终导致不推荐使用分流头。
The security considerations in [RFC4244] and [RFC5806] apply.
[RFC4244]和[RFC5806]中的安全注意事项适用。
The use of the Diversion header or the History-Info header require the application of the requested privacy and integrity asked 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, deletion of modification of those headers, can provide misleading information to users and applications. A SIP entity that can provide a redirection reason in a History-Info header or a Diversion header should be able to suppress this in accordance with privacy requirements of the user concerned.
身份信息。在没有保密性的情况下，网络上的窃听者（或用户与隐私服务之间的任何中间人）可以看到用户要求隐私服务掩盖的非常私人的信息。未经授权的插入、删除或修改这些标题可能会向用户和应用程序提供误导性信息。能够在历史信息报头或转移报头中提供重定向原因的SIP实体应当能够根据相关用户的隐私要求抑制这种情况。
The editor 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, and Robert Sparks. Merci a Lionel Morand, Xavier Marjou, and Philippe Fouquart.
编辑要感谢史蒂夫·诺里斯、扬·范吉尔、马丁·多利、弗朗西斯科·席尔瓦、吉塞佩·肖尔蒂诺、辛扎·阿曼达、克里斯特·霍姆伯格、伊恩·埃尔兹、让·弗朗索瓦·穆勒、玛丽·巴恩斯、弗朗索瓦·奥德特、埃里克·萨斯基、实达·舒伯特、乔尔·M·哈尔彭、鲍勃·布莱登和罗伯特·斯帕克斯提供的建设性反馈和支持。谢谢莱昂内尔·莫兰德、泽维尔·马约和菲利普·福夸特。
[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月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[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月。
[RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244]Barnes，M.，Ed.，“请求历史信息会话启动协议（SIP）的扩展”，RFC 4244，2005年11月。
[RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in SIP", RFC 5806, March 2010.
[RFC5806]Levy，S.和M.Mohali，编辑，“SIP中的分流指示”，RFC 5806，2010年3月。
[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月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[TS_24.604] 3rd Generation Partnership Project, "Technical Specification Group Core Network and Terminals ; Communication Diversion (CDIV) using IP Multimedia (IM)Core Network (CN) subsystem ; Protocol specification (Release 8), 3GPP TS 24.604", December 2008.
[TS_24.604]第三代合作项目，“技术规范组核心网络和终端；使用IP多媒体（IM）核心网络（CN）子系统的通信转移（CDIV）；协议规范（版本8），3GPP TS 24.604”，2008年12月。
[TS_29.163] 3rd Generation Partnership Project, "Technical Specification Group Core Network and Terminals ; Interworking between the IP Multimedia (IM) Core Network (CN) Subsystem and Circuit Switched (CS) networks (Release 8)", December 2008.
[TS_29.163]第三代合作项目，“技术规范组核心网络和终端；IP多媒体（IM）核心网络（CN）子系统和电路交换（CS）网络之间的互通（第8版）”，2008年12月。
Voicemail URI is a mechanism described in RFC 4458 to provide a simple way to transport only one redirecting user address and the reason why the diversion occurred in the R-URI of the INVITE request. This mechanism is mainly used for call diversion to a voicemail.
语音邮件URI是RFC 4458中描述的一种机制，它提供了一种只传输一个重定向用户地址的简单方法，以及在INVITE请求的R-URI中发生转移的原因。此机制主要用于呼叫转移到语音邮件。
Diversion header to Voicemail URI:
语音邮件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 with a default value set to 404.
重定向原因的映射与历史信息头的映射相同，默认值设置为404。
If the Diversion header 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 not the voicemail serves this user).
如果转移头包含多个转移条目，则URI中插入的重定向用户信息的选择由网络本地策略负责。例如，URI中插入的重定向信息的选择标准可以是转发的INVITE请求的目的地（无论语音邮件是否为该用户服务）。
Note: This interworking could be done in addition to the interworking of the Diversion header into the History-Info header.
注：除了分流总管与历史信息总管的互通外，还可以进行该互通。
Voicemail URI to Diversion header:
转接头的语音邮件URI：
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 following:
对于真正的语音邮件，这种互通方式不应该发生。但是，如果由于任何原因发生，建议按照以下步骤进行：
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
Author's Address
作者地址
Marianne Mohali France Telecom Orange 38-40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France
Marianne Mohali法国电信橙色Leclerc Issy Les Moulineaux Cedex路38-40号法国92794
Phone: +33 1 45 29 45 14
EMail: marianne.mohali@orange-ftgroup.com
Phone: +33 1 45 29 45 14
EMail: marianne.mohali@orange-ftgroup.com