1 概述
由于IP寬帶網(wǎng)絡(luò)不斷普及,一般單位在建設(shè)視訊會議時都會考慮在IP寬帶網(wǎng)絡(luò)上進行。由于視訊會議中需要實時交換視音頻數(shù)據(jù),所以在IP視訊會議中視頻和音頻信息采用承載在UDP上的RTP通道進行傳輸,RTP不提供任何機制來確保數(shù)據(jù)的按時發(fā)送或保證服務(wù)的質(zhì)量,甚至不能保證分組數(shù)據(jù)的順序遞交,一旦中間傳輸網(wǎng)絡(luò)出現(xiàn)點異常如網(wǎng)絡(luò)擁塞、震蕩就會導(dǎo)致接收端接收到的數(shù)據(jù)產(chǎn)生丟包、亂序、延時等現(xiàn)象,使得接收終端不能解碼出流暢聲音與圖像,出現(xiàn)聲音停頓、圖像馬賽克等現(xiàn)象。
2 NAA技術(shù)
在視訊會議中由于RTP通道不能為視音頻數(shù)據(jù)提供良好的Qos保障,導(dǎo)致視訊會議在實際應(yīng)用中效果受到很大影響,杭州華三通信技術(shù)有限公司在充分分析問題的基礎(chǔ)上,依靠自身在IP領(lǐng)域技術(shù)雄厚積累與視音頻技術(shù)深入研究,提出了視訊會議NAA(Network Auto-Adaptability,網(wǎng)絡(luò)自適應(yīng))技術(shù)(以下簡稱“NAA”),為視訊會議提供端到端良好的Qos保障。 NAA在傳輸層面與編解碼層面對視音頻的質(zhì)量進行了特性保障:
2.1 傳輸層
2.1.1 PQ隊列
視訊會議端點設(shè)備支持IP DiffServe服務(wù)模型。在視音頻報文發(fā)送之前把報文優(yōu)先級設(shè)置為高優(yōu)先級(如下圖中的“緊急報文”),當路由設(shè)備接收到這些視音頻報文會優(yōu)先轉(zhuǎn)發(fā),報文的丟失率和時延這兩個性能指標在網(wǎng)絡(luò)擁塞時也可以有一定的保障。
圖1 PQ隊列處理過程示意圖
在報文到達路由設(shè)備接口后首先對報文進行分類,然后按照報文所屬的類別讓報文進入所屬隊列的尾部,在報文發(fā)送時按照優(yōu)先級總是在所有優(yōu)先級較高的隊列中的報文發(fā)送完畢后再發(fā)送低優(yōu)先級隊列中的報文,這樣在每次發(fā)送報文時總是將優(yōu)先級高的報文先發(fā)出去,保證了屬于較高優(yōu)先級隊列的報文有較低的時延與丟失率。
2.1.2 冗余糾錯
在傳輸帶寬允許的情況下,在發(fā)送端對重要的宏塊進行冗余編碼,發(fā)送給對端,這樣的話當網(wǎng)絡(luò)出現(xiàn)異常出現(xiàn)丟包時,可以最大限度保護重要的編碼宏塊不丟失。如下:
圖2 冗余糾錯處理過程示意圖
當?shù)?個包在傳輸過程中丟失時,由于包“3”被冗余編碼到第4個傳輸包中,在對端接收到碼流后還可以正常重構(gòu)出包“3”。
2.1.3 丟包重發(fā)
利用實時傳輸控制協(xié)議RTCP反饋信息提供丟包重發(fā)功能,當接收端檢測到有丟包時,判定對端是否來得及進行重發(fā),可以的話通過RTCP控制信道向發(fā)送端請求重發(fā)。
圖3 丟抱重發(fā)處理過程示意圖
圖中包“2”在傳輸過程中丟失,接收端根據(jù)包往返時間及包解碼等待時間判定包“2”可以在容許的時間內(nèi)重新傳送到接收端,所以通過RTCP通道向發(fā)送端請求包“2”重發(fā)。
2.1.4 帶寬自適應(yīng)
在RTP會話期間,各會議參與者周期性地傳送RTCP包,RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料。因此,發(fā)送端可以利用這些信息動態(tài)地改變傳輸速率以適應(yīng)網(wǎng)絡(luò)的異常變化,當出現(xiàn)網(wǎng)絡(luò)擁塞時降低發(fā)送速率,當網(wǎng)絡(luò)恢復(fù)正常時恢復(fù)正常發(fā)送速率。RTP和RTCP配合使用,它們能以有效的反饋和最小的開銷使傳輸效率達到最佳化。
圖4 帶寬自適應(yīng)處理過程示意圖
2.1.5 抖動重整
由于收到中間路由交換時延抖動、擁塞影響,導(dǎo)致數(shù)據(jù)包到達接收端產(chǎn)生亂序現(xiàn)象,這樣直接把數(shù)據(jù)包進行解碼的話會導(dǎo)致圖像出現(xiàn)停頓、馬賽克等現(xiàn)象,接收端會進行一次抖動重整,按照接收到包的時戳恢復(fù)數(shù)據(jù)包原來的順序。
圖5 抖動重整處理過程示意圖