Network Working Group J. Rosenberg
Request for Comments: 2871 dynamicsoft
Category: Informational H. Schulzrinne
Columbia University
June 2000
A Framework for Telephony Routing over IP
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The document defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony.
この文書では、プロバイダ間ルーティングテーブルIPテレフォニーゲートウェイの発見及び交換をサポートオーバーIPテレフォニールーティング（TRIP）のためのフレームワークとして働きます。文書は、電話ルーティング交換の問題を定義し、プロトコルの必要性に動機を与えます。それは、TRIPのためのアーキテクチャフレームワークを提示した用語を定義して、さまざまなプロトコル要素とそれらの機能を指定し、プロトコルによって提供されるサービスを概観し、それがインターネット電話のより広い文脈にどのように適合するかについて説明します。
Table of Contents
目次
1 Introduction ........................................ 2
2 Terminology ......................................... 2
3 Motivation and Problem Definition ................... 4
4 Related Problems .................................... 6
5 Relationship with BGP ............................... 7
6 Example Applications of TRIP ........................ 8
6.1 Clearinghouses ...................................... 8
6.2 Confederations ...................................... 9
6.3 Gateway Wholesalers ................................. 9
7 Architecture ........................................ 11
8 Elements ............................................ 12
8.1 IT Administrative Domain ............................ 12
8.2 Gateway ............................................. 13
8.3 End Users ........................................... 14
8.4 Location Server ..................................... 14
9 Element Interactions ................................ 16
9.1 Gateways and Location Servers ....................... 16
9.2 Location Server to Location Server .................. 16
9.2.1 Nature of Exchanged Information ..................... 17
9.2.2 Quality of Service .................................. 18
9.2.3 Cost Information .................................... 19
10 The Front End ....................................... 19
10.1 Front End Customers ................................. 19
10.2 Front End Protocols ................................. 20
11 Number Translations ................................. 21
12 Security Considerations ............................. 22
13 Acknowledgments ..................................... 23
14 Bibliography ........................................ 23
15 Authors' Addresses .................................. 24
16 Full Copyright Statement ............................ 25
1 Introduction
1はじめに
This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The document defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony.
この文書では、プロバイダ間ルーティングテーブルIPテレフォニーゲートウェイの発見及び交換をサポートオーバーIPテレフォニールーティング（TRIP）のためのフレームワークとして働きます。文書は、電話ルーティング交換の問題を定義し、プロトコルの必要性に動機を与えます。それは、TRIPのためのアーキテクチャフレームワークを提示した用語を定義して、さまざまなプロトコル要素とそれらの機能を指定し、プロトコルによって提供されるサービスを概観し、それがインターネット電話のより広い文脈にどのように適合するかについて説明します。
2 Terminology
2用語
We define the following terms. Note that there are other definitions for these terms, outside of the context of gateway location. Our definitions aren't general, but refer to the specific meaning here:
私たちは、次の用語を定義します。ゲートウェイの場所のコンテキストの外でこれらの用語の他の定義が存在することに留意されたいです。私たちの定義は一般的ではありませんが、ここでは特定の意味を参照してください。
Gateway: A device with some sort of circuit switched network connectivity and IP connectivity, capable of initiating and terminating IP telephony signaling protocols, and capable of initiating and terminating telephone network signaling protocols.
ゲートウェイは：回路のいくつかの並べ替えを持つデバイスがネットワーク接続とIP接続、IP電話シグナリングプロトコルを開始し、終了することができる、及びシグナリングプロトコル電話網を開始し、終了することが可能な切り替え。
End User: The end user is usually (but not necessarily) a human being, and is the party who is the ultimate initiator or recipient of calls.
エンドユーザーは：エンドユーザーは、（必ずしも必要ではないが）通常は人間である、そして究極のイニシエータまたは通話の受信者である当事者です。
Calling Device: The calling device is a physical entity which has IP connectivity. It is under the direction of an end user who wishes to place a call. The end user may or may not be directly controlling the calling device. If the calling device is a PC, the end user is directly controlling it. If, however, the calling device is a telephony gateway, the end user may be accessing it through a telephone.
デバイスの呼び出し：呼び出し側のデバイスは、IP接続を持っている物理的なエンティティです。これは、電話を置きたいと思って、エンドユーザの指示の下です。エンドユーザは直接呼び出し制御装置であってもなくてもよいです。発信側デバイスがPCであれば、エンドユーザーはそれを直接制御しています。しかし、発信側デバイスは、テレフォニーゲートウェイである場合、エンドユーザーは、電話からアクセスすることができます。
Gatekeeper: The H.323 gatekeeper element, defined in [1].
ゲートキーパー：H.323ゲートキーパー要素、[1]で定義されます。
SIP Server: The Session Initiation Protocol proxy or redirect server defined in [2].
SIPサーバー：セッション開始プロトコルのプロキシまたはリダイレクトサーバはで定義された[2]。
Call Agent: The MGCP call agent, defined in [3].
MGCPコールエージェント、[3]で定義されます。エージェントを呼び出します。
GSTN: The Global Switched Telephone Network, which is the worldwide circuit switched network.
GSTN：グローバルは世界中の回路交換ネットワークである電話網、交換しました。
Signaling Server: A signaling server is an entity which is capable of receiving and sending signaling messages for some IP telephony signaling protocol, such as H.323 or SIP. Generally speaking, a signaling server is a gatekeeper, SIP server, or call agent.
サーバシグナリング：シグナリング・サーバが受信し、そのようなH.323またはSIPのようないくつかのIP電話シグナリングプロトコルのシグナリングメッセージを送信することが可能なエンティティです。一般的に言って、シグナリング・サーバは、ゲートキーパー、SIPサーバ、またはコールエージェントです。
Location Server (LS): A logical entity with IP connectivity which has knowledge of gateways that can be used to terminate calls towards the GSTN. The LS is the main entity that participates in Telephony Routing over IP. The LS is generally a point of contact for end users for completing calls to the telephony network. An LS may also be responsible for propagation of gateway information to other LS's. An LS may be coresident with an H.323 gatekeeper or SIP server, but this is not required.
ロケーションサーバ（LS）：GSTNへの通話を終了することができるゲートウェイの知識を持っているIP接続されている論理エンティティ。 LSは、IPテレフォニー上のルーティングに参加する主なエンティティです。 LSは、一般電話網への呼び出しを完了するため、エンドユーザーのための接点です。 LSは、他のLSのへのゲートウェイ情報の伝播を担当することがあります。 LSは、H.323ゲートキーパーまたはSIPサーバと共存することができるが、これは必須ではありません。
Internet Telephony Administrative Domain (ITAD): The set of resources (gateways and Location Servers) under the control of a single administrative authority. End users are customers of an ITAD.
インターネット電話管理ドメイン（ITAD）：単一の管理権限の制御下にあるリソース（ゲートウェイとロケーションサーバ）のセット。エンドユーザーは、ITADの顧客です。
Provider: The administrator of an ITAD.
プロバイダ：ITADの管理者。
Location Server Policy: The set of rules which dictate how a location server processes information it sends and receives via TRIP. This includes rules for aggregating, propagating, generating, and accepting information.
ロケーションサーバのポリシー：ロケーションサーバが、それはTRIPを経由して送信し、受信した情報をどのように処理するかを指示する一連の規則。これは、凝集伝播、生成、及び情報を受け入れるための規則を含みます。
End User Policy: Preferences that an end user has about how a call towards the GSTN should be routed.
エンドユーザー・ポリシー：設定エンドユーザはGSTNへのコールがルーティングされるべきかについて持っています。
Peers: Two LS's are peers when they have a persistent association between them over which gateway information is exchanged.
ピア：二つのLSの彼らは、ゲートウェイ情報が交換された上で、それらの間の永続的な関連を持っているとき、ピアです。
Internal peers: Peers that both reside within the same ITAD.
内部ピア：両方が同じITAD内に存在することをピア。
External peers: Peers that reside within different ITADs.
外部ピア：異なるITADs内に存在するピア。
Originating Location Server: A Location Server which first generates a route to a gateway in its ITAD.
発信ロケーションサーバ：最初にITAD内のゲートウェイへのルートを生成するロケーションサーバ。
Telephony Routing Information Base (TRIB): The database of gateways an LS builds up as a result of participation in TRIP.
電話ルーティング情報ベース（TRIB）：ゲートウェイのデータベースLSは、TRIPの参加の結果として蓄積します。
3 Motivation and Problem Definition
3動機と問題定義
As IP telephony gateways grow in terms of numbers and usage, managing their operation will become increasingly complex. One of the difficult tasks is that of gateway location, also known as gateway selection, path selection, gateway discovery, and gateway routing. The problem occurs when a calling device (such as a telephony gateway or a PC with IP telephony software) on an IP network needs to complete a call to a phone number that represents a terminal on a circuit switched telephone network. Since the intended target of the call resides in a circuit switched network, and the caller is initiating the call from an IP host, a telephony gateway must be used. The gateway functions as a conversion point for media and signaling, converting between the protocols used on the IP network, and those used in the circuit switched network.
IPテレフォニーゲートウェイが番号と使用量の面で成長するにつれ、彼らの動作を管理することはますます複雑になります。困難なタスクの1つは、ゲートウェイの選択、経路選択、ゲートウェイ発見、およびゲートウェイルーティングとして知られているゲートウェイの位置のことです。 IPネットワーク上の（例えば、テレフォニーゲートウェイまたはIPテレフォニーソフトウェアを使用してPCなど）を呼び出すデバイスは、回路交換電話網上の端末を表し、電話番号にコールを完了する必要があるときに問題が発生します。呼の意図された標的は、回路内に存在するので、ネットワークを切り替え、そして発呼者がIPホストからのコールを開始し、電話ゲートウェイを使用しなければなりません。 IPネットワーク上で使用されるプロトコル、および回路交換ネットワークで使用されるものとの間で変換するメディアおよびシグナリングのための変換点としてゲートウェイ機能、。
The gateway is, in essence, a relaying point for an application layer signaling protocol. There may be many gateways which could possibly complete the call from the calling device on the IP network to the called party on the circuit switched network. Choosing such a gateway is a non-trivial process. It is complicated because of the following issues:
ゲートウェイは、本質的に、アプリケーション層シグナリングプロトコルのための中継点です。おそらく回路上のIPネットワーク上の発呼デバイスからの着信側の呼び出しはネットワークを切り替え完了ができ、多くのゲートウェイがあるかもしれません。そのようなゲートウェイを選択すると、非自明なプロセスです。それは次の理由問題の複雑です。
Number of Candidate Gateways: It is anticipated that as IP telephony becomes widely deployed, the number of telephony gateways connecting the Internet to the GSTN will become large. Attachment to the GSTN means that the gateway will have connectivity to the nearly one billion terminals reachable on this network. This means that every gateway could theoretically complete a call to any terminal on the GSTN. As such, the number of candidate gateways for completing a call may be very large.
候補ゲートウェイの数：IPテレフォニーが広く展開になると、GSTNにインターネットを接続するテレフォニーゲートウェイの数が大きくなることが予想されます。 GSTNへの添付ファイルは、ゲートウェイは、このネットワーク上で到達可能なほぼ10億の端末への接続を持っていることを意味します。これは、すべてのゲートウェイは、理論的にGSTN上の任意の端末への呼び出しを完了できることを意味します。そのため、コールを完了するための候補ゲートウェイの数が非常に大きくなることがあります。
Business Relationships: In reality, the owner of a gateway is unlikely to make the gateway available to any user who wishes to connect to it. The gateway provides a useful service, and incurs cost when completing calls towards the circuit switched network. As a result, providers of gateways will, in many cases, wish to charge for use of these gateways. This may restrict usage of the gateway to those users who have, in some fashion, an established relationship with the gateway provider.
ビジネス関係：現実には、ゲートウェイの所有者がそれに接続することを希望するすべてのユーザーへのゲートウェイを利用できるようにすることはほとんどありません。ゲートウェイは、有用なサービスを提供し、回路に向かって完成コールがネットワークを切り替える際にコストを招きます。その結果、ゲートウェイのプロバイダは、多くの場合、これらのゲートウェイの使用に対して課金を希望します。これは、いくつかの方法で、ゲートウェイプロバイダと確立された関係を持っているユーザーへのゲートウェイの使用を制限することができます。
Provider Policy: In all likelihood, an end user who wishes to make use of a gateway service will not compensate the gateway provider directly. The end user may have a relationship with an IP telephony service provider which acts as an intermediary to providers of gateways. The IP telephony service provider may have gateways of its own as well. In this case, the IP telephony service provider may have policies regarding the usage of various gateways from other providers by its customers. These policies must figure into the selection process.
プロバイダポリシー：すべての可能性では、ゲートウェイサービスを利用したいエンドユーザーが直接ゲートウェイプロバイダを補償しません。エンドユーザーは、ゲートウェイの提供者に仲介するIPテレフォニーサービスプロバイダーとの関係を有することができます。 IPテレフォニーサービスプロバイダーは、同様に、独自のゲートウェイを有することができます。この場合、IP電話サービスプロバイダは、その顧客が他のプロバイダーからの各種ゲートウェイの使用に関するポリシーを持っていることがあります。これらのポリシーは、選択プロセスに把握しなければなりません。
End User Policy: In some cases, the end user may have specific requirements regarding the gateway selection. The end user may need a specific feature, or have a preference for a certain provider. These need to be taken into account as well.
エンドユーザー・ポリシー：いくつかのケースでは、エンドユーザーは、ゲートウェイ選択に関する特定の要件を有することができます。エンドユーザは、特定の機能を必要とする、または特定のプロバイダの優先度を有していてもよいです。これらは、同様に考慮する必要があります。
Capacity: All gateways are not created equal. Some are large, capable of supporting hundreds or even thousands of simultaneous calls. Others, such as residential gateways, may only support one or two calls. The process for selecting gateways should allow gateway capacity to play a role. It is particularly desirable to support some form of load balancing across gateways based on their capacities.
容量：すべてのゲートウェイが同じように作成されていません。いくつかは、同時通話の数百あるいは数千をサポートできる大きさです。このようレジデンシャルゲートウェイのような他のものは、1つのまたは2つのコールをサポートすることができます。ゲートウェイを選択するためのプロセスは、ゲートウェイ容量が役割を担うことができるようにすべきです。彼らの能力に基づいて、ゲートウェイ間でのロードバランシングのいくつかのフォームをサポートすることが特に望ましいです。
Protocol and Feature Compatibilities: The calling party may be using a specific signaling or media protocol that is not supported by all gateways.
プロトコルおよび機能の互換性：発呼者はすべてのゲートウェイでサポートされていない特定のシグナリングまたはメディアのプロトコルを使用しても良いです。
From these issues, it becomes evident that the selection of a gateway is driven in large part by the policies of various parties, and by the relationships established between these parties. As such, there cannot be a global "directory of gateways" in which users look up phone numbers. Rather, information on availability of gateways must be exchanged by providers, and subject to policy, made available locally and then propagated to other providers. This would allow each provider to build up its own local database of available gateways - such a database being very different for each provider depending on policy.
これらの問題から、ゲートウェイの選択は、様々な関係者の政策によって大部分が駆動され、これらの当事者の間で確立された関係でされることが明らかになりました。そのため、ユーザーが電話番号を検索するグローバルな「ゲートウェイのディレクトリ」そこにすることはできません。むしろ、ゲートウェイの利用可能性に関する情報は、プロバイダによって交換、およびポリシーの対象、ローカルで利用できるようにして、他のプロバイダに伝播する必要があります。これは、各プロバイダが利用できるゲートウェイの独自のローカルデータベースを構築することができるようになる - このようなデータベースは、ポリシーに応じて、各プロバイダのために非常に異なっています。
From this, we can conclude that a protocol is needed between administrative domains for exchange of gateway routing information. The protocol that provides these functions is Telephony Routing over IP (TRIP). TRIP provides a specific set of functions:
このことから、我々は、プロトコルがゲートウェイルーティング情報の交換のために管理ドメインの間に必要であると結論付けることができます。これらの機能を提供するプロトコルは、IP（TRIP）上テレフォニールーティングです。 TRIPは、機能の特定のセットを提供します。
o Establishment and maintenance of peering relationships between providers;
O確立とプロバイダ間のピアリング関係の維持。
o Exchange and synchronization of telephony gateway routing information between providers;
O Exchangeとプロバイダとの間のルーティング情報を電話ゲートウェイの同期。
o Prevention of stable routing loops for IP telephony signaling protocols;
シグナリングプロトコルIPテレフォニーのための安定したルーティングループのO予防;
o Propagation of learned gateway routing information to other providers in a timely and scalable fashion;
O学んゲートウェイの伝播は、タイムリーかつスケーラブルな方法で他のプロバイダに情報をルーティングします。
o Definition of the syntax and semantics of the data which describe telephony gateway routes.
テレフォニーゲートウェイのルートを記述したデータの構文と意味のO定義。
TRIP can be generally summarized as an inter-domain IP telephony gateway routing protocol.
TRIPは、一般的にドメイン間のIPテレフォニーゲートウェイルーティングプロトコルのように要約することができます。
4 Related Problems
4つのに関連する問題
At a high level, the problem TRIP solves appears to be a mapping problem: given an input telephone number, determine, based on some criteria, the address of a telephony gateway. For this reason, the gateway location problem is often called a "phone number to IP address translation problem". This is an over-simplification, however. There are at least three separate problems, all of which can be classified as a "phone number to IP address translation problem", and only one of which is addressed by TRIP:
入力された電話番号が与えられると、決定、いくつかの基準に基づいて、電話ゲートウェイのアドレス：ハイレベルで、問題トリップ解くは、マッピングの問題であると思われます。このため、ゲートウェイの場所の問題は、多くの場合、「IPアドレス変換問題への電話番号」と呼ばれています。しかし、これは、過剰に単純化です。 「IPアドレス変換問題への電話番号」として分類することができ、かつ一つのみのがTRIPによって対処されるすべては、少なくとも3つの別々の問題が、あります。
o Given a phone number that corresponds to a terminal on a circuit switched network, determine the IP address of a gateway capable of completing a call to that phone number.
O回路上の端子に対応する電話番号が、ネットワークを切り替え、その電話番号へのコールを完了することができるゲートウェイのIPアドレスを決定考えます。
o Given a phone number that corresponds to a specific host on the Internet (this host may have a phone number in order to facilitate calls to it from the circuit switched network), determine the IP address of this host.
Oインターネット上の特定のホストに対応する電話番号を指定すると、（このホストは回路交換ネットワークからの呼び出しを容易にするために電話番号を有していてもよい）、このホストのIPアドレスを決定します。
o Given a phone number that corresponds to a user of a terminal on a circuit switched network, determine the IP address of an IP terminal which is owned by the same user.
O回路上の端末のユーザに対応する電話番号を、ネットワークを切り替え、同じユーザによって所有されているIP端末のIPアドレスを決定考えます。
The last of these three mapping functions is useful for services where the PC serves as an interface for the phone. One such service is the delivery of an instant message to a PC when the user's phone rings. To deliver this service, a switch in the GSTN is routing a call towards a phone number. It wishes to send an Instant Message to the PC for this user. This switch must somehow have access to the IP network, in order to determine the IP address of the PC corresponding to the user with the given phone number. The mapping function is a name to address translation problem, where the name happens to be represented by a string of digits. Such a translation function is best supported by directory protocols. This problem is not addressed by TRIP.
これら三つのマッピング関数の最後には、PCが電話のためのインターフェースとして機能するサービスのために有用です。このようなサービスの1つは、PCユーザーの電話が鳴ると、インスタントメッセージの配信です。このサービスを提供するために、GSTNのスイッチは電話番号へのコールをルーティングしています。これは、このユーザーのPCにインスタントメッセージを送信したいです。このスイッチは、何らかの形で与えられた電話番号を持つユーザーに対応したPCのIPアドレスを決定するために、IPネットワークへのアクセスを持っている必要があります。マッピング機能は、名前が数字の文字列で表されることを起こる翻訳の問題に対処するための名前です。このような翻訳機能は、最高のディレクトリ・プロトコルによってサポートされています。この問題は、TRIPによって対処されていません。
The second of these mappings is needed to facilitate calls from traditional phones to IP terminals. When a user on the GSTN wishes to call a user with a terminal on the IP network, they need to dial a number identifying that terminal. This number could be an IP address. However, IP addresses are often ephemeral, assigned on demand by DHCP [4] or by dialup network access servers using PPP [5]. The number could be a hostname, obtained through some translation of groups of numbers to letters. However, this is cumbersome. It has been proposed instead to assign phone numbers to IP telephony terminals. A caller on the GSTN would then dial this number as they would any other. This number serves as an alternate name for the IP terminal, in much the same way its hostname serves as a name. A switch in the GSTN must then access the IP network, and obtain the mapping from this number to an IP address for the PC. Like the previous case, this problem is a name to address translation problem, and is best handled by a directory protocol. It is not addressed by TRIP.
これらのマッピングの第二は、IP端末への伝統的な電話からの通話を促進するために必要とされています。 GSTN上のユーザは、IPネットワーク上の端末を持つユーザーを呼び出すしたい場合、彼らはその端末を識別する番号をダイヤルする必要があります。この番号は、IPアドレスである可能性があります。しかし、IPアドレスは、[5] [4]またはPPPを使用してダイヤルアップネットワークアクセスサーバーによって、しばしば短命あるDHCPによってオンデマンドで割り当てられます。数は、文字の数字のグループのいくつかの翻訳を経て得られたホスト名である可能性があります。しかし、これは面倒です。 IPテレフォニー端末に電話番号を割り当てる代わりに、提案されています。彼らは、他の同じようGSTN上の呼び出し側は、この番号をダイヤルします。この番号は、そのホスト名が名前として機能ほぼ同じ方法で、IP端末の代替名として働きます。 GSTN内のスイッチは、IPネットワークにアクセスし、PCのIPアドレスにこの番号からマッピングを取得する必要があります。前のケースと同様に、この問題は、翻訳の問題に対処するための名前であり、そして最高のディレクトリプロトコルによって処理されます。それはTRIPによって対処されていません。
The first mapping function, however, is fundamentally an address to route translation problem. It is this problem which is considered by TRIP. As discussed in Section 3, this mapping depends on local factors such as policies and provider relationships. As a result, the database of available gateways is substantially different for each provider, and needs to be built up through specific inter-provider relationships. It is for this reason that a directory protocol is not appropriate for TRIP, whereas it is appropriate for the others.
最初のマッピング機能は、しかし、基本的にルートの翻訳の問題へのアドレスです。それはTRIPによって検討され、この問題です。第3節で説明したように、このマッピングは、ポリシープロバイダとの関係のような局所因子に依存します。結果として、利用可能なゲートウェイのデータベースには、各プロバイダのために、実質的に異なり、特定の間のプロバイダとの関係を通じて構築される必要があります。それは他人のために適切であるのに対し、ディレクトリプロトコルは、TRIPのために適切ではありません。この理由のためです。
5 Relationship with BGP
BGPと5の関係
TRIP can be classified as a close cousin of inter-domain IP routing protocols, such as BGP [6]. However, there are important differences between BGP and TRIP:
TRIPは、BGPなどのドメイン間のIPルーティングプロトコル、の近いいとことして分類することができる[6]。しかし、BGPおよびTRIPの間には重要な違いがあります。
o TRIP runs at the application layer, not the network layer, where BGP resides.
O TRIPは、BGPが常駐アプリケーション層ではなく、ネットワーク層で動作します。
o TRIP runs between servers which may be separated by many intermediate networks and IP service providers. BGP runs between routers that are usually adjacent.
OのTRIPは、多くの中間のネットワークとIPサービスプロバイダーによって分離することができるサーバ間で実行されます。 BGPは通常、隣接しているルータ間で実行されます。
o The information exchanged between TRIP peers describes routes to application layer devices, not IP routers, as is done with BGP.
BGPを用いて行われているようにO TRIPピア間で交換される情報は、アプリケーション層デバイスではなく、IPルータへのルートを記述する。
o TRIP assumes the existence of an underlying IP transport network. This means that servers which exchange TRIP routing information need not act as forwarders of signaling messages that are routed based on this information. This is not true in BGP, where the peers must also act as forwarding points (or name an adjacent forwarding hop) for IP packets.
O TRIPは、基礎となるIPトランスポートネットワークの存在を前提としています。これは、TRIPルーティング情報を交換サーバは、この情報に基づいてルーティングされるシグナリングメッセージのフォワーダとして機能する必要がないことを意味します。これは、ピアはまた、IPパケットの転送ポイントとして作用する（または隣接中継ホップに名前を付ける）必要がありBGPに当てはまりません。
o The purpose of TRIP is not to establish global connectivity across all ITADs. It is perfectly reasonable for there to be many small islands of TRIP connectivity. Each island represents a closed set of administrative relationships. Furthermore, each island can still have complete connectivity to the entire GSTN. This is in sharp contrast to BGP, where the goal is complete connectivity across the Internet. If a set of AS's are isolated from some other set because of a BGP disconnect, no IP network connectivity exists between them.
O TRIPの目的は、すべてのITADs全体でグローバルな接続を確立することではありません。 TRIP接続の多くの小さな島々があることは完全に合理的です。各島は行政関係の閉集合を表します。さらに、各島にはまだ全体のGSTNへの完全な接続性を持つことができます。これは、目標は、インターネットを介して、完全な接続性であるBGP、と対照的です。 ASのセットが原因でBGP切断のいくつかの他のセットから隔離されている場合は、IPネットワークの接続は、それらの間に存在しません。
o Gateway routes are far more complex than IP routes (since they reside at the application, not the network layer), with many more parameters which may describe them.
Oゲートウェイルートは、それらを記述することができるより多くのパラメータを使用して、はるかに複雑なIPルーティング（それらはアプリケーションではなく、ネットワーク層に存在するので）以上です。
o BGP exchanges prefixes which represent a portion of the IP name space. TRIP exchanges phone number ranges, representing a portion of the GSTN numbering space. The organization and hierarchies in these two namespaces are different.
O BGPは、IP名前空間の一部を表す接頭辞を交換します。 TRIP交換電話番号がGSTN番号空間の一部を表す、の範囲です。これら2つの名前空間内の組織や階層が異なっています。
These differences means that TRIP borrows many of the concepts from BGP, but that it is still a different protocol with its own specific set of functions.
これらの違いは、TRIPは、BGPからの概念の多くを借用していること、それはまだ機能の独自の特定のセットと異なるプロトコルであることを意味しています。
6 Example Applications of TRIP
TRIPの6つのサンプルアプリケーション
TRIP is a general purpose tool for exchanging IP telephony routes between providers. TRIP does not, in any way, dictate the structure or nature of the relationships between those providers. As a result, TRIP has applications for a number of common cases for IP telephony.
TRIPは、プロバイダ間でIPテレフォニールートを交換するための汎用ツールです。 TRIPは、どのような方法で、これらのプロバイダ間の関係の構造または性質を規定していません。その結果、TRIPは、IPテレフォニーのための一般的な例数のアプリケーションを持っています。
A clearinghouse is a provider that serves as an exchange point between a number of other providers, called the members of the clearinghouse. Each member signs on with the clearinghouse. As part of the agreement, the member makes their gateways available to the other members of the clearinghouse. In exchange, the members have access to the gateways owned by the other members of the clearinghouse. When a gateway belonging to one member makes a call, the clearinghouse plays a key role in determining which member terminates the call.
クリアリングハウスは、クリアリングハウスのメンバーと呼ばれる他のプロバイダの数、の間の交換点となるプロバイダです。各メンバーは、クリアリングハウスでの署名します。契約の一環として、メンバーは、クリアリングハウスの他のメンバーへのゲートウェイが使用可能になります。為替では、メンバーは、クリアリングハウスの他のメンバーが所有するゲートウェイへのアクセス権を持っています。一方の部材に属するゲートウェイが呼び出しを行うと、クリアリングハウスは、通話を終了するメンバーを決定する上で重要な役割を果たしています。
TRIP can be applied here as the tool for exchanging routes between the members and the clearinghouse. This is shown in Figure 1.
TRIPメンバーと交換所との間のルートを交換するためのツールとしてここに適用することができます。これは、図1に示されています。
There are 6 member companies, M1 through M6. Each uses TRIP to send and receive gateway routes with the clearinghouse provider.
6つの会員企業、M6を通じてM1があります。各々がクリアリングハウスプロバイダとゲートウェイルートを送受信するTRIPを使用します。
We refer to a confederation as a group of providers which all agree to share gateways with each other in a full mesh, without using a central clearinghouse. Such a configuration is shown in Figure 2. TRIP would run between each pair of providers.
我々は、すべてが中央のクリアリングハウスを使用せずに、フルメッシュで互いにゲートウェイを共有することに同意プロバイダのグループとして連合を参照してください。このような構成は、プロバイダの各対の間に実行されます。図2 TRIPに示されています。
------ ------
| | | |
| M1 | TRIP TRIP | M2 |
| |\ | | /| |
------ \ | | / ------
\ \ / -------------- \ / /
------ \----| |----/ ------
| | | | | |
| M3 |--------| Clearinghouse|--------| M4 |
| | | | | |
------ /----| |----\ ------
/ -------------- \
------ / \ ------
| |/ \| |
| M5 | | M6 |
| | | |
------ ------
Figure 1: TRIP in the Clearinghouse Application
図1：クリアリングハウスアプリケーションにおけるTRIP
------ ------
| |------| |
| M1 | | M2 |
| |\ /| |
------ \ / ------
| \/ |
| /\ |<-----TRIP
------ / \ ------
| |/ \| |
| M3 | | M4 |
| |------| |
------ ------
Figure 2: TRIP for Confederations
図2：コンフェデレーションズためTRIP
In this application, there are a number of large providers of telephony gateways. Each of these resells its gateway services to medium sized providers. These, in turn, resell to local providers who sell directly to consumers. This is effectively a pyramidal relationship, as shown in Figure 3.
このアプリケーションでは、テレフォニーゲートウェイの大プロバイダの数があります。これらのそれぞれは、中規模のプロバイダへのゲートウェイサービスを再販。これらは、順番に、消費者に直接販売する地元のプロバイダに転売します。図3に示すように、これは、効果的にピラミッド形の関係です。
------
| |
| M1 |
| |
------
/ \ <------- TRIP
------ ------
| | | |
| M2 | | M3 |
| | | |
------ ------
/ \ / \
------ ------ ------
| | | | | |
| M4 | | M5 | | M6 |
| | | | | |
------ ------ ------
Figure 3: TRIP for Wholesalers
図3：卸売業者TRIP
Note that in this example, provider M5 resells gateways from both M2 and M3.
この例では、プロバイダM5は、M2及びM3の両方からゲートウェイを再販することに留意されたいです。
7 Architecture
7アーキテクチャ
Figure 4 gives the overall architecture of TRIP.
図4は、TRIPの全体的なアーキテクチャを与えます。
ITAD1 ITAD2
----------------- ------------------
| | | |
| ---- | | ---- |
| | GW | | | | EU | |
| ---- \ ---- | | ---- / ---- |
| | LS | ---------------- | LS | |
| ---- ---- | / ---- \ ---- |
| | GW | / | /| | EU | |
| ---- | / | ---- |
| | / | |
------------------ / ------------------
/
/
--------- /----------
| | |
| ---- |
| | LS | |
| / ---- \ |
| ---- || ---- |
| | GW | || | EU | |
| ---- || ---- |
| ---- || ---- |
| | GW | / \ | EU | |
| ---- ---- |
| |
---------------------
ITAD3
Figure 4: TRIP Architecture
図4：TRIPアーキテクチャ
There are a number of Internet Telephony administrative domains (ITAD's), each of which has at least one Location Server (LS). The LS's, through an out-of-band means, called the intra-domain protocol, learn about the gateways in their domain. The intra-domain protocol is represented by the lines between the GW and LS elements in ITAD1 in the Figure. The LS's have associations with other LS's, over which they exchange gateway information. These associations are established administratively, and are set up when the IT administrative domains have some kind of agreements in place regarding exchange of gateway information. In the figure, the LS in ITAD1 is connected to the LS in ITAD2, which is in turn connected to the LS in ITAD3. Through Telephony Routing over IP (TRIP), the LS in ITAD2 learns about the two gateways in ITAD1. This information is accessed by end users (EUs) in ITAD2 through the front-end. The front-end is a non-TRIP protocol or mechanism by which the LS databases are accessed. In ITAD3, there are both EUs and gateways. The LS in ITAD3 learns about the gateways in ITAD1 through a potentially aggregated advertisement from the LS in ITAD2.
少なくとも一つのロケーションサーバ（LS）をそれぞれ有するインターネット電話管理ドメイン（ITADの）、の数があります。 LSさんは、アウトオブバンドの手段を通じて、そのドメイン内のゲートウェイを学び、ドメイン内プロトコルと呼ばれます。ドメイン内プロトコルを図ITAD1におけるGWとLS要素間の線で表されています。 LSさんは、彼らがゲートウェイ情報を交換する上で他のLSの、との関連を持っています。これらの関連付けは管理設立され、IT管理ドメインは、ゲートウェイの情報交換に関する代わりに契約のいくつかの種類を持っているときに設定されています。同図において、ITAD1にLSを順次ITAD3でLSに接続されているITAD2にLSに接続されています。 IPテレフォニー以上のルーティング（TRIP）を通じ、ITAD2でLSはITAD1で2つのゲートウェイについて学習します。この情報は、フロントエンドを介してITAD2にエンドユーザ（のEU）によってアクセスされます。フロントエンドは、LSデータベースがアクセスされることにより、非TRIPプロトコルまたは機構です。 ITAD3では、のEUおよびゲートウェイの両方があります。 ITAD3でLSはITAD2でLSから潜在的に集約広告を通じてITAD1におけるゲートウェイについて学習します。
8 Elements
8つの要素
The architecture in Figure 4 consists of a number of elements. These include the IT administrative domain, end user, gateway, and location server.
図4のアーキテクチャは、要素の数から成ります。これらは、IT管理ドメイン、エンドユーザー、ゲートウェイ、およびロケーションサーバが含まれます。
An IT administrative domain consists of zero or more gateways, at least one Location Server, and zero or more end users. The gateways and LS's are those which are under the administrative control of a single authority. This means that there is one authority responsible for dictating the policies and configuration of the gateways and LS's.
IT管理ドメインは、ゼロ以上のゲートウェイ、少なくとも一つのロケーションサーバ、およびゼロ以上のエンドユーザーで構成されています。ゲートウェイとのLSのは、単一の庁の管理下にあるものです。これは、ゲートウェイとLS年代のポリシーと設定を規定するための1つの権威に責任があることを意味します。
An IT administrative domain need not be the same as an autonomous system. While an AS represents a set of physically connected networks, an IT administrative domain may consist of elements on disparate networks, and even within disparate autonomous systems.
IT管理ドメインは、自律システムと同じである必要はありません。 ASが物理的に接続されたネットワークの集合を表している、IT管理ドメインは、異なるネットワーク上の、さらに異なる自律システム内の要素から構成されてもよいです。
The end users within an IT administrative domain are effectively the customers of that IT administrative domain. They are interested in completing calls towards the telephone network, and thus need access to gateways. An end user may be a customer of one IT administrative domain for one call, and then a customer of a different one for the next call.
IT管理ドメイン内のエンドユーザーが効果的にそのIT管理ドメインの顧客です。彼らは、電話網への通話を完了することに興味があるので、ゲートウェイにアクセスする必要があります。エンドユーザは、1つのコールに1つのIT管理ドメインの顧客、その後、次の呼び出しのために別のものの顧客かもしれません。
An IT administrative domain need not have any gateways. In this case, its LS learns about gateways in other domains, and makes these available to the end users within its domain. In this case, the IT administrative domain is effectively a virtual IP telephony gateway provider. This is because it provides gateway service, but may not actually own or administer any gateways.
IT管理ドメインは、任意のゲートウェイを持つ必要はありません。この場合には、そのLSは、他のドメイン内のゲートウェイについて学習し、そのドメイン内のエンドユーザーにこれらを利用できるようになります。この場合、IT管理ドメインは、効果的に仮想IPテレフォニーゲートウェイプロバイダです。それはゲートウェイサービスを提供していますが、実際にどのゲートウェイを所有または管理していない可能性があるためです。
An IT administrative domain need not have any end users. In this case, it provides "wholesale" gateway service, making its gateways available to customers in other IT administrative domains.
IT管理ドメインは、任意のエンドユーザーである必要はありません。この場合、それは他のIT管理ドメインでの顧客へのゲートウェイを利用可能にする、「卸売」のゲートウェイサービスを提供しています。
An IT administrative domain need not have gateways nor end users. In this case, the ITAD only has LS's. The ITAD acts as a reseller, learning about other gateways, and then aggregating and propagating this information to other ITAD's which do have customers.
IT管理ドメインは、ゲートウェイやエンドユーザーである必要はありません。この場合、ITADは、唯一のLSのを持っています。 ITADは、他のゲートウェイについて学び、再販業者として働き、その後、顧客を持っている他のどのITADのにこの情報を集約して伝播します。
A gateway is a logical device which has both IP connectivity and connectivity to some other network, usually a public or private telephone network. The function of the gateway is to translate the media and signaling protocols from one network technology to the other, achieving a transparent connection for the users of the system.
ゲートウェイは、通常、いくつかの他のネットワークへのIP接続および接続の両方を持っている論理デバイス、パブリックまたはプライベートの電話網です。ゲートウェイの機能は、システムのユーザーのための透過的な接続を達成する、他の1つのネットワーク技術からメディア及びシグナリングプロトコルを変換することです。
A gateway has a number of attributes which characterize the service it provides. Most fundamental among these are the range of phone numbers to which it is willing to provide service. This range may be broken into subranges, and associated with each, some cost metric or cost token. This token indicates some notion of cost or preference for completing calls for this part of the telephone number range.
ゲートウェイは、それが提供するサービスを特徴付ける属性の数を有しています。これらの中で最も基本的には、サービスを提供するために喜んでいるに電話番号の範囲です。この範囲は、下位範囲に分け、それぞれ、いくつかのコストメトリックまたはコストトークンに関連付けることができます。このトークンは、電話番号の範囲のこの部分のコールを完了するためのコストや好みのいくつかの概念を示します。
A gateway has attributes which characterize the volume of service which it can provide. These include the number of ports it has (i.e., the number of simultaneous phone calls it can support), and the access link speed. These two together represent some notion of the capacity of the gateway. The metric is useful for allowing Location Servers to decide to route calls to gateways in proportion to the value of the metric, thus achieving a simple form of load balancing.
ゲートウェイは、それが提供できるサービスの量を特徴付ける属性があります。これらは、それが有するポート数（すなわち、同時通話の数は、それがサポートすることができる）、及びアクセスリンク速度が挙げられます。これら二つは一緒にゲートウェイの容量の一部概念を表しています。メトリックは、ロケーションサーバは、ルートに決定できるようにするのに便利ですので、負荷分散の簡単なフォームを達成するため、メトリックの値に比例してゲートウェイに呼び出します。
A gateway also has attributes which characterize the type of service it provides. This includes, but is not limited to, signaling protocols supported, telephony features provided, speech codecs understood, and encryption algorithms which are implemented. These attributes may be important in selecting a gateway. In the absence of baseline required features across all gateways (an admirable, but difficult goal), such a set of attributes is required in order to select a gateway with which communications can be established. End users which have specific requirements for the call (such as a user requesting a business class call, in which case certain call features may need to be supported) may wish to make use of such information as well.
ゲートウェイはまた、それが提供するサービスの種類を特徴付ける属性を有しています。これには、これらに限定されないが、サポートされるシグナリングプロトコル、提供テレフォニー機能、音声コーデックを理解し、実装されている暗号化アルゴリズム。これらの属性は、ゲートウェイを選択する上で重要であるかもしれません。すべてのゲートウェイ（立派な、しかし難しい目標）の両端のベースラインに必要な機能がない場合、属性のそのようなセットは、通信が確立可能なゲートウェイを選択するために必要とされます。 （例えば、特定の通話機能をサポートする必要があり、その場合には、ビジネスクラスの呼び出しを要求しているユーザ、など）の呼び出しのための特定の要件を持つエンドユーザーは、同様に、そのような情報を利用することを望むかもしれません。
Some of these attributes are transported in TRIP to describe gateways, and others are not. This depends on whether the metric can be reasonably aggregated, and whether it is something which must be conveyed in TRIP before the call is set up (as opposed to negotiated or exchanged by the signaling protocols themselves). The philosophy of TRIP is to keep it simple, and to favor scalability above abundance of information. TRIP's attribute set is readily extensible. Flags provide information that allow unknown attributes to be reasonably processed by an LS.
これらの属性のいくつかは、ゲートウェイを記述するためにTRIPに輸送され、そして他の人はそうではありません。これは、メトリックが合理的に集約できるかどうかに依存し、それかどうかを呼が設定される前に、（シグナリングプロトコル自身によって交渉や交換ではなく）TRIPに搬送しなければならないものです。 TRIPの哲学はそれをシンプルに保つために、情報の豊富な上に拡張性を優先することです。 TRIPの属性セットは、容易に拡張可能です。フラグは、未知の属性が合理的にLSによって処理されることを可能にする情報を提供します。
An end user is an entity (usually a human being) which wishes to complete a call through a gateway from an IP network to a terminal on a telephone network. An end user may be a user logged on at a PC with some Internet telephony software. The end user may also be connected to the IP network through an ingress telephone gateway, which the user accessed from telephone handset. This is the case for what is referred to as "phone to phone" service with the IP network used for interexchange transport.
エンドユーザは、電話ネットワーク上の端末にIPネットワークからゲートウェイを介してコールを完了することを希望するエンティティ（通常は人間）です。エンドユーザーは、いくつかのインターネット電話ソフトウェアを使用してPCにログオンしたユーザーかもしれません。エンドユーザはまた、ユーザが電話の受話器からアクセス入口電話ゲートウェイを介してIPネットワークに接続されていてもよいです。これは、エクスチェンジの輸送に使用するIPネットワークと「電話の電話に」サービスと呼ばれるものの場合です。
End users may, or may not be aware that there is a telephony routing service running when they complete a call towards the telephone network. In cases where they are aware, end users may have preferences for how a call is completed. These preferences might include call features which must be supported, quality metrics, owner or administrator, and cost preferences.
エンドユーザーは、または彼らは電話網へのコールを完了したときに実行しているテレフォニールーティングサービスがあることを認識していない可能性があります。彼らは認識しているケースでは、エンドユーザは、コールが完了したかについての好みを有することができます。これらの設定はサポートされなければならない通話機能、品質メトリクス、所有者や管理者、およびコストの好みが含まれる場合があります。
TRIP does not dictate how these preferences are combined with those of the provider to yield the final gateway selection. Nor does TRIP support the transport of these preferences to the LS. This transport can be accomplished using the front end, or by some non-protocol means.
TRIPは、これらの設定は、最終的なゲートウェイ選択を得るために、プロバイダのものと組み合わされる方法を指示しません。 NOR TRIPは、LSにこれらの設定の転送をサポートしていません。この輸送は、フロントエンドを使用して達成、またはいくつかの非プロトコルの手段によって行うことができます。
The Location Server (LS) is the main functional entity of TRIP. It is a logical device which has access to a database of gateways, called the Telephony Routing Information Base (TRIB). This database of gateways is constructed by combining the set of locally available gateways and the set of remote gateways (learned through TRIP) based on policy. The LS also exports a set of gateways to its peer LS's in other ITAD's. The set of exported gateways is constructed from the set of local gateways and the set of remote gateways (learned through TRIP) based on policy. As such, policy plays a central role in the LS operation. This flow of information is shown in Figure 5.
ロケーションサーバ（LS）は、TRIPの主な機能エンティティです。これは、ゲートウェイのデータベースへのアクセスを有する論理デバイスであり、電話ルーティング情報ベース（TRIB）と呼ばれます。ゲートウェイのこのデータベースがローカルで利用可能なゲートウェイのセットとリモートゲートウェイのセットを組み合わせることにより構成されているポリシーに基づいて（TRIPを通じて学習）。 LSは、他のITADの中でそのピアLS年代にゲートウェイのセットをエクスポートします。エクスポートされたゲートウェイのセットがローカルゲートウェイのセットとリモートゲートウェイのセットから構成されているポリシーに基づいて（TRIPを通じて学習）。そのため、政策はLS操作で中心的な役割を果たしています。情報の流れは、図5に示されています。
|
|Intra-domain protocol
\ /
Local
Gateways
TRIP--> Gateways POLICY Gateways -->TRIP IN Out | \ / Telephony Routing Information Base
TRIP - >ゲートウェイポリシーゲートウェイ - アウトIN> TRIP | \ /テレフォニールーティング情報ベース
Figure 5: Flow of Information in TRIP
図5：TRIPにおける情報の流れ
The TRIB built up in the LS allows it to make decisions about IP telephony call routing. When a signaling message arrives at a signaling server, destined for a telephone network address, the LS's database can provide information which is useful for determining a gateway or an additional signaling server to forward the signaling message to. For this reason, an LS may be coresident with a signaling server. When they are not coresident, some means of communication between the LS and the signaling server is needed. This communication is not specifically addressed by TRIP, although it is possible that TRIP might meet the needs of such a protocol.
LSに構築TRIBは、IPテレフォニーコールルーティングに関する決定を行うことができます。シグナリングメッセージは、シグナリング・サーバに到着すると、電話ネットワークアドレス宛、LSのデータベースは、ゲートウェイまたはへシグナリングメッセージを転送するための追加のシグナリング・サーバを決定するために有用である情報を提供することができます。このような理由から、LSは、シグナリングサーバと共存することができます。彼らは共存ない場合、LSとシグナリングサーバ間の通信のいくつかの手段が必要とされています。 TRIPは、このようなプロトコルのニーズを満たす可能性があることは可能であるが、この通信は、具体的には、TRIPによって対処されていません。
An ITAD must have at least one LS in order to participate in TRIP. An ITAD may have more than one LS, for purposes of load balancing, ease of management, or any other reason. In that case, communications between these LS's may need to take place in order to synchronize databases and share information learned from external peers. This is often referred to as the interior component of an inter-domain protocol. TRIP includes such a function.
ITADはTRIPに参加するために、少なくとも1つのLSを持っている必要があります。 ITADは、負荷分散、管理のしやすさ、あるいはその他の理由のために、複数のLSを有することができます。その場合には、これらのLSの間の通信には、データベースを同期して、外部ピアから学習した情報を共有するために、場所を取る必要があるかもしれません。これは、多くの場合、ドメイン間プロトコルの内部構成要素と呼ばれます。 TRIPは、このような機能を含んでいます。
Figure 5 shows an LS learning about gateways within the ITAD by means of an intra-domain protocol. There need not be an intra-domain protocol. An LS may operate without knowledge of any locally run gateways. Or, it may know of locally run gateways, but through static configuration. An LS may also be co-resident with a gateway, in which case it would know about the gateway that it is co-resident with.
図5は、ドメイン内のプロトコルによってITAD内のゲートウェイについて学ぶLSを示しています。ドメイン内のプロトコルが存在する必要はありません。 LSは、ローカルで実行するゲートウェイの知識がなくても動作することができます。それとも、それはローカルで実行ゲートウェイの知っているが、静的な構成によることがあります。 LSはまた、それがと共存であることゲートウェイについて知っているであろうその場合、ゲートウェイと共存してもよいです。
9 Element Interactions
9つの要素の相互作用
Gateways must somehow propagate information about their characteristics to an LS within the same ITAD. This LS may, in turn, further propagate this information outside of the ITAD by means of TRIP. This LS is called an originating LS for that gateway. When an LS nis not coresident with the gateway, the means by which the information gets propagated is not within the scope of TRIP. The protocol used to accomplish this is generally called an intra-domain protocol.
ゲートウェイは何とか同じITAD内のLSにその特性についての情報を伝達する必要があります。これは、順番に、さらにTRIPによってITADの外に、この情報を伝搬することができるLS。これは、ゲートウェイの元のLSと呼ばれているLS。 LSのNISは、ゲートウェイと共存しない場合、情報が伝播されますする手段は、TRIPの範囲内ではありません。これを実現するために使用されるプロトコルは、一般的に、ドメイン内プロトコルと呼ばれています。
One way in which the information can be propagated is with the Service Location Protocol (SLP) [7]. The gateway can contain a Service Agent (SA), and the LS can act as a Directory Agent (DA). SLP defines procedures by which service information is automatically propagated to DA's from SA's. In this fashion, an LS can learn about gateways in the ITAD.
情報が伝播されることができる1つの方法は、サービスロケーションプロトコル（SLP）である[7]。ゲートウェイは、サービス・エージェント（SA）を含むことができ、およびLSはディレクトリエージェント（DA）として機能することができます。 SLPは、サービス情報が自動的にSAのDAからのに伝播させる手順を定義します。このように、LSはITAD内のゲートウェイについて学ぶことができます。
An alternate mechanism for the intra-domain protocol is via the registration procedures of SIP or H.323. The registration procedures provide a means by which users inform a gatekeeper or SIP server about their address. Such a registration procedure could be extended to allow a gateway to effectively register as well.
ドメイン内プロトコルの代替メカニズムは、SIPまたはH.323の登録手順を介してです。登録手続きは、ユーザーが自分のアドレスについてのゲートキーパーまたはSIPサーバに通知する手段を提供します。そのような登録手順は、ゲートウェイが効果的にも登録できるように拡張することができます。
LDAP [8] might also be used for the intra-domain protocol. A gateway can use LDAP to add an entry for itself into the database. If the LS also plays the role of the LDAP server, it will be able to learn about all those gateways in its ITAD.
[8] LDAPはまた、ドメイン内のプロトコルのために使用される可能性があります。ゲートウェイは、データベースに自分自身のためにエントリを追加するためにLDAPを使用することができます。 LSはまた、LDAPサーバーの役割を果たしている場合、そのITAD内のすべてのこれらのゲートウェイを学ぶことができるようになります。
The intra-domain protocol which is used may be different from IT administrative domain to IT administrative domain, and is a matter of local configuration. There may also be more than one intra-domain protocol in a particular ITAD. An LS can also function without an intra-domain protocol. It may learn about gateways through static configuration, or may not know of any local gateways.
使用されているドメイン内のプロトコルは、ITへのIT管理ドメイン管理ドメインとは異なること、及びローカル構成の問題であることができます。また、特定のITADに複数のドメイン内のプロトコルがあるかもしれません。 LSはまた、ドメイン内のプロトコルがなくても機能することができます。これは、静的な構成を通じてゲートウェイについて学ぶこと、または任意のローカルゲートウェイを知らないかもしれません。
The interaction between LS's is what is defined by TRIP. LS's within the same ITAD use TRIP to synchronize information amongst themselves. LS's within different ITADs use TRIP to exchange gateway information according to policy. In the former case the LS's are referred to as internal peers, and in the latter case, external peers.
LS年代の間の相互作用は、TRIPによって定義されるものです。同じITAD内のLSのは、それ自体で情報を同期するためにTRIPを使用しています。異なるITADs内のLSのは、ポリシーに応じてゲートウェイ情報を交換するためにTRIPを使用しています。前者の場合のLSの内部ピア、および後者の場合には、外部ピアと呼ばれます。
LS's communicate with each other through persistent associations. An LS may be connected to one or more other LS's. LS's need not be physically adjacent or part of the same autonomous system. The association between a pair of LS's is normally set up administratively. Two LS's are configured to communicate with each other when their administrators have an agreement in place to exchange gateway information. While TRIP does not provide an autodiscovery procedure for peer LS's to discover each other, one could possibly be used. Such a procedure might be useful for finding a backup peer LS when a crash occurs. Alternatively, in an environment where the business relationships between peers become more standardized, peers might be allowed to discover each other through protocols like the Service Location Protocol (SLP) [9]. Determination about whether autodiscovery should or should not be used is at the discretion of the administrator.
LSさんは、永続的な団体を介して相互に通信します。 LSは、一つ以上の他のLSのに接続することができます。 LSさんは、物理的に隣接するか、同じ自律システムの一部である必要はありません。 LS年代のペア間の関連付けは、通常、管理上設定されています。二つのLSのは、その管理者は、ゲートウェイ情報を交換する場で契約を結んでいたときに、相互に通信するように構成されています。 TRIPが互いを発見するために、ピアのLSのために自動検出手順を提供していませんが、一つは、おそらく使用することができます。このような手順は、クラッシュが発生したときに、バックアップピアLSを見つけるための役に立つかもしれません。また、ピア間のビジネス関係をより標準になる環境で、ピアは、サービスロケーションプロトコル（SLP）などのプロトコルを使用して互いを発見させて頂く場合がございます[9]。自動検出がまたは使用すべきではないべきかどうかについての決意は、管理者の裁量です。
The syntax and semantics of the messages exchanged over the association between LS's are dictated by TRIP. The protocol does not dictate the nature of the agreements which must be in place. TRIP merely provides a transport means to exchange whatever gateway routing information is deemed appropriate by the administrators of the system. Details are provided in the TRIP protocol specification itself.
メッセージの構文とセマンティクスはのはTRIPによって決定されているLSの間の関連を介して交換しました。プロトコルは場所になければならない契約の性質を規定していません。 TRIPは、単に輸送がルーティング情報は、システムの管理者が適切と判断されているものゲートウェイ交換する手段を提供します。詳細は、TRIPプロトコル仕様自体に設けられています。
The rules which govern which gateway information is generated, propagated, and accepted by a gateway is called a location server policy. TRIP does not dictate or mandate any specific policy.
ゲートウェイ情報は、ゲートウェイによって、生成された伝播、及び受け入れられる支配するルールは、ロケーションサーバポリシーと呼ばれます。 TRIPは、口述または任意の特定のポリシーを強制しません。
The information exchanged by the LS's is a set of routing objects. Each routing object minimally consists of a range of telephone numbers which are reachable, and an IP address or host name which is the application-layer "next hop" towards a gateway which can reach that range. Routing objects are learned from the intra-domain protocol, static configuration, or from LS's in remote ITAD's. An LS may aggregate these routing objects together (merging ranges of telephone numbers, and replacing the IP address with its own IP address, or with the IP address of a signaling server with which the LS is communicating) and then propagate them to another LS. The decision about which objects to aggregate and propagate is known as a route selection operation. The administrator has great latitude in selecting which objects to aggregate and propagate, so long as they are within the bounds of correct protocol operation (i.e., no loops are formed). The selection can be made based on information learned through TRIP, or through any out of band means.
LS年代によって交換される情報は、ルーティングオブジェクトのセットです。各ルーティング目的は、最小限、その範囲に到達することができ、ゲートウェイに向かってアプリケーション層「ネクストホップ」で到達可能な電話番号の範囲、およびIPアドレスまたはホスト名から成ります。ルーティングオブジェクトは、ドメイン内のプロトコル、静的な設定から学習され、またはリモートITAD年代のLS年代から。 LSは（電話番号の範囲をマージし、自身のIPアドレスを持つ、またはLSが通信しているシグナリング・サーバのIPアドレスとIPアドレスを交換）した後、別のLSにそれらを伝播一緒にこれらのルーティングのオブジェクトを集約することができます。凝集と伝播するどのオブジェクトについての決定は、経路選択操作として知られています。管理者は、彼らが正しいプロトコル動作の範囲内である限り、凝集と伝播するオブジェクトを選択する際に大きな自由度を有している（すなわち、いかなるループは形成されません）。選択はTRIPを通じて、またはいずれかを介して、バンド手段の外に学習した情報に基づいて行うことができます。
A routing object may have additional information which characterizes the service at the gateway. These attributes include things like protocols, features supported, and capacity. Greater numbers of attributes can provide useful information, however, they come at a cost. Aggregation becomes difficult with more and more information, impacting the scalability of the protocol.
ルーティングオブジェクトはゲートウェイでサービスを特徴付ける追加情報を有していてもよいです。これらの属性は、プロトコル、サポートされている機能、および能力のようなものが含まれます。属性の大きい数字は、しかし、彼らはコストで来る、有用な情報を提供することができます。集計は、プロトコルの拡張性に影響を与え、より多くの情報が困難になります。
Aggregation plays a central role in TRIP. In order to facilitate scalability, routing objects can be combined into larger aggregates before being propagated. The mechanisms by which this is done are specified in TRIP. Aggregation of application layer routes to gateways is a non-trivial problem. There is a fundamental tradeoff between aggregatability and verbosity. The more information that is present in a TRIP routing object, the more difficult it is to aggregate.
集計は、TRIPにおいて中心的な役割を果たしています。スケーラビリティを容易にするために、ルーティングオブジェクトが伝播される前に、より大きな凝集体に結合することができます。これが行われているメカニズムは、TRIPに指定されています。ゲートウェイへのアプリケーション層経路の集合は、非自明な問題です。凝集性と冗長性の間には根本的なトレードオフがあります。 TRIPルーティング・オブジェクトに存在するより多くの情報は、より困難それが凝集することです。
Consider a simple example of two gateways, A and B, capable of reaching some set of telephone numbers, X and Y, respectively. C is an LS for the ITAD in which A and B are resident. C learns of A and B through some other means. As it turns out, X and Y can be combined into a single address range, Z. C has several options. It can propagate just the advertisement for A, just the advertisement for B, propagate both, or combine them and propagate the aggregate advertisement. In this case C chooses the latter approach, and sends a single routing object to one of its peers, D, containing address range Z and its own address, since it is also a signaling server. D is also a signaling server.
電話番号、それぞれX及びY、いくつかの組に到達することが可能な2つのゲートウェイ、AとBの単純な例を考えます。 Cは、A及びBが常駐されたITADためLSです。 Cは、いくつかの他の手段を介してAとBを知ります。結局のところ、X及びYは、単一のアドレス範囲に組み合わせることができ、ZのCは、いくつかのオプションを有しています。それは、A、Bのためだけの広告のためだけに広告を伝播の両方を伝播し、またはそれらを組み合わせて、集約広告を伝播することができます。この場合、Cは、後者のアプローチを選択し、そしてそれはまた、シグナリング・サーバであるので、アドレス範囲Zと、自身のアドレスを含む、そのピアの1つ、Dに単一のルーティング・オブジェクトを送信します。 Dはまた、シグナリング・サーバです。
Some calling device, E, wishes to place a phone call to telephone number T, which happens to be in the address range X. E is configured to use D as its default H.323 gatekeeper. So, E sends a call setup message to D, containing destination address T. D determines that the address T is within the range Z. As D had received a routing object from C containing address range Z, it forwards the call setup message to C. C, in turn, sees that T is within range X, and so it forwards the call setup to A, which terminates the call signaling and initiates a call towards the telephone network.
いくつかの呼び出しデバイス、Eは、EがデフォルトのH.323ゲートキーパーとしてDを使用するように設定されたアドレス範囲Xにあることを起こるの電話番号Tに電話をかけることを望みます。だから、Eは、Dは、Dは、アドレス範囲Zを含むCからルーティングオブジェクトを受けていたように、アドレスTが範囲Z.内であると判断し、宛先アドレスT.を含む、Dへ呼設定メッセージを送信し、それは、Cに呼設定メッセージを転送します。Cは、今度は、Tが範囲X内にあることを見て、それは、コールシグナリングを終了し、電話網に向かって呼を開始Aに呼設定を転送します。
One of the factors which is useful to consider when selecting a gateway is "QoS" - will a call through this gateway suffer sufficiently low loss, delay, and jitter? The quality of a call depends on two components - the QoS on the path between the caller and gateway, and the capacity of the gateway itself (measured in terms of number of circuits available, link capacity, DSP resources, etc.). Determination of the latter requires intricate knowledge of underlying network topologies, and of where the caller is located. This is something handled by QoS routing protocols, and is outside the scope of TRIP.
このゲートウェイを介してコールが十分に低損失、遅延、およびジッタを被るだろう - ゲートウェイを選択する際に考慮することが有益である要因の一つは、「QoSが」ですか？ （利用可能な回路、リンク容量、DSPリソース、等の多数の点で測定された）発呼者及びゲートウェイ、ゲートウェイ自体の容量との間の経路上のQoS - 通話の品質は、2つの成分に依存します。後者の決定は、発信者が位置する場合の、基本的なネットワークトポロジの複雑な知識を必要とします。これは、QoSルーティングプロトコルで扱うものです、そしてTRIPの範囲外です。
However, gateway capacity is not dependent on the caller location or path characteristics. For this reason, a capacity metric of some form is supported by TRIP. This metric represents the static capacity of the gateway, not the dynamic available capacity which varies continuously during the gateways operation. LS's can use this metric as a means of load balancing of calls among gateways. It can also be used as an input to any other policy decision.
しかし、ゲートウェイ容量は、発信者の場所または経路の特性に依存しません。このため、何らかの形の容量メトリックはTRIPによってサポートされています。このメトリックは、ゲートウェイ、ゲートウェイの動作中に連続的に変化しない動的な利用可能な容量の静電容量を表します。 LSさんは、ゲートウェイ間のコールの負荷分散の手段として、このメトリックを使用することができます。また、他の政策決定への入力として使用することができます。
Another useful attribute to propagate is a pricing metric. This might represent the amount a particular gateway might charge for a call. The metric can be an index into a table that defines a pricing structure according to a pre-existing business arrangement, or it can contain a representation of the price itself. TRIP itself does not define a pricing metric, but one can and should be defined as an extension. Using an extension for pricing means more than one such metric can be defined.
伝播する別の有用な属性は、価格指標です。これは、特定のゲートウェイがコールのために課金することがある量を表すことができます。メトリックは、既存のビジネスの配置に従って価格構成を定義するテーブルへのインデックスとすることができる、またはそれは価格自体の表現を含むことができます。 TRIP自体は、価格のメトリックを定義していませんが、1缶と拡張として定義されなければなりません。価格設定のための拡張機能を使用すると、複数のそのようなメトリックを定義することができることを意味します。
10 The Front End
10フロントエンド
As a result of TRIP, the LS builds up a database (the TRIB) of gateway routes. This information is made available to various entities within the ITAD. The way in which this information is made available is called the front end. It is the visible means by which TRIP services are exposed outside of the protocol.
TRIPの結果として、LSは、ゲートウェイの経路データベース（TRIB）を構築します。この情報は、ITAD内のさまざまなエンティティに利用可能になります。この情報が利用可能にされる方法は、フロントエンドと呼ばれています。これは、TRIPサービスは、プロトコルの外側に露出されて可視の手段です。
There are several entities which might use the front end to access the TRIB. These include, but are not limited to:
TRIBにアクセスするためのフロントエンドを使用する場合がありますいくつかのエンティティがあります。これらには、これらに限定されません：
Signaling Servers: Signaling servers receive signaling messages (such as H.323 or SIP messages) whose purpose is the initiation of IP telephony calls. The destination address of these calls may be a phone number corresponding to a terminal on the GSTN. In order to route these calls to an appropriate gateway, the signaling server will need access to the database built up in the LS.
サーバーシグナリング：シグナリングサーバは、その目的は、IPテレフォニーコールの開始である（例えばH.323やSIPメッセージなど）シグナリングメッセージを受信します。これらの呼び出しの宛先アドレスは、GSTN上の端末に対応する電話番号であってもよいです。ルート適切なゲートウェイにこれらの呼び出しをするためには、シグナリング・サーバは、LSに構築データベースにアクセスする必要があります。
End Users: End users can directly query the LS to get routing information. This allows them to provide detailed information on their requirements. They can then go and contact the next hop signaling server or gateway towards that phone number.
エンドユーザー：エンドユーザーが直接ルーティング情報を取得するLSを照会することができます。これは、彼らがその要件に関する詳細な情報を提供することができます。そして、彼らは行って、その電話番号に向けて次のホップシグナリングサーバやゲートウェイに接続することができます。
Administrators: Administrators may need to access the TRIB for maintenance and management functions.
管理者：管理者は、保守・管理機能のためのTRIBにアクセスする必要があるかもしれません。
When a signaling server contacts the LS to route a phone number, it is usually doing so because a calling device (on behalf of an end user) has attempted to set up a call. As a result, signaling servers effectively act as proxies for end users when accessing the LS database. The communication between the calling devices and their proxies (the signaling servers) is through the signaling protocol.
（エンドユーザーの代わりに）発信側デバイスがコールをセットアップしようとしているため、ルートへのシグナリング・サーバーの連絡先LS電話番号は、通常はそうした場合。 LSデータベースにアクセスするときその結果、シグナリング・サーバは、効果的にエンドユーザーのためのプロキシとして動作します。発呼デバイスとそのプロキシ（シグナリング・サーバ）との間の通信は、シグナリングプロトコルを介して行われます。
The advantage of this proxy approach is that the actual LS interaction is hidden from the calling device. Therefore, whether the call is to a phone number or IP address is irrelevant. The routing in the case of phone numbers takes place transparently. Proxy mode is also advantageous for thin clients (such as standalone IP telephones) which do not have the interfaces or processing power for a direct query of the LS.
このプロキシアプローチの利点は、実際のLSの相互作用が発信側デバイスから隠されていることです。そのため、コールは電話番号やIPアドレスにあるかどうかは無関係です。電話番号の場合、ルーティングは透過的に行われます。プロキシモードは、LSの直接クエリのインターフェイス又は処理能力を持っていない（例えば、スタンドアロンのIP電話のような）シンクライアントのためにも有利です。
The disadvantage of the proxy approach is the same as its advantage - the LS interaction is hidden from the calling device (and thus the end user). In some cases, the end user may have requirements as to how they would like the call to be routed. These include preferences about cost, quality, administrator, or call services and protocols. These requirements are called the end user policy. In the proxy approach, the user effectively accesses the service through the signaling protocol. The signaling protocol is not likely to be able to support expression of complex call routing preferences from end users (note however, that SIP does support some forms of caller preferences for call routing [10]). Therefore, direct access from the end user to the LS can provide much richer call routing services.
プロキシ・アプローチの欠点は、その利点と同じである - LSの相互作用は、発呼デバイス（したがって、エンドユーザ）から隠されています。いくつかのケースでは、エンドユーザは、彼らがコールをルーティングする方法を希望するなどの要件を有することができます。これらは、コスト、品質、管理者、または通話サービスとプロトコルに関する設定が含まれています。これらの要件は、エンドユーザーポリシーと呼ばれています。プロキシ・アプローチでは、ユーザは、効果的にシグナリングプロトコルを介してサービスにアクセスします。シグナリングプロトコルは、（[10] SIPはコールルーティングのために発信者の好みのいくつかの形式をサポートしないことは注意してください）エンドユーザからの複雑なコールルーティング選好の発現を支持することはできそうにありません。したがって、LSにエンドユーザーからの直接のアクセスが非常に豊かなコールルーティングサービスを提供することができます。
When the end user policy is presented to the LS (either directly or through the signaling protocol), it is at the discretion of the LS how to make use of it. The location server may have its own policies regarding how end user preferences are handled.
エンドユーザポリシーが（直接またはシグナリング・プロトコルを介して）LSに提示されたとき、それを利用する方法LSの裁量です。ロケーションサーバは、エンドユーザー設定の処理方法に関する独自のポリシーを持っていることがあります。
There are numerous protocols that can be used in the front end to access the LS database. TRIP does not specify or restrict the possibilities for the front end. It is not clear that it is necessary or even desirable for there to be a single standard for the front end. The various protocols have their strengths and weaknesses. One may be the right solution in some cases, and another in different cases.
LSデータベースにアクセスするためのフロントエンドで使用することができ、多数のプロトコルがあります。 TRIPは、指定したり、フロントエンドの可能性を制限するものではありません。フロントエンドのための単一の標準が存在することは、それが必要な、あるいは望ましいことは明らかではありません。さまざまなプロトコルは、彼らの長所と短所を持っています。一つは、いくつかのケースで適切なソリューションであること、および異なる場合は、別のことがあります。
Some of the possible protocols for the front end are:
フロントエンドのための可能なプロトコルは以下のとおりです。
Service Location Protocol (SLP): SLP has been designed to fit exactly this kind of function. SLP is ideal for locating servers described by a set of attributes. In this case, the server is a gateway (or next hop towards the gateway), and the attributes are the end user policy. The end user is an SLP UA, and the LS is an SLP DA. The Service Query is used to ask for a gateway with a particular set of attributes.
サービス・ロケーション・プロトコル（SLP）：SLPは、関数のまさにこのようにフィットするように設計されています。 SLPは、属性のセットで記述サーバを見つけるための理想的です。この場合、サーバは、ゲートウェイ（またはゲートウェイに向かう次のホップ）であり、属性は、エンドユーザポリシーです。エンドユーザーは、SLP UAで、LSは、SLP DAです。サービスのクエリは、特定の属性セットを持つゲートウェイを求めるために使用されます。
Open Settlements Protocol (OSP): OSP [11] is a client server protocol. It allows the client to query a server with a phone number, and get back the address of a next hop, along with authorization tokens to use for the call. In this case, the server can be an LS. The routing table it uses to respond to OSP queries is the one built up using TRIP.
オープン決済プロトコル（OSP）：OSP [11]クライアント・サーバ・プロトコルです。これは、呼び出しに使用する認証トークンと一緒に、クライアントは電話番号を持つサーバーを照会することができ、およびネクストホップのアドレスを取り戻します。この場合、サーバはLSすることができます。それはOSPクエリに応答するために使用するルーティングテーブルはTRIPを使って構築されたものです。
Lightweight Directory Access Protocol (LDAP): LDAP is used for accessing distributed databases. Since the LS server contains a database, LDAP could be used to query it.
LDAP（Lightweight Directory Access Protocol）の：LDAPは、分散データベースにアクセスするために使用されています。 LSサーバーがデータベースに含まれているため、LDAPは、それを照会するために使用することができます。
Web Page: The LS could have a web front end. Users could enter queries into a form, and the matching gateways returned in the response. This access mechanism is more appropriate for human access, however. A signaling server would not likely access the front end through a web page.
Webページ：LSは、Webフロントエンドを持つことができます。ユーザーがフォームにクエリを入力することができ、およびマッチング・ゲートウェイは、応答で返さ。このアクセス機構は、しかし、人間のアクセスのためのより適切です。シグナリング・サーバーは、おそらくウェブページを介してフロントエンドにアクセスしないでしょう。
TRIP: The protocols discussed above are all of the query-response type. There is no reason why the LS access must be of this form. It is perfectly acceptable for the access to be through complete database synchronization, so that the entity accessing the LS database effectively has a full copy of it. If this approach were desired, TRIP itself is an appropriate mechanism. This approach has obvious drawbacks, but nothing precludes it from being done.
TRIP：上記のプロトコルは、クエリ応答型のすべてです。 LSのアクセスはこの形式でなければなりません理由はありません。 LSのデータベースにアクセスするエンティティが効果的にそれの完全なコピーを持つようにアクセスが、完全なデータベース同期経由であることが完全に許容可能です。このアプローチは、所望された場合、TRIP自体は、適切な機構です。このアプローチは、明らかな欠点がありますが、何も行われているから、それを排除しません。
11 Number Translations
11数の翻訳
The model for TRIP is that of many gateways, each of which is willing to terminate calls towards some set of phone numbers. Often, this set will be based on the set of telephone numbers which are in close geographic proximity to the gateway. For example, a gateway in New York might be willing to terminate calls to the 212 and 718 area codes. Of course, it is up to the administrator to decide on what phone numbers the gateway is willing to call.
TRIPのためのモデルは、多くのゲートウェイの、そのそれぞれが、電話番号の一部セットへの通話を終了する意思があるということです。多くの場合、このセットは、ゲートウェイに近い地理的に近接している電話番号のセットに基づいて行われます。例えば、ニューヨークのゲートウェイは、212および718の市外局番への通話を終了することをいとわないかもしれません。もちろん、それはゲートウェイが呼び出すために喜んでどのような電話番号を決定するには、管理者に任されています。
However, certain phone numbers don't represent GSTN terminals at all, but rather they represent services or virtual addresses. An example of such numbers are freephone and LNP numbers. In the telephone network, these are actually mapped to routable telephone numbers, often based on complex formulae. A classic example is time-of-day-based translation.
しかし、特定の電話番号は、全くGSTN端末を表すものではありませんが、むしろ彼らは、サービスや仮想アドレスを表します。そのような数字の例は、フリーダイヤルやLNP数字です。電話ネットワークでは、これらは実際には、多くの場合、複雑な数式に基づいて、ルーティング可能な電話番号にマッピングされます。古典的な例は、時刻ベースの翻訳です。
While nothing prevents a gateway from advertising reachability to these kinds of numbers, this usage is highly discouraged. Since TRIP is a routing protocol, the routes it propagates should be to routable numbers, not to names which are eventually translated to routable numbers. Numerous problems arise when TRIP is used to propagate routes to these numbers:
何も数字のこれらの種類の広告到達性からゲートウェイを妨げませんが、この使用方法は非常に落胆しています。 TRIPは、ルーティングプロトコルであるため、それは伝播経路は、ルーティング可能な番号にではなく、最終的にルーティング可能な番号に変換される名前であるべきです。 TRIPは、これらの番号へのルートを伝播するために使用されている場合、多くの問題が発生します：
o Often, these numbers have only local significance. Calls to a freephone number made from New York might terminate in a New York office of a company, while calls made from California will terminate in a California branch. If this freephone number is injected into TRIP by a gateway in New York, it could be propagated to other LS's with end users in California. If this route is used, calls may be not be routed as intended.
Oしばしば、これらの数字は、ローカルな意味を持っています。カリフォルニアから発信されたコールは、カリフォルニア支店で終了する一方、ニューヨークから作られたフリーダイヤル番号への通話は、同社のニューヨークオフィスで終了することがあります。このフリーダイヤル番号はニューヨークのゲートウェイによってTRIPに注入された場合、それはカリフォルニアのエンドユーザーとのLSの他に伝播することができます。このルートを使用する場合は意図したように、呼び出しがルーティングされないことがあります。
o The call signaling paths might be very suboptimal. Consider a gateway in New York that advertises a ported number that maps to a phone in California. This number is propagated by TRIP, eventually being learned by an LS with end users in California. When one of them dials this number, the call is routed over the IP network towards New York, where it hits the gateway, and then is routed over the GSTN back to California. This is a waste of resources. Had the ported number been translated before the gateway routing function was invoked, a California gateway could have been accessed directly.
Oパスをコールシグナリングは非常に次善のかもしれません。カリフォルニア州にある電話にマップ移植された番号をアドバタイズニューヨークのゲートウェイを考えてみましょう。この数は、最終的にカリフォルニアのエンドユーザーとのLSによって学習され、TRIPによって伝播されます。そのうちの一つは、この番号をダイヤルすると、コールは、それがゲートウェイに当たるニューヨークに向かってIPネットワークを介してルーティングされ、その後、戻ってカリフォルニアにGSTNを介してルーティングされます。これは資源の無駄です。ポート番号は、ゲートウェイルーティング機能が起動される前に、カリフォルニアゲートウェイが直接アクセスされた可能性が翻訳されていました。
As a result, it is more efficient to perform translations of these special numbers before the LS routing databases are accessed. How this translation is done is outside the scope of TRIP. It can be accomplished by the calling device before making the call, or by a signaling server before it accesses the LS database.
その結果、ルーティングデータベースがアクセスされるLS前に、これらの特別な番号の変換を実行する方が効率的です。この翻訳はどのように行われているTRIPの範囲外です。それはLSデータベースにアクセスする前に、それは、呼び出しを行う前に、またはシグナリング・サーバによって発呼装置によって達成することができます。
12 Security Considerations
12のセキュリティの考慮事項
Security is an important component in TRIP. The TRIP model assumes a level of trust between peer LS's that exchange information. This information is used to propagate information which determines where calls will be routed. If this information were incorrect, it could cause complete misrouting of calls. This enables a significant denial of service attack. The information might also be propagated to other
セキュリティは、TRIPにおける重要な要素です。 TRIPモデルは、ピアLS情報を交換の間の信頼のレベルを想定しています。この情報は、コールがルーティングされる場所を決定する情報を伝播するために使用されます。この情報が正しくありませんでした場合は、通話の完全なmisroutingを引き起こす可能性があります。これは、サービス攻撃の重要な拒否を可能にします。情報は、他に伝播される可能性があります
ITADs, causing the problem to potentially spread. As a result, mutual authentication of peer LS's is critical. Furthermore, message integrity is required.
問題の原因ITADsは、潜在的に広がっています。その結果、ピアLS年代の相互認証が重要です。さらに、メッセージの整合性が必要とされます。
TRIP messages may contain potentially sensitive information. They represent the routing capabilities of an ITAD. Such information might be used by corporate competitors to determine the network topology and capacity of the ITAD. As a result, encryption of messages is also supported in TRIP.
TRIPメッセージは、潜在的な機密情報が含まれていてもよいです。彼らはITADのルーティング機能を表しています。このような情報は、ITADのネットワークトポロジと容量を決定するために、企業の競合他社が使用される可能性があります。その結果、メッセージの暗号化もTRIPでサポートされています。
As routing objects can be passed via one LS to another, there is a need for some sort of end to end authentication as well. However, aggregation will cause the routing objects to be modified, and therefore authentication can only take place from the point of last aggregation to the receiving LS's.
ルーティングオブジェクトを別のLSを経由して渡すことができるように、同様の認証をエンド・ツー・エンドのいくつかの並べ替えの必要性があります。しかし、集約はルーティングオブジェクトが変更されますので、認証のみ受信LS年代に最後の集約の観点から行うことができます。
13 Acknowledgments
13の謝辞
The authors would like to thank Randy Bush, Mark Foster, Dave Oran, Hussein Salama, and Matt Squire for their useful comments on this document.
作者はこのドキュメント上での有益なコメントをランディブッシュ、マーク・フォスター、デイブ・オラン、フセインサラマ、そしてマット・スクワイアに感謝したいと思います。
14 Bibliography
14参考文献
[1] International Telecommunication Union, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service," Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, May 1996.
[1]国際電気通信連合、「サービスの非保証品質を提供するローカルエリアネットワークのためのビジュアル電話システムおよび機器、」勧告H.323、ITU、ジュネーブ、スイス、1996年5月の電気通信標準化部門。
[2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[3] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999.
[3]アランゴ、M.、デュガン、A.、エリオット、I.、のHuitema、C.及びS.ピケット、 "メディアゲートウェイ制御プロトコル（MGCP）バージョン1.0"、RFC 2705、1999年10月。
[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[4] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[5] Simpson, W., "The Point-to-Point Protocol (PPP)," STD 51, RFC 1661, July 1994.
[5]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）、" STD 51、RFC 1661、1994年7月。
[6] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[6] Rekhter Y.とT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[7] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, June 1997.
[7] Veizades、J.、ガットマン、E.、パーキンス、C.及びS.カプラン、 "サービス・ロケーション・プロトコル"、RFC 2165、1997年6月。
[8] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[8]永、W.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル"、RFC 1777、1995年3月。
[9] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[9]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[10] Schulzrinne H. and J. Rosenberg, "SIP caller preferences and callee capabilities", Work in progress.
[10] SchulzrinneとH.とJ.ローゼンバーグ、「SIP発信者の好みや着信機能」、進行中の作業。
[11] European Telecommunications Standards Institute (ETSI), Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON), "Inter-domain pricing, authorization, and usage exchange," Technical Specification 101 321 version 1.4.2, ETSI, 1998.
[11]欧州電気通信標準化機構（ETSI）、電気通信およびインターネット・プロトコル調和オーバーネットワーク（TIPHON）、「ドメイン間の価格設定、認証、および使用方法の交流、」技術仕様101 321バージョン1.4.2、ETSI、1998。
15 Authors' Addresses
15本の著者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
72イーグルロックアベニューまず階イーストハノーバー、NJ 07936 dynamicsoftジョナサン・ローゼンバーグ
Email: jdrosen@dynamicsoft.com
メール：jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027-7003
Email: schulzrinne@cs.columbia.edu
メール：schulzrinne@cs.columbia.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。