使用英特尔主机媒体处理软件等进行在线呼叫录音

2005年10月26日

引言:在线录音是呼叫中心的一项重要功能。随着呼叫中心向IP环境的过渡,在线录音的方法也将随之发生改变。本应用注释即将讨论的是用于在线录音的“代理RTP”系统,以及该系统的体系结构和信息流程。此外,本文还将对该系统和IP环境的另一种在线录音方法“端口监控”进行简要的比较。

呼叫中心会出于多种目的来使用在线录音功能,比如员工培训或法律要求等。随着呼叫中心从TDM向IP环境的逐步过渡,在线录音的重要性也将变得越加明显。但在线录音的方法不是一成不变的。

本应用注释推荐一种适用于IP环境的在线录音方法。该方法采用高性能、可配置的开放源代码SIP(RFC3261)服务器?D?DSIP Express路由器(SER),并同时采用基于开放源代码PortaOne RTP代理的组合RTP代理/录音程序。

PortaOne RTP代理主要用于通行NAT防火墙。在线呼叫过程中,其SER接口和会话管理能力将被使用,而且其RTP分组中继(packet relay)能力也将与英特尔IP媒体库(IPML)API和面向Linux的英特尔NetStructure主机媒体处理(HMP)软件1.2版同时使用。最终将获得全双工音频数据流,并将通过英特尔 NetStructure HMP创建的“虚拟SCbus”,顺利地录制至磁盘。

在本文所述的“代理RTP”中,使用英特尔NetStructure HMP作为媒体管理器具有如下优势:

通过熟悉的API简化应用编程
提高信道密度
便于使用低位速语音信号编码器,进而减少录音所需要的磁盘空间
全面控制录音过程,包括结尾
轻松获取语音数据流,轻松进行诸如流传输至ASR服务器进行关键字查询(word spotting)等操作

SER仅适用于Unix或Linux环境。因为它是一款相对“轻量级”的应用,所以它可以很好地与面向Linux的英特尔NetStructure HMP驻留在同一个Linux系统上。为此,本文将只介绍单机箱方法。然而,包含更多功能的更大应用,或者需要更高信道密度的部署项目,也可以依照此处介绍的这一基本的单机箱模式进行部署,只是需要将组件分布到多个机箱。

注:我们不主张将此处描述的方法用做完整的呼叫中心解决方案。完整的呼叫中心应用很可能还需要其它的组件。为使问题不过于复杂化,我们此处只讨论在线录音。

高层体系结构

图1是本文所述之在线录音系统的高层结构图解。下面我们将就其主要的两个组件及其使用方法进行详细的探讨。

SER

SER承担着SIP代理的功能并负责控制录音组件的操作流程。从网络SIP终端(用户代理或UA)的角度看,SER是个相当标准的SIP代理。终端向外发出的所有呼出均被导入该代理,然后该代理再通过数据库查询操作确定所有呼叫的最终目的地。该路由器会向目的地终端提供SIP信息,但在此之前,它需对SIP信息的会话描述符协议(SDP)部分的RTP连接信息进行修改。这样RTP数据流就不是直接在两个终端之间移动,而是要被重新路由,以便它们经过在线录音系统。发起呼叫时(INVITE期间)可不需要上述操作,但是当呼叫已经开始(通过re-INVITE信息),就应该进行上述操作。使用re-INVITE的优势在于,在没有进行录音操作的时候,将不会占用系统的端口。

RTP代理会话管理器

录音开始后,即需发挥第二个组件的功用。SER与RTP代理会话管理器是接通的,当会话管理器得知有新的呼叫到达时,它会打开一个呼叫会话,并为SER提供一个唯一的端口号。SER再将呼叫终端的原有地址/端口更换为录音系统的端口号和IP地址。

如今您已可以在录音系统和两个SIP终端之间建立起两个RTP数据流,以替代直接连接两个终端的单个数据流。该应用使用英特尔R4 IPML API来建立数据流。数据流出现在虚拟SCbus上,并将同时被路由,以形成一个交叉连接。然后您就可以使用R4 Media API完整的特性集,完成数据流向磁盘的录制操作。R4 Media API中可用于在线录音的媒体特性包括:

对话录音功能,可同时录制两个半双工RTP数据流,并具备数字信号处理器(DSP)的一般功能,能在单个数据流写盘之前有效地混合各种数据流。这样就无需事后再对两个独立的数据流文件进行组合,以合成为一个同步的录音文件。
设置录音参数的能力,能够设置每次录音的参数,如文件格式、数据编码、取样率和每样本位数等
流传输数据能力,能够轻松地流传输录制数据至数据库的二进制大对象(BLOB),或者通过套接字传输至一个集中的录音服务器
停止单个API呼叫录音的能力
轻松限制录音文件大小和录音时间的能力

SER与RTP代理会话管理器连接有一个Unix域套接字(先进先出[FIFO]流程间信息队列)。这些组件之间的通信经过了一个非常简单、由应用定义的信息集,该信息集是RTP代理的一部分。

信息流程

图2是“代理RTP”在线录音系统典型呼叫录音的信息流程图解。图中数字对应于下文的段落编号。

SER经过配置可作为一个有状态的代理,以负责中继呼叫期间生成的所有SIP信息。当SER从源UA收到INVITE请求之后,它将从请求中提取SIP呼叫ID,并通过流程间套接字连接将其传送到RTP代理会话管理器。会话管理器使用该ID在现有会话中进行查找,如果该会话存在,则返回该会话的用户数据包协议(UDP)端口。如果该会话不存在,则创建一个新会话,将其绑定至配置/启动期间指定范围内的第一个空UDP端口,并将端口号返回SER。收到录音应用的回复之后,SER再将呼叫终端的原有地址/端口更换为录音系统的端口号和IP地址,并照例发出请求。
SER从目的地UA收到肯定的SIP回复(“OK”)。SER将再次从信息的SDP部分抽取其呼叫ID,并发送至录音应用。此时,如果发现该会话不存在,它将不再分配新会话。它只是简单地在现有会话中进行查找,如果找到该会话就返回端口号,如果未找到该会话就返回错误信息。在收到录音应用的肯定回复后,SER会将呼叫终端的原有地址/端口更换为录音系统的端口号和IP地址,并照例发出请求。
会话建好之后,录音应用将会使用R4 IPML API在自身与外部UA之间建立起两个独立的RTP连接。然后再将由此产生的Scbus时隙相连接,创建一个全双工连接。这时就可以使用多时隙对话录音开始呼叫录音操作。
收到一个UA的BYE之后,SER会将该BYE中继给其它UA。如果收到“OK”,SER则将从第二个UA中抽取呼叫ID并发送到录音应用。该ID与现有录音会话匹配。录音终止,双向数据传输停止。向BYE信息的发送者中继“OK”,完成SIP信令。

附录:在线录音系统结构比较

作为“代理RTP”在线录音系统的替选方法,您也可以使用一些以太网交换机上经常采用的“端口监控”。在这种情况下,录音应用引导交换机复制需要录音的对话RTP数据流。IP录音系统然后接收分组流,并使用英特尔 NetStructure HMP进行录音。下表分别介绍了这两种方法的优缺点。