基于機(jī)頂盒VoIP語(yǔ)音解碼模塊的設(shè)計(jì)與驗(yàn)證

高健

（1 重慶郵電大學(xué) 重慶 400065；2 重慶四聯(lián)微電子有限公司 重慶 401121）

0 引言

VoIP是Voice Over Internet Protocol的縮寫(xiě)，是建立在IP技術(shù)上的分組化，數(shù)字化傳輸技術(shù)[1]，其基本原理如圖1所示。近年來(lái)，VoIP以其低帶寬和低廉的通信費(fèi)得到了廣泛應(yīng)用。隨著三網(wǎng)融合，將VoIP應(yīng)用于機(jī)頂盒已成為該行業(yè)關(guān)注的熱點(diǎn)。本文依托重慶四聯(lián)微電子有限公司機(jī)頂盒VoIP項(xiàng)目，基于公司機(jī)頂盒硬件平臺(tái)，提出了一種機(jī)頂盒VoIP解碼模塊軟件設(shè)計(jì)方案，對(duì)機(jī)頂盒VoIP的開(kāi)發(fā)實(shí)現(xiàn)具有重要意義。

圖1 VoIP基本原理圖

1 機(jī)頂盒VoIP硬件平臺(tái)

圖2為機(jī)頂盒硬件平臺(tái)，該系統(tǒng)由微處理器、電源模塊、音頻處理模塊、串口和USB接口模塊、以太網(wǎng)口模塊、數(shù)據(jù)存儲(chǔ)模塊以及系統(tǒng)工作狀態(tài)指示模塊構(gòu)成[2]。其中，該微處理器采用重慶四聯(lián)微電子公司自主研發(fā)的sic8008高清解碼芯片。通過(guò)外接USB話(huà)機(jī)對(duì)語(yǔ)音信號(hào)進(jìn)行采樣和播放，從而完成終端VoIP功能。

圖2 機(jī)頂盒硬件平臺(tái)

2 基于機(jī)頂盒的VoIP軟件架構(gòu)

圖3為基于機(jī)頂盒硬件平臺(tái)在Linux系統(tǒng)構(gòu)架的VoIP語(yǔ)音終端軟件系統(tǒng)。此系統(tǒng)依據(jù)iLBC編解碼算法、SIP信令協(xié)議、UDP、TCP/IP協(xié)議以及RTP實(shí)時(shí)傳輸協(xié)議等完成語(yǔ)音壓縮編碼、語(yǔ)音傳輸和解壓縮解碼恢復(fù)原始語(yǔ)音數(shù)據(jù)等功能來(lái)實(shí)現(xiàn)VoIP語(yǔ)音終端的會(huì)話(huà)功能，其VoIP語(yǔ)音會(huì)話(huà)過(guò)程如下。

圖3 基于機(jī)頂盒的VoIP系統(tǒng)架構(gòu)圖

說(shuō)話(huà)方：USB話(huà)機(jī)采集模擬語(yǔ)音信號(hào)→USB話(huà)機(jī)語(yǔ)音芯片采樣量化編碼成PCM信號(hào)→ sic8008芯片對(duì)信號(hào)進(jìn)行壓縮編碼→ RTP格式打包→UDP格式打包→ IP格式打包→ Internet網(wǎng)絡(luò)傳輸。

收聽(tīng)方：接收語(yǔ)音數(shù)據(jù)→去IP/UDP/RTP包頭→ 將接收到的有效信號(hào)存放在sic8008芯片的硬件平臺(tái)上，然后對(duì)該信號(hào)解壓縮、解碼還原成PCM信號(hào) USB話(huà)機(jī)語(yǔ)音芯片將PCM轉(zhuǎn)為模擬信號(hào)→揚(yáng)聲器播放。

3 VoIP解碼難點(diǎn)——實(shí)時(shí)性

3.1 丟包

丟包率定義為在網(wǎng)絡(luò)傳輸數(shù)據(jù)包時(shí)丟棄數(shù)據(jù)包的最高比率。丟包率應(yīng)小于5%，當(dāng)丟包率超過(guò)10%時(shí)將極大影響服務(wù)質(zhì)量。丟包的原因：線路誤碼或網(wǎng)絡(luò)路由故障；傳輸時(shí)延過(guò)長(zhǎng)或網(wǎng)絡(luò)擁塞導(dǎo)致分組被丟棄。

3.2 時(shí)延

時(shí)延是接收到的數(shù)據(jù)包與發(fā)送數(shù)據(jù)包的時(shí)間差。時(shí)延又分為算法時(shí)延、處理時(shí)延、網(wǎng)絡(luò)傳輸時(shí)延和抖動(dòng)緩沖時(shí)延。

3.3 抖動(dòng)

抖動(dòng)也叫時(shí)延變化，是指由于各種延時(shí)的變化導(dǎo)致網(wǎng)絡(luò)中的數(shù)據(jù)分組到達(dá)速率的變化。如果網(wǎng)絡(luò)抖動(dòng)比較嚴(yán)重，那么有的話(huà)音包會(huì)因遲到而被丟棄，會(huì)產(chǎn)生話(huà)音的斷續(xù)及部分失真，嚴(yán)重影響音質(zhì)。延遲的變化應(yīng)該在10%以?xún)?nèi)為好。

抖動(dòng)原因：排隊(duì)時(shí)延；可變的分組大?。恢虚g鏈路和路由器上的相對(duì)負(fù)載。

3.4 包亂序

當(dāng)網(wǎng)絡(luò)較差的時(shí)候，語(yǔ)音包在傳輸過(guò)程中很容易出現(xiàn)亂序現(xiàn)象，從而影響接收端播放。但是根據(jù)每個(gè)語(yǔ)音包的時(shí)間戳，可以方便地判斷出語(yǔ)音包的發(fā)送順序。通常采用的解決方法是在接收端使用抖動(dòng)緩存，對(duì)失序包進(jìn)行調(diào)整，從而重現(xiàn)發(fā)端順序。

4 VoIP語(yǔ)音解碼端設(shè)計(jì)與驗(yàn)證

針對(duì)影響解碼端實(shí)時(shí)性因素，本設(shè)計(jì)從語(yǔ)音編解碼選取、解碼端緩存技術(shù)和終端采用網(wǎng)絡(luò)控制策略3個(gè)角度確定了解碼端具體設(shè)計(jì)方案，并通過(guò)VoIP系統(tǒng)通話(huà)測(cè)試驗(yàn)證了方案可行性。

4.1 語(yǔ)音編解碼的選取

好的語(yǔ)音編解碼應(yīng)具有低碼率、低帶寬、低時(shí)延和適當(dāng)算法復(fù)雜度。iLBC是一種開(kāi)源編解碼算法，以窄帶語(yǔ)音為設(shè)計(jì)基礎(chǔ)，具有8kHz的采樣率，它對(duì)每個(gè)數(shù)據(jù)包的處理都能夠獨(dú)立于其它數(shù)據(jù)包來(lái)進(jìn)行，是數(shù)據(jù)包通信的理想選擇。如表1可知，iLBC的MOS及編解碼延時(shí)優(yōu)于目前流行的G.729、G.723.1。

表1 語(yǔ)音編解碼性能比較

另外，iLBC對(duì)丟包進(jìn)行了特有處理，即便在丟包率相當(dāng)高的網(wǎng)絡(luò)環(huán)境下，仍可獲得較清晰的語(yǔ)音效果。如圖4給出了不同網(wǎng)絡(luò)丟包環(huán)境下，iLBC,G.729A和G.723.1編解碼算法的語(yǔ)音質(zhì)量性能仿真。該仿真以網(wǎng)上實(shí)際IP包丟失的觀察統(tǒng)計(jì)為基礎(chǔ)，模擬了（0—15）%丟包率。由圖觀察可以發(fā)現(xiàn)，當(dāng)沒(méi)有丟包時(shí)，MOS值分別為3.981,3.880,3.695，由此可以看出，iLBC編解碼器的語(yǔ)音質(zhì)量和G.729A及G.723.1相比相差不大。然而。當(dāng)丟包嚴(yán)重時(shí)，iLBC比G.729A和G.723.1的語(yǔ)音質(zhì)量明顯好。

圖4 丟包率為(0-15)%時(shí)iLBC,G.729A和G.723.1的MOS對(duì)比

iLBC編解碼的出現(xiàn)，改善了在包交換的IP網(wǎng)絡(luò)中，傳輸語(yǔ)音所遇到的網(wǎng)絡(luò)丟包嚴(yán)重影響通話(huà)質(zhì)量等實(shí)際問(wèn)題，實(shí)現(xiàn)了“語(yǔ)音質(zhì)量的飛躍”，是語(yǔ)音包通信的理想選擇。

4.2 解碼端緩存技術(shù)

本設(shè)計(jì)將在解碼端采用動(dòng)態(tài)確定時(shí)限和動(dòng)態(tài)分配緩沖區(qū)的策略。當(dāng)網(wǎng)絡(luò)狀況好的時(shí)候，網(wǎng)絡(luò)時(shí)延和抖動(dòng)都比較小，此時(shí)緩沖區(qū)可以設(shè)定為一個(gè)較小的值，以減少端到端的時(shí)延和抖動(dòng)。當(dāng)網(wǎng)絡(luò)發(fā)生擁塞時(shí)，時(shí)延和抖動(dòng)都比較大，此時(shí)緩沖區(qū)可以設(shè)定為一個(gè)較大的值等待遲到的那些語(yǔ)音分組，減少丟包率。

4.3 終端采用的網(wǎng)絡(luò)控制策略

所謂網(wǎng)絡(luò)控制策略是合理利用現(xiàn)有的各種協(xié)議和語(yǔ)音處理技術(shù)，綜合帶寬、時(shí)延和丟包率因素找到相對(duì)好的平衡點(diǎn)，從而提高VoIP語(yǔ)音通話(huà)性能指標(biāo)，滿(mǎn)足語(yǔ)音通話(huà)要求。具體設(shè)計(jì)方案如下。

4.3.1 采用RTP/RTCP協(xié)議[3-4]

RTP作為實(shí)時(shí)傳輸協(xié)議用于傳輸實(shí)時(shí)數(shù)據(jù)，能為實(shí)時(shí)業(yè)務(wù)提供端到端的傳遞服務(wù)。其功能是提供凈荷類(lèi)型指示(即數(shù)據(jù)類(lèi)型和編碼方式)、數(shù)據(jù)分組序號(hào)、數(shù)據(jù)發(fā)送時(shí)間戳和數(shù)據(jù)源指示，接收端則能根據(jù)這些信息正確地重組原始信號(hào)。

RTCP(實(shí)時(shí)傳輸控制協(xié)議)是RTP協(xié)議中的控制功能協(xié)議，它單獨(dú)運(yùn)行在底層協(xié)議上。RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或者擁塞控制，它依靠RTCP提供這些服務(wù)。RTCP采用與數(shù)據(jù)包相同的分配機(jī)制，周期性地向RTP會(huì)話(huà)的參與者發(fā)送控制包，應(yīng)用程序通過(guò)接收這些數(shù)據(jù)包，從中獲取會(huì)話(huà)參與者的相關(guān)資料，以及網(wǎng)絡(luò)狀況、分組丟失概率等反饋信息，從而能夠?qū)Ψ?wù)質(zhì)量進(jìn)行控制或者對(duì)網(wǎng)絡(luò)狀況進(jìn)行診斷，并能夠?qū)W(wǎng)絡(luò)擁塞進(jìn)行有效的控制。

4.3.2 采用Qos機(jī)制

(1) 采用靜音檢測(cè)技術(shù)

靜音檢測(cè)是數(shù)字信號(hào)處理器應(yīng)用的一種靜音壓縮技術(shù)。大多數(shù)會(huì)話(huà)中一方說(shuō)話(huà)和聽(tīng)對(duì)方說(shuō)話(huà)的時(shí)間約各占一半，而且說(shuō)話(huà)時(shí)還有停頓間隙，因此話(huà)音活動(dòng)度只占40左右，而約60的時(shí)間是安靜的。由于分組交換中的傳輸通道是統(tǒng)計(jì)復(fù)用的，因此，在靜音時(shí)間段里可以不發(fā)送話(huà)音分組，從而進(jìn)一步降低話(huà)音比特率[5]。

(2) 采用資源預(yù)留協(xié)議

資源預(yù)留協(xié)議(RSVP)可以為應(yīng)用提供有保障的帶寬，有效減少了傳輸延遲和抖動(dòng)，保證信息傳輸?shù)膶?shí)時(shí)性和可靠性。當(dāng)終端需要在一條路徑上預(yù)留帶寬時(shí)，會(huì)通過(guò)RSVP協(xié)議向目的端發(fā)出一條消息，該消息作用于路徑上的所有節(jié)點(diǎn)，并含有數(shù)據(jù)流信息，包括平均速率、突發(fā)數(shù)據(jù)包長(zhǎng)度等。當(dāng)路徑上的節(jié)點(diǎn)收到消息后，分析數(shù)據(jù)流信息，決定應(yīng)保留多少帶寬。如果此時(shí)可用帶寬不足則拒絕申請(qǐng)，否則設(shè)置隊(duì)列管理方法，同時(shí)將消息向下一個(gè)節(jié)點(diǎn)傳送[6-7]。

4.3.3 采用SIP信令技術(shù)[8]

完成用戶(hù)定位，呼叫的建立，應(yīng)答和交互用戶(hù)信息等功能，保證會(huì)話(huà)的順利進(jìn)行。

綜上所述，本文機(jī)頂盒VoIP解碼模塊具體設(shè)計(jì)如圖5所示。該設(shè)計(jì)采用了上述iLBC解碼算法、解碼緩存技術(shù)以及相關(guān)協(xié)議，從理論上保證了VoIP解碼端語(yǔ)音實(shí)時(shí)性。

圖5 機(jī)頂盒VoIP解碼模塊設(shè)計(jì)方案

4.4 設(shè)計(jì)驗(yàn)證

本設(shè)計(jì)基于Linux系統(tǒng)編寫(xiě)C代碼實(shí)現(xiàn)，并結(jié)合整個(gè)項(xiàng)目資源對(duì)機(jī)頂盒VoIP原型系統(tǒng)進(jìn)行了通話(huà)測(cè)試，測(cè)試結(jié)果如圖6所示。由圖6可知，通過(guò)運(yùn)行voip.elf可執(zhí)行程序，撥打接聽(tīng)方IP，該機(jī)頂盒VoIP能夠完成“建立連接-通話(huà)-結(jié)束通話(huà)”整個(gè)過(guò)程，從而驗(yàn)證了本文提出的機(jī)頂盒VoIP解碼端設(shè)計(jì)方案。

圖6 機(jī)頂盒終端的VoIP通話(huà)測(cè)試

5 結(jié)論

本文提出了一種實(shí)現(xiàn)機(jī)頂盒VoIP解碼模塊的設(shè)計(jì)方案，并通過(guò)測(cè)試驗(yàn)證了設(shè)計(jì)方案的可行性。為后續(xù)開(kāi)發(fā)實(shí)現(xiàn)穩(wěn)定實(shí)時(shí)的機(jī)頂盒VoIP終端奠定了基礎(chǔ)。

[1]Daniel Collins.VoIP 技術(shù)與應(yīng)用[M].北京:人民郵電出版社,2003:20-30.

[2]SIC8008芯片使用說(shuō)明[P].重慶四聯(lián)微電子,2011(2):18-19.

[3]方立杰,劉毓.VoIP中關(guān)鍵技術(shù)的研究[J].科技廣場(chǎng),2010(3):42-45.

[4]張鈳,謝忠誠(chéng),鞠丸濱.基于實(shí)時(shí)傳輸協(xié)議的丟包實(shí)時(shí)修復(fù)[J].軟件學(xué)報(bào),2001,12(7):1042-1049.

[5]徐山峰.基于SIP協(xié)議的VoIP系統(tǒng)的OoS機(jī)制的研究[J].無(wú)線通信,2009(12):58-62.

[6]王建新,裴慧民.基于IP的QoS體系結(jié)構(gòu)及路由策略研究[J].電信快報(bào),2001(1O):26-28.

[7]陳宏.提高VoIP服務(wù)質(zhì)量的關(guān)鍵技術(shù)[R].信息通信,2005(2):24-26.

[8]Handly M,Schulzrinne H,Schooler E,et a1.RFC2543 SIP:Session Initiation Protocol[S].March 1999.