基于Ｓｐｅｅｘ語音引擎的ＶｏＩＰ系統設計與實現

摘要：論述了一套基于Speex語音引擎和RTP的VoIP系統設計和開發，介紹了該系統服務器端和客戶機端的軟件實現。該系統具有點對點通信、算法延時小、丟包補償和延時補償性能好等特點，并具有多方通話功能。性能對比實驗表明，該系統的通話質量優于幾套流行的開源VoIP軟件，能滿足實際應用的要求。

關鍵詞：基于IP網絡的語音傳輸； Speex； 實時傳輸協議； 多方通話

中圖分類號：TP393文獻標志碼：A

文章編號：1001-3695(2007)12-0320-04

網絡電話VoIP^[1]是基于IP網絡的語音傳輸技術，它將語音的模擬信號轉換成數字信號并在Internet上進行傳輸。簡單地說，它是首先通過一連串的A/D轉換、編碼、壓縮、打包等程序來處理語音信號，并將語音數據在IP網絡上傳輸到目的端，然后再經由相反的一連串程序，將語音數據還原成原來的語音信號播放給接聽者。VoIP目前已被廣泛地應用于全球IP互聯的Internet環境中。它與模擬語音通信系統相比具有抗干擾性強、保密性好、易于集成、成本低廉等特點，并可開發出更多的增值業務。然而，IP網絡的語音傳輸質量成為制約VoIP發展的瓶頸。基于分組交換的IP網絡使得VoIP系統存在分組延遲、延遲抖動、丟包等問題，使得用戶聽到的話音會出現不連貫甚至中斷的現象。現有的VoIP系統還難以實現高質量的實時語音通信。如何提高語音通信質量是近年來VoIP技術研究的一個重要課題。

Speex^[2，3]是近年來開發出的一套功能強大的語音引擎，能夠實現高質量和低比特率的編碼。它不僅提供了基于碼激勵線性預測（CELP）算法的編/解碼模塊，而且在其最新發布的版本中還提供了聲音預處理和聲學回聲消除模塊，為保障IP網絡中的語音通信質量提供了技術手段。此外，Speex還具有壓縮后的比特率低（2~44 kbps）的特點，并支持多種比特率。這些特點使得Speex特別適合VoIP的系統。

伴隨著VoIP應用的熱潮，目前國內外出現了很多關于VoIP的系統實現，但是大多數系統設計均是基于直接使用IP地址進行呼叫。這就存在一些弊端，如呼叫方必須事先知道對方的IP地址，而這無形中降低了系統的可用性。本文在Speex和RTP（實時傳輸協議）^[4]的基礎上，論述了一套基于客戶機/服務器模式的VoIP系統的設計與開發。該系統克服了上述弊端，提高了VoIP系統的友好性和可推廣性。經過實驗測試，本系統即使在網絡條件較差的情況下，也能達到較好的語音通信效果，而且支持3~5人的多方通話。

1Speex概述

Speex是近年來開發出的一種基于碼激勵線性預測算法的開源軟件語音引擎。它主要面向Internet上的語音通信。其主要設計目標是為了提供高質量和低比特率的語音編碼。Speex編碼支持多種比特率，如8 kHz采樣的低比特率（窄帶2．15~24．6 kbps）、16 kHz采樣的中比特率（寬帶3．95~42．2 kbps）以及32 kHz采樣的高比特率（ultra－wideband）。Speex提供了大多數別的編/解碼器所不具備的技術性能，主要包括：可以在同一個比特流中對語音信號實現窄帶（8 kHz）、寬帶（16 kHz）和超寬帶（32 kHz）的壓縮；支持聲音強度的立體聲編碼；具有丟包補償能力；具有可變比特率（variable bitrate，VBR）特性，編/解碼器可以在任意時刻動態地改變語音的比特率；能實現語音活動檢測（voice activity detection，VAD）；能實現聲音的DTX（discontinuous transmission，不連續傳輸），當背景噪聲穩定時，可以完全停止聲音數據包的傳送；具有語音處理的定點數計算功能（正在開發中）；具有聲學回聲消除功能。

Speex除了編/解碼模塊外，還包括噪聲消除、靜音抑制和自動增益控制等預處理模塊以及回聲消除模塊。正是由于其完備的功能和優良的性能，Speex受到了許多VoIP開發者的關注。2006年9月發布的最新版本Speex 1．2 beta1在聲音處理性能上得到了進一步的改善。語音編碼和解碼的質量有了明顯的提高。軟件運行時的內存使用有了大幅度的降低，定點計算情況下窄帶編/解碼的內存開銷下降為不到原來的一半，只需占用不到6 KB的RAM空間，而且CPU的占用率也有了下降，使Speex在諸如PDA等便攜式語音通信設備中的應用成為可能。

Speex提供了一系列調用其各個功能模塊的API，使得開發者可以很方便地使用這些功能模塊來進行VoIP系統的編程開發。各模塊的API在文獻[3]中有詳細描述。在新版本的Speex中，回聲消除模塊的API有了改進，開發者能更方便地調用這個模塊。此外，抖動緩沖區（jitter buffer）模塊不再專門針對Speex編碼，從而可以應用于其他編碼格式的系統。這些特點都為Speex在VoIP系統中的應用奠定了基礎。

2系統的功能模塊結構

本文所述的VoIP系統采用Speex編碼。整個系統由服務器端和客戶端兩部分構成。系統總體框架如圖1所示。

數據庫服務器上保存了所有已注冊用戶的資料。每個用戶首先要通過客戶端登錄到服務器上，并獲取在線好友的列表，然后才能對在線的好友進行語音呼叫。客戶端之間的通話采用點對點的方式進行。這就避免了由于語音包經過服務器中轉所造成的過大延遲。

2．1服務器端的設計與實現

服務器端除了需要維護一個數據庫以保存用戶信息外，還要對各個客戶端進行指揮和管理。

服務器一旦啟動服務，則開始偵聽用戶請求。服務器收到客戶端發來的消息時，首先，發回確認信息；然后，建立一個獨立線程來處理接收到的數據。在此線程中，按照接收到數據的類別進行相應的處理。如有需要，服務器會向用戶發送處理的結果，成功或失敗的消息。處理完畢，此線程結束。這樣，可以實時接收每個用戶的請求，不會因為處理某一個用戶的請求，而忽略了其他用戶。服務器端的工作流程如圖2所示。

2．2客戶端的設計與實現

客戶端的功能可以分為兩部分：一部分是與服務器端進行交互，從服務器上獲取相關信息；另一部分是完成不同客戶端之間的點對點通話。其中第二部分是VoIP系統的核心。

客戶端程序啟動后，若有本地用戶信息，則加載本地用戶信息，并顯示登錄窗口；若沒有，則顯示用戶注冊窗口（在登錄窗口中，也可以選擇用戶注冊）。登錄時，可選擇是否隱身，并發送賬號和密碼到服務器進行驗證，如正確則成功登錄；否則失敗。當成功登錄進入系統后，服務器將發送用戶的全部好友信息以及在線好友信息（包含好友的IP和端口號）。在好友列表中，在線者將以高亮度顯示，并處在列表的頂部；不在線者將以灰色顯示。如果有好友上線，系統會立即通知用戶；好友下線，用戶也可以在好友列表中看到。用戶可以接收到好友發來的語音通話的請求，同時根據用戶的操作，客戶端可以向好友給出回應，接聽或拒絕。系統還具有查看好友信息、查看在線用戶、查找用戶和修改個人信息等功能。若用戶選擇注冊，在填寫注冊信息后，信息被發送到服務器；服務器登記用戶注冊信息后則會發送回由系統自動分配的賬號；然后用戶就可以成功登錄系統。客戶端的工作流程如圖3所示。

3點對點通話模型

最基本的VoIP系統應該包含錄音模塊、放音模塊、編碼模塊、解碼模塊、接收模塊和發送模塊。本系統除了這些基本模塊之外，還在編碼之前增加了Speex的回聲消除和預處理模塊。

本系統的運行期結構（run－time architecture）由六個線程組成，如圖4所示。其中錄音線程負責從聲卡采集聲音數據并將其放到編碼緩沖區中等待編碼模塊使用。編碼線程每次從編碼緩沖區中取出一幀數據進行Speex的回聲消除、預處理以及編碼，并將編碼后的數據放入發送緩沖區。發送線程每次從發送緩沖區中取出編碼后的數據進行打包（RTP包），并且發送給通話的另一方。接收線程負責從網絡上接收對方發來的RTP語音包。由于每個RTP包頭中有包的序號信息，接收線程依據包的序號把聲音數據依次放入抖動緩沖區中，以達到正確排序和消除抖動的目的。解碼線程負責從抖動緩沖區中取出接收到的語音數據進行Speex的解碼運算，并將解碼后的語音數據存入播放緩沖區。播放線程從播放緩沖區中取出語音數據，送至放音設備播放。

上述六線程的運行期結構能夠使系統各模塊具有高度的并行性。這對于VoIP這種實時性要求很高的應用來說十分重要。例如，當接收線程收到一個包后，它把解碼的任務交給解碼線程，然后又可以去等待或處理接收其他的數據包。因此對數據包的接收響應較快。

上述通話模型的實現采用了RTP和多方通話機制^[5，6]。RTP是由IETF的AVT(Audio Video Transmission)小組開發的，1996年成為RFC正式文檔，為IP網上語音、圖像、傳真等數據等多種需實施傳輸的媒體數據提供點到點和點到多點的端到端的傳輸功能。RTP實際上包含兩個相關的協議——RTP和RTCP。前者用于傳送實時數據；后者實現實時傳輸控制。RTP本身不提供任何保證實時傳送數據和服務質量的能力，而只是提供負荷類型指示、序列號、時戳、數據源標志等信息，接收端根據這些信息重新恢復正確的數據。RTCP是用來提供RTP數據傳輸質量反饋的，同時可以在會議業務中傳送與會者的信息。

本系統采用了點對點的多方通話模型，即為每一個通話者都建立一個RTP會話，在語音通話前，要通過一條主RTP線路建立連接，它的端口被記錄到服務器上。用戶上線后，客戶端可從服務器上獲得各在線好友的RTP端口號。建立連接的過程主要是協調好雙方將要在哪個端口上創建RTP會話進行通話。斷開時，通過各自RTP的BYEPacket結束會話。建立連接的過程如圖5所示；多方通話模型如圖6所示。

圖5中，主叫方先做好通話準備，并創建一個將用來與對方通話的RTP會話。把這個端口號加到呼叫包中周期性地發送出去，直到對方應答。被叫方收到呼叫包后，如果接收呼叫，就創建一個用來通話的RTP會話。同時從接收到的呼叫包中得到對方用來通話的RTP端口；然后把對方IP和這個端口所表示的RTP地址添加到組播地址（在單方通話時實際上是進行單播），并開始通話。主叫方用來通話的RTP會話第一次收到對方發來的RTP包時，也把對方的用來通話的RTP地址加到組播地址，開始通話。當用戶要結束通話時，客戶端只要發送RTP提供的BYEPacket包即可結束通話。

在圖6所示的多方通話模型中，錄音線程每錄完一幀后，就把這幀發給編碼線程。在編碼線程中，對語音幀進行Speex回聲消除以及噪聲消除、自動增益、靜音抑制等預處理，并進行編碼；然后將編碼后的數據傳送給發送線程。在發送線程中，有多個RTP會話；線程調用每個會話的SendPacket()函數，向每個RTP會話方發送語音包。在接收線程中，每個RTP會話從各自的對話方接收語音包放入抖動緩沖區，經過Speex解碼運算后，計時器周期性地從每個RTP會話的抖動緩沖區中取出一幀進行混音，然后播放。

RTP的接收反饋RTCP包內包含了近期內發送的數據包的丟失率。接收方在收到RTCP包后，通過丟包率就可以知道對方的接收情況，據此可以采取相應的丟包補償措施。本系統能夠根據丟包率適當地發送一些語音冗余包，保證了語音質量。

4系統測試

目前已有不少VoIP系統在Internet上獲得了應用。Skype^[7]最具代表性，并且是目前公認最好的商用VoIP系統。IHU^[8]和NetTalk^[9]則是具有代表性的開源VoIP系統。本系統在PC上進行了性能測試，并與上述幾套系統進行了通話話音質量的對比實驗。測試機器配置是Intel P4 1．8 GHz CPU，512 MB內存，操作系統為Windows XP。網絡環境有兩種：一種是在CERNET內進行通信；另一種是在CERNET與CHINANET間進行通信。測試結果如表1所示。

從表1中可以看出，在網絡互聯性能較好的情況下（在CERNET內通信），上述四種VoIP系統都能達到較好的通話效果。本系統的通話質量與Skype相比差距不大，只是音質上略遜于Skype。主要原因在于Skype采用了iLBC^[10]編碼方式，而iLBC的編碼后比特率是13．3~15．2 kbps，明顯高于Speex在8 kHz采樣下的比特率。因此，Skype音質略優于本系統是以占用更多的帶寬為代價的。本系統與IHU和NetTalk相比，優勢相當明顯，主要表現在本系統增加了回聲消除和多方通話功能；另外，聲音抖動的去除也做得相當好。在網絡條件相對較差的情況下（在CERNET與CHINANET間進行通信），四種VoIP系統的通話質量均出現不同程度的下降。但是本系統與IHU和NetTalk相比，在聲音質量上要好得多，而與Skype相比主要的不足表現在回聲消除方面。本系統采用的是Speex語音引擎提供的回聲消除模塊，在網絡延遲較小的情況下，具有比較明顯的回聲消除效果。但是實驗表明，一旦網絡延遲較大，Speex的回音消除效果往往不能令人滿意。提高回聲消除模塊的性能是本系統需要進一步改進的地方。

5結束語

目前，基于IP網絡的多媒體通信得到了迅猛的發展，特別是VoIP系統已日益成為Internet用戶進行語音通信的主要手段。資費便宜以及IP網絡的廣泛性和可伸縮性，使得VoIP成為一種可以替代傳統的PSTN電話的通信方式。Speex是近年來出現的功能強大的開源語音引擎；RTP是協議是網絡多媒體的核心協議之一。本文論述了一個基于Speex語音引擎和RTP的、客戶機/服務器結構模式的VoIP系統的設計與開發。該系統采用客戶機/服務器模式克服了現有的多數VoIP系統只能直接用IP地址進行呼叫的缺陷，提高了VoIP系統的友好性和可推廣性。另外，Speex提供的高質量、低比特率的編碼算法以及聲音預處理和回聲消除功能使得本系統的通話質量優于其他的一些開源VoIP系統。在不同網絡互聯環境中對系統進行的測試表明，在網絡延遲較小時，本系統回聲消除效果明顯，但是當網絡延遲較大時，聲學回聲消除的效果還不能令人滿意。進一步改善回聲消除功能是本系統后續開發的主要任務。

參考文獻：

[1]GOODE B. Voice over Internet protocol(VoIP)[J]. Proceedings of the IEEE， 2002，90(9):1495.

[2]XIPH Open Souce Community. Speex: a free codec for free speech[EB/OL].[2006-09-27].http://www.speex.org.

[3]VALIN J M. The Speex codec manual(version 1.2－beta1)[EB/OL].[2006-09-27].http://www.speex.org/docs/manual/speex－manual.pdf.

[4]HENNING S， STEPHEN L C， RON F， et al. RFC 3550 RTP， a transport protocol for real－time applications[S].

[5]HERSENT O， PETIT J P， GURLE D. Beyond VoIP protocols: understanding voice technology and networking techniques for IP tele－phony[M]. Chichester: Wiley， 2005:206.

[6]HERSENT O， PETIT J P， GURLE D. IP telephony: deploying voice－over－IP protocols[M]. Chichester: Wiley， 2005:108.

[7]張晉江.Skype再次掀起VoIP熱潮[J].通信世界，2005(12):20.

[8]TROTTA M. I hear U(IHU) project homepage[EB/OL].[2006－10－15].http://ihu.sourceforge.net/index.html.

[9]LUSSIER G A， MORENCY F C. NetTalk project Web page[EB/OL].[2006－10-05].http://ntalk.sourceforge.net.

[10]The iLBCfreeware.org Project. iLBCfreeware.org project homepage[EB/OL].[2006－10-05].http://www.ilbcfreeware.org/index.html.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”