[要約] 要約：RFC 5502は、3GPP IP Multimedia Core Network SubsystemにおけるSIP P-Served-User Private-Header（P-Header）に関する仕様です。 目的：このRFCの目的は、3GPP IP Multimedia Core Network SubsystemでのSIP通信において、P-Served-User P-Headerを使用するための標準化とガイドラインを提供することです。
Network Working Group J. van Elburg
Request for Comments: 5502 Ericsson Telecommunicatie B.V.
Category: Informational April 2009
The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem
3GPP IPマルチメディア（IM）コアネットワーク（CN）サブシステム用のSIP P-Served-Userプライベートヘッダー（P-Header）
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation.
このドキュメントは、SIP P-Served-User P-Headerを指定します。このヘッダーフィールドは、S-CSCF（コールセッション制御機能）とISCの（アプリケーションサーバー）（IMSサービスコントロール）の間の第3世代パートナーシッププロジェクト（3GPP）IMS（IPマルチメディアサブシステム）で見つかった問題に対処します。） インターフェース。このヘッダーフィールドは、この特定の通信セッションとアプリケーションの呼び出しに適用されるサービスユーザーの身元とセッションケースを伝えます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions .....................................................3
3. Definitions .....................................................3
3.1. Identity, Network Asserted Identity, Trust Domain,
and Spec(T) ................................................3
3.2. Served User ................................................3
4. Scenarios .......................................................4
4.1. General ....................................................4
4.2. Diversion: Continue on Terminating Leg, but Finish
Subsequent Terminating iFC First ...........................5
4.3. Diversion: Create New Originating Leg and Provide
Originating iFC Processing .................................6
4.4. Call Out of the Blue: on Behalf of User B, but
Service Profile of Service Identity C.......................8
5. Requirements ....................................................8
6. P-Served-User Header Field Definition ...........................9
7. Proxy Behavior ..................................................9
7.1. Generating the P-Served-User Header ........................9
7.2. Consuming the P-Served-User Header ........................10
8. Applicability ..................................................10
9. IANA Considerations ............................................11
10. Security Considerations .......................................11
11. Acknowledgments ...............................................11
12. References ....................................................12
12.1. Normative References .....................................12
12.2. Informative References ...................................12
Appendix A. Why the History-Info Header Is Not Suitable to
Convey the Served User Information on the ISC
Interface ............................................13
A.1. Semantics ................................................13
A.2. Additional Observations ..................................13
A.3. Conclusion ................................................14
The 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) uses SIP (RFC 3261 [2]) as its main signaling protocol. (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [9] and 3GPP TS 24.229 [11].) 3GPP has identified issues with the linking in of a SIP application server that are most appropriately resolved by defining a new SIP P-header, according to the procedures in RFC 3427 [5].
第3世代パートナーシッププロジェクト（3GPP）IMS（IPマルチメディアサブシステム）は、SIP（RFC 3261 [2]）を主要なシグナル伝達プロトコルとして使用します。（IMSの詳細については、3GPP TS 23.228 [9]および3GPP TS 24.229 [11]。）3GPPは、定義することによって最も適切に解決されたSIPアプリケーションサーバーのリンクに関する問題を特定しました。RFC 3427 [5]の手順によると、新しいSIP P-Header。
The remainder of this document is organized as follows. Section 4 outlines the problem by using particular service scenarios, and Section 5 discusses the requirements derived from these scenarios. Section 6 defines the P-Served-User header field, which meets those requirements, Section 7 specifies the proxy behavior for the new header field, and Section 8 discusses the applicability and scope of this new header field. Section 9 registers the P-Served-User header field with the IANA, and Section 10 discusses the security properties of the environment where this header field is intended to be used.
このドキュメントの残りの部分は、次のように整理されています。セクション4では、特定のサービスシナリオを使用して問題の概要を説明し、セクション5では、これらのシナリオから派生した要件について説明します。セクション6では、これらの要件を満たすP-Served-Userヘッダーフィールドを定義し、セクション7で新しいヘッダーフィールドのプロキシ動作を指定し、セクション8では、この新しいヘッダーフィールドの適用性と範囲について説明します。セクション9では、IANAを使用してP-Served-User Headerフィールドを登録し、セクション10では、このヘッダーフィールドを使用することを目的としている環境のセキュリティプロパティについて説明します。
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 BCP 14, RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。
The terms Identity, Network Asserted Identity, Trust Domain, and Spec(T) in this document are specified in RFC 3324 [3].
このドキュメントのアイデンティティ、ネットワークアサートされたID、信頼ドメイン、および仕様（T）という用語は、RFC 3324 [3]で指定されています。
The served user to a proxy or AS (Application Server) is the user whose service profile is accessed by that proxy or AS when an initial request is received that is originated by, originated on behalf of, or terminated to that user. This profile in turn provides some useful information (preferences or permissions) for processing at a proxy and, potentially, at an AS.
提供されるユーザーは、プロキシまたは（アプリケーションサーバー）のユーザーが、そのプロキシによってサービスプロファイルにアクセスされるユーザー、またはそのユーザーに代わって発信、発信、または終了した初期リクエストが受信されたときです。このプロファイルは、プロキシで、潜在的にはASで処理するための有用な情報（設定または許可）を提供します。
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 allocated 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 allocated to that user.
3GPP IMS（IPマルチメディアサブシステム）では、S-CSCF（サービングCSCF）は、レジストラとして機能するSIPプロキシであり、それに割り当てられたユーザーの発信および終了セッション状態を処理します。これは、特定のユーザーから発信される呼び出しまたはその特定のユーザーに終了する呼び出しが、そのユーザーに割り当てられたS-CSCFを通過することを意味します。
At the moment that an S-CSCF is allocated for a specific user, a user profile is downloaded to the S-CSCF from the HSS (Home Subscriber Server) over the Cx interface, see 3GPP TS 29.228 [12]. This user profile tells the S-CSCF whether the user is allowed to originate or terminate calls or whether an AS needs to be linked in over the ISC interface. The user profile information that determines whether a particular initial request needs to be sent to a particular AS is called the initial Filter Criteria (iFC), see for example 3GPP TS 23.218 [8].
S-CSCFが特定のユーザーに割り当てられたときに、CXインターフェイスを介してHSS（Home Subscriber Server）からS-CSCFにユーザープロファイルがダウンロードされます。3GPPTS 29.228 [12]を参照してください。このユーザープロファイルは、S-CSCFに、ユーザーが呼び出しの発信または終了を許可されているかどうか、またはISCインターフェイスを介してリンクする必要があるかどうかを示します。特定の初期リクエストを特定の最初のフィルター基準（IFC）と呼ぶように特定のように送信する必要があるかどうかを判断するユーザープロファイル情報は、たとえば3GPP TS 23.218 [8]を参照してください。
For an S-CSCF to be able to meet its responsibilities, it needs to determine on which user's behalf it is performing its tasks and which session case is applicable for the particular request. (For a definition of session case, see 3GPP TS 29.228 [12]). The session case distinguishes the originating and terminating call cases and determines whether or not the particular user is registered.
S-CSCFが責任を果たすことができるためには、どのユーザーに代わってタスクを実行し、どのセッションケースが特定のリクエストに適用できるかを決定する必要があります。（セッションケースの定義については、3GPP TS 29.228 [12]を参照してください）。セッションケースは、発信および終了のコールケースを区別し、特定のユーザーが登録されているかどうかを決定します。
When the S-CSCF determines that for an incoming initial request the originating call case applies, it determines the served user by looking at the P-Asserted-Identity header field (RFC 3325 [4]), which carries the network asserted identity of the originating user. When, after processing the iFC for this initial request, the S-CSCF decides to forward the request to an AS, the AS has to go through a similar process of determining the session case and the served user. Since it should come to the same conclusion that this is an originating session case, it also has to look at the P-Asserted-Identity header field to determine the served user.
S-CSCFが着信初期リクエストのために発信元のコールケースが適用されると判断すると、P-Asserted-Identityヘッダーフィールド（RFC 3325 [4]）を見ることでサービスユーザーを決定します。元のユーザー。この最初の要求のためにIFCを処理した後、S-CSCFはASにリクエストをASに転送することを決定しました。ASは、セッションケースとサービスユーザーを決定する同様のプロセスを経る必要があります。これは発生するセッションのケースであるという同じ結論に達するはずであるため、サービスユーザーを決定するためにP-Asserted-Identityヘッダーフィールドを調べる必要があります。
When the S-CSCF determines that for an incoming initial request the terminating call case applies, it determines the served user by looking at the Request-URI (RFC 3261 [2]), which carries the identity of the intended terminating user. When, after processing the iFC for this initial request, the S-CSCF decides to forward the request to an AS, the AS has to go through a similar process of determining the session case and the served user. Since it should come to the same conclusion that this is a terminating session case, it also has to look at the Request-URI to determine the served user.
S-CSCFが、着信初期リクエストの場合、終了コールケースが適用されると判断すると、意図した終了ユーザーの身元を伝えるRequest-URI（RFC 3261 [2]）を調べることにより、サービスユーザーを決定します。この最初の要求のためにIFCを処理した後、S-CSCFはASにリクエストをASに転送することを決定しました。ASは、セッションケースとサービスユーザーを決定する同様のプロセスを経る必要があります。これは終了セッションのケースであるという同じ結論に達するはずであるため、サービスユーザーを決定するためにリクエスト-URIを調べる必要があります。
In the originating case, it can be observed that while the P-Asserted-Identity header field just represents the originating user when it enters the S-CSCF, it is overloaded with another meaning when it is sent to an AS over the ISC interface. This other meaning is that it serves as a representation of the served user.
発信元の場合、P-Asserted-Identityヘッダーフィールドは、S-CSCFに入るときに発生するユーザーを表すだけで、ISCインターフェイス上のASに送信されると別の意味で過負荷になることが観察できます。この他の意味は、サービスユーザーの表現として機能することです。
In the terminating case, a similar overloading happens to the Request-URI; while it first only represented the identity of the intended terminating user, it is overloaded with another meaning when it is sent to an AS over the ISC interface. This other meaning is that it serves as a representation of the served user.
終了の場合、同様の過負荷がリクエスト-URIに発生します。最初は、意図した終了ユーザーのIDのみを表していますが、ISCインターフェイス上のASに送信されると、別の意味が過負荷になります。この他の意味は、サービスユーザーの表現として機能することです。
In basic call scenarios, this does not show up as a problem, but once more complicated service scenarios (notably forwarding services) need to be realized, it poses severe limitations. Such scenarios are brought forward in the following subsections.
基本的なコールシナリオでは、これは問題として表示されませんが、もう一度複雑なサービスシナリオ（特に転送サービス）を実現する必要があり、厳しい制限をもたらします。このようなシナリオは、次のサブセクションで提出されます。
Imagine a service scenario where a user B has a terminating service that diverts the call to a different destination but is required to still execute subsequent terminating services for the same user. This means that this particular user has multiple iFC configured that are applicable for an incoming initial request. When the S-CSCF receives an initial INVITE request, it analyzes the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI.
ユーザーBが別の目的地に通話を転用するが、同じユーザーの後続の終了サービスを実行する必要がある終了サービスを持っているサービスシナリオを想像してください。これは、この特定のユーザーが、着信初期リクエストに適用できる複数のIFC構成を備えていることを意味します。S-CSCFが最初の招待リクエストを受信すると、リクエストを分析し、セッションケースが終了した登録ユーザー向けであると判断し、リクエストURIを調べてサービスユーザーがユーザーBになると判断します。
Now the S-CSCF starts the iFC processing. The first iFC that matches the INVITE request causes the INVITE to be forwarded over the ISC interface to an AS that hosts user B's diversion service by adding the AS and S-CSCF's own hostnames to the Route header. The S-CSCF adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname on the Route header. This allows the S-CSCF to correlate an INVITE coming from an AS over the ISC interface to the existing session that forwarded the INVITE to the AS in the first place.
これで、S-CSCFはIFC処理を開始します。招待リクエストに一致する最初のIFCは、ASとS-CSCF独自のホスト名をルートヘッダーに追加することにより、AS HOSTユーザーBの転用サービスをAS AS ASにAS ASに転送します。S-CSCFは、ルートヘッダーのS-CSCF独自のホスト名に元のダイアログ識別子（ODI）を追加します。これにより、S-CSCFは、ISCインターフェイスを介してASの招待状を既存のセッションに相関させることができます。
When the AS receives the initial INVITE request, it analyzes the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI. Based on some criteria, the diversion service concludes that the request needs to be diverted to another user or application C. It does this by changing the Request-URI to C. Optionally, it records the Request-URI history by using the History- Info header field (RFC 4244 [7]). Then the AS removes itself from the Route header and routes the INVITE request back to the S-CSCF by using the topmost Route header field.
ASが最初の招待リクエストを受信すると、リクエストを分析し、セッションケースが終了した登録ユーザー用であると判断し、リクエストURIを調べてサービスユーザーがユーザーBになると判断します。いくつかの基準に基づいて、転用サービスは、リクエストを別のユーザーまたはアプリケーションCに転用する必要があると結論付けています。これは、リクエスト-URIをCに変更することでこれを行います。ヘッダーフィールド（RFC 4244 [7]）。次に、Asはルートヘッダーからそれ自体を削除し、最上部のルートヘッダーフィールドを使用して招待要求をS-CSCFにルーティングします。
When the S-CSCF receives the INVITE over the ISC interface, it can see that the Route header contains its own hostname and an ODI that correlates to an existing terminating session for user B. This can be used by the S-CSCF to analyze whether there are still unexecuted iFC. (Note that the current behavior of the S-CSCF on receiving an INVITE with a changed Request-URI is to terminate the iFC processing and to route the request based on the new Request-URI value.)
S-CSCFがISCインターフェイス上の招待を受信すると、ルートヘッダーには、ユーザーBの既存の終端セッションに相関する独自のホスト名とODIが含まれていることがわかります。まだ不明確なIFCがあります。（変更されたリクエスト-URIで招待を受信する際のS-CSCFの現在の動作は、IFC処理を終了し、新しいリクエスト-URI値に基づいてリクエストをルーティングすることであることに注意してください。）
The process repeats itself. The INVITE is forwarded to the AS that is associated with this particular iFC. When the AS receives the initial INVITE request, it analyzes the request and determines that the session case is for a terminating registered user, then it determines the served user to be user C by looking at the Request-URI. This is clearly wrong, as the user being served is still user B.
プロセスはそれ自体を繰り返します。招待状は、この特定のIFCに関連付けられているASに転送されます。ASが最初の招待リクエストを受信すると、リクエストを分析し、セッションケースが終了した登録ユーザー用であると判断し、リクエストURIを調べてサービスユーザーがユーザーCになると判断します。これは明らかに間違っています。提供されているユーザーはまだユーザーBです。
This scenario clearly shows the problem that occurs when the Request-URI is overloaded with the meanings "intended target identity" and "served user" with the operation as described in Section 4.1. And it shows that this use case can not be realized without introducing a mechanism that conveys information about the served user from the S-CSCF to the AS. Use of the History-Info element does not solve this problem as it does not tell the AS which user is being served; it just presents a history of diversions that might not be even caused by the systems serving this particular user. A more detailed analysis on why the History-Info header field can't be used is provided in Appendix A.
このシナリオは、セクション4.1で説明されているように、リクエスト-URIが意味「意図されたターゲットアイデンティティ」および「サービスユーザー」を操作で過負荷にしたときに発生する問題を明確に示しています。また、このユースケースは、サービスユーザーに関する情報をS-CSCFからASに伝えるメカニズムを導入せずに実現できないことを示しています。履歴INFO要素の使用は、どのユーザーが提供されているかを知らないため、この問題を解決しません。これは、この特定のユーザーにサービスを提供するシステムによってさえ引き起こされない可能性のある転換の歴史を提示するだけです。History-INFOヘッダーフィールドを使用できない理由に関するより詳細な分析は、付録Aに記載されています。
Imagine a service scenario where a user B has a terminating service that diverts the call to a different destination. It is required that a forwarded call leg is handled as an originating call leg and that originating services for user B are executed. This means that this particular user has one or more iFC configured that are applicable for an outgoing initial request.
ユーザーBが別の目的地に通話を転用する終了サービスを持っているサービスシナリオを想像してください。転送されたコールレッグは、元のコールレッグとして処理され、ユーザーBの発信サービスが実行されることが必要です。これは、この特定のユーザーが、発信初期リクエストに適用できる1つ以上のIFC構成を備えていることを意味します。
When the S-CSCF receives an initial INVITE request, it analyzes the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI.
S-CSCFが最初の招待リクエストを受信すると、リクエストを分析し、セッションケースが終了した登録ユーザー向けであると判断し、リクエストURIを調べてサービスユーザーがユーザーBになると判断します。
Now the S-CSCF starts the iFC processing. The first iFC that matches the INVITE request causes the INVITE to be forwarded over the ISC interface to an AS that hosts user B's diversion service by adding the AS and S-CSCF's own hostnames to the Route header. The S-CSCF adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname on the Route header. This allows the S-CSCF to correlate an INVITE coming from an AS over the ISC interface to the existing session that forwarded the INVITE to the AS in the first place.
これで、S-CSCFはIFC処理を開始します。招待リクエストに一致する最初のIFCは、ASとS-CSCF独自のホスト名をルートヘッダーに追加することにより、AS HOSTユーザーBの転用サービスをAS AS ASにAS ASに転送します。S-CSCFは、ルートヘッダーのS-CSCF独自のホスト名に元のダイアログ識別子（ODI）を追加します。これにより、S-CSCFは、ISCインターフェイスを介してASの招待状を既存のセッションに相関させることができます。
When the AS receives the initial INVITE request, it analyzes the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI. Based on some criteria, the diversion service concludes that the request needs to be diverted to another user or application C. It does this by changing the Request-URI to C. Optionally, it records the Request-URI history by using the History-Info header field (RFC 4244 [7]). Then the AS removes itself from the Route header. To make sure that the request is handled as a new originating call on behalf of user B, the AS adds the "orig" parameter to the topmost route header. Then it routes the INVITE request back to the S-CSCF by using this topmost Route header field.
ASが最初の招待リクエストを受信すると、リクエストを分析し、セッションケースが終了した登録ユーザー用であると判断し、リクエストURIを調べてサービスユーザーがユーザーBになると判断します。いくつかの基準に基づいて、転用サービスは、リクエストを別のユーザーまたはアプリケーションCに転用する必要があると結論付けています。これは、リクエスト-URIをCに変更することでこれを行います。ヘッダーフィールド（RFC 4244 [7]）。次に、Asはルートヘッダーからそれ自体を削除します。リクエストがユーザーBに代わって新しい発信の呼び出しとして処理されることを確認するために、ASは「Orig」パラメーターを最上部のルートヘッダーに追加します。次に、この最上部のルートヘッダーフィールドを使用して、招待リクエストをS-CSCFにルーティングします。
When the S-CSCF receives the INVITE over the ISC interface, it can see that the topmost Route header contains its own hostname and an "orig" parameter. Because the topmost Route header contains the "orig" parameter, the S-CSCF concludes that the INVITE should be handled as if a call is originated by the served user. The served user is determined from the P-Asserted-Identity header to be user A. This is clearly wrong, as the user being served is and should be user B.
S-CSCFがISCインターフェイスを介して招待を受信すると、最上部のルートヘッダーに独自のホスト名と「Orig」パラメーターが含まれていることがわかります。最上部のルートヘッダーには「Orig」パラメーターが含まれているため、S-CSCFは、招待状が提供されたユーザーによって発信されるかのように招待状を処理する必要があると結論付けます。サーブユーザーは、P-Asserted-IdentityヘッダーからユーザーAに決定されます。これは明らかに間違っています。
For the sake of discussion, let's assume that the S-CSCF can determine that the served user is user B. Then the procedure would continue as follows: The S-CSCF starts the originating iFC processing, the first iFC that matches the INVITE request causes the INVITE to be forwarded over the ISC interface to an AS that hosts an originating service of user B by adding the AS and S-CSCF's own hostnames to the Route header. The S-CSCF adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname on the Route header.
議論のために、S-CSCFが提供されるユーザーがユーザーBであると判断できると仮定しましょう。その場合、手順は次のように継続します。S-CSCFは、招待リクエストの原因と一致する最初のIFCを起動します。ASとS-CSCF独自のホスト名をルートヘッダーに追加することにより、ISCインターフェイスを介してASに転送されるAS ASにaSに転送されるASにaSに転送されます。S-CSCFは、ルートヘッダーのS-CSCF独自のホスト名に元のダイアログ識別子（ODI）を追加します。
The INVITE is forwarded to the AS that is associated with this particular iFC. When the AS receives the initial INVITE request, it analyzes the request and determines that the session case is for an originating registered user, then it determines the served user to be user A by looking at the P-Asserted-Identity. This is clearly wrong, as the user being served is and should be user B.
招待状は、この特定のIFCに関連付けられているASに転送されます。ASが最初の招待リクエストを受信すると、リクエストを分析し、セッションケースが登録されたユーザー向けであると判断し、P-Asserted-Identityを調べてサービスユーザーがユーザーAになると判断します。これは明らかに間違っています。提供されているユーザーはユーザーBである必要があります。
This scenario clearly shows the problem that occurs when the P-Asserted-Identity is overloaded with the meanings "call originator" and "served user" with the operation as described in Section 4.1. And it shows that this use case can not be realized without introducing a mechanism that conveys information about the served user from the S-CSCF to the AS and from the AS to the S-CSCF. Use of the History-Info element does not solve this problem as it does not tell the AS which user is being served, but just presents a history of diversions that might not be even caused by the systems serving this particular user. A more detailed analysis on why the History-Info header field can't be used is provided in Appendix A.
このシナリオは、セクション4.1で説明されているように、p-asserted-Identityが「コールオリジネーター」と「サーブユーザー」という意味で過負荷になったときに発生する問題を明確に示しています。また、このユースケースは、SCSCFからS-CSCFからS-CSCFにサービスを提供するメカニズムを導入することなく、実現できないことを示しています。History-INFO要素の使用は、どのユーザーが提供されているかを知らないため、この問題を解決しませんが、この特定のユーザーにサービスを提供するシステムによってさえ引き起こされない可能性のある迂回の履歴を提示するだけです。History-INFOヘッダーフィールドを使用できない理由に関するより詳細な分析は、付録Aに記載されています。
There are services that need to be able to initiate a call, whereby the call appears to be coming from a user B but the service profile on behalf of service identity C needs to be executed in the S-CSCF.
通話を開始できる必要があるサービスがあります。これにより、通話はユーザーBから来ているように見えますが、サービスIDに代わってサービスプロファイルをS-CSCFで実行する必要があります。
When a call needs to appear as coming from user B, that means that the P-Asserted-Identity needs to contain B's identity. This is because the Originating Identity Presentation (OIP) service as defined in 3GPP TS 24.173 [10] uses the P-Asserted-Identity to present the call originator. This makes sense because that is the main meaning expressed by the P-Asserted-Identity header field.
通話がユーザーBから来るように表示される必要がある場合、それはP-Asserted-IdentityがBのIDを封じ込める必要があることを意味します。これは、3GPP TS 24.173 [10]で定義されている発信元IDプレゼンテーション（OIP）サービスがP-Asserted-Identityを使用してコールオリジネーターを提示するためです。これは、P-Asserted-Identityヘッダーフィールドで表現される主な意味であるため、理にかなっています。
It is clear that no INVITE request can be constructed currently that would achieve both requirements expressed in the first paragraph, because the P-Asserted-Identity is overloaded with two meanings on the ISC interface. When the S-CSCF will receive this request, it will determine that the served user is user B, which is not what we want to achieve.
P-Asserted-IdentityがISCインターフェイスに2つの意味で過負荷になっているため、最初の段落で表現された両方の要件を達成する招待リクエストを現在構築できないことは明らかです。S-CSCFがこのリクエストを受信すると、サーブユーザーがユーザーBであると判断されますが、これは達成したいものではありません。
This section lists the requirements derived from the previous scenarios:
このセクションには、以前のシナリオから派生した要件をリストします。
1. To be able to offer real-world application services, it is required that the identity of the served user can be conveyed on the ISC interface (see 3GPP TS 23.218 [8]).
1. 実際のアプリケーションサービスを提供できるようにするには、サービスユーザーの身元をISCインターフェイスで伝達できる必要があります（3GPP TS 23.218 [8]を参照）。
2. To be able to offer appropriate services to the served user, it is required that in addition to the served user identity the session case is conveyed.
2. サービスユーザーに適切なサービスを提供できるようにするには、サービスユーザーのIDに加えて、セッションケースが伝達されることが必要です。
This document defines the SIP P-Served-User P-header. This header field can be added to initial requests for a dialog or standalone requests, which are routed between nodes in a Trust Domain for P-Served-User. The P-Served-User P-header contains an identity of the user that represents the served user. The "sescase" parameter may be used to convey whether the initial request is originated by or destined for the served user. The "regstate" parameter may be used to indicate whether the initial request is for a registered or unregistered user.
このドキュメントでは、SIP P-Served-User P-Headerを定義します。このヘッダーフィールドは、ダイアログまたはスタンドアロンリクエストの初期リクエストに追加できます。これは、P-Sived-Userのトラストドメイン内のノード間でルーティングされます。P-Sived-User P-Headerには、サービスユーザーを表すユーザーのIDが含まれています。「SESCASE」パラメーターを使用して、最初のリクエストがサービスユーザーによって発信されるか、運命づけられているかを伝えることができます。「レグステート」パラメーターを使用して、登録されたユーザーまたは未登録のユーザーの最初の要求があるかどうかを示すことができます。
The augmented Backus-Naur Form (BNF) (RFC 5234 [6]) syntax of the P-Served-User header field is as follows:
拡張されたBackus-Naurフォーム（BNF）（RFC 5234 [6]）P-Served-Userヘッダーフィールドの構文は次のとおりです。
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"
registration-state-param = "regstate" EQUAL "unreg" / "reg"
EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are defined in RFC 3261 [2].
Equal、hcolon、semi、name-addr、addr-spec、および汎用パラムは、RFC 3261 [2]で定義されています。
The following is an example of a P-Served-User header field:
以下は、P-Served-Userヘッダーフィールドの例です。
P-Served-User: <sip:user@example.com>; sescase=orig; regstate=reg
Proxies that support the header MUST only insert the header in initial requests for a dialog or in standalone requests when the following conditions hold:
ヘッダーをサポートするプロキシは、次の条件が保持されている場合にのみ、ダイアログの最初のリクエストまたはスタンドアロン要求にヘッダーを挿入する必要があります。
o The proxy has the capability to determine the served user for the current request.
o プロキシには、現在のリクエストのために提供されるユーザーを決定する機能があります。
o The next hop is part of the same Trust Domain for P-Served-User.
o 次のホップは、P-Served-Userの同じ信頼ドメインの一部です。
When the above conditions do not hold, the proxy MUST NOT insert the header.
上記の条件が保持されない場合、プロキシはヘッダーを挿入してはなりません。
A proxy that supports the header MUST, upon receiving from a trusted node the P-Served-User header in initial requests for a dialog or in standalone requests, take the value of the P-Served-User header to represent the served user in operations that require such information.
ヘッダーをサポートするプロキシは、ダイアログまたはスタンドアロンリクエストの最初のリクエストで、信頼できるノードからP-Sived-Userヘッダーを受信すると、P-Severve-Userヘッダーの値を取り、サービスユーザーを操作するユーザーを表現する必要があります。そのような情報が必要です。
A proxy that supports the header MUST remove the header from requests or responses when the header was received from a node outside the Trust Domain for P-Served-User before further forwarding the message.
ヘッダーをサポートするプロキシは、メッセージをさらに転送する前に、PS-Sived-Userのトラストドメインの外側のノードからヘッダーを受信したときに、リクエストまたは応答からヘッダーを削除する必要があります。
A proxy that supports the header MUST remove the header from requests or responses when the next hop is a node outside the Trust Domain for P-Served-User before further forwarding the message.
ヘッダーをサポートするプロキシは、メッセージをさらに転送する前に、次のホップがPに適したユーザーのトラストドメインの外側のノードである場合、リクエストまたは応答からヘッダーを削除する必要があります。
According to RFC 3427 [5], P-headers have a limited applicability. Specifications of P-headers, such as this RFC, need to clearly document the useful scope of the proposal and explain its limitations and why it is not suitable for the general use of SIP on the Internet.
RFC 3427 [5]によると、Pヘッダーの適用性は限られています。このRFCなどのPヘッダーの仕様は、提案の有用な範囲を明確に文書化し、その限界と、インターネット上でのSIPの一般的な使用に適していない理由を説明する必要があります。
The use of the P-Served-User header field extensions is only applicable inside a Trust Domain for served user. 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 Headerフィールド拡張機能の使用は、サービスユーザーのトラストドメイン内でのみ適用されます。このような信頼ドメインのノードは、サービスユーザーを伝え、信頼ドメイン以外でその情報を差し控える責任を負うように互いに明示的に信頼しています。ネットワークが提供されるユーザーを決定する手段と、特定のサービスユーザーに対して実行されるポリシーは、このドキュメントの範囲外です。
The served user information lacks an indication of who or what specifically determined the served user, and so it must be assumed that the Trust Domain determined the served user. Therefore, the information is only meaningful when securely received from a node known to be a member of the Trust Domain.
提供されるユーザー情報には、誰または何がサーブユーザーを決定したかの兆候がないため、信頼ドメインがサーブユーザーを決定したと想定する必要があります。したがって、情報は、信頼ドメインのメンバーであることが知られているノードから安全に受信された場合にのみ意味があります。
Because the served user typically only has validity in one administrative domain, it is in general not suitable for inter-domain use or use in the Internet at large.
サービスユーザーは通常、1つの管理ドメインでのみ有効性を持っているため、一般的にはインターネットでのドメイン間の使用または使用には適していません。
Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and that can accept the limitations that result, to warrant informational publication of this mechanism. An example deployment would be a closed network like 3GPP IMS.
これらの制限にもかかわらず、上記の仮定を満たす十分に有用な専門的な展開があり、このメカニズムの情報公開を保証するために結果の制限を受け入れることができます。展開の例は、3GPPIMSのようなクローズドネットワークです。
This document defines a new SIP header field: P-Served-User. This header field has been registered by the IANA in the SIP Parameters registry under the Header Fields subregistry.
このドキュメントでは、新しいSIPヘッダーフィールド：P-Served-Userを定義しています。このヘッダーフィールドは、ヘッダーフィールドサブレジストリの下にあるSIPパラメータレジストリにIANAによって登録されています。
The P-Served-User header field defined in this document is to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPsec and sometimes by physically protecting the network. In any case, the environment where the P-Served-User header field will be used ensures the integrity and the confidentiality of the contents of this header field.
このドキュメントで定義されているP-Sived-User Headerフィールドは、要素が信頼されており、攻撃者がそれらの要素間のプロトコルメッセージにアクセスできない環境で使用されます。ネットワーク要素間の交通保護は、IPSECを使用し、場合によってはネットワークを物理的に保護することによって達成されることがあります。いずれにせよ、P-Served-Userヘッダーフィールドが使用される環境により、このヘッダーフィールドの内容の整合性と機密性が保証されます。
The Spec(T) that defines the Trust Domain for P-Served-User MUST require that member nodes understand the P-Served-User header extension.
p-sived-userの信頼ドメインを定義する仕様（t）は、メンバーノードがP-Seversed-Userヘッダー拡張を理解することを要求する必要があります。
There is a security risk if a P-Served-User header field is allowed to propagate out of the Trust Domain where it was generated. In that case, user-sensitive information would be revealed. To prevent such a breach from happening, proxies MUST NOT insert the header when forwarding requests to a hop that is located outside the Trust Domain. When forwarding the request to a node in the Trust Domain, proxies MUST NOT insert the header unless they have sufficient knowledge that the route set includes another proxy in the Trust Domain that understands the header, such as the home proxy. There is no automatic mechanism to learn the support for this specification. Proxies MUST remove the header when forwarding requests to nodes that are not in the Trust Domain or when the proxy does not have knowledge of any other proxy included in the route set that will remove it before it is routed to any node that is not in the Trust Domain.
P-Served-Userヘッダーフィールドが生成された信頼ドメインから伝播することが許可されている場合、セキュリティリスクがあります。その場合、ユーザーに敏感な情報が明らかになります。このような違反が発生しないようにするために、プロキシは、信頼ドメインの外側にあるホップにリクエストを転送するときにヘッダーを挿入してはなりません。リクエストをトラストドメインのノードに転送する場合、ルートセットにホームプロキシなどのヘッダーを理解するトラストドメインに別のプロキシが含まれているという十分な知識がない限り、プロキシはヘッダーを挿入してはなりません。この仕様のサポートを学習する自動メカニズムはありません。プロキシは、信頼ドメインにないノードにリクエストを転送する場合、またはプロキシがルートセットに含まれる他のプロキシの知識がない場合、ヘッダーを削除する必要があります。信頼ドメイン。
Alf Heidermark, Hubert Przybysz, and Erik Rolin for the discussion that led to the solution written down in this document. Spencer Dawkins for performing the expert review. Jon Peterson for performing the AD review. Gonzalo Camarillo, Paul Kyzivat, Nils Haenstroem, Arunachalam Venkatraman, Mikael Forsberg, Miguel Garcia, Jozsef Varga, Keith Drage, Tim Polk, and Cullen Jennings for providing improvements. Francis Dupont for performing the general area review. Sandy Murphy for performing the security area review.
Alf Heidermark、Hubert Przybysz、およびErik Rolinは、この文書に書き留めた解決策につながった議論のために。専門家のレビューを実行してくれたスペンサードーキンス。広告レビューを実行してくれたJon Peterson。ゴンザロ・カマリロ、ポール・キジバット、ニルズ・ハーンストローム、アルナチャラム・ベンカトラマン、ミカエル・フォースバーグ、ミゲル・ガルシア、ジョッズフ・バルガ、キース・ドレイジ、ティム・ポーク、カレン・ジェニングスが改善を提供しました。一般的なエリアレビューを実行したフランシスデュポン。セキュリティエリアのレビューを実行したサンディマーフィー。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] 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.
[2] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[3] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[3] ワトソン、M。、「ネットワーク主張されたアイデンティティの短期要件」、RFC 3324、2002年11月。
[4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[4] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
[5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[5] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J。、およびB. Rosen、「セッション開始プロトコルの変更プロセス（SIP）」、BCP 67、RFC 3427、12月2002年。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[6] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[7] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[7] Barnes、M。、「リクエスト履歴情報のセッション開始プロトコル（SIP）の拡張」、RFC 4244、2005年11月。
[8] 3GPP, "IP Multimedia (IM) session handling; IM call model; Stage 2", 3GPP TS 23.218 V7.
[8] 3GPP、「IPマルチメディア（IM）セッションハンドリング; IMコールモデル、ステージ2 "、3GPP TS 23.218 V7。
[9] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 V7.
[9] 3GPP、「IPマルチメディアサブシステム（IMS）、ステージ2」、3GPP TS 23.228 V7。
[10] 3GPP, "IMS multimedia telephony communication service and supplementary services; Stage 3", 3GPP TS 24.173 V7.
[10] 3GPP、「IMSマルチメディアテレフォニー通信サービスおよび補足サービス、ステージ3」、3GPP TS 24.173 V7。
[11] 3GPP, "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 V7.
[11] 3GPP、「インターネットプロトコル（IP）セッション開始プロトコル（SIP）およびセッション説明プロトコル（SDP）、ステージ3 "、3GPP TS 24.229 V7に基づくマルチメディアコールコントロールプロトコル。
[12] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents", 3GPP TS 29.228 V7.
[12] 3GPP、「IPマルチメディア（IM）サブシステムCXおよびDXインターフェイス、シグナリングフローとメッセージコンテンツ」、3GPP TS 29.228 V7。
Appendix A. Why the History-Info Header Is Not Suitable to Convey the Served User Information on the ISC Interface
付録A. 履歴INFOヘッダーがISCインターフェイスで提供されるユーザー情報を伝えるのに適していない理由
The History-Info (as specified in RFC 4244 [7]) holds a record of subsequent Request-URI values that are put on an initial request during its processing in the network.
History-INFO（RFC 4244 [7]で指定されている）には、ネットワークでの処理中に最初のリクエストに配置されたその後のリクエストURI値の記録が記録されています。
If it would be possible at all to use the History-Info header for the purpose of communicating the served user, then again the same overloading would occur as the one that we are trying to get rid of (Section 4.2). In this case, we overload the particular History-Info header field's hi-entry with the meaning "historic target identity" and "served user".
サーブユーザーを通信する目的で履歴INFOヘッダーを使用できる場合、再び同じ過負荷が発生し、私たちが取り除こうとしているものと同じ過負荷が発生します（セクション4.2）。この場合、特定のHistory-infoヘッダーフィールドのHi-entryに「歴史的ターゲットアイデンティティ」と「サーブユーザー」という意味にオーバーロードします。
Another reason that the History-Info header can not solve the requirements as expressed in this document is that, in originating session case scenarios, the served user is currently determined from the P-Asserted-Identity, as that header field contains the asserted originating user's identity. The History-Info header, being a record of Request-URIs, can never be a solution for this case.
履歴INFOヘッダーがこのドキュメントで表明されているように要件を解決できないもう1つの理由は、セッションケースのシナリオで、そのヘッダーフィールドには主張された元のユーザーが含まれているため、サービスユーザーが現在P容認された同一性から決定されていることです。身元。リクエスト・ウリスの記録である歴史とFOのヘッダーは、このケースの解決策になることはありません。
Looking at the call-out-of-the-blue scenario (Section 4.4), it is impossible to construct a History-Info header for an INVITE request on behalf of user C that appears to come from user B and targets user D that would express the served user C without violating the original semantics of the History-Info header according to (RFC 4244 [7]).
ブルーの呼び出しシナリオ（セクション4.4）を見ると、ユーザーBから来ていると思われるユーザーCに代わって招待リクエストの履歴ヘッダーを作成することは不可能です。（RFC 4244 [7]）に従って、履歴INFOヘッダーの元のセマンティクスに違反することなく、提供されるユーザーCを表現します。
The purpose of the History-Info header is a header that has an end-to-end application. For the purpose of informing an AS on the ISC interface, this is overkill.
History-INFOヘッダーの目的は、エンドツーエンドのアプリケーションを備えたヘッダーです。ISCインターフェイスでASを通知する目的で、これは過剰です。
At the moment that the AS receives an initial INVITE over the ISC interface, this INVITE may have passed a vast number of proxies that may or may not have added history information. On top of that, the request may have traversed several AS instances for the same served user. In case several subsequent iFC are active, all these AS instances may perform a forwarding. This means that it is not possible to define an algorithm that points out which hi-entry of a History-Info header should represent the served user. In other words, a History-Info header field with n entries expresses a branch of depth n. Any or none of these elements could be the served user identity.
ASがISCインターフェイスを介した最初の招待状を受け取った瞬間、この招待は、履歴情報を追加した場合と持っていない場合がある膨大な数のプロキシを通過した可能性があります。それに加えて、リクエストは、同じサービスユーザーのインスタンスとしていくつかを通過した可能性があります。いくつかの後続のIFCがアクティブになった場合、これらはすべてインスタンスとして転送を実行する可能性があります。これは、History-infoヘッダーのどのhi-entryがサービスユーザーを表すべきかを指摘するアルゴリズムを定義することができないことを意味します。言い換えれば、nエントリを持つ履歴INFOヘッダーフィールドは、深さnの分岐を表します。これらの要素はいずれも、または提供されるユーザーのアイデンティティになる可能性があります。
The History-Info header does not comply with the second requirement as expressed in Section 5, as it does not have a means to express the session case in a natural way.
History-INFOヘッダーは、セクション5で表明された2番目の要件に準拠していません。これは、セッションケースを自然な方法で表現する手段がないためです。
Each observation in the previous subsections, alone, is enough to disregard the History-Info header as an information element that is suitable for transporting the served user information over the ISC interface.
以前のサブセクションでの各観測では、ISCインターフェイスを介して提供されるユーザー情報を輸送するのに適した情報要素として履歴INFOヘッダーを無視するのに十分です。
Note that this does not prohibit the use of the P-Served-User header and the History-Info header in the same request. In fact that will be a quite likely scenario for network-based diversion services like, for example, the Communication Diversion service as specified in (3GPP TS 24.173 [10]).
これは、同じリクエストでP-Served-UserヘッダーとHistory-INFOヘッダーの使用を禁止していないことに注意してください。実際、（3GPP TS 24.173 [10]）で指定されている通信迂回サービスなど、ネットワークベースの迂回サービスの非常に可能性の高いシナリオになります。
Author's Address
著者の連絡先
Hans Erik van Elburg Ericsson Telecommunicatie B.V. Ericssonstraat 2 Rijen 5121 ML Netherlands
Hans Erik Van Elburg Ericsson Telecommunicatie B.V. Ericssonstraat 2 Rijen 5121 ml Netherlands
EMail: HansErik.van.Elburg@ericsson.com