1 概述

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

2 NAA技術(shù)

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

2.1 傳輸層

2.1.1 PQ隊(duì)列

    視訊會(huì)議端點(diǎn)設(shè)備支持IP DiffServe服務(wù)模型。在視音頻報(bào)文發(fā)送之前把報(bào)文優(yōu)先級(jí)設(shè)置為高優(yōu)先級(jí)（如下圖中的“緊急報(bào)文”），當(dāng)路由設(shè)備接收到這些視音頻報(bào)文會(huì)優(yōu)先轉(zhuǎn)發(fā)，報(bào)文的丟失率和時(shí)延這兩個(gè)性能指標(biāo)在網(wǎng)絡(luò)擁塞時(shí)也可以有一定的保障。

圖1 PQ隊(duì)列處理過(guò)程示意圖

    在報(bào)文到達(dá)路由設(shè)備接口后首先對(duì)報(bào)文進(jìn)行分類(lèi)，然后按照?qǐng)?bào)文所屬的類(lèi)別讓報(bào)文進(jìn)入所屬隊(duì)列的尾部，在報(bào)文發(fā)送時(shí)按照優(yōu)先級(jí)總是在所有優(yōu)先級(jí)較高的隊(duì)列中的報(bào)文發(fā)送完畢后再發(fā)送低優(yōu)先級(jí)隊(duì)列中的報(bào)文，這樣在每次發(fā)送報(bào)文時(shí)總是將優(yōu)先級(jí)高的報(bào)文先發(fā)出去，保證了屬于較高優(yōu)先級(jí)隊(duì)列的報(bào)文有較低的時(shí)延與丟失率。

2.1.2 冗余糾錯(cuò)

    在傳輸帶寬允許的情況下，在發(fā)送端對(duì)重要的宏塊進(jìn)行冗余編碼，發(fā)送給對(duì)端，這樣的話(huà)當(dāng)網(wǎng)絡(luò)出現(xiàn)異常出現(xiàn)丟包時(shí)，可以最大限度保護(hù)重要的編碼宏塊不丟失。如下：

圖2 冗余糾錯(cuò)處理過(guò)程示意圖

    當(dāng)?shù)?個(gè)包在傳輸過(guò)程中丟失時(shí)，由于包“3”被冗余編碼到第4個(gè)傳輸包中，在對(duì)端接收到碼流后還可以正常重構(gòu)出包“3”。

2.1.3 丟包重發(fā)

    利用實(shí)時(shí)傳輸控制協(xié)議RTCP反饋信息提供丟包重發(fā)功能，當(dāng)接收端檢測(cè)到有丟包時(shí)，判定對(duì)端是否來(lái)得及進(jìn)行重發(fā)，可以的話(huà)通過(guò)RTCP控制信道向發(fā)送端請(qǐng)求重發(fā)。

圖3 丟抱重發(fā)處理過(guò)程示意圖

    圖中包“2”在傳輸過(guò)程中丟失，接收端根據(jù)包往返時(shí)間及包解碼等待時(shí)間判定包“2”可以在容許的時(shí)間內(nèi)重新傳送到接收端，所以通過(guò)RTCP通道向發(fā)送端請(qǐng)求包“2”重發(fā)。

2.1.4 帶寬自適應(yīng)

    在RTP會(huì)話(huà)期間，各會(huì)議參與者周期性地傳送RTCP包，RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料。因此，發(fā)送端可以利用這些信息動(dòng)態(tài)地改變傳輸速率以適應(yīng)網(wǎng)絡(luò)的異常變化，當(dāng)出現(xiàn)網(wǎng)絡(luò)擁塞時(shí)降低發(fā)送速率，當(dāng)網(wǎng)絡(luò)恢復(fù)正常時(shí)恢復(fù)正常發(fā)送速率。RTP和RTCP配合使用，它們能以有效的反饋和最小的開(kāi)銷(xiāo)使傳輸效率達(dá)到最佳化。

圖4 帶寬自適應(yīng)處理過(guò)程示意圖

2.1.5 抖動(dòng)重整

    由于收到中間路由交換時(shí)延抖動(dòng)、擁塞影響，導(dǎo)致數(shù)據(jù)包到達(dá)接收端產(chǎn)生亂序現(xiàn)象，這樣直接把數(shù)據(jù)包進(jìn)行解碼的話(huà)會(huì)導(dǎo)致圖像出現(xiàn)停頓、馬賽克等現(xiàn)象，接收端會(huì)進(jìn)行一次抖動(dòng)重整，按照接收到包的時(shí)戳恢復(fù)數(shù)據(jù)包原來(lái)的順序。

圖5 抖動(dòng)重整處理過(guò)程示意圖