IP電話系統(tǒng)和呼叫路由技術(shù)（二）
2003/12/08
摘 要 本文首先分析了對(duì)H.323域間通信進(jìn)行單獨(dú)研究的必要性。然后介紹了ITU-T對(duì)該問題研究的最新進(jìn)展。在介紹了域間模型、地址模版等基本概念和域間通信使用的消息等內(nèi)容后，給出了H.323域間呼叫路由的詳細(xì)工作過程。文章還對(duì)域間呼叫路由方式進(jìn)行了舉例分析。最后給出了需要進(jìn)一步研究的問題。
關(guān)鍵詞 H.323 IP電話系統(tǒng) 呼叫路由 域間模型 對(duì)等單元 地址模版
1 引言
隨著H.323 IP電話系統(tǒng)在全球的廣泛應(yīng)用，要實(shí)現(xiàn)這些系統(tǒng)的互聯(lián)互通，必須要解決管理域間的呼叫路由問題。而H.323的早期版本（版本1和2）沒有考慮域間通信。
在我國制定IP電話總體技術(shù)要求時(shí)[1]，考慮了國際IP電話的互通問題，并提出了兩種使用RAS消息進(jìn)行地址解析的方法：頂級(jí)網(wǎng)守作為對(duì)方網(wǎng)關(guān)和頂級(jí)網(wǎng)守作為對(duì)等網(wǎng)守。在第一種方案中，國內(nèi)頂級(jí)網(wǎng)守使用ARQ（Admission Request）消息以網(wǎng)關(guān)的身份請(qǐng)求國外網(wǎng)守進(jìn)行地址解析。在第二種方案中，國內(nèi)頂級(jí)網(wǎng)守使用LRQ（Location Request）消息請(qǐng)求國外網(wǎng)守進(jìn)行地址解析。
為了解決H.323系統(tǒng)的域間通信問題，研究人員對(duì)RAS協(xié)議用于域間地址解析進(jìn)行了深入的研究，發(fā)現(xiàn)了以下問題：
· RAS協(xié)議的ARQ被設(shè)計(jì)用于端點(diǎn)向網(wǎng)守發(fā)起接納請(qǐng)求，不適合用作網(wǎng)守間和域間的接納認(rèn)證手段。域間通信需要更高級(jí)的認(rèn)證和授權(quán)手段。
· 使用LRQ進(jìn)行地址解析時(shí)，每個(gè)呼叫都需要主叫網(wǎng)守、中間網(wǎng)守和被叫網(wǎng)守的參與。當(dāng)應(yīng)用到域間時(shí)，這種路由方式帶來的開銷、時(shí)延都非常大。
· 管理域互通時(shí)，應(yīng)盡量將互通涉及的問題留在網(wǎng)絡(luò)邊界處，不要對(duì)域內(nèi)的工作方式和域內(nèi)實(shí)體的功能做過多的要求和改動(dòng)。但使用RAS進(jìn)行域間通信時(shí)（如LRQ），不可避免地要域內(nèi)實(shí)體的支持。
因此，ITU-T認(rèn)為RAS協(xié)議并不適合作為域間通信的手段，需要對(duì)域間互通單獨(dú)進(jìn)行研究。經(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)域間通信的框架。隨著對(duì)H.323系統(tǒng)移動(dòng)性支持研究的加深，ITU-T將對(duì)移動(dòng)性支持和域內(nèi)、域間通信的消息和參數(shù)納入了統(tǒng)一的標(biāo)準(zhǔn)H.501[3]，并對(duì)H.225.0 Annex G進(jìn)行了修訂，使其可以用于域內(nèi)和域間通信，并于2002年11月發(fā)布了H.225.0 Annex G Version 2 [4]。
2 基本概念
2.1 域間模型
H.225.0 Annex G使用的域間模型，引入了邊界單元的概念。邊界單元是H.323管理域與其他管理域的互通實(shí)體，它為域外的功能實(shí)體呼叫本管理域內(nèi)的功能實(shí)體進(jìn)行多媒體通信提供接入支持。邊界單元控制著一個(gè)管理域的對(duì)外視圖。邊界單元可以單獨(dú)設(shè)置，也可以跟網(wǎng)守、網(wǎng)關(guān)一起設(shè)置。
H.225.0 Annex G Version 1只適用于參考點(diǎn)A，即邊界單元之間的通信。而Version 2中指出，它可以用于參考點(diǎn)A、B、C。所有使用H.225.0 Annex G Version 2協(xié)議進(jìn)行交互的功能實(shí)體又被稱作“對(duì)等單元”（包括邊界單元）。H.225.0 Annex G規(guī)定了對(duì)等單元互相交換自己可以解析的地址信息的流程。邊界單元?jiǎng)t交換本管理域可解析的地址信息。由于現(xiàn)有的標(biāo)準(zhǔn)仍主要關(guān)注域間通信，因此下文我們重點(diǎn)對(duì)邊界單元進(jìn)行討論。
2.2 地址模板和描述符
地址模板和描述符是H.225.0 Annex G使用的兩個(gè)非常重要的術(shù)語。地址模板和路由表項(xiàng)的作用類似，它包括：（目的地）別名地址、（完成至該目的地呼叫的）費(fèi)用、使用的協(xié)議過程等信息。別名地址可以使用通配符“*”來表示批量地址。以下是地址模板的例子：
地址模板可以靜態(tài)配置，也可以通過H.225.0 Annex G中定義的過程來交換和獲取。邊界單元通過相互交互地址模板來向其他邊界單元通告呼叫路由信息，以對(duì)域間呼叫提供路由支持。當(dāng)邊界單元交互了各自的地址模板后，若其收到來自管理域內(nèi)部的地址解析請(qǐng)求，它就可以根據(jù)自己獲取的地址模板信息對(duì)被叫地址進(jìn)行解析。這樣不僅加快了地址解析的速度，還保護(hù)了管理域內(nèi)部結(jié)構(gòu)信息的私密性。
描述符是指一組地址模板的集合，通過描述符ID來標(biāo)識(shí)。引入描述符的目的是為了方便地址模板的管理。
3 主要消息及作用
H.225.0 Annex G使用了H.501定義的大部分消息，本節(jié)只對(duì)與呼叫路由相關(guān)的消息進(jìn)行簡要介紹。
3.1 業(yè)務(wù)聯(lián)系類消息
消息有四個(gè)：ServiceRequest、ServiceConfirmation、ServiceRejection和ServiceRelease。
ServiceRequest的作用是用于對(duì)等單元之間建立業(yè)務(wù)聯(lián)系。業(yè)務(wù)聯(lián)系主要包括雙方的標(biāo)識(shí)信息和雙方通信時(shí)使用的安全機(jī)制。只有建立業(yè)務(wù)聯(lián)系的對(duì)等單元才可進(jìn)行后續(xù)的交互。
ServiceConfirmation和ServiceRejection分別用于確認(rèn)和拒絕建立業(yè)務(wù)聯(lián)系。
ServiceRelease的作用是供已建立業(yè)務(wù)聯(lián)系的對(duì)等單元解除業(yè)務(wù)聯(lián)系使用。
3.2 描述符分發(fā)類消息
這類消息有兩個(gè)子類：描述符ID相關(guān)類和描述符相關(guān)類。
描述符ID相關(guān)類消息有三個(gè)：DescriptorIDRequest、DescriptorIDConfirmation、DescriptorIDRejection。
DescriptorIDRequest用于一個(gè)實(shí)體向其對(duì)等單元查詢對(duì)方管理域內(nèi)的描述符ID列表。
DescriptorIDConfirmation和DescriptorIDRejection分別對(duì)請(qǐng)求進(jìn)行確認(rèn)和拒絕。
描述符類消息有五個(gè)：DescriptorRequest、DescriptorConfirmation、DescriptorRejection、Descriptor Update、DescriptorUpdateAck。
DescriptorRequest用于一個(gè)實(shí)體向其對(duì)等單元請(qǐng)求一個(gè)特定的描述符。描述符是從此前發(fā)送的描述符ID請(qǐng)求過程得到的。對(duì)等單元可以確認(rèn)（返回描述符）或拒絕該請(qǐng)求。
DescriptorUpdate用于一個(gè)實(shí)體向其對(duì)等單元通告自己的描述符ID或描述符信息已發(fā)生改變（包含一個(gè)更新列表），對(duì)等單元應(yīng)對(duì)相關(guān)的描述符信息進(jìn)行更新。該請(qǐng)求可以以單播或多播的形式發(fā)送。對(duì)等單元可以使用DescriptorUpdateAck對(duì)該消息進(jìn)行確認(rèn)。
3.3 地址解析類消息
此類消有三個(gè)：AccessRequest、AccessConfir mation、AccessRejection。
AccessRequest用于一個(gè)實(shí)體請(qǐng)求其對(duì)等單元對(duì)一個(gè)特定的別名地址進(jìn)行解析。如地址解析成功，對(duì)等單元將在AccessConfirmation中包含解析出來的地址模板列表進(jìn)行確認(rèn)，否則以AccessRejection拒絕該請(qǐng)求。
由此可見，管理域內(nèi)部的網(wǎng)守（對(duì)等單元）也可以使用AccessRequest請(qǐng)求解析地址。這相當(dāng)區(qū)間的地址解析，因此H.225.0 Annex G可以取代LRQ用于域內(nèi)網(wǎng)守間的通信。
3.4 其他消息
其他消息包括使用情況報(bào)告類消息、呼叫驗(yàn)證類消息、請(qǐng)求處理中消息、非標(biāo)準(zhǔn)類消息等。因他們與呼叫路由關(guān)系不大，其詳細(xì)內(nèi)容和作用就不在此介紹了。
4 工作過程
4.1 建立業(yè)務(wù)聯(lián)系
功能實(shí)體（對(duì)等單元）啟動(dòng)后，首先要與其對(duì)等單元建立業(yè)務(wù)聯(lián)系。獲取對(duì)等單元H.225.0 Annex G傳輸層地址信息的方式有多種。可以為一個(gè)功能實(shí)體靜態(tài)配置對(duì)等單元信息，也可以通過域名系統(tǒng)來動(dòng)態(tài)地獲取對(duì)等單元的信息。
功能實(shí)體使用ServiceRequest消息請(qǐng)求與對(duì)等單元建立業(yè)務(wù)聯(lián)系，商議兩者在后續(xù)通信過程中使用的安全機(jī)制。成功建立業(yè)務(wù)聯(lián)系后，兩個(gè)對(duì)等單元就可進(jìn)行后續(xù)的消息交互。
任何一個(gè)對(duì)等單元都可使用ServiceRelease來解除與對(duì)方的業(yè)務(wù)聯(lián)系。解除的原因有多種。提出方還可向?qū)Ψ教峁┢渌蜻x的對(duì)等單元列表，供對(duì)方以后建立業(yè)務(wù)聯(lián)系用。
4.2 地址模板信息的來源
一個(gè)對(duì)等單元有三種獲取地址模板信息的途徑。
第一種是靜態(tài)配置。一個(gè)對(duì)等單元應(yīng)維護(hù)它管轄的所有管理區(qū)的模板信息。這可以通過使用局?jǐn)?shù)據(jù)來靜態(tài)配置。也可以通過其他動(dòng)態(tài)途徑來維護(hù)（比如登記和去登記）。一個(gè)管理域的邊界單元在向外提供地址模板時(shí)，可以根據(jù)策略提供不同詳細(xì)程度的地址模板。
第二種是通過接收描述符來獲取。對(duì)等單元可以使用DescriptorRequest消息向其他對(duì)等單元請(qǐng)求地址模板。收到響應(yīng)后，將收到的地址模板保存下來，直到這些地址模板信息過期。一個(gè)對(duì)等單元在自己的地址模板信息改變時(shí)，可以使用Descriptor- Update消息來通知其他對(duì)等單元。收到更新消息的對(duì)等單元將根據(jù)消息內(nèi)容修改自己存儲(chǔ)的地址模板。
第三種是通過地址解析響應(yīng)來獲取。對(duì)等單元可能向其他對(duì)等單元發(fā)送AccessRequest來請(qǐng)求解析某個(gè)特定的地址。收到解析響應(yīng)后，對(duì)等單元可將收到的解析結(jié)果保存下來，直到該地址模板信息過期。
4.3 地址模板信息的交換
對(duì)等單元首先向其他對(duì)等單元發(fā)送描述符ID請(qǐng)求，以獲取對(duì)方擁有的描述符ID列表。然后對(duì)等單元發(fā)送描述符請(qǐng)求消息，以獲取感興趣的描述符。此外，當(dāng)邊界單元的描述符信息發(fā)生變化時(shí)，它使用描述符更新消息通知其他邊界單元，使它們保存的相關(guān)信息能夠得到即時(shí)更新。
4.4 地址解析過程
當(dāng)對(duì)等單元收到來自本管理域內(nèi)部的地址解析請(qǐng)求時(shí)，它查找自己保存的地址模板。如果有多個(gè)地址模板滿足條件，就根據(jù)一定的策略對(duì)這些地址模板進(jìn)行排序（比如按最長匹配排序，或“發(fā)送Setup”要優(yōu)于“發(fā)送AccessRequest”）。排完序后，將所有滿足條件的地址模板返回給請(qǐng)求者。如果滿足條件的地址模板中沒有一個(gè)包含“發(fā)送Setup”，說明對(duì)等單元沒有能夠“完全”解析該地址。對(duì)等單元就向適當(dāng)?shù)膶?duì)等單元發(fā)送“AccessRequest”地址解析請(qǐng)求。解析到地址后對(duì)等單元將包含“發(fā)送Setup”的地址模板返回請(qǐng)求者，并將解析結(jié)果保存，以供下次解析使用。
當(dāng)邊界單元收到來自另一個(gè)管理域的邊界網(wǎng)關(guān)的“AccessRequest”地址解析請(qǐng)求時(shí)，它查找自己保存的地址模板。如果多個(gè)地址模板滿足條件，先按照最長匹配原則排序，然后按照“發(fā)送 xx”的消息類型排序（Setup要優(yōu)于AccessRequest）。如果“AccessRequest”消息的跳數(shù)已經(jīng)被減為零，但邊界單元沒有找到合適的地址模板，它將返回“AccessReject”來表示解析失敗。如果“AccessRequest”消息的跳數(shù)沒有被減為零，并且匹配的地址模板表明“發(fā)送AccessRequest”，邊界單元可以選擇將地址解析請(qǐng)求消息轉(zhuǎn)發(fā)給匹配模板中指明的對(duì)等單元，也可以選擇直接將找到的地址模板返回。當(dāng)有多個(gè)地址模板滿足要求時(shí)，邊界單元將返回所有的匹配地址模板。
在發(fā)送地址解析請(qǐng)求時(shí)，發(fā)送者可以包含“特定呼叫”標(biāo)記，這樣的話這個(gè)解析結(jié)果將僅對(duì)本次呼叫有用，解析結(jié)果將不會(huì)被保存。
5 應(yīng)用舉例
本節(jié)以H.225.0 Annex G Version 2提供的例子作為實(shí)例，對(duì)管理域間的通信及呼叫路由進(jìn)行描述，以使描述更加直觀和易于理解。
5.1 拓?fù)浣Y(jié)構(gòu)
在我們的例子中，假設(shè)有三個(gè)管理域A、B和C。這三個(gè)管理域之間的關(guān)系是全互聯(lián)關(guān)系。每個(gè)管理域管轄不同前綴號(hào)碼的用戶。
5.2 交換地址模板信息
三個(gè)管理域首先使用4. 1節(jié)的流程建立相互間的業(yè)務(wù)聯(lián)系。
然后使用4. 3節(jié)的流程交換地址模板信息（先請(qǐng)求描述符ID，然后請(qǐng)求描述符信息）。地址模板信息交換完畢后，管理域A的邊界網(wǎng)關(guān)BEA將獲取管理域B的邊界網(wǎng)關(guān)BEB保存的兩個(gè)描述符D2和D3。BEB也將獲取BEA的描述符D1。
5.3 呼叫過程
管理域A中的終端T1呼叫管理域B中的終端T2的呼叫過程。T1首先向其網(wǎng)守GKA1發(fā)送ARQ請(qǐng)求接入，被叫號(hào)碼為“19085551515”。
網(wǎng)守收到ARQ后向邊界單元BEA發(fā)送LRQ（如果GKA1也是對(duì)等單元，也可發(fā)送AccessReque- st）請(qǐng)求解析被叫地址。邊界單元查找其地址模板信息，發(fā)現(xiàn)地址描述符D2中的“1908*”可以匹配。但優(yōu)于該匹配項(xiàng)的發(fā)送消息部分是“AccessRequest”，目的是BEB的Annex G地址。BEA就向BEB發(fā)送AccessRequest請(qǐng)求解析地址。BEB收到AccessRequest后，解析被叫地址，將終端T2的呼叫信令地址返回。終端T1收到接入確認(rèn)后，直接向T2的呼叫信令地址發(fā)送Setup發(fā)起呼叫。
呼叫流程二給出了另一個(gè)例子：管理域A中的終端T1呼叫管理域B中的某個(gè)終端。終端T1首先向其網(wǎng)守GKA1發(fā)送ARQ請(qǐng)求接入，被叫號(hào)碼為“19089532000”。網(wǎng)守收到ARQ后向邊界單元BEA發(fā)送LRQ請(qǐng)求解析被叫地址。邊界單元查找其地址模板信息，發(fā)現(xiàn)地址描述符D3中的“1908953*”可以匹配，且發(fā)送消息部分是“Setup”。BEA直接將解析結(jié)果返回。終端T1收到響應(yīng)后，根據(jù)解析結(jié)果向管理域B的網(wǎng)關(guān)GWB1發(fā)送Setup消息請(qǐng)求建立呼叫。
6 結(jié)束語
隨著IP電話系統(tǒng)的大規(guī)模商用，域間的互通問題顯得非常重要。為了實(shí)現(xiàn)域間的呼叫路由，ITU-T專門制定了H.323的域間通信框架H.225.0 Annex G。在H.501的支持下，H.225.0 Annex G的新版本試圖將域間和域內(nèi)網(wǎng)守間的通信納入同一個(gè)框架。但目前的重點(diǎn)還只限于域間通信。如何將之用于域內(nèi)網(wǎng)守間通信并處理好與LRQ的關(guān)系需要進(jìn)一步研究。
參 考 文 獻(xià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ù)通信》