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履歴-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.
この文書では、Diversionヘッダーと迂回路情報を呼び出す処理するために、歴史-Infoヘッダー間の推奨インターワーキングのガイドラインについて説明します。また、インターワーキングポリシーは、ヘッダの共存を管理することが提案されています。履歴-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 Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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ベース（ボイスオーバーIP）サービス（例えば、ボイスメール、対話型音声認識（IVR）、自動着信分配）のために、それは誰に、なぜセッションが転用されたから識別するために呼び出されるSIPユーザエージェントのために有用です。この情報は、様々なサービスプロバイダによってまたはアプリケーションによって使用されるためには、ネットワークを通過する必要があります。 [RFC4244]で定義された履歴-Infoヘッダと[RFC5806]で定義された歴史的な宛先ヘッダ、両方の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.
Diversionヘッダーの新しい実装と展開が強く推奨されていることに注意してください。
This document provides a mechanism for header-content translation between the Diversion header and the History-Info header.
この文書では、Diversionヘッダーと歴史-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]及び（ボイスメールURIを含む）SIPサービスURIを形成するためにその拡張[RFC4458]はリダイレクト情報を伝達するためにIETFによって推奨されています。これらはまた、「通信迂回（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.
もともと、Diversionヘッダーは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ヘッダーを標準化しました。これは、どのように、なぜセッションが受信されるかを決定するために受信部を可能にします。歴史-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).
Diversionヘッダーと歴史-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エンティティの挙動は、時には先を変更につながるの理由によって異なります。例えば、それはルートへの単純なプロキシセッションまたはアプリケーション・サーバーにあるかどうか付加サービスを提供しています。宛先ヘッダと履歴-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リターゲット/方向転換：リターゲット/方向転換は、プロキシサーバ/ユーザエージェントクライアント（UAC）は、要求にURI（Uniform Resource Identifier）を変更するので、要求のターゲットを変更する処理をいいます。これらの用語は、[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転送/着信転送/通信迂回を呼び出します。これらの用語は、[TS_24.604]等価であり、総合デジタル通信網（ISDN）通信流用付加サービスに基づく通信転用（CDIV）付加サービス、を参照して、3GPPで定義されました。彼らは、中または以前のセッション確立に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.
この文書では、歴史、情報またはのDiversionヘッダーを使用しなければならないとき、またはどのように記述するつもりはありません。以下は、インターワーキングが必要とされる文脈に明確化されています。
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.
歴史-Infoヘッダは着信転送情報を含むすべてのリターゲットの情報を格納するために使用されます。実際には、履歴-INFOヘッダ[RFC4244]は、関連するエントリ内の原因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.
両方のヘッダがコール転送のニーズに対応するので、迂回情報を混同することができ、または両方は、INVITE要求に非協調的な様式で存在する場合、矛盾します。だから、転用及び歴史-情報ヘッダは、独立して、同じセッションシグナリングに共存してはなりません。そしていつ、どのように追加の例をカバーするために、両方のヘッダーを維持するために、Diversionヘッダーと歴史-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つのヘッダが連動する必要があります。共存シナリオが別の1つのユースケースと異なる場合があるので宛先ヘッダと履歴-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.
通常の場合には、ネットワークトポロジの仮定は、本書に記載のインターワーキングは、それが履歴-Infoヘッダを使用して、2つの領域、一方との間の境界にあることを、コンフィギュレーションによって、認識している特定の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.
履歴-INFOヘッダは、標準的な解決策であるように、宛先ヘッダを使用してネットワークが履歴-Infoヘッダを使用してネットワークに情報を提供することができなければなりません。この場合、ヘッダの共存を避けるために、それはできるだけ頻繁に、交換する必要があるため、インターワーキング中のINVITE要求における歴史-InfoヘッダーとのDiversionヘッダー。
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.
、歴史-InfoヘッダーがDiversionヘッダーよりも広い範囲を持っているので、着信転送以外のニーズやサービスのために使用することができます。コール迂回情報を追跡することに加えて、履歴-Infoヘッダは、セッション履歴として作用し、すべての連続するR-URIの値を格納することができます。それは補足的（非迂回）の情報が含まれている場合は結果的に、それは混乱を避けるためのDiversionヘッダーの作成後に歴史-Infoヘッダーを削除するには良いはずです場合でも、歴史-Infoヘッダーは、SIPシグナリングにおける未修正のままにする必要があります。 Diversionヘッダーにマップすることができる値を持っていない歴史-情報ヘッダを持つことが可能です。この場合、迂回ヘッダとは相互動作は行われてはならない、そしてこの場合には何をすべきか、実装ごとに定義する必要があります。この点は、この文書の範囲から除外されます。
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.
Diversionヘッダーが歴史-Infoヘッダーを作成するために使用される場合、Diversionヘッダーは発信INVITEに除去されなければなりません。 Diversionヘッダーに存在するすべての情報は、歴史-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ヘッダが着信（宛先ヘッダに加えて）INVITE中に存在する場合、宛先ヘッダと履歴-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から来るが、以前の履歴-INFOヘッダを用いnetwork_1通過し（又はnetwork_2が連続URI情報を輸送するために履歴-Infoヘッダを使用）及び使用network_3しようINVITEの場合であってもよいです歴史-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.
この場合、INVITE受信は、宛先ヘッダと履歴-Infoヘッダを含んでいます。この文書で推奨したがって、network_3ため、履歴-INFOとヘッダが受信された宛先の両方から既存の情報を収集する単一履歴-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.ネットワークが一つだけヘッダを毎回使用するか、最新の両方のヘッダーを維持するかできない場合、時系列を認定することはできません。
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.歴史-Infoヘッダーは、着信転送情報よりも多く含まれている場合のみのDiversionヘッダーを持ってすることはできません。以前の政策提言が適用される場合宛先エントリが考慮宛先内部年表をとる履歴-Infoヘッダの最後に挿入されるように、時系列が尊重されます。
2.2.2. SIP Network/Terminal Using History-Info Header to SIP Network/Terminal Using Diversion Header
2.2.2. SIPネットワーク/端末のDiversionヘッダーを使用したネットワーク/端末をSIPに歴史-情報ヘッダーを使用して
When the History-Info header is interpreted to create a Diversion header, some precautions must be taken.
歴史-InfoヘッダーがDiversionヘッダーを作成するために解釈されている場合、いくつかの予防措置が取られなければなりません。
If the History-Info header contains only call forwarding information, then it must be deleted after the interworking.
歴史-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.
歴史-情報ヘッダは、他の情報が含まれている場合、分流ユーザーへの懸念の唯一の情報は、Diversionヘッダー内のエントリを作成するために使用しなければならず、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.
注意：歴史-Infoヘッダーには、特定のアプリケーションサーバ（AS）はまだシグナリングパスで呼び出されていたかどうかを知る必要があり、サービスによって、例えば、着信転送サービス以外の理由で使用することができます。コールは、後の歴史-Infoヘッダーを使用してネットワークに転送された場合、原因のみのDiversionヘッダーをサポートするネットワーク通過するに履歴情報を失わない方が良いでしょう。推奨される解決策は、歴史-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].
Diversionヘッダーが中に存在している場合は、着信（歴史-Infoヘッダーに加えて）、歴史-Infoヘッダ中に存在するがないのDiversionヘッダーで唯一の迂回路情報は、既存への最後のエントリ（より最新の）から挿入されなければならない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.
歴史-Infoヘッダーは、同じサービス対象ユーザのためのシーケンシャルフォークの記録を可能にします。それはコール転送「原因」パラメータが含まれている場合は、インターワーキングの間に、歴史-情報からのDiversionヘッダーにヘッダー、（インクリメント「インデックス」パラメータを使用して）フォークの状況を含む歴史、情報項目は、おそらくマップすることができます。インターワーキングエンティティは転用エントリを作成することを選択するか、インターワーキングを適用することができませんでした。選択は、ローカルポリシーに従って行うことができます。
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)
履歴情報= "歴史-情報" HCOLONハイエントリ*（COMMA HI-エントリー）
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-エントリは= HI-対象-に-URI *（SEMI HI-のparam）HI-対象-に-URI =名前-addrにHI-PARAM = HI-指数1 / HI-延長HI-指数= "インデックス" EQUAL * DIGITの*（DOT 1 * DIGIT）HI-延長=ジェネリック-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]で指定されています。 （最初のリストで）最上位の歴史・インフォメーションエントリは最も古い履歴情報に対応しています。
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パラメータが含まれていてもよいです。このオプションの原因URIパラメータは、次の構文を使用して、[RFC4458]で定義されます。
cause-param = "cause" EQUAL Status-Code
原因-PARAM = "原因" EQUALステータスコード
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.
このパラメータはまた、原因のparamという名前で、3GPP CDIV仕様[TS_24.604]の推奨転用-に、ユーザ着信転送の場合の歴史・インフォメーションエントリ（URI）に挿入する必要があります。転用理由原因のparamで使用される原因値は、RFC 4458に記載されていて、それは転送サービスを呼び出すための専用のパラメータであるので、その存在はHI-エントリは転換のユーザであることを決定するために使用されます。より正確には、各分流ユーザは、RFC 4458に記載されている原因値を有する原因PARAMを含むもの前HI-エントリに位置しています。
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]で定義されたReasonヘッダには、転向ユーザのHI-エントリにエスケープされなければなりません。 Reasonヘッダは、真のSIP応答コードに設定されたパラメータは、（ステータスコード）を受信し、原因を含んでいます。したがって、SIP応答に起因する着信転送の場合には、両方の原因パラメータが使用されるべきです。複雑さは、これらのパラメータはなく、同じHI-エントリにしていないのと同じ意味で歴史-Infoヘッダ内で同時に使用することができることです。唯一の原因-PARAMは、転換サービスを呼び出すために専用されています。 「原因」ReasonヘッダパラメータがDiversionヘッダーとマッピングの際に考慮されていません。
[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]はまた、R-URIに、その結果HI標的対URIに挿入することができる「目標」URIパラメータを定義します。このパラメータは、ボイスメールURI実装でINVITEリクエストを下流に転用ユーザアドレスを維持するために使用されます。この情報は、すでにハイエントリに存在するように、「目標」URIパラメータは、宛先ヘッダと相互作用について考慮されていません。宛先ヘッダから、および/またはR-URIのHI-エントリにおける「目標」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-エントリに含めることができます。
The index parameter is a string of digits, separated by dots, to indicate the number of forward hops and retargets.
indexパラメータは、前方ホップと再ターゲティングの数を示すために、ドットで区切られた数字の文字列です。
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
原因; last_diversion_target：歴史-情報：<SIP：？？diverting_user1_addrプライバシー=なし理由= SIPの％3Bcause％3D302>;指数= 1、<SIP：？diverting_user2_addr;原因= 480プライバシー=歴史> = 1.1、<一口インデックス= 486>。インデックス= 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)
流用= "転用" HCOLON転換-のparams *（COMMA転用-の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)]
流用-のparams =名前-addrに*（SEMI（迂回-理由/流用カウンタ/流用制限/流用-プライバシー/流用スクリーン/流用-拡張））迂回-理由= "理由" "/ EQUAL（ "不明"ユーザー・ビジー「/ 『無応答』 / 『利用不可』 / 『無条件』 / 『時刻』 / 『やる-ないディスターブ』 / 『たわみ』 / 『フォローミー』 /」アウト・オブ・サービス "/ "離れ"/トークン/引用符で囲まれた文字列）流用カウンタ= "カウンター" EQUAL 1 * 2DIGIT流用制限= "リミット" EQUAL 1 * 2DIGIT転用-プライバシー= "プライバシー" EQUAL（ "フル"/" 名"/ "URI"/ "オフ"/トークン/引用符で囲まれた文字列）転用スクリーン= "スクリーン" EQUAL（" YES」/ "NO" /トークン/引用符で囲まれた文字列）転用延長=トークン[EQUAL（トークン/引用-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]に推奨されているように、受信INVITEを組み合わせることができます。
Example:
例：
Diversion:
転換：
diverting_user2_addr; reason="user-busy"; counter=1; privacy=full, diverting_user1_addr; reason="unconditional"; counter=1; privacy=off
diverting_user2_addr;理由=「ユーザーが忙しいです」。カウンタ= 1。プライバシー=フル、diverting_user1_addr。理由=「無条件」。カウンタ= 1。プライバシー=オフ
The recommended interworking presented in this document should apply only for INVITE requests.
この文書の推奨インターワーキングは、INVITEリクエストを申請してください。
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応答でのDiversionヘッダーと歴史-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応答を受信した後に、INVITEリダイレクトする場合、それは転送されたINVITEの最後のエントリのいずれかの宛先ヘッダーまたは（その能力に応じて）履歴-Infoヘッダとして追加しなければなりません。ローカルポリシーは、INVITE次に受信したヘッダを送信するために適用することもできます。
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.
歴史-情報が存在し得る他のメッセージはコール転送サービスに使用されていないとのDiversionヘッダーに変更すべきではありません。宛先ネットワークは、受信した履歴-Infoヘッダーに透明でなければなりません。
Note: the following mapping is inspired from the ISDN User Part (ISUP) to the SIP interworking described in [TS_29.163].
注：以下のマッピングは[TS_29.163]に記載のSIPインターワーキングのISDNユーザ部（ISUP）からインスピレーションを得ています。
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リクエストに存在しない場合にのみ有効です。少なくとも一つの歴史-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歴史-情報エントリを作成する必要があります。セッション確立時よりも、同じ順序で歴史-情報エントリを作成するには、転用エントリは最上位の一番下までからマッピングする必要があります。各迂回エントリは、歴史・インフォメーションエントリにマップされなければなりません。追加の歴史・インフォメーションエントリ（最後の1）が流用-にINVITEを受信したのR-URIでパーティアドレスが存在して作成する必要があります。マッピングは以下の通りです。
The first entry created in the History-Info header contains:
歴史-Infoヘッダーで作成された最初のエントリが含まれています。
- a hi-targeted-to-uri with the name-addr parameter of the bottom-most Diversion header.
- HI-対象ツーuriの一番下のDiversionヘッダーの名前-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.
- プライバシーのパラメータは、一番下の転用のエントリに存在する場合、後述のように、[プライバシーヘッダは歴史-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):
（下から上へ）それぞれ以下のDiversionエントリについて、歴史、情報項目は、（上から下へ）、以下のように作成されます。
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:
最後の歴史・インフォメーションエントリが作成され、含まれています：
- a hi-targeted-to-uri with the Request-URI of the INVITE request.
- HI-対象ツーURI INVITEリクエストのRequest-URIを持ちます。
- a cause-param from the top-most Diversion entry, mapped from the diversion-reason as described above.
- 上記のように流用理由からマッピングされた最上位の宛先エントリから原因PARAM、。
- 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"
- インデックスが以前作成したインデックスに設定し、「0.1" でインクリメント
Notes:
ノート：
1. For other optional Diversion parameters, there is no recommendation as History-Info header does not provide equivalent parameters.
他の任意の宛先パラメータの1、履歴-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.推奨デフォルト値にマッピングされている迂回-理由値の値については、また別の値を選択することが可能である可能性があります。原因-PARAM URIパラメータが迂回-理由パラメータよりも少ない可能な値を提供しています。しかし、3GPPで定義され、それはケースの大部分を覆うよう原因PARAM値リスト[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.
名前-addrパラメータにURIが、電話持ってすることはできないようです：：3のDiversionヘッダーは、電話番号が含まれている可能性が歴史-InfoヘッダーにURIを。そして電話：[RFC3261]は、SIPとの間のマッピングに関する表示与えるURIを、この特定の場合には、転換は、前のネットワークで発生した、有効なホスト側が決定することは困難であるとして有効なのHostPortを割り当てることは困難です。 URIのDiversionヘッダーで、歴史-Infoヘッダーがユーザー=電話と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
<一口：unknown@unknown.invalid;原因= XXX>;指数= 1.1
<sip:bob_addr;cause=404>;index=1.1.1
<一口：bob_addr;原因= 404>;指数= 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」前の迂回ユーザーの分流理由を反映しています。プレースホルダハイエントリについて、値が「404」が原因PARAMのために取らなければならないので、次のHi-エントリに位置します。
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].
セッション確立時よりも、同じ順序で転用エントリを作成するには、歴史・インフォエントリは最上位までの一番下からマッピングする必要があります。選択された第一履歴-Infoヘッダエントリが最後の宛先ヘッダエントリなどにマッピングされます。一つの宛先ヘッダエントリは、[RFC4458]に記載されている原因-paramは転向理由を反映して、各履歴-INFOエントリのために作成されなければなりません。
In this case, the History-Info header must be mapped into the Diversion header as following:
この場合、ヒストリー-Infoヘッダは、次のように宛先ヘッダーにマッピングされなければなりません。
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.
注意：他のオプションの歴史-情報パラメータの場合、同等のパラメータを提供していないのDiversionヘッダーとして何らの推薦はありません。
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
last_diverting_target転用をINVITE：diverting_user3_addressを、理由=無条件;カウンタ= 1;プライバシー=オフ、diverting_user2_address;理由=ユーザー忙しい;カウンタ= 1;プライバシー=フル、diverting_user1_address;理由=無応答;カウンタ= 1;プライバシー=オフ
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
歴史-情報：<SIP：diverting_user1_address。プライバシー=なし>。インデックス= 1、<SIP：diverting_user2_address。原因= 408プライバシー=歴史>;指数= 1.1、<SIP：？diverting_user3_address。原因= 486プライバシー=なし>;指数= 1.1.1、<SIP：？last_diverting_target。原因= 302>;指数= 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
歴史-情報：<SIP：？diverting_user1_addressプライバシー=歴史>;インデックス= 1、<SIP：diverting_user2_address。原因= 302？プライバシー=なし>;指数= 1.1、<SIP：last_diverting_target。原因= 486>;指数= 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
転換：diverting_user2_address。理由=ユーザー忙しいです。カウンタ= 1。プライバシー=オフ、diverting_user1_address。理由=無条件;カウンタ= 1。 =完全なプライバシー
7.3. Example with Two SIP Networks Using History-Info Header Interworking with a SIP Network Using Diversion Header
7.3. 転換ヘッダーを使用してSIPネットワークでの歴史、情報ヘッダーインターワーキングを使用して、2つの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.
- > 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.
それらのいくつかは、宛先ヘッダと履歴-Infoヘッダをサポートする他のものをサポートする、異なるノードを含む一つのネットワークがある場合に、メッセージを処理する任意のノードが処理する次のノードを知らないという問題がありますメッセージ。ネットワークは新旧ノード、Diversionヘッダーと、より最近の歴史-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.
ネットワークの交換が発生してもよいが、両方のノードがネットワークに共存する時間があるだろう。異なるノードが異なるノードの能力に起因するさまざまなユーザタイプをサポートするために使用されている場合は、問題がより重要です。この場合、コアネットワーク内履歴-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.
それは古いのDiversionヘッダーサポートするノードは任意の歴史-Infoヘッダ受信に合格しないことが知られている場合は、O、その後、インターワーキングが容易になります。メッセージは唯一のDiversionヘッダーで受信された場合、それは「古い」ノードから発信しています。同等の歴史・インフォエントリを作成することができ、これらは、その後のDiversionヘッダーと同様に渡すことができます。
o If the node creates a new History-Info header for a call diversion, then an additional Diversion header must be created.
ノードは、着信転送のための新たな歴史-Infoヘッダーを作成する場合は、O、その後、追加のDiversionヘッダーを作成する必要があります。
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、両方の宛先ヘッダと履歴-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.
両方のノードが履歴-Infoヘッダと宛先ヘッダの両方に合格し、だけ積極的にいずれかを使用する場合、O、次いで、ノードの両方のタイプは、インターワーキングを実行するために必要とヘッダ間の等価性を維持しなければなりません。これは、最終的には廃止さDiversionヘッダーを使用することになりますときに、ネットワークのサポートの歴史-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.
Diversionヘッダーや歴史-Infoヘッダーの使用は、各転用、ユーザまたはエンティティに頼ま要求されたプライバシーと整合性の適用を必要としています。整合性がなければ、要求されたプライバシー機能は、潜在的に識別情報を暴露する、ダウングレードまたは排除することができます。機密性がなければ、ネットワーク（またはユーザーとプライバシーサービスとの間のいずれかの仲介）上の盗聴者は、ユーザーが不明瞭にプライバシーサービスを求めていることを非常に個人的な情報を見ることができました。不正な挿入、これらのヘッダの変更を削除するには、ユーザーやアプリケーションへの誤解を招くような情報を提供することができます。履歴-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.
エディタはスティーブNorreys、ヤン・ヴァン・ヘール、マーティン・ドリー、フランシスコ・シルバ、ジュゼッペSciortino、Cinza Amenta、クリステルHolmbergの、イアン・エルツ、ジャン=フランソワラバ、メアリー・バーンズ、フランソワAudet、エリックが提供する建設的なフィードバックとサポートに感謝します佐々木、志田シューベルト、ジョエルM.ハルパーン、ボブブレーデン、およびロバート・スパークス。メルシーライオネル・モラン、ザビエルMarjou、およびフィリップ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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[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.、オラン、D.、およびG.カマリロ、RFC 3326 "セッション開始プロトコル（SIP）理由ヘッダーフィールド" 2002年12月。
[RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244]バーンズ、M.、エド。、 "リクエスト履歴情報のためのセッション開始プロトコル（SIP）への拡張"、RFC 4244、2005年11月。
[RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in SIP", RFC 5806, March 2010.
[RFC5806]レヴィ、S.及びM.モハーリ、エド。、 "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]ジェニングス、C.、Audet、F.、およびJ.エルウェル、RFC 4458、2006年4月 "などのボイスメールや対話型音声応答（IVR）などのアプリケーションのためのセッション開始プロトコル（SIP）のURI"。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、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世代パートナーシッププロジェクト、「技術仕様グループコアネットワークと端末、通信迂回（CDIV）を使用して、IPマルチメディア（IM）コアネットワーク（CN）サブシステム、プロトコル仕様（リリース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月。
Appendix A. Interworking between Diversion Header and Voicemail URI
転換ヘッダーとボイスメールURI間の付録A.インターワーキング
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は、唯一のリダイレクトユーザアドレスを輸送するための簡単な方法と転換は、INVITEリクエストのR-URIで発生した理由を提供するために、RFC 4458で説明されたメカニズムです。このメカニズムは、主にボイスメールに着信転送のために使用されています。
Diversion header to Voicemail URI:
ボイスメールURIへ迂回ヘッダ：
Received: Diversion: userA-address;reason=user-busy;counter=1;privacy=full
受信：転換：ユーザA-アドレス;理由=ユーザー忙しい;カウンタ= 1;プライバシー=フル
Sent (Voicemail URI created in the R-URI line of the INVITE): sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0
SIP：送信（ボイスメールURIは、INVITEのR-URIラインで作成された）;ターゲット=ユーザーA-アドレス; voicemail@example.com原因= 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に挿入されたリダイレクト情報の選択基準は、INVITE転送要求（ボイスメールこのユーザーを提供していたか否か）の宛先とすることができます。
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
受信した：SIP INVITE：voicemail@example.comを; \目標= SIP：+ 33145454500% 40example.com;ユーザー=電話; \原因= 302 SIP / 2.0
Sent in the forwarded INVITE: Diversion: sip:+ 33145454500%40example.com;user=phone;reason=unconditional;counter=1
宛先：SIP：;ユーザー=電話、理由=無条件;カウンタ= 1 + 33145454500%の40example.com転送にINVITEを送信
Author's Address
著者のアドレス
Marianne Mohali France Telecom Orange 38-40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France
マリアンヌモハーリフランステレコムオレンジ38-40 RUEデュ一般ルクレールイシレムリノーセデックス9、フランス92794
Phone: +33 1 45 29 45 14 EMail: marianne.mohali@orange-ftgroup.com
電話：+33 1 45 29 45 14 Eメール：marianne.mohali@orange-ftgroup.com