[要約] RFC 4244は、SIPの拡張であり、リクエスト履歴情報を提供するためのものです。目的は、SIPセッションの履歴情報を追跡し、ネットワークのトラブルシューティングやパフォーマンスの改善を支援することです。
Network Working Group M. Barnes, Ed.
Request for Comments: 4244 Nortel
Category: Standards Track November 2005
An Extension to the Session Initiation Protocol (SIP) for Request History Information
リクエスト履歴情報のセッション開始プロトコル（SIP）の拡張
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
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 call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests.
このドキュメントでは、セッション開始プロトコル（SIP）要求に関連する履歴情報を取得するための標準メカニズムを定義しています。この機能により、特定のアプリケーションまたはユーザーに通話がどのように、なぜ到着したかに関する情報を提供することにより、多くの拡張サービスが可能になります。このドキュメントでは、リクエストの履歴情報をキャプチャするための新しいオプションのSIPヘッダーHistory-Infoを定義します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Overview ...................................................2
1.2. Conventions Used in This Document ..........................3
1.3. Background: Why define a Generic "Request History"
capability? ................................................3
2. "Request History" Requirements ..................................4
2.1. Security Requirements ......................................6
2.2. Privacy Requirements .......................................7
3. Request History Information Description .........................7
3.1. Optionality of History-Info ................................8
3.2. Securing History-Info ......................................8
3.3. Ensuring the Privacy of History-Info .......................9
4. Request History Information Protocol Details ....................9
4.1. Protocol Structure of History-Info ........................10
4.2. Protocol Examples .........................................11
4.3. Protocol Usage ............................................12
4.3.1. User Agent Client (UAC) Behavior ...................12
4.3.2. User Agent Server (UAS) Behavior ...................13
4.3.3. Proxy Behavior .....................................13
4.3.4. Redirect Server Behavior ...........................18
4.4. Security for History-Info .................................18
4.5. Example Applications Using History-Info ...................19
4.5.1. Example with Privacy Header for Entire
Request at Proxy2 ..................................21
4.5.2. Example with Privacy Header for Specific
URI (UA4) at Proxy2 ................................22
5. Application Considerations .....................................24
6. Security Considerations ........................................25
7. IANA Considerations ............................................25
7.1. Registration of New SIP History-Info Header ...............25
7.2. Registration of "history" for SIP Privacy Header ..........26
8. Normative References ...........................................26
9. Informative References .........................................26
10. Acknowledgements ..............................................26
11. Contributors' Addresses .......................................27
Appendix. Example Scenarios........................................28
Appendix A. Sequentially forking (History-Info in Response).....28
Appendix B. Voicemail...........................................34
Appendix C. Automatic Call Distribution Example.................39
Appendix D. Session via Redirect and Proxy Servers..............41
Many services that SIP is anticipated to support require the ability to determine why and how the call 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 redirect/retarget capabilities that enable calls to be routed to chosen applications, there is currently no standard mechanism within SIP for communicating the history of such a request. This "request history" information allows the receiving application to determine hints about how and why the call arrived at the application/user.
SIPがサポートすると予想される多くのサービスには、特定のアプリケーションにコールが到着した理由と方法を判別する機能が必要です。このようなサービスの例には、Webページの「クリックツートーク」SIP Uniform Resource Locators（URL）を介してコールセンターに開始されたセッション、インテリジェントな「通話管理」ソフトウェア内の「通話履歴/ロギング」スタイルのサービスが含まれます（ただしこれらに限定されません）。 SIPユーザーエージェント（UA）、およびボイスメールサーバーへの呼び出し。 SIPは暗黙的にリダイレクト/リターゲット機能を提供し、コールを選択したアプリケーションにルーティングできるようにしますが、現在のところ、そのような要求の履歴を通信するためのSIP内の標準メカニズムはありません。この「リクエスト履歴」情報により、受信側アプリケーションは、コールがアプリケーション/ユーザーに到着した方法と理由に関するヒントを判断できます。
This document defines a new SIP header, 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. The History-Info header provides a building block for development of new services.
このドキュメントでは、新しいSIPヘッダーであるHistory-Infoを定義して、リクエスト履歴情報をキャプチャしてネットワークとエンドユーザーにさまざまなサービスを提供するための標準的なメカニズムを提供します。 History-Infoヘッダーは、新しいサービスを開発するためのビルディングブロックを提供します。
Section 1.3 provides additional background motivation for the Request History capability. Section 2 identifies the requirements for a solution, with Section 3 providing an overall description of the solution.
セクション1.3は、リクエスト履歴機能の追加の背景動機を提供します。セクション2はソリューションの要件を識別し、セクション3はソリューションの全体的な説明を提供します。
Section 4 provides the details of the additions to the SIP protocol. Example uses of the new header are included in Section 4.5, with additional scenarios included in the Appendix.
セクション4では、SIPプロトコルへの追加の詳細について説明します。新しいヘッダーの使用例はセクション4.5に含まれ、追加のシナリオは付録に含まれています。
Section 5 summarizes the application considerations identified in the previous sections. Section 6 summarizes the security solution.
セクション5では、前のセクションで特定したアプリケーションの考慮事項を要約します。セクション6では、セキュリティソリューションの概要を説明します。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
SIP implicitly provides redirect/retarget capabilities that enable calls to be routed to specific applications as defined in [RFC3261]. The term 'retarget' will be used henceforth in this document to refer to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request and thus changing the target of the request. This term is chosen to avoid associating this request history only with the specific SIP Redirect Server capability that provides for a response to be sent back to a UAC requesting that the UAC should retarget the original request to an alternate URI. The rules for determining request targets as described in Section 16.5 of [RFC3261] are consistent with the use of the retarget term in this document.
SIPは、[RFC3261]で定義されているように、コールを特定のアプリケーションにルーティングできるようにするリダイレクト/リターゲット機能を暗黙的に提供します。 「リターゲット」という用語は、このドキュメントでは今後、プロキシサーバー/ユーザーエージェントクライアント（UAC）がリクエストのURI（Uniform Resource Identifier）を変更し、リクエストのターゲットを変更するプロセスを指すために使用されます。この用語は、UACが元の要求を代替URIに再ターゲットするよう要求する応答をUACに送り返す応答を提供する特定のSIPリダイレクトサーバー機能のみとこの要求履歴を関連付けないようにするために選択されます。 [RFC3261]のセクション16.5で説明されている要求ターゲットを決定するためのルールは、このドキュメントでの再ターゲット用語の使用と一致しています。
The motivation for the request history is that in the process of retargeting, old routing information can be forever lost. This lost information may be important history that allows elements to which the call is retargeted to process the call in a locally defined, application-specific manner. The proposal in this document is to provide a mechanism for transporting the request history. It is not proposing any application-specific behavior for a Proxy or UA upon receipt of the information. Indeed, such behavior should be a local decision for the recipient application.
リクエスト履歴の動機は、リターゲティングの過程で、古いルーティング情報が永久に失われる可能性があることです。この失われた情報は、コールが再ターゲットされる要素がローカルに定義されたアプリケーション固有の方法でコールを処理できるようにする重要な履歴である可能性があります。このドキュメントの提案は、リクエスト履歴を転送するメカニズムを提供することです。情報の受信時に、プロキシまたはUAにアプリケーション固有の動作を提案するものではありません。実際、そのような動作は、受信側アプリケーションにとってローカルな決定である必要があります。
Current network applications provide the ability for elements involved with the call to exchange additional information relating to how and why the call 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 forwarding whereby the forwarded-to user obtains a "history" of who sent the email to whom and at what time
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. (Note that the diagnostic utility of this mechanism is limited by the fact that its use by entities that retarget is optional.)
o SIPリクエストをデバッグするためのいくつかの診断情報。 （このメカニズムの診断ユーティリティは、リターゲットするエンティティによる使用がオプションであることにより制限されていることに注意してください。）
o A stronger security solution for SIP. A side effect is that each proxy that captures the "request history" information in a secure manner provides an additional means (without requiring signed keys) for the original requestor to be assured that the request was properly retargeted.
o SIPのより強力なセキュリティソリューション。副作用として、「リクエスト履歴」情報を安全にキャプチャする各プロキシは、元のリクエスタがリクエストが適切に再ターゲットされたことを保証するための追加の手段（署名付きキーを必要としない）を提供します。
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) OPTIONALITY-req: The "Request History" information is optional.
2）OPTIONALITY-req：「リクエスト履歴」情報はオプションです。
2.1) In many cases, it is anticipated that whether the history is added to the Request would be a local policy decision enforced by the specific application; thus, no specific protocol element is needed.
2.1）多くの場合、履歴が要求に追加されるかどうかは、特定のアプリケーションによって実施されるローカルポリシー決定であると予想されます。したがって、特定のプロトコル要素は必要ありません。
2.2) Due to the capability being "optional" from the SIP protocol perspective, the impact to an application of not having the "Request History" must be described. Applicability guidelines to be addressed by applications using this capability must be provided as part of the solution to these requirements.
2.2）SIPプロトコルの観点からは「オプション」の機能であるため、「リクエスト履歴」がないことによるアプリケーションへの影響を説明する必要があります。この機能を使用するアプリケーションが取り組む適用性ガイドラインは、これらの要件に対するソリューションの一部として提供する必要があります。
3) GENERATION-req: "Request History" information is generated when the request is retargeted.
3）GENERATION-req：「リクエスト履歴」情報は、リクエストが再ターゲットされるときに生成されます。
3.1) In some scenarios, it might be possible for more than one instance of retargeting to occur within the same Proxy. A proxy should also generate Request History information for the 'internal retargeting'.
3.1）一部のシナリオでは、同じプロキシ内でリターゲティングの複数のインスタンスが発生する可能性があります。プロキシは、「内部リターゲティング」のリクエスト履歴情報も生成する必要があります。
3.2) An entity (UA or proxy) retargeting in response to a redirect or REFER should include any Request History information from the redirect/REFER in the new request.
3.2）リダイレクトまたはREFERに応答してターゲットを変更するエンティティ（UAまたはプロキシ）は、リダイレクト/ REFERからのリクエスト履歴情報を新しいリクエストに含める必要があります。
4) ISSUER-req: "Request History" information can be generated by a UA or proxy. It can be passed in both requests and responses.
4）ISSUER-req：「リクエスト履歴」情報は、UAまたはプロキシによって生成できます。リクエストとレスポンスの両方で渡すことができます。
5) CONTENT-req: The "Request History" information for each occurrence of retargeting shall include the following:
5）CONTENT-req：リターゲティングの発生ごとの「リクエスト履歴」情報には、以下が含まれます。
5.1) The new URI or address to which the request is in the process of being retargeted,
5.1）リクエストがリターゲットされる過程にある新しいURIまたはアドレス、
5.2) The URI or address from which the request was retargeted,
5.2）リクエストが再ターゲットされたURIまたはアドレス、
5.3) The reason for the Request-URI or address modification,
5.3）リクエストURIまたはアドレス変更の理由、
5.4) Chronological ordering of the Request History information.
5.4）リクエスト履歴情報の年代順。
6) REQUEST-VALIDITY-req: Request History is applicable to requests not sent within an established dialog (e.g., INVITE, REGISTER, MESSAGE, and OPTIONS).
6）REQUEST-VALIDITY-req：リクエスト履歴は、確立されたダイアログ内で送信されないリクエストに適用できます（例：INVITE、REGISTER、MESSAGE、およびOPTIONS）。
7) 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.
7）BACKWARDS-req：リクエスト履歴情報は、生成エンティティからUACに向かって逆方向に渡される場合があります。これは、ダイアログの確立の試みについて発呼者に通知するサービスを有効にするために必要です。
8) FORWARDS-req: Request History information may also be included by the generating entity in the request, if it is forwarded onwards.
8）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 entry either by adding an additional entry as a result of retargeting or entering invalid information.
1）不正なアプリケーションが、リターゲティングの結果として追加のエントリを追加するか、無効な情報を入力することにより、偽のリクエスト履歴エントリを挿入する可能性があります。
2) A rogue application could re-arrange 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, either by retargeting and capturing the information, or as an application making use of the information received in either a Request or Response.
これらのセキュリティ要件は、情報をリターゲットしてキャプチャするか、リクエストまたはレスポンスで受信した情報を利用するアプリケーションとして、リクエスト履歴情報を利用するエンティティに適用されることに注意してください。
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.
2）PRIV-req-2：リクエスト履歴を受信するエンティティは、情報に関連付けられたプライバシーを維持する必要があります。
In addition, local policy at a proxy may identify privacy requirements associated with the Request-URI being captured in the Request History information.
さらに、プロキシのローカルポリシーは、リクエスト履歴情報にキャプチャされているリクエストURIに関連するプライバシー要件を特定する場合があります。
3) PRIV-req-3: Request History information subject to privacy requirements shall not be included in outgoing messages unless it is protected as described in [RFC3323].
3）PRIV-req-3：プライバシー要件の対象となるリクエスト履歴情報は、[RFC3323]で説明されているように保護されていない限り、送信メッセージに含めないでください。
The fundamental functionality provided by the request history information is the ability to inform proxies and UAs involved in processing a request about the history or progress of that request (CAPABILITY-req). The solution is to capture the Request-URIs as a request is forwarded in a new header for SIP messages: History-Info (CONTENT-req). This allows for the capturing of the history of a request that would be lost with the normal SIP processing involved in the subsequent forwarding of the request. This solution proposes no changes in the fundamental determination of request targets or in the request forwarding as defined in Sections 16.5 and 16.6 of the SIP protocol specification [RFC3261].
要求履歴情報によって提供される基本的な機能は、要求の処理に関与するプロキシとUAに、その要求の履歴または進行状況を通知する機能です（CAPABILITY-req）。解決策は、リクエストがSIPメッセージの新しいヘッダーであるHistory-Info（CONTENT-req）で転送されるときに、Request-URIをキャプチャすることです。これにより、後続の要求の転送に関連する通常のSIP処理で失われる要求の履歴をキャプチャできます。このソリューションは、SIPプロトコル仕様[RFC3261]のセクション16.5および16.6で定義されているように、要求ターゲットの基本的な決定または要求転送に変更を提案していません。
The History-Info header can appear in any request not associated with an established dialog (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) (REQUEST-VALIDITY-req) and any valid response to these requests (ISSUER-req).
History-Infoヘッダーは、確立されたダイアログに関連付けられていないリクエスト（例：INVITE、REGISTER、MESSAGE、REFERとOPTIONS、PUBLISHとSUBSCRIBEなど）（REQUEST-VALIDITY-req）とこれらのリクエストに対する有効な応答に表示されます。 （ISSUER-req）。
The History-Info header is added to a Request when a new request is created by a UAC or forwarded by a Proxy, or when the target of a request is changed. The term 'retarget' is introduced to refer to this changing of the target of a request and the subsequent forwarding of that request. It should be noted that retargeting only occurs when the Request-URI indicates a domain for which the processing entity is responsible. In terms of the SIP protocol, the processing associated with retargeting is described in Sections 16.5
History-Infoヘッダーは、UACによって新しい要求が作成されたとき、またはプロキシによって転送されたとき、または要求のターゲットが変更されたときに、要求に追加されます。 「リターゲット」という用語は、リクエストのターゲットのこの変更とその後のそのリクエストの転送を指すために導入されています。リターゲットは、Request-URIが処理エンティティが担当するドメインを示している場合にのみ発生することに注意してください。 SIPプロトコルの観点から、リターゲティングに関連する処理はセクション16.5で説明されています。
and 16.6 of [RFC3261]. As described in Section 16.5 of [RFC3261], it is possible for the target of a request to be changed by the same proxy multiple times (referred to as 'internal retargeting' in Section 2), as the proxy MAY add targets to the target set after beginning Request Forwarding. Section 16.6 of [RFC3261] describes Request Forwarding. It is during this process of Request Forwarding that the History Information is captured as an optional, additional header field. Thus, the addition of the History-Info header does not impact fundamental SIP Request Forwarding. An entity (UA or proxy) changing the target of a request in response to a redirect or REFER SHOULD also propagate any History-Info header from the initial Request in the new request (GENERATION-req, FORWARDS-req).
[RFC3261]の16.6。 [RFC3261]のセクション16.5で説明されているように、プロキシはターゲットにターゲットを追加できるため、リクエストのターゲットが同じプロキシによって複数回変更される可能性があります（セクション2では「内部リターゲティング」と呼ばれます）。リクエスト転送の開始後に設定されます。 [RFC3261]のセクション16.6は、リクエストの転送について説明しています。この要求転送のプロセス中に、履歴情報がオプションの追加ヘッダーフィールドとしてキャプチャされます。したがって、History-Infoヘッダーの追加は、基本的なSIP要求転送に影響を与えません。リダイレクトまたはREFERに応じてリクエストのターゲットを変更するエンティティ（UAまたはプロキシ）も、新しいリクエスト（GENERATION-req、FORWARDS-req）の最初のリクエストからHistory-Infoヘッダーを伝播します。
The History-Info header is optional in that neither UAs nor Proxies are required to support it. A new Supported header, "histinfo", is included in the Request to indicate whether the History-Info header is returned in Responses (BACKWARDS-req). In addition to the "histinfo" Supported header, local policy determines whether or not the header is added to any request, or for a specific Request-URI, being retargeted. It is possible that this could restrict the applicability of services that make use of the Request History Information to be limited to retargeting within domain(s) controlled by the same local policy, or between domain(s) which negotiate policies with other domains to ensure support of the given policy, or services for which complete History Information isn't required to provide the service (OPTIONALITY-req). All applications making use of the History-Info header MUST clearly define the impact of the information not being available and specify the processing of such a request.
History-Infoヘッダーは、UAもプロキシもそれをサポートする必要がないという点でオプションです。新しいサポートヘッダー「histinfo」がリクエストに含まれ、History-Infoヘッダーが応答で返されるかどうかを示します（BACKWARDS-req）。 「histinfo」のサポートされているヘッダーに加えて、ローカルポリシーは、ヘッダーが任意の要求に追加されるかどうか、または特定のRequest-URIに追加されるかどうかを決定します。これにより、リクエスト履歴情報を利用するサービスの適用範囲が、同じローカルポリシーによって制御されるドメイン内、または他のドメインとポリシーをネゴシエートするドメイン間のリターゲティングに制限される可能性があります。指定されたポリシーのサポート、またはサービスを提供するために完全な履歴情報を必要としないサービス（OPTIONALITY-req）。 History-Infoヘッダーを使用するすべてのアプリケーションは、利用できない情報の影響を明確に定義し、そのような要求の処理を指定する必要があります。
This document defines a new header for SIP. The use of the Transport Layer Security (TLS) protocol [RFC2246] as a mandatory mechanism to ensure the overall confidentiality of the History-Info headers (SEC-req-4) is strongly RECOMMENDED. This results in History-Info having at least the same level of security as other headers in SIP that are inserted by intermediaries. If TLS is not available for the connection over which the request is being forwarded, then the request MUST NOT include the History-Info header or the request MUST be redirected to the client, including the History-Info header, so that the request can be retargeted by the client.
このドキュメントでは、SIPの新しいヘッダーを定義します。 History-Infoヘッダー（SEC-req-4）の全体的な機密性を確保するための必須メカニズムとしてのトランスポート層セキュリティ（TLS）プロトコル[RFC2246]の使用は強く推奨されます。これにより、History-Infoは、仲介者によって挿入されるSIPの他のヘッダーと少なくとも同じレベルのセキュリティを持つことになります。リクエストが転送されている接続でTLSが利用できない場合、リクエストにHistory-Infoヘッダーを含めないでください。または、リクエストをHistory-Infoヘッダーを含めてクライアントにリダイレクトする必要があるため、リクエストをクライアントによってリターゲットされました。
With the level of security provided by TLS (SEC-req-3), the information in the History-Info header can thus be evaluated to determine if information has been removed by evaluating the indices for gaps (SEC-req-1, SEC-req-2). It would be up to the application to define whether it can make use of the information in the case of missing entries.
TLSによって提供されるセキュリティレベル（SEC-req-3）では、History-Infoヘッダーの情報を評価して、ギャップのインデックスを評価することで情報が削除されたかどうかを判断できます（SEC-req-1、SEC-req req-2）。エントリが欠落している場合にその情報を利用できるかどうかを定義するのはアプリケーション次第です。
Note that while using the SIPS scheme 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スキームを使用すると、History-InfoがSIPメッセージパス外の任意のパーティによる改ざんから保護されますが、パス上のすべての仲介者は暗黙的に信頼されます。悪意のある仲介者が、History-Infoを任意に削除、書き換え、または変更する可能性があります。この仕様は、悪意のある仲介者による攻撃を防止または検出しようとするものではありません。
Since the History-Info header can inadvertently reveal information about the requestor as described in [RFC3323], the Privacy header SHOULD be used to determine whether an intermediary can include the History-Info header in a Request that it receives and forwards (PRIV-req-2) or that it retargets (PRIV-req-1). Thus, the History-Info header SHOULD NOT be included in Requests where the requestor has indicated a priv-value of Session- or Header-level privacy.
[RFC3323]で説明されているように、History-Infoヘッダーはリクエスタに関する情報を誤って明らかにする可能性があるため、プライバシーヘッダーを使用して、仲介者が受信して転送する要求にHistory-Infoヘッダーを含めることができるかどうかを判断する必要があります（PRIV-req -2）またはターゲットを変更する（PRIV-req-1）。したがって、History-Infoヘッダーは、リクエスタがセッションレベルまたはヘッダーレベルのプライバシーのプライベート値を示しているリクエストには含めないでください。
In addition, the History-Info header can reveal general routing information, which may be viewed by a specific intermediary or network, to be subject to privacy restrictions. Thus, local policy MAY also be used to determine whether to include the History-Info header at all, whether to capture a specific Request-URI in the header, or whether it be included only in the Request as it is retargeted within a specific domain (PRIV-req-3). In the latter case, this is accomplished by adding a new priv-value, history, to the Privacy header [RFC3323] indicating whether any or a specific History-Info header(s) SHOULD be forwarded.
さらに、History-Infoヘッダーは、特定の仲介者またはネットワークによって表示される可能性のある一般的なルーティング情報を明らかにし、プライバシー制限の対象となる場合があります。したがって、ローカルポリシーを使用して、History-Infoヘッダーをまったく含めるかどうか、ヘッダーに特定のRequest-URIをキャプチャするかどうか、または特定のドメイン内でターゲットを変更するときに、要求にのみ含めるかどうかを決定することもできます（PRIV-req-3）。後者の場合、これは、Privacyヘッダー[RFC3323]に新しいpriv-value、historyを追加することによって実行されます。転送されるのが特定のHistory-Infoヘッダーであるかどうかを示します。
It is recognized that satisfying the privacy requirements can impact the functionality of this solution by overriding the request to generate the information. As with the optionality and security requirements, applications making use of History-Info SHOULD address any impact this may have or MUST explain why it does not impact the application.
プライバシー要件を満たすことは、情報を生成する要求を上書きすることにより、このソリューションの機能に影響を与える可能性があることが認識されています。オプション性とセキュリティ要件と同様に、History-Infoを使用するアプリケーションは、これが及ぼす可能性のあるすべての影響に対処する必要があります。
This section contains the details and usage of the proposed new SIP protocol elements. It also discusses the security aspects of the solution.
このセクションには、提案された新しいSIPプロトコル要素の詳細と使用法が含まれています。また、ソリューションのセキュリティの側面についても説明します。
History-Info is a header field as defined by [RFC3261]. It is an optional header field and MAY appear in any request or response not associated with a dialog or which starts a dialog. For example, History-Info MAY appear in INVITE, REGISTER, MESSAGE, REFER, OPTIONS, SUBSCRIBE, and PUBLISH and any valid responses, plus NOTIFY requests that initiate a dialog.
History-Infoは、[RFC3261]で定義されているヘッダーフィールドです。これはオプションのヘッダーフィールドであり、ダイアログに関連付けられていない、またはダイアログを開始する要求または応答に表示される場合があります。たとえば、History-Infoは、INVITE、REGISTER、MESSAGE、REFER、OPTIONS、SUBSCRIBE、PUBLISH、および有効な応答に加えて、ダイアログを開始するNOTIFY要求に表示される場合があります。
This document adds the following entry to Table 2 of [RFC3261]. The additions to this table are also provided for extension methods at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way.
このドキュメントは、[RFC3261]の表2に次のエントリを追加します。この表への追加は、このドキュメントの公開時に拡張メソッドに対しても提供されます。これは読者への礼儀として提供されており、決して規範的ではありません。
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
History-Info amdr - - - o o o o
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
History-Info amdr o o o - - - o
The History-Info header carries the following information, with the mandatory parameters required when the header is included in a request or response:
History-Infoヘッダーには、ヘッダーが要求または応答に含まれている場合に必須の必須パラメーターとともに、次の情報が含まれています。
o Targeted-to-URI (hi-targeted-to-uri): A mandatory parameter for capturing the Request-URI for the specific Request as it is forwarded.
o Targeted-to-URI（hi-targeted-to-uri）：転送される特定のリクエストのリクエストURIをキャプチャするための必須パラメーター。
o Index (hi-index): A mandatory parameter for History-Info reflecting the chronological order of the information, indexed to also reflect the forking and nesting of requests. The format for this parameter is a string of digits, 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 branch of the tree. By adding the new entries in order (i.e., following existing entries per the details in Section 4.3.3.1), including the index and securing the header, the ordering of the History-Info headers in the request is assured (SEC-req-2). 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の必須パラメーター。リクエストの分岐とネストも反映するようにインデックスが付けられます。このパラメータの形式は、ドットで区切られた数字の文字列で、フォワードホップとリターゲットの数を示します。これにより、要求の履歴がツリーで表現され、最低レベルのインデックスがツリーのブランチを反映します。インデックスを含めて新しいエントリを順番に（つまり、セクション4.3.3.1の詳細に従って既存のエントリに従って）追加することにより、リクエスト内のHistory-Infoヘッダの順序が保証されます（SEC-req-2 ）。さらに、アプリケーションは、インデックス値に基づいて、さまざまなメトリック（リターゲットの総数、特定のブランチからのリターゲットの総数など）を抽出できます。
o Reason: An optional parameter for History-Info, reflected in the History-Info header by including the Reason Header [RFC3326] escaped in the hi-targeted-to-uri. A reason is not included for a hi-targeted-to-uri when it is first added in a History-Info header, but rather is added when the retargeting actually occurs. Note that this does appear to complicate the security problem; however, retargeting only occurs when the hi-targeted-to-uri indicates a domain for which the processing entity is responsible. Thus, it would be the same processing entity that initially added the hi-targeted-to-URI to the header that would be updating it with the Reason.
o理由：hi-targeted-to-uriでエスケープされた理由ヘッダー[RFC3326]を含めることにより、History-Infoヘッダーに反映されるHistory-Infoのオプションパラメーター。理由は、Hi-targeted-to-URIがHistory-Infoヘッダーに最初に追加されたときは含まれず、実際にリターゲットが発生したときに追加されます。これはセキュリティの問題を複雑にするように見えることに注意してください。ただし、リターゲティングは、hi-targeted-to-uriが処理エンティティが担当するドメインを示している場合にのみ発生します。したがって、理由を使用してヘッダーを更新するヘッダーにhi-targeted-to-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" escaped in the hi-targeted-to-uri or by adding the Privacy header with a priv-value of "history" to the Request. The use of the Privacy Header with a priv-value of "history" indicates whether a specific or all History-Info headers should not be forwarded.
o プライバシー：History-Infoのオプションパラメータ。hi-targeted-to-uriでエスケープされた「history」のプライベート値を持つプライバシーヘッダー[RFC3323]を含めるか、またはリクエストに対する「履歴」のプライベート値を持つプライバシーヘッダー。 priv-valueに "history"を指定したプライバシーヘッダーを使用すると、特定またはすべてのHistory-Infoヘッダーを転送しないようにする必要があります。
o Extension (hi-extension): An optional parameter to allow for future optional extensions. As per [RFC3261], any implementation not understanding an extension should ignore it.
o 拡張（hi-extension）：将来のオプションの拡張を可能にするオプションのパラメーター。 [RFC3261]に従い、拡張機能を理解していない実装はそれを無視する必要があります。
The following summarizes the syntax of the History-Info header, based upon the standard SIP syntax [RFC3261]:
以下は、標準のSIP構文[RFC3261]に基づくHistory-Infoヘッダーの構文をまとめたものです。
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-targeted-to-uri = name-addr
hi-param = hi-index / hi-extension
hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)
hi-extension = generic-param
The following provides some examples of the History-Info header. Note that the backslash and CRLF between the fields in the examples below are for readability purposes only.
以下に、History-Infoヘッダーの例をいくつか示します。以下の例のフィールド間のバックスラッシュとCRLFは、読みやすくするためのものです。
History-Info:<sip:UserA@ims.example.com?Reason=SIP%3B\
cause%3D302>;index=1;foo=bar
History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B \ cause%3D302>; index=1.1,
履歴情報：<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,
<sip:45432@vm.example.com>;index=1.3
This section describes the processing specific to UAs and Proxies for the History-Info header, the "histinfo" option tag, and the priv-value of "history". As discussed in Section 1.3, the fundamental objective is to capture the target Request-URIs as a request is forwarded. This allows for the capturing of the history of a request that would be lost due to subsequent (re)targeting and forwarding. To accomplish this for the entire history of a request, either the UAC must capture the Request-URI in a History-Info header in the initial request or a proxy must add a History-Info header with both a hi-entry for the Request-URI in the initial request and a hi-entry for the target Request-URI as the request is forwarded. The basic processing is for each entity forwarding a request to add a hi-entry for the target Request-URI, updating the index and adding the Reason as appropriate for any retargeted Request-URI.
このセクションでは、History-Infoヘッダー、 "histinfo"オプションタグ、および "history"のプライベート値のUAおよびプロキシに固有の処理について説明します。セクション1.3で説明したように、基本的な目的は、リクエストが転送されるときにターゲットのRequest-URIを取得することです。これにより、後続の（再）ターゲティングと転送が原因で失われるリクエストの履歴をキャプチャできます。要求の履歴全体でこれを実現するには、UACが最初の要求のHistory-InfoヘッダーでRequest-URIをキャプチャするか、プロキシがRequest-の両方のhi-entryを含むHistory-Infoヘッダーを追加する必要があります最初のリクエストのURIと、リクエストが転送されるときのターゲットRequest-URIのhi-entry。基本的な処理は、ターゲットリクエストURIのhi-entryを追加するリクエストを転送するエンティティごとに、インデックスを更新し、リターゲットされたリクエストURIに応じて理由を追加します。
The UAC SHOULD include the "histinfo" option tag in the Supported header in any request not associated with an established dialog for which the UAC would like the History-Info header in the response. In addition, the UAC MAY improve the diagnostic utility of its request by adding a History-Info header, using the Request-URI of the request as the hi-target-to-uri and initializing the index to the RECOMMENDED value of 1 in the hi-entry. As a result, intermediaries and the UAS will know at least the original Request-URI, and if the Request-URI was modified by a previous hop.
UACは、UACが応答のHistory-Infoヘッダーを必要とする確立されたダイアログに関連付けられていない要求のすべての要求で、Supportedヘッダーに「histinfo」オプションタグを含める必要があります（SHOULD）。さらに、UACは、Hi-target-to-URIとして要求のRequest-URIを使用し、インデックスをRECOMMENDED値1に初期化して、History-Infoヘッダーを追加することにより、その要求の診断ユーティリティを改善できます（MAY）。ハイエントリー。その結果、仲介者とUASは少なくとも元のRequest-URIを認識し、Request-URIが前のホップによって変更されたかどうかを認識します。
In the case where the request is routed to a redirect server and the UAC receives a 3xx response with a Contact header, the UAC MAY maintain the previous hi-entry(s) in the request. In this case, the reason header SHOULD be associated with the hi-targeted-to-uri in the previous (last) hi-entry, as described in Section 4.3.3.1.2. A new hi-entry MAY then be added for the URI from the Contact header (which becomes the new Request-URI). In this case, the index is created by reading and incrementing the value of the index from the previous hi-entry, thus following the same rules as those prescribed for a proxy in retargeting, described in Section 4.3.3.1.3. An example of this scenario can be found in Appendix D.
要求がリダイレクトサーバーにルーティングされ、UACがContactヘッダー付きの3xx応答を受信した場合、UACは要求内の以前のhi-entryを維持できます（MAY）。この場合、4.3.1.3.1.2で説明されているように、reasonヘッダーは前の（最後の）hi-entryのhi-targeted-to-uriに関連付けられる必要があります（SHOULD）。次に、新しいhi-entryがContactヘッダーのURIに追加される場合があります（これは新しいRequest-URIになります）。この場合、インデックスは、前のhi-entryからインデックスの値を読み取ってインクリメントすることによって作成されます。そのため、セクション4.3.3.1.3で説明されている、リターゲティングのプロキシに規定されているルールと同じルールに従います。このシナリオの例は、付録Dにあります。
A UAC that does not want the History-Info header added due to privacy considerations SHOULD include a Privacy header with a priv-value(s) of "session", "header", or "history" in the request.
プライバシーを考慮してHistory-Infoヘッダーを追加したくないUACには、リクエストに「session」、「header」、または「history」のpriv-valueを含むPrivacyヘッダーを含める必要があります。
With the exception of the processing of a 3xx response described above, the processing of the History-Info header received in the Response is application specific and outside the scope of this document. However, the validity of the information SHOULD be ensured prior to any application usage. For example, the entries MAY be evaluated to determine gaps in indices, which could indicate that an entry has been maliciously removed or removed for privacy reasons. Either way, an application MAY want to be aware of potentially missing information.
上記の3xx応答の処理を除いて、応答で受信されたHistory-Infoヘッダーの処理はアプリケーション固有であり、このドキュメントの範囲外です。ただし、情報の有効性は、アプリケーションを使用する前に確認する必要があります。たとえば、エントリがインデックスのギャップを判断するために評価される場合があります。これは、エントリが悪意を持って削除されたか、プライバシー上の理由で削除されたことを示している可能性があります。いずれにせよ、アプリケーションは潜在的に欠落している情報を認識したいと思うかもしれません。
The processing of the History-Info header by a UAS in a Request depends upon local policy and specific applications at the UAS that might make use of the information. Prior to any application usage of the information, the validity SHOULD be ascertained. For example, the entries MAY be evaluated to determine gaps in indices, which could indicate that an entry has been maliciously removed or removed for privacy reasons. Either way, an application MAY want to be aware of potentially missing information.
リクエスト内のUASによるHistory-Infoヘッダーの処理は、情報を利用する可能性のあるUASのローカルポリシーと特定のアプリケーションに依存します。情報をアプリケーションで使用する前に、有効性を確認する必要があります。たとえば、エントリがインデックスのギャップを判断するために評価される場合があります。これは、エントリが悪意を持って削除されたか、プライバシー上の理由で削除されたことを示している可能性があります。いずれにせよ、アプリケーションは潜在的に欠落している情報を認識したいと思うかもしれません。
If the "histinfo" option tag is received in a request, the UAS SHOULD include any History-Info received in the request in the subsequent response.
「histinfo」オプションタグがリクエストで受信された場合、UASは後続のレスポンスのリクエストで受信されたすべてのHistory-Infoを含める必要があります。
The inclusion of the History-Info header in a Request does not alter the fundamental processing of proxies for determining request targets as defined in Section 16.5 of [RFC3261]. Whether a proxy adds the History-Info header or a new hi-entry as it forwards a Request depends upon the following considerations:
[RFC3261]のセクション16.5で定義されているように、リクエストにHistory-Infoヘッダーを含めても、リクエストターゲットを決定するためのプロキシの基本的な処理は変わりません。リクエストを転送するときにプロキシがHistory-Infoヘッダーを追加するか、新しいhi-entryを追加するかは、次の考慮事項によって異なります。
1. Whether the Request contains the "histinfo" option tag in the Supported header. 2. Whether the proxy supports the History-Info header. 3. Whether the Request contains a Privacy header with a priv-value of "session", "header", or "history". 4. Whether any History-Info header added for a proxy/domain should go outside that domain. An example being the use of the History-Info header within the specific domain in which it is retargeted, however, policies (for privacy, user and network security, etc.) would prohibit the exposure of that information outside that domain. To accommodate such a scenario, a proxy MAY insert the Privacy header with a priv-value of "history" when the request is being forwarded within the same domain. An example of such an application is provided in Appendix C.
1. リクエストが、Supportedヘッダーに「histinfo」オプションタグを含むかどうか。 2.プロキシがHistory-Infoヘッダーをサポートするかどうか。 3.リクエストに、priv-valueが「session」、「header」、または「history」のプライバシーヘッダーが含まれているかどうか。 4.プロキシ/ドメインに追加されたHistory-Infoヘッダーがそのドメインの外に出る必要があるかどうか。例として、リターゲットされる特定のドメイン内でHistory-Infoヘッダーを使用する場合がありますが、ポリシー（プライバシー、ユーザー、ネットワークセキュリティなど）は、そのドメイン外への情報の公開を禁止します。そのようなシナリオに対応するために、リクエストが同じドメイン内で転送されている場合、プロキシは、「履歴」のpriv-valueでプライバシーヘッダーを挿入してもよい（MAY）。このようなアプリケーションの例を付録Cに示します。
5. Whether a hi-entry is added for a specific Request-URI due to local privacy policy considerations. A proxy MAY add the Privacy header with a priv-value of "history" associated with the specific hi-targeted-to-uri.
5. ローカルのプライバシーポリシーの考慮事項により、特定のRequest-URIにhi-entryが追加されるかどうか。プロキシは、特定のhi-targeted-to-uriに関連付けられた "history"のpriv-valueでプライバシーヘッダーを追加する場合があります。
An example policy would be a proxy that only adds the History-Info header if the "histinfo" option tag is in the Supported header. Other proxies may have a policy that they always add the header, but never forward it outside a particular domain, accomplishing this by adding a Privacy header with a priv-value of "history" to each hi-entry to allow the information to be collected for internal retargeting only.
ポリシーの例は、 "histinfo"オプションタグがSupportedヘッダーにある場合にのみHistory-Infoヘッダーを追加するプロキシです。他のプロキシには、常にヘッダーを追加するポリシーがありますが、特定のドメインの外には転送しないでください。これは、情報を収集できるように、各hi-entryにpriv-valueが「history」のプライバシーヘッダーを追加することで実現します。内部リターゲティングのみ。
Each application making use of the History-Info header SHOULD address the impacts of the local policies on the specific application (e.g., what specification of local policy is optimally required for a specific application and any potential limitations imposed by local policy decisions).
History-Infoヘッダーを使用する各アプリケーションは、特定のアプリケーションに対するローカルポリシーの影響に対処する必要があります（たとえば、特定のアプリケーションに必要なローカルポリシーの仕様と、ローカルポリシーの決定によって課される潜在的な制限）。
Consistent with basic SIP processing of optional headers, proxies SHOULD maintain the History-Info header(s), received in messages being forwarded, independent of whether local policy supports History-Info.
オプションのヘッダーの基本的なSIP処理と一貫して、プロキシは、ローカルポリシーがHistory-Infoをサポートするかどうかに関係なく、転送されるメッセージで受信されるHistory-Infoヘッダーを維持する必要があります（SHOULD）。
The specific processing by proxies for adding the History-Info headers in Requests and Responses, to accommodate the considerations outlined above, is described in detail in the following sections.
上記で概説した考慮事項に対応するために、リクエストとレスポンスにHistory-Infoヘッダーを追加するためのプロキシによる特定の処理について、次のセクションで詳しく説明します。
Upon evaluation of the considerations under which the History-Info header is to be included in requests (e.g., no Privacy header overriding inclusion, local policy supports, etc.), detailed in Section 4.3.3, a proxy SHOULD add a hi-entry as it forwards a Request. Section 16.6 of [RFC3261] defines the steps to be followed as the proxy forwards a Request. Step 5 prescribes the addition of optional headers. Although this would seem the appropriate step for adding the History-Info header, the interaction with Step 6, "Postprocess routing information", and the impact of a strict route in the Route header could result in the Request-URI being changed; thus, adding the History-Info header between Steps 8 (adding Via header) and 9 (adding Content-Length) is RECOMMENDED. Note that in the case of loose routing, the Request-URI does not change during the forwarding of a Request; thus, the capturing of History-Info for such a request would result in duplicate Request-URIs with different indices. The hi-entry MUST be added following any hi-entry received in the request being forwarded. Additionally, if a request is received that doesn't include a History-Info header, the proxy MAY add a History-Info header with a hi-entry preceding the one being added for the current request being forwarded. The index for this hi-entry is RECOMMENDED to start at 1. The following subsections define the details of creating the information associated with each hi-entry.
History-Infoヘッダーがリクエストに含まれる場合の考慮事項（たとえば、プライバシーヘッダーオーバーライドを含まないこと、ローカルポリシーのサポートなど）を評価すると、セクション4.3.3で詳述されているように、プロキシはhi-entryを追加する必要があります（SHOULD）リクエストを転送するとき。 [RFC3261]のセクション16.6は、プロキシがリクエストを転送するときに実行する手順を定義しています。ステップ5では、オプションのヘッダーの追加を規定しています。これはHistory-Infoヘッダーを追加するための適切なステップのように思われますが、ステップ6の「ポストプロセスルーティング情報」との相互作用、およびRouteヘッダーの厳密なルートの影響により、Request-URIが変更される可能性があります。したがって、手順8（Viaヘッダーの追加）と9（Content-Lengthの追加）の間にHistory-Infoヘッダーを追加することをお勧めします。ルーズルーティングの場合、リクエストの転送中にリクエストURIは変更されないことに注意してください。したがって、このようなリクエストのHistory-Infoをキャプチャすると、異なるインデックスを持つRequest-URIが重複することになります。転送される要求で受信した任意のhi-entryの後に、hi-entryを追加する必要があります。さらに、History-Infoヘッダーを含まないリクエストが受信された場合、プロキシは、転送されている現在のリクエストに追加されているものに先行するhi-entryを含むHistory-Infoヘッダーを追加してもよい（MAY）。このhi-entryのインデックスは、1から開始することをお勧めします。以下のサブセクションでは、各hi-entryに関連する情報の作成の詳細を定義します。
If there is a Privacy header in the request with a priv-value of "session", "header", or "history", a hi-entry MAY be added, if the request is being forwarded to a Request-URI associated with a domain for which the processing entity is responsible (and provided local policy supports the History-Info header, etc.). If a request is being forwarded to a Request-URI associated with a domain for which the proxy is not responsible and there is a Privacy header in the request with a priv-value of "session", "header", or "history", the proxy SHOULD remove any hi-entry(s) prior to forwarding, depending upon local policy and whether the proxy might know a priori that it can rely on a downstream privacy service to apply the requested privacy.
priv-valueが「session」、「header」、または「history」のリクエストにプライバシーヘッダーがある場合、リクエストが関連付けられたRequest-URIに転送される場合、hi-entryが追加される場合があります。処理エンティティが責任を負うドメイン（および提供されるローカルポリシーがHistory-Infoヘッダーなどをサポートする場合）。プロキシが責任を負わないドメインに関連付けられたRequest-URIにリクエストが転送され、リクエストに "session"、 "header"、または "history"のpriv-valueを持つプライバシーヘッダーがある場合、プロキシは、ローカルポリシーと、要求されたプライバシーを適用するためにダウンストリームプライバシーサービスに依存できることをプロキシがアプリオリに知っているかどうかに応じて、転送前にhi-entryを削除する必要があります（SHOULD）。
For the scenario where there is no Privacy header in the request and the request is being forwarded to a Request-URI associated with the domain(s) for which this entity is responsible, there are several additional considerations:
リクエストにプライバシーヘッダーがなく、リクエストがこのエンティティが担当するドメインに関連付けられたRequest-URIに転送されているシナリオでは、いくつかの追加の考慮事項があります。
o If there is no local policy associated with privacy, then a hi-entry MAY be added to the Request.
o プライバシーに関連するローカルポリシーがない場合は、リクエストにhi-entryを追加できます（MAY）。
o If the proxy's local policies, per consideration 4 in section 4.3.3, indicate that the History-Info header should not be forwarded beyond the domain for which this intermediary is responsible, then a Privacy header with a priv-value of "history" SHOULD be associated with each hi-entry added by that proxy in this scenario.
o プロキシのローカルポリシーが、セクション4.3.3の考慮事項4に従って、History-Infoヘッダーがこの仲介者が担当するドメインを超えて転送されるべきではないことを示している場合、priv-valueが "history"のプライバシーヘッダーが必要です（SHOULD）。このシナリオでは、そのプロキシによって追加された各hi-entryに関連付けられます。
o If the proxy's policy, per consideration 5 in Section 4.3.3, indicates that History-Info for a specific Request-URI should not be forwarded beyond the domain for which this intermediary is responsible, then a Privacy header with a priv-value of "history" SHOULD be associated with the specific hi-entry, for that specific hi-targeted-to-uri, added by that proxy in this scenario.
o プロキシのポリシーが、セクション4.3.3の考慮事項5に従って、特定のRequest-URIのHistory-Infoが、この仲介者が担当するドメインを超えて転送されるべきではないことを示している場合、priv-valueが「」のプライバシーヘッダー履歴」は、このシナリオでそのプロキシによって追加された特定のhi-targeted-to-uriの特定のhi-entryに関連付ける必要があります。
If a request is being forwarded to a Request-URI associated with a domain for which the proxy is not responsible and local policy requires privacy associated with any, or with specific, hi-entries it has added, any hi-entry with a priv-value of "history" SHOULD be removed prior to forwarding.
プロキシが責任を負わないドメインに関連付けられたRequest-URIにリクエストが転送されており、ローカルポリシーで、追加されたhi-entryまたは特定のhi-entryに関連付けられたプライバシーが必要な場合「history」の値は転送前に削除する必要があります。
For retargets that are the result of an explicit SIP response, a Reason MUST be associated with the hi-targeted-to-uri. If the SIP response does not include a Reason header, the SIP Response Code that triggered the retargeting MUST be included as the Reason associated with the hi-targeted-to-uri that has been retargeted. If the response contains a non-SIP Reason header (e.g., Q.850), it MUST be captured as an additional Reason associated with the hi-targeted-to-uri that has been retargeted, along with the SIP Response Code. If the Reason header is a SIP reason, then it MUST be used as the Reason associated with the hi-targeted-to-uri rather than the SIP response code.
明示的なSIP応答の結果であるリターゲットの場合、理由をhi-targeted-to-uriに関連付ける必要があります。 SIP応答にReasonヘッダーが含まれていない場合、再ターゲットされたhi-targeted-to-uriに関連付けられたReasonとして、再ターゲットをトリガーしたSIP応答コードを含める必要があります。応答に非SIP Reasonヘッダー（Q.850など）が含まれている場合、SIP応答コードとともに、再ターゲットされたhi-targeted-to-uriに関連付けられた追加の理由としてキャプチャする必要があります。 ReasonヘッダーがSIPの理由の場合、SIP応答コードではなく、hi-targeted-to-uriに関連付けられたReasonとして使用する必要があります。
For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted.
タイムアウトまたは内部イベントの結果としての再ターゲットの場合、理由は、再ターゲットされたhi-targeted-to-uriに関連付けることができます（MAY）。
The addition of the Reason should occur prior to the forwarding of the request (which may add a new hi-entry with a new hi-targeted-to-uri) as it is associated with the hi-targeted-to-uri that has been retargeted, since it reflects the reason why the Request to that specific URI was not successful.
Reasonの追加は、リクエストの転送の前に行う必要があります（これにより、新しいhi-targeted-to-uriに新しいhi-entryが追加される場合があります）。特定のURIへの要求が成功しなかった理由を反映するため、再ターゲット。
In order to maintain ordering and accurately reflect the nesting and retargeting of the request, an index MUST be included along with the Targeted-to-URI being captured. Per the syntax in Section 4.1, the index consists of a dot-delimited series of digits (e.g., 1.1.2). Each dot reflects a hop or level of nesting; thus, the number of hops is determined by the total number of dots. Within each level, the integer reflects the number of peer entities to which the request has been routed. Thus, the indexing results in a logical tree representation for the history of the Request. It is recommended that for each level of indexing, the index start at 1. It is recommended that an increment of 1 is used for advancing to a new branch.
順序付けを維持し、リクエストのネストとリターゲティングを正確に反映するために、キャプチャされているURIと一緒にインデックスを含める必要があります。セクション4.1の構文によると、インデックスはドット区切りの一連の数字で構成されます（1.1.2など）。各ドットは、ホップまたはネストのレベルを反映しています。したがって、ホップの数はドットの総数によって決まります。各レベル内で、整数はリクエストがルーティングされたピアエンティティの数を反映します。したがって、索引付けの結果、リクエストの履歴が論理ツリーで表現されます。インデックス作成の各レベルで、インデックスは1から開始することをお勧めします。新しいブランチに進むには、1の増分を使用することをお勧めします。
The basic rules for adding the index are summarized as follows:
インデックスを追加するための基本的なルールは次のとおりです。
1. Basic Forwarding: In the case of a Request that is being forwarded, the index is determined by adding another level of indexing since the depth/length of the branch is increasing. To accomplish this, the proxy reads the value from the History-Info header in the received request, if available, and adds another level of indexing by appending the dot delimiter followed by an initial index for the new level RECOMMENDED to be 1. For example, if the index in the last History-Info header field in the received request is 1.1, this proxy would initialize its index to 1.1.1 and forward the request.
1.基本的な転送：転送されるリクエストの場合、ブランチの深さ/長さが増加しているため、インデックスは別のレベルのインデックスを追加することによって決定されます。これを実現するために、プロキシは、受信したリクエストのHistory-Infoヘッダーから値を読み取り（可能な場合）、ドット区切り文字を追加して別のレベルのインデックスを追加し、その後に新しいレベルRECOMMENDEDの初期インデックスを1に追加します。次に例を示します。 、受信したリクエストの最後のHistory-Infoヘッダーフィールドのインデックスが1.1の場合、このプロキシはインデックスを1.1.1に初期化してリクエストを転送します。
2. Retargeting within a Proxy - 1st instance: For the first instance of retargeting within a Proxy, the calculation of the index follows that prescribed for basic forwarding.
2. プロキシ内のリターゲティング-最初のインスタンス：プロキシ内のリターゲティングの最初のインスタンスの場合、インデックスの計算は、基本的な転送に規定されたものに従います。
3. Retargeting within a Proxy - subsequent instance: For each subsequent retargeting of a request by the same proxy, another branch is added. With the index for each new branch calculated by incrementing the last/lowest digit at the current level, the index in the next request forwarded by this same proxy, following the example above, would be 1.1.2.
3. プロキシ内のリターゲット-後続のインスタンス：同じプロキシによるリクエストの後続のリターゲットごとに、別のブランチが追加されます。現在のレベルで最後/最下位の桁をインクリメントして計算された新しいブランチごとのインデックスを使用すると、上記の例に従って、この同じプロキシによって転送される次のリクエストのインデックスは1.1.2になります。
4. Retargeting based upon a Response: In the case of retargeting due to a specific response (e.g., 302), the index would be calculated per rule 3. That is, the lowest/last digit of the index is incremented (i.e., a new branch is created), with the increment RECOMMENDED to be 1. For example, if the index in the History-Info header of the received request was 1.2, then the index in the History-Info header field for the new hi-targeted-to-URI would be 1.3.
4. レスポンスに基づくリターゲティング：特定のレスポンス（302など）によるリターゲティングの場合、インデックスはルール3に従って計算されます。つまり、インデックスの最下位/最後の桁がインクリメントされます（つまり、新しいブランチ）たとえば、受信したリクエストのHistory-Infoヘッダーのインデックスが1.2の場合、新しいhi-targeted-to-のHistory-InfoヘッダーフィールドのインデックスURIは1.3になります。
5. Retargeting the request in parallel (forking): If the request forwarding is done in parallel, the index MUST be captured for each forked request per the rules above, with each new Request having a unique index. The only difference in the messaging for this scenario and the messaging produced per basic proxy retargeting in rules 2 and 3 is these forwarded requests do not have History-Info entries associated with their peers. The proxy builds the subsequent response (or request) using the aggregated information associated with each of those requests and including the header entries in the order indicated by the indexing. Responses are processed as described in Section 16.7 of [RFC3261] with the aggregated History-Info entries processed similar to Step 7 "Aggregate Authentication Header Field Values". Section 4.5 provides an example of a parallel request scenario, highlighting this indexing mechanism.
5. リクエストを並行して再ターゲットする（フォーク）：リクエストの転送が並行して行われる場合、上記のルールに従ってフォークされたリクエストごとにインデックスをキャプチャする必要があります。新しいリクエストにはそれぞれ一意のインデックスがあります。このシナリオのメッセージングと、ルール2および3の基本的なプロキシリターゲッティングごとに生成されるメッセージングの唯一の違いは、転送されたこれらの要求に、ピアに関連付けられたHistory-Infoエントリがないことです。プロキシーは、それらの要求のそれぞれに関連付けられた集約情報を使用し、索引付けで示された順序でヘッダー項目を含めて、後続の応答（または要求）を作成します。応答は、[RFC3261]のセクション16.7に記載されているように処理されます。集計されたHistory-Infoエントリは、手順7「認証ヘッダーフィールド値の集計」と同様に処理されます。セクション4.5は、並列リクエストのシナリオの例を示し、このインデックス作成メカニズムを強調しています。
A proxy that receives a Request with the "histinfo" option tag in the Supported header, and depending upon a local policy supporting the capture of History-Info, SHOULD return captured History-Info in subsequent, provisional, and final responses to the Request, subject to the following considerations for privacy:
サポートされているヘッダーに「histinfo」オプションタグを含むリクエストを受信し、History-Infoのキャプチャをサポートするローカルポリシーに応じて、リクエストに対する後続の、暫定的な、および最終的な応答でキャプチャされたHistory-Infoを返す必要があります。プライバシーに関する次の考慮事項に従います。
o If the response is being forwarded to a Request-URI associated with a domain for which the proxy is not responsible and there was a Privacy header, in the request received by the proxy, with a priv-value of "session", "header", or "history", the proxy MUST remove the History-Info header (i.e., all hi-entries) prior to forwarding.
o プロキシが責任を負わないドメインに関連付けられたRequest-URIに応答が転送されており、プロキシによって受信されたリクエストに、「session」、「header」のプライベート値を持つプライバシーヘッダーがあった場合または「履歴」の場合、プロキシは転送の前にHistory-Infoヘッダー（つまり、すべてのhi-entries）を削除する必要があります。
o If a request is being forwarded to a Request-URI associated with a domain for which the proxy is not responsible and local policy requires privacy associated with any or all hi-entry(s) it has added, any hi-entry with a priv-value of "history" MUST be removed prior to forwarding.
o プロキシが責任を負わないドメインに関連付けられたRequest-URIにリクエストが転送され、ローカルポリシーで、追加した一部またはすべてのhi-entryに関連付けられたプライバシーが必要な場合、priv- 「history」の値は転送前に削除する必要があります。
o If a proxy receives a response from another intermediary associated with a domain for which it is responsible, including hi-entry(s) with privacy headers, and that response is to be forwarded to a domain for which it is not responsible, then those hi-entry(s) MUST be removed.
o プロキシが、プライバシーヘッダーを含むhi-entryを含む、担当するドメインに関連付けられた別の仲介者から応答を受信し、その応答が担当しないドメインに転送される場合、それらのhi -entry（s）は削除する必要があります。
The processing of History-Info in responses follows the methodology described in Section 16.7 of [RFC3261], with the processing of History-Info headers adding an additional step, just before Step 9, "Forwarding the Response".
レスポンスのHistory-Infoの処理は、[RFC3261]のセクション16.7で説明されている方法に従い、History-Infoヘッダーの処理により、ステップ9の「Forwarding the Response」の直前に追加のステップが追加されます。
A redirect server SHOULD NOT add any new History-Info, as that would be done by the entity receiving the 3xx response. However, a redirect server MAY include History-Info in responses by adding any History-Info headers received in a request to a subsequent response.
リダイレクトサーバーは、3xx応答を受信するエンティティによって行われるため、新しいHistory-Infoを追加しないでください。ただし、リダイレクトサーバーは、リクエストで受信したHistory-Infoヘッダーを後続のレスポンスに追加することにより、レスポンスにHistory-Infoを含めることができます。
As discussed in Section 3, the security requirements are met by recommending the use of TLS (a basic SIP requirement per [RFC3261]) for hop-by-hop security. If TLS is not available on the connection over which a request containing a History-Info header is being forwarded, then either of the following two options MUST be implemented:
セクション3で説明したように、セキュリティ要件は、ホップバイホップのセキュリティにTLS（[RFC3261]ごとの基本的なSIP要件）の使用を推奨することで満たされます。 History-Infoヘッダーを含むリクエストが転送されている接続でTLSが利用できない場合、次の2つのオプションのいずれかを実装する必要があります。
o The History-Info header MUST be removed prior to forwarding the request, or o The request MUST be redirected, including the History-Info header in the response, to allow the UAC to securely issue the request, including the History-Info header.
o History-Infoヘッダーは、リクエストを転送する前に削除する必要があります。または、o History-Infoヘッダーを含むUACがリクエストを安全に発行できるように、レスポンスにHistory-Infoヘッダーを含めて、リクエストをリダイレクトする必要があります。
This scenario highlights an example where the History-Info in the response is primarily of use in not retrying routes that have already been tried by another proxy. Note that this is just an example and that there may be valid reasons why a Proxy would want to retry the routes, and thus, this would likely be a local proxy or even user-specific policy.
このシナリオは、応答内のHistory-Infoが、別のプロキシによってすでに試行されたルートを再試行しない場合に主に使用される例を強調しています。これは単なる例であり、プロキシがルートを再試行する正当な理由がある可能性があるため、これはローカルプロキシまたはユーザー固有のポリシーである可能性が高いことに注意してください。
UA1 sends a call to Bob to proxy 1. Proxy 1 forwards the request to Proxy 2. Proxy 2 sends the requests in parallel and tries several places (UA2, UA3, and UA4) before sending a response to Proxy 1 that all the places are busy. Proxy 1, without the History-Info, would try some of the same places (e.g., UA3) based upon registered contacts for Bob, before completing at UA5. However, with the History-Info, Proxy 1 determines that UA3 has already received the invite; thus, the INVITE goes directly to UA5.
UA1はBobにコールをプロキシ1に送信します。プロキシ1は要求をプロキシ2に転送します。プロキシ2は要求を並行して送信し、いくつかの場所（UA2、UA3、およびUA4）を試行してから、すべての場所がプロキシ1に応答を送信します。忙しい。プロキシー1は、History-Infoなしで、UA5で完了する前に、ボブの登録済み連絡先に基づいて同じ場所（UA3など）のいくつかを試します。ただし、History-Infoを使用すると、プロキシ1はUA3がすでに招待を受信したと判断します。したがって、INVITEは直接UA5に移動します。
Section 4.5.1 provides this same scenario using one of the privacy mechanisms, with Proxy2 (P2) adding the Privacy header indicating that the History-Info header is not to be propagated outside P2's domain. This scenario highlights the potential functionality lost with the use of "history" privacy in the Privacy header for the entire request and the need for careful consideration on the use of privacy for History-Info.
セクション4.5.1は、プライバシーメカニズムの1つを使用してこれと同じシナリオを提供します。Proxy2（P2）は、History-InfoヘッダーがP2のドメインの外部に伝播されないことを示すプライバシーヘッダーを追加します。このシナリオでは、リクエスト全体のプライバシーヘッダーで「履歴」プライバシーを使用すると失われる可能性のある機能と、History-Infoのプライバシーの使用について慎重に検討する必要があることを明らかにします。
Section 4.5.2 also provides the same scenario using one of the privacy mechanisms, however, due to local policy at Proxy2, only one of the Request-URIs (UA4) in the History-Info contains a priv-value of "history", thus allowing some optimized functionality in the routing of the request, but still maintaining privacy for specific URIs.
セクション4.5.2は、プライバシーメカニズムの1つを使用した同じシナリオも提供しますが、Proxy2のローカルポリシーにより、History-InfoのRequest-URI（UA4）の1つだけに "history"のプライベート値が含まれています。したがって、リクエストのルーティングでいくつかの最適化された機能を許可しながら、特定のURIのプライバシーを維持します。
The formatting in these scenarios is for visual purposes; thus, backslash and CRLF are used between the fields for readability and the headers in the URI are not shown properly formatted for escaping. Refer to Section 4.2 examples for the proper formatting. Additional detailed scenarios are available in the appendix.
これらのシナリオのフォーマットは視覚的な目的のためです。したがって、読みやすくするためにフィールド間でバックスラッシュとCRLFが使用され、URIのヘッダーはエスケープ用に適切にフォーマットされて表示されません。適切なフォーマットについては、セクション4.2の例を参照してください。追加の詳細なシナリオは、付録で入手できます。
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
UA1プロキシ1プロキシ2 UA2 UA3 UA4 UA5
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
| | |-INVITE>| | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com>;index=1.1.3
/* All Responses from the INVITEs indicate non-success/non-
availability*/
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;\
cause=408;text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP; \
cause=487;text="Request Terminated">; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP;\
cause=603;text="Decline">; index=1.1.3
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, but finds that it matches a route already attempted
(e.g., UA3), thus the INVITE is only forwarded to UA5, where
the session is successfully established */
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;cause=408;\
text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=487;\
text="Request Terminated">; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP;cause=603;\
text="Decline">; index=1.1.3
<sip:User5@UA5.example.com>;index=1.2
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
UA1プロキシ1プロキシ2 UA2 UA3 UA4 UA5
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1
| | | | | | |
| | |-INVITE>| | | |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com>;index=1.1.3
/* All Responses from the INVITEs indicate non-success/non-
availability and only the initial, received History-Info entries
are NOT returned to P1 due to the Privacy header value.*/
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, including UA3, which was attempted by P2, but due to
Privacy P1 is not aware of this, so UA3 is re-attempted prior to
forwarding the INVITE to UA5, where the session is successfully
established */
| | | | | | |
| |--------------INVITE ----->| | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>; index=1.2
| | | | | | |
| |<-- 486 -------------------| | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>; index=1.2
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=486;\
text="Busy Here">;index=1.2,
<sip:User5@UA5.example.com>;index=1.3
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
UA1プロキシ1プロキシ2 UA2 UA3 UA4 UA5
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
| | |-INVITE>| | | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com?\
Privacy=history>; index=1.1.3
/* All Responses from the INVITEs indicate non-success/non-
availability. The History-Info associated with UA4 is not returned
in the response due to the privacy header associated with that URI */
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;\
cause=408;text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP; \
cause=487;text="Request Terminated">; index=1.1.2,
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, but finds that it matches a route already attempted
(e.g., UA3), thus the INVITE is only forwarded to UA5, where
the session is successfully established */
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;cause=408;\
text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=487;\
text="Request Terminated">; index=1.1.2,
<sip:User5@UA5.example.com>;index=1.2
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
As seen by the example scenarios in the appendix, History-Info provides a very flexible building block that can be used by intermediaries and UAs for a variety of services. As such, any services making use of History-Info must be designed with the following considerations:
付録のシナリオ例からわかるように、History-Infoは、さまざまなサービスの仲介者やUAが使用できる非常に柔軟なビルディングブロックを提供します。そのため、History-Infoを利用するサービスは、次の点を考慮して設計する必要があります。
1) History-Info is optional; thus, a service MUST define default behavior for requests and responses not containing History-Info headers. 2) History-Info may be impacted by privacy considerations. Applications requiring History-Info need to be aware that if Header-, Session-, or History-level privacy is requested by a UA (or imposed by an intermediary) that History-Info may not be available in a request or response. This would be addressed by an application in the same manner as the previous consideration by ensuring there is reasonable default behavior should the information not be available. 3) History-Info may be impacted by local policy. Each application making use of the History-Info header SHOULD address the impacts of the local policies on the specific application (e.g., what specification of local policy is optimally required for a specific application and any potential limitations imposed by local policy decisions). Note that this is related to the optionality and privacy considerations identified in 1 and 2 above, but goes beyond that. For example, due to the optionality and privacy considerations, an entity may receive only partial History-Info entries; will this suffice? Note that this would be a limitation for debugging purposes, but might be perfectly satisfactory for some models whereby only the information from a specific intermediary is required. 4) The security associated with the History-Info header requires the use of TLS. In the case of TLS not being available for a connection over which a request is being forwarded, the History-Info header may be removed from a request. The impact of lack of having the information depends upon the nature of the specific application (e.g., Is the information something that appears on a display or is it processed by automata which could have negative impacts on the subsequent processing of a request?). It is suggested that the impact of an intermediary not supporting the security recommendations should be evaluated by the application to ensure that the impacts have been sufficiently addressed by the application.
1）History-Infoはオプションです。したがって、サービスは、History-Infoヘッダーを含まない要求と応答のデフォルトの動作を定義する必要があります。 2）History-Infoは、プライバシーに関する考慮事項の影響を受ける可能性があります。 History-Infoを必要とするアプリケーションは、ヘッダーレベル、セッションレベル、または履歴レベルのプライバシーがUAによって要求された場合（または仲介者によって課された場合）、要求または応答でHistory-Infoを使用できない場合があることに注意する必要があります。これは、情報が利用できない場合に合理的なデフォルトの動作が存在することを保証することにより、以前の考慮事項と同じ方法でアプリケーションによって対処されます。 3）History-Infoは地域のポリシーによって影響を受ける可能性があります。 History-Infoヘッダーを使用する各アプリケーションは、特定のアプリケーションに対するローカルポリシーの影響に対処する必要があります（たとえば、特定のアプリケーションに必要なローカルポリシーの仕様と、ローカルポリシーの決定によって課される潜在的な制限）。これは、上記の1と2で特定されたオプションとプライバシーの考慮事項に関連していますが、それを超えています。たとえば、オプション性とプライバシーの考慮事項により、エンティティは一部のHistory-Infoエントリのみを受け取る場合があります。これで十分でしょうか？これはデバッグ目的の制限ですが、特定の仲介者からの情報のみが必要な一部のモデルでは完全に満足できる場合があることに注意してください。 4）History-Infoヘッダーに関連付けられたセキュリティでは、TLSを使用する必要があります。要求が転送されている接続でTLSが使用できない場合、History-Infoヘッダーが要求から削除されることがあります。情報がないことの影響は、特定のアプリケーションの性質に依存します（たとえば、情報はディスプレイに表示されるものですか、それともオートマトンによって処理されますか？その後のリクエストの処理に悪影響を与える可能性がありますか？）アプリケーションがセキュリティの推奨事項をサポートしていない仲介者の影響を評価して、影響がアプリケーションで十分に対処されていることを確認することをお勧めします。
The threat model and related security and privacy requirements for the History-Info header are described in Sections 2.1 and 2.2 of this document. Sections 3.2, 3.3, and 4.4 provide normative recommendations related to security and privacy fulfilling these requirements. The use of TLS is mandated between the entities (i.e., UAC to Proxy, Proxy to Proxy, and Proxy to UAS) that use the History-Info header. The appropriate handling of a request in the case that TLS is not available for a specific connection is described in Section 5.
History-Infoヘッダーの脅威モデルと関連するセキュリティおよびプライバシー要件については、このドキュメントのセクション2.1および2.2で説明しています。セクション3.2、3.3、および4.4は、これらの要件を満たすセキュリティとプライバシーに関する規範的な推奨事項を提供します。 TLSの使用は、History-Infoヘッダーを使用するエンティティ（つまり、UACからプロキシ、プロキシからプロキシ、およびプロキシからUAS）間で必須です。特定の接続でTLSが利用できない場合のリクエストの適切な処理については、セクション5で説明します。
With TLS, History-Info headers are no less, nor no more, secure than other SIP headers, which generally have even more impact on the subsequent processing of SIP sessions than the History-Info header.
TLSを使用すると、History-Infoヘッダーは他のSIPヘッダーよりも安全であり、通常、History-InfoヘッダーよりもSIPセッションの後続の処理により大きな影響を与えます。
This document defines a new SIP header field name: History-Info and a new option tag: histinfo.
このドキュメントでは、新しいSIPヘッダーフィールド名：History-Infoおよび新しいオプションタグ：histinfoを定義しています。
The following changes have been made to
http:///www.iana.org/assignments/sip-parameters
The following row has been added to the header field section:
次の行がヘッダーフィールドセクションに追加されました。
Header Name Compact Form Reference
----------- ------------ ---------
History-Info none [RFC4244]
The following has been added to the Options Tags section:
以下がオプションタグセクションに追加されました：
Name Description Reference
---- ----------- ---------
histinfo When used with the Supported header, [RFC4244]
this option tag indicates support
for 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 new priv-value for the SIP Privacy header: history
このドキュメントでは、SIPプライバシーヘッダーの新しいpriv-valueを定義しています：履歴
The following changes have been made to
http://www.iana.org/assignments/sip-priv-values
The following has been added to the registration for the SIP Privacy header:
SIPプライバシーヘッダーの登録に以下が追加されました。
Name Description Registrant Reference
---- ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC4244]
History-Info header(s) mary.barnes@nortel.com
[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月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
[RFC3665]ジョンストン、A。、ドノバン、S。、スパークス、R。、カニンガム、C。、およびK.サマーズ、「Session Initiation Protocol（SIP）Basic Call Flow Examples」、BCP 75、RFC 3665、2003年12月。
The editor would like to acknowledge the constructive feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, Nir Chen, Francois Audet, 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.
編集者は、Robert Sparks、Paul Kyzivat、Scott Orton、John Elwell、Nir Chen、Francois Audet、Palash Jain、Brian Stucker、Norma Ng、Anthony Brown、Jayshree Bharatia、Jonathan Rosenberg、Eric Burgerから提供された建設的なフィードバックを認めたいと思います。マーティン・ドリー、ローランド・ジェスケ、沢田拓也、セバスチャン・プルヴォスト、セバスチャン・ガルシン。
The editor would like to acknowledge the significant input from Rohan Mahy on some of the normative aspects of the ABNF, particularly around the need for and format of the index and around the security aspects.
編集者は、ABNFのいくつかの規範的な側面、特にインデックスの必要性とフォーマット、およびセキュリティの側面に関するRohan Mahyからの重要な意見を認めたいと思います。
Cullen, Mark, and Jon contributed to the development of the initial requirements.
カレン、マーク、およびジョンは、初期要件の開発に貢献しました。
Cullen and Mark provided substantial input in the form of email discussion in the development of the initial version of the individual solution document.
カレンとマークは、個別のソリューションドキュメントの初期バージョンの開発において、電子メールディスカッションの形で実質的な情報を提供しました。
Cullen Jennings Cisco Systems 170 West Tasman Dr MS: SJC-21/3
カレンジェニングスシスコシステムズ170ウエストタスマン博士MS：SJC-21 / 3
Phone: +1 408 421 9990
EMail: fluffy@cisco.com
Jon Peterson NeuStar, Inc. 1800 Sutter Street, Suite 570 Concord, CA 94520 USA
Jon Peterson NeuStar、Inc. 1800 Sutter Street、Suite 570 Concord、CA 94520 USA
Phone: +1 925-363-8720
EMail: Jon.Peterson@NeuStar.biz
Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont、CA 94538 U.S.A.
EMail: mark@digitalfountain.com
Appendix. Example Scenarios
付録。シナリオの例
The scenarios in Appendices A-D provide sample use cases for the History-Info header for informational purposes only. They are not intended to be normative and the formatting is for visual purposes; thus, the headers in the URI are not shown properly formatted for escaping. Refer to Section 4.2 examples with the proper formatting.
付録A〜Dのシナリオでは、情報提供のみを目的として、History-Infoヘッダーの使用例を示します。それらは規範的であるように意図されておらず、フォーマットは視覚的な目的のためです。したがって、URIのヘッダーはエスケープ用に適切にフォーマットされて表示されません。適切なフォーマットで4.2項の例を参照してください。
Appendix A. Sequentially Forking (History-Info in Response)
付録A.順次分岐（応答の履歴情報）
This scenario highlights an example where the History-Info in the response is useful to an application or user that originated the request.
このシナリオは、応答内のHistory-Infoが、要求を発信したアプリケーションまたはユーザーにとって役立つ例を強調しています。
Alice at UA1 sends a call to Bob via Proxy1. Proxy1 sequentially tries several places (UA2, UA3 and UA4) unsuccessfully before sending a response to Alice.
UA1のアリスは、Proxy1を介してBobにコールを送信します。 Proxy1は、Aliceに応答を送信する前に、いくつかの場所（UA2、UA3、およびUA4）を連続して失敗します。
This scenario is provided to show that by providing the History-Info to UA1, the end-user or an application at UA1 could make a decision on how best to attempt finding Bob. Without this mechanism, UA1 might well attempt UA3 (and thus UA4) and then re-attempt UA4 on a third manual attempt at reaching Bob. With this mechanism, either the end-user or application could know that Bob is busy on his home phone and is physically not in the office. If there were an alternative address for Bob known to this end-user or application, that hasn't been attempted, then either the application or the end-user could attempt that. The intent here is to highlight an example of the flexibility of this mechanism that enables applications well beyond SIP as it is certainly well beyond the scope of this document to prescribe detailed applications.
このシナリオは、History-InfoをUA1に提供することによって、エンドユーザーまたはUA1のアプリケーションがボブを見つけるのに最善の方法を決定できることを示すために提供されています。このメカニズムがないと、UA1はUA3（したがってUA4）を試行し、ボブに到達するための3回目の手動試行でUA4を再試行する可能性があります。このメカニズムにより、エンドユーザーまたはアプリケーションは、ボブが自宅の電話でビジーであり、物理的にオフィスにいないことを知ることができます。このエンドユーザーまたはアプリケーションに知られているボブの代替アドレスが存在し、それが試みられていない場合、アプリケーションまたはエンドユーザーのいずれかがそれを試みる可能性があります。ここでの意図は、詳細なアプリケーションを規定することは確かにこのドキュメントの範囲をはるかに超えているため、SIPをはるかに超えるアプリケーションを可能にするこのメカニズムの柔軟性の例を強調することです。
In this scenario, since UA1 has not included the original Request-URI in the INVITE, the proxy adds a hi-entry to capture the original Request-URI to provide the complete set of information, as discussed in Section 4.3.3.1.
このシナリオでは、UA1がINVITEに元のRequest-URIを含めていないため、4.3.3.1で説明されているように、プロキシはhi-entryを追加して元のRequest-URIをキャプチャし、情報の完全なセットを提供します。
UA1 Proxy1 UA2 UA3 UA4
| | | | |
|-INVITE F1->| | | |
| | | | |
| |--INVITE F2------>| | |
|<--100 F3---| | | |
| |<-302 F4----------| | |
| | | | |
| |-------INVITE F5 --------->| |
| | | | |
| |<-------180 F6 ------------| |
|<---180 F7--| | | |
| . . |---retransmit INVITE ----->| |
| | | | |
| | ( timeout ) | | |
| | | | |
| |------INVITE F8 ------------------->|
|<--100 F9 --| | | |
| | | | |
| |<-486 F10 --------------------------|
| | | | |
| |-- ACK F11------------------------->|
|<--486 F12--| | | |
| | | | |
|--ACK F13-->| | | |
| | | | |
Message Details
メッセージ詳細
F1 INVITE UA1 ->Proxy1
F1 INVITE UA1-> Proxy1
INVITE sip:UserA@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/*Client for UA1 prepares to receive data on port 49170
from the network. */
F2 INVITE Proxy1 ->UA2
F2 INVITE Proxy1-> UA2
INVITE sip:UserA@ims.example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
Record-Route: <sip:UserA@example.com>
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com>; index=1.1
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F3 100 Trying Proxy1 ->UA1
F3 100試行Proxy1-> UA1
SIP/2.0 100 Trying
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
F4 302 Moved Temporarily UA2 ->Proxy1
F4 302は一時的にUA2-> Proxy1に移動しました
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP ims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: <sip:UserB@example.com>
Content-Length: 0
F5 INVITE Proxy1 -> UA3
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=2
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">; index=1.1,
<sip:UserB@example.com>;index=1.2
CSeq: 1 INVITE
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F6 180 Ringing UA3 ->Proxy1
F6 180 Ringing UA3-> Proxy1
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>;tag=5
Call-ID: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
F7 180 Ringing Proxy1 -> UA1
F7 180 Ringing Proxy1-> UA1
SIP/2.0 180 Ringing
SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
/* User B is not available. INVITE is sent multiple
times until it times out. */
/* The proxy forwards the INVITE to UA4 after adding the
additional History Information entry. */
F8 INVITE Proxy1 -> UA4
F8 INVITE Proxy1-> UA4
INVITE sip:UserC@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1.1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=1.2,
<sip:UserC@example.com>;index=1.3
CSeq: 1 INVITE
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F9 100 Trying Proxy1 ->UA1
F9 100試行Proxy1-> UA1
SIP/2.0 100 Trying
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
F10 486 Busy Here UA4 -> Proxy1
F10 486 Busy Here UA4-> Proxy1
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
F11 ACK Proxy1 -> UA4
F11 ACK Proxy1-> UA4
ACK sip:UserC@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 ACK
Content-Length: 0
/* The proxy forwards the 486 to Alice after adding the
associated History Information entries from the series of
INVITES */
F12 486 Busy Here Proxy1 -> UA1
F12 486 Busy Here Proxy1-> UA1
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1.1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=1.2,
<sip:UserC@example.com>;index=1.3
CSeq: 1 INVITE
Content-Length: 0
F13 ACK Alice -> Proxy 1
F13 ACKアリス->プロキシ1
ACK sip:UserA@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 ACK
Content-Length: 0
This scenario highlights an example where the History-Info in the request is primarily of use by an edge service (e.g., voicemail server). It should be noted that this isn't intended to be a complete specification for this specific edge service as it is quite likely that additional information is needed by the edge service. History-Info is just one building block that this service makes use of.
このシナリオは、リクエストのHistory-Infoがエッジサービス（ボイスメールサーバーなど）によって主に使用される例を強調しています。これは、エッジサービスが追加情報を必要とする可能性が高いため、この特定のエッジサービスの完全な仕様を意図したものではないことに注意してください。 History-Infoは、このサービスが利用するビルディングブロックの1つにすぎません。
UA1 called UA A, which had been forwarded to UA B, which forwarded to a UA VM (voicemail server). Based upon the retargeted URIs and Reasons (and other information) in the INVITE, the VM server makes a policy decision about what mailbox to use, which greeting to play, etc.
UA1がUA Aを呼び出し、UA BはUA VM（ボイスメールサーバー）に転送されました。 VMサーバーは、INVITEのリターゲットされたURIと理由（およびその他の情報）に基づいて、どのメールボックスを使用するか、どのグリーティングを再生するかなどのポリシーを決定します。
UA1 Proxy UA-A UA-B UA-VM
UA1プロキシUA-A UA-B UA-VM
| | | | |
|--INVITE F1-->| | | |
| | | | |
| |--INVITE F2-->| | |
|<--100 F3-----| | | |
| |<-302 F4------| | |
| | | | |
| |--------INVITE F5---------->| |
| | | | |
| |<--------180 F6-------------| |
|<---180 F7----| | | |
| . . . | | | |
| |------retransmit INVITE---->| |
| . . . | | | |
| | (timeout) | |
| | | | |
| |-------INVITE F8---------------------->|
| | | | |
| |<-200 F9-------------------------------|
| | | | |
|<-200 F10-----| | | |
| | | | |
|--ACK F11-------------------------------------------->|
Message Details
INVITE F1 UA1->Proxy
INVITE F1 UA1->プロキシ
INVITE sip:UserA@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/*Client for UA1 prepares to receive data on port 49170
from the network. */
INVITE F2 Proxy->UA-A
INVITE F2プロキシ-> UA-A
INVITE sip:UserA@ims.example.com SIP/2.0
Via: SIP/2.0/UDPims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
Record-Route: <sip:UserA@example.com>
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
History-Info: <sip:UserA@ims.example.com>; index=1
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
100 Trying F3 Proxy->UA1
SIP/2.0 100 Trying
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
302 Moved Temporarily F4 UserA->Proxy
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP ims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy<sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: <sip:UserB@example.com>
Content-Length: 0
INVITE F5 Proxy-> UA-B
INVITE F5プロキシ-> UA-B
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=2
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">; index=1,
<sip:UserB@example.com>;index=2
CSeq: 1 INVITE
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
180 Ringing F6 UA-B ->Proxy
180 Ringing F6 UA-B-> Proxy
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>;tag=5
Call-ID: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
180 Ringing F7 Proxy-> UA1
180 Ringing F7 Proxy-> UA1
SIP/2.0 180 Ringing
SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
/* User B is not available. INVITE is sent multiple
times until it times out. */
/* The proxy forwards the INVITE to UA-VM after adding the
additional History Information entry. */
INVITE F8 Proxy-> UA-VM
INVITE F8プロキシ-> UA-VM
INVITE sip:VM@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info:<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=2,
<sip:VM@example.com>;index=3
CSeq: 1 INVITE
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
200 OK F9 SIP/2.0 200 OK UA-VM->Proxy
200 OK F9 SIP / 2.0 200 OK UA-VM-> Proxy
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: TheVoiceMail <sip:VM@example.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844527 2890844527 IN IP4 vm.example.com
s=Session SDP
c=IN IP4 192.0.2.4
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
200 OK F10 Proxy->UA1
200 OK F10プロキシ-> UA1
SIP/2.0 200 OK
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: TheVoiceMail <sip:VM@example.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844527 2890844527 IN IP4 vm.example.com
s=Session SDP
c=IN IP4 192.0.2.4
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ACK F11 UA1-> UA-VM
ACK F11 UA1-> UA-VM
ACK sip:VM@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy<sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 ACK
Content-Length: 0
/* RTP streams are established between UA1 and
UA-VM. UA-VM starts announcement for UA1 */
This scenario highlights an example of an Automatic Call Distribution service, where the agents are divided into groups based upon the type of customers they handle. In this example, the Gold customers are given higher priority than Silver customers, so a Gold call would get serviced even if all the agents servicing the Gold group (ACDGRP1) were busy, by retargeting the request to the Silver Group. Upon receipt of the call at the agent assigned to handle the incoming call, based upon the History-Info header in the message, the application at the agent can provide an indication that this is a Gold call, from how many groups it might have overflowed before reaching the agent, etc. and thus can be handled appropriately by the agent.
このシナリオでは、自動コール配信サービスの例を取り上げます。このサービスでは、担当する顧客のタイプに基づいてエージェントがグループに分類されます。この例では、ゴールドの顧客の方がシルバーの顧客よりも優先度が高いため、ゴールドグループ（ACDGRP1）にサービスを提供するすべてのエージェントがビジーの場合でも、要求をシルバーグループに再ターゲティングすることで、ゴールドコールが処理されます。着信コールを処理するために割り当てられたエージェントでコールを受信すると、メッセージのHistory-Infoヘッダーに基づいて、エージェントのアプリケーションは、オーバーフローした可能性のあるグループの数から、これがゴールドコールであることを示します。エージェントに到達する前などに、エージェントによって適切に処理できます。
For scenarios whereby calls might overflow from the Silver to the Gold, clearly the alternate group identification, internal routing, or actual agent that handles the call SHOULD not be sent to UA1. Thus, for this scenario, one would expect that the Proxy would not support the sending of the History-Info in the response, even if requested by the calling UA.
通話がシルバーからゴールドにオーバーフローする可能性があるシナリオでは、通話を処理する代替グループID、内部ルーティング、または実際のエージェントをUA1に送信しないでください。したがって、このシナリオでは、呼び出し側のUAから要求された場合でも、プロキシが応答でのHistory-Infoの送信をサポートしないことを期待します。
As with the other examples, this is not prescriptive of how one would do this type of service but an example of a subset of processing that might be associated with such a service. In addition, this example is not addressing any aspects of Agent availability, which might also be done via a SIP interface.
他の例と同様に、これはこのタイプのサービスをどのように実行するかを規定するものではなく、そのようなサービスに関連付けられる可能性のある処理のサブセットの例です。さらに、この例では、エージェントの可用性の側面については取り上げていません。これは、SIPインターフェースを介して行うこともできます。
UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2
UA1プロキシACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2
| | | | |
|--INVITE F1-->| | | |
Supported:histinfo
| | | | |
| |--INVITE F2-->| | |
Supported:histinfo
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
| | | | |
| |<-302 F3------| | |
Contact: <sip:ACDGRP2@ACD.com>
| | | | |
| |--------INVITE F4---------->| |
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
| | | | |
| | | | |
| | | |INVITE F5>|
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
| | | | |
| | | |<-200 F6--|
| | | | |
| |<-200 F7--------------------| |
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
|<-200 F8------| | | |
< No History-Info included in the response due to Local Policy>
| | | | |
|--ACK F9--------------------------------------------->|
In this scenario, Alice places a call to Bob using first a Redirect server then a Proxy Server. The INVITE message is first sent to the Redirect Server. The Server returns a 302 Moved Temporarily response (F2) containing a Contact header with Bob's current SIP address. Alice then generates a new INVITE with Bob's current SIP address included in another History-Info entry. The INVITE is then sent to Bob via the Proxy Server, with Bob receiving the complete History information; the call then proceeds normally. The complete call flow for this scenario, without the use of History-Info, is described in Section 3.6 of the SIP Basic Call Flow Examples [RFC3665].
このシナリオでは、アリスは最初にリダイレクトサーバー、次にプロキシサーバーを使用してボブに電話をかけます。 INVITEメッセージは、最初にリダイレクトサーバーに送信されます。サーバーは、ボブの現在のSIPアドレスを含むContactヘッダーを含む302 Moved Temporarily応答（F2）を返します。次に、アリスは、ボブの現在のSIPアドレスが別のHistory-Infoエントリに含まれる新しいINVITEを生成します。次に、INVITEはプロキシサーバー経由でボブに送信され、ボブは完全な履歴情報を受信します。その後、呼び出しは通常どおり続行されます。 History-Infoを使用しないこのシナリオの完全なコールフローについては、SIP基本コールフローの例[RFC3665]のセクション3.6で説明されています。
Alice Redirect Server Proxy 3 Bob
| | | |
| INVITE F1 | | |
|--------------->| | |
| 302 F2 | | |
|<---------------| | |
| ACK F3 | | |
|--------------->| | |
| INVITE F4 | |
|-------------------------------->| INVITE F5 |
| 100 F6 |--------------->|
Message Details
メッセージ詳細
F1 INVITE Alice -> Redirect Server
F1 INVITE Alice->リダイレクトサーバー
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
History-Info: <sip:bob@biloxi.example.com>; index=1
Contact: <sip:alice@client.atlanta.example.com>
Content-Length: 0
F2 302 Moved Temporarily Redirect Proxy -> Alice
F2 302が一時的にリダイレクトプロキシを移動しました->アリス
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
;received=192.0.2.1
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
History-Info: <sip:bob@biloxi.example.com>; index=1
Contact: <sip:bob@chicago.example.com;transport=tcp>
Content-Length: 0
F3 ACK Alice -> Redirect Server
F3 ACKアリス->リダイレクトサーバー
ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
F4 INVITE Alice -> Proxy 3
F4 INVITE Alice-> Proxy 3
INVITE sip:bob@chicago.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\
text="Moved Temporarily">; index=1,
<sip:bob@chicago.example.com>; index=2
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Length: 0
F5 INVITE Proxy 3 -> Bob
F5 INVITEプロキシ3->ボブ
INVITE sip:bob@client.chicago.example.com SIP/2.0
Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.1
Max-Forwards: 69
Record-Route: <sip:ss3.chicago.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\
text="Moved Temporarily">; index=1,
<sip:bob@chicago.example.com>; index=2,
<sip:bob@client.chicago.example.com>; index=2.1
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Length: 0
Detailed Call Flow continues per section 6.3 in [RFC3665].
詳細な通話フローは、[RFC3665]のセクション6.3に続きます。
Editor's Address
編集者の住所
Mary Barnes Nortel 2201 Lakeside Blvd Richardson, TX USA
メアリーバーンズノーテル2201 Lakeside Blvd Richardson、TX USA
Phone: 1-972-684-5432 EMail: mary.barnes@nortel.com
電話：1-972-684-5432メール：mary.barnes@nortel.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP 78に含まれる権利、ライセンス、および制限の対象であり、ここに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。