基于機頂盒VoIP語音解碼模塊的設計與驗證

2012-09-12 03:22:32高健

電子測試 2012年1期

高健

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

0 引言

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

圖1 VoIP基本原理圖

1 機頂盒VoIP硬件平臺

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

圖2 機頂盒硬件平臺

2 基于機頂盒的VoIP軟件架構

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

圖3 基于機頂盒的VoIP系統架構圖

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

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

3 VoIP解碼難點——實時性

3.1 丟包

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

3.2 時延

時延是接收到的數據包與發送數據包的時間差。時延又分為算法時延、處理時延、網絡傳輸時延和抖動緩沖時延。

3.3 抖動

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

抖動原因：排隊時延；可變的分組大小；中間鏈路和路由器上的相對負載。

3.4 包亂序

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

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

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

4.1 語音編解碼的選取

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

表1 語音編解碼性能比較

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

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

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

4.2 解碼端緩存技術

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

4.3 終端采用的網絡控制策略

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

4.3.1 采用RTP/RTCP協議[3-4]

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

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

4.3.2 采用Qos機制

(1) 采用靜音檢測技術

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

(2) 采用資源預留協議

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

4.3.3 采用SIP信令技術[8]

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

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