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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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-サーブドユーザPヘッダを指定します。このヘッダーフィールドは、ISCのS-CSCF（サービング呼セッション制御機能）とAS（アプリケーションサーバ）（IMSサービスコントロール間の3GPP（3rd Generation Partnership Project）のIMS（IPマルチメディアサブシステム）で発見された問題に対処します）インターフェース。このヘッダーフィールドは、サービス対象ユーザと、この特定の通信セッションおよびアプリケーションの呼び出しに適用されるセッションケースのIDを伝えます。
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アプリケーションサーバの中にリンクの問題を特定しました新しいSIP P-ヘッダ、RFC 3427の手順に従って、[5]。
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は、セクション7は、新たなヘッダフィールドのプロキシ動作を指定し、そして部8は、この新たなヘッダフィールドの適用性と範囲を説明し、それらの要件を満たしているP-サーブドユーザヘッダフィールドを定義します。セクション9件のIANAに登録P-サーブドユーザヘッダフィールド、およびセクション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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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（アプリケーションサーバ）へのサービス対象ユーザは、そのサービスプロファイルそのプロキシによって、または最初の要求はそれがによって発信された受信されたときのようにアクセスされ、代わって発信し、またはその利用者に終端ユーザーです。次に、このプロファイルは、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は、特定のユーザに割り当てられているその瞬間に、ユーザプロファイルは、3GPP TS 29.228 [12]を参照のCxインタフェースを介してHSS（ホーム加入者サーバ）からS-CSCFにダウンロードされます。このユーザープロファイルは、ユーザーが通話を発信または終了することが許可されているかどうかASは、ISCインタフェースを介してでリンクする必要があるかどうかをS-CSCFに指示します。特定の初期の要求が特定のASに送信する必要があるかどうかを判断するユーザプロファイル情報は、例えば3GPP TS 23.218を参照、初期フィルタ基準（IFC）と呼ばれている[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は、セッションケースとサービス対象ユーザを決定するための同様のプロセスを経る必要があります。それは、これが元のセッションの場合であるのと同じ結論に来るはずなので、それはまた、サービス対象ユーザを決定するために、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は、セッションケースとサービス対象ユーザを決定するための同様のプロセスを経る必要があります。それは、これが終了セッションケースで同じ結論に来るはずなので、それはまた、サービス対象ユーザを決定するためのRequest-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.
元の場合、S-CSCFに入ったときにP-Asserted-Identityヘッダフィールドは、単に元のユーザーを表すことがAS ISCインタフェース上に送信される場合、それは別の意味でオーバーロードされていることを観察することができます。この他の意味は、それがサービス対象ユーザの表現としての役割を果たすということです。
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.
終端場合に、同様のオーバーロードは、Request-URIに起こります。それは最初だけで、意図終端ユーザーのアイデンティティを表現しながら、それはそれは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.
基本的なコールシナリオでは、これが問題として表示されませんが、より複雑なサービスシナリオ（特に転送サービス）を実現する必要があると、それは厳しい制限をもたらします。このようなシナリオは以下のサブセクションで前方に運ばれます。
4.2. Diversion: Continue on Terminating Leg, but Finish Subsequent Terminating iFC First
4.2. 転換：終端レグに進みますが、その後の最初の終端のiFCを終了します
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は、初期INVITE要求を受信すると、それは要求を解析し、セッションの場合は、終端登録ユーザのためのものであると判断し、それは、Request-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を処理を開始します。 INVITE要求に一致する最初のIFCはRouteヘッダにASとS-CSCF自身のホスト名を追加することによって、ユーザBの転換サービスをホストとしてのISCインタフェースを介して転送されるINVITEせます。 S-CSCFは、ルートヘッダにS-CSCF自身のホスト名にオリジナルダイアログ識別子（ODI）を追加します。これは、S-CSCFが最初の場所でASにINVITEを転送し、既存のセッションへのISCインタフェースを介してASから来INVITE相関することができます。
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
ASは、初期INVITE要求を受信すると、それは要求を解析し、セッションの場合は、終端登録ユーザのためのものであると判断し、それは、Request-URIを見て、ユーザBであることをサービス対象ユーザを決定します。いくつかの基準に基づいて、転換サービスは、要求がそれはC.オプションへのRequest-URIを変更することでこれを行い、他のユーザーまたはアプリケーションCに転用される必要があると結論付け、それがHistory-情報を使用してのRequest-URIの履歴を記録しますヘッダフィールド（RFC 4244 [7]）。その後、ASは削除されます
itself from the Route header and routes the INVITE request back to the S-CSCF by using the topmost Route header field.
自体Routeヘッダと経路から最上位のルートヘッダフィールドを使用してバックS-CSCFにINVITE要求を。
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インタフェースを介してINVITEを受信すると、Routeヘッダは、独自のホスト名とするかどうかを分析するためにS-CSCFによって使用することができ、このユーザBのための既存の終端セッションに相関ODIが含まれていることを見ることができます未実行のIFCは残っています。 （変更のRequest-URIでINVITEを受信すると、S-CSCFの現在の動作がのIFC処理と新しいRequest-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.
プロセスが繰り返されます。 INVITEこの特定のiFCに関連付けられているASに転送されます。 ASは、初期INVITE要求を受信すると、それは要求を解析し、セッションの場合は、終端登録ユーザのためのものであると判断し、それは、Request-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.
このシナリオでは明らかに要求URIは、「ターゲット・アイデンティティを目的とする」とセクション4.1で説明したように操作して、「ユーザーを務めた」の意味でオーバーロードされたときに発生する問題を示しています。そしてそれは、このユースケースは、ASへのS-CSCFから務めユーザーに関する情報を伝える仕組みを導入することなく実現することができないことを示しています。それは、ユーザが提供されているASを教えてくれないとして歴史-info要素の使用は、この問題を解決していません。それだけでも、この特定のユーザーにサービスを提供するシステムによって引き起こされていない可能性があります転換の歴史を提示しています。歴史-Infoヘッダーフィールドが使用できない理由についてより詳細な分析は、付録Aに提供されます
4.3. Diversion: Create New Originating Leg and Provide Originating iFC Processing
4.3. 転換：新しい発信脚を作成し、発信のiFC処理を提供
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は、初期INVITE要求を受信すると、それは要求を解析し、セッションの場合は、終端登録ユーザのためのものであると判断し、それは、Request-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を処理を開始します。 INVITE要求に一致する最初のIFCはRouteヘッダにASとS-CSCF自身のホスト名を追加することによって、ユーザBの転換サービスをホストとしてのISCインタフェースを介して転送されるINVITEせます。 S-CSCFは、ルートヘッダにS-CSCF自身のホスト名にオリジナルダイアログ識別子（ODI）を追加します。これは、S-CSCFが最初の場所でASにINVITEを転送し、既存のセッションへのISCインタフェースを介してASから来INVITE相関することができます。
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は、初期INVITE要求を受信すると、それは要求を解析し、セッションの場合は、終端登録ユーザのためのものであると判断し、それは、Request-URIを見て、ユーザBであることをサービス対象ユーザを決定します。いくつかの基準に基づいて、転換サービスは、要求がそれはC.オプションへのRequest-URIを変更することでこれを行い、他のユーザーまたはアプリケーションCに転用される必要があると結論、それは歴史-情報を使用してのRequest-URIの履歴を記録しますヘッダフィールド（RFC 4244 [7]）。その後、ASは、ルートヘッダから自身を削除します。要求は、ユーザBに代わって新しい発信として処理されていることを確認するために、ASは、最上位のルートヘッダに「ORIG」パラメータを追加します。次に、ルートは、この最上位のルートヘッダフィールドを使用してバックS-CSCFにINVITE要求を。
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インタフェースを介してINVITEを受信すると、最上位のルートヘッダは、独自のホスト名と「ORIG」のパラメータが含まれていることを見ることができます。最上位のルートヘッダが「ORIG」のパラメータが含まれているため、S-CSCFは、コールがサービス対象ユーザによって発信されたかのように扱われるべきINVITEと結論づけています。配信ユーザは、これが提供されているユーザであるように、明らかに間違っているとユーザBであるべきであるユーザAであることがP-Asserted-Identityヘッダから決定されます
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は、発信のIFC処理、最初のiFCを開始INVITE要求の原因に一致する：議論のために、のは、S-CSCFは、サービス対象ユーザは、次のようにその後の手順を続けるユーザBであると判断することができると仮定してみましょうRouteヘッダにASとS-CSCF自身のホスト名を追加することによって、ユーザBの発信サービスをホストとしてのISCインタフェースを介して転送されるINVITE。 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.
INVITEこの特定のiFCに関連付けられているASに転送されます。 ASは、初期INVITEリクエストを受信すると、要求を解析して、セッションの場合は、元の登録ユーザのためである、それはP-アサート・アイデンティティを見ることで、ユーザ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-アサート - アイデンティティを意味「発信」と操作して、「サービス対象ユーザ」とオーバーロードされたときに発生する問題を示しています。そしてそれは、このユースケースは、ASにし、ASからS-CSCFにS-CSCFから務めユーザーに関する情報を伝える仕組みを導入することなく実現することができないことを示しています。それは、ユーザが提供されているASを教えてくれないとして歴史-info要素の使用は、この問題を解決していませんが、ちょうどさえも、この特定のユーザーにサービスを提供するシステムによって引き起こされていない可能性があります気分転換の歴史が示しています。歴史-Infoヘッダーフィールドが使用できない理由についてより詳細な分析は、付録Aに提供されます
4.4. Call Out of the Blue: on Behalf of User B, but Service Profile of Service Identity C
4.4. ユーザーBの代理ではなく、サービスのアイデンティティCのサービスプロファイル：ブルーのコールアウト
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が、Cは、S-CSCFに実行する必要があるサービスIDの代わりにサービスプロファイルから来るように見えることにより、コールを開始できるようにする必要があるサービスがあります。
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-アサート-アイデンティティがBのIDが含まれている必要があることを意味します。これは、3GPP TS 24.173で定義されるように[10]発信アイデンティティプレゼンテーション（OIP）サービスからである発信元を提示するP-アサート・アイデンティティを使用します。それは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-アサート - アイデンティティは、ISCインタフェース上の2つの意味でオーバーロードされているので、何のINVITE要求は最初の段落で表現の両方の要件を達成するであろうこと、現在構築することはできないことは明らかです。 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.サービス対象ユーザに適切なサービスを提供できるようにするためには、サービス対象ユーザのアイデンティティに加えて、セッションケースが搬送されていることが必要です。
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-サーブドユーザPヘッダを定義しています。このヘッダーフィールドは、P-サーブドユーザの信頼ドメイン内のノード間でルーティングされるダイアログまたはスタンドアロン要求のための初期要求に追加することができます。 P-サーブドユーザP-ヘッダは、サービス対象ユーザを表すユーザの識別情報を含んでいます。 「sescase」パラメータは、最初の要求はによって発信や、サービス対象ユーザ宛であるかどうかを伝えるために使用することができます。 「regstate」パラメータは、初期要求が登録又は未登録ユーザのためのものであるかどうかを示すために使用されてもよいです。
The augmented Backus-Naur Form (BNF) (RFC 5234 [6]) syntax of the P-Served-User header field is as follows:
次のように拡張バッカスナウア記法（BNF）P-サーブドユーザヘッダフィールドの（RFC 5234 [6]）構文は次のとおりです。
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"
P-サーブドユーザ= "P-サーブドユーザ" HCOLON PServedUser値*（SEMI務め-ユーザーのparam）務め、ユーザーのparam = sessioncase-PARAM /登録状態のparam /ジェネリック-のparam PServedUser値=名前-addr / ADDR仕様sessioncase-PARAM = "sescase" EQUAL "ORIG" / "という用語は、" 登録状態PARAM = "regstate" EQUAL "UNREG" / "REG"
EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are defined in RFC 3261 [2].
EQUAL、HCOLON、SEMI、名前-ADDR、ADDRスペック、および汎用-PARAM RFC 3261で定義されている[2]。
The following is an example of a P-Served-User header field:
以下は、P-サーブドユーザヘッダフィールドの例です。
P-Served-User: <sip:user@example.com>; sescase=orig; regstate=reg
P-サーブドユーザー：<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-サーブドユーザに対して同じ信頼ドメインの一部です。
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-サーブドユーザヘッダを受信すると、動作で提供したユーザを表すためにP-サーブドユーザヘッダの値を取る必要がありますそれは、そのような情報を必要とします。
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.
ヘッダをサポートするプロキシはヘッダがさらにメッセージを転送する前に、P-サーブドユーザの信頼ドメインの外部のノードから受信された要求または応答からヘッダを削除する必要があります。
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-サーブドユーザヘッダフィールドの拡張機能を使用するには、サービス対象ユーザのための信頼ドメインの内部のみ適用されます。こうした信頼ドメイン内のノードは、明示的にサービス対象ユーザを伝えるために、互いを信頼し、信頼ドメインの外にその情報を源泉徴収の原因であると。ネットワークがサービス対象ユーザと特定のサービス対象ユーザのために実行されるポリシーを決定する手段は、この文書の範囲外です。
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.
サービス対象ユーザは通常、一つだけ、管理ドメイン内の妥当性を持っているので、それは一般的に大で、インターネットにおけるドメイン間の使用または使用には適していません。
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.
これらの制限にもかかわらず、上記の仮定を満たす十分に便利な専門的な展開があり、そしてそれは、このメカニズムの情報掲載を保証するために、結果としての限界を受け入れることができます。例の展開は、3GPP IMSのような閉じたネットワークになります。
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.
P-サーブドユーザ：この文書は、新しいSIPヘッダフィールドを定義します。このヘッダーフィールドは、ヘッダフィールド副登録下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-サーブドユーザヘッダフィールドは、要素が信頼されると、攻撃者は、これらの要素間のプロトコルメッセージへのアクセスを有することになっていない場合の環境で使用されます。ネットワーク要素間のトラフィック保護は、時々、IPsecを使用して、時には物理的にネットワークを保護することにより達成されます。いずれの場合においても、P-サーブドユーザヘッダフィールドが使用される環境は、完全性と、このヘッダフィールドの内容の機密性を保証します。
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-サーブドユーザの信頼ドメインを定義する仕様（T）は、そのメンバ・ノードがP-サーブドユーザヘッダ拡張を理解する必要がなければなりません。
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-サーブドユーザヘッダフィールドは、それが生成された信頼ドメインの外に伝播する許可されている場合は、セキュリティ上のリスクがあります。その場合に、ユーザの機密情報を明らかにされるであろう。信頼ドメインの外側に位置するホップに要求を転送するときに起こってからそのような違反を防止するために、プロキシはヘッダを挿入してはいけません。信頼ドメイン内のノードに要求を転送するときに、ルートセットがヘッダを理解し信頼ドメイン内の別のプロキシを含むことが十分な知識を持っていない限り、プロキシは、ホームプロキシとして、ヘッダを挿入してはいけません。この仕様のサポートを学ぶための自動的なメカニズムはありません。プロキシはそれにない任意のノードにルーティングされる前にそれを除去するルートセットに含まれる任意の他のプロキシの知識を持っていない場合に信頼ドメイン内にないノードに要求を転送するとき、またはプロキシは、ヘッダを削除する必要があります信頼ドメイン。
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.
アルフHeidermark、ヒューバートPrzybysz、そしてエリック・ロラン、この文書に書き留めた溶液につながった議論のため。専門家のレビューを実施するためのスペンサードーキンス。 ADの見直しを実施するためのジョン・ピーターソン。ゴンサロ・カマリロ、ポールKyzivat、ニルスHaenstroem、Arunachalam Venkatraman、ミカエル・フォースバーグ、ミゲル・ガルシア、ジョツセフ・バーガ、キース糖剤、ティムポーク、そしてカレンジェニングス改善を提供します。一般的な領域の見直しを実施するためのフランシスデュポン。セキュリティエリアの見直しを実施するためのサンディマーフィー。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[3]ワトソン、M.は、2002年11月、RFC 3324、 "ネットワークのための短期要件は、アイデンティティをアサート"。
[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]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼されたネットワーク内でアサート・アイデンティティのためのセッション開始プロトコル（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]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427、2002年12月。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[6]クロッカー、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]バーンズ、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、 "セッション開始プロトコル（SIP）およびセッション記述プロトコル（SDP）に基づく、インターネットプロトコル（IP）マルチメディア呼制御プロトコル;ステージ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
歴史-情報ヘッダーがISCインタフェース上のサービス対象ユーザの情報を伝えるためには適していませんなぜ付録A.
A.1. Semantics
A.1。意味論
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.
履歴-情報（RFC 4244で指定されるように[7]）ネットワーク内の処理中に初期の要求に置かれている後続のRequest-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節）を取り除くためにしようとしている一人として生じるであろう。この場合、我々は意味の「歴史的なターゲット同一性」と「サービス対象ユーザ」と、特定の歴史-Infoヘッダーフィールドのハイエントリをオーバーロードします。
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ヘッダーが要件を解決することができないもう一つの理由は、そのヘッダーフィールドがアサート元のユーザーのが含まれているように、セッションのケースのシナリオを発信するには、サービス対象ユーザが現在、P-アサート-アイデンティティから決定される、ということです身元。歴史-Infoヘッダーは、リクエスト-URIの記録され、この場合の解決策になることはありません。
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から来るように表示され、その希望ユーザDを対象に、ユーザCの代わりにINVITEリクエストの履歴-Infoヘッダーを構築することは不可能です（RFC 4244 [7]）に応じて履歴-Infoヘッダの元のセマンティクスに違反することなく配信ユーザCを発現します。
A.2. Additional Observations
A.2。追加の観察
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.
履歴-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インターフェースを介してINVITEを受信することを現時点では、このINVITEはや履歴情報を追加していない場合がありプロキシの膨大な数に合格している可能性があります。その上で、要求は同じサービス対象ユーザのためのインスタンスなど、いくつかを横断している可能性があります。場合には、いくつかの後続のIFCはアクティブであり、これらのすべてのASインスタンスは、転送を実行することができます。サービス対象ユーザを表すべき歴史-Infoヘッダーのハイエントリ指摘するアルゴリズムを定義することはできないことを意味します。換言すれば、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.
セクション5で表されるように、それは自然な方法でセッションの場合を表現する手段を持たないように履歴-Infoヘッダは、第二の要件を満たしていません。
A.3. Conclusion
A.3。結論
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-サーブドユーザヘッダと同じ要求で歴史-Infoヘッダーの使用を禁止していないことに注意してください。 （3GPP TS 24.173 [10]）で指定されるように、実際には例えば、のようなネットワークベースの転換サービス、通信迂回サービスのために非常に可能性の高いシナリオであろうこと。
Author's Address
著者のアドレス
Hans Erik van Elburg Ericsson Telecommunicatie B.V. Ericssonstraat 2 Rijen 5121 ML Netherlands
ハンス・エリック・バンElburgエリクソンテレコミュニケーションBVエリクソンストリート2行5121 MLオランダ
EMail: HansErik.van.Elburg@ericsson.com
メールアドレス：HansErik.van.Elburg@ericsson.com