基于移动网络的语音集群通信系统

丁杰+潘晨光

摘要：分析行业用户在语音集群通信方面的具体业务需求和技术要求，给出一套适应移动网络环境的语音集群通信系统解决方案。设计基于SSL Socket安全链路的底层传输框架和数据传输格式，提出建立应用交互的基本方法，针对移动网络环境的网络特性，分析并使用合理的音频编解码库，设计混音算法，解决在语音集群通信系统上的核心问题。

关键词：语音集群通信；移动网络；SSL Socket；opus

中图分类号：TP393 文献标识码：A 文章编号：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

随着公共网络服务和多媒体通信技术的发展，利用移动终端进行语音实时通信已成为民用市场或行业应用的热门业务[1]。相比较传统的电话语音业务，基于IP网络的语音通信系统具有跨地域、低成本、高质量、可定制等优势，且随着移动网络建设的不断升级，语音通信系统的通话效果和时延已与电话语音的差别不大。目前，市场上主流的语音通信应用有两类：一是采用频道、群组或聊天室形式的多人语音通信，如yy语音、qt语音等；二是采用一对一通话模式的IP网络电话，如Skype等。微信作为国内影响力较大的即时通信软件，也提供了一对一的实时语音功能。

对于满足专有行业或企业的语音集群通信业务[2]，通常还需要考虑以下需求：1）群组通话是集群通信的主要业务模式，具有群组信道共享，避免通信互扰等服务要求；2）对于室外作业多采用移动网络，而非连接到有线网络共享的AP热点，网络质量受限。3）VPDN专网服务支持或其他网络安全要求；4）在语音业务基础上，提供文本通信、文件传输等定制功能；5）对语音、文本、共享文件等关键信息的私有存储或全业务存储。因此，在设计开发基于移动网络的语音集群通信系统时，应充分考虑行业应用特点，预留必要的业务应用接口。

1 基本传输框架

语音集群通信系统基于标准的客户端-服务器通信模型设计。客户端与服务器之间的数据传输采用TCP/UDP两种协议，分别适用不同的网络环境。当移动网络质量较好时，可以根据设置使音频数据通过TCP通道传输，保证通话语音的完整性和可靠性；当网络条件较差时，使用UDP通道传输可以避免TCP传输多次握手导致的网络拥塞，实现低延时传输，保证系统的可用性。语音通信过程中的控制信令和通信信令则是基于TCP协议可靠传输[3]。

1.1 构建安全通道

安全套接层（Secure Socket Layer，SSL）是Netscape公司研发的用于在IP网络上实现数据安全传输的专有协议，通过数据加密技术确保数据在网络传输过程中不会被截取及窃听。SSL及其后续发展的传输层安全（Transport Layer Security，TLS）提供了传输层的数据完整性保护，包括身份认证、协商加密算法、交换加密密钥等[4]。OpenSSL是互联网上适用性最广泛的SSL密码库之一，提供了多种编程语言的库支持。本系统引入OpenSSL 1.0.2方法库，将TCP Socket替换为SSL Socket，对传输层协议进行链路安全保护[5]。

SSL Socket的建立流程是：

1）客户端请求建立SSL Socket连接，并向服务器发送SSL版本、加密参数等必要信息。服务器返回自身的SSL版本、加密参数、安全证书等必要信息。客户端向服务器提供认证证书。

2）客户端验证服务器证书后，生成pre-master secret，并用公钥加密后发送给服务器。服务器对证书进行认证，通过后用私钥解密pre-master secret，并生成master secret。

3）通信双方通过master secret生成会话密钥，完成SSL Socket的创建，之后的通信数据将通过会话密钥加密传输。在本系统中，会话密钥采用TLSv1 AES256-SHA加密。

由于UDP是面向无连接的传输协议，为保证数据传输安全，在发送函数sendto（）之前加入encrypt（），这里可采用与TLSv1 AES256-SHA强度相当的加密算法进行数据加密。接收侧在recvfrom（）之后加入decrypt（），进行数据解密。

1.2 数据传输格式

本系统的数据报文格式如图1所示。客户端与服务器之间遵循此格式发送交互信息，其中报文头Ptrfix包含1个字节的类型信息，区别信令数据或语音数据，提供长度信息进行组包校验。载荷部分Data为实际交互数据，采用TLSv1 AES256-SHA或其他算法加密。由于UDP协议仅用于发送语音数据，其数据传输格式为图1的Payload部分，最大长度为UDP分片的理论最大长度65507B[6]。

2 应用流程

2.1 用户接入

本系统的接入流程如图2所示，主要包括：

1）建立连接：客户端向服务器请求建立用于控制信令和TCP数据通信的SSL Socket长连接。

2）版本确认：客户端与服务器相互发送版本信息，包括软件版本、操作系统版本、其他备注信息等，双方根据版本判断系统访问的兼容性。

3）用户登录：客户端向服务器发送登录认证信息，包括登录账户、登录密码，或是用于登录认证的证书信息。

4）密钥交换：该步骤为可选项，由于SSL Socket完成了TCP连接的密钥交换，如系统支持UDP传输，则需要服务器发送UDP加密的密钥信息给客户端。

5）群组信息：服务器向请求登录的客户端发送群组的状态信息，包括群组ID、名称、描述、拓扑关系，以及群组中用户的在线状况和当前状态。

6）用户信息：服务器向其他客户端发送新登录用户的状态信息，通知该用户已上线。

7）心跳信息：客户端完成基本登录流程，通过发送周期性的心跳报文，维持长连接状态。根据实际网络状况可调整心跳报文的发送周期，如部署地域的网络状态较好，可采用3至5秒的发送间隔。

2.2 信息响应

作为集群通信系统，信息响应的基本单位是群组。每个群组的数据处理和信息状态相对于其他群组保持独立，即群组之间的数据和资源是隔离的，这里通过建立用户信息的HashMap结构hmUsers和群组信息的HashMap结构hmGroups进行数据调用和处理。调用用户或群组对象时，需通过ReadWriteLock进行资源锁定，保护线程安全[7]。考虑到多线程存在资源切换和锁定的开销，在设计上主要对不同类型或分组的任务建立线程，如图3所示。其中：

1）接收线程主要响应网卡资源，监听服务端口，接收由客户端发送的业务数据或信令信息，如果是心跳消息，则直接返回响应；否则，将通过hmUsers和hmGourps查找所属群组，并将数据推送到指定群组的消息缓冲区中。

2）处理线程主要响应和实现具体业务。每个群组对象在实例化过程中都会创建本群组的处理线程和数据缓冲区，通过提取缓冲区中的数据并解析，线程将信令或其他业务数据交给业务响应函数处理，语音数据交给数据响应函数处理，并将处理后的数据发送给指定客户端。在处理线程中，可分模块响应语音业务以外的请求，对预留接口进行功能实现。

3）存储线程主要响应数据I/O操作。本系统对独占性的I/O操作采用单线程序列化处理，即所有群组的语音数据通过统一的缓冲序列顺序解码、混音和写入文件，降低线程切换的开销。为提高I/O读写效率，语音数据不会立即写入文件，而是积累时长2秒（可根据实际情况配置）的数据包后批量写入。

3 语音处理

3.1 音频编解码器选型

目前，国内4G LTE网络建设日趋完善，基于移动网络的语音通信技术已摆脱GSM时期小于16kbps的窄带传输限制。在音频编解码技术选型上，更多考虑的是适应16kbps到64kbps区间的高品质音频编解码算法。

本系统主要对Opus、Speex、AMR-WB和G.722.1四种编解码方案进行比较。Opus是在Skype的SILK编解码器和Xiph.Org的CELT编解码器基础上发展的开源编解码方案，已形成RFC 6716标准，具有灵活的带宽适应性。Speex是基于CELP发展的音频编解码方案，但根据Speex官网提示，Opus的性能已在各方面优于Speex。AMR-WB（G.722.2）被广泛应用在WCDMA的话音业务上，其VBR特性可以较好的适应网络带宽变化。G.722.1提供了优于G.722的24kbps和32kbps音频编码压缩。

根据Opus-Codec给出的音频编码质量统计对比（图4），以及两份Google组织的主观评测报告[9][10]，在同等比特率条件下，Opus编码能够达到或超过AMR-WB、G.722.1的编码质量。且考虑到国内各地区移动网络的传输质量差异较大，支持6kbps到510kbps比特率和VBR技术的Opus编解码器可为不同网络环境提供更稳定的语音通话效果。

3.2 Opus编解码实例

Opus是基于C语言编写的音频编解码器，Windows平台可直接加载Opus源代码进行函数调用，Android平台还需要对源代码进行NDK编译，生成供Java语言调用的so库。

使用Opus进行语音编码的代码片段如下：

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） { //仅处理采集片段，而非长期占用线程

…

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 混音流程

多路语音的数据混音是语音集群通信的核心功能。通过混音算法和调平参数，同一群组内的多路通话语音将根据逐帧数据的时间戳进行合帧处理，形成一路语音数据，送入声卡缓冲区进行放音。不论语音数据是以8位、16位或浮点形式存储，在多路混音时仅做逻辑叠加运算将会导致数据越界，必须先通过调平参数进行数据调整，之后根据叠加系数按比例缩减，保证合帧后的语音数据不会越界[11][12]。

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

mixlocker.lock（）；

…

foreach（audio_source as， mixlist） {

source_buf = as.getbuf（）；

level = volume_level * generate_adjust（）； // 设置调平参数

…

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++） // 数据越界保护

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

…

mixlocker.lock（）；

4 实验与分析

本系统分别在10M专线、联通4G、移动4G、电信4G等网络条件下进行测试，测试结果如表1所示。

在不同网络环境下，语音数据传输的平均延时在可接受范围，UDP丢包率小于2.2%，网络抖动小于20ms。通过主观测试，语音通话连贯，无连续丢帧，可懂性良好。因此，语音集群通信系统在传输延迟、网络抖动等方面可以较好满足语音集群和实时通信要求。在编码处理方面，优于国际电联G.711语音编码的90kbps带宽占用。

5 结束语

本文主要根据移动网络环境下的语音集群通信需求，给出一套可行的系统解决方案，并对其中底层链路、应用构建、核心编码处理等关键环节进行详细阐述。在实际应用过程中，不同领域的业务单位可能对系统的数据存储、用户负载、网络安全有更高的业务需求，可以通过合理配置磁盘阵列、负载均衡、安全网关、代理服务器等硬件设备或软件服务来实现。

参考文献：

[1] 2015年中国移动语音社交应用行业研究报告[R]. 上海： iResearch， 2015：19-23

[2] 王芳. 数字集群通信系统的构成及功能[J]. 电信网技术， 2005（2）：9-12.

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

[4] 曾强. 网络安全协议SSL原理及应用[D]. 天津：天津大学， 2005.

[5] 秦贞虎. 基于OpenSSL开发的聊天工具的设计与实现[D]. 成都：电子科技大学， 2013.

[6] 李一鸣， 任勇毛， 李俊. 基于UDP的传输协议性能比较与分析[J]. 计算机应用研究， 2010， 27（10）：3906-3910.

[7] 赵兴. 基于VoIP技术的无线语音通信系统设计[D].长沙： 湖南大学， 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电话会议系统中混音模块关键技术的研究与实现[D]. 上海：华东师范大学， 2007.

[12] 韩钰， 普杰信. 一种新的网络电话会议混音算法[J]. 计算机应用， 2010， 30（2）：564-566.