IP電話系統和呼叫路由技術（2）

2019-11-03 09:04:38

字體：大中小

來源：轉載

供稿：網友

第2講 H.323 ip電話系統的域間呼叫路由
趙志峰1, 2, 3

　　楊永康2　　仇佩亮1
（1. 浙江大學博士后科研流動站　　杭州310027）
（2. 東方通信博士后科研工作站　　杭州310053）
（3. 解放軍理工大學通信工程學院　　南京210007）

　　摘要本文首先分析了對H.323域間通信進行單獨研究的必要性。然后介紹了ITU-T對該問題研究的最新進展。在介紹了域間模型、地址模版等基本概念和域間通信使用的消息等內容后，給出了H.323域間呼叫路由的詳細工作過程。文章還對域間呼叫路由方式進行了舉例分析。最后給出了需要進一步研究的問題。

　　關鍵詞 H.323 IP電話系統呼叫路由域間模型對等單元地址模版

1 引言

　　隨著H.323 IP電話系統在全球的廣泛應用，要實現這些系統的互聯互通，必須要解決管理域間的呼叫路由問題。而H.323的早期版本（版本1和2）沒有考慮域間通信。

　　在我國制定IP電話總體技術要求時[1]，考慮了國際IP電話的互通問題，并提出了兩種使用RAS消息進行地址解析的方法：頂級網守作為對方網關和頂級網守作為對等網守。在第一種方案中，國內頂級網守使用ARQ（Admission Request）消息以網關的身份請求國外網守進行地址解析。在第二種方案中，國內頂級網守使用LRQ（Location Request）消息請求國外網守進行地址解析。

　　為了解決H.323系統的域間通信問題，研究人員對RAS協議用于域間地址解析進行了深入的研究，發現了以下問題：

　　· RAS協議的ARQ被設計用于端點向網守發起接納請求，不適合用作網守間和域間的接納認證手段。域間通信需要更高級的認證和授權手段。

　　· 使用LRQ進行地址解析時，每個呼叫都需要主叫網守、中間網守和被叫網守的參與。當應用到域間時，這種路由方式帶來的開銷、時延都非常大。

　　· 管理域互通時，應盡量將互通涉及的問題留在網絡邊界處，不要對域內的工作方式和域內實體的功能做過多的要求和改動。但使用RAS進行域間通信時（如LRQ），不可避免地要域內實體的支持。

　　

　　因此，ITU-T認為RAS協議并不適合作為域間通信的手段，需要對域間互通單獨進行研究。經過數年的努力，ITU-T于1999年5月發布了H.225.0 Annex G Version 1[2]，專門為H.323系統域間網守互通制定了標準。從此確立了H.323系統域間通信的框架。隨著對H.323系統移動性支持研究的加深，ITU-T將對移動性支持和域內、域間通信的消息和參數納入了統一的標準H.501[3]，并對H.225.0 Annex G進行了修訂，使其可以用于域內和域間通信，并于2002年11月發布了H.225.0 Annex G Version 2 [4]。

2 基本概念

2.1 域間模型

　　H.225.0 Annex G使用的域間模型，引入了邊界單元的概念。邊界單元是H.323管理域與其他管理域的互通實體，它為域外的功能實體呼叫本管理域內的功能實體進行多媒體通信提供接入支持。邊界單元控制著一個管理域的對外視圖。邊界單元可以單獨設置，也可以跟網守、網關一起設置。圖中的后端服務指那些提供認證、記費等功能的實體。

　　H.225.0 Annex G Version 1只適用于參考點A，即邊界單元之間的通信。而Version 2中指出，它可以用于參考點A、B、C。所有使用H.225.0 Annex G Version 2協議進行交互的功能實體又被稱作“對等單元”（包括邊界單元）。H.225.0 Annex G規定了對等單元互相交換自己可以解析的地址信息的流程。邊界單元則交換本管理域可解析的地址信息。由于現有的標準仍主要關注域間通信，因此下文我們重點對邊界單元進行討論。

2.2 地址模板和描述符

　　地址模板和描述符是H.225.0 Annex G使用的兩個非常重要的術語。地址模板和路由表項的作用類似，它包括：（目的地）別名地址、（完成至該目的地呼叫的）費用、使用的協議過程等信息。別名地址可以使用通配符“*”來表示批量地址。以下是地址模板的例子：

　　地址模板可以靜態配置，也可以通過H.225.0 Annex G中定義的過程來交換和獲取。邊界單元通過相互交互地址模板來向其他邊界單元通告呼叫路由信息，以對域間呼叫提供路由支持。當邊界單元交互了各自的地址模板后，若其收到來自管理域內部的地址解析請求，它就可以根據自己獲取的地址模板信息對被叫地址進行解析。這樣不僅加快了地址解析的速度，還保護了管理域內部結構信息的私密性。

　　描述符是指一組地址模板的集合，通過描述符ID來標識。引入描述符的目的是為了方便地址模板的管理。

3 主要消息及作用

　　H.225.0 Annex G使用了H.501定義的大部分消息，本節只對與呼叫路由相關的消息進行簡要介紹。

3.1 業務聯系類消息

　　消息有四個：ServiceRequest、ServiceConfirmation、ServiceRejection和ServiceRelease。

　　ServiceRequest的作用是用于對等單元之間建立業務聯系。業務聯系主要包括雙方的標識信息和雙方通信時使用的安全機制。只有建立業務聯系的對等單元才可進行后續的交互。

　　ServiceConfirmation和ServiceRejection分別用于確認和拒絕建立業務聯系。

　　ServiceRelease的作用是供已建立業務聯系的對等單元解除業務聯系使用。

3.2 描述符分發類消息

　　這類消息有兩個子類：描述符ID相關類和描述符相關類。

　　描述符ID相關類消息有三個：DescriptorIDRequest、DescriptorIDConfirmation、DescriptorIDRejection。

　　DescriptorIDRequest用于一個實體向其對等單元查詢對方管理域內的描述符ID列表。

　　DescriptorIDConfirmation和DescriptorIDRejection分別對請求進行確認和拒絕。

　　描述符類消息有五個：DescriptorRequest、DescriptorConfirmation、DescriptorRejection、Descriptor Update、DescriptorUpdateAck。 DescriptorRequest用于一個實體向其對等單元請求一個特定的描述符。描述符是從此前發送的描述符ID請求過程得到的。對等單元可以確認（返回描述符）或拒絕該請求。

　　DescriptorUpdate用于一個實體向其對等單元通告自己的描述符ID或描述符信息已發生改變（包含一個更新列表），對等單元應對相關的描述符信息進行更新。該請求可以以單播或多播的形式發送。對等單元可以使用DescriptorUpdateAck對該消息進行確認。

3.3 地址解析類消息此類消有三個：accessRequest、AccessConfir mation、AccessRejection。

　　AccessRequest用于一個實體請求其對等單元對一個特定的別名地址進行解析。如地址解析成功，對等單元將在AccessConfirmation中包含解析出來的地址模板列表進行確認，否則以AccessRejection拒絕該請求。

　　由此可見，管理域內部的網守（對等單元）也可以使用AccessRequest請求解析地址。這相當區間的地址解析，因此H.225.0 Annex G可以取代LRQ用于域內網守間的通信。3.4 其他消息

　　其他消息包括使用情況報告類消息、呼叫驗證類消息、請求處理中消息、非標準類消息等。因他們與呼叫路由關系不大，其詳細內容和作用就不在此介紹了。

4 工作過程

4.1 建立業務聯系

　　功能實體（對等單元）啟動后，首先要與其對等單元建立業務聯系。獲取對等單元H.225.0 Annex G傳輸層地址信息的方式有多種。可以為一個功能實體靜態配置對等單元信息，也可以通過域名系統來動態地獲取對等單元的信息。

　　功能實體使用ServiceRequest消息請求與對等單元建立業務聯系，商議兩者在后續通信過程中使用的安全機制。成功建立業務聯系后，兩個對等單元就可進行后續的消息交互。

　　任何一個對等單元都可使用ServiceRelease來解除與對方的業務聯系。解除的原因有多種。提出方還可向對方提供其他候選的對等單元列表，供對方以后建立業務聯系用。

4.2 地址模板信息的來源

　　一個對等單元有三種獲取地址模板信息的途徑。

　　第一種是靜態配置。一個對等單元應維護它管轄的所有管理區的模板信息。這可以通過使用局數據來靜態配置。也可以通過其他動態途徑來維護（比如登記和去登記）。一個管理域的邊界單元在向外提供地址模板時，可以根據策略提供不同詳細程度的地址模板。

　　第二種是通過接收描述符來獲取。對等單元可以使用DescriptorRequest消息向其他對等單元請求地址模板。收到響應后，將收到的地址模板保存下來，直到這些地址模板信息過期。一個對等單元在自己的地址模板信息改變時，可以使用Descriptor-Update消息來通知其他對等單元。收到更新消息的對等單元將根據消息內容修改自己存儲的地址模板。

　　第三種是通過地址解析響應來獲取。對等單元可能向其他對等單元發送AccessRequest來請求解析某個特定的地址。收到解析響應后，對等單元可將收到的解析結果保存下來，直到該地址模板信息過期。

4.3 地址模板信息的交換

　　地址模板信息的交換過程對等單元首先向其他對等單元發送描述符ID請求，以獲取對方擁有的描述符ID列表。然后對等單元發送描述符請求消息，以獲取感興趣的描述符。此外，當邊界單元的描述符信息發生變化時，它使用描述符更新消息通知其他邊界單元，使它們保存的相關信息能夠得到即時更新。

4.4 地址解析過程

　　當對等單元收到來自本管理域內部的地址解析請求時，它查找自己保存的地址模板。如果有多個地址模板滿足條件，就根據一定的策略對這些地址模板進行排序（比如按最長匹配排序，或“發送Setup”要優于“發送AccessRequest”）。排完序后，將所有滿足條件的地址模板返回給請求者。如果滿足條件的地址模板中沒有一個包含“發送Setup”，說明對等單元沒有能夠“完全”解析該地址。對等單元就向適當的對等單元發送“AccessRequest”地址解析請求。解析到地址后對等單元將包含“發送Setup”的地址模板返回請求者，并將解析結果保存，以供下次解析使用。

　　當邊界單元收到來自另一個管理域的邊界網關的“AccessRequest”地址解析請求時，它查找自己保存的地址模板。如果多個地址模板滿足條件，先按照最長匹配原則排序，然后按照“發送 xx”的消息類型排序（Setup要優于AccessRequest）。如果“AccessRequest”消息的跳數已經被減為零，但邊界單元沒有找到合適的地址模板，它將返回“AccessReject”來表示解析失敗。如果“AccessRequest”消息的跳數沒有被減為零，并且匹配的地址模板表明“發送AccessRequest”，邊界單元可以選擇將地址解析請求消息轉發給匹配模板中指明的對等單元，也可以選擇直接將找到的地址模板返回。當有多個地址模板滿足要求時，邊界單元將返回所有的匹配地址模板。

　　在發送地址解析請求時，發送者可以包含“特定呼叫”標記，這樣的話這個解析結果將僅對本次呼叫有用，解析結果將不會被保存。

5 應用舉例

　　本節以H.225.0 Annex G Version 2提供的例子作為實例，對管理域間的通信及呼叫路由進行描述，以使描述更加直觀和易于理解。

5.1 拓撲結構

　　在我們的例子中，假設有三個管理域A、B和C。這三個管理域之間的關系是全互聯關系。每個管理域管轄不同前綴號碼的用戶。

　　三個管理域的邊界網關配置的地址模板信息。其中管理域A的邊界網關包含了一個描述符D1，管理域B的邊界網關包含了兩個描述符D2和D3，管理域C的邊界網關包含了兩個描述符D4和D5。

5.2 交換地址模板信息

　　三個管理域首先使用4. 1節的流程建立相互間的業務聯系。

　　然后使用4. 3節的流程交換地址模板信息（先請求描述符ID，然后請求描述符信息）。地址模板信息交換完畢后，管理域A的邊界網關BEA將獲取管理域B的邊界網關BEB保存的兩個描述符D2和D3。BEB也將獲取BEA的描述符D1。

5.3 呼叫過程

　　網守收到ARQ后向邊界單元BEA發送LRQ（如果GKA1也是對等單元，也可發送AccessReque-st）請求解析被叫地址。邊界單元查找其地址模板信息，發現地址描述符D2中的“1908*”可以匹配。但優于該匹配項的發送消息部分是“AccessRequest”，目的是BEB的Annex G地址。BEA就向BEB發送AccessRequest請求解析地址。BEB收到AccessRequest后，解析被叫地址，將終端T2的呼叫信令地址返回。終端T1收到接入確認后，直接向T2的呼叫信令地址發送Setup發起呼叫。

　　呼叫流程二給出了另一個例子：管理域A中的終端T1呼叫管理域B中的某個終端。終端T1首先向其網守GKA1發送ARQ請求接入，被叫號碼為“19089532000”。網守收到ARQ后向邊界單元BEA發送LRQ請求解析被叫地址。邊界單元查找其地址模板信息，發現地址描述符D3中的“1908953*”可以匹配，且發送消息部分是“Setup”。BEA直接將解析結果返回。終端T1收到響應后，根據解析結果向管理域B的網關GWB1發送Setup消息請求建立呼叫。

6 結束語

　　隨著IP電話系統的大規模商用，域間的互通問題顯得非常重要。為了實現域間的呼叫路由，ITU-T專門制定了H.323的域間通信框架H.225.0 Annex G。在H.501的支持下，H.225.0 Annex G的新版本試圖將域間和域內網守間的通信納入同一個框架。但目前的重點還只限于域間通信。如何將之用于域內網守間通信并處理好與LRQ的關系需要進一步研究。

參考文獻

[1] 中華人民共和國信息產業部. IP電話/傳真業務總體技術要求（Version2）. 2001年

[2] ITU-T Recommendation H.225.0 Annex G (Version 1) (1999), Communication between Administrative Domains

[3] ITU-T Recommendation H.501 (2002), PRotocol for Mobility Management and Intra/inter-domain Communicationin Multimedia Systems.

[4] ITU-T Recommendation H.225.0 Revised Annex G (Version 2) (2002), Communication between and within Administrative Domains

----《中國數據通信》