介绍

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

本应用注释推荐一种适用于IP环境的在线录音方法。该方法采用高性能、可配置的开放源代码SIP（RFC3261）服务器――SIP 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. 高层体系结构

高层体系结构

图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”在线录音系统典型呼叫录音的讯息流程图解。图中数字对应于下文的段落编号。

图2. 典型呼叫录音的讯息流程

1.          SER经过配置可作为一个有状态的代理，以负责中继呼叫期间生成的所有SIP讯息。当SER从源UA收到INVITE请求之后，它将从请求中提取SIP呼叫ID，并通过流程间套接字连接将其传送到RTP代理会话管理器。会话管理器使用该ID在现有会话中进行查找，如果该会话存在，则返回该会话的用户数据包协议（UDP）端口。如果该会话不存在，则创建一个新会话，将其绑定至配置/启动期间指定范围内的第一个空UDP端口，并将端口号返回SER。收到录音应用的回复之后，SER再将呼叫终端的原有地址/端口更换为录音系统的端口号和IP地址，并照例发出请求。

2.          SER从目的地UA收到肯定的SIP回复（“OK”）。SER将再次从讯息的SDP部分抽取其呼叫ID，并发送至录音应用。此时，如果发现该会话不存在，它将不再分配新会话。它只是简单地在现有会话中进行查找，如果找到该会话就返回端口号，如果未找到该会话就返回错误信息。在收到录音应用的肯定回复后，SER会将呼叫终端的原有地址/端口更换为录音系统的端口号和IP地址，并照例发出请求。

3.          会话建好之后，录音应用将会使用R4 IPML API在自身与外部UA之间建立起两个独立的RTP连接。然后再将由此产生的Scbus时隙相连接，创建一个全双工连接。这时就可以使用多时隙对话录音开始呼叫录音操作。

4.          收到一个UA的BYE之后，SER会将该BYE中继给其它UA。如果收到“OK”，SER则将从第二个UA中抽取呼叫ID并发送到录音应用。该ID与现有录音会话匹配。录音终止，双向数据传输停止。向BYE讯息的发送者中继“OK”，完成SIP信令。

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

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

(责任编辑：刘鹏)

共找到 7,495,073 个相关网页.