[要約] RFC 2871は、IP上の電話ルーティングのためのフレームワークを提供するものであり、VoIPネットワークの設計と実装を支援することを目的としています。
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
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.
Copyright（c）The Internet Society（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（TRIP）を介したテレフォニールーティングのフレームワークとして機能します。これは、プロバイダー間のIPテレフォニーゲートウェイルーティングテーブルの発見と交換をサポートします。このドキュメントは、テレフォニールーティング交換の問題を定義し、プロトコルの必要性を動機付けます。旅行用のアーキテクチャの枠組みを提示し、用語を定義し、さまざまなプロトコル要素とその機能を指定し、プロトコルが提供するサービスの概要を示し、インターネットテレフォニーのより広いコンテキストにどのように適合するかについて説明します。
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（TRIP）を介したテレフォニールーティングのフレームワークとして機能します。これは、プロバイダー間のIPテレフォニーゲートウェイルーティングテーブルの発見と交換をサポートします。このドキュメントは、テレフォニールーティング交換の問題を定義し、プロトコルの必要性を動機付けます。旅行用のアーキテクチャの枠組みを提示し、用語を定義し、さまざまなプロトコル要素とその機能を指定し、プロトコルが提供するサービスの概要を示し、インターネットテレフォニーのより広いコンテキストにどのように適合するかについて説明します。
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].
ゲートキーパー：[1]で定義されているH.323ゲートキーパー要素。
SIP Server: The Session Initiation Protocol proxy or redirect server defined in [2].
SIPサーバー：[2]で定義されているセッション開始プロトコルプロキシまたはリダイレクトサーバー。
Call Agent: The MGCP call agent, defined in [3].
コールエージェント：[3]で定義されているMGCPコールエージェント。
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.
ロケーションサーバーポリシー：ロケーションサーバーが送信する情報をどのように処理し、旅行を通じて受信するかを決定するルールのセット。これには、情報の集約、伝播、生成、および情報の受け入れに関するルールが含まれます。
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.
ピア：2つのLSは、ゲートウェイ情報が交換されるそれらの間に持続的な関連性がある場合、ピアです。
Internal peers: Peers that both reside within the same ITAD.
内部ピア：両方とも同じITAD内に存在する仲間。
External peers: Peers that reside within different ITADs.
外部ピア：異なるITADに存在するピア。
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）：旅行への参加の結果としてゲートウェイAN LSのデータベースが構築されます。
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）を介したテレフォニールーティングです。旅行は、特定の関数セットを提供します。
o Establishment and maintenance of peering relationships between providers;
o プロバイダー間のピアリング関係の確立と維持。
o Exchange and synchronization of telephony gateway routing information between providers;
o プロバイダー間の情報情報をテレフォニーゲートウェイルーティングの交換と同期。
o Prevention of stable routing loops for IP telephony signaling protocols;
o IPテレフォニーシグナリングプロトコルの安定したルーティングループの防止。
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.
旅行は通常、ドメイン間の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アドレス変換の問題」と呼ばれます。ただし、これは単純化されていません。少なくとも3つの別個の問題があり、そのすべては「電話番号からIPアドレス変換の問題」として分類でき、そのうちの1つのみが旅行によって対処されています。
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.
これらの3つのマッピング関数の最後は、PCが電話のインターフェイスとして機能するサービスに役立ちます。そのようなサービスの1つは、ユーザーの電話が鳴るときにPCにインスタントメッセージを配信することです。このサービスを提供するために、GSTNのスイッチは電話番号に通話をルーティングしています。このユーザーのためにPCにインスタントメッセージを送信したいと考えています。このスイッチは、指定された電話番号を使用してユーザーに対応するPCのIPアドレスを決定するために、どういうわけかIPネットワークにアクセスする必要があります。マッピング関数は、翻訳の問題に対処する名前であり、名前は一連の数字で表されます。このような翻訳関数は、ディレクトリプロトコルによって最もよくサポートされています。この問題は旅行によって対処されていません。
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.
これらのマッピングの2番目は、従来の携帯電話からIPターミナルへの通話を容易にするために必要です。GSTNのユーザーがIPネットワーク上の端末を持つユーザーに電話をかけたい場合、その端末を識別する番号をダイヤルする必要があります。この番号はIPアドレスになる可能性があります。ただし、IPアドレスは多くの場合、DHCP [4]またはPPP [5]を使用してダイヤルアップネットワークアクセスサーバーによってオンデマンドで割り当てられた一時的なものです。数字は、数字のグループの文字への翻訳によって取得されるホスト名である可能性があります。ただし、これは面倒です。代わりに、電話番号をIPテレフォニー端末に割り当てることが提案されています。GSTNの発信者は、他のものと同じようにこの番号をダイヤルします。この番号は、IP端末の代替名として機能します。そのホスト名が名前として機能するのとほぼ同じように。GSTNのスイッチは、IPネットワークにアクセスし、この番号からPCのIPアドレスへのマッピングを取得する必要があります。前のケースと同様に、この問題は翻訳の問題に対処する名前であり、ディレクトリプロトコルによって最適に処理されます。旅行によって対処されていません。
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.
ただし、最初のマッピング関数は、基本的に翻訳問題をルーティングするアドレスです。旅行によって考慮されるのはこの問題です。セクション3で説明したように、このマッピングは、ポリシーやプロバイダー関係などのローカル要因に依存します。その結果、利用可能なゲートウェイのデータベースは各プロバイダーで大幅に異なり、特定のプロバイダー間関係を通じて構築する必要があります。このため、ディレクトリプロトコルは旅行に適していませんが、他のプロトコルには適切です。
5 Relationship with BGP
5 BGPとの関係
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:
旅行は、BGPなどのドメイン間IPルーティングプロトコルの密接ないとことして分類できます[6]。ただし、BGPと旅行には重要な違いがあります。
o TRIP runs at the application layer, not the network layer, where BGP resides.
o トリップは、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 多くの中間ネットワークとIPサービスプロバイダーによって分離される可能性のあるサーバー間の旅行走行。BGPは、通常隣接するルーター間で実行されます。
o The information exchanged between TRIP peers describes routes to application layer devices, not IP routers, as is done with BGP.
o トリップピア間で交換される情報は、BGPで行われるように、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 旅行は、基礎となるIP輸送ネットワークの存在を想定しています。これは、この情報に基づいてルーティングされるシグナリングメッセージの転送者として機能する必要はないことを意味します。これはBGPでは当てはまりません。ここでは、ピアはIPパケットの転送ポイント（または隣接する転送ホップに名前を付ける）としても機能する必要があります。
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 旅行の目的は、すべてのITADにわたってグローバルな接続性を確立することではありません。旅行の小さな島がたくさんあることは完全に合理的です。各島は、管理関係の閉鎖セットを表しています。さらに、各島はまだGSTN全体に完全な接続を持つことができます。これは、インターネット全体の完全な接続性であるBGPとは対照的です。BGPの切断のためにASのセットが他のセットから分離されている場合、それらの間に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 IP名スペースの一部を表すBGP交換のプレフィックス。旅行交換電話番号範囲は、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
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.
旅行は、プロバイダー間でIPテレフォニールートを交換するための汎用ツールです。旅行は、いかなる方法でも、これらのプロバイダー間の関係の構造や性質を決定するものではありません。その結果、旅行には、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.
クリアリングハウスは、クリアリングハウスのメンバーと呼ばれる他の多くのプロバイダー間の交換ポイントとして機能するプロバイダーです。各メンバーはクリアリングハウスにサインオンします。契約の一環として、メンバーは、クリアリングハウスの他のメンバーがゲートウェイを利用できるようにします。引き換えに、メンバーはクリアリングハウスの他のメンバーが所有するゲートウェイにアクセスできます。1人のメンバーに属するゲートウェイが電話をかけると、クリアリングハウスは、どのメンバーがコールを終了するかを決定する上で重要な役割を果たします。
TRIP can be applied here as the tool for exchanging routes between the members and the clearinghouse. This is shown in Figure 1.
ここでは、メンバーとクリアリングハウスの間のルートを交換するためのツールとして、ここで旅行を適用できます。これを図1に示します。
There are 6 member companies, M1 through M6. Each uses TRIP to send and receive gateway routes with the clearinghouse provider.
M1からM6のメンバー企業が6つあります。それぞれが旅行を使用して、Clearinghouseプロバイダーとのゲートウェイルートを送信および受け取ります。
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に示します。プロバイダーの各ペア間でトリップが実行されます。
------ ------
| | | |
| M1 | TRIP TRIP | M2 |
| |\ | | /| |
------ \ | | / ------
\ \ / -------------- \ / /
------ \----| |----/ ------
| | | | | |
| M3 |--------| Clearinghouse|--------| M4 |
| | | | | |
------ /----| |----\ ------
/ -------------- \
------ / \ ------
| |/ \| |
| M5 | | M6 |
| | | |
------ ------
Figure 1: TRIP in the Clearinghouse Application
図1：クリアリングハウスアプリケーションでの旅行
------ ------
| |------| |
| M1 | | M2 |
| |\ /| |
------ \ / ------
| \/ |
| /\ |<-----TRIP
------ / \ ------
| |/ \| |
| M3 | | M4 |
| |------| |
------ ------
Figure 2: TRIP for Confederations
図2：南軍の旅行
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：卸売業者のための旅行
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は、旅行の全体的なアーキテクチャを示しています。
ITAD1 ITAD2
----------------- ------------------
| | | |
| ---- | | ---- |
| | GW | | | | EU | |
| ---- \ ---- | | ---- / ---- |
| | LS | ---------------- | LS | |
| ---- ---- | / ---- \ ---- |
| | GW | / | /| | EU | |
| ---- | / | ---- |
| | / | |
------------------ / ------------------
/
/
--------- /----------
| | |
| ---- |
| | LS | |
| / ---- \ |
| ---- || ---- |
| | GW | || | EU | |
| ---- || ---- |
| ---- || ---- |
| | GW | / \ | EU | |
| ---- ---- |
| |
---------------------
ITAD3
Figure 4: TRIP Architecture
図4：トリップアーキテクチャ
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.
多くのインターネットテレフォニー管理ドメイン（ITAD）があり、それぞれに少なくとも1つのロケーションサーバー（LS）があります。LSは、ドメイン内プロトコルと呼ばれる帯域外の手段を通じて、ドメインのゲートウェイについて学びます。ドメイン内プロトコルは、図のITAD1のGW要素とLS要素の間の線で表されます。LSには、他のLSとの関連があり、その上にゲートウェイ情報を交換します。これらの協会は管理上確立され、IT管理ドメインがゲートウェイ情報の交換に関して何らかの契約を締結したときに設定されます。図では、ITAD1のLSはITAD2のLSに接続されており、ITAD3のLSに接続されています。IP（TRIP）を介したテレフォニールーティングを通じて、ITAD2のLSはITAD1の2つのゲートウェイについて学びます。この情報は、フロントエンドを介してITAD2のエンドユーザー（EU）によってアクセスされます。フロントエンドは、LSデータベースにアクセスする非トリッププロトコルまたはメカニズムです。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管理ドメインは、ゼロ以上のゲートウェイ、少なくとも1つのロケーションサーバー、ゼロ以上のエンドユーザーで構成されています。ゲートウェイと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管理ドメインは、自律システムと同じである必要はありません。Aは物理的に接続された一連のネットワークを表しますが、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接続と他のネットワーク、通常はパブリックまたはプライベートの電話ネットワークへの接続の両方を備えた論理デバイスです。ゲートウェイの機能は、メディアとシグナリングプロトコルをあるネットワークテクノロジーから別のネットワークテクノロジーに変換し、システムのユーザーに透明な接続を実現することです。
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.
ゲートウェイには、提供できるサービスの量を特徴付ける属性があります。これらには、持っているポートの数（つまり、サポートできる同時電話の数）とアクセスリンク速度が含まれます。これら2つは一緒になって、ゲートウェイの容量の概念を表しています。メトリックは、位置サーバーがメトリックの値に比例してゲートウェイへの通話をルーティングできるようにするために役立ち、したがって、単純なフォームのロードバランシングを実現します。
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の属性セットは容易に拡張可能です。フラグは、不明な属性を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でログオンしているユーザーである場合があります。エンドユーザーは、ユーザーが電話ハンドセットからアクセスしたIngress電話ゲートウェイを介して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はこれらの設定の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）は、旅行の主要な機能エンティティです。これは、テレフォニールーティング情報ベース（Trib）と呼ばれるゲートウェイのデータベースにアクセスできる論理デバイスです。このゲートウェイのデータベースは、ローカルで利用可能なゲートウェイのセットと、ポリシーに基づいてリモートゲートウェイのセット（旅行を通じて学習）を組み合わせて構築されます。LSはまた、他のITADのピアLSに一連のゲートウェイをエクスポートします。エクスポートされたゲートウェイのセットは、ポリシーに基づいて、ローカルゲートウェイのセットとリモートゲートウェイのセット（旅行を通じて学習）から構成されています。そのため、ポリシーはLS操作において中心的な役割を果たします。この情報の流れを図5に示します。
|
|Intra-domain protocol
\ /
Local
Gateways
TRIP--> Gateways POLICY Gateways -->TRIP
IN Out
|
\ /
Telephony Routing
Information Base
Figure 5: Flow of Information in TRIP
図5：旅行中の情報の流れ
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に組み込まれた部族により、IPテレフォニーコールルーティングに関する決定を下すことができます。電話ネットワークアドレス用に運命づけられた信号メッセージがシグナリングサーバーに到着すると、LSのデータベースは、ゲートウェイまたは追加のシグナリングサーバーを決定して信号メッセージを転送するのに役立つ情報を提供できます。このため、LSはシグナリングサーバーを備えたコアリングである可能性があります。彼らがコアシデントではない場合、LSとシグナリングサーバーの間のコミュニケーション手段が必要です。このコミュニケーションは、旅行によって特別に対処されていませんが、旅行はそのようなプロトコルのニーズを満たす可能性があります。
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には、旅行に参加するために少なくとも1つのLSが必要です。ITADには、負荷分散、管理の容易さ、またはその他の理由のために、複数のLSがある場合があります。その場合、これらのLS間の通信は、データベースを同期し、外部のピアから学んだ情報を共有するために行われる必要があります。これは、多くの場合、ドメイン間プロトコルの内部コンポーネントと呼ばれます。旅行にはそのような機能が含まれます。
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に対する特性に関する情報を何らかの形で伝播する必要があります。このLSは、旅行によってこの情報をITADの外でさらに伝播する可能性があります。このLSは、そのゲートウェイの起源のLSと呼ばれます。LS NISがゲートウェイのコアシデントではない場合、情報が伝播される手段は旅行の範囲内ではありません。これを達成するために使用されるプロトコルは、一般にドメイン内プロトコルと呼ばれます。
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.
LDAP [8]は、ドメイン内プロトコルにも使用される場合があります。ゲートウェイは、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間の相互作用は、旅行によって定義されるものです。同じITAD内のLSは、旅行を使用して情報を同期します。異なるITAD内のLSは、トリップを使用して、ポリシーに応じてゲートウェイ情報を交換します。前者の場合、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は、1つ以上の他のLSに接続されている場合があります。LSは、物理的に隣接したり、同じ自律システムの一部である必要はありません。LSのペア間の関連性は通常、管理上セットアップされています。2つのLSは、管理者がゲートウェイ情報を交換するための合意が整ったときに互いに通信するように構成されています。旅行では、ピア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.
LS間の関連性を介して交換されたメッセージの構文とセマンティクスは、旅行によって決定されます。プロトコルは、整っている必要がある契約の性質を決定しません。旅行は、システムの管理者によって適切と見なされるゲートウェイルーティング情報を交換するための輸送手段を提供するだけです。詳細は、旅行プロトコルの仕様自体で提供されます。
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.
ゲートウェイ情報が生成、伝播、およびゲートウェイによって受け入れられるルールは、ロケーションサーバーポリシーと呼ばれます。旅行は、特定のポリシーを指示したり義務付けたりしません。
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アドレスを独自のIPアドレスに置き換え、またはLSが通信しているシグナリングサーバーのIPアドレスに置き換えてから、それらを別のLSに伝播します。どのオブジェクトが集約および伝播するかについての決定は、ルート選択操作として知られています。管理者は、正しいプロトコル操作の範囲内にある限り（つまり、ループが形成されない）、集約および伝播するオブジェクトを選択する際に大きな緯度を持っています。選択は、旅行を通じて学んだ情報、またはバンド外の手段を通じて学習した情報に基づいて行うことができます。
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.
集約は旅行で中心的な役割を果たします。スケーラビリティを容易にするために、伝播する前にルーティングオブジェクトをより大きな集合体に結合することができます。これが行われるメカニズムは、旅行で指定されます。アプリケーションレイヤールートのゲートウェイへの集約は、自明ではない問題です。集合性と冗長性の間には基本的なトレードオフがあります。旅行ルーティングオブジェクトに存在する情報が多いほど、集約することはより困難になります。
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は後者のアプローチを選択し、単一のルーティングオブジェクトをピアの1つであるDに送信します。これは、シグナリングサーバーでもあるため、アドレス範囲Zと独自のアドレスを含みます。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は、電話番号Tに電話をかけたいと考えています。これはたまたまアドレス範囲Xにあります。Eは、デフォルトのh.323ゲートキーパーとしてDを使用するように設定されています。したがって、eは宛先アドレスTを含むコールセットアップメッセージをDに送信します。Dは、アドレスtが範囲zにあると判断します。Dがアドレス範囲zを含むcからルーティングオブジェクトを受信したため、コールセットアップメッセージを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.
ゲートウェイを選択する際に検討するのに役立つ要因の1つは「QoS」です。このゲートウェイを通る呼び出しは、損失、遅延、ジッターが十分に低くなりますか？呼び出しの品質は、2つのコンポーネントに依存します - 発信者とゲートウェイの間のパス上のQoSと、ゲートウェイ自体の容量（利用可能な回路の数、リンク容量、DSPリソースなど）。後者の決定には、基礎となるネットワークトポロジと発信者がどこにあるかについての複雑な知識が必要です。これは、QoSルーティングプロトコルによって処理されるものであり、旅行の範囲外です。
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.
ただし、ゲートウェイ容量は、発信者の場所やパスの特性に依存しません。このため、何らかの形の容量メトリックが旅行によってサポートされています。このメトリックは、ゲートウェイの静的容量を表し、ゲートウェイ操作中に連続的に変化する動的利用可能容量ではありません。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.
伝播するもう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.
旅行の結果、LSはゲートウェイルートのデータベース（Trib）を構築します。この情報は、ITAD内のさまざまなエンティティで利用可能になります。この情報が利用可能になる方法は、フロントエンドと呼ばれます。これは、トリップサービスがプロトコル以外で公開される目に見える手段です。
There are several entities which might use the front end to access the TRIB. These include, but are not limited to:
フロントエンドを使用して部族にアクセスする可能性のあるエンティティがいくつかあります。これらには以下が含まれますが、これらに限定されません。
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相互作用は呼び出しデバイス（したがってエンドユーザー）から隠されています。場合によっては、エンドユーザーには、呼び出しがどのようにルーティングされるかについての要件がある場合があります。これらには、コスト、品質、管理者、またはコールサービスとプロトコルに関する好みが含まれます。これらの要件は、エンドユーザーポリシーと呼ばれます。プロキシアプローチでは、ユーザーはシグナリングプロトコルを介してサービスに効果的にアクセスします。シグナル伝達プロトコルは、エンドユーザーからの複雑なコールルーティング設定の表現をサポートすることはできません（ただし、SIPはコールルーティングのためのいくつかの形式の発信者設定をサポートしていることに注意してください[10]）。したがって、エンドユーザーから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データベースにアクセスするためにフロントエンドで使用できる多数のプロトコルがあります。旅行では、フロントエンドの可能性を指定または制限しません。フロントエンドに単一の標準があることが必要であるか、望ましいことであることは明らかではありません。さまざまなプロトコルには長所と短所があります。1つは場合によっては正しい解決策であり、別の場合は別のソリューションである可能性があります。
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.
Open Settlements Protocol（OSP）：OSP [11]はクライアントサーバープロトコルです。これにより、クライアントは電話番号を使用してサーバーを照会し、次のホップのアドレスを取り戻し、通話に使用する承認トークンを取得できます。この場合、サーバーはLSになります。OSPクエリに応答するために使用するルーティングテーブルは、旅行を使用して構築されたものです。
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.
Lightweight Directory Access Protocol（LDAP）：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フロントエンドがある可能性があります。ユーザーはクエリをフォームに入力でき、一致するゲートウェイは応答で返されます。ただし、このアクセスメカニズムは、人間のアクセスにより適しています。信号サーバーは、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.
旅行：上記のプロトコルはすべてクエリ応答タイプです。LSアクセスがこの形式でなければならない理由はありません。完全なデータベース同期を介してアクセスできるようにアクセスすることは完全に受け入れられ、LSデータベースにアクセスするエンティティには完全なコピーがあります。このアプローチが必要な場合、トリップ自体が適切なメカニズムです。このアプローチには明らかな欠点がありますが、それが行われることを妨げるものはありません。
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.
旅行のモデルは多くのゲートウェイのモデルであり、それぞれが電話番号のセットに向けて通話を終了することをいとわない。多くの場合、このセットは、ゲートウェイに近接している地理的に近い電話番号のセットに基づいています。たとえば、ニューヨークのゲートウェイは、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:
これらの種類の数値への広告の到達可能性からゲートウェイを防ぐものは何もありませんが、この使用は非常に落胆しています。旅行はルーティングプロトコルであるため、伝播するルートは、最終的にルーティング可能な数値に翻訳される名前ではなく、ルーティング可能な数値である必要があります。これらの数値へのルートを伝播するために旅行を使用すると、多くの問題が発生します。
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 多くの場合、これらの数字には局所的な重要性しかありません。ニューヨークから作られたフリーフォン番号への電話は、ニューヨークの会社のオフィスで終了する可能性がありますが、カリフォルニアからの電話はカリフォルニアの支店で終了します。このフリーフォン番号がニューヨークのゲートウェイで旅行に注入された場合、カリフォルニアのエンドユーザーと一緒に他の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によって学習されます。そのうちの1つがこの番号にダイヤルすると、コールは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ルーティングデータベースにアクセスする前に、これらの特別な数字の翻訳を実行する方が効率的です。この翻訳がどのように行われるかは、旅行の範囲外です。呼び出しを行う前に呼び出しデバイスによって、または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 ITADs, causing the problem to potentially spread. As a result, mutual authentication of peer LS's is critical. Furthermore, message integrity is required.
セキュリティは旅行の重要な要素です。旅行モデルは、その交換情報のピアLS間の信頼のレベルを想定しています。この情報は、コールがルーティングされる場所を決定する情報を伝播するために使用されます。この情報が正しくない場合、それは通話の完全な誤った誤ったものを引き起こす可能性があります。これにより、サービス攻撃の大幅な拒否が可能になります。情報は他のITADにも伝播され、問題が潜在的に広がる可能性があります。その結果、ピア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.
トリップメッセージには、潜在的に機密情報が含まれている場合があります。それらは、ITADのルーティング機能を表しています。このような情報は、ITADのネットワークトポロジと能力を決定するために企業の競合他社によって使用される場合があります。その結果、メッセージの暗号化も旅行でサポートされています。
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に渡すことができるため、何らかのエンドツーエンド認証も必要です。ただし、集約によりルーティングオブジェクトが変更されるため、認証は最後の集約の時点から受信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、1996年5月、スイス、ジュネーブのITUの電気通信標準化セクター。
[2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2] Handley、M.、Schulzrinne、H.、Schooler、E。and J. Rosenberg、「SIP：SESSION INTIATION Protocol」、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] Arango、M.、Dugan、A.、Elliott、I.、Huitema、C。and S. Pickett、「Media Gateway Control Protocol（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. Li、「A Border Gateway Protocol 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.、Guttman、E.、Perkins、C。and S. Kaplan、「Service Location Protocol」、RFC 2165、1997年6月。
[8] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[8] Yeong、W.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol」、RFC 1777、1995年3月。
[9] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[9] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「Service Location Protocol、Version 2」、RFC 2608、1999年6月。
[10] Schulzrinne H. and J. Rosenberg, "SIP caller preferences and callee capabilities", Work in progress.
[10] Schulzrinne H.およびJ. Rosenberg、「SIP発信者の好みとCallee機能」、進行中の作業。
[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イーグルロックアベニュー1階イーストハノーバー、ニュージャージー07936
Email: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングシュルツリンヌコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027-7003
Email: schulzrinne@cs.columbia.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。