[要約] RFC 7044は、SIPの拡張であり、リクエスト履歴情報を提供するためのものです。その目的は、SIPセッションの履歴情報を取得し、ネットワークのトラブルシューティングやパフォーマンスの改善に役立てることです。
Internet Engineering Task Force (IETF) M. Barnes
Request for Comments: 7044 Polycom
Obsoletes: 4244 F. Audet
Category: Standards Track Skype
ISSN: 2070-1721 S. Schubert
NTT
J. van Elburg
Detecon International Gmbh
C. Holmberg
Ericsson
February 2014
An Extension to the Session Initiation Protocol (SIP) for Request History Information
リクエスト履歴情報のセッション開始プロトコル（SIP）の拡張
Abstract
概要
This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244.
このドキュメントでは、セッション開始プロトコル（SIP）要求に関連する履歴情報を取得するための標準メカニズムを定義しています。この機能は、SIPリクエストが特定のアプリケーションまたはユーザーにどのように、なぜ到着したかに関する情報を提供することにより、多くの拡張サービスを可能にします。このドキュメントでは、リクエストの履歴情報を取得するためのオプションのSIPヘッダーフィールドHistory-Infoを定義しています。このドキュメントでは、History-InfoおよびContactヘッダーフィールドのSIPヘッダーフィールドパラメーターも定義して、リクエストのターゲットを決定する方法にタグを付けています。さらに、この仕様では、History-Infoヘッダーフィールドの値の匿名化を指示するPrivacyヘッダーフィールドの値を定義しています。このドキュメントはRFC 4244を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、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/rfc7044.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7044で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの資料が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. History-Info Header Field Protocol Structure . . . . . . . . 7
5.1. History-Info Header Field Example Scenario . . . . . . . 10
6. User Agent Handling of the History-Info Header Field . . . . 12
6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . 12
6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . 12
6.3. Back-to-Back User Agent (B2BUA) Behavior . . . . . . . . 12
7. Proxy/Intermediary Handling of History-Info Header Fields . . 13
8. Redirect Server Handling of History-Info Header Fields . . . 13
9. Handling of History-Info Header Fields in Requests and
Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 14
9.2. Sending a Request with History-Info . . . . . . . . . . . 14
9.3. Receiving a Response with History-Info or Request
Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 15
9.4. Sending History-Info in Responses . . . . . . . . . . . . 16
10. Processing the History-Info Header Field . . . . . . . . . . 16
10.1. Privacy in the History-Info Header Field . . . . . . . . 16
10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 16
10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 17
10.2. Reason in the History-Info Header Field . . . . . . . . 18
10.3. Indexing in the History-Info Header Field . . . . . . . 19
10.4. Mechanism for Target Determination in the History-Info
Header Field . . . . . . . . . . . . . . . . . . . . . . 21
11. Application Considerations . . . . . . . . . . . . . . . . . 22
12. Application-Specific Usage . . . . . . . . . . . . . . . . . 24
12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . 24
12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14.1. Registration of New SIP History-Info Header Field . . . 26
14.2. Registration of "history" for SIP Privacy Header Field . 27
14.3. Registration of Header Field Parameters . . . . . . . . 27
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 28
16.1. Backwards Compatibility . . . . . . . . . . . . . . . . 29
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.1. Normative References . . . . . . . . . . . . . . . . . . 31
17.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Request History Requirements . . . . . . . . . . . . 33
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 34
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . 35
Many services that SIP is anticipated to support require the ability to determine why and how a SIP request arrived at a specific application. Examples of such services include (but are not limited to) sessions initiated to call centers via "click to talk" SIP Uniform Resource Locators (URLs) on a web page, "call history/ logging"-style services within intelligent "call management" software for SIP user agents (UAs), and calls to voicemail servers. Although SIP implicitly provides the retarget capabilities that enable SIP requests to be routed to chosen applications, there is a need for a standard mechanism within SIP for communicating the retargeting history of the requests. This request history information allows the receiving application to obtain information about how and why the SIP request arrived at the application/user.
SIPがサポートすると予想される多くのサービスでは、SIPリクエストが特定のアプリケーションに到着した理由と方法を判別する機能が必要です。このようなサービスの例には、Webページの「クリックツートーク」SIP Uniform Resource Locators（URL）を介してコールセンターに開始されるセッション、インテリジェントな「通話管理」内の「通話履歴/ロギング」スタイルのサービスが含まれます（ただしこれらに限定されません）。 SIPユーザーエージェント（UA）用のソフトウェア、およびボイスメールサーバーへの呼び出し。 SIPは暗黙的に、SIP要求を選択されたアプリケーションにルーティングできるようにするリターゲット機能を提供しますが、要求のリターゲット履歴を通信するためのSIP内の標準メカニズムが必要です。この要求履歴情報により、受信アプリケーションは、SIP要求がアプリケーション/ユーザーに到着した方法と理由に関する情報を取得できます。
This document defines a SIP header field, History-Info, to provide a standard mechanism for capturing the request history information to enable a wide variety of services for networks and end-users. SIP header field parameters are defined for the History-Info and Contact header fields to tag the method by which the target of a request is determined. This specification also defines a value, "history", for the Privacy header field. In addition, a SIP option tag, "histinfo", is defined.
このドキュメントでは、SIPヘッダーフィールドであるHistory-Infoを定義して、リクエスト履歴情報をキャプチャしてネットワークとエンドユーザーにさまざまなサービスを提供するための標準メカニズムを提供します。リクエストのターゲットを決定するメソッドにタグを付けるために、History-InfoおよびContactヘッダーフィールドに対してSIPヘッダーフィールドパラメータが定義されています。この仕様は、プライバシーヘッダーフィールドの値「履歴」も定義します。さらに、SIPオプションタグ「histinfo」が定義されています。
The History-Info header field provides a building block for development of SIP-based applications and services. The requirements for the solution described in this specification are included in Appendix A. Example scenarios using the History-Info header field are available in [CALLFLOWS].
History-Infoヘッダーフィールドは、SIPベースのアプリケーションとサービスを開発するためのビルディングブロックを提供します。この仕様で説明されているソリューションの要件は、付録Aに含まれています。History-Infoヘッダーフィールドを使用したシナリオ例は、[CALLFLOWS]にあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The term "retarget" is used in this specification to refer to the process of a SIP entity changing the Request-URI (Section 7.1 of [RFC3261]) in a request based on the rules for determining request targets as described in Section 16.5 of [RFC3261] and of the subsequent forwarding of that request as described in step 2 in Section 16.6 of [RFC3261]. 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 the forwarding of the request.
「リターゲット」という用語は、この仕様では、[16.5節で説明されているように、リクエストターゲットを決定するためのルールに基づいて、リクエスト内のリクエストURI（[RFC3261]のセクション7.1）を変更するSIPエンティティのプロセスを指します。 [RFC3261]と、[RFC3261]のセクション16.6のステップ2で説明されている、そのリクエストのその後の転送。これには、位置情報サービスの検索とリダイレクト処理によるRequest-URIの変更が含まれます。これには、要求の転送前のURIの内部（プロキシ/ SIP中間）への変更も含まれます。
The terms "location service", "forward", "redirect", and "AOR" (address-of-record) are used consistently with the terminology in [RFC3261].
「ロケーションサービス」、「フォワード」、「リダイレクト」、および「AOR」（レコードのアドレス）という用語は、[RFC3261]の用語と一貫して使用されています。
The term "target user" is used in this specification as the human user associated with one or more particular AORs (in case the human user has multiple aliases).
「ターゲットユーザー」という用語は、この仕様では、1つ以上の特定のAORに関連付けられた人間のユーザーとして使用されます（人間のユーザーが複数のエイリアスを持っている場合）。
The references to "domain for which the SIP entity/proxy/intermediary is responsible" are consistent with and intended to convey the same context as the usage of that terminology in [RFC3261]. The applicability of History-Info to architectures or models outside the context of [RFC3261] is outside the scope of this specification.
「SIPエンティティ/プロキシ/仲介者が責任を負うドメイン」への言及は、[RFC3261]でのその用語の使用と同じコンテキストと一致し、同じコンテキストを伝えることを目的としています。 [RFC3261]のコンテキスト外のアーキテクチャまたはモデルへのHistory-Infoの適用性は、この仕様の範囲外です。
SIP implicitly provides retargeting capabilities that enable SIP requests to be routed to specific applications as defined in [RFC3261]. The motivation for capturing the request history is that in the process of retargeting a request, old routing information can be forever lost. This lost information may be important history that allows elements to which the request is retargeted to process the request in a locally defined, application-specific manner. This document defines a mechanism for transporting the request history. Application-specific behavior is outside the scope of this specification.
SIPは、[RFC3261]で定義されているように、SIP要求を特定のアプリケーションにルーティングできるようにするリターゲティング機能を暗黙的に提供します。リクエスト履歴をキャプチャする動機は、リクエストのターゲットを変更するプロセスで、古いルーティング情報が永久に失われる可能性があることです。この失われた情報は、ローカルで定義されたアプリケーション固有の方法でリクエストを再ターゲットする要素がリクエストを処理できるようにする重要な履歴である可能性があります。このドキュメントでは、リクエスト履歴を転送するメカニズムを定義しています。アプリケーション固有の動作は、この仕様の範囲外です。
Current network applications for other protocols provide the ability for elements involved with the request to obtain additional information relating to how and why the request was routed to a particular destination. The following are examples of such applications:
他のプロトコルの現在のネットワークアプリケーションでは、要求に関連する要素が、要求が特定の宛先にルーティングされた方法と理由に関する追加情報を取得できます。以下はそのようなアプリケーションの例です。
1. Web "referral" applications, whereby an application residing within a web server determines that a visitor to a website has arrived at the site via an "associate" site that will receive some "referral" commission for generating this traffic.
1. Web "紹介"アプリケーション。これにより、Webサーバー内にあるアプリケーションは、Webサイトへの訪問者が、このトラフィックを生成するための "紹介"手数料を受け取る "関連"サイトを介してサイトに到達したと判断します。
2. Email relaying whereby the recipient obtains a detailed "trace of the path" of the message from originator to receiver, including the time of each relay.
2. 受信者が各リレーの時間を含む、発信者から受信者へのメッセージの詳細な「パスのトレース」を取得する電子メールリレー。
3. Traditional telephony services such as voicemail, call-center "automatic call distribution", and "follow me"-style services.
3. ボイスメール、コールセンターの「自動コール配信」、「フォローミー」スタイルのサービスなどの従来のテレフォニーサービス。
Several of the aforementioned applications currently define application-specific mechanisms through which it is possible to obtain the necessary history information.
前述のアプリケーションのいくつかは現在、必要な履歴情報を取得できるアプリケーション固有のメカニズムを定義しています。
In addition, request history information could be used to enhance basic SIP functionality by providing the following:
さらに、要求履歴情報は、以下を提供することにより、基本的なSIP機能を拡張するために使用できます。
o Some diagnostic information for debugging SIP requests.
o SIPリクエストをデバッグするためのいくつかの診断情報。
o Capturing aliases and Globally Routable User Agent URIs (GRUUs) [RFC5627], which can be overwritten by a registrar or a "home proxy" (a proxy serving as the terminal point for routing an address-of-record) upon receipt of the initial request.
o エイリアスとグローバルルーティング可能なユーザーエージェントURI（GRUU）[RFC5627]のキャプチャ。これは、レジストラまたは「ホームプロキシ」（レコードのアドレスをルーティングするためのターミナルポイントとして機能するプロキシ）によって上書きされます。リクエスト。
o Facilitating the use of limited use addresses (minted on demand) and sub-addressing.
o 使用制限付きアドレス（オンデマンドで作成）およびサブアドレス指定の使用を容易にします。
o Preserving service-specific URIs that can be overwritten by a downstream proxy, such as those defined in [RFC3087], and control of network announcements and Interactive Voice Response (IVR) with a SIP URI [RFC4240].
o [RFC3087]で定義されているような、ダウンストリームプロキシによって上書きできるサービス固有のURIを保持し、SIP URI [RFC4240]でネットワークアナウンスとインタラクティブ音声応答（IVR）を制御します。
The fundamental functionality provided by the request history information is the ability to inform proxies and user agents (UAs) involved in processing a request about the history or progress of that request. The solution is to capture the Request-URIs, as a request is retargeted, in a SIP header field: History-Info. This allows for the capturing of the history of a request that would be lost with the normal SIP processing involved in the subsequent retargeting of the request.
要求履歴情報によって提供される基本的な機能は、要求の処理に関与するプロキシおよびユーザーエージェント（UA）に、その要求の履歴または進行状況を通知する機能です。解決策は、リクエストがリターゲットされるときに、SIPヘッダーフィールドHistory-InfoでリクエストURIをキャプチャすることです。これにより、その後のリクエストの再ターゲットに関連する通常のSIP処理で失われるリクエストの履歴をキャプチャできます。
The History-Info header field is added to a request when a new request is created by a User Agent Client (UAC) or forwarded by a proxy, or when the target of a request is changed. It is possible for the target of a request to be changed by the same proxy/SIP intermediary multiple times (referred to as 'internal retargeting'). A SIP entity changing the target of a request in response to a redirect also propagates any History-Info header field from the initial request in the new request. The ABNF and detailed description of the History-Info header field parameters, along with examples, are provided in Section 5. Sections 6, 7, and 8 provide the detailed handling of the History-Info header field by SIP user agents, proxies, and redirect servers, respectively.
History-Infoヘッダーフィールドは、ユーザーエージェントクライアント（UAC）によって新しい要求が作成されたとき、またはプロキシによって転送されたとき、または要求のターゲットが変更されたときに、要求に追加されます。リクエストのターゲットが同じプロキシ/ SIP仲介者によって複数回変更される可能性があります（「内部再ターゲット」と呼ばれます）。リダイレクトに応答してリクエストのターゲットを変更するSIPエンティティは、新しいリクエストの最初のリクエストからのHistory-Infoヘッダーフィールドも伝播します。 ABNFとHistory-Infoヘッダーフィールドパラメータの詳細な説明は、例とともにセクション5で提供されています。セクション6、7、および8は、SIPユーザーエージェント、プロキシ、およびクライアントによるHistory-Infoヘッダーフィールドの詳細な処理を提供します。それぞれリダイレクトサーバー。
This specification also defines three new SIP header field parameters, "rc", "mp", and "np", for the History-Info and Contact header fields to tag the method by which the target of a request is determined. Further detail on the use of these header field parameters is provided in Section 5.
この仕様では、History-InfoおよびContactヘッダーフィールドの3つの新しいSIPヘッダーフィールドパラメーター「rc」、「mp」、および「np」も定義しており、リクエストのターゲットを決定する方法にタグを付けています。これらのヘッダーフィールドパラメータの使用の詳細については、セクション5で説明します。
This specification also defines a priv-value for the Privacy header, "history"; it requires anonymization of all the History-Info header field entries in a request or to a specific History-Info header field value (hi-entry) as described below. Further detail is provided in Section 10.1.
この仕様では、プライバシーヘッダー「履歴」のプライベート値も定義されています。以下に説明するように、リクエスト内のすべてのHistory-Infoヘッダーフィールドエントリ、または特定のHistory-Infoヘッダーフィールド値（hi-entry）への匿名化が必要です。詳細は、10.1項を参照してください。
In addition, a SIP option tag, "histinfo", is defined. The use of this option tag is described in Section 6.1.
さらに、SIPオプションタグ「histinfo」が定義されています。このオプションタグの使用については、セクション6.1で説明します。
The History-Info header field defined in this specification defines the usage in out-of-dialog requests or initial requests for a dialog (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) and any non-100 provisional or final responses to these requests.
この仕様で定義されているHistory-Infoヘッダーフィールドは、ダイアログ外の要求またはダイアログの最初の要求（たとえば、INVITE、REGISTER、MESSAGE、REFERとOPTIONS、PUBLISHとSUBSCRIBEなど）および非これらの要求に対する100の暫定または最終応答。
The following provides details for the information that is captured in the History-Info header field entries for each target used for forwarding a request.
以下に、リクエストの転送に使用される各ターゲットのHistory-Infoヘッダーフィールドエントリにキャプチャされる情報の詳細を示します。
o hi-targeted-to-uri: A mandatory parameter for capturing the Request-URI for the specific request as it is forwarded.
o hi-targeted-to-uri：特定の要求が転送されるときに、その要求のRequest-URIを取得するための必須パラメーター。
o hi-index: A mandatory parameter for History-Info reflecting the chronological order of the information, indexed to reflect the forking and retargeting of requests. The format for this parameter is a sequence of nonnegative integers, separated by dots to indicate the number of forward hops and retargets. This results in a tree representation of the history of the request, with the lowest-level index reflecting a leaf. By adding the new entries in chronological order (i.e., following existing entries per the details in Section 10.3), including the index and sending the messages using a secure transport, the ordering of the History-Info header fields in the request is assured. In addition, applications may extract a variety of metrics (total number of retargets, total number of retargets from a specific branch, etc.) based upon the index values.
o hi-index：情報の発生順を反映するHistory-Infoの必須パラメーター。リクエストの分岐と再ターゲットを反映するようにインデックスが付けられます。このパラメーターの形式は、フォワードホップとリターゲットの数を示すためにドットで区切られた一連の非負整数です。これにより、リクエストの履歴がツリーで表現され、最低レベルのインデックスが葉を反映します。インデックスを含め、新しいエントリを時系列順に（つまり、セクション10.3の詳細に従って既存のエントリに従って）追加し、リクエスト内のHistory-Infoヘッダーフィールドの順序を保証します。さらに、アプリケーションは、インデックス値に基づいて、さまざまなメトリック（リターゲットの総数、特定のブランチからのリターゲットの総数など）を抽出できます。
o hi-target-param: An optional parameter reflecting the mechanism by which the Request-URI captured in the hi-targeted-to-uri in the History-Info header field value (hi-entry) was determined. This parameter is either an "rc", "mp", or "np" header field parameter, which is interpreted as follows:
o hi-target-param：History-Infoヘッダーフィールド値（hi-entry）のhi-targeted-to-uriでキャプチャされたRequest-URIが決定されるメカニズムを反映するオプションのパラメーター。このパラメーターは、 "rc"、 "mp"、または "np"ヘッダーフィールドパラメーターであり、次のように解釈されます。
"rc": The hi-targeted-to-URI represents a change in Request-URI, while the target user remains the same. This occurs, for example, when the user has multiple AORs as an alias. The "rc" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that reflects the Request-URI that was retargeted.
「rc」：hi-targeted-to-URIは、ターゲットユーザーは同じまま、Request-URIの変更を表します。これは、たとえば、ユーザーがエイリアスとして複数のAORを持っている場合に発生します。 「rc」ヘッダーフィールドパラメータには、再ターゲットされたRequest-URIを反映するhi-targeted-to-uriを持つhi-entryのhi-indexの値が含まれます。
"mp": The hi-targeted-to-URI represents a user other than the target user associated with the Request-URI in the incoming request that was retargeted. This occurs when a request is statically or dynamically retargeted to another user represented by an AOR unassociated with the AOR of the original target user. The "mp" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that reflects the Request-URI that was retargeted, thus identifying the "mapped from" target.
"mp"：hi-targeted-to-URIは、リターゲットされた受信リクエストのRequest-URIに関連付けられたターゲットユーザー以外のユーザーを表します。これは、要求が静的または動的に、元のターゲットユーザーのAORに関連付けられていないAORによって表される別のユーザーに再ターゲットされるときに発生します。 「mp」ヘッダーフィールドパラメータには、再ターゲットされたRequest-URIを反映するhi-targeted-to-uriを持つhi-entryのhi-indexの値が含まれるため、「マップされた」ターゲットを識別します。
"np": The hi-targeted-to-URI represents that there was no change in the Request-URI. This would apply, for example, when a proxy merely forwards a request to a next-hop proxy and loose routing is used. The "np" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that reflects the Request-URI that was copied unchanged into the request represented by this hi-entry. That value will usually be the hi-index of the parent hi-entry of this hi-entry.
"np"：hi-targeted-to-URIは、Request-URIに変更がなかったことを表します。これは、たとえば、プロキシが要求をネクストホッププロキシに転送するだけで、ルーズルーティングが使用される場合に適用されます。 「np」ヘッダーフィールドパラメータには、hi-entryのhi-indexの値が含まれ、hi-targeted-to-uriには、このhi-entryで表されるリクエストに変更されずにコピーされたRequest-URIが反映されます。その値は通常、このhi-entryの親hi-entryのhi-indexになります。
o Extension (hi-extension): A parameter to allow for future optional extensions. As per [RFC3261], any implementation not understanding an extension MUST ignore it.
o 拡張（hi-extension）：将来のオプションの拡張を可能にするパラメーター。 [RFC3261]に従って、拡張機能を理解しない実装はそれを無視しなければなりません（MUST）。
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)
History-Info = "History-Info" HCOLON hi-entry *（COMMA hi-entry）
hi-entry = hi-targeted-to-uri *(SEMI hi-param)
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
hi-index = "index" EQUAL index-val
index-val = number *("." number)
index-val = number *（ "。" number）
number = [ %x31-39 *DIGIT ] DIGIT
hi-target-param = rc-param / mp-param / np-param
rc-param = "rc" EQUAL index-val
rc-param = "rc" EQUAL index-val
mp-param = "mp" EQUAL index-val
mp-param = "mp" EQUAL index-val
np-param = "np" 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]からのものです。
This document also extends the "contact-params" for the Contact header field as defined in [RFC3261] with the "rc", "mp", and "np" header field parameters defined above.
このドキュメントはまた、[RFC3261]で定義されているContactヘッダーフィールドの "contact-params"を、上記で定義された "rc"、 "mp"、および "np"ヘッダーフィールドパラメーターで拡張します。
In addition to the parameters defined by the ABNF, an hi-entry may also include a Reason header field and/or a Privacy header field, which are both included in the "headers" component of the hi-targeted-to-uri as described below:
ABNFで定義されたパラメーターに加えて、hi-entryにはReasonヘッダーフィールドやPrivacyヘッダーフィールドが含まれる場合があります。これらは両方とも、前述のようにhi-targeted-to-uriの「ヘッダー」コンポーネントに含まれています。未満：
o Reason: An optional parameter for History-Info, reflected in the History-Info header field by including the Reason header field [RFC3326] included in the hi-targeted-to-uri. A reason is included in the hi-targeted-to-uri of an hi-entry to reflect information received in a response to the request sent to that URI.
o 理由：hi-targeted-to-uriに含まれるReasonヘッダーフィールド[RFC3326]を含めることにより、History-Infoヘッダーフィールドに反映されるHistory-Infoのオプションパラメーター。 hi-entryのhi-targeted-to-uriには、そのURIに送信された要求への応答で受信した情報を反映する理由が含まれています。
o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy header [RFC3323] with a priv-value of "history", as defined in this document, included in the hi-targeted-to-uri or by adding the Privacy header field with a priv-value of "history" to the request. The latter case indicates that the History-Info entries for all History-Info entries whose hi-targeted-to-uri has the same domain as the domain for which the SIP entity processing the message is responsible MUST be anonymized prior to forwarding, whereas the use of the Privacy header field included in the hi -targeted-to-uri means that a specific hi-entry MUST be anonymized.
o プライバシー：History-Infoのオプションのパラメーター。His-targeted- to-uriを使用するか、priv-valueが「history」のプライバシーヘッダーフィールドをリクエストに追加します。後者のケースは、hi-targeted-to-uriが、メッセージを処理するSIPエンティティが担当するドメインと同じドメインを持つすべてのHistory-InfoエントリのHistory-Infoエントリは、転送前に匿名化する必要があることを示します。 hi -targeted-to-uriに含まれるプライバシーヘッダーフィールドを使用すると、特定のhi-entryを匿名化する必要があります。
Note that since both the Reason and Privacy parameters are included in the hi-targeted-to-uri, these fields will not be available in the case that the hi-targeted-to-uri is a Tel-URI [RFC3966].
ReasonパラメータとPrivacyパラメータの両方がhi-targeted-to-uriに含まれているため、hi-targeted-to-uriがTel-URI [RFC3966]である場合、これらのフィールドは使用できないことに注意してください。
The following provides examples of the format for the History-Info header field. Note that the backslash, CRLF, and whitespace between the lines in the examples below are inserted for readability purposes only. Note, however, that History-Info can be broken into multiple lines due to the SWS (sep whitespace) that is part of HCOLON, COMMA, and SEMI, and there can be multiple History-Info header fields due to the rule of Section 7.3 of [RFC3261]. Additional detailed examples are available in [CALLFLOWS].
以下に、History-Infoヘッダーフィールドの形式の例を示します。以下の例のバックスラッシュ、CRLF、および行間の空白は、読みやすくする目的でのみ挿入されていることに注意してください。ただし、HCOLON、COMMA、およびSEMIの一部であるSWS（sep whitespace）により、History-Infoが複数行に分割される可能性があり、セクション7.3のルールにより複数のHistory-Infoヘッダーフィールドが存在する可能性があることに注意してください。 [RFC3261]の。追加の詳細な例は、[CALLFLOWS]にあります。
History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar
History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B\
cause%3D302>;index=1.1,\
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
cause%3D486>;index=1.2;mp=1.1,\
<sip:45432@192.168.0.3>;index=1.3;rc=1.2
The following is an illustrative example of usage of History-Info.
次に、History-Infoの使用例を示します。
In this example, Alice (sip:alice@atlanta.example.com) calls Bob (sip:bob@biloxi.example.com). Alice's proxy in her home domain (sip:atlanta.example.com) forwards the request to Bob's proxy (sip:biloxi.example.com). When the request arrives at sip:biloxi.example.com, it does a location service lookup for bob@biloxi.example.com and changes the target of the request to Bob's Contact URIs that were provided as part of normal SIP registration. In this example, Bob is simultaneously contacted on a PC client and on a phone, and Bob answers on the PC client.
この例では、アリス（sip：alice@atlanta.example.com）がボブ（sip：bob@biloxi.example.com）を呼び出します。ホームドメイン内のアリスのプロキシ（sip：atlanta.example.com）は、リクエストをボブのプロキシ（sip：biloxi.example.com）に転送します。リクエストがsip：biloxi.example.comに到着すると、リクエストサービスはbob@biloxi.example.comの位置情報サービスを検索し、リクエストのターゲットを通常のSIP登録の一部として提供されたボブの連絡先URIに変更します。この例では、ボブはPCクライアントと電話で同時に接続され、ボブはPCクライアントで応答します。
One important thing illustrated by this call flow is that without History-Info, Bob would "lose" the original target information or the initial Request-URI, including any parameters in the Request-URI. Bob can recover that information by locating the last hi-entry with an "rc" header field parameter. This "rc" header field parameter contains the index of the hi-entry containing the lost target information, i.e., the sip:bob@biloxi.example.com hi-entry with index=1.1. Note that in the 200 response to Alice, an hi-entry is not included for the fork to sip:bob@192.0.2.7 (index 1.1.1) since biloxi.example.com had not received a response from that fork at the time it sent the 200 OK that ultimately reached Alice.
この呼び出しフローで示されている重要なことの1つは、History-Infoがないと、Bobが元のターゲット情報または最初のRequest-URI（Request-URIのパラメーターを含む）を「失う」ことです。ボブは、「rc」ヘッダーフィールドパラメータを使用して最後のhi-entryを見つけることで、その情報を回復できます。この「rc」ヘッダーフィールドパラメータには、失われたターゲット情報を含むhi-entryのインデックスが含まれます。つまり、sip：bob@biloxi.example.com hi-entryはindex = 1.1です。 Aliceへの200応答では、biloxi.example.comがそのフォークからその時点で応答を受け取っていなかったため、sip：bob@192.0.2.7（インデックス1.1.1）へのフォークのhi-entryは含まれていません。最終的にアリスに到達する200 OKを送信しました。
Additional detailed examples are available in [CALLFLOWS].
追加の詳細な例は、[CALLFLOWS]にあります。
Note: This example uses loose routing procedures.
注：この例では、ルーズルーティング手順を使用しています。
Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone
| | | | |
| INVITE sip:bob@biloxi.example.com;p=x | |
|--------------->| | | |
| Supported: histinfo | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 |
| | | | |
| | INVITE sip:bob@biloxi.example.com;p=x |
| |--------------->| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 |
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| | | | |
| | | INVITE sip:bob@192.0.2.3|
| | |--------------->| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | | INVITE sip:bob@192.0.2.7|
| | |-------------------------->|
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.7>;index=1.1.2;rc=1.1
| | | 200 | |
| | |<---------------| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | 200 | | |
| |<---------------| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | |
| | | Proxy Cancels INVITE |
| | |<=========================>|
| 200 | | | |
|<---------------| | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| ACK | | | |
|--------------->| ACK | | |
| |--------------->| ACK | |
| | |--------------->| |
Figure 1: Basic Call
図1：基本的な呼び出し
This section describes the processing specific to UAs -- User Agent Clients (UACs), User Agent Servers (UASs), and Back-to-Back User Agents (B2BUAs) -- for the History-Info header.
このセクションでは、History-InfoヘッダーのUAに固有の処理（ユーザーエージェントクライアント（UAC）、ユーザーエージェントサーバー（UAS）、およびバックツーバックユーザーエージェント（B2BUA））について説明します。
The UAC MUST include the "histinfo" option tag in the Supported header field in any out-of-dialog requests or initial requests for a dialog for which the UAC would like the History-Info header field in the response. When issuing a request, the UAC MUST follow the procedures in Section 9.2. In the case of an initial request, except where the UAC is part of a B2BUA, there is no cache of hi-entries with which to populate the History-Info header field, and the hi-index is set to 1 per Section 10.3. When receiving a response, the UAC MUST follow the procedures in Section 9.3.
UACは、UACが応答のHistory-Infoヘッダーフィールドを必要とするダイアログのダイアログ外の要求または初期要求で、Supportedヘッダーフィールドに「histinfo」オプションタグを含める必要があります。リクエストを発行するとき、UACはセクション9.2の手順に従う必要があります。最初のリクエストの場合、UACがB2BUAの一部である場合を除き、History-Infoヘッダーフィールドに入力するhiエントリのキャッシュはなく、hi-indexはセクション10.3に従って1に設定されます。応答を受信するとき、UACはセクション9.3の手順に従う必要があります。
If the UAC generates further forks of the initial request (either due to acting on a 3xx response or internally directed forking to multiple destinations), the successive requests will add hi-entries with hi-indexes of 2, 3, etc.
UACが最初のリクエストのさらなるフォークを生成する場合（3xx応答に基づいて動作するか、複数の宛先に内部的に向けられたフォークのいずれかにより）、後続のリクエストは、2、3などのhi-indexを持つhi-entriesを追加します。
When receiving a request, a UAS MUST follow the procedures defined in Section 9.2. When sending a response other than a 3xx response, a UAS MUST follows the procedures defined in Section 9.4. When sending a 3xx response, the UAS MUST follow the procedures defined for a redirect server per Section 8. An application at the UAS can make use of the cached hi-entries as described in Section 11.
UASは、リクエストを受け取るとき、セクション9.2で定義された手順に従う必要があります。 3xx応答以外の応答を送信する場合、UASはセクション9.4で定義された手順に従う必要があります。 3xx応答を送信するとき、UASはセクション8に従ってリダイレクトサーバーに対して定義された手順に従う必要があります。UASのアプリケーションは、セクション11で説明されているように、キャッシュされたhi-entryを利用できます。
A B2BUA MAY follow the behavior of a SIP intermediary, per Section 7, as an alternative to following the behavior of a UAS per Section 6.2 or a UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries forward hi-entries received in requests at the UAS to requests being forwarded by the UAC, as well as carrying forward hi-entries in responses received at the UAC to the responses forwarded by the UAS, subject to privacy considerations per Section 10.1.
B2BUAは、セクション6.2のUASまたはセクション6.1のUACの動作に従う代わりに、セクション7のSIP中間機能の動作に従う場合があります。仲介者として動作する場合、B2BUAは、UASで転送された要求に、UASで転送された要求に受信したhi-entryを転送し、UASで転送された応答にUACで受信された応答で転送hi-entriesを転送します。セクション10.1のプライバシーに関する考慮事項
This section describes the procedures for proxies and other SIP intermediaries for the handling of the History-Info header fields for each of the following scenarios:
このセクションでは、次の各シナリオのHistory-Infoヘッダーフィールドを処理するためのプロキシおよびその他のSIP仲介者の手順について説明します。
Receiving a Request: An intermediary MUST follow the procedures in Section 9.1 for the handling of hi-entries in incoming SIP requests.
リクエストの受信：仲介者は、着信SIPリクエストのhi-entriesを処理するためにセクション9.1の手順に従う必要があります。
Sending a Request: For each outgoing request relating to a target in the target set, the intermediary MUST follow the procedures of Section 9.2.
リクエストの送信：ターゲットセット内のターゲットに関連する発信リクエストごとに、仲介者はセクション9.2の手順に従う必要があります。
Receiving a Response or Timeout: An intermediary MUST follow the procedures of Section 9.3 when a SIP response is received or a request times out.
応答またはタイムアウトの受信：仲介者は、SIP応答を受信したとき、または要求がタイムアウトしたときに、セクション9.3の手順に従う必要があります。
Sending a Response: An intermediary MUST follow the procedures of Section 9.4 for the handling of the hi-entries when sending a SIP response.
応答の送信：仲介者は、SIP応答を送信するときのhi-entriesの処理について、セクション9.4の手順に従う必要があります。
In some cases, an intermediary may retarget a request more than once before forwarding, i.e., a request is retargeted to a SIP entity that is "internal" to the intermediary before the same intermediary retargets the request to an external target. A typical example would be a proxy that retargets a request first to a different user (i.e., it maps to a different AOR) and then forwards it to a registered contact bound to the same AOR. In this case, the intermediary MUST add an hi-entry for (each of) the internal target(s) per the procedures in Section 9.2. The intermediary MAY include a Reason header field in the hi-entry with the hi-targeted-to-uri that has been retargeted. Note that this is shown in the INVITE (F6) in the example entitled "Sequentially Forking (History-Info in Response)" in [CALLFLOWS].
場合によっては、仲介者が転送の前にリクエストを複数回リターゲティングすることがあります。つまり、同じ仲介者がリクエストを外部ターゲットに再ターゲティングする前に、リクエストは仲介者に対して「内部」にあるSIPエンティティに再ターゲティングされます。典型的な例は、最初に要求を別のユーザーに再ターゲットし（つまり、別のAORにマップする）、次に同じAORにバインドされた登録済み連絡先に転送するプロキシです。この場合、仲介者は、セクション9.2の手順に従って、内部ターゲット（のそれぞれ）のhi-entryを追加する必要があります。仲介者は、再ターゲットされたhi-targeted-to-uriとともにhi-entryにReasonヘッダーフィールドを含めることができます（MAY）。これは、[CALLFLOWS]の「Sequentially Forking（History-Info in Response）」というタイトルの例のINVITE（F6）に示されていることに注意してください。
A redirect server MUST follow the procedures in Section 9.1 when it receives a SIP request. A redirect server MUST follow the procedures in Section 9.4 when it sends a SIP response. When generating the Contact header field in a 3xx response, the redirect server MUST add the appropriate "mp", "np", or "rc" header field parameter to each Contact header field as described in Section 10.4, if applicable.
リダイレクトサーバーは、SIPリクエストを受信するとき、セクション9.1の手順に従う必要があります。リダイレクトサーバーは、SIP応答を送信するときにセクション9.4の手順に従う必要があります。 3xx応答でContactヘッダーフィールドを生成するとき、リダイレクトサーバーは、セクション10.4で説明されているように、該当する場合、適切な「mp」、「np」、または「rc」ヘッダーフィールドパラメーターを各Contactヘッダーフィールドに追加する必要があります。
This section describes the procedures for SIP entities for the handling of the History-Info header field in SIP requests and responses.
このセクションでは、SIP要求および応答のHistory-Infoヘッダーフィールドを処理するSIPエンティティの手順について説明します。
When receiving a request, a SIP entity MUST keep a copy of the hi-entries from the incoming request. This document describes this copy in terms of a cache containing the hi-entries associated with the request. The hi-entries MUST be added to the cache in the order in which they were received in the request.
リクエストを受信すると、SIPエンティティは着信リクエストからのhi-entriesのコピーを保持する必要があります。このドキュメントでは、リクエストに関連付けられたhi-entriesを含むキャッシュの観点からこのコピーについて説明します。 hi-entriesは、リクエストで受信された順序でキャッシュに追加する必要があります。
If the Request-URI of the incoming request does not match the hi -targeted-to-uri in the last hi-entry (i.e., the previous SIP entity that sent the request did not include a History-Info header field), the SIP entity MUST add an hi-entry to the end of the cache, on behalf of the previous SIP entity. This is done as follows, before proceeding to Section 9.2.
着信要求のRequest-URIが最後のhi-entryのhi -targeted-to-uriと一致しない場合（つまり、要求を送信した以前のSIPエンティティにHistory-Infoヘッダーフィールドが含まれていなかった場合）、SIPエンティティは、前のSIPエンティティに代わって、キャッシュの最後にhi-entryを追加する必要があります。これは、セクション9.2に進む前に、次のように行われます。
The SIP entity MUST set the hi-targeted-to-uri to the value of the Request-URI in the incoming request. If the Request-URI is a Tel-URI, it SHOULD be transformed into a SIP URI (per Section 19.1.6 of [RFC3261]) before being added as an hi-targeted-to-uri.
SIPエンティティは、hi-targeted-to-uriを着信要求のRequest-URIの値に設定する必要があります。 Request-URIがTel-URIの場合は、hi-targeted-to-uriとして追加する前にSIP URIに変換する必要があります（[RFC3261]のセクション19.1.6に従って）。
If privacy is required, the SIP entity MUST follow the procedures of Section 10.1.
プライバシーが必要な場合、SIPエンティティはセクション10.1の手順に従う必要があります。
The SIP entity MUST set the hi-index parameter as described in Section 10.3.
SIPエンティティは、セクション10.3で説明されているようにhi-indexパラメータを設定する必要があります。
The SIP entity MUST NOT include an "rc", "mp", or "np" header field parameter.
SIPエンティティには、「rc」、「mp」、または「np」ヘッダーフィールドパラメータを含めることはできません。
When sending a request, a SIP entity MUST include all the hi-entries from the cache that was created per Section 9.1. In addition, the SIP entity MUST add a new hi-entry to the outgoing request, but the SIP entity MUST NOT add the hi-entry to the cache at this time. The hi-entries in the outgoing request's History-Info header field represent the preorder of the tree of hi-entries, that is, by the lexicographic ordering of the hi-indexes. The new hi-entry is populated as follows: hi-targeted-to-uri: The hi-targeted-to-uri MUST be set to the value of the Request-URI of the current (outgoing) request. If the Request-URI is a Tel-URI, it SHOULD be transformed into a SIP URI (per Section 19.1.6 of [RFC3261]) before being added as an hi-targeted-to-uri.
リクエストを送信するとき、SIPエンティティは、セクション9.1に従って作成されたキャッシュからのすべてのhi-entriesを含める必要があります。さらに、SIPエンティティは発信要求に新しいhi-entryを追加する必要がありますが、この時点ではSIPエンティティはキャッシュにhi-entryを追加してはなりません。発信要求のHistory-Infoヘッダーフィールドのhi-entriesは、hi-entriesのツリーの事前順序を表します。つまり、hi-indexの辞書式順序によるものです。新しいhi-entryは次のように入力されます。hi-targeted-to-uri：hi-targeted-to-uriは、現在の（発信）リクエストのRequest-URIの値に設定する必要があります。 Request-URIがTel-URIの場合は、hi-targeted-to-uriとして追加する前にSIP URIに変換する必要があります（[RFC3261]のセクション19.1.6に従って）。
privacy: If privacy is required, the procedures of Section 10.1 MUST be followed.
プライバシー：プライバシーが必要な場合は、セクション10.1の手順に従う必要があります。
hi-index: The SIP entity MUST include an hi-index for the hi-entry as described in Section 10.3.
hi-index：セクション10.3で説明されているように、SIPエンティティはhi-entryのhi-indexを含める必要があります。
rc/mp/np: The SIP entity MUST include an "rc", "mp", or "np" header field parameter in the hi-entry, if applicable, per the procedures in Section 10.4.
rc / mp / np：SIPエンティティは、セクション10.4の手順に従って、該当する場合、hi-entryに「rc」、「mp」、または「np」ヘッダーフィールドパラメータを含める必要があります。
When a SIP entity receives a non-100 response or a request times out, the SIP entity performs the following steps:
SIPエンティティが100以外の応答を受信するか、要求がタイムアウトすると、SIPエンティティは次の手順を実行します。
Step 1: Add hi-entry to cache
ステップ1：hi-entryをキャッシュに追加する
The SIP entity MUST add the hi-entry that was added to the request that received the non-100 response or timed out to the cache, if it was not already cached. The hi-entry MUST be added to the cache in ascending order as indicated by the values in the hi-index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 but before 1.2.2 or 1.3).
SIPエンティティーは、非100応答を受信した要求に追加された、またはタイムアウトになったhi-entryをキャッシュに追加する必要があります（まだキャッシュされていない場合）。 hi-entryは、hi-entriesのhi-indexパラメータの値で示されているように、昇順でキャッシュに追加する必要があります（たとえば、1.2.1は1.2の後に来るが1.2.2または1.3の前に来る）。
Step 2: Add Reason header field
ステップ2：Reasonヘッダーフィールドを追加する
If the response is not a 100 or 2xx response, the SIP entity adds one or more Reason header fields to the hi-targeted-to-uri in the (newly) cached hi-entry reflecting the SIP response code in the non-100 or non-2xx response, per the procedures of Section 10.2.
応答が100または2xx応答でない場合、SIPエンティティは、1つ以上のReasonヘッダーフィールドを（新しく）キャッシュされたhi-entryのhi-targeted-to-uriに追加し、非100またはセクション10.2の手順に従って、2xx以外の応答。
Step 3: Add additional hi-entries
ステップ3：hi-entriesを追加する
The SIP entity MUST also add to the cache any hi-entries received in the response that are not already in the cache. This situation can occur when the entity that generated the non-100 response retargeted the request before generating the response. As per Step 1, the hi-entries MUST be added to the cache in ascending order as indicated by the values in the hi-index parameters of the hi-entries.
SIPエンティティは、まだキャッシュにない応答で受信されたすべてのhiエントリもキャッシュに追加する必要があります。この状況は、非100応答を生成したエンティティが、応答を生成する前に要求を再ターゲットした場合に発生する可能性があります。ステップ1のとおり、hi-entriesのhi-indexパラメーターの値で示されるように、hi-entriesを昇順でキャッシュに追加する必要があります。
It is important to note that the cache (and the request or response) does not contain hi-entries for requests that have not yet received a non-100 response, so there can be gaps in indices (e.g., 1.2 and 1.4 could be present but not 1.3).
キャッシュ（および要求または応答）には、まだ100以外の応答を受け取っていない要求のhi-entriesが含まれていないため、インデックスにギャップがある可能性があることに注意してください（例：1.2と1.4が存在する可能性があります） 1.3ではありません）。
Note that in the case that a request has traversed one or more intermediaries that do not support RFC 4244 or this document, there can be duplicate indices (due to forking), which would be added to the appropriate position in the cache in the order in which they are received.
リクエストがRFC 4244またはこのドキュメントをサポートしていない1つ以上の仲介者を通過した場合、（forkにより）重複するインデックスが存在する可能性があることに注意してください。これらのインデックスは、次の順序でキャッシュの適切な位置に追加されます。それらが受信されます。
When sending a response other than a 100, a SIP entity MUST include all the cached hi-entries in the response, subject to the privacy consideration in Section 10.1.2, and with the following exception: If the received request contained no hi-entries and there is no "histinfo" option tag in the Supported header field, the SIP entity MUST NOT include History-Info in the response.
100以外の応答を送信する場合、SIPエンティティは、セクション10.1.2のプライバシーに関する考慮事項に従って、キャッシュされたすべてのhi-entryを応答に含める必要があります。ただし、次の例外があります。受信したリクエストにhi-entriesが含まれていない場合また、Supportedヘッダーフィールドに「histinfo」オプションタグがない場合、SIPエンティティは応答にHistory-Infoを含めてはなりません。
The following subsections describe the procedures for processing the History-Info header field. These procedures are applicable to SIP entities such as proxies/intermediaries, redirect servers, or user agents.
次のサブセクションでは、History-Infoヘッダーフィールドの処理手順について説明します。これらの手順は、プロキシ/仲介者、リダイレクトサーバー、ユーザーエージェントなどのSIPエンティティに適用できます。
The privacy requirements for this document are described in Appendix A.2. Section 10.1.1 describes the insertion of the Privacy header field (defined in [RFC3323]) to indicate the privacy to be applied to the History-Info header field entries. Section 10.1.2 describes how to apply privacy to a request or response that is being forwarded, based on the presence of the Privacy header field.
このドキュメントのプライバシー要件については、付録A.2で説明しています。セクション10.1.1は、History-Infoヘッダーフィールドエントリに適用されるプライバシーを示すためのプライバシーヘッダーフィールド（[RFC3323]で定義）の挿入について説明しています。セクション10.1.2では、プライバシーヘッダーフィールドの存在に基づいて、転送される要求または応答にプライバシーを適用する方法について説明します。
As with other SIP headers described in [RFC3323], the hi-targeted-to-uris in the History-Info header field can inadvertently reveal information about the initiator of the request. Thus, the UAC needs a mechanism to indicate that the hi-targeted-to-uris in the hi-entries need to be privacy protected. The Privacy header field is used by the UAC to indicate that privacy is to be applied to all the hi-entries in the request as follows: o If the UAC is including a Privacy header field with a priv-value of "header" in the request, then the UAC SHOULD NOT include a priv-value of "history" in the Privacy header field in the request.
[RFC3323]で説明されている他のSIPヘッダーと同様に、History-Infoヘッダーフィールドのhi-targeted-to-urisは、リクエストの開始者に関する情報を誤って明らかにする可能性があります。したがって、UACには、hi-entriesのhi-targeted-to-uriをプライバシー保護する必要があることを示すメカニズムが必要です。プライバシーヘッダーフィールドはUACによって使用され、プライバシーが要求内のすべてのhi-entriesに次のように適用されることを示します。o UACが「ヘッダー」のプライベート値を持つプライバシーヘッダーフィールドを含む場合、リクエストの場合、UACはリクエストのプライバシーヘッダーフィールドに「history」のプライベート値を含めないでください。
o If the UAC is including any priv-values other than "header" in the Privacy header field, then the UAC MUST also include a priv-value of "history" in the Privacy header field in the request.
o UACがプライバシーヘッダーフィールドに「ヘッダー」以外の任意のプライベート値を含める場合、UACはリクエストのプライバシーヘッダーフィールドに「履歴」のプライベート値も含める必要があります。
o If the UAC is not including any priv-values in the Privacy header field in the request, then the UAC MUST add a Privacy header field, with a priv-value of "history", to the request. The UAC MUST NOT include a priv-value of "critical" in the Privacy header field in the request in this case.
o UACがリクエストのプライバシーヘッダーフィールドにプライベート値を含まない場合、UACはリクエストにプライバシー値「履歴」のプライバシーヘッダーフィールドを追加する必要があります。この場合、UACはリクエストのプライバシーヘッダーフィールドに「クリティカル」のプライベート値を含めてはなりません（MUST NOT）。
In addition, the History-Info header field can reveal general routing and diverting information that is within an intermediary and that the intermediary wants to privacy protect. In this case, the intermediary MUST construct a Privacy header field with the single priv-value of "history" and include the Privacy header field in the hi-targeted-to-uri, for each new hi-entry created by the intermediary whose hi-targeted-to-uri it wishes to privacy protect. Note that the priv-value in the Privacy header for the incoming request does not necessarily influence whether the intermediary includes a Privacy header field in the hi-entries. For example, even if the Privacy header for the incoming request contained a priv-value of "none", the proxy can still set a priv-value of "history" in the Privacy header field included in the hi-targeted-to-uri.
さらに、History-Infoヘッダーフィールドは、仲介者内にあり、仲介者がプライバシー保護を望んでいる一般的なルーティングおよび迂回情報を明らかにすることができます。この場合、仲介者は、「history」という単一のプライベート値でプライバシーヘッダーフィールドを作成し、hi-targeted-to-uriにプライバシーヘッダーフィールドを含める必要があります。 -targeted-to-uriプライバシーを保護したい。着信要求のプライバシーヘッダーのpriv-valueは、仲介者がhi-entriesにプライバシーヘッダーフィールドを含めるかどうかに必ずしも影響しないことに注意してください。たとえば、着信リクエストのプライバシーヘッダーに「none」のpriv-valueが含まれている場合でも、プロキシはhi-targeted-to-uriに含まれるプライバシーヘッダーフィールドに「history」のpriv-valueを設定できます。 。
Finally, the UAS may not want to reveal the final reached target to the originator. In this case, the UAS MUST include a Privacy header field with a priv-value of "history" in the hi-targeted-to-uri in the last hi-entry, in the response. As noted above, the UAS of the request MUST NOT use any other priv-values in the Privacy header field included in the hi-entry.
最後に、UASは最終的に到達したターゲットを発信者に明らかにしたくない場合があります。この場合、UASは、応答の最後のhi-entryのhi-targeted-to-uriに「history」のpriv-valueを持つプライバシーヘッダーフィールドを含める必要があります。上記のように、リクエストのUASは、hi-entryに含まれるプライバシーヘッダーフィールドで他のプライベート値を使用してはなりません。
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 "headers" component of the hi-targeted-to-uri in the individual hi-entries.
SIPメッセージがSIP仲介者が責任を負わないドメインに転送されると、ドメインの境界にあるプライバシーサービスは、メッセージヘッダーまたは「ヘッダー」のプライバシーヘッダーフィールドの値に基づいて適切なプライバシーを適用します個々のhi-entriesのhi-targeted-to-uriのコンポーネント。
If there is a Privacy header field in the message header of a request or response, 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-uris in these hi-entries that have not been anonymized (evidenced by their domain not being "anonymous.invalid") to anonymous URIs containing a domain of anonymous.invalid as recommended in Section 4.1.1.3 of [RFC3323]. As defined in Section 4.1.1.2 of [RFC3323], the recommendations of [RFC3261] for anonymizing the URI Username SHOULD be followed (i.e., "anonymous" in the user portion of the URI). If there is a Privacy header field in the "headers" component of the hi-targeted-to-uri in the hi-entries, then the Privacy header field value MUST be removed from the hi-entry. Once all the appropriate hi-entries have been anonymized, the Privacy Service MUST remove the priv-value of "history" from the Privacy header field in the message header of the request or response. If there are no remaining priv-values in the Privacy header field, the Privacy Service MUST remove the Privacy header field from the request or response per [RFC3323].
リクエストまたはレスポンスのメッセージヘッダーにプライバシーヘッダーフィールドがあり、priv-valueが「header」または「history」の場合、すべてのhi-targeted-to-uris（に関連付けられているhi-entries SIP仲介者が責任を負うドメイン）は、プライバシーサービスによって匿名化されます。プライバシーサービスは、匿名化されていない（ドメインが「anonymous.invalid」でないことから明らかな）これらのhi-entriesのhi-targeted-to-uriを、セクションで推奨されているように、anonymous.invalidのドメインを含む匿名URIに変更する必要があります。 [RFC3323]の4.1.1.3。 [RFC3323]のセクション4.1.1.2で定義されているように、URIユーザー名を匿名化するための[RFC3261]の推奨に従う必要があります（つまり、URIのユーザー部分の「匿名」）。 hi-entriesのhi-targeted-to-uriの「headers」コンポーネントにプライバシーヘッダーフィールドがある場合は、プライバシーヘッダーフィールドの値をhi-entryから削除する必要があります。すべての適切なhi-entriesが匿名化されると、プライバシーサービスは、要求または応答のメッセージヘッダーのプライバシーヘッダーフィールドから "history"のpriv-valueを削除する必要があります。プライバシーヘッダーフィールドにプライベート値が残っていない場合、プライバシーサービスは、[RFC3323]に従って、要求または応答からプライバシーヘッダーフィールドを削除する必要があります。
If there is not a Privacy header field in the message header of the request or response that is being forwarded, but there is a Privacy header field with a priv-value of "history" in the "headers" component in any of the hi-targeted-uris in the hi-entries associated with the domain for which a SIP intermediary is responsible, then the Privacy Service MUST update those hi-targeted-to-uris as described above. Any other priv-values in the Privacy header field in the "headers" component of the hi-targeted-to-uris in the hi-entries MUST be ignored. In any case, the Privacy Service MUST remove the Privacy header field from the "headers" component of the hi-targeted-to-uris in the hi-entries prior to forwarding.
転送されている要求または応答のメッセージヘッダーにプライバシーヘッダーフィールドがないが、いずれかのhi-の「ヘッダー」コンポーネントに「履歴」のプライベート値を持つプライバシーヘッダーフィールドがある場合SIP仲介者が担当するドメインに関連付けられたhi-entriesのTargeted-urisの場合、プライバシーサービスは、上記のようにそれらのhi-targeted-to-urisを更新する必要があります。 hi-entriesのhi-targeted-to-urisの「headers」コンポーネントのプライバシーヘッダーフィールドにあるその他のpriv-valuesは無視する必要があります。いずれの場合でも、プライバシーサービスは、転送の前にhi-entriesのhi-targeted-to-urisの「ヘッダー」コンポーネントからプライバシーヘッダーフィールドを削除する必要があります。
A Reason header field is added when the hi-entry is added to the cache based upon the receipt of a SIP response that is neither a 100 nor a 2xx response, as described in Section 9.3. The SIP entity MUST include a Reason header field, containing the SIP Response Code, in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. In addition, if the response contains any Reason header fields (see [RFC3326]), then the SIP entity MUST also include the Reason header fields in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache.
セクション9.3で説明されているように、100でも2xx応答でもないSIP応答の受信に基づいてhi-entryがキャッシュに追加されると、Reasonヘッダーフィールドが追加されます。 SIPエンティティは、キャッシュに追加された最後のhi-entryのhi-targeted-to-uriの「ヘッダー」コンポーネントに、SIP応答コードを含むReasonヘッダーフィールドを含める必要があります（ただし、hi-targeted-to- uriはTel-URIです。さらに、応答にReasonヘッダーフィールド（[RFC3326]を参照）が含まれている場合、SIPエンティティは最後のhi-entryのhi-targeted-to-uriの "headers"コンポーネントにReasonヘッダーフィールドも含める必要があります。キャッシュに追加されました。
If a request has timed out (instead of being explicitly rejected), the SIP entity MUST update the cache as if the request received a SIP error response code of 408 "Request Timeout".
リクエストが（明示的に拒否されるのではなく）タイムアウトした場合、SIPエンティティは、リクエストが408 "Request Timeout"のSIPエラー応答コードを受け取ったかのようにキャッシュを更新する必要があります。
A request can receive multiple responses that are neither 100 nor 2xx responses and that carry or imply (for responses without Reason headers, and for timeouts) multiple, possibly duplicated, reason-values to be applied to an hi-targeted-to-uri. In these situations, the SIP entity creating the History-Info header value would choose the appropriate Reason header field value.
リクエストは、100でも2xxでもない複数の応答を受け取り、（Reasonヘッダーのない応答とタイムアウトの場合）hi-targeted-to-uriに適用される複数の、おそらく重複したreason-valuesを運ぶか、または含意します。これらの状況では、History-Infoヘッダー値を作成するSIPエンティティは、適切なReasonヘッダーフィールド値を選択します。
A SIP entity MAY also include a Reason header field (in the "headers" component of an hi-targeted-to-uri) that contains the URI of a request that was retargeted as a result of internal retargeting.
SIPエンティティは、内部リターゲティングの結果としてリターゲティングされたリクエストのURIを含むReasonヘッダーフィールド（hi-targeted-to-uriの「headers」コンポーネント内）も含めることができます（MAY）。
If additional Reason header field parameters are defined in the future per [RFC3326], the use of these Reason header field parameters for the History-Info header field MUST follow the same rules as described above.
追加のReasonヘッダーフィールドパラメーターが[RFC3326]に従って将来定義される場合、History-Infoヘッダーフィールドに対するこれらのReasonヘッダーフィールドパラメーターの使用は、上記と同じルールに従う必要があります。
In order to maintain ordering and accurately reflect the retargeting of the request, the SIP entity MUST add an hi-index to each hi-entry. Per the syntax in Section 5, the hi-index consists of a series of nonnegative integers separated by dots (e.g., 1.1.2). Each dot reflects a SIP forwarding hop. The nonnegative integer following each dot reflects the order in which a request was retargeted at the hop. The highest nonnegative integer at each hop reflects the number of entities to which the request has been retargeted at the specific hop (i.e., the number of branches) at the time that the request represented by this hi-entry was generated. Thus, the indexing results in a logical tree representation for the history of the request and the hi-entries are given in the preorder of the tree.
順序を維持し、リクエストのリターゲティングを正確に反映するために、SIPエンティティは各hi-entryにhi-indexを追加する必要があります。セクション5の構文によれば、hi-indexは、ドットで区切られた一連の非負の整数で構成されます（例：1.1.2）。各ドットは、SIP転送ホップを反映しています。各ドットに続く負でない整数は、要求がホップで再ターゲットされた順序を反映しています。各ホップの最大の負でない整数は、このhi-entryで表されるリクエストが生成された時点で、リクエストが特定のホップで再ターゲットされたエンティティの数（つまり、ブランチの数）を反映しています。したがって、索引付けの結果、要求の履歴の論理ツリー表現が得られ、hi-entryはツリーのプリオーダーで指定されます。
The first index in a series of History-Info entries MUST be set to 1. In the case that a SIP entity (intermediary or UAS) adds a first hi-entry on behalf of the previous hop, the hi-index MUST be set to 1. For each forward hop (i.e., each new level of indexing), the last integers of the hi-indexes of the new requests MUST be generated starting at 1 and incrementing by 1 for each additional request.
一連のHistory-Infoエントリの最初のインデックスは1に設定する必要があります。SIPエンティティ（中間またはUAS）が前のホップに代わって最初のhi-entryを追加する場合、hi-indexは1.各フォワードホップ（つまり、新しいレベルのインデックス作成）ごとに、新しいリクエストのhi-indexの最後の整数は、1から始まり、追加のリクエストごとに1ずつ増加する必要があります。
The basic rules for adding the hi-index are summarized as follows:
hi-indexを追加するための基本的なルールは、次のように要約されます。
1. Forwarding a request without changing the target: In the case of a request that is being forwarded without changing the target, the hi-index reflects the increasing length of the branch. In this case, the SIP entity MUST read the value from the History-Info header field in the received request and MUST add another level of indexing by appending the dot delimiter followed by an initial value of 1 for the new level. For example, if the hi-index in the last History-Info header field in the received request is 1.1, a proxy would add an hi-entry with an hi-index of 1.1.1 and forward the request.
1.ターゲットを変更せずにリクエストを転送する：ターゲットを変更せずに転送されるリクエストの場合、hi-indexはブランチの長さの増加を反映します。この場合、SIPエンティティは、受信した要求のHistory-Infoヘッダーフィールドから値を読み取り、新しいレベルの初期値1が後に続くドット区切り文字を追加することにより、別のレベルのインデックスを追加する必要があります。たとえば、受信した要求の最後のHistory-Infoヘッダーフィールドのhi-indexが1.1の場合、プロキシはhi-indexが1.1.1のhi-entryを追加し、要求を転送します。
2. Retargeting within a processing entity - first instance: For the first instance of retargeting within a processing entity, the SIP entity MUST calculate the hi-index as prescribed for basic forwarding.
2. 処理エンティティ内での再ターゲット-最初のインスタンス：処理エンティティ内での再ターゲットの最初のインスタンスでは、SIPエンティティは基本的な転送に規定されているようにhi-indexを計算する必要があります。
3. Retargeting within a processing entity - subsequent instance: For each subsequent retargeting of a request by the same SIP entity, the SIP entity MUST calculate and add the hi-index for each new branch by incrementing the rightmost value from the hi-index in the last hi-entry. Per the example above, the hi-index in the next request forwarded by this same SIP entity would be 1.1.2.
3. 処理エンティティ内での再ターゲット-後続のインスタンス：同じSIPエンティティによるリクエストの後続の再ターゲットごとに、SIPエンティティは最後のhi-indexから右端の値をインクリメントして、新しいブランチごとにhi-indexを計算して追加する必要がありますハイエントリー。上記の例では、この同じSIPエンティティによって転送される次のリクエストのhi-indexは1.1.2になります。
4. Retargeting based upon a response: In the case of retargeting due to a specific response (e.g., 302), the SIP entity MUST calculate the hi-index calculated per rule 3. That is, the rightmost value of the hi-index MUST be incremented (i.e., a new branch is created). For example, if the hi-index in the History-Info header field of the sent request is 1.2 and the response to the request is a 302, then the hi-index in the History-Info header field for the new hi-targeted-to-URI would be 1.3.
4. 応答に基づくリターゲティング：特定の応答（302など）によるリターゲティングの場合、SIPエンティティはルール3に従って計算されたhi-indexを計算する必要があります。つまり、hi-indexの右端の値をインクリメントする必要があります。 （つまり、新しいブランチが作成されます）。たとえば、送信されたリクエストのHistory-Infoヘッダーフィールドのhi-indexが1.2で、リクエストに対するレスポンスが302の場合、新しいhi-targeted-のHistory-Infoヘッダーフィールドのhi-index to-URIは1.3になります。
5. Forking requests: If the request forwarding is done in multiple forks (sequentially or in parallel), the SIP entity MUST set the hi-index for each hi-entry for each forked request per the rules above, with each new request having a unique index. Each index MUST be sequentially assigned. For example, if the index in the last History-Info header field in the received request is 1.1, this processing entity would initialize its index to 1.1.1 for the first fork, 1.1.2 for the second, and so forth. (See Figure 1 for an example.) Note that, in the case of parallel forking, only the hi-entry corresponding to the fork is included in the request because no response can yet have been received for any of the parallel forked requests.
5. リクエストのフォーク：リクエストの転送が複数のフォークで（順次または並列に）行われる場合、SIPエンティティは、上記のルールに従って、フォークされた各リクエストの各hi-entryにhi-indexを設定する必要があります。 。各インデックスは順次割り当てられなければなりません。たとえば、受信したリクエストの最後のHistory-Infoヘッダーフィールドのインデックスが1.1の場合、この処理エンティティは、最初のフォークのインデックスを1.1.1に、2番目のフォークを1.1.2に、というように初期化します。 （例については、図1を参照してください。）並列フォークの場合、並列フォークされた要求のいずれに対してもまだ応答を受信できないため、フォークに対応するhi-entryのみが要求に含まれることに注意してください。
6. 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 an hi-entry MUST add a single index with a value of "0" (i.e., the nonnegative integer zero) prior to adding the appropriate index for the action to be taken. For example, if the index of the last hi-entry in the request received was 1.1.2 and there was a missing hi-entry and the request was being forwarded to the next hop, the resulting index will be 1.1.2.0.1. In the case of requests that are forked by a proxy that does not support History-Info, it is possible for hi-entries generated by different entities to have the same index, i.e., each entity supporting History-Info would receive a forked request with the same hi-index to which they would add the value of ".0" prior to adding the appropriate index. Thus, in the previous example, each of the next-hop entities would generate an hi-index of 1.1.2.0.1.
6.欠落しているエントリ：リクエストのhi-entryに明らかにギャップがある場合（つまり、最後のhi-entryとRequest-URIが異なる場合）、hi-entryを追加するエンティティは、値「0」の単一のインデックスを追加する必要があります。 "（つまり、非負の整数ゼロ）を実行する前に、実行するアクションに適切なインデックスを追加します。たとえば、受信したリクエストの最後のhi-entryのインデックスが1.1.2で、hi-entryが欠落していて、リクエストが次のホップに転送されている場合、結果のインデックスは1.1.2.0.1になります。 History-Infoをサポートしないプロキシによってフォークされたリクエストの場合、異なるエンティティによって生成されたhi-entryが同じインデックスを持つ可能性があります。つまり、History-Infoをサポートする各エンティティは、適切なインデックスを追加する前に「.0」の値を追加するのと同じhi-index。したがって、前の例では、各ネクストホップエンティティは1.1.2.0.1のhi-indexを生成します。
10.4. Mechanism for Target Determination in the History-Info Header Field
10.4. History-Infoヘッダーフィールドでのターゲット決定のメカニズム
This specification 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 is the hi-index of the hi-entry with an hi-targeted-to-uri that represents the Request-URI that was retargeted.
この仕様では、「rc」、「mp」、「np」の3つのヘッダーフィールドパラメータを定義しています。ヘッダーフィールドパラメータ「rc」と「mp」は、リクエストの新しいターゲットが決定されるメカニズムを示します。ヘッダーフィールド「np」は、ターゲットが変更されていないことを反映しています。すべてのパラメーターには、値がhi-entryのhi-indexであるインデックスが含まれ、hi-targeted-to-uriは、リターゲットされたRequest-URIを表します。
The SIP entity MUST determine the specific parameter field to be included in the hi-target-param, in the History-Info header field, as the targets are added to the target set per the procedures in Section 16.5 of [RFC3261] or per Section 8.1.3.4 of [RFC3261] in the case of retargeting to a Contact URI received in a 3xx response. In the latter case, the specific header field parameter in the Contact header field becomes the header field parameter that is used in the hi-entry when the request is retargeted. If the Contact header field does not contain an "rc" or "mp" header field parameter, then the SIP entity MUST NOT include an "rc" or "mp" header field parameter in the hi-target-param in the hi-entry when the request is retargeted to a Contact URI received in a 3xx response. This is because the redirect server is the only element with any knowledge on how the target was determined. Note that the "np" header field parameter is not applicable in the case of redirection.
[RFC3261]のセクション16.5の手順に従って、またはセクションごとにターゲットセットにターゲットが追加されるため、SIPエンティティは、His-target-paramに含まれる特定のパラメーターフィールドをHistory-Infoヘッダーフィールドで決定する必要があります。 3xx応答で受信した連絡先URIにリターゲットする場合の[RFC3261]の8.1.3.4。後者の場合、Contactヘッダーフィールドの特定のヘッダーフィールドパラメーターが、リクエストが再ターゲットされるときにhi-entryで使用されるヘッダーフィールドパラメーターになります。 Contactヘッダーフィールドに「rc」または「mp」ヘッダーフィールドパラメーターが含まれていない場合、SIPエンティティはhi-entryのhi-target-paramに「rc」または「mp」ヘッダーフィールドパラメーターを含めてはなりません（MUST NOT）。リクエストが3xxレスポンスで受信した連絡先URIにリターゲットされる場合。これは、リダイレクトサーバーが、ターゲットの決定方法に関する知識を持つ唯一の要素であるためです。 「np」ヘッダーフィールドパラメータは、リダイレクトの場合には適用されないことに注意してください。
Based on the following criteria, the SIP entity (intermediary or redirect server) determines the specific header field parameter ("rc", "mp", or "np") to be used.
次の基準に基づいて、SIPエンティティ（中間サーバーまたはリダイレクトサーバー）は、使用する特定のヘッダーフィールドパラメーター（ "rc"、 "mp"、または "np"）を決定します。
o "rc": The Request-URI has changed while the target user associated with the original Request-URI prior to retargeting has been retained.
o "rc"：リターゲット前の元のRequest-URIに関連付けられたターゲットユーザーが保持されている間に、Request-URIが変更されました。
o "mp": The target was determined based on a mapping to a user other than the target user associated with the Request-URI being retargeted.
o "mp"：ターゲットは、リターゲットされるRequest-URIに関連付けられたターゲットユーザー以外のユーザーへのマッピングに基づいて決定されました。
o "np": The target hasn't changed, and the associated Request-URI remained the same.
o "np"：ターゲットは変更されておらず、関連するRequest-URIは同じままです。
Note that there are two scenarios by which the "mp" header field parameter can be derived.
「mp」ヘッダーフィールドパラメータを取得できるシナリオは2つあることに注意してください。
o The mapping was done by the receiving entity on its own authority, in which case the mp-value is the parent index of the hi-entry's index.
o マッピングは受信エンティティによって独自の権限で行われました。この場合、mp値はhi-entryのインデックスの親インデックスです。
o The mapping was done due to receiving a 3xx response, in which case the mp-value is an earlier sibling or descendant of an earlier sibling of the hi-entry's index; the index is that of the downstream request that received the 3xx response.
o マッピングは3xx応答を受信したために行われました。この場合、mp値は以前の兄弟またはhi-entryのインデックスの以前の兄弟の子孫です。インデックスは、3xx応答を受信したダウンストリーム要求のインデックスです。
History-Info provides a very flexible building block that can be used by intermediaries and UAs for a variety of services. 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 the hi-entries. The SIP entity MUST be prepared to process effectively messages whose hi-entries show evidence of "gaps", that is, situations that reveal that not all of the forks of the request have been recorded in the hi-entries. Gaps are possible if the request is forwarded through intermediaries that do not support the History-Info header field and are reflected by the existence of hi-entries with a nonnegative integer of "0", e.g., "1.1.0.1". Gaps are also possible in the case of parallel forking if there is an outstanding request at the time the SIP entity sends a message. In addition, gaps may introduce the possibility of duplicate values for the hi-index in the case that a proxy that does not support History-Info forks a request. If gaps are detected, the SIP entity MUST NOT treat this as an error but SHOULD indicate to any applications that there are gaps. The interpretation of the information in the History-Info header field depends upon the specific application; an application might need to provide special handling in some cases where there are gaps.
History-Infoは、仲介者やUAがさまざまなサービスに使用できる非常に柔軟なビルディングブロックを提供します。アプリケーションがHistory-Infoヘッダーフィールドパラメータを使用する前に、hi-entriesを処理するSIPエンティティはhi-entriesを評価し、hi-entriesにギャップがあるかどうかを判断する必要があります。 SIPエンティティは、hi-entriesが「ギャップ」の証拠を示すメッセージ、つまりリクエストのすべてのフォークがhi-entriesに記録されていないことを明らかにする状況を効果的に処理する準備ができていなければなりません。リクエストがHistory-Infoヘッダーフィールドをサポートしていない仲介者を介して転送され、「0」の非負整数、たとえば「1.1.0.1」のhi-entriesの存在によって反映される場合、ギャップが発生する可能性があります。 SIPエンティティがメッセージを送信するときに未処理の要求がある場合、並列分岐の場合にもギャップが発生する可能性があります。さらに、History-Infoをサポートしないプロキシがリクエストをフォークした場合、ギャップによりhi-indexの値が重複する可能性があります。ギャップが検出された場合、SIPエンティティはこれをエラーとして扱ってはなりません（MUST NOT）が、ギャップがあることをアプリケーションに示す必要があります（SHOULD）。 History-Infoヘッダーフィールドの情報の解釈は、特定のアプリケーションによって異なります。ギャップがある場合、アプリケーションは特別な処理を提供する必要があるかもしれません。
The following describes some categories of information that applications can use:
以下では、アプリケーションが使用できる情報のいくつかのカテゴリについて説明します。
1. Complete history information, e.g., for debugging or other operational and management aspects, optimization of determining targets to avoid retargeting to the same URI, etc. This information is relevant to proxies, UACs, and UASs.
1. 完全な履歴情報。たとえば、デバッグまたはその他の運用および管理の側面、同じURIへの再ターゲットを回避するためのターゲット決定の最適化など。この情報は、プロキシ、UAC、およびUASに関連しています。
2. Hi-entry with the index that matches the value of the "rc" header field parameter in the last hi-entry with an "rc" header field parameter in the request received by a UAS, i.e., the last AOR that was retargeted to a contact based on an AOR-to-contact binding.
2. 最後のhi-entryの「rc」ヘッダーフィールドパラメーターの値と、UASが受信したリクエストの「rc」ヘッダーフィールドパラメーターの値と一致するインデックスを持つHi-entry、つまり、aに再ターゲットされた最後のAOR AORから連絡先へのバインディングに基づく連絡先。
3. Hi-entry with the index that matches the value of the "mp" header field parameter in the last hi-entry with an "mp" header field parameter in the hi-target-param in the request received by a UAS, i.e., the last Request-URI that was mapped to reach the destination.
3. UASが受信したリクエストのhi-target-paramの「mp」ヘッダーフィールドパラメータを持つ最後のhi-entryの「mp」ヘッダーフィールドパラメータの値と一致するインデックスを持つHi-entry、つまり、宛先に到達するためにマップされた最後のRequest-URI。
4. Hi-entry with the index that matches the value of the "rc" header field parameter in the first hi-entry with an "rc" header field parameter in the request received by a UAS. Note that this would be the original AOR if all the entities involved support the History-Info header field and there is an absence of an "mp" header field parameter prior to the "rc" header field parameter in the hi-target-param in the History-Info header field. However, there is no guarantee that all entities will support History-Info; thus, the hi-entry that matches the value of the "rc" header field parameter of the first hi-entry with an "rc" header field parameter in the hi-target-param within the domain associated with the target URI at the destination is more likely to be useful.
4. UASが受信したリクエストの "rc"ヘッダーフィールドパラメーターを持つ "rc"ヘッダーフィールドパラメーターの値と一致するインデックスを持つHi-entry。関係するすべてのエンティティがHistory-Infoヘッダーフィールドをサポートし、のhi-target-paramの "rc"ヘッダーフィールドパラメーターの前に "mp"ヘッダーフィールドパラメーターがない場合、これは元のAORであることに注意してください。 History-Infoヘッダーフィールド。ただし、すべてのエンティティがHistory-Infoをサポートするという保証はありません。したがって、最初のhi-entryの "rc"ヘッダーフィールドパラメーターの値と、宛先のターゲットURIに関連付けられたドメイン内のhi-target-paramの "rc"ヘッダーフィールドパラメーターと一致するhi-entry有用である可能性が高いです。
5. Hi-entry with the index that matches the value of the "mp" header field parameter in the first hi-entry with an "mp" header field parameter in the request received by a UAS. Note that this would be the original mapped URI if all entities supported the History-Info header field. However, there is no guarantee that all entities will support History-Info; thus, the hi-entry that matches the value of the "mp" header field parameter of the first hi-entry with an "mp" header field parameter within the domain associated with the target URI at the destination is more likely to be useful.
5. UASが受信したリクエストの「mp」ヘッダーフィールドパラメーターを持つ「mp」ヘッダーフィールドパラメーターの値と一致するインデックスを持つハイエントリー。すべてのエンティティがHistory-Infoヘッダーフィールドをサポートしている場合、これは元のマップされたURIになることに注意してください。ただし、すべてのエンティティがHistory-Infoをサポートするという保証はありません。したがって、最初のhi-entryの「mp」ヘッダーフィールドパラメータの値と、宛先のターゲットURIに関連付けられたドメイン内の「mp」ヘッダーフィールドパラメータが一致するhi-entryの方が便利です。
In many cases, applications are most interested in the information within one or more particular domains; thus, only a subset of the information is required.
多くの場合、アプリケーションは1つ以上の特定のドメイン内の情報に最も関心があります。したがって、情報のサブセットのみが必要です。
Some applications may use multiple types of information. For example, an Automatic Call Distribution (ACD) / call center application that utilizes the hi-entry with an index that matches the value of the "mp" header field parameter in the first hi-entry with an "mp" header field parameter may also display other agents, reflected by hi-entries prior to hi-entries with an "rc" header field parameter, to whom the call was targeted prior to its arrival at the current agent. This could allow the agent the ability to decide how they might forward or reroute the call if necessary (avoiding agents that were not previously available for whatever reason, etc.).
一部のアプリケーションは、複数のタイプの情報を使用する場合があります。たとえば、「mp」ヘッダーフィールドパラメータを持つ最初のhi-entryの「mp」ヘッダーフィールドパラメータの値と一致するインデックスを持つhi-entryを利用する自動コール配信（ACD）/コールセンターアプリケーションは、また、「rc」ヘッダーフィールドパラメータを使用したhi-entriesの前のhi-entriesによって反映され、現在のエージェントに到着する前にコールがターゲットにされた他のエージェントも表示します。これにより、エージェントは必要に応じてコールを転送または再ルーティングする方法を決定できます（以前に何らかの理由で対応できなかったエージェントを回避するなど）。
Since support for History-Info header field is optional, a service MUST define default behavior for requests and responses not containing History-Info header fields. For example, an entity may receive an incomplete set of hi-entries or hi-entries that are not tagged appropriately with an hi-target-param in the case of entries added by entities that are only compliant to RFC 4244. This may not impact some applications (e.g., debug); however, it could require some applications to make some default assumptions in this case. For example, in an ACD scenario, the application could select the oldest hi-entry with the domain associated with the ACD system and display that as the original called party. Depending upon how and where the request may have been retargeted, the complete list of agents to whom the call was targeted may not be available.
History-Infoヘッダーフィールドのサポートはオプションであるため、サービスはHistory-Infoヘッダーフィールドを含まない要求と応答のデフォルトの動作を定義する必要があります。たとえば、エンティティがRFC 4244にのみ準拠しているエンティティによって追加されたエントリの場合、hi-target-paramで適切にタグ付けされていないhi-entriesまたはhi-entriesの不完全なセットを受け取ることがあります。一部のアプリケーション（デバッグなど）。ただし、この場合、一部のアプリケーションでデフォルトの仮定を行う必要があります。たとえば、ACDシナリオでは、アプリケーションはACDシステムに関連付けられたドメインを持つ最も古いhi-entryを選択し、それを元の着信者として表示できます。リクエストがどのようにどこで再ターゲットされたかによって、コールのターゲットとなったエージェントの完全なリストが利用できない場合があります。
The following are possible (non-normative) application-specific usages of History-Info.
以下は、History-Infoの可能な（規範的ではない）アプリケーション固有の使用法です。
A voicemail system (VMS) typically requires the original called party information to determine the appropriate mailbox so an appropriate greeting can be provided and the appropriate party notified of the message.
ボイスメールシステム（VMS）は通常、適切なメールボックスを決定するために元の着信者情報を必要とするため、適切なグリーティングを提供し、適切な当事者にメッセージを通知できます。
The original target is determined by finding the first hi-entry tagged with "rc" and using the hi-entry referenced by the index of the "rc" header field parameter as the target for determining the appropriate mailbox. This hi-entry is used to populate the "target" URI parameter as defined in [RFC4458]. The VMS can look at the last hi-entry and find the target of the mailbox by looking at the URI entry in the "target" URI parameter in the hi-entry.
元のターゲットは、「rc」でタグ付けされた最初のhi-entryを見つけ、「rc」ヘッダーフィールドパラメータのインデックスで参照されるhi-entryを、適切なメールボックスを決定するためのターゲットとして使用することによって決定されます。このhi-entryは、[RFC4458]で定義されている「ターゲット」URIパラメータを設定するために使用されます。 VMSは最後のhi-entryを確認し、hi-entryの「target」URIパラメータのURIエントリを確認することで、メールボックスのターゲットを見つけることができます。
This example usage does not work properly in the presence of forwarding that takes place before the call reaches the company. In that case, not the first hi-entry with an "rc" value, but the first hi-entry with an "rc" value following an "mp" entry needs to be picked. Further detail for this example can be found in the call flow entitled "PBX Voicemail Example" in [CALLFLOWS].
この使用例は、通話が会社に届く前に転送が行われている場合、正しく機能しません。その場合、「rc」値を持つ最初のhi-entryではなく、「mp」エントリに続く「rc」値を持つ最初のhi-entryを選択する必要があります。この例の詳細は、[CALLFLOWS]の「PBX Voicemail Example」というタイトルのコールフローにあります。
Note that in the case where there is no entry tagged with "rc", a VMS can follow the procedures, as defined in [RFC4458], for the "Interaction with Request History Information".
「rc」でタグ付けされたエントリがない場合、VMSは、[RFC4458]で定義されている「要求履歴情報との相互作用」の手順に従うことができることに注意してください。
The voicemail system in this environment typically requires the last called party information to determine the appropriate mailbox so an appropriate greeting can be provided and the appropriate party notified of the message.
この環境のボイスメールシステムでは、適切なグリーティングを提供し、適切な関係者にメッセージを通知できるように、通常、適切なメールボックスを決定するために最後の着信者情報が必要です。
The last target is determined by finding the hi-entry referenced by the index of the last hi-entry tagged with "rc" for determining the appropriate mailbox. This hi-entry is used to populate the "target" URI parameter as defined in [RFC4458]. The VMS can look at the last hi-entry and find the target of the mailbox by looking for the "target" URI parameter in the hi-entry. Further detail for this example can be found in the call flow entitled "Consumer Voicemail Example" in [CALLFLOWS].
最後のターゲットは、適切なメールボックスを決定するために「rc」でタグ付けされた最後のhi-entryのインデックスによって参照されるhi-entryを見つけることによって決定されます。このhi-entryは、[RFC4458]で定義されている「ターゲット」URIパラメータを設定するために使用されます。 VMSは、最後のhi-entryを調べ、hi-entryで "target" URIパラメータを探すことにより、メールボックスのターゲットを見つけることができます。この例の詳細は、[CALLFLOWS]の「Consumer Voicemail Example」というタイトルのコールフローにあります。
In the case where there is no entry tagged with "rc", a VMS can follow the procedures, as defined in [RFC4458], for the "Interaction with Request History Information".
「rc」でタグ付けされたエントリがない場合、VMSは、[RFC4458]で定義されている「要求履歴情報との相互作用」の手順に従うことができます。
The security requirements for this specification are specified in Appendix A.1.
この仕様のセキュリティ要件は、付録A.1で指定されています。
This document defines a header field for SIP. The use of the Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the overall confidentiality of the History-Info header fields (SEC-req-4) is strongly RECOMMENDED. If TLS is NOT used, the intermediary MUST ensure that the messages are only sent within an environment that is secured by other means or that the messages don't leave the intermediary's domain. This results in History-Info's having at least the same level of security as other headers in SIP that are inserted by intermediaries. With TLS, History-Info header fields are no less, nor no more, secure than other SIP header fields, which generally have even more impact on the subsequent processing of SIP sessions than the History-Info header field.
このドキュメントでは、SIPのヘッダーフィールドを定義します。 History-Infoヘッダーフィールド（SEC-req-4）の全体的な機密性を保証するメカニズムとしてのトランスポート層セキュリティ（TLS）プロトコル[RFC5246]の使用は強く推奨されます。 TLSを使用しない場合、仲介者は、メッセージが他の手段で保護された環境内でのみ送信されること、またはメッセージが仲介者のドメインを出ないことを確認する必要があります。これにより、History-Infoのセキュリティは、仲介者によって挿入されるSIPの他のヘッダーと少なくとも同じレベルになります。 TLSを使用すると、History-Infoヘッダーフィールドは他のSIPヘッダーフィールドよりも安全であり、通常、History-InfoヘッダーフィールドよりもSIPセッションの後続の処理により大きな影響を与えます。
Note that while using the SIPS scheme (as per [RFC5630]) protects History-Info from tampering by arbitrary parties outside the SIP message path, all the intermediaries on the path are trusted implicitly. A malicious intermediary could arbitrarily delete, rewrite, or modify History-Info. This specification does not attempt to prevent or detect attacks by malicious intermediaries.
SIPSスキーム（[RFC5630]に従って）を使用することで、History-InfoがSIPメッセージパス外の任意のパーティによる改ざんから保護されますが、パス上のすべての仲介者は暗黙的に信頼されます。悪意のある仲介者が、History-Infoを任意に削除、書き換え、または変更する可能性があります。この仕様は、悪意のある仲介者による攻撃を防止または検出しようとするものではありません。
In terms of ensuring the privacy of hi-entries, the same security considerations as those described in [RFC3323] apply. The Privacy Service that's defined in [RFC3323] MUST also support the new Privacy header field priv-value of "history" and anonymize hi-entries in the case of a priv-value of "header" as described in Section 10.1.2.
hi-entriesのプライバシーを確保するという点では、[RFC3323]で説明されているものと同じセキュリティ上の考慮事項が適用されます。 [RFC3323]で定義されているプライバシーサービスは、セクション10.1.2で説明されているように、「履歴」の新しいプライバシーヘッダーフィールドpriv-valueをサポートし、priv-valueが「header」の場合はhi-entriesを匿名化する必要があります。
IANA registrations have been implemented or updated as detailed in the following subsections.
IANA登録は、以下のサブセクションで詳しく説明するように実装または更新されています。
This document obsoletes [RFC4244] but uses the same SIP header field name, Privacy header field, and Option tag. References to [RFC4244] in the IANA "Session Initiation Protocol (SIP) Parameters" registry (<http://www.iana.org/assignments/sip-parameters>) have been replaced with references to this document.
このドキュメントは[RFC4244]を廃止しますが、同じSIPヘッダーフィールド名、プライバシーヘッダーフィールド、およびオプションタグを使用します。 IANAの「セッション開始プロトコル（SIP）パラメータ」レジストリ（<http://www.iana.org/assignments/sip-parameters>）の[RFC4244]への参照は、このドキュメントへの参照に置き換えられました。
This document defines a SIP header field name, History-Info; and an option tag, histinfo. The following updates have been made to <http://www.iana.org/assignments/sip-parameters>.
このドキュメントでは、SIPヘッダーフィールド名History-Infoを定義しています。オプションタグ、histinfo。 <http://www.iana.org/assignments/sip-parameters>に次の更新が行われました。
The following row has been updated in the "Header Fields" sub-registry:
次の行が「Header Fields」サブレジストリで更新されました。
Header Name Compact Form Reference
----------- ------------ ---------
History-Info none [RFC7044]
The following has been updated in the "Option Tags" sub-registry:
「オプションタグ」サブレジストリで以下が更新されました。
Name Description Reference
---- ----------- ---------
histinfo When used with the Supported header field, [RFC7044]
this option tag indicates the UAC supports
the History Information to be captured for
requests and returned in subsequent
responses. This tag is not used in a
Proxy-Require or Require header field,
since support of History-Info is optional.
This document defines a priv-value for the SIP Privacy header field: history. The following updates have been made to the "SIP Privacy Header Field Values" sub-registry in <http://www.iana.org/assignments /sip-parameters> for the registration of the SIP Privacy header field:
このドキュメントでは、SIPプライバシーヘッダーフィールドの履歴のプライベート値を定義しています。 <http://www.iana.org/assignments / sip-parameters>の "SIPプライバシーヘッダーフィールド値"サブレジストリに、SIPプライバシーヘッダーフィールドの登録用に次の更新が行われました。
Privacy
Type Description Registrant Reference
------ ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC7044]
History-Info header mary.ietf.barnes@gmail.com
field(s)
This specification defines the following new SIP header field parameters in the "Header Field Parameters and Parameter Values" sub-registry in <http:/www.iana.org/assignments/sip-parameters>.
この仕様では、<http：/www.iana.org/assignments/sip-parameters>の「Header Field Parameters and Parameter Values」サブレジストリで、次の新しいSIPヘッダーフィールドパラメータを定義しています。
Header Field Parameter Name Predefined Values Reference
------------- -------------- ----------------- ---------
History-Info mp No [RFC7044]
History-Info rc No [RFC7044]
History-Info np No [RFC7044]
Contact mp No [RFC7044]
Contact rc No [RFC7044]
Contact np No [RFC7044]
Jonathan Rosenberg et al. produced the document that provided additional use cases precipitating the requirement for the new header parameters to capture the method by which a Request-URI is determined. The authors would like to acknowledge the constructive feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel Kaplan, Marianne Mohali, Brett Tate, and Dale Worley. John Elwell also provided excellent suggestions in terms of document structure. Dan Romascanu performed the Gen-ART review.
ジョナサン・ローゼンバーグ他Request-URIが決定されるメソッドをキャプチャするための新しいヘッダーパラメータの要件を明確にする追加のユースケースを提供するドキュメントを作成しました。著者は、Ian Elz、Paul Kyzivat、John Elwell、Hadriel Kaplan、Marianne Mohali、Brett Tate、およびDale Worleyから提供された建設的なフィードバックを認めたいと思います。 John Elwellは、ドキュメント構造の点でも優れた提案をしました。 Dan RomascanuがGen-ARTレビューを行いました。
Mark Watson, Cullen Jennings, and Jon Peterson provided significant input into the initial work that resulted in the development of [RFC4244]. The authors would like to acknowledge the constructive feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and Sebastien Garcin in the development of [RFC4244].
Mark Watson、Cullen Jennings、およびJon Petersonは、[RFC4244]の開発につながった初期の作業に重要な情報を提供しました。著者は、Robert Sparks、Paul Kyzivat、Scott Orton、John Elwell、Nir Chen、Palash Jain、Brian Stucker、Norma Ng、Anthony Brown、Jayshree Bharatia、Jonathan Rosenberg、Eric Burger、Martin Dollyから提供された建設的なフィードバックを認めたいと思います。 [RFC4244]の開発におけるRoland Jesske、澤田拓也、Sebastien Prouvost、Sebastien Garcin。
The authors would like to acknowledge the significant input from Rohan Mahy on some of the normative aspects of the ABNF for [RFC4244], particularly regarding security and the index (the need for it as well as its format).
著者は、[RFC4244]のABNFのいくつかの規範的な側面、特にセキュリティとインデックス（その必要性とそのフォーマット）に関するRohan Mahyからの重要な意見を認めたいと思います。
This RFC replaces [RFC4244].
このRFCは[RFC4244]を置き換えます。
Deployment experience with [RFC4244] over the years has shown a number of issues, warranting an update:
長年にわたる[RFC4244]の展開経験には、更新を保証する多くの問題が示されています。
o In order to make [RFC4244] work in "real life", one needs to make "assumptions" on how History-Info is used. For example, numerous implementations filter out many entries and only leave specific entries corresponding, for example, to first and last redirection. Since vendors use different rules, this causes significant interoperability issues.
o [RFC4244]を「実生活」で機能させるためには、History-Infoの使用方法について「仮定」を行う必要があります。たとえば、多くの実装では多くのエントリが除外され、特定のエントリのみが、たとえば最初と最後のリダイレクトに対応したままになります。ベンダーは異なるルールを使用しているため、相互運用性に関する重大な問題が発生します。
o [RFC4244] is overly permissive and evasive about recording entries, causing interoperability issues.
o [RFC4244]は、エントリの記録に関して過度に許容的で回避的であり、相互運用性の問題を引き起こしています。
o The examples in the call flows had errors and were confusing because they often assume "loose routing".
o コールフローの例にはエラーがあり、「ルーズルーティング」を想定することが多いため、混乱を招きました。
o [RFC4244] has lots of repetitive and unclear text due to the combination of requirements with the solution.
o [RFC4244]には、要件とソリューションの組み合わせにより、反復的で不明確なテキストがたくさんあります。
o [RFC4244] gratuitously mandates the use of TLS on every hop. No existing implementation enforces this rule, and instead, whether to use TLS is a general SIP issue, not an issue with [RFC4244] per se.
o [RFC4244]当然のことながら、すべてのホップでのTLSの使用を義務付けています。既存の実装はこのルールを適用せず、代わりに、TLSを使用するかどうかはSIPの一般的な問題であり、[RFC4244]自体の問題ではありません。
o [RFC4244] does not include clear procedures on how to deliver current target URI information to the UAS when the Request-URI is replaced with a contact.
o [RFC4244]には、Request-URIが連絡先に置き換えられたときに、現在のターゲットURI情報をUASに配信する方法に関する明確な手順は含まれていません。
o [RFC4244] does not allow for marking History-Info entries for easy processing by user agents.
o [RFC4244]は、ユーザーエージェントによる簡単な処理のためにHistory-Infoエントリをマークすることを許可していません。
The following summarizes the functional changes between this specification and [RFC4244]:
以下は、この仕様と[RFC4244]の間の機能変更を要約したものです。
1. Added header field parameters to capture the specific method by which a target is determined to facilitate processing by users of the History-Info header field entries. A specific header field parameter is captured for each of the target URIs as the target set is determined (per Section 16.5 of [RFC3261]). The header field parameter is used in both the History-Info and the Contact header fields.
1. History-Infoヘッダーフィールドエントリのユーザーによる処理を容易にするためにターゲットが決定される特定のメソッドをキャプチャするヘッダーフィールドパラメーターが追加されました。ターゲットセットが決定されると、特定のヘッダーフィールドパラメータが各ターゲットURIに対してキャプチャされます（[RFC3261]のセクション16.5に従って）。ヘッダーフィールドパラメータは、History-InfoおよびContactヘッダーフィールドの両方で使用されます。
2. Added a way to indicate a gap in History-Info by adding a nonnegative integer of "0".
2. 「0」の非負の整数を追加することにより、History-Infoのギャップを示す方法が追加されました。
3. Rather than recommending that entries be removed in the case of certain values of the Privacy header field, the entries are anonymized.
3. プライバシーヘッダーフィールドの特定の値の場合にエントリを削除することを推奨するのではなく、エントリは匿名化されます。
4. Updated the security section to be equivalent to the security recommendations for other SIP header fields inserted by intermediaries.
4. 仲介者によって挿入される他のSIPヘッダーフィールドのセキュリティ推奨事項と同等になるようにセキュリティセクションを更新しました。
5. Removed Appendix B ("Voicemail") since a separate call flow document is being published as a companion to this document.
5. 別のコールフロードキュメントがこのドキュメントのコンパニオンとして公開されているため、付録B（「ボイスメール」）を削除しました。
The first two changes are intended to facilitate application usage of the History-Info header field and eliminate the need to make assumptions based upon the order of the entries and ensure that the most complete set of information is available to the applications.
最初の2つの変更は、アプリケーションによるHistory-Infoヘッダーフィールドの使用を容易にし、エントリの順序に基づいて仮定を行う必要をなくし、最も完全な情報のセットがアプリケーションで利用できるようにすることを目的としています。
In addition, editorial changes were done to both condense and clarify the text, moving the requirements to an appendix and removing the inline references to the requirements. The examples were simplified and updated to reflect the protocol changes. Several of the call flows in the appendix were removed and put into a separate document that includes additional use cases that require the new header field parameters.
さらに、テキストを要約および明確化するために編集上の変更が行われ、要件が付録に移動され、要件へのインライン参照が削除されました。例はプロトコルの変更を反映するように簡略化および更新されました。付録のコールフローのいくつかは削除され、新しいヘッダーフィールドパラメータを必要とする追加のユースケースを含む別のドキュメントに入れられました。
This specification is backwards compatible because [RFC4244] allows for the addition of new optional parameters. This specification adds an optional SIP header field parameter to the History-Info and Contact header fields. Entities that have not implemented this specification will ignore these parameters; however, per [RFC4244], an entity will not remove these parameters from an hi-entry. While entities compliant to this document and [RFC4244] must be able to recognize gaps in the hi-entries, this document requires that an index of "0" be used in this case. In comparison, [RFC4244] recommended (but did not require) the use of "1". However, since the ABNF in [RFC4244] defines the index as a DIGIT, "0" would be a valid value; thus, an [RFC4244] implementation should not have an issue if it receives hi-entries added by intermediaries compliant to this document.
[RFC4244]では新しいオプションのパラメータを追加できるため、この仕様には下位互換性があります。この仕様は、オプションのSIPヘッダーフィールドパラメーターをHistory-InfoおよびContactヘッダーフィールドに追加します。この仕様を実装していないエンティティは、これらのパラメーターを無視します。ただし、[RFC4244]に従い、エンティティはこれらのパラメータをhi-entryから削除しません。このドキュメントと[RFC4244]に準拠するエンティティはhi-entriesのギャップを認識できる必要がありますが、このドキュメントでは、この場合「0」のインデックスを使用する必要があります。対照的に、[RFC4244]は "1"の使用を推奨しました（ただし必須ではありませんでした）。ただし、[RFC4244]のABNFはインデックスをDIGITとして定義しているため、「0」が有効な値になります。したがって、[RFC4244]の実装は、このドキュメントに準拠した仲介者によって追加されたhi-entriesを受信する場合、問題はありません。
As for the behavior of the UACs, UASs, and intermediaries, the following additional normative changes have been made:
UAC、UAS、および仲介者の動作については、次の追加の規範的な変更が行われました。
UAC behavior
UACの動作
1. Inclusion of option tag by UAC has changed from SHOULD to MUST.
1. UACによるオプションタグの組み込みは、SHOULDからMUSTに変更されました。
2. Inclusion of hi-target-entry along with hi-index has changed from MAY/RECOMMEND to MUST/MUST.
2. hi-target-entryとhi-indexを含めることは、MAY / RECOMMENDからMUST / MUSTに変更されました。
3. Behavior surrounding the addition of hi-target-entry based on a 3xx response has changed from MAY/SHOULD to MUST.
3. 3xx応答に基づくhi-target-entryの追加に関する動作は、MAY / SHOULDからMUSTに変更されました。
None of the behavior changes will cause any backward or forward compatibility issues.
動作の変更によって、下位互換性または上位互換性の問題が発生することはありません。
UAS behavior
UASの動作
1. Inclusion of hi-entry in response has changed from SHOULD to MUST.
1. 応答にhi-entryを含めることは、SHOULDからMUSTに変更されました。
As the entity receiving response with hi-entry expected it with SHOULD, this change will not cause any backward compatibility issues.
hi-entryで応答を受信するエンティティはSHOULDでそれを期待していたので、この変更は下位互換性の問題を引き起こしません。
Proxy/redirect server behavior
プロキシ/リダイレクトサーバーの動作
1. Inclusion of the History-Info header field when forwarding the request has changed from SHOULD to MUST.
1. リクエストの転送時にHistory-Infoヘッダーフィールドを含めることは、SHOULDからMUSTに変更されました。
2. Association of Reason with timeout/internal reason has changed from MAY to MUST.
2. Reasonとタイムアウト/内部理由の関連付けは、MAYからMUSTに変更されました。
3. Inclusion of hi-index has changed from RECOMMENDED to MUST.
3. hi-indexを含めることは、RECOMMENDEDからMUSTに変更されました。
4. Inclusion of hi-entries in the response has changed from SHOULD to MUST.
4. 応答にhi-entriesを含めることは、SHOULDからMUSTに変更されました。
None of the above behavior changes impact backwards compatibility since they only strengthen normative behavior to improve interoperability.
上記の動作の変更は、相互運用性を改善するために規範的な動作を強化するだけなので、下位互換性に影響を与えません。
In cases where an entity that is compliant to this document receives a request that contains hi-entries compliant only to RFC 4244 (i.e., the hi-entries do not contain any of the new header field parameters), the entity MUST NOT add any of the new header field parameters to the hi-entries. The hi-entries MUST be cached and forwarded as any other entries are, as specified in Section 9.1. As with entities that are compliant to RFC 4244, applications must be able to function in cases of missing information, as specified in Section 11.
このドキュメントに準拠しているエンティティがRFC 4244にのみ準拠しているhi-entriesを含むリクエストを受け取った場合（つまり、hi-entriesに新しいヘッダーフィールドパラメータが含まれていない場合）、エンティティはhi-entriesへの新しいヘッダーフィールドパラメータ。セクション9.1で指定されているように、hi-entriesは他のエントリと同様にキャッシュして転送する必要があります。 RFC 4244に準拠するエンティティと同様に、セクション11で指定されているように、情報が欠落している場合でもアプリケーションは機能する必要があります。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[RFC3326] Schulzrinne、H.、Oran、D。、およびG. Camarillo、「セッション開始プロトコル（SIP）の理由ヘッダーフィールド」、RFC 3326、2002年12月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323] Peterson、J。、「Session Initiation Protocol（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244] Barnes、M。、「リクエスト履歴情報のためのセッション開始プロトコル（SIP）の拡張」、RFC 4244、2005年11月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェントURI（GRUU）を取得して使用する」、RFC 5627、2009年10月。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630]オーデットF.、「セッション開始プロトコル（SIP）でのSIPS URIスキームの使用」、RFC 5630、2009年10月。
[RFC3087] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
[RFC3087] Campbell、B。およびR. Sparks、「SIP Request-URIを使用したサービスコンテキストの制御」、RFC 3087、2001年4月。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240]バーガー、E。、ヴァンダイク、J。、およびA.スピッツァー、「SIPを使用した基本的なネットワークメディアサービス」、RFC 4240、2005年12月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinne、H。、「電話番号のtel URI」、RFC 3966、2004年12月。
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006.
[RFC4458] Jennings、C.、Audet、F。、およびJ. Elwell、「ボイスメールやインタラクティブ音声応答（IVR）などのアプリケーションのセッション開始プロトコル（SIP）URI」、RFC 4458、2006年4月。
[CALLFLOWS] Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. Holmberg, "Session Initiation Protocol (SIP) History-Info Header Call Flow Examples", Work in Progress, November 2013.
[CALLFLOWS] Barnes、M.、Audet、F.、Schubert、S.、Elburg、H.、C。Holmberg、「Session Initiation Protocol（SIP）History-Info Header Call Flow Examples」、Work in Progress、2013年11月。
The following list constitutes a set of requirements for a "Request History" capability.
次のリストは、「リクエスト履歴」機能の一連の要件を構成しています。
1. CAPABILITY-req: The "Request History" capability provides a capability to inform proxies and UAs involved in processing a request about the history/progress of that request. Although this is inherently provided when the retarget is in response to a SIP redirect, it is deemed useful for non-redirect retargeting scenarios, as well.
1. CAPABILITY-req：「リクエスト履歴」機能は、リクエストの処理に関与するプロキシとUAに、そのリクエストの履歴/進行状況を通知する機能を提供します。これは本質的に、リターゲットがSIPリダイレクトに応答するときに提供されますが、非リダイレクトのリターゲットシナリオにも役立ちます。
2. GENERATION-req: "Request History" information is generated when the request is retargeted.
2. GENERATION-req：「リクエスト履歴」情報は、リクエストが再ターゲットされるときに生成されます。
A. In some scenarios, it might be possible for more than one instance of retargeting to occur within the same proxy. A proxy MUST also generate "Request History" information for the 'internal retargeting'.
A.一部のシナリオでは、同じプロキシ内でリターゲティングの複数のインスタンスが発生する可能性があります。プロキシは、「内部リターゲティング」の「リクエスト履歴」情報も生成する必要があります。
B. An entity (UA or proxy) retargeting in response to a redirect or REFER MUST include any "Request History" information from the redirect/REFER in the new request.
B.リダイレクトまたはREFERに応答してリターゲットするエンティティ（UAまたはプロキシ）は、リダイレクト/ REFERからの「リクエスト履歴」情報を新しいリクエストに含める必要があります。
3. ISSUER-req: "Request History" information can be generated by a UA or proxy. It can be passed in both requests and responses.
3. ISSUER-req：「リクエスト履歴」情報は、UAまたはプロキシによって生成できます。リクエストとレスポンスの両方で渡すことができます。
4. CONTENT-req: The "Request History" information for each occurrence of retargeting shall include the following:
4. CONTENT-req：リターゲティングの発生ごとの「リクエスト履歴」情報には、以下が含まれます。
A. the new URI or address to which the request is in the process of being retargeted,
A.リクエストのリターゲット中の新しいURIまたはアドレス、
B. the URI or address from which the request was retargeted, and whether the retarget URI was an AOR,
B.リクエストがリターゲットされたURIまたはアドレス、およびリターゲットされたURIがAORであったかどうか
C. the mechanism by which the new URI or address was determined,
C.新しいURIまたはアドレスが決定されたメカニズム
D. the reason for the Request-URI or address modification, and
D.リクエストURIまたはアドレス変更の理由、および
E. chronological ordering of the "Request History" information.
E.「リクエスト履歴」情報の時系列順。
5. REQUEST-VALIDITY-req: "Request History" is applicable to requests not sent within an early or established dialog (e.g., INVITE, REGISTER, MESSAGE, and OPTIONS).
5. REQUEST-VALIDITY-req：「リクエスト履歴」は、早期または確立されたダイアログ内で送信されなかったリクエストに適用されます（例：INVITE、REGISTER、MESSAGE、およびOPTIONS）。
6. BACKWARDS-req: "Request History" information may be passed from the generating entity backwards towards the UAC. This is needed to enable services that inform the calling party about the dialog establishment attempts.
6. BACKWARDS-req：「リクエスト履歴」情報は、生成エンティティからUACに向かって逆方向に渡される場合があります。これは、ダイアログの確立の試みについて発呼者に通知するサービスを有効にするために必要です。
7. FORWARDS-req: "Request History" information may also be included by the generating entity in the request, if it is forwarded onwards.
7. FORWARDS-req：「リクエスト履歴」情報は、転送される場合、生成エンティティによってリクエストに含まれることもあります。
The "Request History" information is being inserted by a network element retargeting a request, resulting in a slightly different problem than the basic SIP header problem, thus requiring specific consideration. It is recognized that these security requirements can be generalized to a basic requirement of being able to secure information that is inserted by proxies.
「リクエスト履歴」情報は、リクエストをリターゲットするネットワーク要素によって挿入されているため、基本的なSIPヘッダーの問題とは少し異なる問題が発生するため、特別な考慮が必要です。これらのセキュリティ要件は、プロキシによって挿入される情報を保護できるという基本的な要件に一般化できることが認識されています。
The potential security problems include the following:
潜在的なセキュリティの問題には、次のものがあります。
1. A rogue application could insert a bogus Request History-Info entry by either adding an additional hi-entry as a result of retargeting or entering invalid information.
1. 不正なアプリケーションは、リターゲティングの結果としてhi-entryを追加するか、無効な情報を入力することにより、偽のRequest History-Infoエントリを挿入する可能性があります。
2. A rogue application could rearrange the "Request History" information to change the nature of the end application or to mislead the receiver of the information.
2. 不正なアプリケーションが「リクエスト履歴」情報を再配置して、エンドアプリケーションの性質を変更したり、情報の受信者を誤解させたりする可能性があります。
3. A rogue application could delete some or all of the "Request History" information.
3. 不正なアプリケーションにより、「リクエスト履歴」情報の一部またはすべてが削除される可能性があります。
Thus, a security solution for "Request History" must meet the following requirements:
したがって、「リクエスト履歴」のセキュリティソリューションは、次の要件を満たす必要があります。
1. SEC-req-1: The entity receiving the "Request History" must be able to determine whether any of the previously added "Request History" content has been altered.
1. SEC-req-1：「リクエスト履歴」を受信するエンティティは、以前に追加された「リクエスト履歴」コンテンツのいずれかが変更されたかどうかを判断できる必要があります。
2. SEC-req-2: The ordering of the "Request History" information must be preserved at each instance of retargeting.
2. SEC-req-2：リリクエストの各インスタンスで「リクエスト履歴」情報の順序を維持する必要があります。
3. SEC-req-3: The entity receiving the information conveyed by the "Request History" must be able to authenticate the entity providing the request.
3. SEC-req-3：「リクエスト履歴」によって伝えられた情報を受信するエンティティは、リクエストを提供するエンティティを認証できる必要があります。
4. SEC-req-4: To ensure the confidentiality of the "Request History" information, only entities that process the request SHOULD have visibility to the information.
4. SEC-req-4：「リクエスト履歴」情報の機密性を確保するために、リクエストを処理するエンティティのみが情報の可視性を持っている必要があります。
It should be noted that these security requirements apply to any entity making use of the "Request History" information.
これらのセキュリティ要件は、「リクエスト履歴」情報を利用するすべてのエンティティに適用されることに注意してください。
Since the Request-URI that is captured could inadvertently reveal information about the originator, there are general privacy requirements that MUST be met:
キャプチャされたRequest-URIが誤って発信者に関する情報を明らかにする可能性があるため、満たさなければならない一般的なプライバシー要件があります。
1. PRIV-req-1: The entity retargeting the request must ensure that it maintains the network-provided privacy (as described in [RFC3323]) associated with the request as it is retargeted.
1. PRIV-req-1：リクエストをリターゲットするエンティティは、リクエストがリターゲットされるときに、リクエストに関連付けられたネットワーク提供のプライバシー（[RFC3323]で説明）を維持する必要があります。
2. PRIV-req-2: The entity receiving the "Request History" must maintain the privacy associated with the information. In addition, local policy at a proxy may identify privacy requirements associated with the Request-URI being captured in the "Request History" information.
2. PRIV-req-2：「リクエスト履歴」を受信するエンティティは、情報に関連付けられたプライバシーを維持する必要があります。さらに、プロキシのローカルポリシーは、「リクエスト履歴」情報にキャプチャされているリクエストURIに関連するプライバシー要件を特定する場合があります。
3. PRIV-req-3: "Request History" information subject to privacy shall not be included in outgoing messages unless it is protected as described in [RFC3323].
3. PRIV-req-3：プライバシーの対象となる「リクエスト履歴」情報は、[RFC3323]で説明されているように保護されていない限り、送信メッセージに含まれません。
Authors' Addresses
著者のアドレス
Mary Barnes Polycom TX US
メアリーバーンズポリコムTX US
EMail: mary.ietf.barnes@gmail.com
Francois Audet Skype
フランソワ・オーデ・スカイプ
EMail: francois.audet@skype.net
Shida Schubert NTT
志田シューベルトNTT
EMail: shida@ntt-at.com
Hans Erik van Elburg Detecon International Gmbh Sternengasse 14-16 Cologne Germany
Hans Erik van Elburg Detecon International GmbH Sternengasse 14-16ケルンドイツ
EMail: ietf.hanserik@gmail.com
Christer Holmberg Ericsson Hirsalantie 11, Jorvas Finland
Christer Holmberg Ericsson Hirsalantie 11、ヨルヴァスフィンランド
EMail: christer.holmberg@ericsson.com