基于H.323協(xié)議的IP視頻會(huì )議服務(wù)質(zhì)量技術(shù)

近年來(lái)，基于H.323的IP視頻會(huì )議系統得到了很大的發(fā)展，已經(jīng)具備了公眾運營(yíng)的條件，而實(shí)現這一條件，服務(wù)質(zhì)量是關(guān)鍵。本文從兩個(gè)層面：網(wǎng)絡(luò )層面和業(yè)務(wù)層面給出了IP視頻會(huì )議的服務(wù)質(zhì)量技術(shù)。

　 關(guān)鍵詞：H.323；IP視頻會(huì )議；Qos

　 1 引言

　 2001年，國內各大運營(yíng)商把目光投向IP視頻會(huì )議系統的建設。由于H.323協(xié)議本身的不成熟，這給IP視頻會(huì )議的公眾運營(yíng)帶來(lái)一定的困難。IP視頻會(huì )議的公眾運營(yíng)化，必須解決用戶(hù)管理、業(yè)務(wù)管理、計費管理和視頻交換的互操作性等問(wèn)題。由于Internet是一個(gè)無(wú)連接網(wǎng)絡(luò )，只提供一種承載業(yè)務(wù)-盡力傳送(best effort)業(yè)務(wù)。也就是說(shuō)，網(wǎng)絡(luò )并不保證向應用數據流提供所需的帶寬，也不保證數據流的傳送時(shí)延和丟失率等質(zhì)量指標。對于數據業(yè)務(wù)等非實(shí)時(shí)業(yè)務(wù)，盡力傳送能夠滿(mǎn)足要求，但是對于音頻或視頻等實(shí)時(shí)通信應用，網(wǎng)絡(luò )必須能支持具有一定QoS的端到端承載業(yè)務(wù)。如何提高實(shí)時(shí)性能，確保通信的QoS，是IP視頻系統的關(guān)鍵技術(shù)要求，也是一個(gè)技術(shù)難點(diǎn)。在IP視頻會(huì )議中，QoS的策略可分為兩個(gè)層面來(lái)實(shí)現：網(wǎng)絡(luò )層面和業(yè)務(wù)層面。本文從這兩個(gè)層面出發(fā)分析了IP承載網(wǎng)適合用于視頻會(huì )議的QoS策略和H.323協(xié)議本身的QoS實(shí)現，提出了IP視頻會(huì )議的QoS的實(shí)現技術(shù)。

　 2 確保視頻系統QoS的方法

　 Internet上確保IP視頻系統QoS有兩種方法。
　 2.1 超量工程法(overengineering)

　 即在網(wǎng)絡(luò )規劃時(shí)預留足夠的帶寬，使得任何時(shí)候都能獲得可接受的QoS。這種方法十分簡(jiǎn)單，不需要資源預留協(xié)議和接納控制功能，但是要求部署足夠多的路由器和高速鏈路，保證即使在忙時(shí)網(wǎng)絡(luò )資源也有足夠的余量。它可用于網(wǎng)絡(luò )資源便宜、同時(shí)網(wǎng)絡(luò )最大業(yè)務(wù)量又可以預測的情況。

　 2.2綜合服務(wù)Internet方法

　 由IETF綜合服務(wù)(IntServ)工作組定義。它需定義呼叫接納控制功能資源預留協(xié)議，如RSVP。利用RSVP消息，端點(diǎn)應用程序可以提出數據傳送全程必須保留的網(wǎng)絡(luò )資源（如帶寬、緩沖區大小等），同時(shí)也確定了沿途各路由器的傳輸調度策略，藉此，可以對每個(gè)數據流的QoS依次進(jìn)行控制。

　 3 網(wǎng)絡(luò )設計上對QoS的保證

　 3.1 網(wǎng)絡(luò )結構

　 城域IP網(wǎng)絡(luò )通常由核心層、匯接層和接入層組成，匯接層的各節點(diǎn)通過(guò)高速鏈路連接到核心層。在城域IP網(wǎng)中，在路由器連接上考慮路由跳數，保證網(wǎng)絡(luò )任意兩個(gè)節點(diǎn)間通信路由跳數最多為4跳，配置高性能路由器，根據經(jīng)驗值，在采用光傳輸的情況下，一個(gè)數據包經(jīng)過(guò)一跳其延遲一般為10ms，該值不由線(xiàn)路的長(cháng)度和路由器的性能所決定（對于7500以上的路由器），所以數據包在骨干網(wǎng)中的正常延時(shí)大概在50ms左右。從這個(gè)角度考慮，延時(shí)問(wèn)題不是影響IP視頻業(yè)務(wù)質(zhì)量的主要問(wèn)題。

　 3.2 路由振蕩問(wèn)題

　 路由振蕩原因分為兩個(gè)方面。

　 一個(gè)是由于鏈路狀態(tài)的改變造成的路由改變，如果采用IS-IS或OSPF的路由發(fā)現，由于該問(wèn)題要靠Hello包的檢測，同時(shí)檢測一次還不行，還需要檢測幾次。一般情況下，從鏈路中斷到新路由選定需要幾秒到幾十秒的時(shí)間，這樣的問(wèn)題發(fā)生在骨干網(wǎng)上將大大地影響實(shí)時(shí)多媒體業(yè)務(wù)的質(zhì)量，該問(wèn)題主要通過(guò)使用MPLS的FRR能力加以保護。
另一個(gè)路由振蕩問(wèn)題主要是網(wǎng)絡(luò )設計不嚴謹造成的，對于出現大量的同值選路或大量的Route ReLookup或路由狀態(tài)更新振蕩的情況，防止問(wèn)題的主要方案是在設計網(wǎng)絡(luò )時(shí)要求所有的流量的方向和選路都需要監控者明確地加以檢查。

　 3.3 處理振蕩問(wèn)題

　 振蕩是一個(gè)非常難于解決的問(wèn)題，由于路由器原理的問(wèn)題（相對于交換機來(lái)說(shuō)），總有一些時(shí)間可能處于較忙的時(shí)間，這可能令到單臺路由器的延遲增加到100ms以上，這樣就會(huì )造成多媒體會(huì )議系統的質(zhì)量發(fā)生下降。產(chǎn)生這樣的情況有時(shí)候不見(jiàn)得是由于線(xiàn)路上流量過(guò)多造成的，有可能在20%~30%的帶寬下也會(huì )發(fā)生這樣的事情。這樣的問(wèn)題主要是由于路由器的Buffer設置的問(wèn)題造成的。改善的方案是將路由器的Buffer設置專(zhuān)門(mén)為會(huì )議系統這樣的情況進(jìn)行優(yōu)化，不過(guò)有可能造成傳統IP業(yè)務(wù)的效率下降。最好的情況是采用兩個(gè)網(wǎng)絡(luò )分開(kāi)進(jìn)行服務(wù)，這里有一個(gè)決策的問(wèn)題。

　 3.4 網(wǎng)絡(luò )擁塞

　 除了振蕩，網(wǎng)絡(luò )擁塞對IP視頻會(huì )議業(yè)務(wù)也有著(zhù)重大影響。因此我們在設計網(wǎng)絡(luò )時(shí)，要防止網(wǎng)絡(luò )擁塞的產(chǎn)生。在部署擁塞管理時(shí)，使用以下幾個(gè)步驟：

?。?）測定WAN是否發(fā)生擁塞現象。
?。?）根據所需要管理的通信的種類(lèi)、網(wǎng)絡(luò )的拓撲結構及設計方案來(lái)決定目標。在確定需要取得什么樣的結果的時(shí)候，考慮目標是否位于幾條標準之中：
　·能夠為所確定的所有通信類(lèi)型建立一種公平的帶寬分配方式；
　·對于從IP視頻業(yè)務(wù)發(fā)送出來(lái)的通信，都能夠指定嚴格的優(yōu)先級。這樣可能會(huì )傷害到同時(shí)也支持的、但不是緊急的通信業(yè)務(wù)的利益；
　·能夠自定義帶寬分配，以便在所服務(wù)的所有的應用之間共享網(wǎng)絡(luò )資源。每一個(gè)應用都具有特定的、已經(jīng)確定好的帶寬需求。
?。?）用所選定的那種排隊策略配置接口，并且觀(guān)察所得到的結果。

　 4 IP視頻業(yè)務(wù)本身的QoS的實(shí)現

　 如何提高實(shí)時(shí)性，確保通信的QoS，是IP視頻會(huì )議的關(guān)鍵技術(shù)要求。在這一點(diǎn)上，基于H.323的視頻會(huì )議系統采用IETF提出的實(shí)時(shí)協(xié)議和網(wǎng)絡(luò )技術(shù)。首先，話(huà)音信號采用實(shí)時(shí)傳送協(xié)議RTP封裝傳輸。但是，RTP本身并不提供任何保證QoS的機制，要確保通信的實(shí)時(shí)性還需要IP網(wǎng)絡(luò )本身具有這方面的增強能力。

　 4． 1 RTP功能及設計思想

　 RTP協(xié)議為音頻、視頻等實(shí)時(shí)數據提供端到端的傳遞服務(wù)，可以向接收端點(diǎn)傳送恢復實(shí)時(shí)信號必需的定時(shí)和順序的信息，并向收發(fā)雙方和網(wǎng)絡(luò )運營(yíng)者提供QoS監測的手段，降低對網(wǎng)絡(luò )帶寬的需求。RTP可以大大減少你的帶寬占用。RTP還可以使視頻會(huì )議中容忍少量的丟包，以避免數據包重傳造成的時(shí)延。RTP實(shí)際包括兩個(gè)協(xié)議。

　 （1）RTP本身：用以傳送實(shí)時(shí)數據。其功能提供凈荷類(lèi)型指示、數據分組序號、數據發(fā)送時(shí)戳和數據源標識。

　 （2）RTCP：用以傳送實(shí)時(shí)信號傳遞的質(zhì)量參數，提供QoS監視機制；同時(shí)還可傳送會(huì )議通信中的參會(huì )者的信息，向沒(méi)有顯式的成員控制和呼叫建立的松弛型會(huì )議通信提供控制機制。

　 H.323協(xié)議利用RTCP的SR和RR包監測QoS。