高健

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

0 引言

VoIP是Voice Over Internet Protocol的縮寫，是建立在IP技術(shù)上的分組化，數(shù)字化傳輸技術(shù)[1]，其基本原理如圖1所示。近年來，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的開發(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高清解碼芯片。通過外接USB話機(jī)對(duì)語音信號(hào)進(jìn)行采樣和播放，從而完成終端VoIP功能。

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

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

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

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

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

收聽方：接收語音數(shù)據(jù)→去IP/UDP/RTP包頭→ 將接收到的有效信號(hào)存放在sic8008芯片的硬件平臺(tái)上，然后對(duì)該信號(hào)解壓縮、解碼還原成PCM信號(hào) USB話機(jī)語音芯片將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)丟包率超過10%時(shí)將極大影響服務(wù)質(zhì)量。丟包的原因：線路誤碼或網(wǎng)絡(luò)路由故障；傳輸時(shí)延過長或網(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ì)產(chǎn)生話音的斷續(xù)及部分失真，嚴(yán)重影響音質(zhì)。延遲的變化應(yīng)該在10%以內(nèi)為好。

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

3.4 包亂序

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

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

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

4.1 語音編解碼的選取

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

表1 語音編解碼性能比較

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

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

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

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è)較大的值等待遲到的那些語音分組，減少丟包率。

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

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

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

RTP作為實(shí)時(shí)傳輸協(xié)議用于傳輸實(shí)時(shí)數(shù)據(jù)，能為實(shí)時(shí)業(yè)務(wù)提供端到端的傳遞服務(wù)。其功能是提供凈荷類型指示(即數(shù)據(jù)類型和編碼方式)、數(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ì)話的參與者發(fā)送控制包，應(yīng)用程序通過接收這些數(shù)據(jù)包，從中獲取會(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) 采用靜音檢測技術(shù)

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

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

資源預(yù)留協(xié)議(RSVP)可以為應(yīng)用提供有保障的帶寬，有效減少了傳輸延遲和抖動(dòng)，保證信息傳輸?shù)膶?shí)時(shí)性和可靠性。當(dāng)終端需要在一條路徑上預(yù)留帶寬時(shí)，會(huì)通過RSVP協(xié)議向目的端發(fā)出一條消息，該消息作用于路徑上的所有節(jié)點(diǎn)，并含有數(shù)據(jù)流信息，包括平均速率、突發(fā)數(shù)據(jù)包長度等。當(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]

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

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

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

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

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

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

5 結(jié)論

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

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

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

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

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

[5]徐山峰.基于SIP協(xié)議的VoIP系統(tǒng)的OoS機(jī)制的研究[J].無線通信,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.