IP電話系統(tǒng)和呼叫路由技術(shù)（二）

2003/12/08

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

　　關(guān)鍵詞 H.323 IP電話系統(tǒng) 呼叫路由 域間模型 對等單元 地址模版

1 引言

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

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

　　為了解決H.323系統(tǒng)的域間通信問題，研究人員對RAS協(xié)議用于域間地址解析進行了深入的研究，發(fā)現(xiàn)了以下問題：

　　· RAS協(xié)議的ARQ被設(shè)計用于端點向網(wǎng)守發(fā)起接納請求，不適合用作網(wǎng)守間和域間的接納認(rèn)證手段。域間通信需要更高級的認(rèn)證和授權(quán)手段。

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

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

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

2 基本概念

2.1 域間模型

　　H.225.0 Annex G使用的域間模型，引入了邊界單元的概念。邊界單元是H.323管理域與其他管理域的互通實體，它為域外的功能實體呼叫本管理域內(nèi)的功能實體進行多媒體通信提供接入支持。邊界單元控制著一個管理域的對外視圖。邊界單元可以單獨設(shè)置，也可以跟網(wǎng)守、網(wǎng)關(guān)一起設(shè)置。

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

2.2 地址模板和描述符

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

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

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

3 主要消息及作用

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

3.1 業(yè)務(wù)聯(lián)系類消息

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

　　ServiceRequest的作用是用于對等單元之間建立業(yè)務(wù)聯(lián)系。業(yè)務(wù)聯(lián)系主要包括雙方的標(biāo)識信息和雙方通信時使用的安全機制。只有建立業(yè)務(wù)聯(lián)系的對等單元才可進行后續(xù)的交互。

　　ServiceConfirmation和ServiceRejection分別用于確認(rèn)和拒絕建立業(yè)務(wù)聯(lián)系。

　　ServiceRelease的作用是供已建立業(yè)務(wù)聯(lián)系的對等單元解除業(yè)務(wù)聯(lián)系使用。

3.2 描述符分發(fā)類消息

　　這類消息有兩個子類：描述符ID相關(guān)類和描述符相關(guān)類。

　　描述符ID相關(guān)類消息有三個：DescriptorIDRequest、DescriptorIDConfirmation、DescriptorIDRejection。

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

　　DescriptorIDConfirmation和DescriptorIDRejection分別對請求進行確認(rèn)和拒絕。

　　描述符類消息有五個：DescriptorRequest、DescriptorConfirmation、DescriptorRejection、Descriptor Update、DescriptorUpdateAck。

DescriptorRequest用于一個實體向其對等單元請求一個特定的描述符。描述符是從此前發(fā)送的描述符ID請求過程得到的。對等單元可以確認(rèn)（返回描述符）或拒絕該請求。

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

3.3 地址解析類消息

此類消有三個：AccessRequest、AccessConfir mation、AccessRejection。

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

　　由此可見，管理域內(nèi)部的網(wǎng)守（對等單元）也可以使用AccessRequest請求解析地址。這相當(dāng)區(qū)間的地址解析，因此H.225.0 Annex G可以取代LRQ用于域內(nèi)網(wǎng)守間的通信。

3.4 其他消息

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

4 工作過程

4.1 建立業(yè)務(wù)聯(lián)系

　　功能實體（對等單元）啟動后，首先要與其對等單元建立業(yè)務(wù)聯(lián)系。獲取對等單元H.225.0 Annex G傳輸層地址信息的方式有多種�？梢詾橐粋�功能實體靜態(tài)配置對等單元信息，也可以通過域名系統(tǒng)來動態(tài)地獲取對等單元的信息。

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

　　任何一個對等單元都可使用ServiceRelease來解除與對方的業(yè)務(wù)聯(lián)系。解除的原因有多種。提出方還可向?qū)Ψ教峁┢渌蜻x的對等單元列表，供對方以后建立業(yè)務(wù)聯(lián)系用。

4.2 地址模板信息的來源

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

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

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

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

4.3 地址模板信息的交換

　　對等單元首先向其他對等單元發(fā)送描述符ID請求，以獲取對方擁有的描述符ID列表。然后對等單元發(fā)送描述符請求消息，以獲取感興趣的描述符。此外，當(dāng)邊界單元的描述符信息發(fā)生變化時，它使用描述符更新消息通知其他邊界單元，使它們保存的相關(guān)信息能夠得到即時更新。

4.4 地址解析過程

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

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

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

5 應(yīng)用舉例

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

5.1 拓撲結(jié)構(gòu)

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

5.2 交換地址模板信息

　　三個管理域首先使用4. 1節(jié)的流程建立相互間的業(yè)務(wù)聯(lián)系。

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

5.3 呼叫過程

　　管理域A中的終端T1呼叫管理域B中的終端T2的呼叫過程。T1首先向其網(wǎng)守GKA1發(fā)送ARQ請求接入，被叫號碼為“19085551515”。

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

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

6 結(jié)束語

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

參 考 文 獻

[1] 中華人民共和國信息產(chǎn)業(yè)部. IP電話/傳真業(yè)務(wù)總體技術(shù)要求（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 Communication 　　 in Multimedia Systems.

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

中國通信網(wǎng)(www.c114.net)----《中國數(shù)據(jù)通信》