者遠程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不指定或限制對于前端訪問的可能性。目
前并不清楚是否應該制定一個單一的前端訪問標準。每個協議各有優缺點。有些適用于一些
場合，而另一些則適用于其它場合。
當前的前端協議有：
     Service Location Protocol (SLP): 服務定位協議，SLP設計為可以精確地滿足這種
功能。SLP對于由屬性集描述的定位服務器非常理想。這時服務器是一個網關，或者通向網
關的下一跳，而屬性則是端用戶策略。端用戶是一個SLP UA，并且LS是一個SLP DA。服務查
詢（Service Query）用于通過特定屬性集尋找網關。
     Open Settlements Protocol (OSP): 開放結算協議，OSP [11]是一個客戶/服務器協
議。它允許客戶通過電話號碼查詢服務器，并得到下一跳的地址，以及用于呼叫的認證令牌。
此時，服務器可以是LS。響應OSP查詢的路由表就是用TRIP建立起來的。
     Lightweight Directory Access Protocol (LDAP): 輕量目錄訪問協議，LDAP用于訪
問分布式數據庫。由于LS上有數據庫，LDAP可以用來進行查詢。
     Web Page: 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．鳴謝
   感謝Randy Bush, Mark Foster, Dave Oran,Hussein Salama,和Matt Squire為本文提出的有
益見解。
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.
   [2]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
        "SIP:  Session Initiation Protocol", RFC 2543, March 1999.
   [3]  Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett,
        "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705,
        October 1999.
   [4]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.
   [5]  Simpson, W., "The Point-to-Point Protocol (PPP)," STD 51, RFC
        1661, July 1994.
   [6]  Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
        1771, March 1995.
   [7]  Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
        Location Protocol", RFC 2165, June 1997.
   [8]  Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access
        Protocol", RFC 1777, March 1995.
   [9]  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
        Location Protocol, Version 2", RFC 2608, June 1999.
   [10] Schulzrinne H. and J. Rosenberg, "SIP caller preferences and
        callee capabilities", Work in progress.
   [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.
15．作者地址
   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   Email: jdrosen@dynamicsoft.com
   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   Email: schulzrinne@cs.columbia.edu
16．版權聲明
   Copyright (C) The Internet Society (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.

   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.
致謝
   Funding for the RFC Editor function is currently provided by the
   Internet Society.




RFC 2871——A Framework for Telephony Routing over IP		     一個IP電話路由框架


1
RFC文檔中文翻譯計劃