一种软交换录音系统热备份的实现方法

阅读: 评论:0

著录项
  • CN201610333118.5
  • 20160519
  • CN105847604A
  • 20160810
  • 河北远东通信系统工程有限公司
  • 王金辉;王增顺;沈广茂
  • H04M3/42
  • H04M3/42 H04L29/06 H04M7/00

  • 河北省石家庄市鹿泉经济开发区昌盛大街21号
  • 河北(13)
  • 河北东尚律师事务所
  • 王文庆
摘要
本发明公开了一种软交换录音系统热备份的实现方法,涉及软交换通信领域。本发明在集中式录音方式基础上,在软交换设备中配置两台以上的录音服务器,然后向媒体服务器申请至少4个录音端口;录音端口申请成功后,主叫用户和被叫用户将主叫RTP流和被叫RTP流分别发送到媒体服务器的对应的录音端口;媒体服务器将收到的主叫RTP流和被叫RTP流分别发送到每个录音服务器。本发明和分布式方式相比,有效的降低了录音系统的成本;多台录音服务器中只要有一台录音服务器正常工作,就能保存完整的RTP流,从而提高录音系统的可靠性,实现全网录音系统的热备份。
权利要求

1.一种软交换录音系统热备份的实现方法,其特征在于,包括以下步骤:

S1:在软交换设备中配置两台以上的录音服务器,所有录音服务器注册到软 交换设备;

S2:主叫用户向软交换设备发起呼叫请求,呼叫请求中携带SDP信息;所 述的SDP信息包括主叫RTP流的IP地址和RTP端口;

S3:软交换设备收到呼叫消息后,分析主叫用户和被叫用户的业务属性,如 果主叫用户和被叫用户中至少一方登记了录音业务,则触发录音业务逻辑,转至 S5;如果主叫用户和被叫用户均没有登记录音业务,则转至S4;

S4:软交换设备控制主叫用户与被叫用户进行媒体协商后,主叫用户和被叫 用户正常通话,结束本流程;

S5:录音业务逻辑向媒体服务器申请至少4个录音端口,并判断录音端口是 否申请成功,如果录音端口申请失败,则转至S4;如果录音端口申请成功,则 转至S6;

S6:录音业务逻辑向主叫用户回复媒体服务器对主叫用户分配的录音端口信 息;同时,向被叫用户和所有录音服务器分别发起呼叫请求,对被叫用户发起的 呼叫请求中包含媒体服务器对被叫用户分配的录音端口信息,对录音服务器发起 的呼叫请求中包含媒体服务器对该录音服务器分配的录音端口信息;

S7:主叫用户、被叫用户和所有录音服务器在收到各自的录音端口信息后分 别发送反馈信息至录音业务逻辑;

S8:录音业务逻辑收到主叫用户、被叫用户和所有录音服务器的反馈信息后, 通知媒体服务器将所有录音端口形成会议;

S9:主叫用户和被叫用户将主叫RTP流和被叫RTP流分别发送到媒体服务 器的对应的录音端口;

S10:媒体服务器将收到的主叫RTP流和被叫RTP流分别发送到每个录音 服务器;

S11:所有录音服务器均将收到的主叫RTP流和被叫RTP流进行保存。

2.根据权利要求1所述的一种软交换录音系统热备份的实现方法,其特征 在于:所述的录音业务逻辑部署在软交换设备内部或者软交换设备外部。

3.根据权利要求1所述的一种软交换录音系统热备份的实现方法,其特征 在于:S5中所述的软交换设备向媒体服务器申请至少4个录音端口为:软交换 设备为主叫用户申请1个录音端口,被叫用户申请1个录音端口,每个录音服务 器对应申请一个录音端口。

4.根据权利要求3所述的一种软交换录音系统热备份的实现方法,其特征 在于:S4之后还包括录音业务逻辑检查媒体服务器和录音服务器的连接状态, 如果媒体服务器连接状态不正常,或者所有的录音服务器连接状态均不正常,则 执行S4;如果媒体服务器正常、并且至少一台录音服务器正常,则执行S5。

5.根据权利要求3或4所述的一种软交换录音系统热备份的实现方法,其 特征在于:S6、S7或者S8之后还包括软交换设备将媒体服务器上与录音服务 器通信的录音端口设置为ReceiveOnly模式。

说明书
技术领域

本发明涉及软交换通信领域,特别是涉及集中式软交换录音系统热备份的实 现方法。

软交换系统基于VOIP技术,通过IP网络,实现了分布式部署。在软交换 系统中,终端和终端或网关设备的语音通过RTP(Realtime Transport Protocol实 时传输协议)在网络上传输。在呼叫过程中,主叫发起呼叫时,呼叫协议中携带 的SDP数据中包含了主叫媒体流的IP地址、RTP端口。软交换设备在进行号码 分析、路由选择等呼叫控制操作后,将主叫的媒体流信息转发给被叫。被叫进行 媒体协商后,对呼叫的响应消息中携带了被叫媒体流的IP地址、RTP端口,软 交换设备将被叫的媒体流信息又转发给了主叫,这样,通话双方就获取了对方的 媒体流信息,从而语音就在通话双方之间进行交互。在此过程中,软交换设备仅 仅起到了媒体流信息的转发功能,媒体流并不经过软交换设备。

针对软交换系统的录音,一般采用分布式方式或集中式方式。分布式采用端 口镜像方式。端口镜像方式是将录音服务器和终端或网关部署到同一台网络交换 机上,将终端或网关连接的端口镜像到录音服务器连接的端口上,这样录音服务 器便可以获取到终端或网关的媒体流,如图1所示。集中式方式采用媒体服务器 方式,原理是软交换设备利用媒体服务器的会议功能,将被录音用户和媒体服务 器的某个端口形成会议,从而在媒体服务器上获取被录音用户的媒体流,如图2 所示。

无论是分布式还是集中式,都存在一旦录音服务器出现故障,就会导致无法 录音的问题。

本发明在集中式录音方式基础上,创建了一种热备份的录音方式。本发明提 高了录音系统的可靠性,保证了多台录音服务器组成的录音系统中,单台录音服 务器故障后,录音系统还能正常工作。

本发明通过以下技术方案来实现:一种软交换录音系统热备份的实现方法, 包括以下步骤:

S1:在软交换设备中配置两台以上的录音服务器,所有录音服务器注册到软 交换设备;

S2:主叫用户向软交换设备发起呼叫请求,呼叫请求中携带SDP信息;所 述的SDP信息包括主叫RTP流的IP地址和RTP端口;

S3:软交换设备收到呼叫消息后,分析主叫用户和被叫用户的业务属性,如 果主叫用户和被叫用户中至少一方登记了录音业务,则触发录音业务逻辑,转至 S5;如果主叫用户和被叫用户均没有登记录音业务,则转至S4;

S4:软交换设备控制主叫用户与被叫用户进行媒体协商后,主叫用户和被叫 用户正常通话,结束本流程;

S5:录音业务逻辑向媒体服务器申请至少4个录音端口,并判断录音端口是 否申请成功,如果录音端口申请失败,则转至S4;如果录音端口申请成功,则 转至S6;

S6:录音业务逻辑向主叫用户回复媒体服务器对主叫用户分配的录音端口信 息;同时,向被叫用户和所有录音服务器分别发起呼叫请求,对被叫用户发起的 呼叫请求中包含媒体服务器对被叫用户分配的录音端口信息,对录音服务器发起 的呼叫请求中包含媒体服务器对该录音服务器分配的录音端口信息;

S7:主叫用户、被叫用户和所有录音服务器在收到各自的录音端口信息后分 别发送反馈信息至录音业务逻辑;

S8:录音业务逻辑收到主叫用户、被叫用户和所有录音服务器的反馈信息后, 通知媒体服务器将所有录音端口形成会议;

S9:主叫用户和被叫用户将主叫RTP流和被叫RTP流分别发送到媒体服务 器的对应的录音端口;

S10:媒体服务器将收到的主叫RTP流和被叫RTP流分别发送到每个录音 服务器;

S11:所有录音服务器均将收到的主叫RTP流和被叫RTP流进行保存。

其中,所述的录音业务逻辑部署在软交换设备内部或者软交换设备外部。

其中,S5中所述的软交换设备向媒体服务器申请至少4个录音端口为:软 交换设备为主叫用户申请1个录音端口,被叫用户申请1个录音端口,每个录音 服务器对应申请一个录音端口。

其中,S4之后还包括录音业务逻辑检查媒体服务器和录音服务器的连接状 态,如果媒体服务器连接状态不正常,或者所有的录音服务器连接状态均不正常, 则执行S4;如果媒体服务器正常、并且至少一台录音服务器正常,则执行S5。

其中,S6、S7或者S8之后还包括软交换设备将媒体服务器上与录音服务 器通信的录音端口设置为ReceiveOnly模式。

本发明相比背景技术的优点在于:

本发明采用了集中式录音方式,和分布式方式相比,有效的降低了录音系统 的成本;多台录音服务器中只要有一台录音服务器正常工作,就能保存完整的 RTP流,从而提高录音系统的可靠性,实现全网录音系统的热备份。

图1是背景技术中分布式录音系统的连接示意图。

图2是背景技术中集中式录音系统的连接示意图。

图3是本发明的集中式录音热备份系统的连接示意图。

图4是本发明的集中式录音热备份系统的流程图。

下面结合附图和实施例对本发明所述方法做进一步详细描述。

实例:结合图3和图4,设主叫用户为录音用户,被叫用户为普通用户,配 置两台录音服务器。则,一种软交换录音系统热备份的实现方法,包括以下步骤:

S1:在软交换设备的数据配置中配置两台录音服务器,两台录音服务器均注 册到软交换设备;

S2:主叫用户向软交换设备发起呼叫请求,呼叫请求中携带主叫号码、被叫 号码和SDP(Session Description Protocol,会话描述协议)信息;

SDP信息中包含:主叫RTP流的IP地址、RTP端口、语音编解码能力。

S3:软交换设备收到呼叫请求后,首先对主叫用户进行鉴权,鉴权通过后, 通过数据库配置,检查主叫用户和被叫用户的业务属性,如果主叫用户和被叫用 户中至少一方登记并激活了录音业务,则触发录音业务逻辑,转至S5;如果主 叫用户和被叫用户均没有登记激活录音业务,则转至S4;

录音业务逻辑可以部署在软交换设备内,也可以部署在软交换设备外。

S4:软交换设备控制主叫用户与被叫用户进行媒体协商后,主叫用户和被叫 用户正常通话,结束本流程;

S5:录音业务逻辑检查媒体服务器和录音服务器的连接状态,如果媒体服务 器连接状态不正常,或者所有的录音服务器连接状态均不正常,则转至S4;如 果媒体服务器正常、并且至少一台录音服务器正常,则执行S6;

S6:录音业务逻辑向媒体服务器申请4个录音端口;

软交换设备为主叫用户申请1个录音端口,被叫用户申请1个录音端口,两 台录音服务器对应申请两个录音端口。

S7:媒体服务器分配4个录音端口,并将媒体信息发送到录音业务逻辑;

媒体信息包括:媒体流的IP地址、4个RTP端口、语音编解码能力;

S8:录音业务逻辑判断录音端口是否申请成功,如果录音端口申请失败,则 转至S4;如果录音端口申请成功,则转至S9;

S9:录音业务逻辑向主叫用户回复媒体服务器向主叫用户回复媒体服务器对 主叫用户分配的录音端口信息;同时,向被叫用户和所有录音服务器分别发起呼 叫请求,对被叫用户发起的呼叫请求中包含媒体服务器对被叫用户分配的录音端 口信息,对录音服务器发起的呼叫请求中包含媒体服务器对该录音服务器分配的 录音端口信息;

S10:主叫用户、被叫用户和两个录音服务器在收到各自的录音端口信息后, 进行媒体协商,并将协商结果发送到录音业务逻辑;

S11:录音业务逻辑收到协商结果后向媒体服务器发送形成会议指令,同时, 设置媒体服务器和录音服务器之间的通信端口的媒体流收发模式为ReceiveOnly 模式;

设置媒体服务器和录音服务器之间的通信端口的媒体流收发模式还可以在 S9或者S10之后。

S12:主叫用户和被叫用户将主叫RTP流和被叫RTP流分别发送到媒体服 务器的对应的录音端口;

S13:媒体服务器将收到的主叫RTP流和被叫RTP流分别发送到每个录音 服务器;

S14:录音服务器收到主叫RTP流和被叫RTP流后,保存为文件。

本文发布于:2023-04-14 10:37:41,感谢您对本站的认可!

本文链接:https://patent.en369.cn/patent/3/86572.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

留言与评论(共有 0 条评论)
   
验证码:
Copyright ©2019-2022 Comsenz Inc.Powered by © 369专利查询检索平台 豫ICP备2021025688号-20 网站地图