[要約] RFC 7544は、SIPのDiversionとHistory-Infoヘッダーフィールド間の転送情報のマッピングと相互運用に関するものです。このRFCの目的は、DiversionとHistory-Infoヘッダーフィールドの相互運用性を向上させ、通信セッションの転送情報を効果的に管理することです。
Independent Submission M. Mohali
Request for Comments: 7544 Orange
Obsoletes: 6044 August 2015
Category: Informational
ISSN: 2070-1721
Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）の転換とHistory-Infoヘッダーフィールド間の転換情報のマッピングとインターワーキング
Abstract
概要
Although the SIP History-Info header field described in RFC 7044 is the solution adopted in IETF, the non-standard Diversion header field described, as Historic, in RFC 5806 is nevertheless already implemented and used for conveying call-diversion-related information in Session Initiation Protocol (SIP) signaling.
RFC 7044で説明されているSIP History-InfoヘッダーフィールドはIETFで採用されたソリューションですが、RFC 5806でHistoricと説明されている非標準のDiversionヘッダーフィールドは、セッションで通話転送関連情報を伝達するためにすでに実装および使用されています開始プロトコル（SIP）シグナリング。
RFC 7044 obsoletes the original RFC 4244 and redefines the History-Info header field for capturing the history information in requests.
RFC 7044は元のRFC 4244を廃止し、履歴情報を要求に取り込むためのHistory-Infoヘッダーフィールドを再定義します。
Since the Diversion header field is used in existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This document describes a recommended interworking guideline between the Diversion header field and the History-Info header field to handle call diversion information. This work is intended to enable the migration from non-standard implementations toward IETF specification-based implementations.
Diversionヘッダーフィールドは、コール転送情報の転送のために既存のネットワーク実装で使用されるため、SIP History-Info標準化ソリューションとの相互作用が必要です。このドキュメントでは、コール転送情報を処理するための、DiversionヘッダーフィールドとHistory-Infoヘッダーフィールドの間の推奨されるインターワーキングガイドラインについて説明します。この作業は、非標準の実装からIETF仕様ベースの実装への移行を可能にすることを目的としています。
This document obsoletes RFC 6044, which describes the interworking between the Diversion header field defined in RFC 5806 and the obsoleted History-Info header field defined on RFC 4244.
このドキュメントはRFC 6044を廃止します。RFC6044は、RFC 5806で定義されたDiversionヘッダーフィールドとRFC 4244で定義された廃止されたHistory-Infoヘッダーフィールドの間の相互作用について説明しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7544.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7544で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Overview ...................................................4
1.2. Background .................................................4
1.3. From RFC 4244 to RFC 7044 ..................................5
2. Problem Statement ...............................................5
3. Interworking Recommendations ....................................7
3.1. General Recommendations ....................................7
3.2. Privacy Considerations .....................................8
3.3. Headers in SIP Method .....................................10
3.4. SIP Network/Terminal Using Diversion Header Field
to SIP Network/Terminal Using History-Info Header Field ...10
3.5. SIP Network/Terminal Using History-Info Header
Field to SIP Network/Terminal Using Diversion
Header Field ..............................................12
4. Reminder of the Syntax for Header Fields .......................13
4.1. History-Info Header Field Syntax ..........................13
4.2. Diversion Header Field Syntax .............................16
5. Diversion Header Field to History-Info Header Field ............16
6. History-Info Header Field to Diversion Header Field ............20
7. Examples .......................................................22
7.1. Example with Diversion Header Field Changed into
History-Info Header Field .................................22
7.2. Example with History-Info Header Field Changed into
Diversion Header Field ....................................22
7.3. Example with Two SIP Networks Using History-Info Header
Field Interworking with a SIP Network Using Diversion
Header Field ..............................................22
7.4. Additional Interworking Cases .............................24
8. Backward Compatibility .........................................26
9. Security Considerations ........................................26
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
Appendix A. Interworking between Diversion Header Field and
Voicemail URI ........................................29
A.1. Diversion Header Field to Voicemail URI ...................29
A.2. Voicemail URI to Diversion Header Field ...................29
Acknowledgements ..................................................30
Author's Address ..................................................30
For some services based on VoIP (Voice over IP) services (e.g., voicemail, Interactive Voice Recognition (IVR), or automatic call distribution), it is helpful for the called SIP user agent to identify from whom and why the session was diverted. For this information to be used by various service providers or by applications, it needs to pass through the network. This is possible with two different SIP header fields: the History-Info header field defined in [RFC7044] and the historic Diversion header field defined in [RFC5806]. Both of these header fields are able to transport diversion information in SIP signaling.
VoIP（Voice over IP）サービスに基づく一部のサービス（ボイスメール、インタラクティブ音声認識（IVR）、自動コール配信など）では、呼び出されたSIPユーザーエージェントが、誰から、およびセッションが迂回されたのかを特定することが役立ちます。この情報をさまざまなサービスプロバイダーまたはアプリケーションで使用するには、ネットワークを通過する必要があります。これは、2つの異なるSIPヘッダーフィールドで可能です。[RFC7044]で定義されているHistory-Infoヘッダーフィールドと、[RFC5806]で定義されている履歴Diversionヘッダーフィールドです。これらのヘッダーフィールドはどちらも、SIPシグナリングで宛先変更情報を転送できます。
Although the Diversion header field is not standardized, it has been widely implemented. Therefore, it is useful to have guidelines to make this header field interwork with the standard History-Info header field.
Diversionヘッダーフィールドは標準化されていませんが、広く実装されています。したがって、このヘッダーフィールドを標準のHistory-Infoヘッダーフィールドと連動させるためのガイドラインを用意すると便利です。
Note that new implementation and deployment of the Diversion header field are strongly discouraged.
Diversionヘッダーフィールドの新しい実装と展開は強くお勧めしません。
This document provides a mechanism for the translation of header field content between the Diversion header field and the History-Info header field.
このドキュメントは、DiversionヘッダーフィールドとHistory-Infoヘッダーフィールドの間でヘッダーフィールドの内容を変換するメカニズムを提供します。
This document obsoletes [RFC6044].
このドキュメントは廃止されました[RFC6044]。
The obsoleted History-Info header field [RFC4244] and its extension for forming SIP service URIs (including Voicemail URI) [RFC4458] used to be recommended by IETF to convey redirection information. They also used to be recommended in the Communication Diversion (CDIV) 3GPP specification [TS_24.604].
廃止されたHistory-Infoヘッダーフィールド[RFC4244]およびSIPサービスURI（ボイスメールURIを含む）を形成するための拡張[RFC4458]は、リダイレクト情報を伝えるためにIETFによって推奨されていました。また、Communication Diversion（CDIV）3GPP仕様[TS_24.604]でも推奨されていました。
The Diversion header field was originally described in a document that was submitted to the SIP Working Group and was eventually published as an Independent Submission as [RFC5806] for the historical record; it serves as a reference for this RFC.
Diversionヘッダーフィールドは、SIPワーキンググループに提出されたドキュメントで最初に説明され、最終的には履歴レコードの[RFC5806]として独立提出として公開されました。このRFCのリファレンスとして機能します。
This header field contains a list of diverting URIs and associated information providing specific information as the reason for the call diversion. Most of the first SIP-based implementations have implemented the Diversion header field when no standard solution was ready to deploy. The IETF has standardized the History-Info header field partly because it can transport general history information.
このヘッダーフィールドには、転送URIのリストと、着信転送の理由として特定の情報を提供する関連情報が含まれています。最初のSIPベースの実装のほとんどは、標準ソリューションを展開する準備ができていないときにDiversionヘッダーフィールドを実装しています。 IETFは、一般的な履歴情報を転送できるため、History-Infoヘッダーフィールドを標準化しました。
This allows the receiving party to determine how and why the session is received. As the History-Info header field may contain further information than call diversion information, it is critical to avoid losing information and to be able to extract the relevant data using the retargeting cause URI parameter described in [RFC4458] for the transport of the call forwarding reason.
これにより、受信側はセッションを受信する方法と理由を決定できます。 History-Infoヘッダーフィールドには、コール転送情報以外の情報が含まれている可能性があるため、情報の損失を回避し、[RFC4458]で説明されているリターゲティング原因URIパラメータを使用して関連データを抽出して、コール転送を転送することが重要です。理由。
The Diversion header field and the History-Info header field have different syntaxes, which are described in this document. Note that the main difference is that the History-Info header field is a chronological writing header whereas the Diversion header field applies a reverse chronology (i.e., the first diversion entry read corresponds to the last diverting user).
DiversionヘッダーフィールドとHistory-Infoヘッダーフィールドは、このドキュメントで説明されている構文が異なります。主な違いは、History-Infoヘッダーフィールドが年代順の書き込みヘッダーであるのに対し、Diversionヘッダーフィールドは年代順が逆になることです（つまり、最初に読み取られた迂回エントリは最後の迂回ユーザーに対応します）。
Appendix A provides an interworking guideline between the Diversion header field and the Voicemail URI, which is another way to convey diversion information without using the History-Info header field. The Voicemail URI is defined in [RFC4458].
付録Aは、DiversionヘッダーフィールドとボイスメールURIの間のインターワーキングガイドラインを示しています。これは、History-Infoヘッダーフィールドを使用せずに転送情報を伝達するもう1つの方法です。ボイスメールURIは[RFC4458]で定義されています。
The details of why and how [RFC4244] was obsoleted by [RFC7044] are provided in Section 16 of [RFC7044].
[RFC4244]が[RFC7044]によって廃止された理由と方法の詳細は、[RFC7044]のセクション16に記載されています。
The main changes for implementation of the History-Info header field are as follows:
History-Infoヘッダーフィールドの実装に関する主な変更点は次のとおりです。
1. The header field parameters "mp", "rc", and "np" were added to capture the specific method by which a target is determined.
1. ヘッダーフィールドパラメーター「mp」、「rc」、および「np」が追加され、ターゲットが決定される特定のメソッドをキャプチャします。
2. A way to indicate a gap in the History-Info header field was added by using a "0" in the index.
2. インデックスで「0」を使用することにより、History-Infoヘッダーフィールドのギャップを示す方法が追加されました。
3. To apply privacy, entries were anonymized rather than removed.
3. プライバシーを適用するために、エントリは削除されるのではなく匿名化されました。
4. Many SHOULDs were changed into MUSTs to have a more reliable header.
4. 多くのSHOULDは、より信頼できるヘッダーを持つようにMUSTに変更されました。
Backward-compatibility aspects are discussed in Section 8 of this document.
下位互換性については、このドキュメントのセクション8で説明します。
This section provides the baseline terminology used in the rest of the document and defines the scope of interworking between the Diversion header field and the History-Info header field.
このセクションでは、ドキュメントの残りの部分で使用される基本的な用語を提供し、DiversionヘッダーフィールドとHistory-Infoヘッダーフィールドの間の相互作用の範囲を定義します。
There are many ways in which SIP signaling can be used to modify a session destination before it is established and many reasons for doing so. The behavior of the SIP entities that will have to further process the session downstream will sometimes vary depending on the reasons that led to changing the destination, for example, whether it is for a simple proxy to route the session or for an application server (AS) to provide a supplementary service. The Diversion header field and the History-Info header field differ in the approach and scope of addressing this problem.
SIPシグナリングを使用して、セッションの宛先が確立される前にそれを変更できる多くの方法と、そのための多くの理由があります。セッションをさらに下流で処理する必要があるSIPエンティティの動作は、単純なプロキシがセッションをルーティングするのか、アプリケーションサーバー（AS ）補足サービスを提供する。 DiversionヘッダーフィールドとHistory-Infoヘッダーフィールドは、この問題への対処方法と範囲が異なります。
For clarity, the following vocabulary is used in this document:
明確にするために、このドキュメントでは次の用語を使用しています。
o Retarget/redirect: these terms refer to the process of a Proxy Server/User Agent Client (UAC) changing a Request-URI (Section 7.1 of [RFC3261]) in a request and thus changing the target of the request. This includes changing the Request-URI due to a location service lookup and redirect processing. This also includes internal (to a proxy/SIP intermediary) changes of the URI prior to forwarding of the request. The term "retarget" is defined in [RFC7044].
o 再ターゲット/リダイレクト：これらの用語は、プロキシサーバー/ユーザーエージェントクライアント（UAC）がリクエストのリクエストURI（[RFC3261]のセクション7.1）を変更し、リクエストのターゲットを変更するプロセスを指します。これには、位置情報サービスの検索とリダイレクト処理によるRequest-URIの変更が含まれます。これには、リクエストを転送する前のURIの（プロキシ/ SIP中間の）内部変更も含まれます。 「リターゲット」という用語は[RFC7044]で定義されています。
o Call forwarding/call diversion/communication diversion: these terms are equivalent and refer to the Communications Diversion (CDIV) supplementary services, based on the ISDN Communication diversion supplementary services and defined in 3GPP [TS_24.604]. They are applicable to entities that are intended to modify the original destination of an IP multimedia session during or prior to the session establishment.
o 自動転送/自動転送/通信転送：これらの用語は同等であり、ISDN通信転送補足サービスに基づいており、3GPP [TS_24.604]で定義されている通信転送（CDIV）補足サービスを指します。これらは、セッションの確立中または確立前にIPマルチメディアセッションの元の宛先を変更することを目的としたエンティティに適用できます。
This document does not intend to describe when or how History-Info or Diversion header fields should be used. Hereafter is provided clarification on the context in which the interworking is required.
このドキュメントでは、History-InfoまたはDiversionヘッダーフィールドをいつどのように使用する必要があるかについては説明しません。以下では、インターワーキングが必要なコンテキストについて説明します。
The Diversion header field has exactly the same scope as the call diversion service, and each header field entry reflects a call diversion invocation. The Diversion header field is used for recording call forwarding information that could be useful to network entities downstream. Today, this SIP header field is implemented by several manufacturers and deployed in networks.
Diversionヘッダーフィールドは、コール転送サービスとまったく同じスコープを持ち、各ヘッダーフィールドエントリは、コール転送呼び出しを反映しています。 Diversionヘッダーフィールドは、ダウンストリームのネットワークエンティティに役立つ可能性のあるコール転送情報を記録するために使用されます。現在、このSIPヘッダーフィールドは複数の製造元によって実装され、ネットワークに展開されています。
The History-Info header field is used to store all retargeting information, including call diversion information. As such, the History-Info header field [RFC7044] is used to convey call-diversion-related information by using a cause URI parameter [RFC4458] in the relevant entry.
History-Infoヘッダーフィールドは、着信転送情報を含むすべてのリターゲティング情報を格納するために使用されます。そのため、History-Infoヘッダーフィールド[RFC7044]は、関連するエントリの原因URIパラメータ[RFC4458]を使用して、コール転送関連情報を伝達するために使用されます。
Note, however, that the use of cause URI parameter [RFC4458] in a History-Info entry for a call diversion is specific to the 3GPP specification [TS_24.604]. [RFC4458] focuses on retargeting toward a voicemail server and does not specify whether the cause URI parameter should be added in a URI for other cases. As a consequence, implementations that do not use the cause URI parameter for call forwarding information are not considered for the mapping described in this document. Nevertheless, some recommendations are given in the next sections on how to avoid the loss of non-mapped information at the boundary between a network region using the History-Info header field and one using the Diversion header field.
ただし、着信転送のHistory-Infoエントリで原因URIパラメータ[RFC4458]を使用することは、3GPP仕様[TS_24.604]に固有であることに注意してください。 [RFC4458]は、ボイスメールサーバーへの再ターゲットに焦点を当てており、他の場合に原因URIパラメータをURIに追加する必要があるかどうかを指定していません。その結果、着信転送情報に原因URIパラメータを使用しない実装は、このドキュメントで説明されているマッピングでは考慮されません。それでも、History-Infoヘッダーフィールドを使用するネットワーク地域とDiversionヘッダーフィールドを使用するネットワーク地域の間の境界で、マップされていない情報の損失を回避する方法に関するいくつかの推奨事項を次のセクションで示します。
[RFC7044] defines three header field parameters: "rc", "mp", and "np". The header field parameters "rc" and "mp" indicate the mechanism by which a new target for a request is determined. The header field "np" reflects that the target has not changed. All parameters contain an index whose value refers to the hi-index of the hi-entry, which contains a hi-targeted-to-uri that represents the Request-URI that was retargeted.
[RFC7044]は、「rc」、「mp」、「np」の3つのヘッダーフィールドパラメータを定義しています。ヘッダーフィールドパラメータ「rc」と「mp」は、リクエストの新しいターゲットが決定されるメカニズムを示します。ヘッダーフィールド「np」は、ターゲットが変更されていないことを反映しています。すべてのパラメーターには、値がhi-entryのhi-indexを参照するインデックスが含まれています。これには、リターゲットされたRequest-URIを表すhi-targeted-to-uriが含まれています。
Since both header fields address call forwarding needs, diverting information could be mixed up or be inconsistent if both are present in an uncoordinated fashion in the INVITE request. So, Diversion and History-Info header fields must not independently coexist in the same session signaling. This document addresses how to convert information between the Diversion header field and the History-Info header field and when and how to preserve both header fields to cover additional cases.
両方のヘッダーフィールドがコール転送のニーズに対応しているため、INVITEリクエストで両方が調整されていない方法で存在すると、転送情報が混同されたり、矛盾したりする可能性があります。したがって、DiversionおよびHistory-Infoヘッダーフィールドは、同じセッションシグナリング内で独立して共存してはなりません。このドキュメントでは、DiversionヘッダーフィールドとHistory-Infoヘッダーフィールド間で情報を変換する方法と、両方のヘッダーフィールドを保持して追加のケースをカバーする方法と方法について説明します。
For the transportation of consistent diversion information downstream, it is necessary to make the two header fields interwork. Interworking between the Diversion header field and the History-Info header field is introduced in Sections 5 and 6. Since the coexistence scenario may vary from one use case to another, guidelines regarding interaction of header fields are proposed in Section 3.
ダウンストリームで一貫した転送情報を転送するには、2つのヘッダーフィールドを連動させる必要があります。 DiversionヘッダーフィールドとHistory-Infoヘッダーフィールド間のインターワーキングについては、セクション5と6で説明しています。共存シナリオはユースケースによって異なるため、セクション3でヘッダーフィールドの相互作用に関するガイドラインを提案します。
Interworking function (IWF):
インターワーキング機能（IWF）：
In a normal case, the network topology assumption is that the interworking described in this document should be performed by a specific SIP border device that is aware, by configuration, that it is at the border between two regions, one using the History-Info header field and one using the Diversion header field.
通常の場合、ネットワークトポロジの前提は、このドキュメントで説明されているインターワーキングが特定のSIPボーダーデバイスによって実行される必要があるということです。構成によって、2つのリージョンの境界にあることを認識し、1つはHistory-Infoヘッダーを使用します。フィールドとDiversionヘッダーフィールドを使用するフィールド。
As the History-Info header field is a standard solution, a network using the Diversion header field must be able to provide information to a network using the History-Info header field. In this case, to avoid coexistence of header fields, it is required to replace, as often as possible, the Diversion header field with the History-Info header field in the INVITE request during the interworking.
History-Infoヘッダーフィールドは標準的なソリューションであるため、Diversionヘッダーフィールドを使用するネットワークは、History-Infoヘッダーフィールドを使用してネットワークに情報を提供できる必要があります。この場合、ヘッダーフィールドの共存を回避するために、インターワーキング中にINVITE要求のDiversionヘッダーフィールドをHistory-Infoヘッダーフィールドで可能な限り頻繁に置き換える必要があります。
Since, the History-Info header field has a wider scope than the Diversion header field, it may be used for needs and services other than call diversion. In addition, to trace call diversion information, the History-Info header field also acts as a session history and can store all successive Request-URI values. Consequently, even if it should be better to remove the History-Info header field after the creation of the Diversion header field to avoid confusion, the History-Info header field must remain unmodified in the SIP signaling if it contains supplementary (non-diversion) information. It is possible to have History-Info header fields that do not have values that can be mapped into the Diversion header field. In this case, no interworking with the Diversion header field should be performed, and it must be defined per implementation what to do in this case. This point is out of the scope of this document.
History-Infoヘッダーフィールドは、Diversionヘッダーフィールドよりもスコープが広いため、コール転送以外のニーズやサービスに使用できます。さらに、通話転送情報を追跡するために、History-Infoヘッダーフィールドはセッション履歴としても機能し、連続するすべてのRequest-URI値を格納できます。その結果、混乱を避けるためにDiversionヘッダーフィールドの作成後にHistory-Infoヘッダーフィールドを削除した方がよい場合でも、History-Infoヘッダーフィールドに補足（非迂回）が含まれている場合は、SIPシグナリングで変更しないでおく必要があります。情報。 Diversionヘッダーフィールドにマップできる値を持たないHistory-Infoヘッダーフィールドを持つことが可能です。この場合、Diversionヘッダーフィールドとのインターワーキングは実行されません。この場合、何をするかを実装ごとに定義する必要があります。この点は、このドキュメントの範囲外です。
In conclusion, it is recommended to have local policies minimizing the loss of information and find the best way to keep it up to the terminating user agent.
結論として、情報の損失を最小限に抑え、それを終端のユーザーエージェントまで維持するための最良の方法を見つけるローカルポリシーを持つことをお勧めします。
The following sections describe the basic use cases. Additional interworking cases are described in Section 7.4.
次のセクションでは、基本的な使用例について説明します。追加のインターワーキングケースについては、セクション7.4で説明します。
When a SIP message is forwarded to a domain for which the SIP intermediary is not responsible, a Privacy Service at the boundary of the domain applies the appropriate privacy based on the value of the Privacy header field in the message header or in the privacy parameter within the concerned header:
SIPメッセージがSIP仲介者が責任を負わないドメインに転送されると、ドメインの境界にあるプライバシーサービスは、メッセージヘッダーまたはプライバシーパラメータ内のプライバシーヘッダーフィールドの値に基づいて適切なプライバシーを適用します関連するヘッダー：
1. For the History-Info header field, it is the Privacy header field included as the "headers" component of the hi-targeted-to-uri in the individual hi-entries with the priv-value "history".
1. History-Infoヘッダーフィールドの場合は、priv-valueが「history」である個々のhiエントリのhi-targeted-to-uriの「headers」コンポーネントとして含まれているPrivacyヘッダーフィールドです。
2. For the Diversion header field, it is the diversion-privacy parameter "privacy" in each Diversion header field.
2. Diversionヘッダーフィールドの場合は、各Diversionヘッダーフィールドのdiversion-privacyパラメータ「privacy」です。
For the History-Info header field, as recommended in [RFC7044]:
[RFC7044]で推奨されているHistory-Infoヘッダーフィールドの場合：
o If there is a Privacy header field in the message header of a request with a priv-value of "header" or "history", then all the hi-targeted-to-uris (in the hi-entries associated with the domain for which the SIP intermediary is responsible) are anonymized by the Privacy Service. The Privacy Service must change any hi-targeted-to-uri in these hi-entries that have not been anonymized to the anonymous SIP URI "anonymous@anonymous.invalid" as recommended in Sections 4.1.1.2 and 4.1.1.3 of [RFC3323].
o priv-valueが「header」または「history」のリクエストのメッセージヘッダーにプライバシーヘッダーフィールドがある場合、すべてのhi-targeted-to-uris（そのドメインに関連付けられたhi-entries内） SIP仲介者が責任を負います）は、プライバシーサービスによって匿名化されます。プライバシーサービスは、[RFC3323]のセクション4.1.1.2および4.1.1.3で推奨されているように、匿名化されていないこれらのhi-entriesのhi-targeted-to-uriを匿名のSIP URI "anonymous@anonymous.invalid"に変更する必要があります。 。
o If there is a Privacy header field in the "headers" component of a hi-targeted-to-uri with a priv-value of "history", then all the concerned hi-entries must be anonymized as described above prior to forwarding.
o priv-valueが「history」のhi-targeted-to-uriの「headers」コンポーネントにプライバシーヘッダーフィールドがある場合、転送の前に、関係するすべてのhi-entryを上記のように匿名化する必要があります。
The Privacy Service must remove the Privacy header field from the "headers" component of the hi-targeted-to-uris of the concerned hi-entries and the priv-value of "history" from the Privacy header field in the message header of the request prior to forwarding. If there are no remaining priv-values in the Privacy header field, the Privacy Service must remove the Privacy header field from the request.
プライバシーサービスは、関係するhi-entriesのhi-targeted-to-urisの「headers」コンポーネントからプライバシーヘッダーフィールドを削除し、メッセージヘッダーのプライバシーヘッダーフィールドから「history」のプライベート値を削除する必要があります。転送する前にリクエストします。プライバシーヘッダーフィールドにプライベート値が残っていない場合、プライバシーサービスはリクエストからプライバシーヘッダーフィールドを削除する必要があります。
For the Diversion header field:
Diversionヘッダーフィールドの場合：
o If there is a Privacy header field in the message header of a request with a priv-value of "header", then all the addresses in the Diversion header fields (associated with the domain for which the SIP intermediary is responsible) are anonymized by the Privacy Service by changing the address to the anonymous SIP URI "anonymous@anonymous.invalid" as recommended in Sections 4.1.1.2 and 4.1.1.3 of [RFC3323] prior to forwarding.
o priv-valueが「header」のリクエストのメッセージヘッダーにプライバシーヘッダーフィールドがある場合、Diversionヘッダーフィールドのすべてのアドレス（SIP仲介が担当するドメインに関連付けられている）は、転送前に[RFC3323]のセクション4.1.1.2および4.1.1.3で推奨されているように、アドレスを匿名のSIP URI "anonymous@anonymous.invalid"に変更することによるプライバシーサービス。
o For each Diversion header field or each entry in the Diversion header field, if there is a diversion-privacy parameter with a value set to "full", "uri", or "name", then the concerned Diversion header field address must be anonymized as described above prior to forwarding.
o DiversionヘッダーフィールドまたはDiversionヘッダーフィールドの各エントリについて、値が「full」、「uri」、または「name」に設定されたdiversion-privacyパラメーターがある場合、関係するDiversionヘッダーフィールドのアドレスを匿名化する必要があります。転送する前に上記のように。
In the concerned Diversion header field entries, the diversion-privacy parameter must be removed from the header.
関連するDiversionヘッダーフィールドエントリでは、ヘッダーからdiversion-privacyパラメータを削除する必要があります。
The privacy information interworking as described in Sections 5 and 6 must only be considered within a trusted domain that ensures correct application of the privacy requirements.
セクション5と6で説明されているプライバシー情報の相互作用は、プライバシー要件の正しい適用を保証する信頼できるドメイン内でのみ検討する必要があります。
The recommended interworking presented in this document should apply only for INVITE requests.
このドキュメントに記載されている推奨されるインターワーキングは、INVITE要求にのみ適用されます。
In 3xx responses:
3xx応答：
Both History-Info and Diversion header fields could be present in 3xx responses.
History-InfoおよびDiversionヘッダーフィールドの両方が3xx応答に存在する可能性があります。
When a proxy wants to interwork with a network supporting the other header field, it should apply the interworking between Diversion header field and History-Info header field in the 3xx response.
プロキシが他のヘッダーフィールドをサポートするネットワークと相互作用する場合、3xx応答のDiversionヘッダーフィールドと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 field or a History-Info header field (according to its capabilities) in the forwarded INVITE. Local policies could apply regarding whether or not to send the received header field in the next INVITE.
再帰プロキシが3xx応答の受信後に最初のINVITEをリダイレクトする場合、転送されたINVITEのDiversionヘッダーフィールドまたはHistory-Infoヘッダーフィールド（その機能に応じて）を最後のエントリとして追加する必要があります。受信したヘッダーフィールドを次のINVITEで送信するかどうかに関して、ローカルポリシーを適用できます。
In SIP responses other than 100:
100以外のSIP応答の場合：
All SIP responses where the History-Info header field could be present are not used for the call forwarding service and should not be changed into the Diversion header field. The destination network must be transparent to the received History-Info header field.
History-Infoヘッダーフィールドが存在する可能性のあるすべてのSIP応答は、コール転送サービスには使用されないため、Diversionヘッダーフィールドに変更しないでください。宛先ネットワークは、受信したHistory-Infoヘッダーフィールドに対して透過的である必要があります。
Note: The following mapping is inspired by the ISDN User Part (ISUP) to SIP interworking described in [TS_29.163].
注：次のマッピングは、[TS_29.163]で説明されているISDNユーザーパート（ISUP）からSIPインターワーキングへのインスピレーションを受けています。
3.4. SIP Network/Terminal Using Diversion Header Field to SIP Network/ Terminal Using History-Info Header Field
3.4. 履歴情報ヘッダーフィールドを使用するSIPネットワーク/ターミナルへの宛先変更ヘッダーフィールドを使用するSIPネットワーク/ターミナル
When the Diversion header field is used to create a History-Info header field, the Diversion header field must be removed in the outgoing INVITE. It is assumed that all the information present in the Diversion header field is transferred in the History-Info header field.
Diversionヘッダーフィールドを使用してHistory-Infoヘッダーフィールドを作成する場合、Diversionヘッダーフィールドを発信INVITEから削除する必要があります。 Diversionヘッダーフィールドに存在するすべての情報がHistory-Infoヘッダーフィールドで転送されることを前提としています。
If a History-Info header field is also present in the incoming INVITE (in addition to the Diversion header field), the Diversion header field and History-Info header field present must be mixed, and only the diversion information not yet present in the History-Info header field must be inserted as a last entry (most recent) in the existing History-Info header field, following the creation process recommended in [RFC7044].
History-Infoヘッダーフィールドが着信INVITEにも（Diversionヘッダーフィールドに加えて）存在する場合、DiversionヘッダーフィールドとHistory-Infoヘッダーフィールドが混在している必要があり、履歴にはまだ転送情報が存在しない-Infoヘッダーフィールドは、[RFC7044]で推奨されている作成プロセスに従って、既存のHistory-Infoヘッダーフィールドの最後のエントリ（最新）として挿入する必要があります。
As an example, this could be the case of an INVITE coming from network_2 using the Diversion header field but previously passed through network_1 using the History-Info header field (or the network_2 uses History-Info header field to transport successive URI information) and going to network_3 using the History-Info header field.
例として、これはDiversionヘッダーフィールドを使用してnetwork_2から来たが、History-Infoヘッダーフィールドを使用してnetwork_1を通過した（またはnetwork_2がHistory-Infoヘッダーフィールドを使用して連続するURI情報を転送する）INVITEの場合が考えられます。 History-Infoヘッダーフィールドを使用してnetwork_3に送信します。
IWF* IWF*
network_1 | network_2 |network_3
History-Info | Diversion |using
| |History-
| |Info
UA A P1 AS B | P2 AS C UA C AS D | UA E
| | | | | | | | | |
|INVITE | | | | | | | | |
|------>| | | | | | | | |
| | | | | | | | | |
| |INVITE | | | | | | | |
| |------>| | | | | | | |
| |Supported: histinfo | | | | | |
| | History-Info: | | | | | |
| | <sip:proxyP1>;index=1,| | | | | |
| | <sip:userB>;index=1.1;rc=1 | | | | |
| | | | | | | | | |
| | |INVITE | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | |<sip:proxyP1>;index=1, | | | | |
| | |<sip:userB>;index=1.1;rc=1, | | | |
| | |<sip:userC;cause=302>;index=1.1.1;mp=1.1 | |
In this case, the incoming INVITE contains a Diversion header field and a History-Info header field. Therefore, as recommended in this document, it is necessary to create, for network_3, a single History-Info header field gathering existing information from both the History-Info and the Diversion header fields received. Anyway, it is required that network_2 (i.e., IWF) remove the Diversion header field when the message is going to a network not using the Diversion header field. Then, network_3 could use call forwarding information that is present in a single header field and add its own diversion information if necessary.
この場合、着信INVITEには、DiversionヘッダーフィールドとHistory-Infoヘッダーフィールドが含まれます。したがって、このドキュメントで推奨されているように、network_3に対して、受信したHistory-InfoヘッダーフィールドとDiversionヘッダーフィールドの両方から既存の情報を収集する単一のHistory-Infoヘッダーフィールドを作成する必要があります。いずれにしても、メッセージがDiversionヘッダーフィールドを使用していないネットワークに送信される場合は、network_2（IWFなど）がDiversionヘッダーフィールドを削除する必要があります。次に、network_3は、単一のヘッダーフィールドにあるコール転送情報を使用し、必要に応じて独自の転送情報を追加できます。
Notes:
ノート：
1. If a network is not able either to use only one header field each time or to maintain both header fields up to date, the chronological order cannot be certified.
1. ネットワークが毎回1つのヘッダーフィールドのみを使用することも、両方のヘッダーフィールドを最新の状態に維持することもできない場合、時系列の順序は保証されません。
2. It is not possible to have only a Diversion header field when the History-Info header field contains more than call diversion information. If previous policy recommendations are applied, the chronological order is respected as Diversion entries are inserted at the end of the History-Info header field taking into account the Diversion internal chronology.
2. History-Infoヘッダーフィールドに通話転送情報以外の情報が含まれている場合は、Diversionヘッダーフィールドのみを持つことはできません。以前のポリシーの推奨事項が適用されている場合は、Diversionの内部年表を考慮に入れて、History-Infoヘッダーフィールドの最後にDiversionエントリが挿入されるため、日付順が順守されます。
3.5. SIP Network/Terminal Using History-Info Header Field to SIP Network/Terminal Using Diversion Header Field
3.5. History-Infoヘッダーフィールドを使用したSIPネットワーク/ターミナルからDiversionヘッダーフィールドを使用したSIPネットワーク/ターミナルへ
When the History-Info header field is interpreted to create a Diversion header field, some precautions must be taken.
History-InfoヘッダーフィールドがDiversionヘッダーフィールドを作成するために解釈される場合、いくつかの予防策を講じる必要があります。
If the History-Info header field contains only call forwarding information, then it must be deleted after the interworking.
History-Infoヘッダーフィールドに着信転送情報のみが含まれている場合、インターワーキング後に削除する必要があります。
If the History-Info header field contains other information, then only the information of concern to the diverting user must be used to create entries in the Diversion header field, and the History-Info header field must be kept as received in the INVITE and forwarded downstream.
History-Infoヘッダーフィールドに他の情報が含まれている場合は、転送ユーザーに関係する情報のみを使用してDiversionヘッダーフィールドにエントリを作成し、History-InfoヘッダーフィールドをINVITEで受信したまま転送して転送する必要があります。下流。
Note: The History-Info header field could be used for reasons other than call diversion services, for example, by a service that needs to know if a specific AS has yet been invoked in the signaling path. If the call is later forwarded to a network using the History-Info header field, it would be better not to lose history information due to passing though the network that only supports the Diversion header field. A recommended solution must not disrupt the standard behavior, and networks that do not implement the History-Info header field must be transparent to a received History-Info header field.
注：History-Infoヘッダーフィールドは、コール転送サービス以外の理由で使用できます。たとえば、特定のASがまだシグナリングパスで呼び出されているかどうかを知る必要のあるサービスがこれに該当します。コールが後でHistory-Infoヘッダーフィールドを使用してネットワークに転送される場合、Diversionヘッダーフィールドのみをサポートするネットワークを通過するため、履歴情報を失わない方が良いでしょう。推奨されるソリューションは、標準の動作を妨げてはならず、History-Infoヘッダーフィールドを実装しないネットワークは、受信したHistory-Infoヘッダーフィールドに対して透過的でなければなりません。
If a Diversion header field is present in the incoming INVITE (in addition to the History-Info header field), only diversion information present in the History-Info header field but not in the Diversion header field must be inserted from the last entry (most recent) into the existing Diversion header field as recommended in [RFC5806].
着信INVITEに（History-Infoヘッダーフィールドに加えて）Diversionヘッダーフィールドが存在する場合、History-Infoヘッダーフィールドに存在し、Diversionヘッダーフィールドに存在しない転換情報のみを最後のエントリから挿入する必要があります（ほとんど最近）[RFC5806]で推奨されている既存のDiversionヘッダーフィールドに。
Note that the chronological order could not be certified. If previous policy recommendations are respected, this case should not happen.
年代順は認定できなかったことに注意してください。以前のポリシーの推奨事項が順守されている場合、このケースは発生しないはずです。
Forking case:
フォークケース：
The History-Info header field enables the recording of sequential forking for the same served user. During an interworking from the History-Info header field to the Diversion header field, the History-Info entries containing a forking situation (with an incremented "index" parameter) could possibly be mapped if they contain a call forwarding "cause" parameter. The interworking entity could choose to create only a Diversion entry or not apply the interworking. The choice could be done according a local policy.
History-Infoヘッダーフィールドを使用すると、同じサービスを提供するユーザーの順次フォークを記録できます。 History-InfoヘッダーフィールドからDiversionヘッダーフィールドへのインターワーキング中に、フォーキング状況を含むHistory-Infoエントリ（インクリメントされた「インデックス」パラメータを含む）が、コール転送「原因」パラメータを含む場合、マップされる可能性があります。インターワーキングエンティティは、宛先変更エントリのみを作成するか、インターワーキングを適用しないかを選択できます。選択は、ローカルポリシーに従って行うことができます。
The same logic is applied for an interworking with Voicemail URI (see Appendix A).
ボイスメールURIとのインターワーキングにも同じロジックが適用されます（付録Aを参照）。
The ABNF syntax [RFC5234] for the History-Info header field and header field parameters is as follows.
History-InfoヘッダーフィールドとヘッダーフィールドパラメーターのABNF構文[RFC5234]は次のとおりです。
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
hi-entry = hi-targeted-to-uri *(SEMI hi-param)
hi-targeted-to-uri = name-addr
hi-param = hi-index/hi-target-param/hi-extension
hi-index = "index" EQUAL index-val
index-val = number *("." number)
number = [ %x31-39 *DIGIT ] DIGIT
hi-target-param = rc-param / mp-param / np-param
rc-param = "rc" EQUAL index-val
mp-param = "mp" EQUAL index-val
np-param = "np" EQUAL index-val
hi-extension = generic-param
The ABNF definitions for "generic-param", "name-addr", "HCOLON", "COMMA", "SEMI", and "EQUAL" are from [RFC3261].
「generic-param」、「name-addr」、「HCOLON」、「COMMA」、「SEMI」、および「EQUAL」のABNF定義は、[RFC3261]からのものです。
The History-Info header field is specified in [RFC7044]. The top-most History-Info entry (first in the list) corresponds to the oldest history information.
History-Infoヘッダーフィールドは、[RFC7044]で指定されています。一番上のHistory-Infoエントリ（リストの最初）は、最も古い履歴情報に対応しています。
Cause URI parameter:
かうせ うり ぱらめてｒ：
A hi-entry may contain a cause URI parameter expressing the diversion reason. This cause URI parameter is defined in [RFC4458]. The ABNF grammar [RFC5234] for the cause-param parameter is shown below as it has been subject to Erratum ID 1409 [Err1409] for [RFC4458]. The Status-Code is defined in [RFC3261].
hi-entryには、宛先変更の理由を表す原因URIパラメータを含めることができます。この原因URIパラメータは[RFC4458]で定義されています。 cause-paramパラメータのABNF文法[RFC5234]は、[RFC4458]のエラータID 1409 [Err1409]の対象となっているため、以下に示します。ステータスコードは[RFC3261]で定義されています。
cause-param = "cause=" Status-Code
cause-param = "cause ="ステータスコード
The cause-param parameter is a SIP/SIPS URI parameter and should be inserted in the History-Info entry (URI) of the diverted-to user in case of call diversion as recommended in the 3GPP CDIV specification [TS_24.604]. The cause values used in the cause-param for the diverting reason are listed in [RFC4458]. Because it is a parameter dedicated to call forwarding service, its presence is used to determine that a hi-entry is a diverting user. More precisely, each diverting user is located in the hi-entry before the one containing a cause-param with cause value as listed in [RFC4458].
cause-paramパラメータはSIP / SIPS URIパラメータであり、3GPP CDIV仕様[TS_24.604]で推奨されているように、コール転送の場合に転送先ユーザーのHistory-Infoエントリ（URI）に挿入する必要があります。迂回理由のcause-paramで使用される原因値は、[RFC4458]にリストされています。着信転送サービス専用のパラメータであるため、その存在は、ハイエントリが転送先のユーザーであることを確認するために使用されます。より正確には、各迂回ユーザーは、[RFC4458]にリストされている原因値を持つcause-paramを含むユーザーの前のhi-entryにあります。
Reason header field:
理由ヘッダーフィールド：
The Reason header field defined in [RFC3326] should be escaped in the hi-entry of the diverting user when the call diversion is due to a received SIP response. The Reason header field contains a cause parameter set to the true SIP response code received (Status-Code).
[RFC3326]で定義されているReasonヘッダーフィールドは、着信転送が受信したSIP応答によるものである場合、転送元ユーザーのhi-entryでエスケープする必要があります。 Reasonヘッダーフィールドには、受信した実際のSIP応答コード（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 field but not in the same hi-entry and not with the same meaning. Only the cause-param is dedicated to call diversion service. The 'cause' Reason header field parameter is not taken into account in the mapping with a Diversion header field.
したがって、SIP応答による着信転送の場合は、両方の原因パラメータを使用する必要があります。複雑なのは、これらのパラメーターをHistory-Infoヘッダーフィールドで同時に使用できることですが、同じhi-entryでは使用できず、同じ意味でもありません。 cause-paramのみが宛先変更サービスの呼び出し専用です。 「原因」Reasonヘッダーフィールドパラメータは、Diversionヘッダーフィールドとのマッピングでは考慮されません。
Target URI parameter:
ターゲットURIパラメータ：
[RFC4458] also defines the 'target' URI parameter, which could be inserted in a Request-URI and consequently in the hi-targeted-to-uri. This parameter is used to keep the diverting user address in the downstream INVITE request in Voicemail URI implementation. As this information is already present in the hi-entries, the 'target' URI parameter is not taken into account regarding the interworking with the Diversion header field. From the Diversion header field, it could be possible to create the
[RFC4458]は「ターゲット」URIパラメータも定義します。これはRequest-URIに挿入でき、その結果hi-targeted-to-uriに挿入できます。このパラメーターは、ボイスメールURI実装のダウンストリームINVITE要求で転送ユーザーアドレスを維持するために使用されます。この情報はすでにhi-entriesに存在するため、「target」URIパラメーターは、Diversionヘッダーフィールドとのインターワーキングに関して考慮されません。 Diversionヘッダーフィールドから、
'target' URI parameter in the hi-entries and/or in the Request-URI, but this possibility is based on local policies not described in this document.
hi-entriesおよび/またはRequest-URIの「target」URIパラメーター。ただし、この可能性は、このドキュメントで説明されていないローカルポリシーに基づいています。
Privacy header field:
プライバシーヘッダーフィールド：
A Privacy header field as defined in [RFC3323] could also be embedded in hi-entries with the 'history' value defined in [RFC7044].
[RFC3323]で定義されているプライバシーヘッダーフィールドは、[RFC7044]で定義されている「履歴」値を使用してhi-entriesに埋め込むこともできます。
Index header field parameter:
インデックスヘッダーフィールドパラメータ：
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」パラメーターに関するルールを適用する必要があるかどうかに関係なく、このパラメーターはマッピングに影響を与えず、提供されたユーザーアドレスでのみコピーする必要があります。
Missing entry:
エントリがありません：
If the request clearly has a gap in the hi-entry (i.e., the last hi-entry and Request-URI differ), the entity adding a hi-entry must add a single index with a value of "0" (i.e., the non-negative integer zero) prior to adding the appropriate index for the action to be taken (e.g., Index=1.1.2.0.1). Prior to any application usage of the History-Info header field parameters, the SIP entity that processes the hi-entries must evaluate the hi-entries and determine if there are any gaps in them.
リクエストに明らかにhi-entryにギャップがある場合（つまり、最後のhi-entryとRequest-URIが異なる場合）、hi-entryを追加するエンティティは、値が「0」の単一のインデックスを追加する必要があります（つまり、負でない整数ゼロ）を実行する前に、実行するアクションに適切なインデックスを追加します（たとえば、Index = 1.1.2.0.1）。アプリケーションがHistory-Infoヘッダーフィールドパラメータを使用する前に、hi-entriesを処理するSIPエンティティがhi-entriesを評価し、それらにギャップがあるかどうかを判断する必要があります。
"histinfo" option tag:
「histinfo」オプションタグ：
According to [RFC7044], a proxy that receives a Request with the "histinfo" option tag in the Supported header field should return captured History-Info in subsequent, provisional, and final responses to the Request. The behavior depends upon whether or not the local policy supports the capture of History-Info.
[RFC7044]によれば、Supportedヘッダーフィールドに「histinfo」オプションタグを含むリクエストを受信するプロキシは、リクエストに対する後続の、暫定的な、および最終的な応答で、キャプチャされたHistory-Infoを返す必要があります。動作は、ローカルポリシーがHistory-Infoのキャプチャをサポートしているかどうかによって異なります。
Example:
例：
History-Info:
<sip:diverting_user1_addr?Privacy=none&Reason=SIP%3Bcause%3D302>;
index=1,
<sip:diverting_user2_addr;cause=480?Privacy=history>;index=1.1;mp=1,
<sip:last_diversion_target;cause=486>;index=1.1.1;mp=1.1
The following text is restating the exact syntax that the production rules in [RFC5806] define, but using ABNF [RFC5234]:
次のテキストは、[RFC5806]のプロダクションルールが定義する正確な構文を再説明していますが、ABNF [RFC5234]を使用しています。
Diversion = "Diversion" HCOLON diversion-params
*(COMMA diversion-params)
diversion-params = name-addr *(SEMI (diversion-reason /
diversion-counter / diversion-limit /
diversion-privacy / diversion-screen /
diversion-extension))
diversion-reason = "reason" EQUAL ("unknown" / "user-busy" /
"no-answer" / "unavailable" / "unconditional"
/ "time-of-day" / "do-not-disturb" /
"deflection" / "follow-me" / "out-of-service"
/ "away" / token / quoted-string)
diversion-counter = "counter" EQUAL 1*2DIGIT
diversion-limit = "limit" EQUAL 1*2DIGIT
diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" /
"off" / token / quoted-string)
diversion-screen = "screen" EQUAL ("yes" / "no" / token /
quoted-string)
diversion-extension = token [EQUAL (token / quoted-string)]
Note: The Diversion header field could be used in the comma-separated format as described below and in a header-separated format. Both formats could be combined in a received INVITE as recommended in [RFC3261].
注：Diversionヘッダーフィールドは、以下で説明するようにカンマ区切り形式とヘッダー区切り形式で使用できます。 [RFC3261]で推奨されているように、受信したINVITEで両方の形式を組み合わせることができます。
Example:
例：
Diversion:
<sip:diverting_user2_addr>;reason=user-busy;counter=1;privacy=full,
<sip:diverting_user1_addr>;reason=unconditional;counter=1;privacy=off
The following text is valid only if no History-Info header field is present in the INVITE request. If at least one History-Info header field is present, the interworking function must adapt its behavior to respect the chronological order. For more information, see Section 3.
次のテキストは、INVITEリクエストにHistory-Infoヘッダーフィールドが存在しない場合にのみ有効です。少なくとも1つのHistory-Infoヘッダーフィールドが存在する場合、インターワーキング機能は、時系列順に動作を適応させる必要があります。詳細については、セクション3を参照してください。
Concerning the privacy information in the Diversion header field, the following mapping only applies within a trusted domain; for other domains, see the privacy considerations in Section 3.2.
Diversionヘッダーフィールドのプライバシー情報に関して、次のマッピングは信頼できるドメイン内でのみ適用されます。他のドメインについては、セクション3.2のプライバシーに関する考慮事項を参照してください。
For N Diversion entries, N+1 History-Info entries must be created. To create the History-Info entries in the same order as during a session establishment, the Diversion entries must be mapped from the bottom-most to the top-most. Each Diversion entry shall be mapped into a History-Info entry. An additional History-Info entry (the last one) must be created with the diverted-to party address present in the Request-URI of the received INVITE. The mapping is described in the table below.
N Diversionエントリの場合、N + 1 History-Infoエントリを作成する必要があります。セッションの確立時と同じ順序でHistory-Infoエントリを作成するには、Diversionエントリを一番下から一番上にマッピングする必要があります。各迂回エントリは、History-Infoエントリにマップされます。追加のHistory-Infoエントリ（最後のエントリ）は、受信したINVITEのRequest-URIに存在する転送先アドレスで作成する必要があります。マッピングについては、以下の表で説明しています。
The first entry created in the History-Info header field contains:
History-Infoヘッダーフィールドに作成される最初のエントリには、次のものが含まれます。
o a hi-targeted-to-uri with the name-addr parameter of the bottom-most Diversion header field.
o 最下部のDiversionヘッダーフィールドのname-addrパラメーターを持つhi-targeted-to-uri
o if a privacy parameter is present in the bottom-most Diversion entry, then a Privacy header field must be escaped in the History-Info header field as described in the table below.
o プライバシーパラメータが最下部のDiversionエントリに存在する場合、プライバシーヘッダーフィールドは、以下の表で説明するようにHistory-Infoヘッダーフィールドでエスケープする必要があります。
o a hi-index set to 1.
o hi-indexが1に設定されています。
For each of the following Diversion entries (from bottom to top), the History-Info entries are created as follows (from top to bottom):
次の各転換エントリ（下から上）に対して、History-Infoエントリは次のように（上から下に）作成されます。
Source Destination
Diversion header component: History-Info header component:
=======================================================================
name-addr hi-targeted-to-uri
=======================================================================
reason of the previous cause URI parameter
Diversion entry A cause-param "cause" is
added in each hi-entry
(except the first one)
"unknown"----------------------------------404 (default 'cause' value)
"unconditional"----------------------------302
"user-busy"--------------------------------486
"no-answer"--------------------------------408
"deflection "------------------------------480 or 487
"unavailable"------------------------------503
"time-of-day"------------------------------404 (default)
"do-not-disturb"---------------------------404 (default)
"follow-me"--------------------------------404 (default)
"out-of-service"---------------------------404 (default)
"away"-------------------------------------404 (default)
======================================================================
counter hi-index
"1" or parameter ------------------------The previous created index
not present is extended with ".1"
Superior to "1" -------------------------Create N-1 placeholder History
(i.e., N) entry with the previous index
extended with ".1"
Then the History-Info header
created with the Diversion
entry with the previous index
extended with ".1"
======================================================================
privacy Privacy header escaped in the
hi-targeted-to-uri
"full"-----------------------------------"history"
"Off"------------------------------------Privacy header field
absent or "none"
"name"-----------------------------------"history"
"uri"------------------------------------"history"
======================================================================
hi-target-param
An mp-param "mp" is added in
each created hi-entry
(except the first one)
The "mp" parameter is set to
the index value of the
preceding hi-entry.
=======================================================================
A last History-Info entry is created and contains:
最後のHistory-Infoエントリが作成され、以下が含まれます。
o a hi-targeted-to-uri with the Request-URI of the INVITE request.
o INVITEリクエストのRequest-URIを持つhi-targeted-to-uri
o a cause-param from the top-most Diversion entry, mapped from the diversion-reason as described above.
o 上記のdiversion-reasonからマッピングされた、最上位のDiversionエントリのcause-param。
o an index set to the previous created index extended with a new level ".1" added at the end.
o 最後に追加された新しいレベル「.1」で拡張された、以前に作成されたインデックスに設定されたインデックス。
o a hi-target-param set to "mp" equals to the index value of the previous hi-entry.
o 「mp」に設定されたhi-target-paramは、前のhi-entryのインデックス値と同じです。
Notes:
ノート：
1. For other optional Diversion parameters, there is no recommendation as the History-Info header field does not provide equivalent parameters.
1. その他のオプションのDiversionパラメータについては、History-Infoヘッダーフィールドに同等のパラメータがないため、推奨事項はありません。
2. For values of the diversion-reason that are mapped with a recommended default value, it could also be possible to choose another value. The cause-param URI parameter offers fewer possible values than the diversion-reason parameter. However, it has been considered that the cause-param values list was sufficient to implement CDIV service as defined in 3GPP [TS_24.604] as it covers a large portion of cases.
2. 推奨されるデフォルト値でマッピングされている迂回理由の値の場合、別の値を選択することも可能です。 cause-param URIパラメータは、diversion-reasonパラメータよりも少ない値を提供します。ただし、3GPP [TS_24.604]で定義されているCDIVサービスの実装には、ケースの大部分をカバーしているため、cause-param値リストで十分であると考えられていました。
3. The Diversion header field can contain a "tel" URI as defined in [RFC3966] in the name-addr parameter. The History-Info header field can also contain an address that is a "tel" URI, but if this hi-entry has to be completed with either a SIP header field (e.g., Reason or Privacy) or a SIP URI parameter (e.g., 'cause' or 'target'), the "tel" URI must be converted into a SIP URI. [RFC3261] gives an indication as to the mapping between sip: and tel: URIs, but in this particular case, it is difficult to assign a valid hostport as the diversion occurred in a previous network and a valid hostport is difficult to determine. So, it is suggested that in case of "tel" URI in the Diversion header field, the History-Info header field should be created with a SIP URI with user=phone and a domain set to "unknown.invalid".
3. Diversionヘッダーフィールドには、name-addrパラメータの[RFC3966]で定義されている「tel」URIを含めることができます。 History-Infoヘッダーフィールドには、「tel」URIであるアドレスを含めることもできますが、このhi-entryをSIPヘッダーフィールド（例：ReasonまたはPrivacy）またはSIP URIパラメーター（例： 「原因」または「ターゲット」）、「tel」URIはSIP URIに変換する必要があります。 [RFC3261]はsip：とtel：URI間のマッピングを示しますが、この特定のケースでは、以前のネットワークで宛先変更が発生し、有効なホストポートを判別することが困難であるため、有効なホストポートを割り当てることは困難です。したがって、Diversionヘッダーフィールドに「tel」URIがある場合、History-Infoヘッダーフィールドは、user = phoneおよび「unknown.invalid」に設定されたドメインを含むSIP URIで作成することをお勧めします。
4. The Diversion header field allows carrying of a counter that retains the information about the number of successive redirections. History-Info does not have an equivalent because to trace and count the number of diversions, it is necessary to count the cause parameter containing a value associated to a call diversion listed in [RFC4458]. Reading the index value is not enough. With the use of the "placeholder" entry the History-Info header field, entries can reflect the real number of diversions that occurred, thanks to the cause-param.
4. Diversionヘッダーフィールドを使用すると、連続するリダイレクトの数に関する情報を保持するカウンターを保持できます。宛先変更の数を追跡してカウントするには、[RFC4458]にリストされているコール宛先変更に関連付けられた値を含む原因パラメータをカウントする必要があるため、History-Infoには同等のものはありません。インデックス値を読み取るだけでは不十分です。 「プレースホルダー」エントリーのHistory-Infoヘッダーフィールドを使用すると、cause-paramのおかげで、エントリーは発生した転換の実際の数を反映できます。
Example of placeholder entry in the History-Info header field:
History-Infoヘッダーフィールドのプレースホルダーエントリの例：
<sip:unknown@unknown.invalid;cause=xxx>;index=1.1
<sip:bob_addr;cause=404>;index=1.1.1;mp=1.1
"cause=xxx" reflects the diverting reason of a previous diverting user. For a placeholder hi-entry, the value "404" must be taken for the cause-param and so, located in the next hi-entry.
「cause = xxx」は、以前の転送ユーザーの転送理由を反映しています。プレースホルダーのhi-entryの場合、次のhi-entryにあるcause-paramなどに値「404」を使用する必要があります。
For recommendations for local policies regarding the coexistence of header fields in the INVITE request, see Sections 3 and 7.4.
INVITEリクエストのヘッダーフィールドの共存に関するローカルポリシーの推奨事項については、セクション3および7.4を参照してください。
Concerning the privacy information for the History-Info header field, the following mapping only applies within a trusted domain; for other domains, see the privacy considerations in Section 3.2.
History-Infoヘッダーフィールドのプライバシー情報に関して、次のマッピングは信頼されるドメイン内でのみ適用されます。他のドメインについては、セクション3.2のプライバシーに関する考慮事項を参照してください。
To create the Diversion entries in the same order as during a session establishment, the History-Info entries must be mapped from the top-most to the bottom-most. The first History-Info header field entry selected will be mapped into the last Diversion header field entry and so on. One Diversion header field entry must be created for each History-Info entry that has cause-param with a value listed in [RFC4458].
セッション確立時と同じ順序で転換エントリを作成するには、History-Infoエントリを一番上から一番下にマッピングする必要があります。選択された最初のHistory-Infoヘッダーフィールドエントリは、最後のDiversionヘッダーフィールドエントリにマッピングされます。 [RFC4458]にリストされている値を持つcause-paramを持つHistory-Infoエントリごとに、1つのDiversionヘッダーフィールドエントリを作成する必要があります。
Diversion information:
転送情報：
The definitions of "Target_entry" and "Diverting_entry" are included below to help readers understand the mapping of the History-Info header field.
「Target_entry」と「Diverting_entry」の定義は、読者がHistory-Infoヘッダーフィールドのマッピングを理解するのに役立つように以下に含まれています。
The diversion information can be identified by finding the following hi-entries:
転送情報は、次のhi-entriesを見つけることで識別できます。
o Target_entry: hi-entries containing a cause-param URI parameter with a value listed in [RFC4458] will contain the diversion reason and the address of the target of the concerned call forwarding. Per [RFC7044], these hi-entries may also contain a hi-target-param set to "mp".
o Target_entry：[RFC4458]にリストされている値を持つcause-param URIパラメータを含むhi-entriesには、転送の理由と、関連するコール転送のターゲットのアドレスが含まれます。 [RFC7044]によると、これらのhi-entriesには、「mp」に設定されたhi-target-paramも含まれる場合があります。
o Diverting_entry: For each previously identified hi-entry:
o Diverting_entry：以前に識別された各hi-entryについて：
* If there is an "mp" header field parameter, the hi-entry whose hi-index matches the value of the hi-target-param "mp" will contain the diverting party address, its possible privacy, and/ or SIP reason when the retargeting has been caused by a received SIP response.
* "mp"ヘッダーフィールドパラメータがある場合、hi-indexがhi-target-param "mp"の値と一致するhi-entryには、転送先アドレス、そのプライバシー、および/またはSIPの理由が含まれます。再ターゲットは、受信したSIP応答によって引き起こされました。
* If there is no "mp" header field parameter, the information of the diverting party address, privacy and/or SIP reason will be found in the hi-entry that precede this identified hi-entry.
* 「mp」ヘッダーフィールドパラメータがない場合、転送先アドレス、プライバシー、SIPの理由の情報は、この識別されたhi-entryに先行するhi-entryにあります。
Note: Per [RFC7044], all retargeting entries must point to a hi-entry that contains an "mp" parameter, but for backward-compatibility reasons, it may be absent from some of the received hi-entries. See Section 8 for more information on backward compatibility.
注：[RFC7044]に従い、すべてのリターゲティングエントリは「mp」パラメータを含むhi-entryをポイントする必要がありますが、下位互換性の理由から、受信したhi-entryの一部に存在しない場合があります。下位互換性の詳細については、セクション8を参照してください。
The History-Info header field must be mapped into the Diversion
header field as follows:
Source Destination
History-Info header component: Diversion header component:
=====================================================================
hi-targeted-to-uri name-addr
of the Diverting_entry.
=====================================================================
cause-param reason
of the Target_entry
404---------------------------------------"unknown" (default value)
302---------------------------------------"unconditional"
486---------------------------------------"user-busy"
408---------------------------------------"no-answer"
480 or 487--------------------------------"deflection "
503---------------------------------------"unavailable"
=====================================================================
hi-index counter
Mandatory parameter for-------------------The counter is set to "1".
History-Info reflecting
the chronological order
of the information.
=====================================================================
Privacy header field escaped privacy
in the hi-targeted-to-uri
of the Diverting_entry
"history"----------------------------------"full"
Privacy header field ----------------------"Off"
Absent or "none"
=====================================================================
Note: For other optional History-Info parameters, there is no recommendation as the Diversion header field does not provide equivalent parameters.
注：その他のオプションのHistory-Infoパラメーターについては、Diversionヘッダーフィールドに同等のパラメーターがないため、推奨事項はありません。
For recommendations for local policies regarding the coexistence of header fields in the INVITE request, see Section 3.
INVITEリクエストのヘッダーフィールドの共存に関するローカルポリシーの推奨事項については、セクション3を参照してください。
7.1. Example with Diversion Header Field Changed into History-Info Header Field
7.1. DiversionヘッダーフィールドがHistory-Infoヘッダーフィールドに変更された例
INVITE sip:last_diverting_target
Diversion:
<sip:diverting_user3_address>;reason=unconditional;counter=1;
privacy=off,
<sip:diverting_user2_address>;reason=user-busy;counter=1;
privacy=full,
<sip:diverting_user1_address>;reason=no-answer;counter=1;
privacy=off
Mapped into:
マップ先：
History-Info:
<sip:diverting_user1_address?Privacy=none>;index=1,
<sip:diverting_user2_address;
cause=408?Privacy=history>;index=1.1;mp=1,
<sip:diverting_user3_address;
cause=486?Privacy=none>;index=1.1.1;mp=1.1,
<sip:last_diverting_target;cause=302>;index=1.1.1.1;mp=1.1.1
7.2. Example with History-Info Header Field Changed into Diversion Header Field
7.2. History-InfoヘッダーフィールドがDiversionヘッダーフィールドに変更された例
INVITE sip:last_diverting_target; cause=486
History-Info:
<sip:diverting_user1_address?Privacy=history>;index=1,
<sip:diverting_user2_address;cause=302?Privacy=none>;index=1.1;mp=1,
<sip:last_diverting_target;cause=486>;index=1.1.1;mp=1.1
Mapped into:
マップ先：
Diversion:
<sip:diverting_user2_address>;reason=user-busy;counter=1;privacy=off,
<sip:diverting_user1_address>;reason=unconditional;counter=1;privacy=
full
7.3. Example with Two SIP Networks Using History-Info Header Field Interworking with a SIP Network Using Diversion Header Field
7.3. History-Infoヘッダーフィールドを使用した2つのSIPネットワークと、Diversionヘッダーフィールドを使用したSIPネットワークとのインターワーキングの例
A -> P1 -> B -> C -> P2 -> D-> E A, B, C, D and E are users. B, C and D have call forwarding service invoked. P1 and P2 are proxies. Only relevant information is shown on the following call flow.
A-> P1-> B-> C-> P2-> D-> E A、B、C、D、Eはユーザーです。 B、C、およびDには、コール転送サービスが呼び出されています。 P1とP2はプロキシです。次のコールフローには、関連情報のみが表示されています。
IWF* IWF*
SIP network using | SIP network using |SIP net.
History-Info | Diversion |using
| History-Info
| |
UA A P1 AS B | P2 AS C UA C AS D | UA E
| | | | | | | | | |
|INV B | | | | | | | | |
|------>| | | | | | | | |
| | | | | | | | | |
| |INV B | | | | | | | |
| |------>| | | | | | | |
| |Supported: histinfo | | | | | |
| | History-Info: | | | | | |
| | <sip:proxyP1>;index=1, | | | | |
| | <sip:userB>;index=1.1;rc=1 | | | | |
| | | | | | | | | |
| | |INV C | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | <sip:proxyP1>;index=1, | | | | |
| | <sip:userB>;index=1.1;rc=1, | | | |
| | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 | |
| | | | | | | | | |
| | | |INV C | | | | | |
| | | |----->| | | | | |
| | | Diversion: | | | | | |
| | <sip:userB>;reason=unconditional;counter=1;privacy=off|
| | | |History-Info: | | | | |
| | | <sip:proxyP1>;index=1, | | | |
| | | <sip:userB>;index=1.1;rc=1, | | |
| | | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 |
| | | | | | | | | |
| | | | |INV C | | | | |
| | | | |------>| | | | |
| | | | No modification of Diversion header |
| | | | | | | | | |
| | | | | |INV C | | | |
| | | | | |------>| | | |
| | | | | | | | | |
| | | | | |<--180-| | | |
| | | | | | | | | |
| | | | | No response timer expires | |
| | | | | |---INV D --->| | |
| | |Diversion: | | |
| | <sip:userC>;reason=no-answer;counter=1;privacy=full, |
| | <sip:userB>;reason=unconditional;counter=1;privacy=off|
| | | History-Info: | | |
| | | <sip:proxyP1>;index=1, | | |
| | | <sip:userB>;index=1.1;rc=1, | | |
| | | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 |
| | | | | | | | | |
| | | | | | | |INV E | |
| | | | | | | |----->| |
| | |Diversion: | |
| | <sip:userD>;reason=time-of-day;counter=1;privacy=off, |
| | <sip:userC>;reason=no-answer;counter=1;privacy=full, |
| | <sip:userB>;reason=unconditional;counter=1;privacy=off|
| | | History-Info: | |
| | | <sip:proxyP1>;index=1, | |
| | | <sip:userB>;index=1.1;rc=1, | |
| | | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1 |
| | | | | | | | | |
| | | | | | | | | INV E |
| | | | | | | | |------>|
| | History-Info: | | | | | |
| | <sip:proxyP1>;index=1, | | | | |
| | <sip:userB>;index=1.1;rc=1, | | | |
| | <sip:proxyP2;cause=302>;index=1.1.1;mp=1.1, | |
| | <sip:userC ?Privacy=history>;index=1.1.1.0.1, | |
|<sip:userD;cause=408?Privacy=none>;index=1.1.1.0.1.1;mp=1.1.1.0.1, |
| |<sip:userE;cause=404>;index=1.1.1.0.1.1.1;mp=1.1.1.0.1.1 |
| | | | | | | | | |
| | | | | | | | | |
Note: The IWF is an interworking function that could be a stand-alone equipment not defined in this document (it could be a proxy).
注：IWFは、このドキュメントで定義されていないスタンドアロンの機器の可能性があるインターワーキング機能です（プロキシの場合もあります）。
Even for particular cases in which both header fields could coexist, it should be the responsibility of the network local policy to make it work together. This section describes some situations and some recommendations on behavior.
両方のヘッダーフィールドが共存できる特定の場合でも、ネットワークフィールドを連携させるのはネットワークローカルポリシーの責任です。このセクションでは、いくつかの状況と動作に関するいくつかの推奨事項について説明します。
In the case where there is one network that includes different nodes, some of them supporting the Diversion header field and other ones supporting the History-Info header field, there is a problem when any node handling a message does not know the next node that will handle the message. This case can occur when the network has new and old nodes, the older ones using the Diversion header field and the most recent using the History-Info header field.
異なるノードを含む1つのネットワークがあり、そのうちのいくつかはDiversionヘッダーフィールドをサポートし、他のネットワークはHistory-Infoヘッダーフィールドをサポートしている場合、メッセージを処理するノードが次のノードを認識しないと問題が発生します。メッセージを処理します。このケースは、ネットワークに新しいノードと古いノードがあり、古いノードがDiversionヘッダーフィールドを使用し、最新のノードがHistory-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 the History-Info header field and the Diversion header field within the core network.
ネットワークの交換が行われている可能性がありますが、ネットワーク内で両方のノードが共存している場合があります。異なるノードの機能により、異なるノードが異なるサブスクライバータイプをサポートするために使用されている場合、問題はより重要です。この場合、History-InfoヘッダーフィールドとDiversionヘッダーフィールドの両方をコアネットワーク内で渡す必要があります。
These header fields need to be equivalent to ensure that, whatever the node receiving the message, the correct diversion information is received. This requires that, whatever the received header field, there is a requirement to be able to compare the header fields and to convert the header fields. Depending upon the node capability, it may be possible to make assumptions as to how this is handled.
これらのヘッダーフィールドは、メッセージを受信するノードが何であれ、正しい転送情報が受信されるようにするために、同等である必要があります。これには、受信したヘッダーフィールドが何であれ、ヘッダーフィールドを比較し、ヘッダーフィールドを変換できる必要があります。ノードの機能によっては、これがどのように処理されるかを想定できる場合があります。
o If it is known that the older Diversion header field supporting nodes does not pass on any received History-Info header field, then the interworking becomes easier. If a message is received with only Diversion header fields, then it has originated from an old node. The equivalent History-Info entries can be created, and these can then be passed as well as the Diversion header field.
o ノードをサポートする古いDiversionヘッダーフィールドが受信したHistory-Infoヘッダーフィールドを渡さないことがわかっている場合、インターワーキングが容易になります。 Diversionヘッダーフィールドのみを含むメッセージが受信された場合、そのメッセージは古いノードから発信されています。同等のHistory-Infoエントリを作成し、これらをDiversionヘッダーフィールドとともに渡すことができます。
o If the node creates a new History-Info header field for a call diversion, then an additional Diversion header field must be created.
o ノードがコール転送用に新しいHistory-Infoヘッダーフィールドを作成する場合、追加のDiversionヘッダーフィールドを作成する必要があります。
o If the next node is an old node, then the Diversion header field will be used by that node, and the History-Info entries will be removed from the message when it is passed on.
o 次のノードが古いノードである場合、そのノードはDiversionヘッダーフィールドを使用し、History-Infoエントリは、渡されたときにメッセージから削除されます。
o If the next node is a new node, then the presence of both the Diversion header field and History-Info header field means that interworking has already occurred and the Diversion and History-Info entries must be considered equivalent.
o 次のノードが新しいノードの場合、DiversionヘッダーフィールドとHistory-Infoヘッダーフィールドの両方が存在することは、インターワーキングがすでに発生していることを意味し、DiversionとHistory-Infoのエントリは同等と見なす必要があります。
o If both nodes pass on both the History-Info header field and Diversion header field but only actively use one, then both types of nodes need to perform the interworking and must maintain equivalence between the header fields. This will eventually result in the use of the Diversion header field being deprecated when all nodes in the network support the History-Info header field.
o 両方のノードがHistory-InfoヘッダーフィールドとDiversionヘッダーフィールドの両方を渡し、一方のみをアクティブに使用する場合、両方のタイプのノードがインターワーキングを実行する必要があり、ヘッダーフィールド間の同等性を維持する必要があります。これにより、ネットワーク内のすべてのノードがHistory-Infoヘッダーフィールドをサポートする場合、最終的にDiversionヘッダーフィールドの使用が廃止されます。
o If a gap is identified in the History-Info header field by a node that would create a new entry, it shall add a single index with a value of "0" prior to adding the appropriate index for the action to be taken.
o 新しいエントリを作成するノードによってHistory-Infoヘッダーフィールドでギャップが識別された場合、実行するアクションに適切なインデックスを追加する前に、値「0」の単一のインデックスを追加します。
Issues with backward compatibility are due to the evolution of the History-Info header field from [RFC4244] to [RFC7044], as described in Section 1.3 of this document. Backward compatibility is taken into account throughout this document for the interworking with the Diversion header field. More details are provided in the "Backwards Compatibility" section of [RFC7044].
このドキュメントのセクション1.3で説明されているように、下位互換性の問題は、History-Infoヘッダーフィールドが[RFC4244]から[RFC7044]に進化したためです。このドキュメントでは、Diversionヘッダーフィールドとの相互作用のために、下位互換性が考慮されています。詳細については、[RFC7044]の「下位互換性」セクションをご覧ください。
The security considerations in [RFC7044] and [RFC5806] apply.
[RFC7044]および[RFC5806]のセキュリティに関する考慮事項が適用されます。
The privacy considerations described in Section 3.2 apply.
セクション3.2で説明されているプライバシーに関する考慮事項が適用されます。
The use of the Diversion header field or History-Info header field requires application of the requested privacy and integrity requested by each diverting user or entity. Without integrity, the requested privacy functions could be downgraded or eliminated, potentially exposing identity information. Without confidentiality, eavesdroppers on the network (or any intermediaries between the user and the Privacy Service) could see the very personal information that the user has asked the Privacy Service to obscure. Unauthorized insertion and deletion/modification of those header fields can provide misleading information to users and applications. A SIP entity that can provide a redirection reason in a History-Info header field or Diversion header field should be able to suppress this in accordance with privacy requirements of the user concerned.
DiversionヘッダーフィールドまたはHistory-Infoヘッダーフィールドを使用するには、各転送ユーザーまたはエンティティが要求する、要求されたプライバシーと整合性を適用する必要があります。完全性がないと、要求されたプライバシー機能が格下げまたは排除され、ID情報が公開される可能性があります。機密性がなければ、ネットワーク上の盗聴者（またはユーザーとプライバシーサービスの間の仲介者）は、ユーザーがプライバシーサービスに隠蔽するように要求した非常に個人的な情報を見ることができます。これらのヘッダーフィールドの不正な挿入および削除/変更は、ユーザーおよびアプリケーションに誤解を招く情報を提供する可能性があります。 History-InfoヘッダーフィールドまたはDiversionヘッダーフィールドでリダイレクトの理由を提供できるSIPエンティティは、関係するユーザーのプライバシー要件に従ってこれを抑制できる必要があります。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <http://www.rfc-editor.org/info/rfc3323>.
[RFC3323] Peterson、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、DOI 10.17487 / RFC3323、2002年11月、<http://www.rfc-editor.org/info/rfc3323> 。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, <http://www.rfc-editor.org/info/rfc3326>.
[RFC3326] Schulzrinne、H.、Oran、D。、およびG. Camarillo、「セッション開始プロトコル（SIP）の理由ヘッダーフィールド」、RFC 3326、DOI 10.17487 / RFC3326、2002年12月、<http：// www .rfc-editor.org / info / rfc3326>。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.
[RFC3966] Schulzrinne、H。、「電話番号のtel URI」、RFC 3966、DOI 10.17487 / RFC3966、2004年12月、<http://www.rfc-editor.org/info/rfc3966>。
[RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, DOI 10.17487/RFC4244, November 2005, <http://www.rfc-editor.org/info/rfc4244>.
[RFC4244] Barnes、M。、編、「リクエスト履歴情報のセッション開始プロトコル（SIP）の拡張」、RFC 4244、DOI 10.17487 / RFC4244、2005年11月、<http：//www.rfc-editor。 org / info / rfc4244>。
[RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, <http://www.rfc-editor.org/info/rfc5806>.
[RFC5806] Levy、S。およびM. Mohali、編、「SIPの宛先変更表示」、RFC 5806、DOI 10.17487 / RFC5806、2010年3月、<http://www.rfc-editor.org/info/rfc5806> 。
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, DOI 10.17487/RFC7044, February 2014, <http://www.rfc-editor.org/info/rfc7044>.
[RFC7044] Barnes、M.、Audet、F.、Schubert、S.、van Elburg、J。、およびC. Holmberg、「An an Extension to the Session Initiation Protocol（SIP）for Request History Information」、RFC 7044、DOI 10.17487 / RFC7044、2014年2月、<http://www.rfc-editor.org/info/rfc7044>。
[Err1409] RFC Errata, Erratum ID 1409, RFC 4458.
[Err1409] RFC Errata、Erratum ID 1409、RFC 4458。
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, DOI 10.17487/RFC4458, April 2006, <http://www.rfc-editor.org/info/rfc4458>.
[RFC4458] Jennings、C.、Audet、F。、およびJ. Elwell、「ボイスメールやインタラクティブ音声応答（IVR）などのアプリケーションのセッション開始プロトコル（SIP）URI」、RFC 4458、DOI 10.17487 / RFC4458、2006年4月、<http://www.rfc-editor.org/info/rfc4458>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC6044] Mohali, M., "Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", RFC 6044, DOI 10.17487/RFC6044, October 2010, <http://www.rfc-editor.org/info/rfc6044>.
[RFC6044] Mohali、M。、「セッション開始プロトコル（SIP）の転換とHistory-Infoヘッダー間の転換情報のマッピングとインターワーキング」、RFC 6044、DOI 10.17487 / RFC6044、2010年10月、<http：// www。 rfc-editor.org/info/rfc6044>。
[TS_24.604] 3rd Generation Partnership Project, "Communication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification", Release 13.1, 3GPP TS 24.604, June 2015.
[TS_24.604] 3rd Generation Partnership Project、「Communication Diversion（CDIV）using IP Multimedia（IM）Core Network（CN）subsystem; Protocol specification」、Release 13.1、3GPP TS 24.604、June 2015。
[TS_29.163] 3rd Generation Partnership Project, "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks", Release 13.2, 3GPP TS 29.163, June 2015.
[TS_29.163]第3世代パートナーシッププロジェクト、「IPマルチメディア（IM）コアネットワーク（CN）サブシステムと回線交換（CS）ネットワーク間のインターワーキング」、リリース13.2、3GPP TS 29.163、2015年6月。
Appendix A. Interworking between Diversion Header Field and Voicemail URI
付録A.宛先変更ヘッダーフィールドとボイスメールURI間のインターワーキング
Voicemail URI is a mechanism described in [RFC4458] to provide a simple way to transport only one redirecting user address and the reason why the diversion occurred in the Request-URI of the INVITE request. This mechanism is mainly used for call diversion to a voicemail.
ボイスメールURIは、[RFC4458]で説明されているメカニズムで、リダイレクトするユーザーアドレスを1つだけ転送する簡単な方法と、INVITEリクエストのRequest-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 field with a default value set to 404.
リダイレクション理由のマッピングは、デフォルト値が404に設定されたHistory-Infoヘッダーフィールドの場合と同じです。
If the Diversion header field contains more than one Diversion entry, the choice of the redirecting user information inserted in the URI is in charge of the network local policy. For example, the choice criterion of the redirecting information inserted in the URI could be the destination of forwarded INVITE request (whether or note the voicemail serves this user).
Diversionヘッダーフィールドに複数のDiversionエントリが含まれている場合、URIに挿入されたリダイレクトするユーザー情報の選択は、ネットワークローカルポリシーを担当します。たとえば、URIに挿入されたリダイレクト情報の選択基準は、転送されたINVITEリクエストの宛先になる可能性があります（ボイスメールがこのユーザーにサービスを提供するかどうかにかかわらず）。
Note: This interworking could be done in addition to the interworking of the Diversion header field into the History-Info header field.
注：このインターワーキングは、DiversionヘッダーフィールドをHistory-Infoヘッダーフィールドにインターワーキングすることに加えて実行できます。
In case of real voicemail, this way of interworking should not happen. However, if for any reason it occurs, it is recommended to do it as follows:
実際のボイスメールの場合、このようなインターワーキングは発生しません。ただし、何らかの理由で発生した場合は、次のようにすることをお勧めします。
Received:
INVITE sip: voicemail@example.com;\
target=sip:+33145454500%40example.com;user=phone;\
cause=302 SIP/2.0
Sent in the forwarded INVITE:
Diversion: sip:+33145454500%40example.com;user=phone;
reason=unconditional;counter=1
Acknowledgements
謝辞
The author would like to acknowledge the constructive feedback and support provided by Steve Norreys, Jan Van Geel, Martin Dolly, Francisco Silva, Guiseppe Sciortino, Cinza Amenta, Christer Holmberg, Ian Elz, Jean-Francois Mule, Mary Barnes, Francois Audet, Erick Sasaki, Shida Schubert, Joel M. Halpern, Bob Braden, Robert Sparks, Merci a Lionel Morand, and Xavier Marjou et Philippe Fouquart.
著者は、スティーブ・ノーレイズ、ヤン・ヴァン・ゲール、マーティン・ドリー、フランシスコ・シルバ、ギセップ・シオルティノ、シンザ・アメンタ、クリスター・ホルムバーグ、イアン・エルツ、ジャン・フランソワ・ミュール、メアリー・バーンズ、フランソワ・オーデ、エリックによる建設的なフィードバックとサポートに感謝します佐々木、志田シューベルト、ジョエル・M・ハルパーン、ボブ・ブレーデン、ロバート・スパークス、メルシー・ア・リオネル・モランド、ザビエル・マルジュとフィリップ・フーカル。
Author's Address
著者のアドレス
Marianne Mohali Orange 38-40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France
マリアンヌモハリオレンジ38-40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France
Phone: +33 1 45 29 45 14
Email: marianne.mohali@orange.com