[要約] RFC 6044は、SIPのDiversionヘッダとHistory-Infoヘッダ間の転送情報のマッピングと相互運用に関する仕様です。このRFCの目的は、SIPセッション中の転送情報を正確に伝達し、相互運用性を向上させることです。
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）の流用と履歴INFOヘッダーの間の迂回情報のマッピングと相互作用
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 History-INFOヘッダーは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.
このドキュメントでは、転用ヘッダーと履歴INFOヘッダーとの間の推奨されるインターワーキングガイドラインについて説明します。さらに、ヘッダーの共存を管理するためのインターワーキングポリシーが提案されています。History-INFOヘッダーは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履歴INFO標準化されたソリューションとの相互作用が必要です。この作業は、非標準の実装からの移行と、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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
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ベースの（Voice Over IP）サービス（ボイスメール、インタラクティブな音声認識（IVR）または自動コール分布）の場合、呼び出されたSIPユーザーエージェントが誰から、なぜセッションが転用されたのかを特定するのに役立ちます。この情報をさまざまなサービスプロバイダーまたはアプリケーションで使用するには、ネットワークを通過する必要があります。これは、[RFC4244]で定義されている履歴INFOヘッダーと[RFC5806]で定義されている歴史的迂回ヘッダーの2つの異なるSIPヘッダーで可能です。どちらも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.
迂回ヘッダーは標準化されていませんが、広く使用されています。したがって、このヘッダーが標準履歴INFOヘッダーとのインターワークを行うためのガイドラインを持っていると便利です。
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.
このドキュメントは、迂回ヘッダーとHistory-INFOヘッダーの間のヘッダーコンテンツ翻訳のメカニズムを提供します。
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].
履歴INFOヘッダー[RFC4244]とSIPサービスURIS（ボイスメールURIを含む）[RFC4458を含む）を形成するためのその拡張は、リダイレクト情報を伝えるためにIETFによって推奨されます。また、「Communication Diversion（CDIV）サービス」第3世代パートナーシッププロジェクト（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 be able to extract the relevant data using the retargeting cause URI parameter described in [RFC4458] for the transport of the diversion reason.
このヘッダーには、呼び出しの転換の理由として特定の情報を提供する、迂回するURIと関連する情報のリストが含まれています。ほとんどの既存のSIPベースの実装は、標準ソリューションが展開する準備ができていない場合、迂回ヘッダーを実装しています。IETFは、一般的な履歴情報を輸送できるため、最終的に履歴INFOヘッダーを標準化しました。これにより、受信部品はセッションがどのように、なぜ受信されるかを判断できます。History-INFOヘッダーには、転用情報よりもさらなる情報が含まれている可能性があるため、情報を失うことを避け、迂回理由の輸送のために[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).
迂回ヘッダーとHistory-INFOヘッダーには、以下で説明する構文が異なります。主な違いは、履歴INFOヘッダーが年代順のライティングヘッダーであるのに対し、迂回ヘッダーは逆の年表を適用することであることに注意してください（つまり、最初の迂回エントリ読み取りは最後の転換ユーザーに対応しています）。
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.
このセクションでは、ドキュメントの残りの部分で使用されるベースライン用語を提供し、迂回ヘッダーと履歴INFOヘッダーの間のインターワーキングの範囲を定義します。
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エンティティの動作は、目的地の変更につながる理由によって異なる場合があります。たとえば、簡単なプロキシがセッションをルーティングするか、アプリケーションサーバーが補足サービスを提供するかです。迂回ヘッダーとHistory-INFOヘッダーは、この問題に対処するアプローチと範囲が異なります。
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 リターゲティング/リダイレクト：リターゲティング/リダイレクトとは、リクエストで均一なリソース識別子（URI）を変更してリクエストのターゲットを変更するプロキシサーバー/ユーザーエージェントクライアント（UAC）のプロセスを指します。これらの用語は[RFC4244]で定義されています。履歴INFOヘッダーは、リターゲティング情報をキャプチャするために使用されます。
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 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 コール転送/通話転換/通信転用：これらの用語は同等であり、統合サービスデジタルネットワーク（ISDN）通信迂回補足サービスに基づいて、3GPP [TS_24.604]で定義されている通信迂回（CDIV）補足サービスを参照してください。これらは、セッション施設中または事前に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.
このドキュメントでは、履歴INFOまたは迂回ヘッダーをいつ、どのように使用するかを説明するつもりはありません。以下には、インターワーキングが必要なコンテキストについて説明が提供されます。
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.
History-INFOヘッダーは、通話転換情報を含むすべてのリターゲティング情報を保存するために使用されます。実際には、History-INFOヘッダー[RFC4244]を使用して、関連するエントリでCause URIパラメーター[RFC4458]を使用して、コールダイバーズ関連の情報を伝達します。ただし、コール転換の履歴INFOエントリでの原因URIパラメーター[RFC4458]の使用は、3GPP仕様[TS_24.604]に固有のものであることに注意してください。[RFC4458]は、ボイスメールサーバーへのリターゲティングに焦点を当てており、他のケースではURIに原因URIパラメーターを追加するかどうかを指定していません。結果として、コール転送情報に原因URIパラメーターを使用しない実装は、このドキュメントで説明されているマッピングについては考慮されません。それにもかかわらず、次のセクションでは、履歴INFOヘッダーを使用して転換ヘッダーを使用してネットワーク領域の境界でマッピングされていない情報の損失を回避する方法についてのいくつかの推奨事項を示します。
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.
両方のヘッダーアドレスアドレスは転送のニーズを呼び出すため、招待状リクエストで両方が協調していない方法で存在する場合、迂回情報を混同したり一貫している可能性があります。したがって、迂回と履歴INFOヘッダーは、同じセッションシグナリングで独立して共存してはなりません。このドキュメントでは、迂回ヘッダーとHistory-INFOヘッダーの間で情報を変換する方法、および追加のケースをカバーするために両方のヘッダーをいつ、どのように保持するかについて説明します。
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.
下流の一貫した迂回情報の輸送のために、2つのヘッダーをインターワークする必要があります。迂回ヘッダーとHistory-INFOヘッダーの間のインターワーキングは、セクション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.
通常の場合、ネットワークトポロジの仮定は、このドキュメントに記載されているインターワーキングは、構成ごとに、2つの地域の境界線、1つは履歴INFOヘッダーを使用し、1つは境界線にあることを認識している特定の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.
History-INFOヘッダーは標準ソリューションであるため、迂回ヘッダーを使用するネットワークは、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ヘッダーは迂回ヘッダーよりも広いスコープを持っているため、呼び出し以外のニーズやサービスに使用される場合があります。Trace Call Diversion Informationに加えて、History-INFOヘッダーはセッション履歴としても機能し、すべての連続したR-URI値を保存できます。その結果、混乱を避けるために迂回ヘッダーの作成後に履歴INFOヘッダーを削除する方が良い場合でも、歴史とFOのヘッダーには、補足（非隣接）情報が含まれている場合、SIPシグナリングでは修正されていないままでなければなりません。迂回ヘッダーにマッピングできる値を持たない履歴INFOヘッダーを持つことができます。この場合、迂回ヘッダーとの相互作用を実行する必要はなく、この場合に何をすべきかを実装ごとに定義する必要があります。この点は、このドキュメントの範囲から除外されています。
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で説明します。
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.
迂回ヘッダーを使用してHistory-infoヘッダーを作成する場合、転換招待で迂回ヘッダーを削除する必要があります。迂回ヘッダーに存在するすべての情報は、歴史INFOヘッダーに転送されると考えられています。
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].
履歴INFOヘッダーが着信招待状に存在する場合（転用ヘッダーに加えて）、迂回ヘッダーと履歴INFOヘッダーの存在を混合する必要があり、歴史INFOヘッダーにまだ存在していない迂回情報のみを挿入する必要があります。[RFC4244]で推奨されているように、既存の履歴INFOヘッダーの最後のエントリ（より最近）。
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.
例として、これは転用ヘッダーを使用してNetwork_2から招待された招待状の場合である可能性がありますが、以前はhistory-infoヘッダーを使用してNetwork_1を通過しました（またはnetwork_2はhistory-infoヘッダーを使用してURI情報を輸送します）。History-infoヘッダー。
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.
この場合、着信招待には迂回ヘッダーと履歴INFOヘッダーが含まれています。したがって、このドキュメントで推奨されているように、Network_3の場合、履歴INFOと迂回ヘッダーの両方から既存の情報を収集する単一の履歴ヘッダーを作成する必要があります。とにかく、メッセージが転換ヘッダーを使用しないネットワークに送られているときに転換ヘッダーを削除することは、Network_2（つまり、IWF）から必要です。次に、Network_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. ネットワークが毎回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. History-infoヘッダーに通話迂回情報以上のものが含まれている場合、迂回ヘッダーのみを持つことはできません。以前のポリシーの推奨事項が適用された場合、転用内部の年表を考慮して歴史INFOヘッダーの最後に迂回エントリが挿入されると、時系列の順序が尊重されます。
When the History-Info header is interpreted to create a Diversion header, some precautions must be taken.
History-infoヘッダーが迂回ヘッダーを作成するために解釈される場合、いくつかの予防措置を講じる必要があります。
If the History-Info header contains only call forwarding information, then it must be deleted after the interworking.
History-infoヘッダーに呼び出しの転送情報のみが含まれている場合、インターワーキング後に削除する必要があります。
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.
History-infoヘッダーに他の情報が含まれている場合、転用ヘッダーにエントリを作成するために使用されているユーザーへの懸念情報のみが、招待状に歴史とFOヘッダーを受け取ったとおりに保持する必要があります。
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.
注：履歴INFOヘッダーは、たとえば、特定のアプリケーションサーバー（AS）がシグナリングパスでまだ呼び出されているかどうかを知る必要があるサービスなど、転用サービスを呼び出す以外の理由で使用できます。履歴INFOヘッダーを使用してコールが後でネットワークに転送された場合、転用ヘッダーのみをサポートするネットワークを通過するために履歴情報を失わない方が良いでしょう。推奨されるソリューションは、履歴INFOヘッダーを実装しない標準的な動作とネットワークを破壊してはなりません。
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].
迂回ヘッダーが着信招待状に（履歴INFOヘッダーに加えて）存在する場合、既存のエントリ（より最近）から迂回ヘッダーにはないが、歴史INFOヘッダーに存在する迂回情報のみが既存のエントリ（最近）に挿入する必要があります。[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.
History-INFOヘッダーは、同じサービスユーザーのシーケンシャルフォーキングの録音を可能にします。歴史INFOヘッダーから転用ヘッダーまで、インターワーキング中、フォーキング状況（インクリメント「インデックス」パラメーターを含む）を含む履歴INFOエントリは、コール転送「原因」パラメーターを含む場合、おそらくマッピングできます。インターワーキングエンティティは、転用エントリのみを作成するか、インターワーキングを適用しないかを選択できます。選択は、ローカルポリシーに従って行うことができます。
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 *（Comma 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
The History-Info header is specified in [RFC4244]. The top-most History-Info entry (first in the list) corresponds to the oldest history information.
履歴INFOヘッダーは[RFC4244]で指定されています。最上位の履歴INFOエントリ（リストの最初）は、最も古い履歴情報に対応しています。
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-Entryには、転用理由を表す原因URIパラメーターが含まれている場合があります。このオプションの原因URIパラメーターは、次の構文を使用して[RFC4458]で定義されています。
cause-param = "cause" EQUAL Status-Code
case-param = "原因"等しいステータスコード
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.
このパラメーターの名前は原因と呼ばれ、3GPP CDIV仕様[TS_24.604]で推奨されているように、通話転換の場合に、転用されたユーザーの歴史INFOエントリ（URI）に挿入する必要があります。迂回理由のために原因パラムで使用される原因値はRFC 4458にリストされており、コール転送サービスに専念するパラメーターであるため、その存在は、hi-entryが迂回ユーザーであると判断するために使用されます。より正確には、各迂回ユーザーは、RFC 4458にリストされている原因値を持つ原因パラムを含むhi-entryに位置しています。
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.
さらに、[RFC3326]で定義されているヘッダーが、通話の転換が受信したSIP応答によるものである場合、迂回ユーザーのhi-entryで逃げる必要があります。理由ヘッダーには、受信した真のSIP応答コードに設定された原因パラメーターが含まれています（ステータスコード）。したがって、SIP応答による通話転換の場合、両方ともパラメーターを使用する必要があります。複雑さは、これらのパラメーターが歴史INFOヘッダーで同時に使用できるが、同じ意味ではなく、同じhi侵入では使用できないことです。Cause-Paramのみが転用サービスを呼び出すことに専念しています。「原因」理由ヘッダーパラメーターは、迂回ヘッダーを使用したマッピングでは考慮されません。
[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]は、「ターゲット」URIパラメーターも定義します。これは、r-uriに挿入され、その結果、HiターゲットからURIに挿入できます。このパラメーターは、ボイスメールURI実装のダウンストリーム招待リクエストに迂回ユーザーアドレスを維持するために使用されます。この情報は既にHI-Enteriesに存在しているため、「ターゲット」URIパラメーターは、迂回ヘッダーとの相互作用に関して考慮されていません。迂回ヘッダーから、Hi-Enteriesおよび/またはR-URIで「ターゲット」URIパラメーターを作成することが可能ですが、この可能性は、このドキュメントに記載されていないローカルポリシーに基づいています。
A Privacy header, as defined in [RFC3323], could also be included in hi-entries with the 'history' value defined in the [RFC4244].
[RFC3323]で定義されているプライバシーヘッダーは、[RFC4244]で定義されている「履歴」値を持つHi-Enteriesにも含めることができます。
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
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」オプションタグでリクエストを受信するプロキシは、リクエストに対するその後の暫定的かつ最終的な応答でキャプチャされた履歴INFOを返す必要があります。。動作は、ローカルポリシーが歴史INFOの獲得をサポートするかどうかに依存します。
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)
転用= "迂回" hcolon division-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 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
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応答で迂回ヘッダーとHistory-INFOヘッダーの間のインターワーキングを適用する必要があります。
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応答を受け取った後に最初の招待状をリダイレクトする場合、転送された招待状の転換ヘッダーまたは履歴INFOヘッダー（その機能に従って）のいずれかの最後のエントリとして追加する必要があります。次の招待で受信されたヘッダーを送信するために、ローカルポリシーが適用される可能性があります。
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.
History-INFOが存在する可能性のある他のメッセージは、コール転送サービスに使用されず、迂回ヘッダーに変更する必要はありません。宛先ネットワークは、受信した履歴INFOヘッダーに対して透過的でなければなりません。
Note: the following mapping is inspired from the ISDN User Part (ISUP) to the SIP interworking described in [TS_29.163].
注：次のマッピングは、ISDNユーザーパーツ（ISUP）から[TS_29.163]に記載されている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.
次のテキストは、招待リクエストに履歴INFOが存在しない場合にのみ有効です。少なくとも1つの履歴INFOヘッダーが存在する場合、インターワーキング関数はその動作を年代順を尊重するために適応させる必要があります。セクション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 History-infoエントリを作成する必要があります。セッションの確立中と同じ順序で履歴INFOエントリを作成するには、迂回エントリを一番下から最上位までマッピングする必要があります。各迂回エントリは、履歴INFOエントリにマッピングされなければなりません。追加の履歴INFOエントリ（最後のエントリ）は、受信した招待のR-URIに存在する迂回されたパーティーアドレスで作成する必要があります。マッピングについては、以下に説明します。
The first entry created in the History-Info header contains:
History-INFOヘッダーで作成された最初のエントリには、次のものが含まれています。
- a hi-targeted-to-uri with the name-addr parameter of the bottom-most Diversion header.
- 一番下の迂回ヘッダーの名前-ADDRパラメーターを備えたHIターゲットから尿ターから
- 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.
- プライバシーパラメーターが一番下の転用エントリに存在する場合、以下に説明するように、プライバシーヘッダーが歴史INFOヘッダーで逃げる可能性があります。
- 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):
次の各転用エントリ（下から上へ）について、履歴INFOエントリは次のように作成されます（上から下まで）：
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)
=======================================================================
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:
最後の履歴INFOエントリが作成され、含まれています。
- a hi-targeted-to-uri with the Request-URI of the INVITE request.
- 招待状リクエストのリクエスト-URIを備えたHIターゲットから尿を取得します。
- 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.
- プライバシーパラメーターが最上位の転用エントリに存在する場合、上記のように歴史INFOヘッダーでプライバシーヘッダーを逃れることができます。
- 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. 他のオプションの迂回パラメーターの場合、History-infoヘッダーは同等のパラメーターを提供しないため、推奨はありません。
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. 推奨されるデフォルト値でマッピングされた迂回革新値の値の場合、別の値を選択することも可能です。Case-Param URIパラメーターは、迂回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を含めることができますが、歴史INFOヘッダーに電話：URIを持つことはできないようです。[RFC3261]は、SIPの間のマッピングについての兆候を示します。したがって、転用ヘッダーのTel：URIの場合、履歴INFOヘッダーは、user =電話を使用した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. 迂回ヘッダーは、連続したリダイレクトの数に関する情報を保持するカウンターを運ぶことができます。履歴INFOヘッダーには、転換の数を追跡およびカウントするために、通話転換に関連付けられた値を含む原因パラメーターをカウントする必要があるため、同等のものはありません。インデックス値を読むだけでは不十分です。「プレースホルダー」エントリを使用すると、履歴INFOヘッダーエントリは、実際の迂回が発生したことを反映する可能性があります。
Example of placeholder entry in the History-Info header:
歴史INFOヘッダーのプレースホルダーエントリの例：
<sip:unknown@unknown.invalid;cause=xxx>;index=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-entryの場合、次のhi-entryに位置する、原因パラムの値「404」を取得する必要があります。
Concerning local policies recommendations about headers coexistence in the INVITE request, see sections 2.2 and 7.5.
招待リクエストのヘッダーの共存に関するローカルポリシーの推奨事項については、セクション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].
セッションの確立中と同じ順序で転用エントリを作成するには、履歴INFOエントリを最下部まで最上位からマッピングする必要があります。選択された最初の履歴INFOヘッダーエントリは、最後の迂回ヘッダーエントリなどにマッピングされます。[RFC4458]に記載されているように、転用理由を反映した原因パラムを使用して、各履歴INFOエントリごとに1つの迂回ヘッダーエントリを作成する必要があります。
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.
=====================================================================
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"
=====================================================================
Note: For other optional History-Info parameters, there is no recommendation as Diversion header does not provide equivalent parameters.
注：他のオプションの履歴INFOパラメーターの場合、迂回ヘッダーが同等のパラメーターを提供しないため、推奨はありません。
Concerning local policies recommendations about headers coexistence in the INVITE request, see section 2.2.
招待リクエストのヘッダーの共存に関するローカルポリシーの推奨事項については、セクション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
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=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
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 --->| | |
| | |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.
異なるノードを含む1つのネットワークがあり、その一部は転換ヘッダーをサポートしているネットワーク、および履歴INFOヘッダーをサポートする他のネットワークがある場合、メッセージを処理するノードが次のノードを知らない場合、問題があります。メッセージ。このケースは、ネットワークに新しいノードと古いノードがあり、古いノードが転換ヘッダーを使用し、最近の履歴INFOヘッダーを使用している場合に発生する可能性があります。
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.
ネットワークの交換が発生している可能性がありますが、両方のノードがネットワークに共存する時期があります。さまざまなノード機能のために異なるサブスクライバータイプをサポートするために異なるノードが使用されている場合、問題がより重要です。この場合、Core Network内のHistory-infoヘッダーと転用ヘッダーの両方を渡す必要があります。
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.
これらのヘッダーは、メッセージを受信していようと、正しい迂回情報が受信されることを確認するために同等である必要があります。これには、受信したヘッダーが何であれ、ヘッダーを比較してヘッダーを変換できる必要があることが必要です。ノード機能に応じて、これがどのように処理されるかについて仮定を立てることができるかもしれません。
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 ノードをサポートする古い迂回ヘッダーが受信した履歴INFOヘッダーを渡さないことがわかっている場合、インターワーキングが容易になります。迂回ヘッダーのみでメッセージが受信された場合、「古い」ノードから発生しました。同等の履歴INFOエントリを作成することができ、これらは迂回ヘッダーと同様に渡すことができます。
o If the node creates a new History-Info header for a call diversion, then an additional Diversion header must be created.
o ノードが通話転換のために新しい履歴INFOヘッダーを作成する場合、追加の迂回ヘッダーを作成する必要があります。
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 次のノードが「古い」ノードである場合、そのノードによって転換ヘッダーが使用され、渡されたときに履歴INFOエントリがメッセージから削除されます。
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 次のノードが新しいノードである場合、迂回ヘッダーと履歴INFOヘッダーの両方の存在は、インターワーキングがすでに発生しており、迂回と履歴INFOエントリを同等と見なす必要があることを意味します。
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 両方のノードがHistory-INFOヘッダーと迂回ヘッダーの両方を渡すが、積極的に使用するだけの場合、両方のタイプのノードがインターワーキングを実行する必要があり、ヘッダー間の等価性を維持する必要があります。これにより、最終的には、ネットワーク内のすべてのノードが履歴INFOヘッダーをサポートすると、迂回ヘッダーの使用が非推奨になります。
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.
迂回ヘッダーまたは履歴INFOヘッダーの使用には、各迂回ユーザーまたはエンティティが要求されたプライバシーと整合性を適用する必要があります。整合性がなければ、要求されたプライバシー関数は格下げまたは排除され、ID情報を公開する可能性があります。機密性がなければ、ネットワーク上の盗聴者（またはユーザーとプライバシーサービスの間の仲介者）は、ユーザーがプライバシーサービスに不明瞭に求めた非常に個人情報を見ることができました。不正な挿入、これらのヘッダーの変更の削除は、ユーザーとアプリケーションに誤解を招く情報を提供できます。履歴INFOヘッダーまたは迂回ヘッダーのリダイレクト理由を提供できる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・ハルパーン、ボブ・ブレーデン、ロバート・スパークス。Merci A Lionel Morand、Xavier Marjou、およびPhilippe Fouquart。
[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：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、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、「VoicemailやInteractive Voice Response（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の増強」、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]第3世代パートナーシッププロジェクト、「技術仕様グループコアネットワークおよび端末、IPマルチメディア（IM）コアネットワーク（CN）サブシステムを使用した通信迂回（CDIV）、プロトコル仕様（リリース8）、3GPP TS 24.604 "、12月2008年。
[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]第3世代パートナーシッププロジェクト、「技術仕様グループコアネットワークと端末、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で説明されているメカニズムであり、1つのリダイレクトユーザーアドレスのみを輸送する簡単な方法と、招待リクエストのR-URIで転用が発生した理由を提供します。このメカニズムは、主にボイスメールへの呼び出しに使用されます。
Diversion header to Voicemail URI:
VoiceMail URIへの転用ヘッダー：
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
Mapping of the Redirection Reason is the same as for History-Info header with a default value set to 404.
リダイレクト理由のマッピングは、404に設定されたデフォルト値を持つ履歴INFOヘッダーの場合と同じです。
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に挿入されたリダイレクト情報の選択基準は、転送された招待リクエストの宛先である可能性があります（ボイスメールがこのユーザーにサービスを提供するかどうかにかかわらず）。
Note: This interworking could be done in addition to the interworking of the Diversion header into the History-Info header.
注：この相互作用は、迂回ヘッダーの歴史INFOヘッダーへのインターワーキングに加えて行うことができます。
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
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 France Telecom Orange 38-40 Rue General Leclerc Issy-Les-Moulineaux Cedex 9 92794フランス
Phone: +33 1 45 29 45 14
EMail: marianne.mohali@orange-ftgroup.com