丁杰+潘晨光

摘要：分析行業(yè)用戶在語音集群通信方面的具體業(yè)務(wù)需求和技術(shù)要求，給出一套適應(yīng)移動(dòng)網(wǎng)絡(luò)環(huán)境的語音集群通信系統(tǒng)解決方案。設(shè)計(jì)基于SSL Socket安全鏈路的底層傳輸框架和數(shù)據(jù)傳輸格式，提出建立應(yīng)用交互的基本方法，針對(duì)移動(dòng)網(wǎng)絡(luò)環(huán)境的網(wǎng)絡(luò)特性，分析并使用合理的音頻編解碼庫(kù)，設(shè)計(jì)混音算法，解決在語音集群通信系統(tǒng)上的核心問題。

關(guān)鍵詞：語音集群通信；移動(dòng)網(wǎng)絡(luò)；SSL Socket；opus

中圖分類號(hào)：TP393 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2016）27-0014-04

Abstract： The paper analyzes the specific business demands and technical requirements of the industry users in the voice cluster communication， and gives a solution of voice cluster communication system for the mobile network environment. It designs the underlying transmission framework based on SSL Socket secure link and data transmission format， puts forward the basic method to establish interactive applications， according to the features of mobile network environment， it analyzes and uses the reasonable audio codec library， designs audio mixing algorithm， solves the core problem of the voice cluster communication system.

Key words： voice cluster communication； mobile network； SSL Socket； opus

隨著公共網(wǎng)絡(luò)服務(wù)和多媒體通信技術(shù)的發(fā)展，利用移動(dòng)終端進(jìn)行語音實(shí)時(shí)通信已成為民用市場(chǎng)或行業(yè)應(yīng)用的熱門業(yè)務(wù)[1]。相比較傳統(tǒng)的電話語音業(yè)務(wù)，基于IP網(wǎng)絡(luò)的語音通信系統(tǒng)具有跨地域、低成本、高質(zhì)量、可定制等優(yōu)勢(shì)，且隨著移動(dòng)網(wǎng)絡(luò)建設(shè)的不斷升級(jí)，語音通信系統(tǒng)的通話效果和時(shí)延已與電話語音的差別不大。目前，市場(chǎng)上主流的語音通信應(yīng)用有兩類：一是采用頻道、群組或聊天室形式的多人語音通信，如yy語音、qt語音等；二是采用一對(duì)一通話模式的IP網(wǎng)絡(luò)電話，如Skype等。微信作為國(guó)內(nèi)影響力較大的即時(shí)通信軟件，也提供了一對(duì)一的實(shí)時(shí)語音功能。

對(duì)于滿足專有行業(yè)或企業(yè)的語音集群通信業(yè)務(wù)[2]，通常還需要考慮以下需求：1）群組通話是集群通信的主要業(yè)務(wù)模式，具有群組信道共享，避免通信互擾等服務(wù)要求；2）對(duì)于室外作業(yè)多采用移動(dòng)網(wǎng)絡(luò)，而非連接到有線網(wǎng)絡(luò)共享的AP熱點(diǎn)，網(wǎng)絡(luò)質(zhì)量受限。3）VPDN專網(wǎng)服務(wù)支持或其他網(wǎng)絡(luò)安全要求；4）在語音業(yè)務(wù)基礎(chǔ)上，提供文本通信、文件傳輸?shù)榷ㄖ乒δ埽?）對(duì)語音、文本、共享文件等關(guān)鍵信息的私有存儲(chǔ)或全業(yè)務(wù)存儲(chǔ)。因此，在設(shè)計(jì)開發(fā)基于移動(dòng)網(wǎng)絡(luò)的語音集群通信系統(tǒng)時(shí)，應(yīng)充分考慮行業(yè)應(yīng)用特點(diǎn)，預(yù)留必要的業(yè)務(wù)應(yīng)用接口。

1 基本傳輸框架

語音集群通信系統(tǒng)基于標(biāo)準(zhǔn)的客戶端-服務(wù)器通信模型設(shè)計(jì)?？蛻舳伺c服務(wù)器之間的數(shù)據(jù)傳輸采用TCP/UDP兩種協(xié)議，分別適用不同的網(wǎng)絡(luò)環(huán)境。當(dāng)移動(dòng)網(wǎng)絡(luò)質(zhì)量較好時(shí)，可以根據(jù)設(shè)置使音頻數(shù)據(jù)通過TCP通道傳輸，保證通話語音的完整性和可靠性；當(dāng)網(wǎng)絡(luò)條件較差時(shí)，使用UDP通道傳輸可以避免TCP傳輸多次握手導(dǎo)致的網(wǎng)絡(luò)擁塞，實(shí)現(xiàn)低延時(shí)傳輸，保證系統(tǒng)的可用性。語音通信過程中的控制信令和通信信令則是基于TCP協(xié)議可靠傳輸[3]。

1.1 構(gòu)建安全通道

安全套接層（Secure Socket Layer，SSL）是Netscape公司研發(fā)的用于在IP網(wǎng)絡(luò)上實(shí)現(xiàn)數(shù)據(jù)安全傳輸?shù)膶Ｓ袇f(xié)議，通過數(shù)據(jù)加密技術(shù)確保數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中不會(huì)被截取及竊聽。SSL及其后續(xù)發(fā)展的傳輸層安全（Transport Layer Security，TLS）提供了傳輸層的數(shù)據(jù)完整性保護(hù)，包括身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等[4]。OpenSSL是互聯(lián)網(wǎng)上適用性最廣泛的SSL密碼庫(kù)之一，提供了多種編程語言的庫(kù)支持。本系統(tǒng)引入OpenSSL 1.0.2方法庫(kù)，將TCP Socket替換為SSL Socket，對(duì)傳輸層協(xié)議進(jìn)行鏈路安全保護(hù)[5]。

SSL Socket的建立流程是：

1）客戶端請(qǐng)求建立SSL Socket連接，并向服務(wù)器發(fā)送SSL版本、加密參數(shù)等必要信息。服務(wù)器返回自身的SSL版本、加密參數(shù)、安全證書等必要信息。客戶端向服務(wù)器提供認(rèn)證證書。

2）客戶端驗(yàn)證服務(wù)器證書后，生成pre-master secret，并用公鑰加密后發(fā)送給服務(wù)器。服務(wù)器對(duì)證書進(jìn)行認(rèn)證，通過后用私鑰解密pre-master secret，并生成master secret。

3）通信雙方通過master secret生成會(huì)話密鑰，完成SSL Socket的創(chuàng)建，之后的通信數(shù)據(jù)將通過會(huì)話密鑰加密傳輸。在本系統(tǒng)中，會(huì)話密鑰采用TLSv1 AES256-SHA加密。

由于UDP是面向無連接的傳輸協(xié)議，為保證數(shù)據(jù)傳輸安全，在發(fā)送函數(shù)sendto（）之前加入encrypt（），這里可采用與TLSv1 AES256-SHA強(qiáng)度相當(dāng)?shù)募用芩惴ㄟM(jìn)行數(shù)據(jù)加密。接收側(cè)在recvfrom（）之后加入decrypt（），進(jìn)行數(shù)據(jù)解密。

1.2 數(shù)據(jù)傳輸格式

本系統(tǒng)的數(shù)據(jù)報(bào)文格式如圖1所示?？蛻舳伺c服務(wù)器之間遵循此格式發(fā)送交互信息，其中報(bào)文頭Ptrfix包含1個(gè)字節(jié)的類型信息，區(qū)別信令數(shù)據(jù)或語音數(shù)據(jù)，提供長(zhǎng)度信息進(jìn)行組包校驗(yàn)。載荷部分Data為實(shí)際交互數(shù)據(jù)，采用TLSv1 AES256-SHA或其他算法加密。由于UDP協(xié)議僅用于發(fā)送語音數(shù)據(jù)，其數(shù)據(jù)傳輸格式為圖1的Payload部分，最大長(zhǎng)度為UDP分片的理論最大長(zhǎng)度65507B[6]。

2 應(yīng)用流程

2.1 用戶接入

本系統(tǒng)的接入流程如圖2所示，主要包括：

1）建立連接：客戶端向服務(wù)器請(qǐng)求建立用于控制信令和TCP數(shù)據(jù)通信的SSL Socket長(zhǎng)連接。

2）版本確認(rèn)：客戶端與服務(wù)器相互發(fā)送版本信息，包括軟件版本、操作系統(tǒng)版本、其他備注信息等，雙方根據(jù)版本判斷系統(tǒng)訪問的兼容性。

3）用戶登錄：客戶端向服務(wù)器發(fā)送登錄認(rèn)證信息，包括登錄賬戶、登錄密碼，或是用于登錄認(rèn)證的證書信息。

4）密鑰交換：該步驟為可選項(xiàng)，由于SSL Socket完成了TCP連接的密鑰交換，如系統(tǒng)支持UDP傳輸，則需要服務(wù)器發(fā)送UDP加密的密鑰信息給客戶端。

5）群組信息：服務(wù)器向請(qǐng)求登錄的客戶端發(fā)送群組的狀態(tài)信息，包括群組ID、名稱、描述、拓?fù)潢P(guān)系，以及群組中用戶的在線狀況和當(dāng)前狀態(tài)。

6）用戶信息：服務(wù)器向其他客戶端發(fā)送新登錄用戶的狀態(tài)信息，通知該用戶已上線。

7）心跳信息：客戶端完成基本登錄流程，通過發(fā)送周期性的心跳報(bào)文，維持長(zhǎng)連接狀態(tài)。根據(jù)實(shí)際網(wǎng)絡(luò)狀況可調(diào)整心跳報(bào)文的發(fā)送周期，如部署地域的網(wǎng)絡(luò)狀態(tài)較好，可采用3至5秒的發(fā)送間隔。

2.2 信息響應(yīng)

作為集群通信系統(tǒng)，信息響應(yīng)的基本單位是群組。每個(gè)群組的數(shù)據(jù)處理和信息狀態(tài)相對(duì)于其他群組保持獨(dú)立，即群組之間的數(shù)據(jù)和資源是隔離的，這里通過建立用戶信息的HashMap結(jié)構(gòu)hmUsers和群組信息的HashMap結(jié)構(gòu)hmGroups進(jìn)行數(shù)據(jù)調(diào)用和處理。調(diào)用用戶或群組對(duì)象時(shí)，需通過ReadWriteLock進(jìn)行資源鎖定，保護(hù)線程安全[7]?？紤]到多線程存在資源切換和鎖定的開銷，在設(shè)計(jì)上主要對(duì)不同類型或分組的任務(wù)建立線程，如圖3所示。其中：

1）接收線程主要響應(yīng)網(wǎng)卡資源，監(jiān)聽服務(wù)端口，接收由客戶端發(fā)送的業(yè)務(wù)數(shù)據(jù)或信令信息，如果是心跳消息，則直接返回響應(yīng)；否則，將通過hmUsers和hmGourps查找所屬群組，并將數(shù)據(jù)推送到指定群組的消息緩沖區(qū)中。

2）處理線程主要響應(yīng)和實(shí)現(xiàn)具體業(yè)務(wù)。每個(gè)群組對(duì)象在實(shí)例化過程中都會(huì)創(chuàng)建本群組的處理線程和數(shù)據(jù)緩沖區(qū)，通過提取緩沖區(qū)中的數(shù)據(jù)并解析，線程將信令或其他業(yè)務(wù)數(shù)據(jù)交給業(yè)務(wù)響應(yīng)函數(shù)處理，語音數(shù)據(jù)交給數(shù)據(jù)響應(yīng)函數(shù)處理，并將處理后的數(shù)據(jù)發(fā)送給指定客戶端。在處理線程中，可分模塊響應(yīng)語音業(yè)務(wù)以外的請(qǐng)求，對(duì)預(yù)留接口進(jìn)行功能實(shí)現(xiàn)。

3）存儲(chǔ)線程主要響應(yīng)數(shù)據(jù)I/O操作。本系統(tǒng)對(duì)獨(dú)占性的I/O操作采用單線程序列化處理，即所有群組的語音數(shù)據(jù)通過統(tǒng)一的緩沖序列順序解碼、混音和寫入文件，降低線程切換的開銷。為提高I/O讀寫效率，語音數(shù)據(jù)不會(huì)立即寫入文件，而是積累時(shí)長(zhǎng)2秒（可根據(jù)實(shí)際情況配置）的數(shù)據(jù)包后批量寫入。

3 語音處理

3.1 音頻編解碼器選型

目前，國(guó)內(nèi)4G LTE網(wǎng)絡(luò)建設(shè)日趨完善，基于移動(dòng)網(wǎng)絡(luò)的語音通信技術(shù)已擺脫GSM時(shí)期小于16kbps的窄帶傳輸限制。在音頻編解碼技術(shù)選型上，更多考慮的是適應(yīng)16kbps到64kbps區(qū)間的高品質(zhì)音頻編解碼算法。

本系統(tǒng)主要對(duì)Opus、Speex、AMR-WB和G.722.1四種編解碼方案進(jìn)行比較。Opus是在Skype的SILK編解碼器和Xiph.Org的CELT編解碼器基礎(chǔ)上發(fā)展的開源編解碼方案，已形成RFC 6716標(biāo)準(zhǔn)，具有靈活的帶寬適應(yīng)性。Speex是基于CELP發(fā)展的音頻編解碼方案，但根據(jù)Speex官網(wǎng)提示，Opus的性能已在各方面優(yōu)于Speex。AMR-WB（G.722.2）被廣泛應(yīng)用在WCDMA的話音業(yè)務(wù)上，其VBR特性可以較好的適應(yīng)網(wǎng)絡(luò)帶寬變化。G.722.1提供了優(yōu)于G.722的24kbps和32kbps音頻編碼壓縮。

根據(jù)Opus-Codec給出的音頻編碼質(zhì)量統(tǒng)計(jì)對(duì)比（圖4），以及兩份Google組織的主觀評(píng)測(cè)報(bào)告[9][10]，在同等比特率條件下，Opus編碼能夠達(dá)到或超過AMR-WB、G.722.1的編碼質(zhì)量。且考慮到國(guó)內(nèi)各地區(qū)移動(dòng)網(wǎng)絡(luò)的傳輸質(zhì)量差異較大，支持6kbps到510kbps比特率和VBR技術(shù)的Opus編解碼器可為不同網(wǎng)絡(luò)環(huán)境提供更穩(wěn)定的語音通話效果。

3.2 Opus編解碼實(shí)例

Opus是基于C語言編寫的音頻編解碼器，Windows平臺(tái)可直接加載Opus源代碼進(jìn)行函數(shù)調(diào)用，Android平臺(tái)還需要對(duì)源代碼進(jìn)行NDK編譯，生成供Java語言調(diào)用的so庫(kù)。

使用Opus進(jìn)行語音編碼的代碼片段如下：

OpusEncoder *opus_enc = opus_encoder_create（16000，1，OPUS_APPLICATION_VOIP， &err）；

…

opus_encoder_ctl（opus_enc， OPUS_SET_BANDWIDTH（OPUS_BANDWIDTH_WIDEBAND））；

opus_encoder_ctl（opus_enc， OPUS_SET_BITRATE（24000））；

opus_encoder_ctl（opus_enc， OPUS_SET_VBR（1））；

opus_encoder_ctl（opus_enc， OPUS_SET_FORCE_CHANNELS（1））；

opus_encoder_ctl（opus_enc， OPUS_SET_DTX（0））；

…

while （total_length - input_pos > frame_bytes） { //僅處理采集片段，而非長(zhǎng)期占用線程

…

get_data（input_buf， input_pos）；

num = opus_encode（opus_enc， input_buf， frame_size， output_buf， max_output_size）；

send_data（output_buf， num）；

… }

…

opus_encoder_destroy（opus_enc）；

3.3 混音流程

多路語音的數(shù)據(jù)混音是語音集群通信的核心功能。通過混音算法和調(diào)平參數(shù)，同一群組內(nèi)的多路通話語音將根據(jù)逐幀數(shù)據(jù)的時(shí)間戳進(jìn)行合幀處理，形成一路語音數(shù)據(jù)，送入聲卡緩沖區(qū)進(jìn)行放音。不論語音數(shù)據(jù)是以8位、16位或浮點(diǎn)形式存儲(chǔ)，在多路混音時(shí)僅做邏輯疊加運(yùn)算將會(huì)導(dǎo)致數(shù)據(jù)越界，必須先通過調(diào)平參數(shù)進(jìn)行數(shù)據(jù)調(diào)整，之后根據(jù)疊加系數(shù)按比例縮減，保證合幀后的語音數(shù)據(jù)不會(huì)越界[11][12]。

混音操作的代碼片段如下：

mixlocker.lock（）；

…

foreach（audio_source as， mixlist） {

source_buf = as.getbuf（）；

level = volume_level * generate_adjust（）； // 設(shè)置調(diào)平參數(shù)

…

for （unsigned int i = 0； i < sample_num； i++）

mix_buf[i] += source_buf[i] * level；

… }

…

for （unsigned int i = 0； i < sample_num； i++） // 數(shù)據(jù)越界保護(hù)

mix_buf[i] = bound（mix_buf[i]， -32768， 32767）；

…

mixlocker.lock（）；

4 實(shí)驗(yàn)與分析

本系統(tǒng)分別在10M專線、聯(lián)通4G、移動(dòng)4G、電信4G等網(wǎng)絡(luò)條件下進(jìn)行測(cè)試，測(cè)試結(jié)果如表1所示。

在不同網(wǎng)絡(luò)環(huán)境下，語音數(shù)據(jù)傳輸?shù)钠骄訒r(shí)在可接受范圍，UDP丟包率小于2.2%，網(wǎng)絡(luò)抖動(dòng)小于20ms。通過主觀測(cè)試，語音通話連貫，無連續(xù)丟幀，可懂性良好。因此，語音集群通信系統(tǒng)在傳輸延遲、網(wǎng)絡(luò)抖動(dòng)等方面可以較好滿足語音集群和實(shí)時(shí)通信要求。在編碼處理方面，優(yōu)于國(guó)際電聯(lián)G.711語音編碼的90kbps帶寬占用。

5 結(jié)束語

本文主要根據(jù)移動(dòng)網(wǎng)絡(luò)環(huán)境下的語音集群通信需求，給出一套可行的系統(tǒng)解決方案，并對(duì)其中底層鏈路、應(yīng)用構(gòu)建、核心編碼處理等關(guān)鍵環(huán)節(jié)進(jìn)行詳細(xì)闡述。在實(shí)際應(yīng)用過程中，不同領(lǐng)域的業(yè)務(wù)單位可能對(duì)系統(tǒng)的數(shù)據(jù)存儲(chǔ)、用戶負(fù)載、網(wǎng)絡(luò)安全有更高的業(yè)務(wù)需求，可以通過合理配置磁盤陣列、負(fù)載均衡、安全網(wǎng)關(guān)、代理服務(wù)器等硬件設(shè)備或軟件服務(wù)來實(shí)現(xiàn)。

參考文獻(xiàn)：

[1] 2015年中國(guó)移動(dòng)語音社交應(yīng)用行業(yè)研究報(bào)告[R]. 上海： iResearch， 2015：19-23

[2] 王芳. 數(shù)字集群通信系統(tǒng)的構(gòu)成及功能[J]. 電信網(wǎng)技術(shù)， 2005（2）：9-12.

[3] Chauncey D， Kuliner M. Secure wireless communications system and related method： WO， US7987363[P]. 2011.

[4] 曾強(qiáng). 網(wǎng)絡(luò)安全協(xié)議SSL原理及應(yīng)用[D]. 天津：天津大學(xué)， 2005.

[5] 秦貞虎. 基于OpenSSL開發(fā)的聊天工具的設(shè)計(jì)與實(shí)現(xiàn)[D]. 成都：電子科技大學(xué)， 2013.

[6] 李一鳴， 任勇毛， 李俊. 基于UDP的傳輸協(xié)議性能比較與分析[J]. 計(jì)算機(jī)應(yīng)用研究， 2010， 27（10）：3906-3910.

[7] 趙興. 基于VoIP技術(shù)的無線語音通信系統(tǒng)設(shè)計(jì)[D].長(zhǎng)沙： 湖南大學(xué)， 2011.

[8] opus-codec. Quality vs Bitrate[EB/OL]. http：//www.opus-codec.org/comparison/.

[9] opus-codec. Google listening tests[EB/OL]. http：//www.opus-codec.org/comparison/GoogleTest1.pdf.

[10] opus-codec. Google listening tests[EB/OL]. http：//www.opus-codec.org/comparison/GoogleTest2.pdf.

[11] 張微. VOIP電話會(huì)議系統(tǒng)中混音模塊關(guān)鍵技術(shù)的研究與實(shí)現(xiàn)[D]. 上海：華東師范大學(xué)， 2007.

[12] 韓鈺， 普杰信. 一種新的網(wǎng)絡(luò)電話會(huì)議混音算法[J]. 計(jì)算機(jī)應(yīng)用， 2010， 30（2）：564-566.