本備忘錄的狀態
本備忘錄為Internet團體提供了相關信息，但并未規定任何形式的標準。本備忘錄的發
布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
摘要
本文介紹了一種ip電話路由（TRIP）的框架，它為供給商提供了相互之間發現和交換
IP電話網關路由表的支持。文檔定義了IP電話路由交換的問題以及協議需要的動機。文中
介紹了一種TRIP體系結構框架，定義了術語，規定了不同的協議元素及其功能，概述了協
議提供的服務，并討論了如何將其應用于更廣泛的Internet電話中。

目錄
1．簡介 2
2．術語 2
3．動機與存在的問題 3
4．相關問題 4
5．與BGP的關系 5
6．TRIP應用舉例 5
6.1Clearinghouses-交換中心 5
6.2Confederations-聯邦 5
6.3GatewayWholesalers-網關批發商 6
7．體系結構 7
8．基本要素 8
8.1ITAD 8
8.2網關 9
8.3端用戶 9
8.4區域服務器 9
9．要素間的交互 10
9.1網關與區域服務器交互 10
9.2區域服務器之間的交互 10
10．前端 12
10.1前端客戶 12
10.2前端協議 13
11．號碼翻譯 13
12．安全考慮 14
13．鳴謝 14
14．參考資料 14
15．作者地址 15
16．版權聲明 15
致謝 16
1．簡介
本文檔介紹了一種IP電話路由（TRIP）的框架，它為供給商提供了相互之間發現和交換
IP電話網關路由表的支持。文檔定義了IP電話路由交換的問題以及協議需要的動機。文中提
出了一種TRIP體系結構的框架，定義了術語集合，規定了不同的協議元素及其功能，概述了
協議提供的服務，并討論了如何將其應用于更廣泛的Internet電話中。
2．術語
我們定義了如下的術語，注重：這些術語在網關領域以外可能還有其它定義，因此我們的定
義不是通用的，僅在此有特定含義：
網關（Gateway）:連接電路開關網絡和IP網絡的設備，可以發起和結束IP電話信令
協議，并發起和結束電話網絡信令協議。
端用戶（EndUser）:端用戶是呼叫的發起方或者接受方，可能是人，也可能是設備。
呼叫設備（CallingDevice）:呼叫設備是一個有IP連接性的物理設備，處于控制呼叫
的端用戶管轄之下。假如呼叫設備是PC機，則端用戶可以直接控制它；假如呼叫設備是電
話網關，則端用戶只能通過電話來訪問它。
關守（Gatekeeper）:H.323關守，定義于[1]。
會話初始協議服務器（SIPServer）:會話初始協議代理或重定向服務器，定義于[2]。
呼叫代理（CallAgent）:MGCP呼叫代理，定義于[3]。
全球開關電話網（GSTN）:GSTN是全球電路開關網絡。
信令服務器（SignalingServer）:信令服務器功能是為IP電話信令協議接收和發送信令
消息，如H.323或SIP。通常，信令服務器是一個關守，SIP服務器，或者呼叫代理。
區域服務器（LocationServer(LS)）:一個具有IP連接性的邏輯設備，可以知道那些網
關可用于終止對GSTN的呼叫。LS是參與TRIP的主要設備，通常是端用戶完成與電話網
絡呼叫的聯系點。它也負責向其它LS傳播網關信息。LS可以同H.323關守或SIP服務器共
存。
Internet電話治理域（InternetTelephonyAdministrativeDomain(ITAD)）:單個治理機構
控制下的資源集合（網關和區域服務器）。端用戶是ITAD的客戶。
提供商（PRovider）:ITAD的治理員。
區域服務器策略（LocationServerPolicy）:區域服務器處理通過TRIP發送和接收信息
的規則集。其中包括聚集，傳播，產生和接受信息的規則。
端用戶策略:關于到GSTN的呼叫如何路由的端用戶收選項。
對等體（Peers）:當兩個LS有穩固聯系，能夠交換網關信息時，它們就構成對等體。
內部對等體（Internalpeers）:對等體的兩方位于同一個ITAD。
外部對等體（Externalpeers）:對等體位于不同的ITAD。
源區域服務器（OriginatingLocationServer）:ITAD中第一個產生到網關的路由的區域服務
器。
電話路由信息庫（TelephonyRoutingInformationBase(TRIB)）:LS建立的網關數據庫，
用于保存TRIP的參與結果。
3．動機與存在的問題
隨著IP電話網關數量和使用的增加，對它們操作的治理也越來越復雜。其中最困難的問
題就是網關定位，也叫做網關選擇，路徑選擇，網關發現和網關路由。當呼叫設備要呼叫一
個開關電路網絡中的終端電話號碼時就會出現這一問題。由于目標位于開關電路網絡，并且
呼叫者是從一個IP宿主機上發起呼叫，因此必須使用電話網關。網關作為媒體和信令的轉
換點，負責在IP網絡協議和電路開關網絡協議之間進行轉換。
網關在本質上是應用層信令協議的接力點。由于有很多網關都可以完成由IP網絡的呼叫
設備到電路開關網絡用戶的呼叫，從中選擇一個網關并不是一項簡單的工作。以下原因使得
這一過程很復雜：
候選網關數量：由于IP電話的廣泛應用，連接Internet和GSTN的電話網關的數量也
很龐大。連接到GSTN上意味著網關同該網絡的數十億終端建立了連接性。這就是說每個
網關都在理論上可以完成到GSTN上任何終端的呼叫。同樣地，候選網關的數量也非常龐
大。
商業關系（BusinessRelationships）:事實上，網關的治理者未必想讓任何人都能隨心
所欲地使用網關。網關提供了一定的服務，并在完成到電路開關網絡時要進行一定的開銷。
因此，網關的提供商需要對網關的使用收費。此舉就限制了網關供給商的客戶對網關的使用。
供給商策略（ProviderPolicy）:要訪問網關的端用戶多半都不是直接向網關提供商付
費，而是同IP電話服務供給商建立聯系，并由后者作為到網關的中間人。IP電話服務提供
商自己也可以擁有網關。這時，IP電話服務供給商就要根據客戶對來自其它供給商的各種
網關的使用建立一定的策略。選擇過程要考慮這些策略。
端用戶策略（EndUserPolicy）:在某些情況下，端用戶也可根據網關選擇提出特定需
求。他可能需要能夠提供非凡服務的供給商，或者有自己的首選供給商。這些都要作為計費
的環節。
容量（Capacity）:網關并不是完全相同的。有些大，支持成百上千的并發請求。有些
住宅區網關，則只支持1到2路呼叫。選擇網關的過程應該考慮到網關的容量。非凡地，要
根據網關的容量采取一定的負載均衡措施。
協議和特征兼容性（ProtocolandFeatureCompatibilities）:呼叫方可能使用某些網關不支持
的專用信令或媒體協議。
根據以上討論，很明顯，網關的選擇要受到很多因素的驅動，包括不同團體的策略，以及它
們相互間的關系。因此，不可能有一個全局的“網關目錄”供用戶查詢。此外，網關的可用
性信息交換必須由供給商完成，并且服從于選擇策略，首先在本地可用，然后再傳播給其它
供給商。這就答應每個供給商建立自己的本地可用網關數據庫-根據每個供給商的策略不同。
因此我們得出結論，在治理域之間進行網關路由信息交換需要一個專用協議。提供這些
功能的協議就是TRIP。TRIP功能如下：
o建立和維護供給商之間的對等關系；
o在供給商之間交換和同步電話網關路由信息；
o保護IP電話信令協議的穩定路由循環；
o及時并以可縮放形式向其它供給商傳播網關路由信息；
o定義描述電話網關路由的語法和語義。
總之，TRIP是一個域間IP電話網關路由協議。
4．相關問題
TRIP解決的高層問題主要是映射：給定一個電話號碼，根據規則判定電話網關。因此，
網關定位問題常稱為“電話號碼到IP地址轉換問題”。當然，這是一個相當簡化的說法，
其中至少應包括3個單獨的問題，它們統一歸類為“電話號碼到IP地址轉換問題”，但只
有一個是通過TRIP尋址：
o給定一個電路開關網絡的終端電話號碼，判定能夠完成呼叫的網關的IP地址。
o給定Internet上一個特定主機（為了便于從電路開關網絡呼叫，該主機有一個電話
號碼）的電話號碼，判定其IP地址。
o給定電路開關網絡的終端用戶的電話號碼，判定該用戶擁有的IP終端的IP地址。
最后一個映射主要用于PC服務器作為電話接口的場合。其中一項服務就是當用戶的電
話響鈴時向PC發送一條即時消息。為了發送該服務，GSTN的交換機要向電話號碼路由一
個呼叫。它希望能為用戶向PC機發送一個即時消息。交換機必須能訪問IP網絡，判定電
話號碼用戶PC機的IP地址。映射函數要解決名稱到地址的轉換，名稱由一串數字表示。
目錄協議能最好地支持這樣的轉換。TRIP不解決該問題。
第二個映射主要用于處理從傳統電話到IP終端的呼叫。當GSTN用戶想呼叫IP網絡的
一個終端用戶時，他需要撥終端的號碼。該號碼可以是IP地址，但由于IP地址多通過DHCP[4]
分配或撥號網絡訪問服務器通過PPP[5]分配，所以往往是暫時的。該號碼也可以是主機名，
通過一些翻譯方法可以將號碼變為字符串，但這樣也很麻煩。因此建議為每個IP電話終端
分配一個電話號碼。GSTN用戶可以直接撥號。和主機名一樣，該號碼也作為IP終端的別
名。GSTN交換機必須能訪問IP網絡，并得到號碼到主機IP的映射。正如前面的例子，該
問題是名稱到地址的轉換問題，也由目錄協議處理，不屬于TRIP的范疇。
第一種映射是一個基本的地址到路由的轉換問題。屬于TRIP要考慮和處理的對象。正
如第三節所討論的，這一映射取決于本地因素，比如策略和供給商關系等。因此，對于每個
供給商而言，可用的本地網關數據庫不盡相同，并要通過特定的供給商關系來建立。正由于
這個原因，盡管可以更好的處理另外兩個映射問題，目錄協議處理該映射問題不如TRIP協
議。
5．與BGP的關系
TRIP可歸類為域間路由協議的近親，如BGP[6]。不過，兩者之間還是有很重大的區別：
oTRIP運行在應用層，而不象BGP在網絡層。
oTRIP運行在許多中間網絡和IP服務供給商分隔的服務器之間。BGP則在鄰近的路
由器之間。
oTRIP對等體之間交換的信息描述了到應用層設備的路徑，而不象BGP是IP路由器。
oTRIP假定存在底層的IP傳輸網絡。這意味著交換TRIP路由信息的服務器不需要
轉發信息路由的信令消息。而在BGP中卻非如此，對等體必須作為IP包的轉發點（或為一
個相鄰跳命名）。
oTRIP的目的不是建立跨ITAD的全局連接。但建立到許多TRIP小島的連接卻是非
?？尚械?。每個小島表示一個治理關系閉包。此外，每個島都有到GSTN的全連接。這同
BGP形成了鮮明對比，BGP的目標是通過Internet的全連接。假如由于BGP斷連，一個AS
從其他中分離出來，則它們之間就沒有任何IP網絡連接了。
o由于位于應用層，而不是網絡層，網關路徑比IP路由復雜得多，用于描述的參數
也多的多。
oBGP交換代表IP命名空間的部分前綴。TRIP交換電話號碼區，表示GSTN編碼空
間的一部分。兩種命名空間的組織和層次均不相同。
這些區別說明TRIP從BGP借鑒了很多方法，但也有很多自己的特征，與BGP是不同
的協議。
6．TRIP應用舉例
TRIP是用于交換IP電話路徑的工具，但并沒有規定供給商之間的關系結構。因此，有
很多針對各種IP電話用例的TRIP應用。
6.1Clearinghouses-交換中心
一個clearinghouse是作為稱為clearinghouse成員的其它供給商交換節點的供給商。每個
成員要在clearinghouse注冊。作為協議的一部分，成員要將其網關向其它成員開放。在交
換時，成員可以訪問其他成員擁有的網關。當一個成員的網關產生呼叫時，clearinghouse在
決定由哪個成員來終止呼叫時要起要害作用。
在此，TRIP可作為成員之間交換路徑的工具，如圖1所示。
圖中有6個成員公司，M1到M6。每個成員都利用TRIP同clearinghouse供給商之間發
送和接收網關路徑。
6.2Confederations-聯邦
我們將視為一組供給商，他們遵循彼此之間以全交叉方式共享網關的協議，而不用通過
中心clearinghouse。這樣的配置見圖2。每對TRIP之間都運行TRIP。
6.3GatewayWholesalers-網關批發商
------------

M1TRIPTRIPM2
//
------//------
///--------------///
------/--------/------

M3--------Clearinghouse--------M4

------/--------/------
/--------------/
------//------
//
M5M6

------------


圖1:交換中心應用中的TRIP
------------
------
M1M2
//
------//------
//
//<-----TRIP
------//------
//
M3M4
------
------------


圖2:聯邦形式的TRIP

在本應用中，有大量的電話網關大型供給商。每個都向中等規模的供給商轉售其業務。
依次，直到轉售給為用戶提供直接服務的本地供給商。圖3表示了這種高效的金字塔關系：
------

M1

------
//<-------TRIP
------------

M2M3

------------
////
------------------

M4M5M6

------------------

圖3:批發商模式的TRIP

注重在該例中，M5同時從M2和M3購買網關。
7．體系結構
圖4給出了TRIP的體系結構。

ITAD1ITAD2
-----------------------------------

--------
GWEU
----/--------/----
LS----------------LS
--------/----/----
GW//EU
----/----
/
------------------/------------------
/
/
---------/----------

----
LS
/----/
--------
GWEU
--------
--------
GW//EU
--------

---------------------
ITAD3

圖4:TRIP體系結構

網絡上有許多ITAD(InternetTelephonyadministrativedomain),每個ITAD至少有一個區
域服務器。這些區域服務器，通過稱為域內協議的帶外方式了解域內網關的信息。圖中
ITAD1，域內協議用GW和LS元素之間的連線表示。這些區域服務器可以同其他區域服務
器聯合，通過這種方式交換網關信息。首先由IT治理者簽訂一些適于交互網關信息的協議，
然后通過治理手段建立起這些聯合。在圖中，ITAD1的LS聯到了ITAD2的LS，ITAD2的
LS又依次聯到了ITAD3的LS。通過TRIP，ITAD2的LS可以了解ITAD1上的兩個網關。
這些信息由ITAD2上的終端用戶透過前端（front－end）進行訪問。這個前端是一個非TRIP
協議或訪問LS數據庫的裝置。在ITAD3中，既有終端用戶，又有網關。ITAD3的LS通過
ITAD2上LS的宣傳來了解ITAD1上的網關。
8．基本要素
圖4的體系結構中包括下列元素：ITAD，端用戶，網關，區域服務器。
8.1ITAD
一個ITAD由局域服務器（至少一個）、網關（零個或多個）和終端用戶（零個或多個）
組成。網關和局域服務器是在單一權威組織的行政治理之下的。這意味這只有一個權威負責
制訂策略和配置網關和局域服務器。
一個ITAD不同于一個自治系統。AS描述物理連接的網絡，而ITAD可以由完全不同
的網絡上的要素組成，甚至在不同的AS治理之下。一個IT治理域的終端用戶是他的有效
客戶。他們希望完成通向電話網的呼叫，并且需要訪問網關。在一次呼叫中，端用戶可以是
一個ITAD的客戶，在下一次呼叫中又是另一個IT治理域的客戶。
一個ITAD可以沒有網關。這時局域服務器要了解其他域的網關，使這些網關可為它的
域內的終端用戶使用。于是ITAD就成為一個有效地虛擬IP電話網關的供給商。因為它能
提供網關服務，卻不必真的擁有或治理網關。
一個IT治理域也可以沒有端用戶。這時它可以提供“批發”網關服務，為其他IT治理
域里的顧客提供網關服務。
一個IT治理域可以既沒有網關也沒有端用戶。這時的ITAD中只有局域服務器，ITAD
扮演轉售商的角色，了解其他網關，然后綜合并將這些信息傳播給其他有顧客的ITAD.
8.2網關
網關是一個邏輯裝置，既有IP連通性，又與其他網絡（通常是共有或私人電話網）連
通，網關的功能是將一種網絡的媒體和信令協議轉換為另一種，為系統用戶實現透明連接。
網關有許多屬性標志它所提供的服務。這些屬性中最基本的是它所提供服務的電話號碼
范圍。這個范圍可以分為幾個段，彼此之間以一些耗費度量參數和耗費標記聯系。標記可以
標示出這部分電話號碼范圍呼叫的消費或愛好傾向。有些屬性標志網關所提供的服務量。其
中包括它所擁有的端口數（它所能支持的同時呼叫的數量）和訪問速度。這兩個屬性共同標
志了網關的容量。該度量可幫助局域服務器根據度量值按比例決定路由，從而實現簡單的負
載平衡。
網關也有些屬性標志它所提供的服務類型。其中包括支持的信令協議、提供的電話特征、
可識別的語音編碼和實現的加密算法等。這些屬性對于選擇網關是很重要的。在缺乏對所有
網關特征基線標準的情況下（這是一個美好但很難達到的目標），為了選擇一個網關完成通
信，我們需要這樣一組屬性。對呼叫有非凡要求的終端用戶（例如：一個用戶需要商業類呼
叫，這種呼叫需要一些特定呼叫特征的支持）也希望利用這些信息。
在TRIP上，有些屬性用來描述網關，另一些屬性則不是。這取決于度量能否被合理的
綜合，以及呼叫建立之前是否還要傳遞一些屬性（同信令協議本身的協商和交換相對）。TRIP
的思想是保持簡潔，支持大量信息的縮放性。TRIP的屬性設置是輕易擴展的。一些標記允
許局域服務器處理未知屬性。
8.3端用戶
端用戶通常是一個希望通過網關完成從IP網到電話網終端呼叫的實體（通常是人）。終
端用戶可以是登錄到有Internet電話軟件的PC機的用戶，也可以是通過入口電話網關連接
到IP網上的電話用戶。這就是我們提到過的“電話到電話”服務，IP網絡用于交換傳輸。
當終端用戶完成一次到電話網呼叫時，他們可能知道，也可能不知道有電話路由服務正
在運行。在終端用戶知道的情況下，他們可以選擇呼叫完成的方式。這些選擇包括，必須支
持的特征、質量度量、所有者或者治理者和耗費選擇等。
TRIP既不指定這些選擇如何與提供商的選擇聯合決定最終網關，也不支持這些選擇傳
遞到LS。使用前端或者用一些非協議方法可以完成這種傳輸。
8.4區域服務器
局域服務器(LS)是TRIP的主要功能實體。它是一個訪問網關數據庫的邏輯設備，這個
數據庫稱為電話路由信息庫(TRIB)。網關數據庫由可用的本地網關和一些基于策略的遠程網
關構成。LS也為其他ITAD網中的對等LS輸出網關集合。這組輸出的網關由本地網關和基
于策略的遠程網關（通過TRIP了解）構成。同樣，在LS操作中策略扮演了核心的角色。圖
5所示為這種信息流。

Intra-domainprotocol
//
Local
Gateways

TRIP-->GatewaysPOLICYGateways-->TRIP
INOut

//
TelephonyRouting
InformationBase
圖5:TRIP信息流
LS中建立的TRIB答應它決定IP電話呼叫路由，當一個去往電話網地址的信令消息到達信
令服務器時，LS的數據庫能提供的信息可幫助它判定將信令消息轉發給哪一個網關或附加
信令服務器?；谶@個原因，LS可與信號服務器合一。假如不在一起，則他們之間需要一
些通信方法。這些通信不是由TRIP來尋址的，盡管TRIP可以滿足這樣的協議的需求。
要想參與TRIP，ITAD中至少得有一個LS。出于負載平衡，治理方便或者一些其他原因，
ITAD可以有多個LS。這時，為了實現數據庫同步和共享其他外部同級服務器信息，在這些
LS之間也要進行一些通信。通常這種通信作為域間協議的內部組件。TRIP就包含這樣的功
能。
圖5顯示了LS正通過域內協議了解ITAD內的其他網關。其實沒必要有域內協議。LS運行
時可以不用了解任何運行的本地網關?；蛘?，它可以通過靜態配置了解運行的本地網關。
LS也可以與網關在一起，這樣它就要了解與它在一起的網關。
9．要素間的交互
9.1網關與區域服務器交互
網關必須以某種方式向同一個ITAD內的LS散播他的特征信息。LS可以進一步通過TRIP
將這些信息傳播到ITAD外。該LS稱為該網關的源LS。當LS與網關不在一起時，信息的傳
播方式不屬TRIP的范疇。完成這一功能的協議稱為域內協議。
信息散播的一種方式是使用服務定位協議。網關可以包含一個服務代理，LS可以作為
目錄代理。服務定位協議規定了服務信息自動由DA傳播到SA的步驟。通過這種方式，LS
可以了解ITAD中的網關。
另一種域內協議的機制是通過SIP或者H.323的注冊過程。注冊過程提供了一種方法，
用戶可以通知關守或SIP服務器他們的地址。這一注冊程序可擴展為答應網關有效地注冊。
LDAP[8]也可用作域內協議。網關利用LDAP為自己添加一條記錄到數據庫。假如LS也
要作為LDAP服務器，那么它就能了解所在ITAD上的所有網關。
不同的ITAD可以使用不同的域內協議，域內協議屬于本地配置。在一個特定的ITAD
中可以有多個域內協議。沒有域內協議，LS照樣可以工作。它可以通過靜態配置了解網關，
或者可以不了解任何網關。
9.2區域服務器之間的交互
LS間的交互由TRIP定義。同一個TRIP內的LS使用TRIP來同步信息。不同LS內的LS根據策略使
用TRIP來交換網關信息。前者中LS作為內部對等體，后者中為外部對等體。
LS之間通過固定連接進行通信。一個LS可以連接到一個或多個LS。LS不必物理上相
鄰，也不必在同一個自治系統內。一對LS間的聯系通常是以治理手段建立。首先兩個LS
的治理員要就交換網關信息達成適當的協議，然后他們就配置為彼此之間可以通信。TRIP
并不提供LS間彼此查找的自動搜索程序。當發生崩潰時，這樣的程序可以用來發現對等備
份LS。在對等體商業關系變得更加標準化的環境中，對等體間可以通過象SLP等協議相互
查找。是否使用自動搜索由治理員決定。
通過LS聯合交換的信息的語法和語義由TRIP規定。協議沒有規定協定合適的種類。TRIP
僅提供傳輸方式交換系統治理員認為合適網關路由信息。在TRIP規范中有具體說明。
控制網關信息產生、傳播、接受的規則稱為LS策略。TRIP沒有規定或要求任何特定策
略。
9.2.1交換信息概述
LS交換的信息是一組路由對象。每個路由對象至少包含可達的電話號碼范圍和IP地址
或主機名（向可到達該范圍網關的應用層下一跳）。路由對象可通過域內協議、靜態配置或
者遠程ITAD的LS來了解。LS可以將這些路由對象聚合到一起（合并電話碼的范圍，用自
己的或與LS通信的信令服務器的IP地址代替那些IP地址，）然后傳播給另一個LS。決定
哪一個對象進行聚合和傳播稱為路由選擇操作。治理員在決定對哪一個對象進行聚合和傳播
上有很大的選擇自由，只要他們在正確的協議操作范圍內（無回路形成）。選擇可以基于通
過TRIP了解到的信息，或者任何其他帶外方式。
路由對象可以有表述網關服務特征的附加信息。這些屬性包括協議、支持特征和容量等
等。屬性越多可以提供有益的信息就越多，但是，它們也會帶來開銷。越來越多的信息會使
集合操作變得困難，嚴重影響協議的伸縮性。
聚合在TRIP中起核心的作用。為了提高伸縮性，路由對象在傳播之前可以聚合為更大
的集合。TRIP中描述了這種機制。應用層的集合路由到網關并不是一個簡單的問題。在聚
合和冗長之間存在著基本的權衡。TRIP路由對象中信息越多，聚合就越困難。
考慮一個兩個網關的簡單例子。網關A和B分別可以到達電話號碼區X和Y，。C是A、
B所在ITAD中的一個LS。C通過一些方法了解A和B。當他工作時，X和Y被合并為一個單
一地址范圍Z。C有幾個選項。它可以散播A的信息，也可以散播B的信息，也可以同時散
播A和B，或者將他們合并然后再散播。在本例中，C選擇后一種方式，發送一個路由對象
到一個對等體D，其中包含地址范圍Z和它自己的地址，由于它也是一個信令服務器。D也
是一個信令服務器。
呼叫裝置E希望撥一個電話號碼T,該號碼恰巧在地址范圍X內。E被配置使用D作為他
的默認H.323關守。于是E發送一個呼叫建立信息給D，其中包含目的地址T。D判定出地
址T在Z內。由于D已經接受了一個來自于C的包含地址范圍Z的路由對象，它將呼叫建立
消息轉發給C。接著，C發現T在地址范圍X內，于是它繼續將消息發到A，A結束呼叫信令
并向電話網發起一個呼叫。
9.2.2服務質量
當選擇網關時，一個值得考慮的因素是服務質量（QoS），即呼叫通過這個網關所經歷的
損失、延時和波動等。呼叫的質量取決于兩個因素：呼叫者和網關之間路徑上的服務質量和
網關本身的能力（衡量可依據電路門數、鏈路容量、DSP資源等等）。后者的確定需要復雜
的底層網絡拓撲知識和呼叫者定位知識。這些因素由QoS路由協議控制，不屬于TRIP的范
圍。
但是，網關容量不靠呼叫者的位置或者路徑特征。因此，TRIP支持一些形式的容量度
量。這種度量表述了網關的靜態容量，而不是網關工作期間不斷變化的動態可用容量。LS
可用該度量作為網關間對呼叫負載平衡的手段。它也可用作對任何其他策略判定的輸入。
9.2.3費用信息
對傳播的另一個有用屬性是費用度量。它可以表示為一個特定的網關對呼叫的收費。它
可以是一個到根據預先存在的商業協議而定義了價格結構的表的索引，或者它本身就表示了
費用。TRIP本身不定義價格度量，但可以且應該作為一個擴展定義。使用一個價格擴展意
味著可以定義更多的度量。
10．前端
作為TRIP的一個結果，LS建立了一個網關路由的數據庫（即TRIB）。這些信息被ITAD
中各種實體所利用。這種將信息加工成可用的方法稱為前端。通過這種明顯的方式TRIP服
務被暴露在協議外。
10.1前端客戶
目前有以下幾種實體（可能不止這幾種）會使用前端來訪問TRIB：
信令服務器：信令服務器接受信令消息（例如H.323或者SIP消息），這些消息用于初
始化IP電話呼叫。這些呼叫的目的地址可以是一個與GSTN終端相對應的電話號碼。為了將
這些呼叫路由到一個合適的網關，信令服務器需要訪問建在LS上的數據庫。
端用戶：端用戶可以直接查詢LS取得路由信息。此舉答應他們提供需求的細節信息。
然后，他們可以聯系通往被呼叫電話號碼的下一跳信令服務器或者網關。
治理員：治理員需要訪問TRIB來完成維護和治理功能。
當一個信號服務器聯系LS路由電話號碼時，它通常正在這么做，因為呼叫設備（代表
端用戶）已經嘗試要建立一個呼叫。結果，信令服務器作為端用戶的代理高效地訪問LS數
據庫。呼叫設備和他們的代理人（信令服務器）之間通過信令協議通信。
這種代理方法的優點是使真實的LS交互對于呼叫設備隱藏起來。因此，不管呼叫是電
話號碼還是IP地址都無所謂。假如是電話號碼，則路由透明地發生。代理模式令一個優點
是方便了瘦客戶端，因為它們沒有接口或者處理能力直接查詢局域服務器（例如：單獨的
IP電話）。這種代理方法的優點同樣也是它的缺點-真實的LS交互對于呼叫設備（即端用戶）
隱藏起來了。在某些情況下，端用戶需要知道呼叫如何被路由，包括花費、質量、治理員、
或者呼叫服務和協議。這些需求稱為端用戶策略。在代理方法中，用戶能通過信令協議高效
地訪問服務。信號協議不可能為端用戶支持復雜的呼叫路由首選項的表述。（注重：SIP可
以為呼叫路由支持一些形式的呼叫者首選項。）因此，由端用戶直接訪問局域數據庫可以提
供更豐富的呼叫路由服務。當端用戶策略被提交到LS時（或者直接或者通過信令協議），LS
判定如何使用它。LS有它自己的策略來處理端用戶首選項。
10.2前端協議
有許多協議可用于前端訪問LS數據庫。TRIP不指定或限制對于前端訪問的可能性。目
前并不清楚是否應該制定一個單一的前端訪問標準。每個協議各有優缺點。有些適用于一些
場合，而另一些則適用于其它場合。
當前的前端協議有：
ServiceLocationProtocol(SLP):服務定位協議，SLP設計為可以精確地滿足這種
功能。SLP對于由屬性集描述的定位服務器非常理想。這時服務器是一個網關，或者通向網
關的下一跳，而屬性則是端用戶策略。端用戶是一個SLPUA，并且LS是一個SLPDA。服務查
詢（ServiceQuery）用于通過特定屬性集尋找網關。
OpenSettlementsProtocol(OSP):開放結算協議，OSP[11]是一個客戶/服務器協
議。它答應客戶通過電話號碼查詢服務器，并得到下一跳的地址，以及用于呼叫的認證令牌。
此時，服務器可以是LS。響應OSP查詢的路由表就是用TRIP建立起來的。
LightweightDirectoryaccessProtocol(LDAP):輕量目錄訪問協議，LDAP用于訪
問分布式數據庫。由于LS上有數據庫，LDAP可以用來進行查詢。
WebPage:Web頁面，LS也可以有Web前端。用戶可以將查詢輸入form，響應中就返回
匹配的網關。這種訪問機制更適合于人直接訪問。不過信令服務器可不喜歡通過Web頁面來
訪問前端。
TRIP:前面討論的協議都是關于查詢響應類型。至于為什么LS訪問必須是這種形式并
沒有什么理由。通過完全數據庫同步訪問也是可以接受的，這樣一來，訪問LS的實體就有一
個完全的備份。雖然這種方法有明顯的缺點，不過不妨礙具體實施。
11．號碼翻譯
TRIP模型有許多網關，每個網關都可以完成通往一些電話號碼集的呼叫。通常，這些
電話號碼集按照在地理上與網關相近來劃分的。例如。一個紐約的網關可以完成區號為212
到718的呼叫。當然，實際上是治理員決定那些號碼由那個網關完成。
但是，某些電話號碼根本不是GSTN終端，而是服務或者虛擬地址。例如：免費電話和
LNP。在電話網絡中，它們被真實的映射到可路由的電話號碼，通常都要基于復雜的公式。
典型的例子是基于time-of-day的轉換。
由于沒有什么措施可以保護網關不受到這種號碼的廣告可達性的影響，因此不鼓勵采用
這種用法。TRIP是一個路由協議，它傳播的路由應該是可路由號碼，不是最終轉化為可路
由號碼的名字。當TRIP用于傳播到達這些號碼的路由的時候，會產生很多問題：
? 通常，這些號碼僅在局部有意義。從紐約呼叫一個免費電話可以終結于紐約某個公
司的辦公室，從加利福尼亞呼叫的僅可以在加利福尼亞完成。假如這個免費電話在
紐約通過網關接入TRIP，它將被傳播到加利福尼亞端用戶使用的LS。假如使用了
這個路由，則呼叫可能無法按照用戶的意愿進行。
? 呼叫信令路徑可能遠遠達不到最佳。設想一個在紐約的網關廣告一個映射到加利福
尼亞的電話的端口號碼。該號碼由TRIP傳播，最終被加利福尼亞端用戶使用的LS
了解。當一個用戶撥這個號碼時，呼叫由IP網絡路由到紐約，找到符合的網關，
然后由GSTN路由返回加利福尼亞。這樣做十分浪費資源。假如網關路由功能啟用
之前端口號碼已經被轉換，就可以直接訪問加利福尼亞的網關。
因此，在LS路由數據庫訪問之前完成這些特定號碼的轉換應該更高效。怎樣完成這一
轉換不屬于TRIP的范圍。它可以由呼叫設備在在呼叫之前完成，或者在訪問LS數據庫之前
由信令服務器完成。
12．安全考慮
安全是TRIP的重要組成部分。TRIP模型假設交換信息的對等LS之間相互信任的。這
些消息被用于傳播確定呼叫路由的信息。假如信息是錯誤的，將導致一個錯誤的路由。這會
造成一種嚴重的拒絕服務攻擊。這些信息也可以被傳播到其他的ITAD，致使問題潛在的擴
散。結果，對等LS的相互認證是很要害的，而且，信息的完整性也要保證。
TRIP消息可以包含潛在的敏感信息。他們表示了一個ITAD的路由容量。這樣的信息可
以被競爭對手利用來判定ITAD網絡的拓撲和容量。因此，TRIP也支持消息加密。
由于路由對象可以在LS間傳遞，也需要某種形式的端到端認證。但是聚合會導致路由
對象改變，因此認證只能從接收LS的最后一個聚合點開始進行。
13．鳴謝
感謝RandyBush,MarkFoster,DaveOran,HusseinSalama,和MattSquire為本文提出的有
益見解。
14．參考資料
[1]InternationalTelecommunicationUnion,"Visualtelephonesystems
andequipmentforlocalareanetworkswhichprovideanon-
guaranteedqualityofservice,"RecommendationH.323,
TelecommunicationStandardizationSectorofITU,Geneva,
Switzerland,May1996.
[2]Handley,M.,Schulzrinne,H.,Schooler,E.andJ.Rosenberg,
"SIP:sessionInitiationProtocol",RFC2543,March1999.
[3]Arango,M.,Dugan,A.,Elliott,I.,Huitema,C.andS.Pickett,
"MediaGatewayControlProtocol(MGCP)Version1.0",RFC2705,
October1999.
[4]Droms,R.,"DynamicHostConfigurationProtocol",RFC2131,
March1997.
[5]Simpson,W.,"ThePoint-to-PointProtocol(PPP),"STD51,RFC
1661,July1994.
[6]RekhterY.andT.Li,"ABorderGatewayProtocol4(BGP-4)",RFC
1771,March1995.
[7]Veizades,J.,Guttman,E.,Perkins,C.andS.Kaplan,"Service
LocationProtocol",RFC2165,June1997.
[8]Yeong,W.,Howes,T.andS.Kille,"LightweightDirectoryAccess
Protocol",RFC1777,March1995.
[9]Guttman,E.,Perkins,C.,Veizades,J.andM.Day,"Service
LocationProtocol,Version2",RFC2608,June1999.
[10]SchulzrinneH.andJ.Rosenberg,"SIPcallerpreferencesand
calleecapabilities",Workinprogress.
[11]EuropeanTelecommunicationsStandardsInstitute(ETSI),
TelecommunicationsandInternetProtocolHarmonizationOver
Networks(TIPHON),"Inter-domainpricing,authorization,and
usageexchange,"TechnicalSpecification101321version1.4.2,
ETSI,1998.
15．作者地址
JonathanRosenberg
dynamicsoft
72EagleRockAvenue
FirstFloor
EastHanover,NJ07936
Email:jdrosen@dynamicsoft.com
HenningSchulzrinne
ColumbiaUniversity
M/S0401
1214AmsterdamAve.
NewYork,NY10027-7003
Email:schulzrinne@cs.columbia.edu
16．版權聲明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsUChcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
致謝
FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.