要点综述

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

目录

介绍
高层体系结构
讯息流程
附录：在线录音系统结构比较
术语缩写
了解更多信息

介绍

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

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

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

　　在本文所述的"代理RTP"中，使用Dialogic® NetStructure™ HMP作为媒体管理器具有如下优势：

• 通过熟悉的API简化应用编程


• 提高信道密度


• 便于使用低位速语音信号编码器，进而减少录音所需要的磁盘空间


• 全面控制录音过程，包括结尾


• 轻松获取语音数据流，轻松进行诸如流传输至ASR服务器进行关键字查询（word spotting）等操作

　　SER仅适用于Unix或Linux环境。因为它是一款相对"轻量级"的应用，所以它可以很好地与面向Linux的Dialogic® 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数据流，以替代直接连接两个终端的单个数据流。该应用使用DialogicR4 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录音系统然后接收分组流，并使用Dialogic® NetStructure™ HMP进行录音。下表分别介绍了这两种方法的优缺点。

	端口监控	代理RTP
RTP流量	一对额外的RTP数据流承载对话通过录音系统	需要两只“腿”（各为一对RTP数据流）重新引导从交换机到录音系统的对话
设备故障	录音系统出现故障对语音流量没有影响	语音流量依赖于录音系统的运行情况。通过在另一个系统上提供第二个代理（没有录音），可以避免这种依赖性
现有IP基础设施改建	并非所有交换机均有端口监控。         部署端口监控意味着以高昂的成本改变呼叫中心的基础设施	除录音系统要求的硬件外无需额外硬件。只需较小幅度地对SIP终端进行重新配置，以使它们能够与代理录音系统共同使用即可
安全性	未经授权的系统可能会通过端口监控进入语音数据流	所有语音数据流都经过单个系统进行传输，可最大限度保证安全性
尺寸调整	可能会限制同时被监控的端口数量	录音系统的规模可以按需进行调整
录音智能	录音应用可能难以确定录音的内容和时间	可以轻松地抽取SIP讯息中的讯息，以用于控制和定制录音