[要約] RFC 7549は、3GPP SIP URI Inter-Operator Traffic Legパラメータに関する仕様です。このRFCの目的は、異なるオペレータ間でのSIP URIトラフィックの制御を可能にするためのパラメータを定義することです。
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 7549 J. Holm
Category: Standards Track Ericsson
ISSN: 2070-1721 R. Jesske
Deutsche Telekom
M. Dolly
AT&T
May 2015
3GPP SIP URI Inter-Operator Traffic Leg Parameter
3GPP SIP URIオペレーター間トラフィックレッグパラメーター
Abstract
概要
In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a Back-to-Back User Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg.
3GPPネットワークでは、発信側ユーザーと着信側ユーザー間のシグナリングパスを、トラフィックレッグと呼ばれるセグメントに分割できます。各トラフィックレッグは、異なる事業者に属するネットワークにまたがることがあり、同じコールの他のトラフィックレッグとは異なる可能性がある独自の特性を持ちます。たとえば、SIPダイアログ識別子を変更するバックツーバックユーザーエージェント（B2BUA）がトラフィックレッグ内にある場合、トラフィックレッグは複数のSIPダイアログに関連付けられている可能性があります。
This document defines a new SIP URI parameter, 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).
このドキュメントでは、新しいSIP URIパラメータ 'iotl'（オペレーター間トラフィックレッグの略称）を定義しています。このパラメーターをSIP URIで使用して、アドレスに関連付けられたエンティティ、またはアドレスのホスト部分を担当するエンティティが、特定のトラフィックレッグ（または複数のトラフィックレッグ）の終わりを表すことを示すことができます。
The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible.
このドキュメントで定義されているSIP URIの「iotl」パラメータは、3GPPネットワークでの既知の用途があります。他のネットワークでの使用も可能です。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7549.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7549で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Traffic Leg Examples . . . . . . . . . . . . . . . . . . . . 6
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Originating Roaming Call . . . . . . . . . . . . . . . . 6
4.3. Terminating Roaming Call . . . . . . . . . . . . . . . . 7
4.4. Call from Originating Home to Terminating Home . . . . . 7
5. 'iotl' SIP URI Parameter . . . . . . . . . . . . . . . . . . 7
5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 8
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. homea-homeb . . . . . . . . . . . . . . . . . . . . . 8
5.2.3. homeb-visitedb . . . . . . . . . . . . . . . . . . . 8
5.2.4. visiteda-homea . . . . . . . . . . . . . . . . . . . 9
5.2.5. homea-visiteda . . . . . . . . . . . . . . . . . . . 9
5.2.6. visiteda-homeb . . . . . . . . . . . . . . . . . . . 9
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 12
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2. The UE Registers via P-CSCF . . . . . . . . . . . . . . . 12
A.3. Originating IMS Call . . . . . . . . . . . . . . . . . . 14
A.4. Terminating IMS Call . . . . . . . . . . . . . . . . . . 15
A.5. Call between Originating Home and Terminating Home
Network . . . . . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
In a 3GPP network, an end-user device can be attached (e.g., using a radio access network) to its own operator network (home network) [TS.3GPP.24.229] or to another operator's network (visited network) [TS.3GPP.24.229]. In the latter case, the user is referred to as a roaming user.
3GPPネットワークでは、エンドユーザーのデバイスを（たとえば、無線アクセスネットワークを使用して）独自のオペレーターネットワーク（ホームネットワーク）[TS.3GPP.24.229]または別のオペレーターのネットワーク（訪問ネットワーク）[TS。 3GPP.24.229]。後者の場合、ユーザーはローミングユーザーと呼ばれます。
3GPP operator networks are often not connected directly to each other. Instead, there might be intermediate networks, referred to as 3GPP transit networks, between them. Such transit networks act on the SIP level or the IP level.
3GPPオペレーターネットワークは、多くの場合、互いに直接接続されていません。代わりに、それらの間に3GPPトランジットネットワークと呼ばれる中間ネットワークが存在する場合があります。このようなトランジットネットワークは、SIPレベルまたはIPレベルで動作します。
In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a B2BUA [RFC3261] that modifies the SIP dialog identifier is located within the traffic leg.
3GPPネットワークでは、発信側ユーザーと着信側ユーザー間のシグナリングパスを、トラフィックレッグと呼ばれるセグメントに分割できます。各トラフィックレッグは、異なる事業者に属するネットワークにまたがることがあり、同じコールの他のトラフィックレッグとは異なる可能性がある独自の特性を持ちます。たとえば、SIPダイアログ識別子を変更するB2BUA [RFC3261]がトラフィックレッグ内にある場合、トラフィックレッグは複数のSIPダイアログに関連付けられている可能性があります。
The traffic leg information can be used by intermediary entities to make policy decisions related to, e.g., media anchoring, signaling policy, insertion of media functions (e.g., transcoder), and charging.
トラフィックレッグ情報は、メディアアンカー、シグナリングポリシー、メディア機能（トランスコーダーなど）の挿入、課金などに関連するポリシー決定を行うために中間エンティティによって使用できます。
The figure below shows two users (Alice and Bob) and the different type of networks that the signaling might traverse. The signaling path can be divided into multiple traffic legs, and the type of traffic legs depends on how the signaling is routed.
次の図は、2人のユーザー（アリスとボブ）と、シグナリングが通過する可能性のある異なるタイプのネットワークを示しています。シグナリングパスは複数のトラフィックレッグに分割できます。トラフィックレッグのタイプは、シグナリングのルーティング方法によって異なります。
Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob
Home + + + + + Home
+ ++++++++++++++++++ + +
+ + +
+ + +
+ +++++++++++++++++++++++ +
+ + + +
Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob
Visited Visited
ORIG HNW = Originating 3GPP Home Network TERM HNW = Terminating 3GPP Home Network ORIG VNW = Originating 3GPP Visited Network TERM VNW = Terminating 3GPP Visited Network TRANSIT NW = 3GPP Transit Network
ORIG HNW = 3GPPホームネットワークの発信TERM HNW = 3GPPホームネットワークの終了ORIG VNW = 3GPP訪問ネットワークの発信TERM VNW = 3GPP訪問ネットワークの終了TRANSIT NW = 3GPPトランジットネットワーク
Figure 1: 3GPP Operator Network Roaming Roles
図1：3GPPオペレーターネットワークローミングの役割
In Figure 1, Alice is a user initiating communication with Bob. Also, consider the following information:
図1では、アリスはボブとの通信を開始するユーザーです。また、次の情報も考慮してください。
Alice is attached to an originating network, which is either the home network of Alice or a visited network (in case Alice is roaming). In both cases, any originating service is provided by the home network of Alice.
Aliceは、Aliceのホームネットワークまたは訪問先ネットワーク（Aliceがローミングしている場合）のいずれかである発信元ネットワークに接続されています。どちらの場合も、元のサービスはすべてアリスのホームネットワークによって提供されます。
Bob is attached to a terminating network, which is either the home network of Bob or a visited network (in case Bob is roaming). In both cases, any terminating service is provided by the home network of Bob.
ボブは、ボブのホームネットワークまたは訪問先ネットワーク（ボブがローミングしている場合）のいずれかである終端ネットワークに接続されています。どちらの場合も、着信サービスはボブのホームネットワークによって提供されます。
A transit network providing transit functions (e.g., translation of free phone numbers) may be included between the originating and terminating networks and between visited and home networks.
トランジット機能（無料電話番号の変換など）を提供するトランジットネットワークは、発信元ネットワークと終端ネットワークの間、訪問先ネットワークとホームネットワークの間に含めることができます。
This document defines a new SIP URI parameter [RFC3261], 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).
このドキュメントでは、新しいSIP URIパラメータ[RFC3261]、 'iotl'（オペレーター間トラフィックレッグの略語）を定義しています。このパラメーターをSIP URIで使用して、アドレスに関連付けられたエンティティ、またはアドレスのホスト部分を担当するエンティティが、特定のトラフィックレッグ（または複数のトラフィックレッグ）の終わりを表すことを示すことができます。
This document defines the following 'iotl' parameter values:
このドキュメントでは、次の「iotl」パラメータ値を定義しています。
o homea-homeb
o homea-homeb
o homeb-visitedb
o homeb-visitedb
o visiteda-homea
o 訪問したホメア
o homea-visiteda
o ホメア訪問
o visiteda-homeb
o Visita-homeb
SIP entities that do not support the SIP URI 'iotl' parameter will simply ignore it, if received, as defined in [RFC3261].
[RFC3261]で定義されているように、SIP URI 'iotl'パラメータをサポートしないSIPエンティティは、受信された場合、それを単に無視します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible.
このドキュメントで定義されているSIP URIの「iotl」パラメータは、3GPPネットワークでの既知の用途があります。他のネットワークでの使用も可能です。
This section describes examples of different types of traffic legs in 3GPP networks.
このセクションでは、3GPPネットワークのさまざまなタイプのトラフィックレッグの例について説明します。
In this case, Alice is located in a visited network. When Alice sends the initial SIP INVITE request for a call, one traffic leg (referred to as the 'visiteda-homea' traffic leg) represents the signaling path between the User Agent (UA) of Alice and the home Serving Call Session Control Function (S-CSCF) [TS.3GPP.24.229] of Alice.
この場合、アリスは訪問先ネットワークに配置されています。アリスがコールの最初のSIP INVITE要求を送信すると、1つのトラフィックレッグ（「visiteda-homea」トラフィックレッグと呼ばれる）は、アリスのユーザーエージェント（UA）とホームサービスコールセッション制御機能（ S-CSCF）アリスの[TS.3GPP.24.229]。
In this case, Bob is located in a visited network. When the home S-CSCF of Bob forwards the initial SIP INVITE request for a call towards Bob, one traffic leg (referred to as the 'homeb-visitedb' traffic leg) represents the signaling path between the home S-CSCF of Bob and the UA of Bob.
この場合、ボブは訪問先ネットワークに配置されています。ボブのホームS-CSCFがボブへのコールの最初のSIP INVITE要求を転送するとき、1つのトラフィックレッグ（「homeb-visitedb」トラフィックレッグと呼ばれる）は、ボブのホームS-CSCFとボブのUA。
In this case, the home S-CSCF of Alice forwards the initial SIP INVITE request towards the home S-CSCF of Bob. The signaling path between the S-CSCFs represents one traffic leg (referred to as the 'homea-homeb' traffic leg).
この場合、アリスのホームS-CSCFは、最初のSIP INVITE要求をボブのホームS-CSCFに転送します。 S-CSCF間のシグナリングパスは、1つのトラフィックレッグ（「homea-homeb」トラフィックレッグと呼ばれる）を表します。
As specified in [RFC3261], when a SIP entity inserts a SIP URI in an initial request for a dialog, or in a stand-alone request, the SIP URI will be used to route the request to another SIP entity, addressed by the SIP URI, or to a SIP entity responsible for the host part of the SIP URI (e.g., a SIP registrar). If such an entity represents the end of one or more traffic legs, the SIP entity inserting the SIP URI can add a SIP URI 'iotl' parameter to the SIP URI to indicate the type(s) of traffic leg. Each parameter value indicates a type of traffic leg.
[RFC3261]で指定されているように、SIPエンティティがダイアログの最初の要求またはスタンドアロンの要求にSIP URIを挿入すると、SIP URIは、SIPによってアドレス指定された別のSIPエンティティに要求をルーティングするために使用されますURI、またはSIP URIのホスト部分を担当するSIPエンティティ（SIPレジストラなど）。そのようなエンティティが1つ以上のトラフィックレッグの終わりを表す場合、SIP URIを挿入するSIPエンティティはSIP URIにSIP URI 'iotl'パラメータを追加して、トラフィックレッグのタイプを示すことができます。各パラメータ値は、トラフィックレッグのタイプを示します。
For routing of an initial SIP request for a dialog, or a stand-alone SIP request, a SIP entity can add the 'iotl' parameter to (a) the SIP URI of the Request-URI [RFC3261] or (b) the SIP URI of a Route header field [RFC3261] of the SIP request. SIP entities can add the 'iotl' parameter to the SIP URI of a Path header field [RFC3327] or a Service-Route header field [RFC3608] in order for the parameter to later occur in a Route header field.
ダイアログの最初のSIPリクエスト、またはスタンドアロンのSIPリクエストのルーティングでは、SIPエンティティは 'iotl'パラメータを（a）Request-URI [RFC3261]のSIP URIまたは（b）SIPに追加できます。 SIPリクエストのルートヘッダーフィールド[RFC3261]のURI。 SIPエンティティは、パスヘッダーフィールド[RFC3327]またはService-Routeヘッダーフィールド[RFC3608]のSIP URIに 'iotl'パラメーターを追加して、後でパラメーターをルートヘッダーフィールドで発生させることができます。
When a SIP entity receives an initial request for a dialog or a stand-alone request, which contains one or more SIP URI 'iotl' parameters, it identifies the type of traffic leg in the following way:
SIPエンティティが1つ以上のSIP URI 'iotl'パラメータを含むダイアログまたはスタンドアロン要求の初期要求を受信すると、次の方法でトラフィックレッグのタイプを識別します。
o if the SIP request contains a single Route header field containing a SIP URI with an 'iotl' parameter, that parameter identifies the type of traffic leg;
o SIPリクエストに、「iotl」パラメーターを持つSIP URIを含む単一のルートヘッダーフィールドが含まれている場合、そのパラメーターはトラフィックレッグのタイプを識別します。
o if the SIP request contains multiple Route header fields containing a SIP URI with an 'iotl' parameter, the 'iotl' parameter associated with the SIP URI of the topmost Route header field (or, if the SIP URI of the topmost Route header field does not contain an 'iotl' parameter, the SIP URI of the Route header field closest to the topmost) identifies the type of traffic leg; or
o SIPリクエストに 'iotl'パラメータを持つSIP URIを含む複数のルートヘッダーフィールドが含まれている場合、 'iotl'パラメータは最上位のルートヘッダーフィールドのSIP URIに関連付けられています（または、最上位のルートヘッダーフィールドのSIP URIが「iotl」パラメータを含まない場合、最上位に最も近いルートヘッダーフィールドのSIP URI）はトラフィックレッグのタイプを識別します。または
o if a SIP request contains an 'iotl' parameter only in the Request-URI SIP URI, the 'iotl' parameter identifies the type of traffic leg.
o SIPリクエストにRequest-URI SIP URIにのみ「iotl」パラメータが含まれている場合、「iotl」パラメータはトラフィックレッグのタイプを識別します。
During SIP registration [RFC3261], entities can add the 'iotl' parameter to the SIP URI of a Path or Service-Route header field if the entity is aware that the SIP URI will be used to indicate the end of a specific traffic leg for initial requests for dialogs or stand-alone requests sent on the registration path.
SIP登録[RFC3261]中に、エンティティが特定のトラフィックレッグの終了を示すためにSIP URIが使用されることをエンティティが認識している場合、エンティティは、PathまたはService-RouteヘッダーフィールドのSIP URIに「iotl」パラメーターを追加できます。ダイアログの最初のリクエストまたは登録パスで送信されたスタンドアロンのリクエスト。
As defined in [RFC3261], a SIP proxy must not modify or remove URI parameters from SIP URIs associated with other entities. This also applies to the 'iotl' parameter.
[RFC3261]で定義されているように、SIPプロキシは、他のエンティティに関連付けられたSIP URIからURIパラメータを変更または削除してはなりません。これは、「iotl」パラメーターにも適用されます。
This section describes the SIP URI 'iotl' parameter values defined in this specification.
このセクションでは、この仕様で定義されているSIP URIの「iotl」パラメータ値について説明します。
Note that, when a request is routed between different networks, the request might traverse one or more IBCFs (Interconnection Border Control Functions) acting as network border entities.
リクエストが異なるネットワーク間でルーティングされる場合、リクエストはネットワーク境界エンティティとして機能する1つ以上のIBCF（相互接続ボーダー制御機能）を通過する可能性があることに注意してください。
This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the home network (originating) of the calling user and the home network (terminating) of the called user.
この値は、パラメーターに関連付けられたSIP URIのホスト部分を担当するSIPエンティティが、呼び出し元ユーザーのホームネットワーク（発信）と呼び出し先ユーザーのホームネットワーク（終端）の間のトラフィックレッグの終わりを表すことを示します。
In 3GPP, this traffic leg is between two S-CSCFs.
3GPPでは、このトラフィックレッグは2つのS-CSCFの間にあります。
This value indicates that the SIP entity addressed by the SIP URI associated with the parameter represents the end of a traffic leg between the home network (terminating) of the called user and the visited network (terminating) in which the called user is located.
この値は、パラメータに関連付けられたSIP URIでアドレス指定されたSIPエンティティが、呼び出されたユーザーのホームネットワーク（終端）と、呼び出されたユーザーが配置されている訪問先ネットワーク（終端）の間のトラフィックレッグの終わりを表すことを示します。
In 3GPP, this traffic leg is between the home S-CSCF and the User Equipment (UE) of the called user or between the Service Centralization and Continuity Application Server (SCC AS) in the home network of the called user and Access Transfer Control Function (ATCF) in the visited network of the called user.
3GPPでは、このトラフィックレッグは、ホームS-CSCFと呼び出されたユーザーのユーザー機器（UE）の間、または呼び出されたユーザーのホームネットワークのサービス集中化と継続性アプリケーションサーバー（SCC AS）とアクセス転送制御機能の間にあります。 （ATCF）呼び出されたユーザーの訪問先ネットワーク。
This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the visited network (originating) in which the calling user is located and the home network (originating) of the calling user.
この値は、パラメータに関連付けられたSIP URIのホスト部分を担当するSIPエンティティが、呼び出し元のユーザーがいる訪問先ネットワーク（発信元）とホームネットワーク（発信元）の間のトラフィックレッグの終わりを表すことを示します。呼び出し元のユーザー。
In 3GPP, this traffic leg is between the UE and the home S-CSCF of the calling user or between the Proxy Call Session Control Function (P-CSCF) in the visited network, serving the calling user and the home S-CSCF of the calling user.
3GPPでは、このトラフィックレッグは、UEと発信ユーザーのホームS-CSCFの間、または訪問先ネットワークのプロキシコールセッション制御機能（P-CSCF）の間にあり、発信ユーザーとホームのS-CSCFにサービスを提供します。呼び出し元のユーザー。
This value indicates that the SIP entity addressed by the SIP URI associated with the parameter represents the end of a traffic leg between the home network (originating) and the visited network (originating) in which the calling user is located.
この値は、パラメーターに関連付けられたSIP URIでアドレス指定されたSIPエンティティが、ホームネットワーク（発信）と呼び出し元ユーザーが配置されている訪問先ネットワーク（発信）間のトラフィックレッグの終わりを表すことを示します。
In 3GPP, this traffic leg is between the home S-CSCF of the calling user and the Transit and Roaming Function (TRF) [TS.3GPP.24.229] serving the calling user and exists in scenarios where the home S-CSCF of the calling user forwards a request back to the visited network where the UE of the calling user is located. An example of this is when the Roaming Architecture for Voice over IMS with Local Breakout (RAVEL) [TS.3GPP.24.229] feature is enabled.
3GPPでは、このトラフィックレッグは、呼び出し元ユーザーのホームS-CSCFと、呼び出し元ユーザーにサービスを提供するTransit and Roaming Function（TRF）[TS.3GPP.24.229]の間にあり、呼び出し元のホームS-CSCFが存在するシナリオに存在します。ユーザーは、呼び出し元ユーザーのUEが配置されている訪問先ネットワークに要求を転送します。この例は、ローカルブレイクアウト（RAVEL）を使用したVoice over IMSのローミングアーキテクチャ[TS.3GPP.24.229]機能が有効になっている場合です。
This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the visited network (originating) of the calling user and the home network (terminating) of the called user.
この値は、パラメーターに関連付けられたSIP URIのホスト部分を担当するSIPエンティティが、呼び出し元ユーザーの訪問先ネットワーク（発信）と呼び出し先ユーザーのホームネットワーク（終端）の間のトラフィックレッグの終わりを表すことを示します。
In 3GPP, this traffic leg is between the TRF [TS.3GPP.24.229] serving the calling user and the home S-CSCF of the called user and exists in scenarios where a request is forwarded from the visited network where the calling user is located directly to the home S-CSCF of the called user. An example of this is when the RAVEL [TS.3GPP.24.229] feature is enabled.
3GPPでは、このトラフィックレッグは、呼び出し元のユーザーにサービスを提供するTRF [TS.3GPP.24.229]と呼び出し先のユーザーのホームS-CSCFの間にあり、呼び出し元のユーザーがいる訪問先ネットワークから要求が転送されるシナリオに存在します。呼び出されたユーザーのホームS-CSCFに直接。この例は、RAVEL [TS.3GPP.24.229]機能が有効になっている場合です。
This section defines the ABNF for the 'iotl' SIP URI parameter. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234].
このセクションでは、「iotl」SIP URIパラメータのABNFを定義します。この仕様で定義されているABNFは、RFC 5234 [RFC5234]に準拠しています。
This specification does not create an IANA registry for 'iotl' parameter values. A registry should be considered if new parameter values are defined in the future.
この仕様では、「iotl」パラメータ値のIANAレジストリは作成されません。将来、新しいパラメータ値が定義される場合は、レジストリを検討する必要があります。
The ABNF [RFC5234] grammar for this SIP URI parameter is:
このSIP URIパラメータのABNF [RFC5234]文法は次のとおりです。
uri-parameter =/ iotl-param
iotl-param = iotl-tag "=" iotl-value ["." iotl-value]
iotl-tag = "iotl"
iotl-value = "homea-homeb" / "homeb-visitedb" / "visiteda-homea"
/ "homea-visiteda" / "visiteda-homeb" / other-iotl
other-iotl = 1*iotl-char
iotl-char = alphanum / "-"
;; alphanum defined in RFC 3261
The information in the 'iotl' parameter is used for making policy decisions. Such policies can be related to charging and triggering of services. In order to prevent abuse, which could cause user billing or service failure, the parameter SHOULD only be used for making policy decisions based on the role by nodes within the same trust domain [RFC3325], and network boundary entities MUST NOT forward information received from untrusted entities. In addition, an agreement MUST exist between the operators for usage of the roaming role information.
「iotl」パラメーターの情報は、ポリシー決定を行うために使用されます。このようなポリシーは、サービスの課金とトリガーに関連する場合があります。ユーザーへの課金やサービス障害の原因となる悪用を防ぐために、パラメーターは、同じ信頼ドメイン[RFC3325]内のノードによる役割に基づいてポリシー決定を行うためにのみ使用する必要があります[RFC3325]。ネットワーク境界エンティティは、信頼できないエンティティ。さらに、ローミングの役割情報の使用に関して、オペレーター間に合意が存在しなければなりません。
General security considerations for SIP are defined in [RFC3261]
SIPの一般的なセキュリティの考慮事項は、[RFC3261]で定義されています。
Per this specification, IANA has added one new value to the "SIP/SIPS URI Parameters" registry as defined in [RFC3969].
この仕様に従って、[RFC3969]で定義されているように、IANAは「SIP / SIPS URIパラメータ」レジストリに1つの新しい値を追加しました。
Parameter Name Predefined Values Reference
____________________________________________
iotl Yes RFC 7549
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, <http://www.rfc-editor.org/info/rfc3327>.
[RFC3327] Willis、D。およびB. Hoeneisen、「非隣接連絡先を登録するためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3327、DOI 10.17487 / RFC3327、2002年12月、<http：//www.rfc- editor.org/info/rfc3327>。
[RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, DOI 10.17487/RFC3608, October 2003, <http://www.rfc-editor.org/info/rfc3608>.
[RFC3608]ウィリスD.およびB.ホネイゼン、「登録時のサービスルートディスカバリ用のセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3608、DOI 10.17487 / RFC3608、2003年10月、<http：//www.rfc- editor.org/info/rfc3608>。
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, <http://www.rfc-editor.org/info/rfc3969>.
[RFC3969] Camarillo、G.、「インターネット開始番号認証局（IANA）セッション開始プロトコル（SIP）のURI（Uniform Resource Identifier）パラメータレジストリ」、BCP 99、RFC 3969、DOI 10.17487 / RFC3969、2004年12月、< http://www.rfc-editor.org/info/rfc3969>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[TS.3GPP.24.229] 3GPP, "Vocabulary for 3GPP Specifications", 3GPP TS 24.229 12.6.0, September 2014.
[TS.3GPP.24.229] 3GPP、「3GPP仕様の語彙」、3GPP TS 24.229 12.6.0、2014年9月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <http://www.rfc-editor.org/info/rfc3325>.
[RFC3325]ジェニングス、C。、ピーターソン、J。、およびM.ワトソン、「信頼できるネットワーク内のアサートされたIDのためのセッション開始プロトコル（SIP）のプライベート拡張」、RFC 3325、DOI 10.17487 / RFC3325、2002年11月、<http ：//www.rfc-editor.org/info/rfc3325>。
This section contains example call flows based on 3GPP usage of the SIP URI 'iotl' parameter.
このセクションには、SIP URI 'iotl'パラメータの3GPP使用に基づくコールフローの例が含まれています。
The Visited Proxy (P-CSCF) adds the 'iotl' value 'homeb-visitedb' to the Path header field of the REGISTER request to be used for terminating routing towards Alice. The Home Proxy (S-CSCF) adds the 'iotl' value 'visiteda-homea' to the Service-Route header field to be used for originating initial/stand-alone requests from Alice.
Visited Proxy（P-CSCF）は、 'iotl'値 'homeb-visitedb'をREGISTERリクエストのPathヘッダーフィールドに追加して、アリスへのルーティングを終了するために使用します。ホームプロキシ（S-CSCF）は、「iotl」値「visiteda-homea」をService-Routeヘッダーフィールドに追加して、Aliceからの初期/スタンドアロン要求の発信に使用されます。
Visited Proxy Visited Proxy Home Proxy Home Proxy
Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF
| | | | |
| REGISTER F1 | | | |
|--------------->| REGISTER F2 | | |
| |--------------->| REGISTER F3 | |
| | |--------------->| REGISTER F4 |
| | | |--------------->|
| | | | |
| | | | 200 (OK) F5 |
| | | |<---------------|
| | | 200 (OK) F6 | |
| | |<---------------| |
| | 200 (OK) F7 | | |
| |<---------------| | |
| 200 (OK) F8 | | | |
|<---------------| | | |
F1 REGISTER Alice -> P-CSCF
REGISTER sip:registrar.home1.net SIP/2.0
F2 REGISTER P-CSCF -> IBCF-V
REGISTER sip:registrar.home1.net SIP/2.0
Path: <p-cscf URI;iotl=homeb-visitedb>
F3 REGISTER IBCF-V -> IBCF-H
REGISTER sip:registrar.home1.net SIP/2.0
Path: <p-cscf URI;iotl=homeb-visitedb>
F4 REGISTER IBCF-H -> S-CSCF
REGISTER sip:registrar.home1.net SIP/2.0
Path: <p-cscf URI;iotl=homeb-visitedb>
F5 200 OK S-CSCF -> IBCF-H
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
F6 200 OK IBCF-H -> IBCF-V
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
F7 200 OK IBCF-V -> P-CSCF
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
F8 200 OK P-CSCF -> Alice
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
Figure 2: The UE Registers via P-CSCF
図2：P-CSCFを介したUEの登録
In the originating INVITE request from Alice, the 'iotl' value 'visiteda-homea', received in the Service-Route header field during registration, is added to the Route header field representing the Home Proxy (S-CSCF) to indicate the traffic leg type between the Visited Proxy (P-CSCF) and the Home Proxy (S-CSCF).
アリスからの元のINVITEリクエストでは、登録時にService-Routeヘッダーフィールドで受信した「iotl」値「visiteda-homea」が、ホームプロキシ（S-CSCF）を表すルートヘッダーフィールドに追加され、トラフィックを示します。 Visited Proxy（P-CSCF）とHome Proxy（S-CSCF）の間のレッグタイプ。
Visited Proxy Visited Proxy Home Proxy Home Proxy
Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| INVITE F3 | |
| | |--------------->| INVITE F4 |
| | | |--------------->|
| | | | |
| | | | 180 F5 |
| | | 180 F6 |<---------------|
| | 180 F7 |<---------------| |
| 180 F8 |<---------------| | |
|<---------------| | | |
| | | | |
F1 INVITE Alice -> P-CSCF
INVITE sip:Bob@homeb.net SIP/2.0
Route: <p-cscf URI>,<s-cscf URI;iotl=visiteda-homea>
F2 INVITE P-CSCF -> IBCF-V
INVITE sip:Bob@homeb.net SIP/2.0
Route: <ibcf-v URI>,<s-cscf URI;iotl=visiteda-homea>
F3 INVITE IBCF-V -> IBCF-H
INVITE sip:Bob@homeb.net SIP/2.0
Route: <ibcf-h URI>,<s-cscf URI;iotl=visiteda-homea>
F4 INVITE IBCF-H -> S-CSCF
INVITE sip:Bob@homeb.net SIP/2.0
Route: <s-cscf URI;iotl=visiteda-homea>
Figure 3: Originating IP Multimedia Subsystem (IMS) Call
図3：発信IPマルチメディアサブシステム（IMS）コール
In the terminating INVITE request towards Alice, the 'iotl' value 'homeb-visitedb' provided to the Home Proxy (S-CSCF) during registration is added to the Route header field representing the Visited Proxy (P-CSCF) to indicate the traffic leg type between the Home Proxy (S-CSCF) and the Visited Proxy (P-CSCF).
アリスへのINVITEリクエストの終了では、登録時にホームプロキシ（S-CSCF）に提供された 'iotl'値 'homeb-visitedb'が、Visited Proxy（P-CSCF）を表すルートヘッダーフィールドに追加され、トラフィックを示します。ホームプロキシ（S-CSCF）と訪問済みプロキシ（P-CSCF）間のレッグタイプ。
Home Proxy Home Proxy Visited Proxy Visited Proxy
S-CSCF . . . . IBCF-H . . . . . IBCF-V . . . . . P-CSCF . . . . . Bob
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| INVITE F3 | |
| | |--------------->| INVITE F4 |
| | | |--------------->|
| | | | |
| | | | 180 F5 |
| | | 180 F6 |<---------------|
| | 180 F7 |<---------------| |
| 180 F8 |<---------------| | |
|<---------------| | | |
| | | | |
F1 INVITE S-CSCF -> IBCF-H
INVITE sip:Bob@visitedb.net SIP/2.0
Route: <ibcf-h URI>,<p-cscf-v URI;iotl=homeb-visitedb
F2 INVITE IBCF-H -> IBCF-V
INVITE sip:Bob@visitedb.net SIP/2.0
Route: <ibcf-v URI>,<p-cscf-v URI;iotl=homeb-visitedb
F3 INVITE IBCF-V -> P-CSCF
INVITE sip:Bob@visitedb.net SIP/2.0
Route: <p-cscf-v URI;iotl=homeb-visitedb
F4 INVITE P-CSCF -> Bob
INVITE sip:Bob@visitedb.net SIP/2.0
Figure 4: Terminating IMS Call
図4：IMS通話の終了
The S-CSCF of the originating home network adds the 'iotl' value 'homea-homeb' in the Request-URI of the INVITE, sent towards the S-CSCF of the terminating network to indicate the traffic leg type between the S-CSCFs.
発信元ホームネットワークのS-CSCFは、INVITEのRequest-URIに「iotl」値「homea-homeb」を追加し、終端ネットワークのS-CSCFに向けて送信され、S-CSCF間のトラフィックレッグタイプを示します。 。
Home-A Proxy Home-A Proxy Home-B Proxy Home-B Proxy Home-B Proxy
S-CSCF-A . . . . IBCF-A . . . . .IBCF-B . . . . .I-CSCF-B . . .S-CSCF-B
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| INVITE F3 | |
| | |--------------->| INVITE F4 |
| | | |--------------->|
| | | | |
| | | | 180 F5 |
| | | 180 F6 |<---------------|
| | 180 F7 |<---------------| |
| 180 F8 |<---------------| | |
|<---------------| | | |
| | | | |
F1 INVITE S-CSCF-A -> IBCF-A
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
F2 INVITE IBCF-a -> IBCF-B
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
F3 INVITE IBCF-B -> I-CSCF-B
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
F4 INVITE I-CSCF-B -> S-CSCF-B
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
Figure 5: Call between Originating Home and Terminating Home Network
図5：ホームネットワークとターミネーションホームネットワーク間の通話
Acknowledgements
謝辞
The authors wish to thank everyone in the 3GPP community that gave comments on the initial version of this document and contributed with comments and suggestions during the work. A special thanks to Paul Kyziwat, Dale Worley, and Michael Hammer. Robert Sparks performed the Gen-ART review of the document.
著者は、このドキュメントの最初のバージョンについてコメントし、作業中にコメントや提案を提供してくれた3GPPコミュニティのすべての人に感謝したいと思います。 Paul Kyziwat、Dale Worley、Michael Hammerに特に感謝します。 Robert SparksがドキュメントのGen-ARTレビューを行いました。
Authors' Addresses
著者のアドレス
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: christer.holmberg@ericsson.com
Jan Holm Ericsson Kistavagen 25 Stockholm16480 Sweden
Jan Holm Ericsson Kistavagen 25 Stockholm16480スウェーデン
EMail: jan.holm@ericsson.com
Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany
Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7ダルムシュタットドイツ
Phone: +4961515812766
EMail: r.jesske@telekom.de
Martin Dolly AT&T 718 Clairmore Ave Lanoka Harbor 08734 United States
Martin Dolly AT＆T 718 Clairmore Ave Lanoka Harbour 08734アメリカ合衆国
EMail: md3135@att.com