高健

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

0 引言

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

圖1 VoIP基本原理圖

1 機頂盒VoIP硬件平臺

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

圖2 機頂盒硬件平臺

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

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

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

說話方：USB話機采集模擬語音信號→USB話機語音芯片采樣量化編碼成PCM信號→ sic8008芯片對信號進行壓縮編碼→ RTP格式打包→UDP格式打包→ IP格式打包→ Internet網(wǎng)絡傳輸。

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

3 VoIP解碼難點——實時性

3.1 丟包

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

3.2 時延

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

3.3 抖動

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

抖動原因：排隊時延；可變的分組大?。恢虚g鏈路和路由器上的相對負載。

3.4 包亂序

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

4 VoIP語音解碼端設計與驗證

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

4.1 語音編解碼的選取

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

表1 語音編解碼性能比較

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

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

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

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

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

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

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

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

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

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

4.3.2 采用Qos機制

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

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

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

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

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

完成用戶定位，呼叫的建立，應答和交互用戶信息等功能，保證會話的順利進行。

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

圖5 機頂盒VoIP解碼模塊設計方案

4.4 設計驗證

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

圖6 機頂盒終端的VoIP通話測試

5 結(jié)論

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

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

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

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

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

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

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

[7]陳宏.提高VoIP服務質(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.