罗云飞 廖建新 曹予飞 荀兆勇
摘要:通话回放(Talk Record and Play Back,TRPB)业务是在用户通话过程中可以动态触发并进行通话录音,事后通过拨打特殊号码听取录音回放的一种增值业务。基于IMS (IP Multimedia Subsystem,IP多媒体子系统)网络的体系结构以及通话回放业务的业务特征,本文提出了一种利用通话回放业务平台(Talk Record & Play Back Service Platform,TRPBSP)来实现通话回放业务的解决方案,包括实现方案、详细设计以及基于SIP(Session Initiation Protocol,会话启动协议)消息的信令流程。同时,对业务特点进行分析并进行了总结。
关键词:通话回放,增值业务,会话启动协议,IP多媒体子系统,通话回放业务平台
1.引言
在移动通信向全IP的网络架构演进的趋势下,3GPP在UMTS R5中引入了IMS(IP Multimedia Subsystem,IP多媒体子系统),并在后续的标准系列R6、R7中进一步完善。IMS以移动分组网(GPRS)等IP网络为承载,为IP多媒体业务提供一套完整的解决方案,来满足多媒体业务在安全、计费、漫游以及QoS上的需求。IMS主要采用SIP(Session Initiation Protocol,会话启动协议)[1]作为呼叫控制协议,与上层控制子系统和具体的接入技术无关。是业界普遍认同的解决移动和固定网络融合的理想方案和发展方向。
目前在通话过程中,只能通过手机或电话设备的录音功能进行录音,有些重要的通话(如:领导指示、重要合作伙伴商谈等)需要录音后进行进一步细听或体会,若能在交换机侧或应用平台通过其他方法进行录音,事后通过拨打某个特殊号码进行录音回放,则可以给用户带来极大的便利。
通话回放(Talk Record & Play Back,TRPB)业务可以在用户通话之前或通话过程中动态触发,通过通话回放业务平台(Talk Record & Play Back Service Platform,TRPBSP)对主被叫的通话进行录音,录音结束后系统自动对录音文件进行有效管理,并提供用户接入方法,方便用户对录音文件进行查询、删除、回放等操作。
本文对基于IMS的通话回放业务的设计及实现进行详细阐述:首先从总体上介绍通话回放业务的设计方案,包括组网方式、系统设计;然后对技术实现和信令流程进行介绍;最后给出业务的特点分析和总结。
2.业务描述
通话回放的主要特征是用户在通话过程中可以对通话进行录音,通话结束后可以接入系统并进行录音回放。其主要业务特征描述如下:
-
用户可以在正常通话的状态下,通过按*或#键2秒以上触发录音,也可以在通话之前设置启动录音。
-
录音过程可以持续到通话结束,或者录音的发起方同样按键2秒以上来停止录音。
-
录音结束后,通话回放业务平台自动对录音文件进行有效管理,录音文件与通话录音发起方建立关联。
-
按照系统设计容量来设置录音文件的保存时间(如3个月),超时后录音文件自动删除,用户也可以通过拨打特殊号码手动删除。
-
通话回放业务平台提供用户接入方法,用户可以通过拨打特殊号码接入系统,对录音文件进行管理,如查询、删除、回放等操作。用户也可以通过Web接入方式实现同样的管理操作。
-
录音文件只能是录音发起方才能进行操作,其他用户均不能进行操作,系统可以采用鉴权或主叫识别技术。
3.实现方案
3.1组网方案
IMS网络采用分层的体系结构:IMS信令网基于SIP协议实现呼叫控制;业务运行在控制层以上,通过SIP消息与CSCF(Call Session Control Function,呼叫会话控制功能)进行业务控制的交互;控制层和业务层之间具有开放的接口,允许运营商采用单一的核心网提供横跨移动网和固定网基于SIP的业务。
如图1所示,通话回放业务平台主要由AS和MS组成,其中AS是应用服务器,运行通话回放的业务逻辑,并与S-CSCF交互以进行业务控制;MS是媒体服务器,负责媒体资源的提供和处理,包括通话的录音、回放等。
IMS核心网设备S-CSCF对呼叫进行控制,并根据用户的业务属性或用户动作,将通话回放业务触发到通话回放业务平台。通话回放业务平台的AS控制MS对主被叫的通话进行桥接,并进行通话录音。通话结束后,用户可以通过拨打特殊号码,接入通话回放业务平台,进行录音回放。
3.2系统设计
如图2所示,通话回放业务平台包括应用服务器AS、媒体服务器MS、媒体资源服务器、数据库服务器、门户网站Portal等单元。
-
AS进行业务控制,运行通话回放业务逻辑,根据业务逻辑对媒体服务器进行控制。AS通过SIP消息与S-CSCF和MS交互控制信令。
-
MS接受AS的控制,主要实现通话录音以及录音回放等功能。MS与主被叫之间基于IP网络通过RTP协议(Real-time Transport Protocol,实时传输协议)传送媒体流;
-
媒体资源服务器用于存储对用户通话进行录音后生成的媒体文件,媒体资源服务器与MS之间通过NFS/TFTP协议传送媒体文件。
-
数据库服务器用于保存用户的业务数据以及媒体资源信息,AS和Web页面通过数据库访问接口来访问和修改数据库。
-
门户网站Portal为用户提供WWW接入网站,使用户可以通过Web方式接入通话回放业务平台,对自己的媒体信息(录音文件)进行管理,如添加、删除、回放等操作。
3.3信令流程
图3为通话回放业务在主被叫已经建立呼叫的情况下,从触发业务开始录音到通话结束停止录音的信令流程。
如图所示,在触发通话回放业务时,S-CSCF将SIP信令(INFO消息)路由至AS,AS控制MS分别与主被叫建立连接,并对主被叫的通话进行录音。通话结束后,AS控制MS分别与主被叫拆除连接,同时停止录音操作。
为简化流程描述,图中并未标出I-CSCF和P-CSCF,并假定主被叫属于同一个IMS网络。图中消息后的编号(a、b、c、d)是用于区分不同的SIP对话。此外,本文仅描述业务触发、开始录音、结束呼叫、停止录音的信令流程,对于用户在维持呼叫的情况下主动停止录音的操作,以及用户进行录音回放操作的信令流程,本文不作进一步阐述。
详细流程说明如下:
1~2:主被叫正常通话时,主叫UE1按*或#键2秒以上触发通话回放业务,S-CSCF将业务触发到通话回放业务平台,使用INFO消息[2]携带业务信息。
3:AS向MS发送INVITE消息,请求MS与UE1建立连接。
4:MS用200 OK消息应答INVITE a。
5~6:AS向UE1发送INVITE消息,该消息实为REINVITE,请求UE1修改会话属性,释放与UE2的连接,并重新建立与MS的连接。
7~8:UE1用200 OK消息应答INVITE b,确认连接。
9~10:AS返回INVITE b的最终确认ACK。
11:AS返回INVITE a的最终确认ACK,此时MS与UE1建立会话连接。
12~20:通过同样的流程,MS与UE2建立会话连接。此时,MS开始对UE1和UE2的通话进行桥接,并对通话进行混音和录音操作。
21~22:UE2挂机,中断与MS的连接,发送BYE消息(对应于INVITE d)至AS。
23~24:AS发送200 OK确认消息至UE2。
25~26:AS发送BYE消息(对应于INVITE b)至UE1,请求UE1中断与MS的连接。
27~28:UE1中断与MS的连接,发送200 OK确认消息至AS。
29:AS发送BYE消息(对应于INVITE a和INVITE c)至MS,请求MS停止录音,并中断与UE1和UE2的连接。
30:MS停止录音,中断与UE1和UE2的连接,发送200 OK确认消息至AS,此时呼叫和连接被完全释放。
3.4方案总结
通话回放业务的特点是用户在通话过程中可以动态地触发业务,通话回放业务平台对主被叫的通话进行录音,并自动对录音文件进行有效管理,通话结束后用户可以接入通话回放业务平台进行录音回放。
目前在2G网络和3G R4网络中,通话回放业务的实现都有一定的困难。在2G网络中,由于需要在IP设备中建立三方呼叫,因而对IP设备的承载能力要求很高,资源占用比较严重。在R4网络中,业务实现需要在媒体网关侧(MGW)建立三方呼叫,由MGW完成对主被叫通话的混音操作,并发送给媒体服务器由媒体服务器完成录音操作,因而对MGW能力要求较高。
通话回放业务在IMS网络中的实现具备一定的优势,由于业务实现时,主被叫的通话是通过媒体服务器进行桥接,并由媒体服务器自动完成录音操作的,因而资源占用适当,实现方式较为简单,并且业务可以快速、高效地进行部署。
不过,通话回放业务在IMS网络中的实现也存在如下缺点:由于主被叫是在已经建立连接和通话的情况下中断原来的连接并重新建立与媒体服务器的连接(通过REINVITE消息),有可能造成一定程度的通话中断、失真或者延迟。由于IMS核心网不承担话路的承载,因而将媒体服务器连接到已经建立的主被叫话路时,上述问题就必然存在。
4.结束语
本文结合IMS网络的体系架构和通话回放业务的业务特征,提出了在IMS网络中利用通话回放业务平台实现通话回放业务的一种方案,并对组网方案、详细设计以及信令流程进行了阐述,对业务特点进行了分析和总结。
基于IMS的通话回放业务可以方便用户对重要通话过程的记录,并且业务触发和使用方式较为方便,业务属性具有很好的吸引力,市场前景看好,势必会成为3G增值业务新的增长点之一。
5.参考文献
[1]J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. SIP: Session Initiation Protocol. RFC 3261, IETF, June 2002
[2]S. Donovan, The SIP INFO Method. RFC 2976, IETF, October 2000
[3]E. Burger, J. Van Dyke, A. Spitzer. Basic Network Media Services with SIP. RFC 4240, IETF, December 2005
[4]Signalling flows for the IP multimedia call control based on Session Initiation Protocol (SIP)
and Session Description Protocol (SDP); 3GPP TS 24.228; 3GPP; June 2005
|