RFC2871 日本語訳
2871 A Framework for Telephony Routing over IP. J. Rosenberg, H.Schulzrinne. June 2000. (Format: TXT=60664 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg
Request for Comments: 2871 dynamicsoft
Category: Informational H. Schulzrinne
Columbia University
June 2000
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 2871dynamicsoft Category: 情報のH.Schulzrinneコロンビア大学2000年6月
A Framework for Telephony Routing over IP
IPの上の電話ルート設定のためのフレームワーク
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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)の上のTelephonyルート設定のためのフレームワークとして機能します。IPはプロバイダーの間のIP電話技術ゲートウェイ経路指定テーブルの発見と交換をサポートします。 ドキュメントは、電話ルーティング交換の問題を定義して、プロトコルの必要性を動機づけます。 それは、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
1つの序論… 2 2用語… 2 3の動機と問題定義… 4 4の関連問題… BGPとの6 5関係… 旅行の7 6の例の応用… 8 6.1の情報センター… 8 6.2人の同盟者… 9 6.3 ゲートウェイ卸売業者… 9 7アーキテクチャ… 11 8つの要素… 12 8.1のITの管理ドメイン… 12 8.2ゲートウェイ… 13 8.3人のエンドユーザ… 14 8.4位置のサーバ… 14 9 要素相互作用… 16
Rosenberg & Schulzrinne Informational [Page 1] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[1ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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
9.1門と位置のサーバ… 16 位置のサーバへの9.2位置のサーバ… 16 9.2 .1 交換された情報の本質… 17 9.2 .2 サービスの品質… 18 9.2 .3 情報かかってください… 19 10、フロントエンド… 19 10.1 フロントエンド顧客… 19 10.2 フロントエンドプロトコル… 20 11の数の翻訳… 21 12のセキュリティ問題… 22 13の承認… 23 14図書目録… 23 15人の作者のアドレス… 24 16の完全な著作権宣言文… 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)の上のTelephonyルート設定のためのフレームワークとして機能します。IPはプロバイダーの間のIP電話技術ゲートウェイ経路指定テーブルの発見と交換をサポートします。 ドキュメントは、電話ルーティング交換の問題を定義して、プロトコルの必要性を動機づけます。 それは、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,
呼び出し装置: 呼び出し装置はIPの接続性がある物理的実体です。 それが電話をしたがっているエンドユーザの方向の下にあります。 エンドユーザは直接呼び出し装置を制御しているかもしれません。 呼び出し装置がPCであるなら
Rosenberg & Schulzrinne Informational [Page 2] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[2ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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.
エンドユーザは直接それを制御しています。 しかしながら、呼び出し装置が電話ゲートウェイであるなら、エンドユーザは電話を通してそれにアクセスしているかもしれません。
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].
サーバをちびちび飲んでください: [2]で定義されたSession Initiationプロトコルプロキシか再直接のサーバ。
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: Global Switched Telephone Network。(そのGlobal Switched Telephone Networkは世界的な回路交換網です)。
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.
シグナリングサーバ: シグナリングサーバは何らかのIP電話技術シグナリングプロトコルへのシグナリングメッセージを受け取って、送ることができる実体です、H.323やSIPのように。 概して、シグナリングサーバは、門番、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): 終わるのに使用できるゲートウェイに関する知識を持っているIPの接続性がある論理的な実体はGSTNに向かって呼びます。 LSはIPの上のTelephonyルート設定に参加する主な実体です。 一般に、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): ただ一つの職務権限のコントロールの下におけるリソース(ゲートウェイとLocation Servers)のセット。 エンドユーザは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.
同輩: 彼らに彼らの間のゲートウェイ情報が交換される永続的な協会があるとき、2LSのものは同輩です。
Rosenberg & Schulzrinne Informational [Page 3] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[3ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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のゲートウェイにルートを生成するLocation Server。
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
取引関係: ゲートウェイの所有者はゲートウェイをそれに接続したがっているどんなユーザにとっても利用可能にするとはほんとうは、ありそうもないです。 ゲートウェイは、役に立つサービスを提供して、回路交換網に向かって呼び出しを終了するとき、費用を被ります。 その結果、多くの場合、ゲートウェイのプロバイダーはそうしたくなるでしょう。
Rosenberg & Schulzrinne Informational [Page 4] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[4ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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)の上のTelephonyルート設定です。 TRIPは特定の関数群を提供します:
Rosenberg & Schulzrinne Informational [Page 5] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[5ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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電話技術ゲートウェイルーティング・プロトコルとしてTRIPをまとめることができます。
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:
高いレベルでは、TRIPが解決する問題はマッピング問題であるように見えます: 入力電話番号を考えて、いくつかの評価基準に基づいて電話ゲートウェイのアドレスを決定してください。 この理由で、ゲートウェイ位置問題はしばしば「IPアドレス変換問題への電話番号」と呼ばれます。 しかしながら、これは過剰簡素化です。「IPアドレス変換問題への電話番号」としてそれのすべてを分類できます。TRIPはその1つだけをそれを扱います。少なくとも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
PCが電話のためのインタフェースとして機能するところでこれらの3つのマッピング機能の最終はサービスの役に立ちます。 ユーザの電話が鳴るとき、そのようなサービスの1つはPCへのインスタントメッセージの配送です。 このサービスを提供するために、GSTNのスイッチは電話番号に向かって呼び出しを発送しています。 それはこのユーザのためにInstant MessageをPCに送りたがっています。 このスイッチはどうにかIPに近づく手段を持たなければなりません。
Rosenberg & Schulzrinne Informational [Page 6] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[6ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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の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.
これらのマッピングの2番目が伝統的な電話からIP端末までの呼び出しを容易にするのが必要です。 端末がIPネットワークにある状態でGSTNの上のユーザが、ユーザに電話をしたがっているとき、彼らは、その端末を特定する番号にダイヤルする必要があります。 この数はIPアドレスであるかもしれません。 しかしながら、IPアドレスはしばしばはかないです、DHCP[4]によって要求に応じて割り当てられるか、またはダイアルアップネットワークアクセス・サーバーでPPP[5]を使用して。 数は数のグループに関する何らかの翻訳で手紙に得られたホスト名であるかもしれません。 しかしながら、これは厄介です。 それは、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
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[6]などの相互ドメインIPルーティング・プロトコルの近いいとことしてTRIPを分類できます。 しかしながら、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は通常、隣接しているルータの間で稼働しています。
Rosenberg & Schulzrinne Informational [Page 7] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[7ページ]のRFC2871はフレームワーク2000年6月につまずきます。
o The information exchanged between TRIP peers describes routes
to application layer devices, not IP routers, as is done with
BGP.
o TRIP同輩の間で交換された情報はIPルータではなく、BGPと共に行われる応用層デバイスにルートを説明します。
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ルーティング情報を交換するサーバがこの情報に基づいて発送されるシグナリングメッセージの混載業者として機能する必要はないことを意味します。 これは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 TRIPの目的はすべてのITADsの向こう側にグローバルな接続性を確立しないことです。 そこに、TRIPの接続性の多くの小島であることが完全に妥当です。 各島は1つのクローズセットの管理関係を表します。 その上、各島はまだ全体のGSTNに完全な接続性を持つことができます。 これはBGPへの著しい対照中です。(そこでは、目標がインターネット中の完全な接続性です)。 ASの1セットが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名の部分を表す接頭語を交換します。 GSTN付番スペースの部分を表して、TRIPは電話番号範囲を交換します。 これらの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.
TRIPは、プロバイダーの間のIP電話技術ルートを交換するための汎用のツールです。 TRIPは何らかの方法でそれらのプロバイダーの間の関係の構造か本質を書き取りません。 その結果、TRIPには、IP電話技術のための多くのよくある例のアプリケーションがあります。
6.1 Clearinghouses
6.1 情報センター
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
情報センターのメンバーは、情報センターが他の多くのプロバイダーの間の交換ポイントとして機能するプロバイダーであると呼びました。 各メンバーは情報センターで雇われます。 協定の一部として、メンバーはそれらのゲートウェイを情報センターの他のメンバーにとって利用可能にします。 交換では、メンバーはそうしました。
Rosenberg & Schulzrinne Informational [Page 8] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[8ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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.
メンバーと情報センターの間のルートを交換するためのツールとしてTRIPをここに適用できます。 これは図1に示されます。
There are 6 member companies, M1 through M6. Each uses TRIP to send and receive gateway routes with the clearinghouse provider.
M6を通して6つのメンバー会社、M1があります。 それぞれが、情報センタープロバイダーでゲートウェイルートを送って、受け取るのにTRIPを使用します。
6.2 Confederations
6.2 同盟者
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はそれぞれの組のプロバイダーの間で稼働しているでしょう。
6.3 Gateway Wholesalers
6.3 ゲートウェイ卸売業者
------ ------
| | | |
| M1 | TRIP TRIP | M2 |
| |\ | | /| |
------ \ | | / ------
\ \ / -------------- \ / /
------ \----| |----/ ------
| | | | | |
| M3 |--------| Clearinghouse|--------| M4 |
| | | | | |
------ /----| |----\ ------
/ -------------- \
------ / \ ------
| |/ \| |
| M5 | | M6 |
| | | |
------ ------
------ ------ | | | | | M1| 旅行旅行| M2| | |\ | | /| | ------ \ | | / ------ \ \ / -------------- \ / / ------ \----| |----/ ------ | | | | | | | M3|--------| 情報センター|--------| M4| | | | | | | ------ /----| |----\ ------ / -------------- \ ------ / \ ------ | |/ \| | | M5| | M6| | | | | ------ ------
Figure 1: TRIP in the Clearinghouse Application
図1: 情報センターアプリケーションでつまずいてください。
Rosenberg & Schulzrinne Informational [Page 9] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[9ページ]のRFC2871はフレームワーク2000年6月につまずきます。
------ ------
| |------| |
| M1 | | M2 |
| |\ /| |
------ \ / ------
| \/ |
| /\ |<-----TRIP
------ / \ ------
| |/ \| |
| M3 | | M4 |
| |------| |
------ ------
------ ------ | |------| | | M1| | M2| | |\ /| | ------ \ / ------ | \/ | | /\ | <、-、-、-、--旅行------ / \ ------ | |/ \| | | 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 |
| | | | | |
------ ------ ------
------ | | | M1| | | ------ /\<。------- 旅行------ ------ | | | | | 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の両方からゲートウェイを転売することに注意してください。
Rosenberg & Schulzrinne Informational [Page 10] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[10ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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
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
多くのインターネットのTelephonyの管理ドメイン(ITADのもの)があります。それはそれぞれ、少なくとも1Location Server(LS)を持っています。 イントラドメインプロトコルと呼ばれるバンドで出ている手段で、LSのものはそれらのドメインのゲートウェイに関して学びます。 イントラドメインプロトコルは図にITAD1のGWとLS要素の間の系列によって表されます。 LSのものには、LSの他のものとの協会があります。(それらはゲートウェイ情報をそれと交換します)。 これらの協会は、行政上設立されて、ITの管理ドメインが適所にゲートウェイ情報の交換に関してある種の協定を持っていると、設立されます。 図では、ITAD1のLSはITAD2のLSに接続されます。(ITAD2は順番にITAD3のLSに接続されます)。 IP(TRIP)の上のTelephonyルート設定で、ITAD2のLSはITAD1の2門に関して学びます。 この情報はエンドユーザによってアクセスされます。
Rosenberg & Schulzrinne Informational [Page 11] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[11ページ]のRFC2871はフレームワーク2000年6月につまずきます。
(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.
フロントエンドを通したITAD2の(EU。) フロントエンドは、LSデータベースがアクセスされている非TRIPプロトコルかメカニズムです。 ITAD3に、EUとゲートウェイの両方があります。 ITAD3のLSはITAD1でゲートウェイに関してITAD2のLSからの潜在的に集められた広告で学びます。
8 Elements
8 Elements
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の管理ドメイン、エンドユーザ、ゲートウェイ、および位置のサーバを含んでいます。
8.1 IT Administrative Domain
8.1 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の管理ドメインはゼロか、より多くのゲートウェイか、少なくとも1Location Serverと、ゼロか、より多くのエンドユーザから成ります。 ゲートウェイと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が1セットの物理的に接続されたネットワークを代表している間、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の他のものにこの情報を他のゲートウェイに関して学んで、集めて、伝播して。
Rosenberg & Schulzrinne Informational [Page 12] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[12ページ]のRFC2871はフレームワーク2000年6月につまずきます。
8.2 Gateway
8.2 ゲートウェイ
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.
ゲートウェイには、それが提供できるサービスのボリュームを特徴付ける属性があります。 これらはそれが持っているポートの数(すなわち、それがサポートすることができる同時の電話の数)、およびアクセスリンク速度を含んでいます。 一緒にこれらの2はゲートウェイの容量の何らかの概念を表します。 Location Serversが、メートル法の値に比例して呼び出しをゲートウェイに発送すると決めるのを許容することのメートル法は役に立ちます、その結果、単純形のロードバランシングを達成します。
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.
また、ゲートウェイには、それが提供するサービスのタイプについて描写する属性があります。 サポートされたプロトコルに合図することでの特徴が提供した電話、コーデックが理解していたスピーチ、および実装される暗号化アルゴリズムに、含んでいますが、これは限られていません。 これらの属性はゲートウェイを選択するのにおいて重要であるかもしれません。 すべてのゲートウェイ(賞賛に値しますが、難しい目標)の向こう側の基線必要な特徴がないとき、1セットのそのような属性が、コミュニケーションを確立できるゲートウェイを選択するのに必要です。 要求(ある繰り上げ償還条項が、どのケースが支えられる必要があるかもしれないかでビジネスクラス呼び出しを要求するユーザなどの)のための決められた一定の要求を持っているエンドユーザはまた、そのような情報を利用したがっているかもしれません。
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によって合理的に処理されるのを許容する情報を提供します。
Rosenberg & Schulzrinne Informational [Page 13] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[13ページ]のRFC2871はフレームワーク2000年6月につまずきます。
8.3 End Users
8.3 エンドユーザ
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ネットワークがinterexchange輸送に使用されている状態で「電話をする電話」サービスと呼ばれることのためのそうです。
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はこれらの好みが最終的なゲートウェイ選択をもたらすためにどうプロバイダーのものに結合されるかを書き取りません。 また、TRIPはこれらの好みの輸送をLSにサポートしません。 この輸送はフロントエンドを使用することで達成されるか、またはいくつかの非プロトコル手段であることができます。
8.4 Location Server
8.4 位置のサーバ
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.
Location Server(LS)はTRIPの主な機能的な実体です。 Telephony経路情報基地(TRIB)は、それがゲートウェイに関するデータベースに近づく手段を持っている論理的なデバイスであると呼びました。 ゲートウェイに関するこのデータベースは、方針に基づく局所的に利用可能なゲートウェイのセットとリモートゲートウェイ(TRIPを通して学習される)のセットを合併することによって、構成されます。 また、LSはITADの他のところの同輩LSのものへの1セットのゲートウェイをエクスポートします。 エクスポートしているゲートウェイのセットは方針に基づく地方のゲートウェイのセットとリモートゲートウェイ(TRIPを通して学習される)のセットから構成されます。 そういうものとして、方針はLS操作で中心的役割を果たします。 情報のこの流れは図5に示されます。
Rosenberg & Schulzrinne Informational [Page 14] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[14ページ]のRFC2871はフレームワーク2000年6月につまずきます。
|
|Intra-domain protocol
\ /
Local
Gateways
| |イントラドメインプロトコル\/地方の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で確立された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には、少なくとも1LSが、TRIPに参加するためになければなりません。 ロードバランシングの目的、管理の容易さ、またはいかなる他の理由でも、ITADには、1LSがあるかもしれません。 その場合、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は、LSがイントラドメインプロトコルによってITADの中でゲートウェイに関して学ぶのを示します。 イントラドメインプロトコルがある必要はありません。 LSはどんな局所的に実行されたゲートウェイに関する知識なしでも作動するかもしれません。 または、それは、局所的に実行されたゲートウェイを知っていますが、静的な構成を通して知るかもしれません。 LSはそうするかもしれません、また、コレジデントになってください。それが、ゲートウェイ、どのケースでゲートウェイに関してコレジデントであることを知るだろうかに。
Rosenberg & Schulzrinne Informational [Page 15] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[15ページ]のRFC2871はフレームワーク2000年6月につまずきます。
9 Element Interactions
9 要素相互作用
9.1 Gateways and Location Servers
9.1 ゲートウェイと位置のサーバ
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はTRIPによって順番にさらにこの情報をITADの外に伝播するかもしれません。 この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つの方法がService Locationプロトコル(SLP)[7]をもってあります。 ゲートウェイはServiceエージェント(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ドメインまで異なるかもしれなくて、地方の構成の問題です。 また、1つ以上のイントラドメインプロトコルが特定のITADにあるかもしれません。 また、LSはイントラドメインプロトコルなしで機能できます。 それは、静的な構成を通してゲートウェイに関して学ばないか、どんな地方のゲートウェイも知らないかもしれません。
9.2 Location Server to Location Server
9.2 位置のサーバへの位置のサーバ
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によって定義されることです。 LSのものは、自分たちの中で情報を同期させるのに同じITADの中でTRIPを使用します。 LSのものは、方針に応じてゲートウェイ情報を交換するのに異なったITADsの中でTRIPを使用します。 前の場合では、内部の同輩、および後者のケース、外部の同輩でLSのものについて言及します。
Rosenberg & Schulzrinne Informational [Page 16] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[16ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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の1組のところの間の協会は行政上設立されます。 2LSのものは、彼らの管理者がいつゲートウェイ情報を交換するために適所に協定を持っているかを互いと伝えるために構成されます。 同輩LSのものが互いを発見するようにTRIPがautodiscovery手順を提供していない間、1つを使用できました。 クラッシュが起こるとバックアップが同輩LSであることがわかることのそのような手順は役に立つかもしれません。 あるいはまた、同輩の間の取引関係がさらに標準化されるようになる環境で、同輩はService Locationプロトコル(SLP)[9]のようなプロトコルを通して互いを発見できるかもしれません。 管理者の裁量には決断がautodiscoveryが使用されるべきであるか、または使用されるべきでないかどうかあります。
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のところの間の協会の上と交換されたメッセージの構文と意味論はTRIPによって書き取られます。 プロトコルは適所にあるに違いない協定の本質を決めません。 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は少しの特定保険証券も書き取りもしませんし、強制もしません。
9.2.1 Nature of Exchanged Information
9.2.1 交換された情報の本質
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のものによって交換された情報は1セットのルーティングオブジェクトです。 それぞれのルーティングオブジェクトはそれに達することができるゲートウェイに向かった「次に跳んでください」という応用層範囲であるさまざまな届いている電話番号と、IPアドレスかホスト名から最少量で成ります。 Routing objects are learned from the intra-domain protocol, static configuration, or from LS's in remote ITAD's. LSはこれらのルーティングオブジェクトに一緒に(それ自身のIPアドレス、またはLSが交信する予定であるシグナリングサーバのIPアドレスに電話番号の範囲を合併して、IPアドレスを置き換える)集めて、次に、別のLSに彼らを伝播するかもしれません。 どのオブジェクトを集めて、伝播したらよいかに関する決定はルート選択操作として知られています。 どのオブジェクトを集めて、伝播したらよいかを選択する際に管理者はかなりの緯度を持っています、正しいプロトコル操作の領域の中にそれらがある(すなわち、輪は全く形成されません)限り。 TRIPを通して、または、バンド手段からのいずれもを通して学習された情報に基づいて選択をすることができます。
Rosenberg & Schulzrinne Informational [Page 17] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[17ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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で指定されます。 ゲートウェイへの応用層ルートの集合は重要な問題です。 aggregatabilityとくどさの間には、基本的な見返りがあります。 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を知っています。 Z.Cには、結局、ただ一つのアドレスの範囲にXとYを結合できて、いくつかのオプションがあります。 それは、Aのためのまさしく広告、Bのためのまさしく広告を伝播するか、両方を伝播するか、それらを結合して、または集合広告を伝播できます。 この場合、Cは、同輩のひとりに後者のアプローチを選んで、単一のルーティングオブジェクトを送ります、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は呼び出しセットアップメッセージをDに送って、T.Dが決定するZ.As Dが取った範囲の中にアドレスTがある送付先アドレスを含んでいて、アドレスの範囲Zを含むCからのルーティングオブジェクトでありそれは呼び出しセットアップメッセージをC.に転送します。Cは、範囲Xの中にTがあるので、それが呼び出しシグナリングを終えるAに呼び出しセットアップを送って、電話網に向かって呼び出しを開始するのを順番に見ます。
9.2.2 Quality of Service
9.2.2 サービスの質
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
要素のいつゲートウェイを選択するのが、「QoS」であるかと考えるために役に立つ1つ--このゲートウェイを通した呼び出しは十分低い損失、遅れ、およびジターを受けるでしょうか? 呼び出しの品質を2つのコンポーネントに依存します--訪問者とゲートウェイの間の経路、およびゲートウェイ自体の容量(利用可能な回路の数、リンク容量、DSPリソースなどで、測定される)のQoS。 後者の決断は複雑な知識を必要とします。
Rosenberg & Schulzrinne Informational [Page 18] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[18ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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.
ネットワークtopologiesの基礎となって、訪問者がいるところについて見つけられています。 これは、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のものは呼び出しのロードバランシングの手段としてゲートウェイの中でメートル法でこれを使用できます。 また、入力としていかなる他の政策決定にもそれを使用できます。
9.2.3 Cost Information
9.2.3 コスト情報
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サービスがプロトコルの外で暴露される有形資産です。
10.1 Front End Customers
10.1 フロントエンド顧客
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について質問できます。 これで、彼らはそれらの要件の詳細な情報を提供できます。 そして、彼らはその電話番号に向かった次のホップシグナリングサーバかゲートウェイに連絡しに行くことができます。
Rosenberg & Schulzrinne Informational [Page 19] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[19ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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アドレスには呼び出しがあるかが、無関係です。 電話番号の場合におけるルーティングは透過的に行われます。 また、インタフェースを持っていないシンクライアント(スタンドアロンIP電話などの)か処理能力に、プロキシモードもLSのダイレクト質問のために有利です。
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の裁量にはそれがあります。それを利用する方法。 位置のサーバには、エンドユーザ好みがどう扱われるかに関するそれ自身の方針があるかもしれません。
10.2 Front End Protocols
10.2 フロントエンドプロトコル
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はフロントエンドのために可能性を指定もしませんし、制限もしません。 フロントエンドのための単本位制であることが必要であるか、またはそこに、望ましくさえある、明確ではありません。 様々なプロトコルには、彼らの長所と短所があります。 1つは、いくつかの場合における正しい解決と、異なった場合において別であるかもしれません。
Rosenberg & Schulzrinne Informational [Page 20] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[20ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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は、まさにこの種類の関数に合うように設計されています。 1セットの属性によって説明されたサーバの場所を見つけるのに、SLPは理想的です。 この場合、サーバはゲートウェイ(または、ゲートウェイに向かった次のホップ)です、そして、属性はエンドユーザ方針です。 エンドユーザはSLP UAです、そして、LSはSLP DAです。 Service Queryは、特定のセットの属性があるゲートウェイを求めるのに使用されます。
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): 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.
ウェブページ: LSには、ウェブフロントエンドがあるかもしれません。 ユーザは質問にフォームに入ることができました、そして、合っているゲートウェイは応答で戻りました。 しかしながら、人間のアクセスには、このアクセス機構は、より適切です。シグナリングサーバはウェブページを通しておそらくフロントエンドにアクセスしないでしょう。
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データベースにアクセスする実体が完全なコピーのそれを持つように。 このアプローチが望まれていたなら、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の市外局番を終えても構わないと思っているかもしれません。 もちろん、どんな電話番号に電話するかを構わないゲートウェイが、思っている決めるのは、管理者次第です。
Rosenberg & Schulzrinne Informational [Page 21] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[21ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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を引き起こす場合があるでしょうに。 これは重要なサービス不能攻撃を可能にします。 また、情報は他に伝播されるかもしれません。
Rosenberg & Schulzrinne Informational [Page 22] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[22ページ]のRFC2871はフレームワーク2000年6月につまずきます。
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.
別のものへの1LSを通してルーティングオブジェクトを渡すことができるように、また、認証を終わらせるある種の終わりの必要があります。 しかしながら、集合で、ルーティングオブジェクトを変更するでしょう、そして、したがって、認証は最後の集合のポイントから受信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.
作者はこのドキュメントの彼らの役に立つコメントについてランディ・ブッシュ、マーク・フォスター、デーヴ・オラン、フセイン・サラマ、およびマットSquireに感謝したがっています。
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] 国際電気通信連合、「展示は非保証されたサービスの質を提供するローカル・エリア・ネットワークのためにシステムと設備に電話をします」、Recommendation H.323、ITUのTelecommunication Standardization Sector、ジュネーブ(スイス)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.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、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.とデュガン、A.、エリオット、I.とHuitemaとC.とS.ピケット、「メディアゲートウェイコントロールは(MGCP)についてバージョン1インチ議定書の中で述べます、RFC2705、1999年10月。」
[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[4]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[5] Simpson, W., "The Point-to-Point Protocol (PPP)," STD 51, RFC
1661, July 1994.
[5] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[6] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
1771, March 1995.
[6]Rekhter Y.と1995年のT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[7] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
Location Protocol", RFC 2165, June 1997.
[7]VeizadesとJ.とGuttmanとE.とパーキンスとC.とS.キャプラン、「サービス位置のプロトコル」、RFC2165、1997年6月。
Rosenberg & Schulzrinne Informational [Page 23] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[23ページ]のRFC2871はフレームワーク2000年6月につまずきます。
[8] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[8]YeongとW.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1777、1995年3月。
[9] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[9] Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。
[10] Schulzrinne H. and J. Rosenberg, "SIP caller preferences and
callee capabilities", Work in progress.
[10]Schulzrinne H.とJ.ローゼンバーグ、「SIP訪問者好みと訪問される人能力」、進行中のWork。
[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] ヨーロッパのTelecommunications Standards Institute(ETSI)、Telecommunications、およびインターネットプロトコルHarmonization Over Networks(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
ジョナサンローゼンバーグdynamicsoft72Eagle Rock AvenueのFirst Floorの東ハノーバー王家、ニュージャージー 07936
Email: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングSchulzrinneコロンビア大学M/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027-7003
Email: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Rosenberg & Schulzrinne Informational [Page 24] RFC 2871 TRIP Framework June 2000
ローゼンバーグとSchulzrinneの情報[24ページ]のRFC2871はフレームワーク2000年6月につまずきます。
16. Full Copyright Statement
16. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg & Schulzrinne Informational [Page 25]
ローゼンバーグとSchulzrinne情報です。[25ページ]
一覧
スポンサーリンク
