Network Working Group M. Bangalore
Request for Comments: 5140 R. Kumar
Category: Standards Track J. Rosenberg
Cisco
H. Salama
Citex Software
D.N. Shah
Moowee Inc.
March 2008
A Telephony Gateway REgistration Protocol (TGREP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony Administrative Domains (ITADs). TGREP shares a lot of similarities with the TRIP protocol. It has similar procedures and finite state machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP.
この文書は、テレフォニーゲートウェイとソフトスイッチでサポートされている電話プレフィックスを登録するためのテレフォニーゲートウェイ登録プロトコル（TGREP）について説明します。登録メカニズムは、リソース情報をエクスポートするために使用することができます。プレフィックスとリソースの情報は、今度はインターネットテレフォニー管理ドメイン（ITADs）内との間で情報をルーティングすることを伝搬することができるオーバーIPテレフォニールーティング（TRIP）ロケーションサーバ、に渡すことができます。 TGREPは、TRIPプロトコルと多くの類似点を共有しています。これは、セッション確立のための同様の手順と有限状態マシンを持っています。また、メッセージのための同じ形式およびTRIPと属性のサブセットを共有しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology and Definitions .....................................5
3. TGREP: Overview of Operation ....................................6
4. TGREP Attributes ................................................7
4.1. TotalCircuitCapacity Attribute .............................8
4.2. AvailableCircuits Attribute ................................9
4.3. CallSuccess Attribute .....................................10
4.4. Prefix Attributes .........................................12
4.5. TrunkGroup Attribute ......................................13
4.6. Carrier Attribute .........................................15
5. TrunkGroup and Carrier Address Families ........................16
5.1. Address Family Syntax .....................................17
6. Gateway Operation ..............................................18
6.1. Session Establishment .....................................18
6.2. UPDATE Messages ...........................................19
6.3. KEEPALIVE Messages ........................................19
6.4. Error Handling and NOTIFICATION Messages ..................19
6.5. TGREP Finite State Machine ................................19
6.6. Call Routing Databases ....................................19
6.7. Multiple Address Families .................................20
6.8. Route Selection and Aggregation ...........................20
7. LS/Proxy Behavior ..............................................20
7.1. Route Consolidation .......................................22
7.2. Aggregation ...............................................23
7.3. Consolidation versus Aggregation ..........................23
8. Security Considerations ........................................23
9. IANA Considerations ............................................24
9.1. Attribute Codes ...........................................24
9.2. Address Family Codes ......................................24
10. Acknowledgments ...............................................25
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................26
It is assumed that the reader of this document is familiar with TRIP [2, 12]. In typical Voice over IP (VoIP) networks, Internet Telephony Administrative Domains (ITADs) will deploy numerous gateways for the purposes of geographical diversity, capacity, and redundancy. When a call arrives at the domain, it must be routed to one of those gateways. Frequently, an ITAD will break its network into geographic Points of Presence (POPs), with each POP containing some number of gateways, and a proxy server element that fronts those gateways. The proxy element is a SIP proxy [11] or H.323 gatekeeper. The proxy server is responsible for managing the access to the POP, and also for determining which of the gateways will receive any given call that arrives at the POP. In conjunction with the proxy server that routes the call signaling, there are two components, the "Ingress LS" (aka "TGREP receiver") and the "Egress LS". The TGREP receiver component maintains TGREP peering relationship with one or more gateways. The routing information received from the gateways is further injected into the Egress LS, which in turn disseminates into the rest of the network on TRIP. For convenience, gateway and GW are used interchangeably.
なお、この文書の読者がトリップ[2]、[12]に精通しているものとします。典型的なボイスオーバーIP（VoIP）のネットワークでは、インターネットテレフォニー管理ドメイン（ITADs）は、地理的な多様性、容量、および冗長性の目的のために、多くのゲートウェイを展開します。呼び出しは、ドメインに到着すると、それはそれらのいずれかのゲートウェイにルーティングする必要があります。しばしば、ITADは、ゲートウェイのいくつかの数、およびそれらの前線のゲートウェイをプロキシサーバーの要素を含む各POPで、プレゼンスの地理的ポイント（POPの）にそのネットワークを中断します。プロキシ要素は、SIPプロキシ[11]またはH.323ゲートキーパーです。プロキシサーバがPOPへのアクセスを管理するための、また、POPに到着する任意のコールを受信するゲートウェイのかを決定する責任があります。ルートコールシグナリングプロキシサーバと連携して、二つの成分、「進入LS」（別名「TGREP受信機」）と「出力LS」があります。 TGREP受信コンポーネントは、1つ以上のゲートウェイとTGREPピアリング関係を維持します。ゲートウェイから受信したルーティング情報は、順番にTRIP上のネットワークの他の部分に発信退出LSに注入されます。便宜のために、ゲートウェイとGWは、交換可能に使用されます。
This configuration is depicted graphically in Figure 1.
この構成を図1にグラフで示されています。
Signaling TGREP
-------------> <----------------
+---------+
| |
| GW |
> +---------+
//
//
SIP // +---------+
<----> // | |
+-------------------------+ // | GW |
| | // +---------+
| +-------------+ |/
| | | |
| | Routing | | +---------+ TO PSTN
| | Proxy | | | |
---> | | |-----------> | GW | ----->
|+---+-----+ +-----+----+ | +---------+
|| | | | |
|| <+-+ | |--
||Egress LS| |Ingress LS| | --- +---------+
|| | | | | -- | |
|+---------+ +----------+ | -- | GW |
| | -- +---------+
| | -->
+-------------------------+
TRIP +---------+
<----> | |
| GW |
+---------+
Figure 1: Gateway and LS Configuration
図1：ゲートウェイとLSの設定
The decision about which gateway to use depends on many factors, including their availability, remaining call capacity, and call success statistics to a particular Public Switched Telephone Network (PSTN) destination (see [14]). For the proxy to do this adequately, it needs to have access to this information in real-time, as it changes. This means there must be some kind of communications between the proxy and the gateways to convey this information.
使用するゲートウェイどの決定は、コールキャパシティを残り、彼らの可用性を含む多くの要因に依存し、特定の公衆交換電話網（PSTN）の宛先（[14]参照）をスイッチに成功統計を呼び出します。プロキシが適切にこれを行うためには、それが変化して、リアルタイムでこの情報へのアクセス権を持っている必要があります。これは、プロキシと、この情報を伝えるためのゲートウェイとの間の通信のいくつかの種類が存在しなければならないことを意味します。
The TRIP protocol [2] is defined for carrying telephony routing information between providers, for the purposes of getting a call routed to the right provider for termination to the PSTN. However, there is no mechanism defined in TRIP that defines how routes get injected into the TRIP protocol from within the network. Nor does it define mechanisms that would allow the provider to select the specific gateway for terminating a call when it arrives. Those gaps are filled by TGREP.
[2] TRIPプロトコルは、PSTNへの終了を右プロバイダにルーティングされるコールを取得する目的で、プロバイダとの間の電話ルーティング情報を運ぶために定義されます。しかし、ルートがネットワーク内からTRIPプロトコルに注入取得方法を定義TRIPに定義されたメカニズムはありません。また、それは、プロバイダが、それが到着したときに通話を終了するための特定のゲートウェイを選択することができるようになるメカニズムを定義しません。これらのギャップはTGREPによって満たされています。
TGREP allows PSTN gateways or soft switches to inform a signaling server, such as a SIP proxy server or H.323 gatekeeper, of routes it has to the PSTN. These advertisements include fairly dynamic information, such as the remaining capacity in a particular trunk, which is essential for selecting the right gateway.
TGREPは、PSTNに有する経路、例えばSIPプロキシサーバまたはH.323ゲートキーパーとして、PSTNゲートウェイまたはソフトスイッチは、シグナリングサーバに通知することを可能にします。これらの広告は、そのような権利ゲートウェイを選択するために不可欠である特定のトランクの残り容量としてかなり動的な情報を含みます。
TGREP is identical in syntax and overall operation to TRIP. However, it differs in the route processing rules followed by the TGREP receiver, allowing for a route processing function called "consolidation". Consolidation combines multiple routes for the same route destination with different attributes to a single route to prevent loss of routing information. TGREP also defines a set of new attributes, usable by TGREP or TRIP. Finally, TGREP only utilizes a subset of overall TRIP capabilities. Specifically, certain attributes are not utilized (as described below), and the TGREP entities (the sender and receiver) operate in an asymmetric relationship, whereas TRIP allows symmetric and asymmetric.
TGREPは、旅行に構文や全体的な動作は同じです。しかし、「連結」と呼ばれるルート処理機能を可能にする、TGREP受信続く経路処理ルールが異なります。統合は、ルーティング情報の損失を防止するために、単一の経路に異なる属性を持つ同じルート先の複数の経路を組み合わせ。 TGREPもTGREPまたはTRIPによって使用可能な、新たな属性の集合を定義します。最後に、TGREPは、全体的なTRIP機能のサブセットを利用しています。具体的には（後述のように）、特定の属性が使用されない、及びTRIPは、対称および非対称可能一方TGREPエンティティ（送信側と受信側）は、非対称な関係で動作します。
As a general rule, because of a lot of similarities between TRIP and TGREP, frequent reference will be made to the terminologies and formats defined in TRIP [2]. It is suggested that the reader be familiar with the concepts of TRIP like attributes, flags, route types, address families, etc.
原則として、なぜならTRIPとTGREP間の類似性のロットの、頻繁に参照がTRIP [2]で定義された用語およびフォーマットについて説明します。読者がなどの属性、フラグ、ルートタイプ、アドレスファミリ、のようなTRIPの概念に精通していることが示唆されました
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 RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
Some other useful definitions are:
いくつかの他の有用な定義は以下のとおりです。
Circuit: A circuit is a discrete (specific) path between two or more points along which signals can be carried. In this context, a circuit is a physical path, consisting of one or more wires and possibly intermediate switching points.
回路：回路は、信号を実施することができるそれに沿って二つ以上の点の間の離散的（特異的）経路です。この文脈において、回路は、1つ以上のワイヤおよびおそらくは中間切替点からなる、物理パスです。
Trunk: In a network, a trunk is a communication path connecting two switching systems used in the establishment of an end-to-end connection. In selected applications, it may have both its terminations in the same switching system.
トランク：ネットワークでは、トランクは、エンドツーエンド接続の確立で使用される2つのスイッチングシステムを接続する通信路です。選択されたアプリケーションでは、同一の交換システムにおけるその終端の両方を有していてもよいです。
TrunkGroup: A trunkgroup is a set of trunks, traffic engineered as a unit, for the establishment of connections within or between switching systems in which all of the paths are interchangeable except where subgrouped.
TrunkGroup：trunkgroupが内または経路の全てがサブグループ場合を除いて、交換された交換システムとの間の接続を確立するためのユニットとして操作トランク、トラフィックのセットです。
Carrier: A carrier is a company offering telephone and data communications between points (end-users and/or exchanges).
キャリア：キャリアポイント（エンドユーザおよび/または交換機）間の電話およびデータ通信を提供する会社です。
TGREP is a route registration protocol for telephony destinations on a gateway. These telephony destinations could be prefixes, trunkgroups, or carriers. The TGREP sender resides on the GW and gathers all the information from the GW to relay to the TRIP Location Server. A TGREP Receiver is defined, which receives this information and optionally performs operations like consolidation and aggregation (see Section 7.3), and hands over the reachability information to a TRIP Location Server. The routing proxy also uses the information to select the gateway for incoming calls.
TGREPは、ゲートウェイ上のテレフォニー目的地のルート登録プロトコルです。これらのテレフォニー先は接頭辞、trunkgroups、またはキャリアである可能性があります。 TGREPの送信者は、GWに常駐し、TRIPのロケーションサーバにリレーするようにGWからすべての情報を収集します。必要に応じてこの情報を受信し、定義されTGREP Receiverは、TRIPロケーション・サーバに到達可能性情報上に統合し、凝集などの操作（7.3節を参照）、及び手を行います。ルーティングプロキシは、着信呼のためのゲートウェイを選択するために情報を使用します。
The TGREP sender establishes a session to the TGREP receiver using a procedure similar to session establishment in TRIP. After the session establishment, the TGREP sender sends the reachability information in the UPDATE messages. The UPDATE messages have the same format as in TRIP. However, certain TRIP attributes are not relevant in TGREP; a TGREP receiver MAY ignore them if they are present in a TGREP message. The following TRIP attributes do not apply to TGREP:
TGREP送信者は、TRIPのセッション確立と同様の手順を使用してTGREP受信機とのセッションを確立します。セッション確立後、TGREPの送信者は、UPDATEメッセージに到達可能性情報を送信します。 UPDATEメッセージは、TRIPと同じフォーマットを有します。しかし、特定のTRIP属性がTGREPには関係ありません。彼らはTGREPメッセージに存在している場合TGREP受信機はそれらを無視するかもしれません。次TRIP属性がTGREPには適用されません。
1. AdvertisementPath 2. RoutedPath 3. AtomicAggregate 4. LocalPreference 5. MultiExitDisc 6. ITADTopology 7. ConvertedRoute
1. AdvertisementPath 2. RoutedPath 3. AtomicAggregate 4. LocalPreference 5. MultiExitDisc 6. ITADTopology 7. ConvertedRoute
In addition, TGREP defines the following new attributes in this document that can be carried in a TGREP UPDATE message.
また、TGREPはTGREP UPDATEメッセージ中で実施することができる。この文書に記載されている次の新しい属性を定義します。
- TotalCircuitCapacity: This attribute identifies the total number of PSTN circuits that are available on a route to complete calls.
- TotalCircuitCapacity：この属性は、呼び出しを完了するために、ルート上で利用可能なPSTN回線の総数を特定します。
- AvailableCircuits: This attribute identifies the number of PSTN circuits that are currently available on a route to complete calls.
- AvailableCircuits：この属性は、呼び出しを完了するために、ルート上で現在利用可能なPSTN回線の番号を識別します。
- CallSuccess: This attribute represents information about the number of normally terminated calls out of a total number of attempted calls.
- CallSuccess：この属性は、試行されたコールの総数のうち正常に終了コール数についての情報を表します。
- Prefix (E164): This attribute is used to represent the list of E164 prefixes to which the respective route can complete calls.
- プレフィックス（E164）：この属性は、それぞれのルートが呼び出しを完了することができたE164プレフィックスのリストを表すために使用されます。
- Prefix (Decimal Routing Number): This attribute is used to represent the list of Decimal prefixes to which the respective route can complete calls.
- プレフィックス（小数点ルーティング番号）：この属性は、それぞれのルートが呼び出しを完了することができたに進接頭辞のリストを表すために使用されます。
- Prefix (Hexadecimal Routing Number): This attribute is used to represent the list of Hexadecimal prefixes to which the respective route can complete calls.
- プレフィックス（16進数ルーティング番号）：この属性は、そのそれぞれのルートが呼び出しを完了できるために進接頭辞のリストを表すために使用されます。
- TrunkGroup: This attribute enables providers to route calls to destinations through preferred trunks.
- TrunkGroup：この属性が優先トランクを使用して宛先へのコールをルーティングするようにプロバイダーを可能にします。
- Carrier: This attribute enables providers to route calls to destinations through preferred carriers.
- キャリア：この属性は、好ましい担体て目的地へのコールをルーティングするようにプロバイダーを可能にします。
In the rest of the document, we specify attributes and address families used in TGREP. The new attributes and address families introduced are also applicable for general usage in TRIP except where noted (AvailableCircuits attribute, for example).
文書の残りの部分では、我々はTGREPで使用される属性とアドレスファミリを指定します。導入された新しい属性やアドレスファミリーにも注目（AvailableCircuitsは、例えば、属性）場合を除き、TRIPにおける一般的な使用のために適用されます。
Due to its usage within a service provider network, TGREP makes use of a subset of the attributes defined for TRIP, in addition to defining several new ones. In particular, the following attributes from TRIP are applicable to TGREP:
サービスプロバイダーネットワーク内での用途に、TGREPは、いくつかの新しいものを定義するだけで、TRIPのために定義された属性のサブセットを使用しています。特に、TRIPから次の属性がTGREPに適用されます。
1. WithdrawnRoutes 2. ReachableRoutes 3. NexthopServer 4. Prefix 5. Communities
1. WithdrawnRoutes 2. ReachableRoutes 3. NexthopServer 4.プレフィックス5.コミュニティ
TGREP also defines several new attributes, described in this section. These are TotalCircuitCapacity, AvailableCircuits, CallSuccess, TrunkGroup, and Carrier. As mentioned above, these new attributes are usable by TRIP unless noted otherwise.
TGREPまた、このセクションで説明するいくつかの新しい属性を定義します。これらはTotalCircuitCapacity、AvailableCircuits、CallSuccess、TrunkGroup、およびキャリアです。前述したように、特に断りのない限り、これらの新しい属性はTRIPで使用可能です。
A TGREP UPDATE supports the following attributes:
TGREPのUPDATEは、次の属性をサポートしています。
1. TotalCircuitCapacity 2. AvailableCircuits 3. CallSuccess 4. Prefix (E.164, Pentadecimal routing number, Decimal routing number) 5. TrunkGroup 6. Carrier
1. TotalCircuitCapacity 2. AvailableCircuits 3. CallSuccess 4.プレフィックス（E.164、十五進法ルーティング番号、進ルーティング番号）5. TrunkGroup 6キャリア
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 13.
必須：偽。必要なフラグ：よく知られていません。潜在的なフラグ：なし。 TRIPタイプコード：13。
The TotalCircuitCapacity attribute identifies the total number of PSTN circuits that are available on a route to complete calls. It is used in conjunction with the AvailableCircuits attribute in gateway selection by the LS. The total number of calls sent to the specified route on the gateway cannot exceed this total circuit capacity under steady state conditions.
TotalCircuitCapacity属性は、呼を完了するために、経路上入手可能であるPSTN回線の総数を識別する。これは、LSによって、ゲートウェイ選択でAvailableCircuits属性と一緒に使用されます。ゲートウェイ上の指定されたルートに送信されたコールの合計数は、定常状態条件下でこの回路全体の容量を超えることはできません。
The TotalCircuitCapacity attribute is used to reflect the administratively provisioned capacity as opposed to the availability at a given point in time as provided by the AvailableCircuits attribute. Because of its relatively static nature, this attribute MAY be propagated beyond the LS that receives it.
TotalCircuitCapacity属性はAvailableCircuits属性によって提供される特定の時点で利用可能とは対照的に管理プロビジョニング能力を反映するために使用されます。その比較的静的な性質のため、この属性は、それを受けたLSを超えて増殖させることができます。
TotalCircuitCapacity represents the total number of possible calls at any instant. This is not expected to change frequently. This can change, for instance, when certain telephony trunks on the gateway are taken out of service for maintenance purposes.
TotalCircuitCapacityは、任意の時点で可能なコールの合計数を表します。これは、頻繁に変更することが予想されていません。これは、ゲートウェイ上の特定の電話トランクがメンテナンスのためのサービスから取り出されたときに、例えば、変更することができます。
The TotalCircuitCapacity attribute is a 4-octet unsigned integer. It represents the total number of circuits available for terminating calls through this advertised route. This attribute represents a potentially achievable upper bound on the number of calls that can be terminated on this route in total.
TotalCircuitCapacity属性は4オクテットの符号なし整数です。なお、この広告経路を介して通話を終了するために利用可能な回路の総数を表します。この属性は、合計で、このルートで終了させることができるコール数の潜在的に実現可能な上限を表します。
Routes MAY be originated containing the TotalCircuitCapacity attribute.
ルートはTotalCircuitCapacity属性を含む由来するものであってもよいです。
The TotalCircuitCapacity attribute MAY be used for route selection. Since one of its primary applications is load balancing, an LS will wish to choose a potentially different route (amongst a set of routes for the same destination), on a call-by-call basis. This can be modeled as re-running the decision process on the arrival of each call. The aggregation and dissemination rules for routes with this attribute ensure that re-running this selection process never results in propagation of a new route to other peers.
TotalCircuitCapacity属性は、ルート選択のために使用されるかもしれません。その主要な用途の一つは負荷分散であるため、LSは、コールごとに、（同じ宛先のルートのセットの中）潜在的に異なるルートを選択することを望むであろう。これは、各コールの到着時に再実行する決定プロセスとしてモデル化することができます。この属性を持つルートの集約と発信ルールを再実行し、この選択プロセスは、他のピアへの新しいルートの伝播につながることはありませんことを。確認してください
An LS MAY aggregate routes to the same prefix that contains a TotalCircuitCapacity attribute. It SHOULD add the values of the individual routes to determine the value for the aggregated route in the same ITAD.
LSはTotalCircuitCapacity属性が含まれている同じプレフィックスへのルートを集約することができます。これは、同じITADに集約ルートの値を決定するために、個々の経路の値を追加する必要があります。
Since this attribute reflects the static capacity of the gateway's circuit resources, it is not expected to change frequently. Hence, the LS receiving this attribute MAY disseminate it to other peers, both internal and external to the ITAD.
この属性は、ゲートウェイの回路資源の静電容量を反映しているので、頻繁に変更することが予想されていません。したがって、この属性を受けたLSはITADの内部と外部の両方の、他のピアにそれを普及するかもしれません。
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 14.
必須：偽。必要なフラグ：よく知られていません。潜在的なフラグ：なし。 TRIPタイプコード：14。
The AvailableCircuits attribute identifies the number of PSTN circuits that are currently available on a route to complete calls. The number of additional calls sent to that gateway for that route cannot exceed the circuit capacity. If it does, the signaling protocol will likely generate errors, and calls will be rejected.
AvailableCircuits属性は、呼び出しを完了するために、ルート上で現在利用可能なPSTN回線の番号を識別します。そのルートにそのゲートウェイに送信された付加的なコールの数は、回路の容量を超えることはできません。それがない場合は、シグナリングプロトコルは、おそらくエラーが発生します、との通話は拒否されます。
The AvailableCircuits attribute is used ONLY between a gateway and its peer LS responsible for managing that gateway. If it is received in a route, it is not propagated.
AvailableCircuits属性ONLYそのゲートウェイの管理を担当するゲートウェイとそのピアLSの間で使用されています。それがルートで受信した場合、それが伝播されません。
The AvailableCircuits attribute is a 4-octet unsigned integer. It represents the number of circuits remaining for terminating calls to this route.
AvailableCircuits属性は4オクテットの符号なし整数です。これは、この経路へのコールを終了するための残りの回路の数を表します。
Routes MAY be originated containing the AvailableCircuits attribute. Since this attribute is highly dynamic, changing with every call, updates MAY be sent as it changes. However, it is RECOMMENDED that measures be taken to help reduce the messaging load from route origination. It is further RECOMMENDED that a sufficiently large window of time be used to provide a useful aggregated statistic.
ルートはAvailableCircuits属性を含む由来するものであってもよいです。この属性は、すべての呼び出しで変更する、非常に動的であるので、それは変化して、アップデートを送るかもしれ。しかし、対策がルート発信からメッセージングの負荷を軽減するために取られることが推奨されます。時間の十分に大きな窓が有用集約統計を提供するために使用されることがさらに推奨されます。
The AvailableCircuits attribute MAY be used for route selection. Since one of its primary applications is load balancing, an LS will wish to choose a potentially different route (amongst a set of routes for the same prefix) on a call-by-call basis. This can be modeled as re-running the decision process on the arrival of each call. The aggregation and dissemination rules for routes with this attribute ensure that re-running this selection process never results in propagation of a new route to other peers.
AvailableCircuits属性は、ルート選択のために使用されるかもしれません。その主な用途の一つは、負荷分散であることから、LSは、コールごとに（同じプレフィックスのルートのセットの中で）潜在的に異なるルートを選択することを望むだろう。これは、各コールの到着時に再実行する決定プロセスとしてモデル化することができます。この属性を持つルートの集約と発信ルールを再実行し、この選択プロセスは、他のピアへの新しいルートの伝播につながることはありませんことを。確認してください
Not applicable.
適用できません。
Routes MUST NOT be disseminated with the AvailableCircuits attribute. The attribute is meant to reflect capacity at the originating gateway only. Its highly dynamic nature makes it inappropriate to disseminate in most cases.
ルートはAvailableCircuits属性を広めてはなりません。属性は、発信ゲートウェイでの容量を反映するものです。その非常に動的な性質は、ほとんどの場合に普及することが不適切になります。
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 15.
必須：偽。必要なフラグ：よく知られていません。潜在的なフラグ：なし。 TRIPタイプコード：15。
The CallSuccess attribute is an attribute used ONLY between a gateway and its peer LS responsible for managing that gateway. If it is received in a route, it is not propagated.
CallSuccess属性は、そのゲートウェイの管理を担当するゲートウェイとそのピアLSの間でのみ使用属性です。それがルートで受信した場合、それが伝播されません。
The CallSuccess attribute provides information about the number of normally terminated calls out of a total number of attempted calls.
CallSuccess属性が試行されたコールの総数のうち正常に終了コール数に関する情報を提供します。
CallSuccess is to be determined by the gateway based on the Disconnect cause code at call termination. For example, a call that reaches the Alerting stage but does not get connected due to the unavailability of the called party, or the called party being busy, is conventionally considered a successful call. On the other hand, a call that gets disconnected because of a circuit or resource being unavailable is conventionally considered a failed call. The exact mapping of disconnect causes to CallSuccess is at the discretion of the gateway reporting the attribute.
CallSuccessは、コール終了時に切断原因コードに基づいて、ゲートウェイによって決定されるべきです。たとえば、アラートの段階に到達したが、被呼者、または話中着信側の使用不能に起因して接続されないコールは、従来、呼び出しが成功と見なされます。一方、利用できないためである回路またはリソースの切断された呼は、通常失敗したコールであると考えられます。 CallSuccessに切断原因の正確なマッピングは、属性を報告するゲートウェイの裁量です。
The CallSuccess attribute is used by the LS to keep track of failures in reaching certain telephony destinations through a gateway(s) and to use that information in the gateway selection process to enhance the probability of successful call termination.
CallSuccess属性は、ゲートウェイ（複数可）を介して、特定の電話の目的地に到達するには失敗を追跡するために、成功した着信の確率を高めるために、ゲートウェイ選択プロセスでその情報を使用するLSによって使用されます。
This information can be used by the LS to consider alternative gateways to terminate calls to those destinations with a better likelihood of success.
この情報は、成功のより良い可能性とそれらの宛先へのコールを終了するには、代替ゲートウェイを検討するLSで使用することができます。
The CallSuccess attribute is composed of two component fields -- each represented as a 4-octet unsigned integer. The first component field represents the total number of calls terminated successfully for the advertised destination on a given address family over a given window of time. The second component field represents the total number of attempted calls for the advertised destination within the same window of time.
4オクテットの符号なし整数として表される各 - CallSuccess属性は、二つの成分のフィールドから構成されています。最初のコンポーネントのフィールドは、所与の時間窓の上に与えられたアドレスファミリのアドバタイズされた宛先に正常に終了したコールの合計数を表します。第二の成分のフィールドは、同じ時間ウィンドウ内でアドバタイズ宛先の試行されたコールの合計数を表します。
When the value for the total number of attempted calls wraps around, the counter value for the number of successful calls is reset to keep it aligned with the other component over a given window of time. The TGREP receiver using this information should obtain this information frequently enough to prevent loss of significance.
試行されたコールの合計数の値がラップアラウンドするとき、成功したコールの数のカウンタ値は、所与の時間窓を介して他の構成要素と位置合わせして維持するリセットされます。重要性の損失を防ぐのに十分な頻度でこの情報を取得する必要があり、この情報を使用してTGREP受信機。
Routes MAY be originated containing the CallSuccess attribute. This attribute is expected to get statistically significant with passage of time as more calls are attempted. It is RECOMMENDED that sufficiently large windows be used to provide a useful aggregated statistic.
ルートはCallSuccess属性を含む由来するものであってもよいです。この属性は、より多くのコールが試行されるように時間の経過とともに、統計的に有意で取得することが期待されています。十分に大きな窓が便利集約統計を提供するために使用することをお勧めします。
The CallSuccess attribute MAY be used for route selection. This attribute represents a measure of success of terminating calls to the advertised destination(s). This information MAY be used to select from amongst a set of alternative routes to increase the probability of successful call termination.
CallSuccess属性は、ルート選択のために使用されるかもしれません。この属性は、アドバタイズ先（複数可）への呼び出しを終了する成功の尺度を表します。この情報は、成功した着信の確率を高めるために、代替ルートのセットの中から選択することができます。
Not applicable.
適用できません。
Routes MUST NOT be disseminated with the CallSuccess attribute. Its potential to change dynamically does not make it suitable to disseminate.
ルートはCallSuccess属性で配布されてはなりません。動的に変化するために、その可能性が普及することは、適切なことはありません。
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Codes: 16 for E164 Prefix, 17 for Pentadecimal Routing Number Prefix, and 18 for Decimal Routing Number Prefix.
必須：偽。必要なフラグ：よく知られていません。潜在的なフラグ：なし。 TRIPタイプコード：10進数ルーティング番号プレフィックスのE164プレフィックス、十五進法ルーティング番号プレフィックスの17、及び18のための16。
The Prefix attribute is used to represent the list of prefixes to which the respective route can complete calls. This attribute is intended to be used with the Carrier or TrunkGroup address family (discussed in Section 5).
prefix属性は、それぞれのルートが呼び出しを完了することができたプレフィックスのリストを表すために使用されます。この属性は、キャリアやTrunkGroupアドレスファミリ（第5節で説明）で使用することを意図しています。
Though it is possible that all prefix ranges may be reachable through a given carrier, administrative issues could make certain ranges preferable to others.
それはすべてのプレフィックス範囲が与えられたキャリア経由で到達可能である可能性がありますが、管理上の問題は他の人に一定の範囲が好適で作ることができます。
The Prefix attribute could be E.164, Decimal, or Pentadecimal (refer to TRIP [2]), each of them having its own type code. The Prefix attribute is encoded as a sequence of prefix values in the attribute Value field. The prefixes are listed sequentially with no padding as shown in Figure 2. Each prefix includes a 2-octet Length field that represents the length of the Address field in octets. The order of prefixes in the attribute is not significant.
prefix属性は、それらのそれぞれが独自のタイプコードを有する、（[2]旅行参照）E.164、進数、又は十五進法であってもよいです。 prefix属性は、属性値]フィールドにプレフィックス値のシーケンスとして符号化されています。各プレフィックスは、オクテットのアドレスフィールドの長さを表す2オクテットの長さフィールドを含む図2に示すように、接頭辞のないパディングで連続的に記載されています。属性内の接頭辞の順序は重要ではありません。
The presence of the Prefix Attribute with the Length field of the attribute as 0 signifies that the TGREP GW can terminate ALL prefixes of that prefix type (E.164, Decimal, or Pentadecimal) for the given Reachable route(s). This is not equivalent to excluding the Prefix attribute in the TGREP update.
0 TGREP GWが所定の到達可能経路（S）のためにそのプレフィックスタイプ（E.164、進数、又は十五進法）の全てのプレフィックスを終了することができることを意味するようにプレフィックスの存在は、属性の長さフィールドと属性。これはTGREPアップデートでprefix属性を除くと同等ではありません。
< 2 octets > < Length1 octets > < 2 octets > < Length2 octets >
<2つのオクテット> <長さ1オクテット> <2つのオクテット> <LENGTH2オクテット>
+------------+--------------//--+------------+--------------//--+-
| Length1 | Prefix1 | Length2 | Prefix2 | ...
+------------+--------------//--+------------+--------------//--+-
Figure 2: Prefix Format
図2：プレフィックスフォーマット
Routes MAY be originated containing the Prefix attribute.
ルートは、prefix属性を含む由来するものであってもよいです。
The Prefix attribute MAY be used for route selection.
prefix属性は、ルート選択のために使用されるかもしれません。
Routes with differing Prefix attributes MUST NOT be aggregated. Routes with the same value in the Prefix attribute MAY be aggregated and the same Prefix attribute attached to the aggregated object.
異なるプレフィックス属性を持つルートは集約されてはなりません。 prefix属性に同じ値を持つルートが集約されてもよく、同じプレフィックスの属性は、集約オブジェクトに取り付けられました。
The LS receiving this attribute should disseminate to other peers, both internal and external to the ITAD.
この属性を受けたLSはITADの内部と外部の両方の他のピアに広める必要があります。
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 19.
必須：偽。必要なフラグ：よく知られていません。潜在的なフラグ：なし。 TRIPタイプコード：19。
The TrunkGroup attribute is used to represent the list of trunkgroups on the gateway used to complete calls. It enables providers to route calls to destinations through preferred trunks. This attribute is relatively static.
TrunkGroup属性は、呼び出しを完了するために使用されるゲートウェイ上trunkgroupsのリストを表すために使用されます。これは、好適なトランクを使用して宛先へのコールをルーティングするようにプロバイダーを可能にします。この属性は、比較的静的です。
The TrunkGroup attribute is a variable-length attribute that is composed of a sequence of trunkgroup identifiers. It indicates that the gateway can complete the call through any trunkgroup identifier indicated in the sequence.
TrunkGroup属性はtrunkgroup識別子のシーケンスで構成されている可変長属性です。これは、ゲートウェイがシーケンスに示さ任意trunkgroup識別子を介してコールを完了することができることを示しています。
Each trunkgroup identifier is encoded as a Length-Value field (shown in Figure 3 below). The Length field is a 1-octet unsigned numeric value. The Value field is a variable-length field consisting of two subfields, a trunkgroup label followed by a trunk context, the two subfields separated by the delimiter ";" (semicolon). Both the trunkgroup label and the trunk context subfields are of variable length. The Length field represents the total size of the Value field including the delimiter.
各trunkgroup識別子は、（図3以下に示す）長さ - 値フィールドとして符号化されます。 Lengthフィールドは1オクテットの符号なしの数値です。 Valueフィールドは、2つのサブフィールド、トランクコンテキスト続いtrunkgroupラベル、区切り文字で区切られた2つのサブフィールドからなる可変長フィールドです「;」 （セミコロン）。 trunkgroupラベルやトランクコンテキストサブフィールドの両方が可変長です。 Lengthフィールドは、区切り記号を含む値フィールドの合計サイズを表します。
The permissible character set for the trunk group label and the trunkgroup context subfields and the associated ABNF [8] is per rules outlined in [4].
トランクグループラベルの許容文字セットとtrunkgroupコンテキストサブフィールドと関連したABNF [8]に概説ルールごとである[4]。
The presence of the TrunkGroup attribute with the Length field of the attribute as 0 signifies that the TGREP GW can terminate ALL trunkgroups for the given Reachable route(s).
0として、属性の長さフィールドを持つTrunkGroup属性の存在はTGREP GWは、所与の到達可能経路（S）のためにALL trunkgroupsを終了することができることを意味します。
< 1 octet > < Length1 octets > < 1 octet > < Length2 octets >
<1オクテット> <長さ1オクテット> <1オクテット> <LENGTH2オクテット>
+-----------+--------------//--+-----------+--------------//--+-
| Length1 | TrunkGroup 1 | Length2 | TrunkGroup 2 | ...
+-----------+--------------//--+-----------+--------------//--+-
Figure 3: TrunkGroup Syntax
図3：TrunkGroup構文
Routes MAY be originated containing the TrunkGroup attribute.
ルートはTrunkGroup属性を含む由来するものであってもよいです。
The TrunkGroup attribute MAY be used for route selection. Certain trunkgroups MAY be preferred over others based on provider policy.
TrunkGroup属性は、ルート選択のために使用されるかもしれません。特定trunkgroupsは、プロバイダのポリシーに基づいて、他の人よりも好ましいです。
Routes with differing TrunkGroup attributes MUST NOT be aggregated. Routes with the same value in the TrunkGroup attribute MAY be aggregated and the same TrunkGroup attribute attached to the aggregated object.
TrunkGroup属性が異なるルートは集約されてはなりません。 TrunkGroup属性に同じ値を持つルートが集約されてもよく、同じTrunkGroup属性が集約オブジェクトに取り付けられました。
This attribute is not expected to change frequently. Hence, the LS receiving this attribute MAY disseminate it to other peers, internal to ITAD. Routes SHOULD not be disseminated external to the ITAD, with TrunkGroup attribute.
この属性は、頻繁に変更することが予想されていません。したがって、この属性を受けたLSはITADに、他のピアへの内部を、それを普及するかもしれません。ルートはTrunkGroup属性で、ITAD外部に普及すべきではありません。
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 20.
必須：偽。必要なフラグ：よく知られていません。潜在的なフラグ：なし。 TRIPタイプコード：20。
The Carrier attribute is used to represent the list of carriers that the gateway uses to complete calls. It enables providers to route calls to destinations through preferred carriers. This attribute is relatively static.
キャリア属性は、ゲートウェイが呼び出しを完了するために使用するキャリアのリストを表すために使用されます。これは、好ましい担体て目的地へのコールをルーティングするようにプロバイダーを可能にします。この属性は、比較的静的です。
The Carrier attribute is a variable-length attribute that is composed of a sequence of carrier identifiers. It indicates that the route can complete the call to any of the carriers represented in the sequence of carrier identifiers [13].
キャリア属性は、キャリア識別子のシーケンスで構成されている可変長の属性です。これは、経路は、キャリア識別子[13]の配列で表されるキャリアのいずれかにコールを完了することができることを示しています。
Each carrier identifier is encoded as a Length-Value field (shown in Figure 4 below). The Length field is a 1-octet unsigned numeric value. The Value field is a variable-length field.
各キャリア識別子は、（図4以下に示す）長さ - 値フィールドとして符号化されます。 Lengthフィールドは1オクテットの符号なしの数値です。 Valueフィールドは可変長フィールドです。
The permissible character set for the Value field and the associated ABNF [8] is per rules outlined in [5]. Specifically, it carries "global-cic" or "local-cic" [5]. In case of "local-cic", the "phonedigit-hex" part and the "cic-context" part would be separated by the delimiter ";". Hence, absence or presence of the delimiter can be used to determine if the value is a "global-cic" or a "local-cic". The Length field represents the total size of the Value field including the delimiter.
Valueフィールドの許容文字セットと関連するABNF [8] [5]に概説ルールごとです。具体的には、「グローバルCIC」または「ローカルCIC」を担持する[5]。 「ローカルCIC」の場合、「phonedigit-ヘクス」部分と「CICコンテキスト」部分はデリミタによって分離されます「;」。したがって、デリミタの有無は、値が「グローバルCIC」または「ローカルCIC」であるかどうかを決定するために使用することができます。 Lengthフィールドは、区切り記号を含む値フィールドの合計サイズを表します。
The presence of the Carrier attribute with the Length field of the attribute as 0 signifies that the TGREP GW can terminate ALL Carriers for the given Reachable route(s).
0として、属性の長さフィールドを持つキャリア属性の存在はTGREP GWは、所与の到達可能経路（S）のためのすべてのキャリアを終了することができることを意味します。
< 1 octet > < Length1 octets > < 1 octet > < Length2 octets >
<1オクテット> <長さ1オクテット> <1オクテット> <LENGTH2オクテット>
+-----------+--------------//--+-----------+--------------//--+-
| Length1 | Carrier 1 | Length2 | Carrier 2 | ...
+-----------+--------------//--+-----------+--------------//--+-
Figure 4: Carrier Syntax
図4：キャリア構文
Routes MAY be originated containing the Carrier attribute.
ルートは、キャリアの属性を含む由来するものであってもよいです。
The Carrier attribute MAY be used for route selection. Certain carriers MAY be preferred over others based on provider policy.
キャリア属性は、ルート選択のために使用されるかもしれません。一部のキャリアは、プロバイダのポリシーに基づいて、他の人よりも好ましいです。
Routes with differing Carrier attributes MUST NOT be aggregated. Routes with the same value in the Carrier attribute MAY be aggregated and the same Carrier attribute attached to the aggregated object.
異なるキャリアの属性を持つルートは集約されてはなりません。キャリア属性に同じ値を持つルートが集約されてもよく、同じキャリア属性は、集約オブジェクトに取り付けられました。
This attribute is not expected to change frequently. Hence, the LS receiving this attribute MAY disseminate it to other peers, both internal and external to the ITAD.
この属性は、頻繁に変更することが予想されていません。したがって、この属性を受けたLSはITADの内部と外部の両方の、他のピアにそれを普及するかもしれません。
As described in TRIP [2], the Address Family field gives the type of address for the route. Two new address families and their codes are defined in this section:
TRIP [2]に記載のように、アドレスファミリフィールドは、ルートのアドレスの種類を与えます。二つの新しいアドレスファミリとそのコードは、このセクションで定義されています。
Code Address Family
4 TrunkGroup
5 Carrier
When a set of GWs is to be managed at the granularity of carriers or trunkgroups, then it may be more appropriate for a GW to advertise routes using the Carrier address family or TrunkGroup address family, respectively. Also, in a TGREP association between the gateway and the LS responsible for managing that gateway, there are some attributes that more naturally fit in as advertised properties of trunkgroups or carriers rather than that of advertised prefixes, for example, the AvailableCircuit information on a particular trunkgroup or a particular carrier. To express this relationship, the existing TRIP address families are inadequate. We need separate address families that can associate certain properties like AvailableCircuits information to trunkgroups or carriers.
GWのセットが担体またはtrunkgroupsの単位で管理する場合にGWは、それぞれ、キャリアアドレスファミリーまたはTrunkGroupアドレスファミリを使用してルートをアドバタイズするために、それがより適切であり得ます。また、ゲートウェイとそのゲートウェイの管理を担当LS間TGREP関連で、より自然例えば、むしろアドバタイズされたプレフィクスよりもtrunkgroupsまたは担体のアドバタイズ特性として合ういくつかの属性があり、特定のにAvailableCircuit情報trunkgroupまたは特定のキャリア。この関係を表現するために、既存のTRIPアドレスファミリは不十分です。私たちは、trunkgroupsやキャリアにAvailableCircuits情報などの特定のプロパティを関連付けることができ、別のアドレスファミリを必要とします。
The primary benefits of this model are as follows:
次のようにこのモデルの主な利点は以下のとおりです。
- It allows a service provider to route calls based strictly on the trunkgroups or carriers.
- それは厳密にtrunkgroupsまたはキャリアに基づいてコールをルーティングサービスプロバイダを可能にします。
- It facilitates more accurate reporting of attributes of a dynamic nature like AvailableCircuits by providing the ability to manage resources at the granularity of a trunkgroup or a carrier.
- それはtrunkgroupやキャリアの粒度でリソースを管理する機能を提供することにより、AvailableCircuitsのような動的な性質の属性のより正確な報告を容易にします。
- It enables scalability as gateways can get really large with the ability to provision hundreds or a few thousand circuits, and this can increase the potential for traffic that reports dynamic resource information between the gateway and the LS. The model introduced can potentially alleviate this UPDATE traffic, hence increasing efficiency and providing a scalable gateway registration model.
- ゲートウェイが提供数百または数千の回路への能力を持つ非常に大きな得ることができるように、それは、スケーラビリティを可能にし、これは、ゲートウェイとLSの間の動的なリソース情報を報告し、トラフィックの可能性を高めることができます。導入されたモデルは、潜在的に効率を高め、スケーラブルゲートウェイ登録モデルを提供するため、この更新トラフィックを軽減することができます。
Consider the generic TRIP route format from TRIP [2] shown below.
以下に示すTRIP [2]から、ジェネリックTRIPルート形式を考えます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Address Family | Application Protocol |
+---------------+---------------+---------------+---------------+
| Length | Address (variable) ...
+---------------+---------------+---------------+---------------+
Figure 5: Generic TRIP Route Format
図5：一般的なTRIPルートフォーマット
The Address Family field will be used to represent the type of the address associated for this family, which is based on the TrunkGroup or Carrier. The codes for the new address families have been allocated by IANA.
アドレスファミリフィールドがTrunkGroupまたはキャリアに基づいており、この家族のために関連付けられているアドレスの種類を表すために使用されます。新しいアドレスファミリのコードは、IANAによって割り当てられています。
The code for the TrunkGroup address family is 4, and the code for the Carrier address family is 5.
TrunkGroupアドレスファミリのコードは4であり、キャリアのアドレスファミリのコードは5です。
The Application Protocol field is the same as the one for the Decimal, Pentadecimal, and E.164 address families defined in TRIP [2]. The Length field represents the total size of the Address field in bytes.
アプリケーションプロトコルフィールドは、TRIPで定義された進数、十五進法、およびE.164アドレス家族のためのものと同じである[2]。 Lengthフィールドは、バイト単位でアドレスフィールドの合計サイズを表します。
The value in the Address field represents either the TrunkGroup or Carrier address family, and the syntax is as follows:
アドレスフィールドの値はTrunkGroupやキャリアアドレスファミリのいずれかを表し、構文は次のとおりです。
For the TrunkGroup address family, the Address field represents a TrunkGroup value that is defined as specified in Section 4.5.1, "TrunkGroup Syntax".
TrunkGroupアドレスファミリの場合は、アドレスフィールドは、セクション4.5.1、「TrunkGroup構文」に指定されているように定義されてTrunkGroup値を表しています。
For the Carrier address family, the Address field represents a Carrier value. This is the same as the Value field specified in an earlier Section 4.6.1, "Carrier Syntax".
キャリアアドレスファミリの場合は、アドレスフィールドには、キャリア値を表しています。これは、以前の4.6.1、「キャリアの構文」で指定した値フィールドと同じです。
The above mentioned address families are not hierarchical, but flat. If a gateway supports any of these address families, it should include that address family as one of the Route types supported in the OPEN message capability negotiation phase.
上記のアドレスファミリは、階層が、平坦ではありません。ゲートウェイはこれらのアドレスファミリのいずれかをサポートしている場合、それがOPENメッセージ能力交渉段階でサポートされているルートの種類の一つとして、そのアドレスファミリを含める必要があります。
The following attributes are currently defined to be used with all the address families including the TrunkGroup and Carrier address families.
以下の属性は、現在TrunkGroupとキャリアアドレスファミリを含む、すべてのアドレスファミリで使用されるように定義されています。
- AvailableCircuits attribute - TotalCircuitCapacity attribute - CallSuccess attribute
- AvailableCircuits属性 - TotalCircuitCapacity属性 - CallSuccess属性
It is recommended that the above three attributes be used by the gateway with the TrunkGroup or Carrier address family, if possible. This will potentially offer a more efficient resource reporting framework, and a scalable model for gateway provisioning.
可能な場合は、上記の3つの属性は、TrunkGroupまたはキャリアアドレスファミリとのゲートウェイで使用することをお勧めします。これは、潜在的に、より効率的なリソースの報告フレームワーク、およびゲートウェイのプロビジョニングのためのスケーラブルなモデルを提供します。
However, when the gateway is not using the TrunkGroup or Carrier address family, it MAY use the above attributes with the Decimal, Pentadecimal, and E.164 address families.
ゲートウェイはTrunkGroupやキャリアアドレスファミリを使用しない場合には、それは十進、十五進法、およびE.164アドレスファミリーと上記の属性を使用するかもしれません。
The Prefix attribute cannot be used when the address family is E164 numbers, Pentadecimal routing numbers, or Decimal routing numbers.
アドレスファミリは、E164番号、十五進法のルーティング番号、または小数ルーティング番号であるとき、prefix属性を使用することはできません。
The Carrier attribute cannot be used if the address family type is Carrier.
アドレスファミリータイプがキャリアの場合、キャリアの属性を使用することはできません。
The TrunkGroup attribute cannot be used if the address family type is TrunkGroup.
アドレスファミリータイプがTrunkGroupある場合TrunkGroup属性を使用することはできません。
A gateway uses TGREP to advertise its reachability to its domain's Location Server(s) (LS, which are closely coupled with proxies). The gateway operates in TRIP Send Only mode since it is only interested in advertising its reachability, but is not interested in learning about the reachability of other gateways and other domains. Also, the gateway will not create its own call routing database. In this section, we describe the operation of TGREP on a gateway.
ゲートウェイは、そのドメインのロケーションサーバ（S）（密接プロキシに連結されているLS）への到達可能性をアドバタイズするTGREPを使用しています。ゲートウェイは、その到達可能性を宣伝にのみ関心があるためOnlyモードを送るTRIPで動作しますが、他のゲートウェイと他のドメインの到達可能性についての学習に興味を持っていないです。また、ゲートウェイは、独自のコールルーティングデータベースを作成しません。ここでは、ゲートウェイ上TGREPの動作を説明します。
When opening a peering session with a TGREP receiver, a TGREP gateway follows exactly the same procedures as any other TRIP entity. The TGREP gateway sends an OPEN message that includes a Send Receive Capability in the Optional Parameters. The Send Receive Capability is set by the gateway to Send Only. The OPEN message also contains the address families supported by the gateway. The remainder of the peer session establishment is identical to TRIP.
TGREP受信機とのピアリングセッションを開くとき、TGREPゲートウェイは、他のTRIPエンティティとまったく同じ手順に従います。 TGREPゲートウェイが送信オプションパラメータでの受信機能を備えてOPENメッセージを送信します。送信、受信能力をのみ送信するためのゲートウェイで設定されています。 OPENメッセージは、ゲートウェイでサポートされているアドレスファミリが含まれています。ピアセッション確立の残りの部分は、TRIPと同一です。
Once the peer session has been established, the gateway sends UPDATE messages to the TRIP LS with the gateway's entire reachability. The gateway also sends any attributes associated with the routes.
ピアセッションが確立されると、ゲートウェイは、ゲートウェイの全体の到達可能性とTRIP LSにUPDATEメッセージを送信します。ゲートウェイは、ルートに関連付けられたすべての属性を送信します。
TGREP processing of the UPDATE message at the gateway is identical to UPDATE processing in TRIP [2]. A TGREP sender MUST support all mandatory TRIP attributes.
ゲートウェイでUPDATEメッセージのTGREP処理TRIP [2]の処理を更新することと同一です。 TGREPの送信者は、すべての必須TRIP属性をサポートしなければなりません。
KEEPALIVE messages are periodically exchanged over the peering session between the TGREP gateway and the TRIP LS as specified in Section 4.4 of TRIP [2].
TRIPのセクション4.4で指定されるようにキープアライブメッセージを定期的TGREPゲートウェイとTRIP LSとの間のピアリングセッションを介して交換される[2]。
The same procedures used with TRIP are used with TGREP for error handling and generating NOTIFICATION messages. The only difference is that a TGREP gateway will never generate a NOTIFICATION message in response to an UPDATE message, irrespective of the contents of the UPDATE message. Any UPDATE message is silently discarded.
TRIPで用いたのと同じ手順は、エラー処理及び生成NOTIFICATIONメッセージにTGREPと共に使用されます。唯一の違いは、TGREPゲートウェイに関係なくUPDATEメッセージの内容の、UPDATEメッセージに応答して通知メッセージを生成しないことです。どれUPDATEメッセージは静かに破棄されます。
When the TGREP finite state machine is in the Established state and an UPDATE message is received, the UPDATE message is silently discarded and the TGREP gateway remains in the Established state. Other than that, the TRIP finite state machine and the TGREP finite state machine are identical.
TGREP有限状態機械が設立された状態にあり、UPDATEメッセージを受信した場合、UPDATEメッセージは静かに捨てとTGREPゲートウェイが確立された状態に留まります。それ以外は、TRIP有限状態マシンとTGREP有限状態マシンは同じです。
A TGREP gateway may maintain simultaneous sessions with more than one TRIP LS. A TGREP gateway maintains one call routing database per peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out, and hence we will call them Adj-TRIBs-GW-Out. An Adj-TRIB-GW-Out contains the gateway's reachability information advertised to its peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is outside the scope of this document (possibly by manual configuration).
TGREPゲートウェイは、複数のTRIPのLSとの同時セッションを維持することができます。 TGREPゲートウェイは、ピアトリップLSあたりデータベースルーティングコールを1つ保持します。これらのデータベースは、TRIPの調整]-TRIBsアウトと同等であるので、我々は調整] - TRIBs-GWアウトそれらを呼び出します。調整] - TRIB-GWアウトは、そのピアTRIPのLSにアドバタイズゲートウェイの到達可能性情報が含まれています。方法のAdj-TRIB-GWアウトデータベースが移入されます（おそらく手動設定による）、この文書の範囲外です。
The TGREP gateway does not have databases equivalent to TRIP's Adj-TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn routes from its peer TRIP LSs, and hence it does not run call route selection.
TGREPゲートウェイがそのピアTRIPのLSからのルートを学習していないため、TGREPゲートウェイは、TRIPの調整]-TRIBs-InとのLoc-TRIBと同等のデータベースを持っていない、ので、それはコールルート選択を実行しません。
As mentioned above, TGREP supports various address families in order to convey the reachability of telephony destinations. A TGREP session MUST NOT send UPDATEs of more than one of the following categories (a) Prefix address families (E164, Pentadecimal, and Decimal), (b) TrunkGroup address family, or (c) Carrier address family for a given established session. TGREP should specify its choice address family through the route-type capability in the OPEN message. And route-type specification in the OPEN message violating the above rule should be rejected with a NOTIFICATION message.
前述したように、TGREPは、電話先の到達可能性を伝えるために、さまざまなアドレスファミリをサポートしています。 TGREPセッションは、次のカテゴリ（a）のプレフィックスアドレスファミリ（E164、十五進法、および10進数）、（b）はTrunkGroupアドレスファミリ、または特定の確立されたセッションのための（c）のキャリアアドレスファミリの複数の更新を送ってはいけません。 TGREPは、OPENメッセージ内のルート型機能を通じて選択アドレスファミリを指定する必要があります。そして、上記のルールに違反OPENメッセージでルート型仕様は、通知メッセージを拒否しなければなりません。
TRIP's route selection and aggregation operations MUST NOT be implemented by TGREP gateways.
TRIPのルート選択と集約操作がTGREPゲートウェイによって実装されてはなりません。
As mentioned earlier, TGREP can be considered as a protocol complimentary to TRIP in providing reachability information, which can then be further fed into the Location Server. The architecture of an LS/Proxy system is as follows: There exists a TRIP LS application that functions as a speaker in the I-TRIP/E-TRIP network as documented in TRIP [2]. This component is termed as "Egress LS" for the purposes of this discussion. Then, there is a signaling server fronting a set of gateways. In conjunction with this signaling server is also a second component operating in receive mode, which peers with one or more gateways, each of them using TGREP to advertise routing information. This component on the receiving end of one or more TGREP sessions is termed as the "Ingress LS" or "TGREP receiver" for the purposes of this discussion. Also, the entity (typically, a gateway) advertising the routes on the TGREP session is termed as the "TGREP sender". The TGREP receiver receiving the TRIP messages takes the resulting routing information from each gateway, and "exports" it to another process we define below, that performs consolidation and aggregation, in that order. These operations would take as input the collective set of routes from all the gateways. Subsequently, the resulting TRIB is passed as input into the LS-Egress process as shown below, that can then disseminate these via TRIP. The interface between the TGREP receiver (aka Ingress LS) peering with the GW(s) and the TRIP LS (Egress LS) is entirely a local matter.
前述したように、TGREPはその後さらにロケーションサーバに供給することができる到達可能性情報を提供することでトリップする相補プロトコル、と考えることができます。 I-TRIP / E-TRIPネットワークにおけるスピーカとして機能TRIPに記載されているようにTRIPのLSのアプリケーションが存在する[2]：LS /プロキシシステムのアーキテクチャは、以下の通りです。このコンポーネントは、この議論の目的のために「出力LS」と呼ばれます。その後、ゲートウェイのセットに面しシグナリング・サーバがあります。このシグナリングサーバと連携して、それらの各々は、ルーティング情報をアドバタイズするTGREPを使用して、1つまたは複数のゲートウェイとピア受信モードで動作する第2の構成要素でもあります。一つ以上のTGREPセッションの受信側で、このコンポーネントは、この議論の目的のための「進入LS」または「TGREP受信機」と呼ばれます。また、TGREPセッションにルートを広告するエンティティ（通常、ゲートウェイ）「TGREP送信者」と呼ばれています。 TRIPメッセージを受信TGREP受信機は、各ゲートウェイから得られたルーティング情報を取得し、我々はそのために、統合および集合を実行することを、以下に定義する他のプロセスを「エクスポート」を。これらの操作は、入力としてすべてのゲートウェイからのルートの集合的なセットを取るだろう。その後、得られたTRIBは次にTRIP介してこれらを広めることができ、以下に示すように、LS-出口プロセスへの入力として渡されます。 GW（複数可）及びTRIPのLS（出力LS）とピアリングTGREP受信機との間のインターフェース（別名進入LS）は、完全にローカルの問題です。
The nature of the consolidation and aggregation operations and the accompanying motivation are described in the subsections below. The order in which the operations are listed represents an implicit logical sequence in which they are applied. The architecture for an LS/Proxy entity is shown in Figure 6 below.
統合と集約操作の性質及び付随するモチベーションは、以下のサブセクションに記載されています。操作がリストされる順序は、それらが適用される暗黙的な論理配列を表します。 LS /プロキシエンティティのアーキテクチャは、以下の図6に示されています。
+-------------------------------------------------------+
| +-------------------------------+ |
| | +-+ +-+ | | TGREP
| | |A| |C| | | +-----+
| | |g| |o| | | | |
| +-------------+ | |g| |n| +-------------+ | | --| GW |
| | | | |r| |s| | | | | +-----+
| | TRIP | | |e| |o| | | | +---
| | LS <----------|g<--|l<--- TGREP |-++-| +-----+
| | | | |a| |i| | Session | | | | |
| | (I-TRIP/ | | |t| |d| | Management |-++-+----| GW |
| | E-TRIP) | | |i| |a| | | | | +-----+
| | (Egress LS) | | |o| |t| | |-+ +---
| +-----------/-+ | |n| |i| +-------------+ | | +-----+
| / | | | |o| | | --| |
| / | | | |n| (Ingress LS) | | | GW |
| / | +-+ +-+ | | +-----+
| / | TGREP Receiver | |
| / +-------------------------------+ |
| / |
| / |
+-------/-----------------------------------------------+
/ LS/Proxy
/
/
/
/
/
+/----------------+
| |
| |
| |
| LS |
| |
| |
| |
| |
| |
+-----------------+
Figure 6: LS Architecture for TRIP-GW
図6：TRIP-GW用LSアーキテクチャ
The TGREP receiver (Ingress LS) may receive routing information from one or more gateways. It is possible that multiple routes are available for the same destination. These different alternative routes may be received from the same gateway or from multiple gateways. It is RECOMMENDED that the set of gateway routes for each destination be consolidated, before presenting a candidate route, to the Egress LS entity. The motivation for this operation should be to define a route that can maximally represent the collective routing capabilities of the set of gateways, managed by this TGREP receiver. Let us take an example scenario in order to bring out the motivation for this operation. Let us say, the TGREP receiver maintains peering sessions with gateways A and B.
TGREP受信（入力LS）は、1つのまたは複数のゲートウェイからルーティング情報を受信することができます。複数のルートが同じ宛先のために利用可能であることも可能です。これらの異なる代替ルートが同じゲートウェイから、または複数のゲートウェイから受信することができます。各宛先のゲートウェイルートのセットが出力LSエンティティに、候補経路を提示する前に、統合されることが推奨されます。この操作のための動機は、最大限このTGREP受信機が管理するゲートウェイのセットの集合的なルーティング機能を表すことができる経路を定義することであるべきです。私たちは、この操作のためのモチベーションを引き出すために、シナリオ例を見てみましょう。私たちは言ってみましょう、TGREP受信機は、ゲートウェイAとBとのピアリングセッション維持
- Gateway A advertises a route for destination "SIP 408" on the E.164 address family with the Carrier attribute value C1.
- ゲートウェイAは、キャリア属性値C1とE.164アドレスファミリの目的地「SIP 408」のためのルートをアドバタイズします。
- Gateway B advertises a route for destination "SIP 408" on the E.164 address family with Carrier attribute value C2.
- ゲートウェイBは、キャリア属性値C2とE.164アドレスファミリの「SIP 408」目的地へのルートをアドバタイズ。
The TGREP receiver that receives these routes can consolidate these constituent routes into a single route for destination "SIP 408" with its Carrier attribute being a union of the Carrier attribute values of the individual routes, namely, "C1 C2". This operation is referred to as consolidation. In the above example, it is possible that a route to the destination "SIP 408" through one or more carriers may have been lost if the individual routes were not consolidated.
これらのルートは、そのキャリア属性はキャリアの組合された状態で「SIP 408」目的地のための単一の経路にこれらの構成のルートを統合することができる受信TGREP受信機は、個々の経路、すなわち、「C1 C2」の属性値。この操作は、連結と呼ばれています。上記の例では、個々のルートが統合されなかった場合は、1つのまたは複数のキャリアを介して目的地までの経路「SIP 408」が失われている可能性があります。
Another example is to consolidate the Prefix attribute from multiple Carrier or TrunkGroup updates received from different gateways for the same destination. Let us say, there are Carrier address family (AF) updates from two gateways for Carrier destination X, and the prefix attribute values are {408, 650} from one update and {919, 973} from the other. The prefix values from these two updates can be consolidated into a single Carrier AF route advertisement with prefix value {408, 650, 919, 973}.
別の例は、同じ宛先に対して異なるゲートウェイから受信した複数のキャリアやTrunkGroupアップデートからprefix属性を統合することです。私たちはそこにキャリア先Xのための2つのゲートウェイからのキャリアアドレスファミリ（AF）の更新があり、prefix属性の値が他の1回の更新と{919、973}から{408、650}されている、としましょう。これら2つの更新からプレフィックス値は、プレフィックス値{408、650、919、973}を有するシングルキャリアAFルート広告に統合することができます。
In general, there is a potential for loss of gateway routing information when TGREP routes from a set of gateways are not consolidated when a candidate route is presented to the TRIP LS. The specifics of applying the consolidation operation to different attributes and routes from different address families is left to the individual TGREP receiver implementations.
一般的に、候補経路がTRIP LSに提示されたときのゲートウェイのセットからTGREPルートが連結されていませんゲートウェイルーティング情報の損失の可能性があります。異なるアドレスファミリから異なる属性及びルートに統合化動作を適用することの詳細は、個々TGREP受信機の実装に任されています。
The set of gateway routes, which are in a consolidated form or otherwise, may be aggregated before importing it to the LS instance that is responsible for I-TRIP/E-TRIP processing (Egress LS). This operation follows the standard aggregation procedures described in TRIP [2], while adhering to the aggregation rules for each route attribute.
連結形またはさもなければいるゲートウェイルートのセットは、I-TRIP / E-TRIP処理（出力LS）の原因であるLSのインスタンスにインポートする前に集約することができます。各ルート属性の集計規則を守りながら、この動作は、TRIP [2]に記載の標準的な凝集手順に従います。
To highlight the difference between the two operations discussed above, "consolidation" combines multiple routes for the same route destination, whereas "aggregation" combines routes for different route destinations that qualify as candidates to be summarized resulting in route information reduction.
「凝集」候補経路情報の低減をもたらす要約されるように資格異なるルート先のルートを組み合わせに対し、上記説明した2つの動作の違いを強調するために、「連結」は、同じルート先の複数の経路を組み合わせ。
To take an example, if there are multiple gateways offering routes to an E.164 destination "408" but with possibly different attributes (e.g., Carrier), the LS/Proxy can combine these to form one route for "408" but representing the attribute information collectively. This process is consolidation.
E.164先「408」へのルートを提供する複数のゲートウェイがある場合は、例を取ることが、おそらく異なる属性（例えば、キャリア）と、LS /プロキシは、「408」のための1つの経路を形成するために、これらを組み合わせることが、表現することができます総称属性情報。このプロセスは統合です。
If, for example, the LS/Proxy receives routes for 4080, 4081, 4082, ... 4089 from amongst a set of gateways, it could aggregate these different candidate routes to have a summarized route destination "408" with each of the attributes computed using the aggregation procedures defined in TRIP.
例えば、LS /プロキシゲートウェイのセットの中から、4080、4081、4082、... 4089のルートを受信した場合、その属性のそれぞれに要約ルート先を有するように「408」を、これらの異なる候補経路を集約することができTRIPで定義された集約手順を使用して計算しました。
The security considerations for TGREP are identical to that identified in TRIP [2] and are just restated here for the purposes of clarity.
TGREPのためのセキュリティの考慮事項は、[2] TRIPで特定されたものと同一であり、単に明確化の目的のためにここに修正再表示されます。
The security mechanism for the peering session between TGREP GW and a TRIP LS, in an IP network, is IPsec [3]. IPsec uses two protocols to provide traffic security: Authentication Header (AH) [6] and Encapsulating Security Payload (ESP) [7].
TGREP GWとTRIP LSとの間のピアリング・セッションのセキュリティメカニズムは、IPネットワークでは、IPsecのである[3]。認証ヘッダー（AH）[6]とカプセル化セキュリティペイロード（ESP）[7]：IPsecはトラフィックセキュリティを提供するために、2つのプロトコルを使用しています。
The AH header affords data origin authentication, connectionless integrity, and optional anti-replay protection of messages passed between the peer LSs. The ESP header provides origin authentication, connectionless integrity, anti-replay protection, and confidentiality of messages.
AHヘッダは、データ発信元認証、コネクションレス完全性、およびピアのLSの間で渡されるメッセージのオプションのアンチリプレイ保護を与えます。 ESPヘッダは、発信元認証、コネクションレス完全性、抗再生保護、およびメッセージの機密性を提供します。
Implementations of the protocol defined in this document employing the ESP header SHALL comply with Section 3.1.1 of [10], which defines a minimum set of algorithms for integrity checking and encryption. Similarly, implementations employing the AH header SHALL comply with Section 3.2 of [10], which defines a minimum set of algorithms for integrity checking.
ESPヘッダを使用する本文書で定義されたプロトコルの実装は、完全性チェックと暗号化のためのアルゴリズムの最小セットを定義する[10]のセクション3.1.1に適合しなければなりません。同様に、AHヘッダを用いる実装は、整合性チェックのためのアルゴリズムの最小セットを定義する[10]のセクション3.2に従わなければなりません。
Implementations SHOULD use the Internet Key Exchange Protocol (IKEv2) [9] to permit more robust keying options. Implementations employing IKEv2 SHOULD support 3DES-CBC for confidentiality and HMAC-SHA1 for integrity.
実装は、[9]より堅牢なキーイングオプションを可能にするために、インターネット鍵交換プロトコル（IKEv2の）を使用する必要があります。 IKEv2のを採用した実装は、整合性のために機密性のための3DES-CBCとHMAC-SHA1をサポートする必要があります。
A Security Association (SA) [3] is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH or ESP, but not both. Two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between two hosts, and is appropriate for protecting the TRIP session between two peer LSs.
セキュリティアソシエーション（SA）が[3]、それによって運ばれるトラフィックにセキュリティサービスを提供シンプレックス「接続」です。セキュリティサービスは、両方ではなく、AHまたはESPの使用により、SAに与えています。 SAの二つのタイプが定義されている：トランスポートモードとトンネルモード。トランスポートモードSAは、2つのホスト間のセキュリティアソシエーションであり、2つのピア間のLS TRIPセッションを保護するために適切です。
Both TRIP [2] and TGREP share the same IANA registry for Capabilities, Attributes, Address Families, and Application Protocols. IANA has added the following attribute codes and address family codes to the TRIP [2] registries.
TRIP [2]及びTGREP両方が機能、属性、アドレスファミリ、およびアプリケーションプロトコルの同じIANAレジストリを共有します。 IANAはTRIP [2]レジストリに以下の属性コードとアドレスファミリのコードを追加しました。
The Attribute Type Codes assigned for the new attributes defined in this document are listed below:
この文書で定義された新しい属性に割り当てられた属性タイプのコードは次のとおりです。
Code Attribute Reference
---- --------- ---------
13 TotalCircuitCapacity [RFC5140]
14 AvailableCircuits [RFC5140]
15 CallSuccess [RFC5140]
16 E.164 Prefix [RFC5140]
17 Pentadecimal Routing Number Prefix [RFC5140]
18 Decimal Routing Number Prefix [RFC5140]
19 TrunkGroup [RFC5140]
20 Carrier [RFC5140]
The following subsections show the codes that have been assigned for the two new address families introduced in this document.
以下のサブセクションでは、この文書に導入された2つの新しいアドレスファミリのために割り当てられているコードを示しています。
Code Address Family Reference
---- -------------- ---------
4 TrunkGroup [RFC5140]
Code Address Family Reference
---- -------------- ---------
5 Carrier [RFC5140]
We wish to thank Vijay Gurbani, Li Li, Kevin McDermott, David Oran, Bob Penfield, Jon Peterson, Anirudh Sahoo, and James Yu for their insightful comments and suggestions.
私たちは、彼らの洞察に満ちたコメントと提案のためのビジェイGurbani、李、ケビン・マクダーモット、デビッド・オラン、ボブペンフィールド、ジョン・ピーターソン、Anirudh Sahoo、そしてジェームズ・ゆうに感謝したいです。
[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., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
[2]ローゼンバーグ、J.、サラマ、H.、およびM.スクワイア、 "オーバーIPテレフォニールーティング（TRIP）"、RFC 3219、2002年1月。
[3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[3]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[4] Gurbani, V. and C. Jennings, "Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, June 2007.
[4] Gurbani、V.およびC.ジェニングスを、 "TELでトランクグループを表す/ Uniform Resource Identifier（URI）をすする"、RFC 4904、2007年6月。
[5] Yu, J., "Number Portability Parameters for the "tel" URI", RFC 4694, October 2006.
[5]ゆう、J.、TEL "URI "" の番号ポータビリティパラメータ"、RFC 4694、2006年10月。
[6] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[6]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[7]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[8] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
。、STD 68、RFC 5234、2008年1月：[8]クロッカー、D.、エド、およびP. Overell、 "ABNF構文仕様のためのBNFを拡張"。
[9] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[9]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[10] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[10] Manral、V.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[11] 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.
[11]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[12] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000.
[12]ローゼンバーグ、J.、およびH. Schulzrinneと、 "IP上テレフォニールーティングの枠組み"、RFC 2871、2000年6月。
[13] ITU-T List of ITU Carrier Codes (published periodically in the ITU-T Operational Bulletin).
ITUキャリアコード（ITU-T動作公報に定期的に発行）の[13] ITU-Tリスト。
[14] Rosenberg, J., "Requirements for Gateway Registration", Work in Progress, November 2001.
[14]ローゼンバーグ、J.、 "ゲートウェイの登録のための要件"、進歩、2001年11月の作品。
Authors' Addresses
著者のアドレス
Manjunath S. Bangalore Cisco Mail Stop SJC-14/2/1 3625 Cisco Way San Jose, CA 95134 Phone: +1-408-525-7555 EMail: manjax@cisco.com
Manjunath S.バンガロールのCiscoメールストップSJC-14/2月1日3625シスコウェイサンノゼ、CA 95134電話：+ 1-408-525-7555 Eメール：manjax@cisco.com
Rajneesh Kumar Cisco Mail Stop SJC-14/4/2 3625 Cisco Way San Jose, CA 95134 Phone: +1-408-527-6148 EMail: rajneesh@cisco.com
ラジニーシ・クマールのCiscoメールストップSJC-14/4月2日3625シスコウェイサンノゼ、CA 95134電話：+ 1-408-527-6148 Eメール：rajneesh@cisco.com
Jonathan Rosenberg Cisco Edison, NJ 08837 EMail: jdrosen@cisco.com
ジョナサン・ローゼンバーグシスコエジソン、NJ 08837 Eメール：jdrosen@cisco.com
Hussein F. Salama Citex Software Giza, Egypt EMail: hsalama@citexsoftware.com
フセインF.サラマCitexソフトウェアギザ、エジプトEメール：hsalama@citexsoftware.com
Dhaval Niranjan Shah Moowee Inc. 4920 El Camino Real Los Altos, CA 94022 Phone: +1-408-307-7455 EMail: dhaval@moowee.tv
DhavalシャーNiranjan Moowee株式会社4920エル・カミノレアルロスアルトス、CA 94022電話：+ 1-408-307-7455 Eメール：dhaval@moowee.tv
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。