1 引言

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

　 2 確保視頻系統QoS的方法

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

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

　 2.2綜合服務Internet方法

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

　 3 網絡設計上對QoS的保證

　 3.1 網絡結構

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

　 3.2 路由振蕩問題

　 路由振蕩原因分為兩個方面。

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

　 3.3 處理振蕩問題

　 振蕩是一個非常難于解決的問題，由于路由器原理的問題（相對于交換機來說），總有一些時間可能處于較忙的時間，這可能令到單臺路由器的延遲增加到100ms以上，這樣就會造成多媒體會議系統的質量發生下降。產生這樣的情況有時候不見得是由于線路上流量過多造成的，有可能在20%~30%的帶寬下也會發生這樣的事情。這樣的問題主要是由于路由器的Buffer設置的問題造成的。改善的方案是將路由器的Buffer設置專門為會議系統這樣的情況進行優化，不過有可能造成傳統IP業務的效率下降。最好的情況是采用兩個網絡分開進行服務，這里有一個決策的問題。

　 3.4 網絡擁塞

　 除了振蕩，網絡擁塞對IP視頻會議業務也有著重大影響。因此我們在設計網絡時，要防止網絡擁塞的產生。在部署擁塞管理時，使用以下幾個步驟：

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

　 4 IP視頻業務本身的QoS的實現

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

　 4． 1 RTP功能及設計思想

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

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

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

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

　 SR：主要用于多RTP流，如音頻和視頻之間的同步，和H.225.0密切相關。和流同步相關的字段是RTP時戳和NTP時戳。

　 RR：用戶監測QoS指標，包括長時指標和短時指標。如果丟包率高于設定值，就應降低媒體速率。如接收報告間隔超過設定值，則應根據RR包中的丟失率字段判斷網絡是否嚴重阻塞，如是，應降低媒體速率。如果連續3個接收報告的到達時延抖動值增加，發送端應采取措施。

　在H.245中也有測量往返時延的消息："往返時延請求"和"往返時延響應"，該消息不含時間參數，請求發送端根據兩個消息的收發時間差即得往返時延，該時延為傳播時延、接受端排隊時延和處理時延之總和。而RTCP中根據SR和RR消息計算得出的是單純的傳播時延，直接反映網絡傳送的QoS。因此，二者監測的是不同物理量，相互之間并不沖突。

　 4． 2 證QoS具體手段

　 為了維持一定的服務質量，當監測到QoS指標下降時，H.323終端采取一定措施。實際上這些措施并不是保持原有的Qos，而按照一定順序依次減低各種媒體的質量，使得在給定的帶寬和負荷條件下仍然能向用戶提供可接受的服務。首先考慮降低質量的是視頻信號，然后依次是數據、音頻和控制信號。采取措施可分為兩類：短時響應和長時響應。前者旨在解決包短時丟失和時延增加的短期問題；后者用于網絡擁塞日益嚴重的情況。

　 (1)動態調整圖像帶寬

　 人們對圖像和語音的敏感程度是不一樣的，當圖像碼流出現延遲、抖動時，解碼后圖像表現為誤碼、丟幀；當語音碼流出現延遲、抖動時，解碼后聲音斷續。從人的感覺上對圖像的誤碼更寬容一些。
為提高QoS，可以利用RTP/RTCP報告，得到關于網絡狀況的信息，如丟包率、包抖動、延遲，根據這些信息動態調整圖像帶寬。當網絡狀況不好時，可以通知編碼器，降低圖像帶寬，優先保證聲音帶寬；當網絡狀況好時，通知編碼器，提高圖像帶寬。

　 (2) 唇音同步

　 接收方：對于接收方語音和圖像的同步，終端收到語音、圖像數據之后，分別放到語音緩沖和圖像緩沖中，定時從語音緩沖中取出語音包解碼，如果取出的語音包時戳與圖像吻合，就把相應的圖像包解碼。這樣做的好處是考慮語音的敏感性。

　 發送方：打時戳。發送方應該給數據包打上時戳，一方面是數據包（RTP包）的時戳，另一方面是數據控制包（RTCP包）的時戳。

　 5 結論

　 據目前種種跡象表明，基于H.323的IP視頻會議系統將成為寬帶IP網的一種潛力很大的增值業務。而它的終極目標是公眾運營化，使千家萬戶享受視頻服務。但IP視頻會議系統的公眾運營化，涉及到很多問題，服務質量是實現IP視頻會議開展的關鍵，所以在IP視頻的系統設計中，要統一做好服務質量的設計。由于IP視頻會議是一項新興的技術，本身還處于發展中，很多技術有待于進一步的研究和探討。