1 概述

    由于IP寬帶網絡不斷普及，一般單位在建設視訊會議時都會考慮在IP寬帶網絡上進行。由于視訊會議中需要實時交換視音頻數據，所以在IP視訊會議中視頻和音頻信息采用承載在UDP上的RTP通道進行傳輸，RTP不提供任何機制來確保數據的按時發送或保證服務的質量，甚至不能保證分組數據的順序遞交，一旦中間傳輸網絡出現點異常如網絡擁塞、震蕩就會導致接收端接收到的數據產生丟包、亂序、延時等現象，使得接收終端不能解碼出流暢聲音與圖像，出現聲音停頓、圖像馬賽克等現象。

2 NAA技術

    在視訊會議中由于RTP通道不能為視音頻數據提供良好的Qos保障，導致視訊會議在實際應用中效果受到很大影響，杭州華三通信技術有限公司在充分分析問題的基礎上，依靠自身在IP領域技術雄厚積累與視音頻技術深入研究，提出了視訊會議NAA（Network Auto-Adaptability，網絡自適應）技術（以下簡稱“NAA”），為視訊會議提供端到端良好的Qos保障。 NAA在傳輸層面與編解碼層面對視音頻的質量進行了特性保障：

2.1 傳輸層

2.1.1 PQ隊列

    視訊會議端點設備支持IP DiffServe服務模型。在視音頻報文發送之前把報文優先級設置為高優先級（如下圖中的“緊急報文”），當路由設備接收到這些視音頻報文會優先轉發，報文的丟失率和時延這兩個性能指標在網絡擁塞時也可以有一定的保障。

圖1 PQ隊列處理過程示意圖

    在報文到達路由設備接口后首先對報文進行分類，然后按照報文所屬的類別讓報文進入所屬隊列的尾部，在報文發送時按照優先級總是在所有優先級較高的隊列中的報文發送完畢后再發送低優先級隊列中的報文，這樣在每次發送報文時總是將優先級高的報文先發出去，保證了屬于較高優先級隊列的報文有較低的時延與丟失率。

2.1.2 冗余糾錯

    在傳輸帶寬允許的情況下，在發送端對重要的宏塊進行冗余編碼，發送給對端，這樣的話當網絡出現異常出現丟包時，可以最大限度保護重要的編碼宏塊不丟失。如下：

圖2 冗余糾錯處理過程示意圖

    當第3個包在傳輸過程中丟失時，由于包“3”被冗余編碼到第4個傳輸包中，在對端接收到碼流后還可以正常重構出包“3”。

2.1.3 丟包重發

    利用實時傳輸控制協議RTCP反饋信息提供丟包重發功能，當接收端檢測到有丟包時，判定對端是否來得及進行重發，可以的話通過RTCP控制信道向發送端請求重發。

圖3 丟抱重發處理過程示意圖

    圖中包“2”在傳輸過程中丟失，接收端根據包往返時間及包解碼等待時間判定包“2”可以在容許的時間內重新傳送到接收端，所以通過RTCP通道向發送端請求包“2”重發。

2.1.4 帶寬自適應

    在RTP會話期間，各會議參與者周期性地傳送RTCP包，RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料。因此，發送端可以利用這些信息動態地改變傳輸速率以適應網絡的異常變化，當出現網絡擁塞時降低發送速率，當網絡恢復正常時恢復正常發送速率。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率達到最佳化。

圖4 帶寬自適應處理過程示意圖

2.1.5 抖動重整

    由于收到中間路由交換時延抖動、擁塞影響，導致數據包到達接收端產生亂序現象，這樣直接把數據包進行解碼的話會導致圖像出現停頓、馬賽克等現象，接收端會進行一次抖動重整，按照接收到包的時戳恢復數據包原來的順序。

圖5 抖動重整處理過程示意圖