一种宽带集群系统录音服务器会话数据的存储策略

窦春斌，肖志辉，陈一山

（1.西南交通大学信息科学与技术学院 成都610031；2.迈普通信技术股份有限公司 成都610041）

1 引言

集群系统是为了满足行业指挥调度的需求而开发的、面向多种行业应用的专用无线通信系统，经历了从模拟、数字到数字集群加宽带接入系统的历程。随着无线高速数据业务的飞速发展，集群系统将向数据宽带化、业务多样化，即宽带集群通信系统的方向发展。宽带集群系统支持多会话业务功能，如呼叫保持、多路终端音/视频通话、单呼、组呼等。系统架构如图1所示，分为4个层次：终端、接入子系统、交换控制平台、调度应用平台。其中，多样化终端之间，通过接入子系统与交换控制平台实现相互通信。调度应用平台是集群系统中的安全运营支撑子系统，包括多媒体调度台、录音服务器、安全服务器等。

录音服务器系统用于实时监控和记录通信信息，包括呼叫号码、呼叫时间、通话内容等，起着服务质量监督、解决纠纷等重要作用。录音服务器的发展也经历了从模拟到数字的发展历程。但现在市场上的许多录音服务器在支持业务类型方面具有一定的局限性，往往仅能支持单一类型，如果想满足多会话业务能力，就必须购买多套录音服务器系统。为了满足宽带集群系统的多业务需求，录音系统必须朝着在基于网络支持的同时处理语音、高速数据、移动图像等多会话业务方向发展。

图1 宽带多媒体集群系统架构

如图1所示的宽带多媒体集群系统架构中，录音服务器控制并保存来自交换控制平台的数据，实现事后查询与实时监控。录音服务器功能实现分为控制平面和业务平面。本文研究了宽带集群系统录音服务器的业务平面，提出了一种存储会话数据的策略，可以在同一时间完成多组会话数据存储，并且支持单呼、组呼、音频、视频等特殊业务的需求。

2 实时传输协议

录音服务器需要处理的是宽带集群系统通信中的会话数据，由实时传输协议（real-time transport protocol，RTP）传送。其中，RTP是一种在Internet上处理多媒体数据流的网络协议，用UDP分组来承载。RTP数据报文分组格式如图2所示。

RTP头部报文格式如图3所示。其中，载荷类型（PT），7 bit，标识了RTP载荷的类型；序列号（SN），16 bit，发送方每发送完一个RTP分组就将该域的值增加1，接收方可以由该域检测分组的丢失及恢复分组序列，序列号的初始值是随机的；同步源标识符（SSRC），32 bit，同步源指RTP分组流的来源，在同一个RTP会话中不能有两个相同的SSRC值。

3 存储策略

据统计，宽带集群系统录音服务器平均1 s约存储50 KB会话数据，一天约4 320 MB，如果磁盘空间按160 GB计算，则录音服务器可以存储约40天的会话数据。进行录音服务器后期查询时，主要的查询条件是：时间、呼叫人和呼叫类型（单呼、组呼、音频、视频）。

上述分析表明，集群系统录音服务器所面临的数据特点是数量庞大，但数据间关系相对简单。大数据量在处理时容易出现数据囤积、丢失等问题。根据录音服务器的数据特点和面临的问题，集群系统录音服务器需要实现两大功能：快速提取会话数据、实时存储大量数据。录音服务器怎样实现这两大功能，高效地完成从接收、处理到存储数据的过程，需要考虑如下两点。

（1）实时处理，快速接收数据，不囤积数据，避免数据丢失

顺序接收技术是将同一时间收到的所有数据存于一个大的缓存中，按照时间的先后顺序依次接收；按照某个接收规则，在接收时判断优先级，优先级高的数据先被接收。两种方法显然都不适合实时处理的思想。多线程接收技术，是为了同步完成多项接收任务，提高资源使用效率以及系统的性能。录音服务器运用多线程接收技术，设定系统性能可接受的线程数目，每个存储会话数据请求对应一个接收线程，每一个接收线程对应一个处理线程。为了保证数据无丢失，录音服务器运用缓存机制，将未处理的数据存于缓存中，并及时清空已处理的数据缓存空间。

（2）实现高效存储，便于事后查询

针对录音服务器“数据量庞大、数据间关系相对简单”的特点，如果用复杂的分布式存储，反而会降低存储效率，采用比较简单的分级目录及文件存储的形式，可以达到高效存储的目的。根据单呼、组呼的会话类型，目录层级设为“/日期/主叫号/被叫号/”（单呼）或“/日期/组号/”（组呼）；根据音频、视频的会话类型，可以将文件后缀类型设为“.artp”（单呼）或“.vrtp”（组呼）。考虑到分级目录的查询效率很低，先选择数据库存储会话信息，再定位存储路径的方法，有利于事后的查询工作。

综上所述，宽带集群系统录音服务器可以采用“多线程+缓存机制+分级目录文件存储形式+数据库存储会话信息”的存储策略。

4 存储策略实现

4.1 会话数据的获取方法

录音服务器功能实现分为控制平面和业务平面。如图4所示，当需要录音时，交换控制平台向录音服务器的控制平面发送“录音开始请求”协议报文，协商成功则控制平面分配port地址，同时生成新的RecordItem对象（RecordItem中存储录音的相关数据，包括主叫号、被叫号、会话类型、分配的端口号等），并用此port地址作为RecordItem的键值存入RecordItemMap缓存中。

业务平面一直处在监听状态，当RecordItemMap中有新的RecordItem时，会添加新的接收RTP任务到任务池，如图5所示。

图4 业务平面与控制平面的交互

图5 业务平面数据缓存分析

当有新任务时，业务平面任务池的接收线程会利用多线程并发方式，使协商好的地址（RecordItem）接收来自交换控制平台的所有RTP数据流，并将会话数据放入缓冲池（RecordData>）中，每一个端口号对应一个会话的数据流。

4.2 文件存储规则

如图5所示，存储线程从缓冲区获取会话数据，解析RTP头报文，按固定格式存储payload数据（RTP分组中的有效载荷）到文件中，文件格式为“RTP数据长度+RTP payload数据”。每一个文件都有RTP管理头，存储当前记录数据的文件长度和时间信息等。

录音服务器接收到的数据有以下几种类型，根据不同的通话类型，需要用不同的方法进行存储。

（1）双向音频通话

双向音频通话，即单呼音频会话类型，记录的信息是双向的。如图6所示，通话双方的RTP数据均存储在一个文件中，如果双方都不说话，则插入相应的静音。当RTP属性更改（如编码协商、呼叫保持/恢复或达到限定文件大小）时，存入另一个文件。

根据SSRC对RTP流进行分段处理，避免SSRC发生变化时，可能存在时间间隔不一致的问题。对双向音频通话的RTP流报文采用“10个报文之后，如果新出现SSRC，则进行分段”的策略进行分段，分段示意如图7所示。在11个报文后，出现了SSRC为4的报文，在此种情况下，解码流程将对RTP报文进行分段处理，各分段报文解码后，直接拼接即可。

图6 双向视频通话存储

（2）集群音频通话

如图8所示，集群音频通话类型为单向通话。同一时间只有一个用户可以发言，故用户每一次发言记录一个数据文件。

根据SSRC对集群音频通话进行分类处理。由于是单向通话，每一个用户发言时，其他用户没有发言权，故该用户在发言时，只有一个SSRC标识源的RTP数据流，一旦变更用户发言，RTP数据流的SSRC也会随之改变。图9描述了3个用户进行集群音频通话的情景，横向为时间轴，每个用户在发言时，其他用户处于等待发言状态。此通话需要存4个文件，其中SSRC为3的用户由于中间有中断，属于两次发言，需要存两个文件。

图9 SSRC集群分组

（3）集群视频通话

根据SSRC对集群视频通话进行分类处理，如图10所示。由于是单向通话，每一个用户发言时，其他用户没有发言权，但与集群音频通话不同的是，每人说话时需要存储两个数据文件，一个为音频，一个为视频。故该用户在发言时，有两个SSRC标识源的RTP数据流，一个是音频，一个是视频。一旦变更用户发言，RTP数据流的两个SSRC也会随之改变。

4.3 文件路径及文件名策略

根据会话类型的不同，数据文件利用分级目录名、文件名表示录音的时间及时间段下的呼叫类型，存储于磁盘中。

所有的录音文件放在统一的路径（如../record/）下，按“日期”进行分布存储，如图11所示。日期以天为单位，按“年—月—日”规则命名文件夹。每一个待存储的数据文件按照日期找到自己所属的路径，接下来判断目标文件记录的是双向通话数据还是群组呼叫记录。

图11 文件路径关系

单呼只有两个发言人，为了清楚地标记出主叫号和被叫号，单呼记录文件路径设定为“../主叫号/被叫号/”。图11中，主叫号是“3000”，被叫号是“2000”。单呼存储时两路存于一个文档中，考虑到文件大小及音频、视频文件类型，单呼文件命名规则是：如果是音频文件，以“时间_序号.artp”格式命名；如果是视频文件，以“时间_序号.vrtp”格式命名。如图12所示的某日某主叫与被叫之间的音频会话记录，包括3个时间段，其中“16∶16”时段，会话时间较长，保存了3个文件。

图12 单呼记录文件

对于每一个组呼会话，都有固定的群组号，为了区分不同时间段的会话，将“/会话群组号/时间段/”作为组呼的文件存储路径。如图13所示，组号为“0012”在“2012年10月22日”的3个时间段的会话记录存储路径。

图13 组呼记录文件

由于群组呼叫的每一个会话中，会出现2个及以上发言人的情况，且每个发言人有可能会存储多个文件，所以文件命名需要区分发言人及发言的先后顺序，考虑到文件大小及音频、视频文件类型，按照“发言序列号_caller_序号.artp”的格式命名音频文件，按照“发言序列号_caller_序号.vrtp”的格式命名视频文件。某日某时间段的某会话组的呼叫记录如图14所示。例如“2_028-105_2.artp”，代表此文件是callID为028-105发言的音频数据，它在当前会话中是第2个发言人，因为发言数据过长，此文件是028-105当前发言的第2个文件。

图14 组呼记录文件

4.4 录音信息存储

为了提供方便的查询，利用数据库存储录音信息，设表名为RecordInform，SQL语句如下所述。

CREATE TABLE RecordInform

(

callID character varying(20),

starttime timestamp without time zone,

stoptime timestamp without time zone,

calltype character varying(5),

callernum character varying(20),

calleenum character varying(20),

audiotype character varying(5),

videotype character varying(5),

filepath character varying(100)

)

callID是一个会话的唯一标识；starttime和stoptime是会话的开始和结束时间；calltype是会话类型，有单呼、组呼两种；callernum和calleenum是会话的主叫和被叫，如果会话类型是组呼，则被叫号为组号；audiotype是话音的编码类型；videotype是视频的编码类型；filepath是当前会话文件的存储路径。

有查询需求时，查询数据库RecordInform表，定位文件存储路径，将查询结果（包括录音开始时间、录音结束时间、数据文件及信息列表）返回给客户端，如果客户端要回放文件，则调用解码库函数，将得到的RTP数据解析，得到音频或视频。

5 实验结果

笔者对本文提出的方法进行了实验：主要在IP语音电话双方、群聊的通话过程中，录音服务器在协商好的通话端口号下抓取语音数据，分组提取解析RTP报文，并保存于文件中。录音服务器处理1、2、5、10路语音数据（10 s/G.711语音格式）所用时间见表1。可以看出，4组实验耗时基本相同，为15～16 s。其中，录音开始时间是服务器接收到第一个会话记录的时间；录音结束时间是将会话数据存储到指定文件结束的时间。

表1 录音服务器存储多路会话消耗的时间

通过数据库查询“时间”/“呼叫人”条件定位目标文件。实验中通过数据库查找到的一路语音数据，经解码所得的Wav文件波形如图14所示，回放时基本没有失真。

图14 回放波形

6 结束语

本文简单分析了宽带集群系统中录音服务器对多会话业务的需求，提出了一种存储策略，并验证了方法的可行性。但由于RTP的多样性，需要分别处理；宽带集群系统的数据量大，需要考虑录音服务器的性能问题；视频数据需要考虑同步问题等。因此，在实际研究工作中，对录音服务器会话数据的处理及存储方法需要进一步分析。

1 吴微,黄焱.IP over DVB中RTP音频数据的提取与恢复.信息工程大学学报,2009(3)

2 RFC3550.RTP:a Transport Protocol for Real-Time Applications,2003

3 严俊,马小骏,顾冠群.RTP的研究与实现.计算机工程与应用,2000,36(9)

4 王备战,牛振喜,楼润瑜等.基于RTP的IP实时音频传输研究.西北工业大学学报,2001,19(1):48～51

5 刘佳翔.RTP流媒体识别算法的设计与实现.电脑知识与技术,2011(2)

6 赵浩然.论数据分区对海量数据处理的必要性.科学之友,2011(11)