[要約] 要約：RFC 8498は、SIPにおけるOriginating Call Diversion（CDIV）セッションケースのためのP-Served-Userヘッダーフィールドパラメータについて説明しています。 目的：このRFCの目的は、CDIVセッションケースにおいて、SIPメッセージに関連する情報を提供するためのP-Served-Userヘッダーフィールドパラメータの使用方法を定義することです。
Internet Engineering Task Force (IETF) M. Mohali
Request for Comments: 8498 Orange
Updates: 5502 February 2019
Category: Informational
ISSN: 2070-1721
A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）の発信コール転送（CDIV）セッションケースのP-Served-Userヘッダーフィールドパラメーター
Abstract
概要
The P-Served-User header field was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) in order to convey the identity of the served user, his/ her registration state, and the session case that applies to that particular communication session and application invocation. A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user. This document updates RFC 5502 by defining a new P-Served-User header field parameter, "orig-cdiv". The parameter conveys the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services have been invoked for the served user. This document also fixes the ABNF in RFC 5502 and provides more guidance for using the P-Served-User header field in IP networks.
P-Served-Userヘッダーフィールドは、第3世代パートナーシッププロジェクト（3GPP）IMS（IPマルチメディアサブシステム）の要件に基づいて定義され、サービス対象ユーザーのID、ユーザーの登録状態、およびセッションケースを伝えます。その特定の通信セッションとアプリケーションの呼び出しに適用されます。セッションケースは、サービス対象ユーザーが登録されているかどうか、またはセッションがサービス対象ユーザーで開始または終了しているかどうかに関係なく、サービス対象ユーザーのセッションのステータスをキャプチャするメタデータです。このドキュメントは、新しいP-Served-Userヘッダーフィールドパラメータ「orig-cdiv」を定義することにより、RFC 5502を更新します。このパラメータは、通話転送（CDIV）サービスがサービス対象のユーザーに対して呼び出された後に、発信セッションを処理するときにプロキシによって使用されるセッションケースを伝えます。このドキュメントは、RFC 5502のABNFも修正し、IPネットワークでP-Served-Userヘッダーフィールドを使用するための詳細なガイダンスを提供します。
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 candidates 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 https://www.rfc-editor.org/info/rfc8498.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8498で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 4
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Proxy Behavior and Parameter Handling . . . . . . . . . . . . 6
5. Clarification of RFC 5502 Procedures . . . . . . . . . . . . 7
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 9
7.1. Call Diversion Case . . . . . . . . . . . . . . . . . . . 9
7.2. Call Diversion and Privacy . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
The P-Served-User header field [RFC5502] was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) in order to convey the identity of the served user, his/her registration state, and the session case between a Serving Call Session Control Function (S-CSCF) and an Application Server (AS) on the IMS Service Control (ISC) interface. A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user. For more information on session cases and the IMS, a detailed description can be found in [TS.3GPP.24.229].
P-Served-Userヘッダーフィールド[RFC5502]は、サーブドユーザーのID、そのユーザーの登録状態、 IMSサービス制御（ISC）インターフェース上のサービングコールセッション制御機能（S-CSCF）とアプリケーションサーバー（AS）の間のセッションケース。セッションケースは、サービス対象ユーザーが登録されているかどうか、またはセッションがサービス対象ユーザーで開始または終了しているかどうかに関係なく、サービス対象ユーザーのセッションのステータスをキャプチャするメタデータです。セッションケースとIMSの詳細については、[TS.3GPP.24.229]に詳細な説明があります。
[RFC5502] defines the originating and terminating session cases for a registered or unregistered user. This document extends the P-Served-User header field to include the session case for a forwarded leg when both a CDIV service has been invoked and an originating service of the diverting user has to be triggered.
[RFC5502]は、登録済みまたは未登録のユーザーの開始セッションと終了セッションのケースを定義します。このドキュメントでは、CDIVサービスが呼び出され、転送元ユーザーの元のサービスをトリガーする必要がある場合に、転送されたレッグのセッションケースを含めるようにP-Served-Userヘッダーフィールドを拡張しています。
The sessioncase-param parameter of the P-Served-User header field is extended with the "orig-cdiv" parameter for this originating-after-CDIV session case.
P-Served-Userヘッダーフィールドのsessioncase-paramパラメータは、このoriginating-after-CDIVセッションケースの「orig-cdiv」パラメータで拡張されています。
The following section defines usage of the "orig-cdiv" parameter of the P-Served-User header field, Section 3 discusses the applicability and scope of this new header field parameter, and Section 4 specifies the proxy behavior for handling the new header field parameter. Section 5 clarifies some of the [RFC5502] procedures, Section 6 describes the extended syntax and corrects the syntax of [RFC5502], Section 7 gives some call flow examples, Section 8 registers the P-Served-User header field parameters with IANA, and Section 9 discusses the security properties of the environment where this new header field parameter is intended to be used.
次のセクションでは、P-Served-Userヘッダーフィールドの「orig-cdiv」パラメーターの使用法を定義し、セクション3では、この新しいヘッダーフィールドパラメーターの適用性とスコープについて説明し、セクション4では、新しいヘッダーフィールドを処理するためのプロキシの動作を指定しますパラメータ。セクション5は[RFC5502]の手順の一部を明確にし、セクション6は拡張構文を説明し、[RFC5502]の構文を修正します。セクション7はいくつかのコールフローの例を示し、セクション8はIANAにP-Served-Userヘッダーフィールドパラメータを登録します。セクション9では、この新しいヘッダーフィールドパラメータを使用する環境のセキュリティプロパティについて説明します。
In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) is a SIP proxy that serves as a registrar and handles originating and terminating session states for users assigned to it. This means that any call that is originated by a specific user or any call that is terminated to that specific user will pass through the S-CSCF that is assigned to that user.
3GPP IMS（IPマルチメディアサブシステム）では、S-CSCF（サービングCSCF）は、レジストラとして機能し、それに割り当てられたユーザーの開始および終了セッション状態を処理するSIPプロキシです。これは、特定のユーザーから発信された通話、またはその特定のユーザーに対して終了した通話は、そのユーザーに割り当てられているS-CSCFを通過することを意味します。
At the moment that an S-CSCF is assigned to a specific user, the user profile is downloaded from the Home Subscriber Server (HSS) to that S-CSCF; see [TS.3GPP.29.228]. The user profile contains the list of actions to be taken by the S-CSCF for the served user depending on the session direction (originating or terminating) and the user state (registered or not) in the IMS network. With this user profile, the S-CSCF determines the current case and applies the corresponding actions such as forwarding the request to an AS. The AS then goes through a similar process of determining who is the current served user, what is his/her "registration state", and what is the "session case" of the session. [RFC5502] defines all those parameters and in particular the originating and terminating session cases.
S-CSCFが特定のユーザーに割り当てられると、ユーザープロファイルがホームサブスクライバーサーバー（HSS）からそのS-CSCFにダウンロードされます。 [TS.3GPP.29.228]を参照してください。ユーザープロファイルには、IMSネットワークのセッションの方向（発信または終了）とユーザーの状態（登録済みかどうか）に応じて、S-CSCFがサービス対象ユーザーに対して実行するアクションのリストが含まれています。このユーザープロファイルを使用して、S-CSCFは現在のケースを決定し、リクエストをASに転送するなど、対応するアクションを適用します。次に、ASは、現在サービスを提供しているユーザー、ユーザーの「登録状態」、およびセッションの「セッションケース」を判別する同様のプロセスを実行します。 [RFC5502]は、これらのすべてのパラメータ、特にセッションの開始および終了のケースを定義します。
In basic call scenarios, there is no particular issue for the S-CSCF and AS to know which scenario needs to be realized, but in case of CDIV services for which the session is re-targeted, the session cases defined in [RFC5502] pose some limitations as described in the following section.
基本的なコールシナリオでは、S-CSCFおよびASがどのシナリオを実現する必要があるかを認識するための特定の問題はありませんが、セッションが再ターゲットされるCDIVサービスの場合、[RFC5502]で定義されているセッションケースが提起されます。次のセクションで説明するいくつかの制限。
To illustrate the problem statement, let's imagine Alice trying to call Bob and Bob having a CDIV service activated towards Carol's address. In the case of a CDIV service, the received request is first treated as a terminating session case (at Bob's side), and the terminating filter criteria configured in the S-CSCF is performed. A filter criteria is information in the user profile that determines whether an initial request is sent to a particular AS. When the AS receives the call initiation request, the AS is able to determine the served user (Bob) and the session case (here "term") from the received P-Served-User header field content and is able to execute terminating services. When the CDIV service is executed (as a terminating service of Bob), the AS changes the target (Request-URI) of the session (toward Carol's address) and a new call leg is created. The served user becomes the diverting user. This new call leg could be considered as an originating call leg from the diverting user (Bob), but this is not the case. Indeed, the originating user remains the same (Alice), and some of the diverting user's originating services should not be triggered as if it was an originating call. For instance, the originating user identity (Alice) should not be restricted because the diverting user (Bob) has a privacy service for his own identity. The privacy of the diverting user should apply to information related to this user only (e.g., in the History-Info header field). In the same manner, some specific services will need to be triggered on the outgoing leg after a CDIV. Without a dedicated session case for originating-after-CDIV, the S-CSCF cannot trigger an originating service for the diverting user, nor can an AS execute the procedures for this particular session case.
問題の説明を説明するために、アリスがボブに電話をかけようとしており、ボブがキャロルのアドレスに対してCDIVサービスをアクティブにしているとします。 CDIVサービスの場合、受信した要求は最初に（Bob側の）終了セッションケースとして扱われ、S-CSCFで構成された終了フィルター基準が実行されます。フィルター基準は、初期要求が特定のASに送信されるかどうかを決定するユーザープロファイル内の情報です。 ASがコール開始要求を受信すると、ASは受信したP-Served-Userヘッダーフィールドの内容から、サービスを提供するユーザー（Bob）とセッションケース（ここでは「term」）を判別し、終端サービスを実行できます。 CDIVサービスが実行されると（ボブの終了サービスとして）、ASはセッションのターゲット（Request-URI）を（キャロルのアドレスに向けて）変更し、新しいコールレッグが作成されます。提供されたユーザーが転送ユーザーになります。この新しいコールレッグは、転送先のユーザー（Bob）からの発信コールレッグと見なすことができますが、そうではありません。実際、発信元ユーザーは同じまま（アリス）であり、転送元ユーザーの一部の発信元サービスは、発信元であるかのようにトリガーされるべきではありません。たとえば、転送元のユーザーID（アリス）は制限されるべきではありません。転送先のユーザー（ボブ）は自分のIDのプライバシーサービスを持っているからです。転送するユーザーのプライバシーは、このユーザーに関連する情報にのみ適用する必要があります（たとえば、History-Infoヘッダーフィールド内）。同様に、CDIVの後に発信レッグで特定のサービスをトリガーする必要があります。 originating-after-CDIVの専用セッションケースがない場合、S-CSCFは転送元ユーザーの発信サービスをトリガーできず、ASはこの特定のセッションケースの手順を実行できません。
For this use case, this document creates a new parameter ("orig-cdiv") for the originating-after-CDIV session case to be embedded in the P-Served-User header field.
この使用例の場合、このドキュメントでは、PDIVヘッダーフィールドに埋め込まれるoriginating-after-CDIVセッションケースの新しいパラメーター（ "orig-cdiv"）を作成します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The use of the P-Served-User header field extensions is only applicable inside a Trust Domain [RFC3324] for the P-Served-User header field. Nodes in such a Trust Domain explicitly trust each other to convey the served user and to be responsible for withholding that information outside of the Trust Domain. The means by which the network determines the served user and the policies that are executed for a specific served user is outside the scope of this document.
P-Served-Userヘッダーフィールド拡張の使用は、P-Served-Userヘッダーフィールドの信頼ドメイン[RFC3324]内でのみ適用できます。そのような信頼ドメイン内のノードは、サービスを提供するユーザーを伝達し、信頼ドメイン外の情報を差し控える責任を負うことを明示的に相互に信頼します。ネットワークがサービスを受けるユーザーと特定のサービスを受けるユーザーに対して実行されるポリシーを決定する方法は、このドキュメントの範囲外です。
The following section illustrates how this header field parameter can be used in a 3GPP network.
次のセクションでは、このヘッダーフィールドパラメータを3GPPネットワークで使用する方法を示します。
For a terminating call, the following steps will be followed:
着信コールの場合、次の手順に従います。
1. The S-CSCF receives the initial INVITE request for a terminating call and determines that the session case is for a terminating user as described in [RFC5502].
1. S-CSCFは、[RFC5502]で説明されているように、終了コールの最初のINVITE要求を受信し、セッションケースが終了ユーザーのものであると判断します。
2. The S-CSCF determines who is the served user by looking at the Request-URI and saves the current Request-URI.
2. S-CSCFは、Request-URIを確認して、誰がサービス対象のユーザーであるかを判別し、現在のRequest-URIを保存します。
3. The S-CSCF analyzes the filter criteria. It then sends the request to the AS of the served user as an INVITE that includes the P-Served-User header field with the "sescase" parameter set to "term" and the "regstate" set to the corresponding value in order to trigger execution of terminating services.
3. S-CSCFはフィルター基準を分析します。次に、「sescase」パラメータが「term」に設定され、「regstate」が対応する値に設定されたP-Served-Userヘッダーフィールドを含むINVITEとして要求を、トリガーするために、対応するユーザーのASに送信します。終端サービスの実行。
4. Based on some criteria, the AS concludes that the request has to be diverted to another target user or application. The AS replaces the received Request-URI with the new diverted-to address and stores the successive Request-URI(s) values by adding one or two History-Info header field entry(ies) [RFC7044] in the outgoing INVITE. In the History-Info header field, the served user address is tagged by using the mp-param header field parameter added in the newly created entry that contains the diverted-to address. The AS forwards the INVITE request back to the S-CSCF.
4. ASは、いくつかの基準に基づいて、要求を別のターゲットユーザーまたはアプリケーションに転送する必要があると結論付けます。 ASは、受信したRequest-URIを新しい宛先アドレスに置き換え、1つまたは2つのHistory-Infoヘッダーフィールドエントリ[RFC7044]を送信INVITEに追加して、連続するRequest-URI値を格納します。 History-Infoヘッダーフィールドでは、転送先アドレスを含む新しく作成されたエントリに追加されたmp-paramヘッダーフィールドパラメーターを使用して、提供されるユーザーアドレスにタグが付けられます。 ASは、INVITE要求をS-CSCFに転送します。
5. When receiving back the INVITE request, the S-CSCF can see that the topmost Route header field contains its own hostname, but the Request-URI does not match the saved Request-URI. In this case, the S-CSCF updates the P-Served-User header field content by replacing the "sescase" parameter with the "orig-cdiv" parameter. The P-Served-User header field value remains unchanged.
5. INVITE要求を受信すると、S-CSCFは最上位のRouteヘッダーフィールドに独自のホスト名が含まれていることを確認できますが、Request-URIが保存されたRequest-URIと一致しません。この場合、S-CSCFは、「sescase」パラメーターを「orig-cdiv」パラメーターで置き換えることにより、P-Served-Userヘッダーフィールドの内容を更新します。 P-Served-Userヘッダーフィールドの値は変更されません。
6. The S-CSCF forwards the INVITE request to an AS that hosts the served user's (diverting user's) originating services, which need to be executed on the forwarded leg after a CDIV service.
6. S-CSCFは、CDIVサービスの後に転送されたレッグで実行する必要がある、サービスを提供するユーザー（転送ユーザー）の発信元サービスをホストするASにINVITE要求を転送します。
7. When the AS receives the INVITE request, it determines that the session case is for the "orig-cdiv" session case and performs the originating services to be executed after retargeting for the diverting user (i.e., served user).
7. ASはINVITEリクエストを受信すると、セッションケースが「orig-cdiv」セッションケースであると判断し、転送元のユーザー（つまり、サービスを提供するユーザー）の再ターゲット後に実行される元のサービスを実行します。
This document provides the following guidance for the handling of the P-Served-User header field that is missing in [RFC5502]:
このドキュメントは、[RFC5502]にないP-Served-Userヘッダーフィールドの処理に関する次のガイダンスを提供します。
o The P-Served-User header field MUST NOT be repeated within a request for a particular session at a particular time for the reason that session cases are mutually exclusive. This document updates [RFC5502] to clearly state that the P-Served-User header field MUST NOT contain multiple values either comma-separated or header-separated. This document also updates the syntax of the header from [RFC5502] to reflect this uniqueness of parameter values.
o P-Served-Userヘッダーフィールドは、セッションケースが相互に排他的であるため、特定のセッションのリクエスト内で特定の時間に繰り返されてはなりません。このドキュメントは、[RFC5502]を更新して、P-Served-Userヘッダーフィールドにカンマ区切りまたはヘッダー区切りの複数の値を含めてはならないことを明確に述べています。また、このドキュメントでは、ヘッダーの構文を[RFC5502]から更新して、このパラメーター値の一意性を反映しています。
o [RFC5502] does not clearly state what to do with the received P-Served-User header field when a call is diverted to another destination. This document highlights that there are several ways of handling the P-Served-User header field: the S-CSCF could store the previous "regstate" value and decide that the same value applies, the "regstate" may no longer be relevant after a diverting service so the S-CSCF removes it, or the "regstate" could be combined with the "orig-cdiv" session case to provide different services depending on whether the served user is registered or unregistered. These choices are implementation dependent.
o [RFC5502]は、コールが別の宛先に転送されたときに、受信したP-Served-Userヘッダーフィールドをどうするかを明確に述べていません。このドキュメントは、P-Served-Userヘッダーフィールドを処理する方法がいくつかあることを強調しています。S-CSCFは以前の「regstate」値を保存し、同じ値が適用されると判断する可能性があります。 S-CSCFがそれを削除するようにサービスを迂回させるか、「regstate」を「orig-cdiv」セッションケースと組み合わせて、サービスを提供するユーザーが登録されているか未登録かに応じて異なるサービスを提供できます。これらの選択は実装に依存します。
[RFC5502] defines the P-Served-User header field with the sessioncase-param parameter "sescase", which is specified as having "orig" and "term" as predefined values. This document defines an additional parameter, "orig-cdiv", for the sessioncase-param.
[RFC5502]は、P-Served-Userヘッダーフィールドを、事前定義された値として「orig」と「term」を持つものとして指定されたsessioncase-paramパラメータ「sescase」で定義します。このドキュメントでは、sessioncase-paramの追加パラメーター「orig-cdiv」を定義しています。
Because this document extends the existing sessioncase-param parameter, and because errors have been identified in the syntax, this document corrects and extends the P-Served-User header field.
このドキュメントは既存のsessioncase-paramパラメータを拡張し、エラーが構文で識別されているため、このドキュメントはP-Served-Userヘッダーフィールドを修正および拡張します。
The extension of the sessioncase-param parameter to add the "orig-cdiv" session case is done in a way that fits the parameter format introduced in Release 11 of the 3GPP [TS.3GPP.24.229] and maintains backward compatibility.
「orig-cdiv」セッションケースを追加するためのsessioncase-paramパラメータの拡張は、3GPP [TS.3GPP.24.229]のリリース11で導入されたパラメータ形式に適合し、下位互換性を維持する方法で行われます。
"EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic-param" are defined in [RFC3261].
「EQUAL」、「HCOLON」、「SEMI」、「name-addr」、「addr-spec」、および「generic-param」は、[RFC3261]で定義されています。
If the "addr-spec" contains a comma, question mark, or semicolon, the "name-addr" form MUST be used. The "name-addr" form requires the use of angle brackets (< and >).
「addr-spec」にコンマ、疑問符、またはセミコロンが含まれている場合は、「name-addr」形式を使用する必要があります。 「name-addr」形式では、山括弧（<および>）を使用する必要があります。
The Augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P-Served-User header field is described in [RFC5502].
P-Served-UserヘッダーフィールドのAugmented Backus-Naur Form（ABNF）[RFC5234]構文は、[RFC5502]で説明されています。
This document updates [RFC5502] to correct the P-Served-User header field ABNF syntax and extend it as the following:
このドキュメントは、[RFC5502]を更新してP-Served-UserヘッダーフィールドのABNF構文を修正し、次のように拡張します。
P-Served-User = "P-Served-User" HCOLON PServedUser-value
*(SEMI served-user-param)
served-user-param = sessioncase-param
/ registration-state-param
/ generic-param
PServedUser-value = name-addr / addr-spec
sessioncase-param = "sescase" EQUAL ("orig"/"term")/ orig-cdiv
registration-state-param = "regstate" EQUAL ("unreg" / "reg")
orig-cdiv = "orig-cdiv"
Examples of possible P-Served-User header fields:
可能なP-Served-Userヘッダーフィールドの例：
P-Served-User: <sip:user@example.com>; orig-cdiv; regstate=reg
or
P-Served-User: <sip:user@example.com>; orig-cdiv
or
P-Served-User: <sip:user@example.com>; sescase=term; regstate=unreg
This document allows choosing between "addr-spec" and "name-addr" when constructing the header field value. As specified in RFC 8217, the "addr-spec" form MUST NOT be used if its value would contain a comma, semicolon, or question mark [RFC8217].
このドキュメントでは、ヘッダーフィールド値を作成するときに、「addr-spec」と「name-addr」のどちらかを選択できます。 RFC 8217で指定されているように、値にコンマ、セミコロン、または疑問符が含まれる場合は、「addr-spec」形式を使用してはなりません[RFC8217]。
The following call flow shows a session establishment when Alice calls Bob, who has a CDIV service that diverts to Carol when Bob is busy.
次のコールフローは、アリスがボブに電話をかけたときのセッション確立を示しています。ボブは、ボブがビジーのときにキャロルに転送されるCDIVサービスを持っています。
proxy server UA
Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| | |
| | INVITE F3 | | |
| |<---------------| INVITE F4 | |
| |-------------------------------->| |
| | 486 F5 | |
| |<--------------------------------| |
| | 486 F6 | | |
| |--------------->| | |
| | INVITE F7 | | |
| |<---------------| | |
| | INVITE F8 | | |
| |--------------->| | |
| | INVITE F9 | | |
| |<---------------| INVITE F10 |
| |------------------------------------------------->|
| | | | |
| | | | 180 F11 |
| | | 180 F12 |<---------------|
| | 180 F13 |<---------------| |
| 180 F14 |<---------------| | |
|<---------------| | | |
| | | | |
[Alice calls Bob]
[アリスはボブに電話します]
F1 INVITE Alice -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
F2 INVITE S-CSCF-B -> AS-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F3 INVITE AS-B -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F4 INVITE S-CSCF-B -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
[Bob is busy. His CDIV when busy is invoked towards Carol]
【ボブは忙しい。忙しいときの彼のCDIVはキャロルに向けて呼び出されます]
F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B
486 BUSY
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>;tag=es43sd
[Alice's call is diverted to Carol]
[アリスの通話はキャロルに転送されます]
F7 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
[The forwarded leg to Carol is identified as an originating call after CDIV, which should not trigger all of Bob's originating services]
[キャロルに転送されたレッグは、CDIVの後に発信コールとして識別されます。これは、ボブの発信サービスのすべてをトリガーするべきではありません]
F8 INVITE S-CSCF-B -> AS-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
F9 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
F10 INVITE S-CSCF-B -> Carol
INVITE sip:carol@192.0.2.7 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
Figure 1. P-Served-User During CDIV Service
図1. CDIVサービス中のP-Served-User
The following call flow shows a CDIV use case for which Alice has no identity restriction service and Bob has an unconditional CDIV service towards Carol and an identity presentation restriction service.
次のコールフローは、Cliceのユースケースを示しています。AliceにはID制限サービスがなく、BobにはCarolへの無条件CDIVサービスとIDプレゼンテーション制限サービスがあります。
proxy server UA
Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| | |
| | INVITE F3 | | |
| |<---------------| | |
| | INVITE F4 | | |
| |--------------->| | |
| | INVITE F5 | | |
| |<---------------| INVITE F6 | |
| |------------------------------------------------->|
| | | | |
| | | | 180 F7 |
| | | 180 F8 |<---------------|
| | 180 F9 |<---------------| |
| 180 F10 |<---------------| | |
|<---------------| | | |
| | | | |
[Alice calls Bob]
[アリスはボブに電話します]
F1 INVITE Alice -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
Supported: histinfo
F2 INVITE S-CSCF-B -> AS-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
[Bob's unconditional CDIV to Carol is triggered]
[ボブのキャロルへの無条件CDIVがトリガーされます]
F3 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
History-Info:
<sip:bob@example.com>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
[Alice's call is diverted to Carol]
[アリスの通話はキャロルに転送されます]
F4 INVITE S-CSCF-B -> AS-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
History-Info:
<sip:bob@example.com>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
F5 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
History-Info:
<sip:bob@example.com?privacy=history>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
[Forwarded leg to Carol is identified as an originating call after CDIV that allows Bob's privacy service to be applied to his identity within the History-Info header field]
[キャロルへの転送されたレッグは、CDIVの後に発信コールとして識別され、ボブのプライバシーサービスをHistory-Infoヘッダーフィールド内の自分のIDに適用できます]
F6 INVITE S-CSCF-B -> Carol
INVITE sip:carol@192.0.2.7 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
History-Info:
<sip:bob@example.com?privacy=history>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
<sip:carol@192.0.2.7>;index=1.1.1;rc=1.1
Figure 2. P-Served-User When Privacy Requested
図2.プライバシーが要求されたときのP-Served-User
The syntax of the P-Served-User header field [RFC5502] is updated in Section 4 of this document.
P-Served-Userヘッダーフィールド[RFC5502]の構文は、このドキュメントのセクション4で更新されています。
IANA has updated the existing row for the P-Served-User header field in the "Header Fields" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry:
IANAは、「Session Initiation Protocol（SIP）Parameters」レジストリ内の「Header Fields」サブレジストリにあるP-Served-Userヘッダーフィールドの既存の行を更新しました。
Header Name Compact Form Reference
------------- ------------ ------------------
P-Served-User none [RFC5502][RFC8498]
IANA has added new rows for the P-Served-User header field parameters in the "Header Field Parameters and Parameter Values" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry (as per the registry created by [RFC3968]):
IANAは、[Session Initiation Protocol（SIP）Parameters]レジストリ内の[Header Field Parameters and Parameter Values]サブレジストリにP-Served-Userヘッダーフィールドパラメータの新しい行を追加しました（[RFC3968]によって作成されたレジストリに従って）。
Header Field Parameter Name Predefined Values Reference
-------------- ---------------- ----------------- -------------
P-Served-User sescase Yes [RFC5502]
P-Served-User regstate Yes [RFC5502]
P-Served-User orig-cdiv No [RFC8498]
The security considerations in [RFC5502] apply.
[RFC5502]のセキュリティに関する考慮事項が適用されます。
As the "orig-cdiv" parameter of the P-Served-User header field can be used to trigger applications when a call is diverted, it is important to ensure that the parameter has not been added to the SIP message by an unauthorized SIP entity. Thus, the P-Served-User header field is to be used in a trusted environment, and proxies MUST NOT insert the header unless they have sufficient knowledge that the route set includes another trusted proxy.
P-Served-Userヘッダーフィールドの「orig-cdiv」パラメーターは、コールが転送されたときにアプリケーションをトリガーするために使用できるため、パラメーターが無許可のSIPエンティティによってSIPメッセージに追加されていないことを確認することが重要です。 。したがって、P-Served-Userヘッダーフィールドは信頼できる環境で使用する必要があり、ルートセットに別の信頼できるプロキシが含まれていることを十分に認識していない限り、プロキシはヘッダーを挿入してはなりません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, <https://www.rfc-editor.org/info/rfc3324>.
[RFC3324] Watson、M。、「Network Asserted Identityの短期要件」、RFC 3324、DOI 10.17487 / RFC3324、2002年11月、<https://www.rfc-editor.org/info/rfc3324>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8217] Sparks, R., "Clarifications for When to Use the name-addr Production in SIP Messages", RFC 8217, DOI 10.17487/RFC8217, August 2017, <https://www.rfc-editor.org/info/rfc8217>.
[RFC8217] Sparks、R。、「SIPメッセージでname-addrプロダクションを使用する場合の説明」、RFC 8217、DOI 10.17487 / RFC8217、2017年8月、<https://www.rfc-editor.org/info/ rfc8217>。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, <https://www.rfc-editor.org/info/rfc3968>.
[RFC3968] Camarillo、G。、「Session Initiation Protocol（SIP）のInternet Assigned Number Authority（IANA）ヘッダーフィールドパラメータレジストリ」、BCP 98、RFC 3968、DOI 10.17487 / RFC3968、2004年12月、<https：// www.rfc-editor.org/info/rfc3968>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc7044>。
[RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April 2009, <https://www.rfc-editor.org/info/rfc5502>.
[RFC5502] van Elburg、J。、「3GPP IPマルチメディア（IM）コアネットワーク（CN）サブシステム用のSIP P-Served-User Private-Header（P-Header）」、RFC 5502、DOI 10.17487 / RFC5502、4月2009、<https://www.rfc-editor.org/info/rfc5502>。
[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 11.28.0, December 2018.
[TS.3GPP.24.229] 3GPP、「セッション開始プロトコル（SIP）とセッション記述プロトコル（SDP）に基づくIPマルチメディアコール制御プロトコル、ステージ3」、3GPP TS 24.229 11.28.0、2018年12月。
[TS.3GPP.29.228] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents", 3GPP TS 29.228 15.1.0, September 2018.
[TS.3GPP.29.228] 3GPP、「IPマルチメディア（IM）サブシステムのCxおよびDxインターフェイス、シグナリングフローとメッセージコンテンツ」、3GPP TS 29.228 15.1.0、2018年9月。
Acknowledgments
謝辞
The author wishes to thank the 3GPP community for providing guidance, input, and comments on the document. Thanks to Dale Worley, Jean Mahoney, and Ben Campbell for their careful review of the document. Thanks to Paul Kyzivat and Adam Roach. A special thanks to Christer Holmberg.
著者は、ドキュメントに関するガイダンス、入力、コメントを提供してくれた3GPPコミュニティに感謝します。ドキュメントを注意深くレビューしてくれたDale Worley、Jean Mahoney、Ben Campbellに感謝します。 Paul KyzivatとAdam Roachに感謝します。 Christer Holmbergに特に感謝します。
Author's Address
著者のアドレス
Marianne Mohali Orange Orange Gardens, 44 avenue de la Republique Chatillon 92326 France
マリアンヌモハリオレンジオレンジガーデンズ、44通り、レピュブリックシャティヨン92326フランス
Email: marianne.mohali@orange.com