[要約] RFC 8119は、SIP "cause" URIパラメータを使用してサービス番号の変換を行うための仕様です。このRFCの目的は、SIPベースの通信システムでサービス番号の変換を効率的に行うための標準化を提供することです。
Internet Engineering Task Force (IETF) M. Mohali
Request for Comments: 8119 Orange
Updates: 4458 M. Barnes
Category: Informational MLB@Realtime Communications
ISSN: 2070-1721 March 2017
SIP "cause" URI Parameter for Service Number Translation
サービス番号変換のSIP「原因」URIパラメータ
Abstract
概要
RFC 4458 (regarding SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the User Agent Server (UAS) receiving the message. This document updates RFC 4458 by creating a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC 4458, for using the "cause" URI parameter within the History-Info header field, since this use is mandatory in some IP networks' implementations.
RFC 4458（アプリケーションのSIP URIに関して）は、SIPリクエストのRequest-URIに表示される「原因」URIパラメータを定義します。これは、リクエストが受信したユーザーエージェントサーバー（UAS）に到着した理由を示すために使用されます。メッセージ。このドキュメントは、「原因」URIパラメータの新しい事前定義値を作成してRFC 4458を更新し、呼び出されたサービスアクセス番号の変換につながる特定のサービスアクションによる再ターゲットのケースのサービス番号変換をカバーします。このドキュメントでは、一部のIPネットワークの実装では必須であるため、History-Infoヘッダーフィールド内の「原因」URIパラメータを使用するための、RFC 4458にはなかったガイダンスも提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8119.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8119で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction, Terminology, and Overview . . . . . . . . . . . 2
2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Interaction with Request History Information . . . . . . 4
3.2. Handling and Processing the Service Number Translation
"cause" URI Parameter Value . . . . . . . . . . . . . . . 5
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
[RFC4458] defines a mechanism to identify retargeting due to call forwarding supplementary services. The "cause" URI parameter in the target URI identifies the reason for retargeting and has defined values equivalent to the TDM (Time Division Multiplexing) Redirecting Reasons [ITU-T_Q.763]. The concept of "retargeting" is defined in [RFC7044].
[RFC4458]は、コール転送補足サービスによるリターゲティングを識別するメカニズムを定義しています。ターゲットURIの「原因」URIパラメータは、リターゲティングの理由を識別し、TDM（時分割多重）リダイレクト理由[ITU-T_Q.763]と同等の値を定義しています。 「リターゲッティング」の概念は[RFC7044]で定義されています。
In the Public Switched Telephone Network (PSTN ) / Integrated Services Digital Network (ISDN), there is another kind of retargeting introduced by the Intelligent Network (IN) services based on a translation of the called number as mentioned in [ITU-T_Q.1214]. Indeed, IN aims to ease the introduction of new services (i.e., Universal Personal Telecommunication (UPT), Virtual Private Network (VPN), Freephone, etc.) based on greater flexibility and new capabilities as described in [ITU-T_I.312_Q.1201]. For these IN services, ISDN User Part (ISUP) introduced the "called IN number" and the "original called IN number" parameters to capture the information of the requested service access number prior its translation [ITU-T_Q.763].
[ITU-T_Q.1214]に記載されているように、公衆交換電話網（PSTN）/サービス総合デジタル網（ISDN）には、着信番号の変換に基づいてインテリジェントネットワーク（IN）サービスによって導入される別の種類の再ターゲットがあります。 ]。実際、INは、[ITU-T_I.312_Qで説明されているように、柔軟性と新機能に基づいて、新しいサービス（つまり、ユニバーサルパーソナルテレコミュニケーション（UPT）、仮想プライベートネットワーク（VPN）、フリーフォンなど）の導入を容易にすることを目的としています。 1201]。これらのINサービスの場合、ISDNユーザーパート（ISUP）は、「着呼IN番号」および「元着呼IN番号」パラメーターを導入して、変換前に要求されたサービスアクセス番号の情報を取得しました[ITU-T_Q.763]。
The term "service access number" is used in this specification to refer to the dialable number by which a specific service is reached. This special number is not a globally routable number; therefore, it needs to be translated into a routable SIP or tel URI to process the session establishment.
「サービスアクセス番号」という用語は、この仕様では、特定のサービスに到達するためのダイヤル可能な番号を指すために使用されます。この特別な番号は、グローバルにルーティング可能な番号ではありません。したがって、セッションの確立を処理するには、ルーティング可能なSIPまたはTel URIに変換する必要があります。
This specification proposes a solution to allow the identification of well-known services, such as premium or toll-free services that perform service access number translation, and to enable interworking with SIP signaling with the ISUP called IN number and original called IN number parameters.
この仕様は、サービスアクセス番号変換を実行するプレミアムサービスやフリーダイヤルサービスなどのよく知られたサービスの識別を可能にし、ISUPと呼ばれるIN番号と元の呼び出されるIN番号パラメーターとのSIPシグナリングとのインターワーキングを可能にするソリューションを提案します。
The mechanism will allow a SIP network to insert and convey the service access number requested before its translation to the final destination.
このメカニズムにより、SIPネットワークは、最終的な宛先に変換する前に、要求されたサービスアクセス番号を挿入して伝達できます。
In order to provide full call forwarding or access number translation services, usage of the "cause" URI parameter is only relevant within the History-Info header field defined in [RFC7044]. Because this relation has not been described in [RFC4458], this document provides guidance for using the "cause" URI parameter in conjunction with the History-Info header field.
完全なコール転送またはアクセス番号変換サービスを提供するために、「原因」URIパラメータの使用は、[RFC7044]で定義されているHistory-Infoヘッダーフィールド内でのみ関連があります。この関係は[RFC4458]で説明されていないため、このドキュメントでは、「原因」URIパラメータをHistory-Infoヘッダーフィールドと組み合わせて使用するためのガイダンスを提供します。
This document also answers a need expressed by the Third Generation Partnership Project (3GPP) [TS.3GPP.24.229] to identify the service access number. The procedures it defines are intended for networks that use 3GPP-defined services. Their use is undefined for other networks.
このドキュメントは、サービスアクセス番号を識別するための、第3世代パートナーシッププロジェクト（3GPP）[TS.3GPP.24.229]によって表明されたニーズにも答えます。定義されている手順は、3GPP定義のサービスを使用するネットワークを対象としています。他のネットワークでは、それらの使用は定義されていません。
A new value for the "cause" URI parameter of the 'sip:' or 'sips:' URI schemes is defined for the "Service number translation" use case. This value may be used in a 'sip:' or 'sips:' URI inserted in the Request-URI and in the History-Info header field [RFC7044] when the URI is issued from a retargeting or a service access number translation by a specific service similar to PSTN/ISDN IN services that is not a call forwarding service.
「sip：」または「sips：」URIスキームの「原因」URIパラメータの新しい値は、「サービス番号変換」のユースケースで定義されています。この値は、URIがリターゲティングまたはサービスアクセス番号変換から発行されたときに、Request-URIおよびHistory-Infoヘッダーフィールド[RFC7044]に挿入された「sip：」または「sips：」URIで使用できます。コール転送サービスではないPSTN / ISDN INサービスに類似した特定のサービス。
As defined in [RFC4458], the "cause" URI parameter must be encoded in the new target URI when generated by the service.
[RFC4458]で定義されているように、「原因」URIパラメータは、サービスによって生成されるときに、新しいターゲットURIでエンコードする必要があります。
The ABNF grammar [RFC5234] for the cause-param and target-param parameters from [RFC4458] is summarized below (including updates described in [Err1409]). The Status-Code is defined in [RFC3261].
[RFC4458]のcause-paramおよびtarget-paramパラメータのABNF文法[RFC5234]を以下に要約します（[Err1409]で説明されている更新を含む）。ステータスコードは[RFC3261]で定義されています。
target-param = "target=" pvalue
target-param = "target =" pvalue
cause-param = "cause=" Status-Code
cause-param = "cause ="ステータスコード
The following value for this URI parameter is added to the existing ones:
このURIパラメータの次の値が既存の値に追加されます。
+---------------------------------+-------+
| Cause | Value |
+---------------------------------+-------+
| Service number translation | 380 |
+---------------------------------+-------+
In order to help implementation of this solution for conveyance of the service access number, this document proposes guidance for usage of the "cause" URI parameter: guidance for the usage of the "cause" URI parameter in the request history information (in Section 3.1) and guidance for processing a service number translation service using the new "cause" URI parameter value (in Section 3.2).
このドキュメントでは、サービスアクセス番号を伝達するためのこのソリューションの実装を支援するために、「原因」URIパラメータの使用に関するガイダンスを提案します。リクエスト履歴情報（セクション3.1 ）と、新しい「原因」URIパラメータ値を使用してサービス番号変換サービスを処理するためのガイダンス（3.2項）。
The History-Info header field defined in [RFC7044] specifies a means of providing the UAS and User Agent Client (UAC) with information about the retargeting of a request. This information includes the initial Request-URI and any retargeted URIs. This information is placed in History-Info headers as the request is retargeted and, upon reaching the UAS, is returned in certain responses. The History-Info header field enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user and to keep this information throughout the signaling path even when successive applications are involved.
[RFC7044]で定義されているHistory-Infoヘッダーフィールドは、UASおよびユーザーエージェントクライアント（UAC）にリクエストの再ターゲットに関する情報を提供する手段を指定します。この情報には、初期のRequest-URIとリターゲットされたURIが含まれます。この情報は、リクエストが再ターゲットされるときにHistory-Infoヘッダーに配置され、UASに到達すると、特定の応答で返されます。 History-Infoヘッダーフィールドは、SIP要求が特定のアプリケーションまたはユーザーに到着する方法と理由に関する情報を提供することにより、多くの拡張サービスを有効にし、連続するアプリケーションが関係する場合でも、この情報をシグナリングパス全体に保持します。
When a proxy inserts a URI containing the "cause" URI parameter defined in [RFC4458] into the Request-URI of a forwarded request (per [RFC7044]), the proxy must also copy this new Request-URI within a History-Info header field entry into the forwarded request; thus, the URI in that entry includes the "cause" URI parameter. Therefore, even if the Request-URI is replaced as a result of rerouting by a downstream proxy, the History-Info header field will still contain these parameters, which can be of use to the UAS. Note that if a proxy does not support generation of the History-Info header field or if a downstream proxy removes the History-Info header fields, an application will only have access to the "cause" URI parameter if the request is not subsequently retargeted (i.e., it will be contained only in the Request-URI in the incoming request). The implications of the solution are further discussed in Section 3.2.
[RFC4458]で定義された「原因」URIパラメータを含むURIが転送されたリクエストのRequest-URIに挿入されると（[RFC7044]に従って）、プロキシはこの新しいRequest-URIをHistory-Infoヘッダー内にコピーする必要があります転送されたリクエストへのフィールドエントリ。したがって、そのエントリのURIには「原因」URIパラメータが含まれています。したがって、ダウンストリームプロキシによる再ルーティングの結果としてRequest-URIが置き換えられた場合でも、History-Infoヘッダーフィールドには、UASで使用できるこれらのパラメーターが含まれます。プロキシがHistory-Infoヘッダーフィールドの生成をサポートしていない場合、またはダウンストリームプロキシがHistory-Infoヘッダーフィールドを削除した場合、アプリケーションが「原因」URIパラメーターにアクセスできるのは、その後リクエストが再ターゲットされない場合のみです（つまり、着信リクエストのRequest-URIにのみ含まれます）。ソリューションの影響については、セクション3.2でさらに説明します。
In order to be able to filter specific entries among the history information, header field parameters have been defined in [RFC7044]. In particular, the "mp" and "rc" header field parameters have the following definitions:
履歴情報の中の特定のエントリをフィルタリングできるようにするために、ヘッダーフィールドパラメータは[RFC7044]で定義されています。特に、「mp」および「rc」ヘッダーフィールドパラメータには次の定義があります。
o When the new target was determined based on a mapping to a user other than the target user associated with the Request-URI being retargeted, the "mp" header field parameter is added. This allows the identification of retargets that are the result of an application decision on a user's behalf and also retargets that are the result of an internal decision made by an application.
o 新しいターゲットが、リターゲットされるRequest-URIに関連付けられたターゲットユーザー以外のユーザーへのマッピングに基づいて決定された場合、「mp」ヘッダーフィールドパラメータが追加されます。これにより、ユーザーに代わってアプリケーションが決定した結果であるリターゲットと、アプリケーションが行った内部決定の結果であるリターゲットを識別できます。
o The "rc" header field parameter is added when the new target represents a change in Request-URI, while the target user remains the same.
o 「rc」ヘッダーフィールドパラメータは、新しいターゲットがRequest-URIの変更を表すときに追加されますが、ターゲットユーザーは同じままです。
These header field parameters can be used in conjunction with the new "cause" URI parameter for certain applications, an example of which is provided in Section 4.
これらのヘッダーフィールドパラメータは、特定のアプリケーションの新しい「原因」URIパラメータと組み合わせて使用できます。その例をセクション4に示します。
When using the History-Info header field in conjunction with the "cause" URI parameter in a Request-URI, it is important to consider that the "cause" URI parameter is not the same parameter as the "cause" header field parameter included in the Reason header [RFC3326]. The "cause" header field parameter of the Reason header field should be added to a History-Info entry only when the retargeting is due to a received SIP response.
Request-URIの「原因」URIパラメーターと一緒にHistory-Infoヘッダーフィールドを使用する場合、「原因」URIパラメーターは、含まれている「原因」ヘッダーフィールドパラメーターと同じパラメーターではないことを考慮することが重要です。 Reasonヘッダー[RFC3326]。 Reasonヘッダーフィールドの「cause」ヘッダーフィールドパラメータは、リターゲティングが受信したSIP応答によるものである場合にのみ、History-Infoエントリに追加する必要があります。
3.2. Handling and Processing the Service Number Translation "cause" URI Parameter Value
3.2. サービス番号変換の「処理」および「原因」URIパラメータ値の処理
At the Application Server:
アプリケーションサーバーで：
When an application receiving a request that is addressed to a service access number changes the Request-URI into a routable number, it should insert within this new Request-URI a "cause" URI parameter value set to 380 "Service number translation". Following the process described in [RFC7044], the application server adds a new History-Info header field entry including the new Request-URI value including the "cause" URI parameter. It is also possible for an application server to add a "target" URI parameter as defined in [RFC4458] with the initial value of the Request-URI received by the application server.
サービスアクセス番号に宛てられた要求を受信するアプリケーションがRequest-URIをルーティング可能な番号に変更するとき、この新しいRequest-URI内に、「原因」URIパラメータ値を380「サービス番号変換」に設定して挿入する必要があります。 [RFC7044]で説明されているプロセスに従って、アプリケーションサーバーは、「原因」URIパラメータを含む新しいRequest-URI値を含む新しいHistory-Infoヘッダーフィールドエントリを追加します。 [RFC4458]で定義されているように、アプリケーションサーバーが「ターゲット」URIパラメータを追加して、アプリケーションサーバーが受信したRequest-URIの初期値を持つことも可能です。
Note that if the new Request-URI is further replaced by a downstream proxy for any reason and if the History-Info header field is not supported, the information of the service access number initially requested would be lost. Thus, it is strongly recommended to support the History-Info header field all along the signaling path.
何らかの理由で新しいRequest-URIがさらにダウンストリームプロキシに置き換えられ、History-Infoヘッダーフィールドがサポートされていない場合、最初に要求されたサービスアクセス番号の情報が失われることに注意してください。したがって、信号パス全体でHistory-Infoヘッダーフィールドをサポートすることを強くお勧めします。
At the UAS:
UASで：
When the UAS receiving the request wants to retrieve the service access number by which it has been reached, first it should look for the "cause" URI parameter value 380 in the History-Info header field. This History-Info entry should also contain an "mp" or "rc" header field parameter so that the UAS can find the requested service number in the History-Info entry having an index parameter value that matches this "mp" or "rc" header field parameter value. If, for any reason, there is no "mp" or "rc" header field parameter in the identified History-Info entry, the UAS can find the requested service number in the preceding History-Info entry.
リクエストを受け取ったUASが、到達したサービスアクセス番号を取得したい場合、まず、History-Infoヘッダーフィールドで「原因」URIパラメータ値380を探す必要があります。このHistory-Infoエントリには、「mp」または「rc」ヘッダーフィールドパラメータも含まれている必要があります。これにより、UASは、この「mp」または「rc」に一致するインデックスパラメータ値を持つHistory-Infoエントリで要求されたサービス番号を見つけることができます。ヘッダーフィールドのパラメーター値。なんらかの理由で、識別されたHistory-Infoエントリに「mp」または「rc」ヘッダーフィールドパラメータがない場合、UASは、前のHistory-Infoエントリで要求されたサービス番号を見つけることができます。
If the History-Info header is not supported or has been removed by a proxy for any reason, the UAS might be able to find the requested service access number before translation in either of the following ways, but there is no guarantee:
History-Infoヘッダーがサポートされていないか、なんらかの理由でプロキシによって削除された場合、UASは次のいずれかの方法で変換前に要求されたサービスアクセス番号を見つけることができますが、保証はありません。
o If the UAS is the direct target of the request coming from the application, the UAS ought to be able to find the service access number in the "target" URI parameter of the Request-URI if there is also a "cause" URI parameter set to 380 in this Request-URI.
o UASがアプリケーションからの要求の直接のターゲットである場合、「原因」URIパラメーターセットもある場合、UASはRequest-URIの「ターゲット」URIパラメーターでサービスアクセス番号を見つけることができるはずです。このRequest-URIで380に。
o If there is no "cause" URI parameter set to 380 in the Request-URI and there is no History-Info header field, the UAS will not be able to reliably retrieve the service access number before translation. Some existing implementations are known to extract the number from the To header field. While that approach may work in some situations, it will not work in the general case because the To header field value is sometimes changed by intermediaries, and such a change is not always detectable.
o Request-URIに「原因」URIパラメータが380に設定されておらず、History-Infoヘッダーフィールドがない場合、UASは変換前にサービスアクセス番号を確実に取得できません。いくつかの既存の実装は、Toヘッダーフィールドから数を抽出することが知られています。このアプローチは状況によっては機能する場合がありますが、Toヘッダーフィールドの値が仲介者によって変更されることがあり、そのような変更が常に検出できるとは限らないため、一般的なケースでは機能しません。
In this section, an example is provided to illustrate the application of the new cause-param value.
このセクションでは、新しいcause-param値の適用を説明する例を示します。
In this example, Alice calls her bank customer care. John is the person at the call center that answers the call. John is in a call center that manages several toll-free services, and he needs to know for which service Alice is calling in order to provide the appropriate welcome speech.
この例では、アリスは銀行のカスタマーケアに電話をかけます。ジョンは、コールに応答するコールセンターの人です。ジョンは、いくつかのフリーダイヤルサービスを管理するコールセンターにいます。彼は、適切なウェルカムスピーチを提供するために、アリスがどのサービスを呼び出しているかを知る必要があります。
Alice Toll-Free Service Atlanta.com John
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | | INVITE F3 |
| | |------------------>|
* Rest of flow not shown *
* 残りのフローは表示されていません*
Figure 1: Service Access Number Translation Example
図1：サービスアクセス番号変換の例
Message Details
メッセージ詳細
F1 INVITE [2001:db8:9::2] -> Toll-Free Service
In the initial request, the Request-URI contains the toll-free number dialed by Alice.
最初の要求では、Request-URIには、Aliceがダイヤルしたフリーダイヤル番号が含まれています。
INVITE sip:+18005551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: <sip:+18005551002@example.com;user=phone>
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@[2001:db8:9::2]>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
[SDPは表示されていません]
F2 INVITE Toll-Free Service -> Atlanta.com
F2 INVITEフリーダイヤルサービス-> Atlanta.com
The toll-free application receives the request and translates the service number into a routable number toward the call center. The Request-URI is changed, and, in the new Request-URI, a "cause" URI parameter set to 380 is added. As there was no History-Info header field in the received request, the application creates a History-Info header with two entries: one for the received Request-URI and one for the new Request-URI.
フリーダイヤルアプリケーションは要求を受信し、サービス番号をコールセンターへのルーティング可能な番号に変換します。 Request-URIが変更され、新しいRequest-URIに、380に設定された「原因」URIパラメータが追加されました。受信した要求にHistory-Infoヘッダーフィールドがなかったため、アプリケーションは、受信したRequest-URI用と新しいRequest-URI用の2つのエントリを持つHistory-Infoヘッダーを作成します。
INVITE sip:+15555551002@atlanta.com;cause=380;user=phone SIP/2.0
Via: SIP/2.0/TCP [2001:db8:a::2];branch=z9hG4bK-ik8
Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: <sip:+18005551002@example.com;user=phone>
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 69
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone>;index=1
History-Info: <sip:+15555551002@atlanta.com;cause=380;user=phone>;
index=1.1;mp=1
Contact: <sip:alice@[2001:db8:9::2]>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
[SDPは表示されていません]
F3 INVITE Atlanta.com -> John
F3 INVITE Atlanta.com-> John
The call center proxy routes the received request to John's IP address by changing the Request-URI. When changing the Request-URI, the proxy adds a new entry in the History-Info header field.
コールセンタープロキシは、Request-URIを変更して、受信した要求をJohnのIPアドレスにルーティングします。 Request-URIを変更すると、プロキシはHistory-Infoヘッダーフィールドに新しいエントリを追加します。
INVITE sip:john@[2001:db8:b::2] SIP/2.0
Via: SIP/2.0/TCP [2001:db8:b::3]:5060;branch=z9hG4bKpxk7g
Via: SIP/2.0/TCP [2001:db8:a::2];branch=z9hG4bK-ik8
Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: <sip:+18005551002@example.com;user=phone>
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 68
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone>;index=1
History-Info: <sip:+15555551002@atlanta.com;cause=380;user=phone>;
index=1.1;mp=1
History-Info: <sip:john@[2001:db8:b::2]>;index=1.1.1;rc=1.1
Contact: <sip:alice@[2001:db8:9::2]>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
[SDPは表示されていません]
NOTE: Line breaks are for display purpose only
注：改行は表示のみを目的としています
[RFC4458] defines a "cause" URI parameter specified as having predefined values. This document defines a new value for the "cause" URI parameter: 380.
[RFC4458]は、事前定義された値を持つものとして指定された「原因」URIパラメータを定義します。このドキュメントでは、「原因」URIパラメータの新しい値380を定義しています。
IANA has modified the existing row for the "cause" URI parameter to add a reference to this document under the "SIP/SIPS URI Parameters" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry:
IANAは、「原因」URIパラメータの既存の行を変更して、「Session Initiation Protocol（SIP）Parameters」レジストリ内の「SIP / SIPS URI Parameters」サブレジストリの下にこのドキュメントへの参照を追加しました。
Parameter Name Predefined Values Reference
-------------- ----------------- ----------------------
cause Yes [RFC4458][RFC8119]
The security considerations in [RFC4458] apply.
[RFC4458]のセキュリティに関する考慮事項が適用されます。
If a privacy level of 'header' is requested in the Privacy header field as described in [RFC3323], the "cause" URI parameter must be removed from the Request-URI to maintain the network-provided privacy requested. Privacy of the parameters, when they form part of a URI within the History-Info header field, is covered in [RFC7044].
[RFC3323]で説明されているように、プライバシーヘッダーフィールドで「ヘッダー」のプライバシーレベルが要求されている場合、要求されたネットワーク提供のプライバシーを維持するために、「原因」URIパラメーターをRequest-URIから削除する必要があります。 History-Infoヘッダーフィールド内のURIの一部を形成するパラメーターのプライバシーは、[RFC7044]でカバーされています。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <http://www.rfc-editor.org/info/rfc3323>.
[RFC3323] Peterson、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、DOI 10.17487 / RFC3323、2002年11月、<http://www.rfc-editor.org/info/rfc3323> 。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, <http://www.rfc-editor.org/info/rfc3326>.
[RFC3326] Schulzrinne、H.、Oran、D。、およびG. Camarillo、「セッション開始プロトコル（SIP）の理由ヘッダーフィールド」、RFC 3326、DOI 10.17487 / RFC3326、2002年12月、<http：// www .rfc-editor.org / info / rfc3326>。
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, DOI 10.17487/RFC7044, February 2014, <http://www.rfc-editor.org/info/rfc7044>.
[RFC7044] Barnes、M.、Audet、F.、Schubert、S.、van Elburg、J。、およびC. Holmberg、「An an Extension to the Session Initiation Protocol（SIP）for Request History Information」、RFC 7044、DOI 10.17487 / RFC7044、2014年2月、<http://www.rfc-editor.org/info/rfc7044>。
[TS.3GPP.24.229] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 13.6.0.0, January 2015.
[TS.3GPP.24.229] 3GPP、「セッション開始プロトコル（SIP）およびセッション記述プロトコル（SDP）に基づくIPマルチメディアコール制御プロトコル、ステージ3」、3GPP TS 24.229 13.6.0.0、2015年1月。
[Err1409] RFC Errata, Erratum ID 1409, RFC 4458.
[Err1409] RFC Errata、Erratum ID 1409、RFC 4458。
[ITU-T_I.312_Q.1201] ITU-T, "Principles of Intelligent Network Architecture", ITU-T Recommendation I312/Q.1201, October 1992.
[ITU-T_I.312_Q.1201] ITU-T、「Principles of Intelligent Network Architecture」、ITU-T Recommendation I312 / Q.1201、1992年10月。
[ITU-T_Q.1214] ITU-T, "Distributed Functional Plane For Intellignet Network CS-1", ITU-T Recommendation Q.1214, October 1995.
[ITU-T Q.1214] ITU-T、「インテリジェントネットワークCS-1の分散機能面」、ITU-T勧告Q.1214、1995年10月。
[ITU-T_Q.763] ITU-T, "Signalling System No. 7 -- ISDN User Part formats and codes", ITU-T Recommendation Q.763, December 1999.
[ITU-T_Q.763] ITU-T、「Signalling System No. 7-ISDN User Part Formats and Codes」、ITU-T Recommendation Q.763、December 1999。
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, DOI 10.17487/RFC4458, April 2006, <http://www.rfc-editor.org/info/rfc4458>.
[RFC4458] Jennings、C.、Audet、F。、およびJ. Elwell、「ボイスメールやインタラクティブ音声応答（IVR）などのアプリケーションのセッション開始プロトコル（SIP）URI」、RFC 4458、DOI 10.17487 / RFC4458、2006年4月、<http://www.rfc-editor.org/info/rfc4458>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
Acknowledgements
謝辞
The authors wish to thank the 3GPP community for providing guidance, input, and comments on the document. Thanks also to Paul Kyzivat, Dale Worley, Jean Mahoney, Robert Sparks, Joel Halpern, and Lionel Morand for their detailed reviews of the document. Special thanks to Ben Campbell for his help to make the work progress.
執筆者は、ドキュメントに関するガイダンス、入力、コメントを提供してくれた3GPPコミュニティに感謝します。ドキュメントの詳細なレビューを提供してくれたPaul Kyzivat、Dale Worley、Jean Mahoney、Robert Sparks、Joel Halpern、Lionel Morandにも感謝します。作業を進歩させるために彼の助けをしてくれたベン・キャンベルに特に感謝します。
Authors' Addresses
著者のアドレス
Marianne Mohali Orange 44 Avenue de la Republique Chatillon 92320 France
マリアンヌモハリオレンジ44アベニュードゥラレピュブリックシャティヨン92320フランス
Email: marianne.mohali@orange.com
Mary Barnes MLB@Realtime Communications TX United States of America
メアリーバーンズMLB @ Realtime Communications TXアメリカ合衆国
Email: mary.ietf.barnes@gmail.com