CN101163172B - 一种应用于移动电话或固定电话交换系统的大容量媒体播送系统及大容量媒体播送方法 - Google Patents
一种应用于移动电话或固定电话交换系统的大容量媒体播送系统及大容量媒体播送方法 Download PDFInfo
- Publication number
- CN101163172B CN101163172B CN2007101566914A CN200710156691A CN101163172B CN 101163172 B CN101163172 B CN 101163172B CN 2007101566914 A CN2007101566914 A CN 2007101566914A CN 200710156691 A CN200710156691 A CN 200710156691A CN 101163172 B CN101163172 B CN 101163172B
- Authority
- CN
- China
- Prior art keywords
- media
- medium
- file
- processing device
- disposable plates
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供了一种应用于移动电话或固定电话交换系统的大容量媒体播送系统。它包括以下组成部分:具备数据存储、处理机和网络功能的媒体存储服务器,媒体处理设备,媒体处理设备能够以文件下载和流媒体实时传送两种方式从媒体存储服务器获取预先存储的媒体内容。本发明能够海量地存储媒体文件并可有选择地采用文件下载或流媒体实时传送两种方式播送文件,所以能够提供大量媒体内容的集中存储,并为较大数量的用户同时提供媒体播送服务。本发明还提供了一种能高效处理媒体文件的应用于移动电话或固定电话交换系统的大容量媒体播送方法,在一般业务条件下可以避免媒体处理板和媒体存储服务器之间大部分的下载流量,从而降低媒体处理板和媒体存储服务器的负荷,能够解决大容量媒体播送系统中存在的存储容量和下载带宽之间的矛盾,在相同的硬件技术条件下,大大提高单系统支持的最大业务容量。
Description
技术领域
本发明涉及固定通信网、移动通信网、软交换以及3G通信网络等的增值业务领域,具体涉及应用于其中的大容量媒体播送方法。
背景技术
随着通信技术的不断进步,人们已经不满足于单一的语音业务,视频业务和多媒体业务逐渐发展起来,同时各种各样的增值业务也不断壮大。
在一些对媒体资源要求比较高的大型增值业务应用中,如个性化回铃音业务,普通的语音处理卡或媒体处理卡不能满足大容量要求,一般采用以交换机内置智能外设为基础发展起来的媒体和语音处理平台。虽然交换机平台能满足系统大容量要求,但是内置的媒体处理板卡中无法存储太多的媒体信息,即便能够存储,由于板卡数量较多,海量的媒体信息如何进行同步也是个难题。采用外置文件服务器存储媒体信息是比较合理的,但是由于大量用户并发的读写操作,使服务器性能成为了瓶颈。
发明内容
本发明首先所要解决的技术问题是提供一种适于合理处理大容量媒体文件的应用于移动电话或固定电话交换系统的大容量媒体播送系统。为此,本发明采用以下技术方案:它包括以下组成部分:
具备数据存储、处理机和网络功能的媒体存储服务器,所述媒体存储服务器能够为媒体处理设备同时提供文件下载和流媒体实时传送两种媒体传输服务;
媒体处理设备,媒体处理设备能够以文件下载和流媒体实时传送两种方式从媒体存储服务器获取预先存储的媒体内容;所述媒体处理设备置有媒体处理板、主控处理机、承载接口板;所述媒体处理板具备预存或缓存媒体文件的内存文件系统,并能利用内存文件系统进行媒体播送;所述媒体处理板设有媒体格式的转换和处理装置,所述媒体格式的转换和处理装置将从媒体存储服务器取得的媒体内容按照媒体需要传送的格式进行处理;所述主控处理机与媒体处理板之间通过内部数据链路通信,并通过以太网向业务控制节点提供控制管理接口;所述承载接口板对外提供TDM电路接口和/或IP媒体承载接口,通过公共通信网络向用户终端播送各种媒体内容。
由于采用本发明的技术方案,能够海量地存储媒体文件并可有选择地采用文件下载或流媒体实时传送两种方式播送文件,所以能够提供大量媒体内容的集中存储,并为较大数量的用户同时提供媒体播送服务。与采用交换机叠加语音卡平台方案的系统相比,本发明所述系统的设计更加紧凑,提高了硬件系统的集成度,并可以节省较多的硬件成本,而且不受语音卡平台容量较小的限制,单系统支持的业务容量可达到百万用户以上。
本发明另一个所要解决的技术问题是提供一种能高效处理媒体文件的应用于移动电话或固定电话交换系统的大容量媒体播送方法。为此,本发明采用以下技术方案:它以前述媒体播送系统为其媒体播送系统,并包括以下主要步骤:
1)、媒体处理设备接收业务控制节点的媒体文件播放命令;
2)、所述媒体播送系统对命令中指定媒体文件的使用频率进行统计,当使用频率低于门限时转到步骤“6)”,否则继续;
3)、检查媒体处理设备的媒体处理板中是否已经缓存了指定的媒体文件,如果是转到步骤“5)”,否则继续;
4)、媒体处理设备开始从媒体存储服务器下载指定的媒体文件,已经下载的文件内容保存在媒体处理板中;
5)、媒体处理设备对媒体处理板中的媒体内容进行格式转换处理,并向用户终端实时播送,直到播放过程结束。
6)、媒体处理设备以流媒体方式从服务器获取指定媒体内容,并实时向用户终端播送,直到播放过程结束。
由于采用本上述技术方案,在一般业务条件下可以避免媒体处理板和媒体存储服务器之间大部分的下载流量,从而降低媒体处理板和媒体存储服务器的负荷,能够解决大容量媒体播送系统中存在的存储容量和下载带宽之间的矛盾,在相同的硬件技术条件下,大大提高单系统支持的最大业务容量。
附图说明
图1为本发明所提供的媒体播送系统在彩铃应用中的系统逻辑框图。
图2为图1所示实施例以流媒体方式实现媒体播送的内部结构图。
图3为图1所示实施例的流媒体方式的媒体播送流程图。
图4为图1所示实施例的文件下载方式的媒体播送流程图。
图5为图1所示实施例与业务控制节点交互的框架流程图。
图6为图1所示实施例的主控软件媒体播放流程图。
图7为图1所示实施例的媒体存储服务器的软件逻辑框图。
图8为图1所示实施例的分布式服务器方式的系统连接图。
图9为图1所示实施例的系统应用逻辑框图。
具体实施方式
参照附图9。本发明所提供的应用于移动电话或固定电话交换系统的大容量媒体播送系统包括以下组成部分:
具备数据存储、处理机和网络功能的媒体存储服务器,所述媒体存储服务器能够为媒体处理设备同时提供文件下载和流媒体实时传送两种媒体传输服务;
媒体处理设备,媒体处理设备能够以文件下载和流媒体实时传送两种方式从媒体存储服务器获取预先存储的媒体内容;所述媒体处理设备置有媒体处理板、主控处理机、承载接口板;所述媒体处理板具备预存或缓存媒体文件的内存文件系统,并能利用内存文件系统进行媒体播送;所述媒体处理板设有媒体格式的转换和处理装置,所述媒体格式的转换和处理装置将从媒体存储服务器取得的媒体内容按照媒体需要传送的格式进行处理;所述主控处理机与媒体处理板之间通过内部数据链路通信,并通过以太网向业务控制节点提供控制管理接口;所述承载接口板对外提供TDM电路接口和/或IP媒体承载接口,通过公共通信网络向用户终端播送各种媒体内容。
以下以在彩铃中应用为例,详细描述本发明所提供的系统及播送方法。
一、系统总体设计
1、系统逻辑框图,参照图1。
由多台媒体存储服务器和多个媒体处理设备组成了前置处理平台,业务管理平台相对独立,媒体存储服务器和业务控制节点分别在不同的服务器上运行,媒体存储服务器采用分布式结构。媒体处理设备由主控处理机和媒体处理板等部件组成,媒体处理板具备缓存较大容量媒体文件的功能,播放的媒体文件大部分可以从媒体处理板内存中提取,只有少数呼叫需要到媒体存储服务器以文件或流媒体方式存取。实现此种技术方案,对媒体存储服务器的要求较低,可以采用低成本的刀片式服务器。
媒体处理设备除了媒体处理板外,还可以包括主控处理机、承载接口板等其它板卡。主控处理机与媒体处理板之间通过内部数据链路通信,它的通信带宽较小,只能作为单板业务控制和管理的通道。主控处理机和媒体处理板都有以太网接口,主控处理机通过以太网向业务控制节点提供控制管理接口,而媒体处理板也是通过以太网从媒体存储服务器下载媒体内容。
图1中的各缩写名词定义如下:
CBRT platform:彩铃系统应用平台
CN:业务控制节点
IPS:媒体处理设备
MCU:主控处理机
MFIP:媒体处理板
VRS:媒体存储服务器
DTP:承载接口板
接口Ic:前后台业务控制接口
接口Iv:媒体文件传输接口
接口Im:媒体文件管理接口
2、图1中各功能模块的划分
2.1、CBRT platform
彩铃系统应用平台使用成熟的语音管理设备,可以实现特服号/WEB/WAP接入方式。提供一个直观的用户界面给用户,通过这个管理界面,用户可以方便的进行:
(1)多彩回铃音业务申请,可以申请、撤销此业务功能。
(2)个人的主叫分类名单,可以增加,删除,修改分类的类别,可以增加,删除每个类别的用户。
(3)管理每个类别对应的回铃音,可以删除、重新选择回铃音音乐。
(4)可以在线试听所有提供的回铃音。
系统提供了电话用户接口(管理接口)、WEB接口以及WAP接口,使得用户可以方便的开通业务和定制音乐,同时,开放与内容提供商的接口,通过多个内容提供商为该业务提供丰富的音乐回铃声以供用户选择。
2.2、CN
业务控制节点(CN)是后台应用系统的控制核心,提供如下功能:
(1)资源管理功能:管理消息标识号与语音文件名的对应关系;管理话路资源与电路识别码的对应关系;管理用户界面脚本。
(2)呼叫状态维护功能:对每一个呼叫利用一个程序实例维护其状态;
(3)话务量控制功能:能有效抑制过负荷;
(4)主动呼出功能:能控制信令节点进行有效的呼出;
(5)信令处理能力:事务能力应用部分(TCAP)编解码、ISDN用户部分(ISUP)编解码,易于扩充和升级。
2.3、MCU
媒体处理设备(IPS)的主控处理机,完成交换机系统的信令处理、设备管理和业务控制等主要功能,在媒体处理上,MCU主要完成以下功能:
(1)MFIP单板的控制和管理:单板的复位、加载和监控等,并控制MFIP单板提供媒体播送、DTMF收发、会议等媒体处理功能。
(2)提供前后台彩铃业务呼叫控制接口:根据后台应用发送的指令完成彩铃业务流程的执行,并反馈相应的结果。
(3)协助完成用户终端和媒体资源之间的连接:利用交换机系统的信令处理、呼叫接续和交换控制等其它功能,共同完成用户需要的业务。
主控处理机(MCU)包括INTEL奔腾处理器、HDLC通信控制器、SDRAM内存、硬盘等主要部件,运行在主控处理机上的程序就是媒体处理设备的主控软件,具体实现见主控软件设计说明。
2.4、MFIP
媒体处理板(MFIP)作为媒体处理设备(IPS)的集媒体播放、DTMF/MFC/FSK收号、多方会议等功能为一体的单板。主要功能如下:
(1)语音缓存、播送和录制:支持A律PCM、ADPCM等语音编码;
(2)多媒体播送和录制:支持3G-324M多媒体格式,其中音频为AMR,视频为H.263和MPEG4;
(3)单板内交换功能:提供背板侧的1条PCM8M连接系统网络,单板内连接DSP的3条PCM8M的无阻塞的交换网络;
(4)DTMF/MFC/FSK收号功能:提供至少128路DTMF收号资源,并符合国标的各项指标要求
(5)多方会议功能:提供40个三方会议组合(可扩展3方以上但不超过120方会议功能)。
媒体处理板(MFIP)主要由一片MPC8250处理器和DSP6204资源池组成,主要技术参数如下:
(1)MPC8250处理器单元
——CPU采用MPC8250ZUMHBC(266/166/66MHz);
——采用512K×8bit的BOOTFLASH、64M×64bit的SDRAM、4M*16bit的FILEFLASH;
——提供2个10M/100M的自适应快速以太网接口,通过跳线器可分别从前面板RJ45插座引出或者从背面IO插座引出;
——可扩展的信令链路处理功能;
——提供1个操作系统调试需要的串口;
——可通过网络、双口实现用户代码在线升级;
——提供1个TTY监视串口;
——提供复位控制电路:上电复位、按扭复位,并提供一个复位按钮;
——提供内部调试灯控制电路,主要是:运行灯RUN、告警灯ALARM、以太网运行灯ENRUN1、ENRUN2;
(2)DSP6204资源池单元
——资源池由三片DSP构成,DSP芯片采用TI TMS320C6204GHK。每一片DSP理论上拥有1600MIPS的处理能力;
——CPU采用TMS320C6204GHK;
——每个DSP外接16MB的SDRAM;
——提供128个64Kbit/s的多通道链路,可以通过软件设计实现录放音功能、DTMF检测、多方会议等功能;
——可通过扩展总线口实现用户代码在线升级;
——提供复位控制电路:上电复位、软件复位;
2.5、DTP
承载接口板(DTP)的主要功能是对外提供媒体承载的TDM电路接口和IP媒体承载接口。
对外提供TDM电路接口时,承载接口板主要完成对E1/T1中继线2M码流的接收和发送,对接收、及发送的码流进行电平调整、码型转换,从接收码流中提取2.048M的时钟作为外标提供给系统,用于对整个系统进行相位锁定。承载接口板还对码流进行同步监视、误码统计、CRC-4校验,在必要时还要进行自环检测等,并完成各项告警功能。
对外提供IP媒体承载接口时,承载接口板主要完成RTP/RTCP实时传输协议的处理,通过IP通信网络实时传送语音和多媒体等。
2.6、VRS
媒体存储服务器主要提供媒体文件的存储、同步和实时下载等主要功能,它接受彩铃系统应用平台的管理,并为媒体处理板(MFIP)提供实时下载媒体文件的服务。
(1)媒体文件的存储和更新:根据彩铃系统应用平台的控制,存储和更新指定的媒体文件。
(2)媒体文件的文件下载服务:接收MFIP板的请求,下载所需要的媒体文件。
(3)流媒体下载服务:接收MFIP板的请求,把媒体文件转换成为媒体流实时传送给MFIP板。
二、系统设计说明
1、二级缓存结构
该技术方案采用VRS+MFIP实现,其中VRS与MFIP之间采用TFTP/NFS(标准协议)+RTP/ICP(自定义协议)方式实现。VRS作为MFIP的准实时媒体服务器,需要提高服务器性能(虚拟文件管理器,缩短文件打开速度),保证语音播放的实时性。
VRS具有一级媒体存储和缓存功能,作为媒体存储服务器,负责媒体资源的准实时播放。MFIP具有二级语音缓存功能,主要完成二级媒体缓存和实时播送功能。
2、MFIP选板和负荷分担
MCU利用算法区分热门和非热门媒体文件。
针对热门媒体文件播放:热门媒体文件的判断标准是根据单位时间内使用的频次来判断。在媒体资源分配命令中可以携带一个选择字,再以这个选择字对模块号和MFIP数量进行取模处理,分配对应的MFIP进行媒体处理。需要考虑MFIP板在线,故障,以及拥塞,正常等几种状态之间的切换。
针对非热门媒体文件播放:随机分配一块MFIP板处理,以流媒体方式下载并播放媒体文件,MFIP板不对播放的内容进行缓存。
MCU和MFIP一起构成系统有机的拥塞和过负荷控制功能。MFIP进入拥塞状态后,需要延时一定时间(1分钟左右)再报告给MCU;MCU收到MFIP拥塞状态后,立即停止分配非热门媒体文件的播放(热门媒体文件由于采用缓存结构,不影响MFIP和VRS之间的媒体下载速度)。
3、MCU和MFIP之间的通信
媒体播放开始和结束等进程由主控处理机MCU进行控制,最多可设2个可选媒体存储服务器提供下载,播放失败需要向MCU进行证实报告(负证实)。
MCU与MFIP之间可以根据功能要求,对MFIP进行静态初始功能配置,如板内基本参数设置,DSP功能分配等。
对业务控制通信报文(上/下行)进行统一定义,并留有可扩展的余地。设备管理报文类似原来的设备管理,需要增加拥塞状态报告。
4、VRS和MFIP之间的通信
管理报文采用ICP协议,支持媒体下载和上载等接口功能。
VRS和MFIP之间媒体传送采用NFS或TFTP协议,可配置。
媒体资源的同步:保证VRS和MFIP之间热门媒体文件的动态同步(具体热门媒体文件的数量根据内存和文件大小可以调整)。
5、系统组网和IP地址分配
VRS对外以太网接口采用与MCU相同的IP地址分配方案。MFIP根据位置采用统一算法生成的IP地址(与MCU不一致),这样MFIP可以做到即插即用。VRS与MFIP采用同一地址域,可以在网管上修改。
6、信源编码方式
如采用信源压缩编码的方式实现,可以较大地减少存储,硬盘读写和网口传输速度的处理瓶径。但带来了信源编码的反复转换(增加了互通和转换的复杂性),增加了协议的复杂性。
信源编码转换如采用服务器静态转换(仅需要一次性处理,不要求实时性),虽然要求较大的存储,硬盘读写和网口传输速度的处理能力,但是减少对前端DSP处理能力的要求(需要每次呼叫编码转换处理一次,要求较强的处理实时性)。由于采用DSP进行媒体压缩编码需要较大的DSP处理能力,目前采用前端设备实时进行语音压缩编码方式实现媒体处理的成本与前端采用G.711方式相比偏高。
目前VOIP以及NGN的应用,较为通用的语音信源编码仍采用G.711方式。也主要是传输带宽,成本,复杂性比较的结果。
7、流媒体传输
当媒体存储服务器与媒体处理设备之间采用流媒体的方式实时传送媒体内容时,在主控处理机的控制下,媒体存储服务器和媒体处理板互相进行流媒体的建立或释放。媒体存储服务器的主要功能是:大容量媒体文件的存储;接受IPS主控处理机的媒体服务控制,把媒体文件转换成流媒体。如图2所示,业务控制节点通过前后台控制接口给媒体处理设备的主控处理机发送媒体播送命令,主控处理机分配相关的资源并选择媒体文件的播送方式,并分别通过命令报文和控制接口控制媒体处理板和媒体存储服务器,以流媒体方式下载并播送媒体内容。
三、软件和播送流程控制
本节以彩铃业务为例给出具体的消息流程控制,说明系统内外部设备在业务执行过程中的相互关系,以及本发明所提供的大容量媒体播送方法,同时也更清楚地说明了媒体播放系统各部分的功能。
内部设备主要包括主控处理机(MCU)、媒体处理板(MFIP)和媒体存储服务器(VRS),其中主控处理机对外提供信令和控制接口,而媒体处理板对外提供媒体接口。
外部设备主要是业务控制节点(CN)和交换业务节点(SSP),其中业务控制节点与媒体播放设备一起组成了彩铃应用系统,而交换业务节点提供了彩铃应用系统与通信网络的连接,所有的通话建立都从交换业务节点主动发起。
1、媒体处理设备主控软件、媒体处理设备与交换业务节点的流程控制、媒体播送的控制。
媒体处理设备主控软件包括基础软件和应用软件,与媒体处理相关的应用软件主要是特殊资源管理软件(以下简称SRMP)。主控处理机的操作系统是VxWorks,在操作系统之上运行的是交换系统的基础软件,主控板通过高速数据链路(HDLC)与MFIP等业务板通信。基础软件屏蔽了操作系统的一些细节,为其它各部分的应用软件提供了各种必要的服务,主要包括系统运行机制、消息通信机制、资源管理、内存分配、定时器机制、打包解包、号码分析、操作维护接口等。
为了适应不同业务的需要,SRMP提供一个基本流程作为与业务控制节点交互的框架流程。所有的业务都遵循这个基本的框架流程,通过不同业务类型的组合完成不同的特殊资源流程。
媒体处理设备一般在业务完成后才返回结束消息,如果在业务尚未完成时,收到了下一次业务请求,前台将中断上一次的业务过程,并开始执行下一次的业务过程。但是媒体播放和录制是在不同方向的业务,如果两次业务分属于这两种情形,允许并行处理。
以下结合图5说明媒体处理设备与业务控制节点的流程控制
a)、业务控制节点在需要使用特殊资源时,首先向IPS发送特殊资源分配请求,根据所需的资源类型请求分配一组特殊资源。特殊资源是为某一条中继电路上的电话呼叫服务的,需要提供该中继的电路号以及提供特殊资源服务的业务类型。
b)、IPS验证特殊资源分配消息参数的正确性,根据业务类型选定所需资源组,并在资源组中选择一个空闲的特殊资源。如果消息中包含中继电路号,则完成中继和特殊资源的网络交换连接。向业务控制节点返回特殊资源分配证实消息,如果分配成功,输出特殊资源编号,如果分配失败,输出原因值。
c)、业务控制节点发送业务请求消息,IPS根据业务请求消息中携带的服务类型参数,启动不同类型的特殊资源服务。每种服务类型提供的功能,在下面有具体的说明。
d)、完成本次语音播放功能后,IPS回复业务响应消息,并且携带收集的数字和业务执行结果,指示业务是否完成。
e)、业务控制节点还有后续的业务请求,则继续发送,直到全部完成;
f)、每次完成服务后,IPS回复业务响应消息;
g)、如果没有后续的业务请求,后台会给IPS发送特殊资源释放消息,表示整个语音交互过程已经结束;
h)、IPS停止任何没有结束的业务过程,释放所申请的特殊资源和进程。
媒体播放作为SRMP的一项业务功能,媒体处理设备与业务控制节点的交互过程也符合上述框架流程的要求。SRMP软件针对每一种业务进一步提供了不同的处理进程,媒体播放功能也有相应的处理进程,以下结合图6予以说明:
1)、媒体处理设备接收业务控制节点的媒体文件播放命令;
2)、所述媒体播送系统对命令中指定媒体文件的使用频率进行统计,当使用频率低于门限时转到步骤“6)”,否则继续;
3)、检查媒体处理设备的媒体处理板中是否已经缓存了指定的媒体文件,如果是转到步骤“5)”,否则继续;
4)、媒体处理设备开始从媒体存储服务器下载指定的媒体文件,已经下载的文件内容保存在媒体处理板中;
5)、媒体处理设备对媒体处理板中的媒体内容进行格式转换处理,并向用户终端实时播送,直到播放过程结束。
6)、媒体处理设备以流媒体方式从服务器获取指定媒体内容,并实时向用户终端播送,直到播放过程结束。
步骤“5)”的执行不需要等待步骤“4)”中文件下载全部完成后才开始,步骤“6)”先检查内存缓冲区中是否已经缓存了指定媒体文件,如果是直接转到步骤“5)”,否则继续按照步骤“6)”进行处理。
步骤“2)”中对媒体文件使用频率的统计采用建立常用媒体文件排序表的方式实现,按照最近一段时间内媒体文件的使用频率进行排序,并确认排序表中前N个媒体文件为热门媒体文件,媒体处理设备以文件方式下载并缓存使用频率较高的热门媒体文件,而采用流媒体播送方式实时传送使用频率较低的其余媒体文件。
在步骤“4)”中,当媒体处理板没有足够的空间时,先把媒体处理板中原先保存的最长时间没有使用的媒体文件删除,直到指定媒体文件有足够的空间保存。
根据系统提供的媒体容量大小,媒体处理设备中的各媒体处理板按比例缓存不同或相同媒体文件。
2、媒体存储服务器软件
媒体存储服务器可以采用机架式服务器(如DL380)和磁盘阵列,彩铃应用中主要提供大容量的语音文件存储和传输功能。媒体存储服务器采用Linux操作系统,当媒体处理板采用文件存取方式进行放音时,操作系统提供了TFTP、NFS等文件传输协议,不需要开发服务器端的应用软件。但是,当媒体处理板采用RTP媒体流传输方式进行放音时,需要开发RTP媒体流的服务器端软件。
以下结合图7,描述媒体存储服务器软件的流程和功能:
1)、实时传输协议和实时传输控制协议(RTP/RTCP)处理:负责RTP/RTCP通道的建立、保持和释放等,并对接收或发送的RTP/RTCP消息进行处理。
2)、媒体文件存取和媒体流处理:当系统提供语音播放功能时,需要从磁盘阵列中取出指定的语音文件,并分析文件格式和语音类型,输出相应的媒体流给RTP/RTCP层。当系统提供语音录制功能时,需要从RTP/RTCP层接收媒体流,并按照预定的语音类型和文件格式,把媒体流存储到指定的媒体文件中。
3)、RTP/RTCP并发服务和控制接口:与IPS主控建立内部通信(可以采用内部通信协议),根据IPS主控处理机发送的命令消息,控制RTP/RTCP通道的建立、保持和释放等,提供大容量的RTP/RTCP并发服务。
3、以下结合图3、4描述两种播送方式的具体流程控制:
A、流媒体方式的媒体播送流程,参照图3,
1)、媒体处理设备的主控板(MCU)收到来自交换业务节点(SSP)的呼叫起始地址消息(IAM),中继电路的逻辑编号为x;
2)、主控处理机(MCU)将IAM转发给业务控制节点(CN);
3)、业务控制节点(CN)响应呼叫,回送呼叫地址全消息(ACM)给主控处理机(MCU);
4)、主控处理机(MCU)将ACM转发给交换业务节点(SSP);
5)、业务控制节点(CN)向媒体处理设备申请媒体资源,发送资源分配请求消息给主控处理机(MCU);
6)、主控处理机(MCU)选择一个空闲的媒体资源,然后给业务控制节点(CN)发送资源分配证实消息,媒体资源的逻辑编号为y。如果资源分配请求消息中携带选择子,系统保证选择子相同的情况下分配同一块媒体处理板上的空闲资源,这样能够让需要相同媒体内容的业务尽量在同一块媒体处理板上,从而不同的媒体处理板上能够存储不同的媒体文件。根据系统提供的媒体容量大小,对选择子和分配策略进行控制,媒体处理设备中的各媒体处理板可以按比例缓存不同或相同媒体文件;
7)、业务控制节点(CN)请求媒体处理设备把中继x和媒体资源y连接起来,发送连接请求消息(Connect Req)给主控处理机(MCU);
8)、主控处理机(MCU)指示媒体处理设备的交换网络完成电路连接后,发送连接证实消息(Connect Cnf)给业务控制节点(CN);
9)、业务控制节点(CN)接通呼叫,回送呼叫应答消息(ANM)给主控处理机(MCU);
10)、主控处理机(MCU)将ANM转发给交换业务节点(SSP);
11)、业务控制节点(CN)发送播音请求消息给主控处理机(MCU),主控处理机(MCU)对媒体文件使用频率进行统计,根据消息参数和常用媒体文件排序表,确认播放的不是热门媒体文件,而且媒体处理板的内存缓冲区中没有缓存指定媒体文件,采用流媒体方式播放指定的语音文件;
12)、主控处理机(MCU)发送RTP通道建立命令消息,指示媒体处理板(MFIP)为媒体资源y建立流媒体下载通道;
13)、媒体处理板(MFIP)为媒体资源y建立流媒体下载通道后,向主控处理机(MCU)回送RTP通道建立证实消息;
14)、主控处理机(MCU)发送RTP语音下载请求消息,指示媒体存储服务器(VRS)为媒体资源y提供指定语音文件的流媒体下载服务;
15)、媒体存储服务器(VRS)启动流媒体下载服务,并向主控处理机(MCU)回送RTP语音下载证实消息;
16)、主控处理机(MCU)发送RTP通道激活命令消息,指示媒体处理板(MFIP)激活流媒体下载,并通过中继电路向用户终端播送语音;
17)、媒体处理板(MFIP)向主控处理机(MCU)回送RTP通道激活证实消息;
18)、媒体存储服务器(VRS)向媒体处理板(MFIP)持续提供流媒体下载;
19)、媒体处理板(MFIP)通过中继电路持续向用户终端播送语音;
20)、媒体处理设备的主控处理机(MCU)收到来自交换业务节点(SSP)的呼叫释放消息(REL),指示中继电路x上的呼叫释放;
21)、主控处理机(MCU)将REL转发给业务控制节点(CN);
22)、业务控制节点(CN)发送播音停止消息给主控处理机(MCU),要求主控处理机(MCU)停止媒体资源y的语音播放;
23)、主控处理机(MCU)发送RTP语音停止消息,指示媒体存储服务器(VRS)停止为媒体资源y提供流媒体下载服务;
24)、主控处理机(MCU)发送RTP通道删除命令消息,指示媒体处理板(MFIP)删除媒体资源y的流媒体下载通道;
25)、媒体存储服务器(VRS)停止流媒体下载服务,并向主控处理机(MCU)回送RTP语音停止证实消息;
26)、媒体处理板(MFIP)删除媒体资源y的流媒体下载通道后,向主控处理机(MCU)回送RTP通道删除证实消息;
27)、主控处理机(MCU)向业务控制节点(CN)发送播音结束消息;
28)、业务控制节点(CN)发送资源释放请求消息给主控处理机(MCU),要求主控板(MCU)释放媒体资源y;
29)、主控处理机(MCU)释放媒体资源y,然后给业务控制节点(CN)发送资源释放证实消息。
30)、业务控制节点(CN)完成呼叫释放,回送呼叫释放完成消息(RLC)给主控处理机(MCU);
31)、主控处理机(MCU)将RLC转发给交换业务节点(SSP);
B、文件下载方式的媒体播送流程,参照图4。
1)、媒体处理设备的主控处理机(MCU)收到来自交换业务节点(SSP)的呼叫起始地址消息(IAM),中继电路的逻辑编号为x;
2)、主控处理机(MCU)将IAM转发给业务控制节点(CN);
3)、业务控制节点(CN)响应呼叫,回送呼叫地址全消息(ACM)给主控处理机(MCU);
4)、主控处理机(MCU)将ACM转发给交换业务节点(SSP);
5)、业务控制节点(CN)向媒体处理设备申请媒体资源,发送资源分配请求消息给主控处理机(MCU);
6)、主控处理机(MCU)选择一个空闲的媒体资源,然后给业务控制节点(CN)发送资源分配证实消息,媒体资源的逻辑编号为y。如果资源分配请求消息中携带选择子,系统保证选择子相同的情况下分配同一块媒体处理板上的空闲资源,这样能够让需要相同媒体内容的业务尽量在同一块媒体处理板上,从而不同的媒体处理板上能够存储不同的媒体文件。根据系统提供的媒体容量大小,对选择子和分配策略进行控制,媒体处理设备中的各媒体处理板可以按比例缓存不同或相同媒体文件;
7)、业务控制节点(CN)请求媒体处理设备把中继x和媒体资源y连接起来,发送连接请求消息(Connect Req)给主控处理机(MCU);
8)、主控处理机(MCU)指示媒体处理设备的交换网络完成电路连接后,发送连接证实消息(Connect Cnf)给业务控制节点(CN);
9)、业务控制节点(CN)接通呼叫,回送呼叫应答消息(ANM)给主控处理机(MCU);
10)、主控处理机(MCU)将ANM转发给交换业务节点(SSP);
11)、业务控制节点(CN)发送播音请求消息给主控处理机(MCU),主控处理机(MCU)对媒体文件使用频率进行统计,根据消息参数和常用媒体文件排序表,当确认播放的是热门媒体文件,或确认播放的不是热门媒体文件,但是检查媒体处理板的内存缓冲区中已经缓存指定媒体文件,采用文件下载方式播放指定的语音文件;
12)、主控处理机(MCU)发送媒体文件播放命令消息,指示媒体处理板(MFIP)为媒体资源y进行媒体文件播送;
13)、媒体存储服务器(VRS)为媒体处理板(MFIP)提供文件下载服务,媒体处理板(MFIP)在短时间内里下载完整个媒体文件,并保存在二级缓存中,如果内存缓冲区没有足够的空间时,需要把内存缓冲区中原先保存的最长时间没有使用的媒体文件淘汰,直到指定媒体文件有足够的空间保存;
14)、媒体处理板(MFIP)读取二级缓存中的媒体文件内容,通过中继电路持续向用户终端播送语音,播送语音的执行不需要等待上一步骤中的文件下载全部完成后才开始;
15)、媒体处理设备的主控处理机(MCU)收到来自交换业务节点(SSP)的呼叫释放消息(REL),指示中继电路x上的呼叫释放;
16)、主控处理机(MCU)将REL转发给业务控制节点(CN);
17)、业务控制节点(CN)发送播音停止消息给主控处理机(MCU),要求主控处理机(MCU)停止媒体资源y的语音播放;
18)、主控处理机(MCU)发送媒体播放停止命令消息,指示媒体处理板(MFIP)停止媒体播放;
19)、媒体处理板(MFIP)停止媒体资源y的播放后,向主控处理机(MCU)回送媒体播放停止证实消息;
20)、主控处理机(MCU)向业务控制节点(CN)发送播音结束消息;
21)、业务控制节点(CN)发送资源释放请求消息给主控处理机(MCU),要求主控处理机(MCU)释放媒体资源y;
22)、主控处理机(MCU)释放媒体资源y,然后给业务控制节点(CN)发送资源释放证实消息。
23)、业务控制节点(CN)完成呼叫释放,回送呼叫释放完成消息(RLC)给主控处理机(MCU);
24)、主控处理机(MCU)将RLC转发给交换业务节点(SSP);
四、彩铃业务系统的组网方案
本发明由于二级缓存和流媒体技术的使用,大大降低了服务器负荷,可采用成本较低的服务器进行分布式处理。媒体处理设备与媒体存储服务器之间组网连接如图8所示,设有多台媒体存储服务器和多个媒体处理设备组成,媒体存储和业务控制管理采用分布式结构,上述媒体存储服务器和媒体处理设备之间通过双平面的局域网进行通信连接。媒体处理设备采用多模块分布式处理结构,提供设备冗余和业务负荷分担的能力,媒体资源的播放大部分从前端媒体处理设备的MFIP内存中提取,只有少数呼叫需要到媒体存储服务器读取。
如果不使用二级缓存和流媒体技术,播放的所有媒体文件均按照呼叫实时从媒体存储服务器存取,就要求媒体存储管理采用高性能的集群服务器,这种技术方案的主要问题是:
a)、对集群Cluster服务器要求较高,为了满足容量要求,需要使用高性能的集群(Cluster)服务器,包括内存容量大(2~4GB以上),硬盘读写速度要求非常快,双网口1000M速度,CPU处理速度高(多CPU)。在以上几个方面易形成瓶颈,系统总体容量的瓶颈在媒体存储服务器上。
b)、在业务和市场初期,由于对业务控制以及媒体存储服务器起点较高,启动成本较高,不便于商业谈判和竞争。
本发明对服务器要求较低,在系统容量上不会有瓶颈,不需要采用昂贵的集群服务器。综合考虑各种因素,在性能成本等各方面优势非常明显。
Claims (8)
1.一种应用于移动电话或固定电话交换系统的大容量媒体播送方法,其特征在于它以如下所述的媒体播送系统为其媒体播送系统,所述媒体播送系统包括以下组成部分:
具备数据存储、处理机和网络功能的媒体存储服务器,所述媒体存储服务器能够为媒体处理设备同时提供文件下载和流媒体实时传送两种媒体传输服务;
媒体处理设备,媒体处理设备能够以文件下载和流媒体实时传送两种方式从媒体存储服务器获取预先存储的媒体内容;所述媒体处理设备置有媒体处理板、主控处理机、承载接口板;所述媒体处理板具备预存或缓存媒体文件的内存文件系统,并能利用内存文件系统进行媒体播送;所述媒体处理板设有媒体格式的转换和处理装置,所述媒体格式的转换和处理装置将从媒体存储服务器取得的媒体内容按照媒体需要传送的格式进行处理;所述主控处理机与媒体处理板之间通过内部数据链路通信,并通过以太网向业务控制节点提供控制管理接口;所述承载接口板对外提供TDM电路接口和/或IP媒体承载接口,通过公共通信网络向用户终端播送各种媒体内容;
所述方法包括以下主要步骤:
1)、媒体处理设备接收业务控制节点的媒体文件播放命令;
2)、所述媒体播送系统对命令中指定媒体文件的使用频率进行统计,当使用频率低于门限时转到步骤“6)”,否则继续;
3)、检查媒体处理设备的媒体处理板中是否已经缓存了指定的媒体文件,如果是转到步骤“5)”,否则继续;
4)、媒体处理设备开始从媒体存储服务器下载指定的媒体文件,已经下载的文件内容保存在媒体处理板中;
5)、媒体处理设备对媒体处理板中的媒体内容进行格式转换处理,并向用户终端实时播送,直到播放过程结束;
6)、媒体处理设备以流媒体方式从媒体存储服务器获取指定媒体内容,并实时向用户终端播送,直到播放过程结束。
2.如权利要求1所述的一种应用于移动电话或固定电话交换系统的大容量媒体播送方法,其特征在于所述媒体播送系统设有多台媒体存储服务器和多个媒体处理设备,上述媒体存储服务器和媒体处理设备之间通过双平面的局域网进行通信连接。
3.如权利要求1所述的一种应用于移动电话或固定电话交换系统的大容量媒体播送方法,其特征在于媒体处理设备采用多模块分布式处理结构,提供设备冗余和业务负荷分担的能力。
4.如权利要求1所述的一种应用于移动电话或固定电话交换系统的大容量媒体播送方法,其特征在于步骤“5)”的执行不需要等待步骤“4)”中文件下载全部完成后才开始。
5.如权利要求1所述的一种应用于移动电话或固定电话交换系统的大容量媒体播送方法,其特征在于步骤“6)”先检查内存缓冲区中是否已经缓存了指定媒体文件,如果是直接转到步骤“5)”,否则继续按照步骤“6)”进行处理。
6.如权利要求1所述的一种应用于移动电话或固定电话交换系统的大容量媒体播送方法,其特征在于步骤“2)”中对媒体文件使用频率的统计采用建立常用媒体文件排序表的方式实现,按照最近一段时间内媒体文件的使用频率进行排序,并确认排序表中前N个媒体文件为热门媒体文件,媒体处理设备以文件方式下载并缓存使用频率较高的热门媒体文件,而采用流媒体播送方式实时传送使用频率较低的其余媒体文件。
7.如权利要求1所述的一种应用于移动电话或固定电话交换系统的大容量媒体播送方法,其特征在于在步骤“4)”中,当媒体处理板没有足够的空间时,先把媒体处理板中原先保存的最长时间没有使用的媒体文件删除,直到指定媒体文件有足够的空间保存。
8.如权利要求1所述的一种应用于移动电话或固定电话交换系统的大容量媒体播送方法,其特征在于根据系统提供的媒体容量大小,媒体处理设备中的各媒体处理板按比例缓存不同或相同媒体文件。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101566914A CN101163172B (zh) | 2007-11-12 | 2007-11-12 | 一种应用于移动电话或固定电话交换系统的大容量媒体播送系统及大容量媒体播送方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101566914A CN101163172B (zh) | 2007-11-12 | 2007-11-12 | 一种应用于移动电话或固定电话交换系统的大容量媒体播送系统及大容量媒体播送方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101163172A CN101163172A (zh) | 2008-04-16 |
CN101163172B true CN101163172B (zh) | 2010-11-10 |
Family
ID=39297992
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101566914A Active CN101163172B (zh) | 2007-11-12 | 2007-11-12 | 一种应用于移动电话或固定电话交换系统的大容量媒体播送系统及大容量媒体播送方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101163172B (zh) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101415027B (zh) * | 2008-11-25 | 2012-05-30 | 哈尔滨工业大学 | 基于hdlc协议的通讯模块及数据实时转发存储控制方法 |
CN102957972B (zh) * | 2011-08-22 | 2015-07-01 | 深圳市云帆世纪科技有限公司 | 一种视频点播方法及其系统 |
CN103957221A (zh) * | 2014-05-20 | 2014-07-30 | 艾诺通信系统(苏州)有限责任公司 | 一种集群并发发送网络媒体流的方法 |
CN105138279A (zh) * | 2015-08-03 | 2015-12-09 | 深圳市美贝壳科技有限公司 | 家用设备数据的智能管理方法 |
CN112181930B (zh) * | 2020-09-29 | 2023-04-25 | 杭州迪普科技股份有限公司 | 虚拟交换矩阵的文件管理方法及装置 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1595905A (zh) * | 2004-07-04 | 2005-03-16 | 华中科技大学 | 基于集群的流媒体缓存代理服务器系统 |
CN1610403A (zh) * | 2004-11-16 | 2005-04-27 | 南京大学 | 基于协作缓存实现视频点播系统的方法 |
-
2007
- 2007-11-12 CN CN2007101566914A patent/CN101163172B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1595905A (zh) * | 2004-07-04 | 2005-03-16 | 华中科技大学 | 基于集群的流媒体缓存代理服务器系统 |
CN1610403A (zh) * | 2004-11-16 | 2005-04-27 | 南京大学 | 基于协作缓存实现视频点播系统的方法 |
Also Published As
Publication number | Publication date |
---|---|
CN101163172A (zh) | 2008-04-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101150419B (zh) | 一种新一代呼叫中心系统及自动业务实现方法 | |
US7899878B2 (en) | Recording trace messages of processes of a network component | |
US8014507B2 (en) | Providing features to a subscriber in a telecommunications network | |
CN108933871B (zh) | 呼叫中心呼入话务路由方法、装置及系统 | |
CN101163172B (zh) | 一种应用于移动电话或固定电话交换系统的大容量媒体播送系统及大容量媒体播送方法 | |
CN101217389B (zh) | 音频会议桥接级联实现方法及音频会议桥接级联系统 | |
CN101277199A (zh) | 自动部署嵌入式ip-pbx及其通信方法 | |
CN100393037C (zh) | 承载和控制相分离的通信网络中多方会议业务的实现方法 | |
CN100484014C (zh) | 智能网中的分布式集群业务管理系统及业务管理方法 | |
US7539288B2 (en) | Apparatus and method for simulating a trunk gateway in a telecommunications switch test system | |
CN101222669B (zh) | 在通信系统中提供融合媒体资源的系统和方法 | |
CN203057286U (zh) | 基于全ip软交换技术的业务综合接入控制器 | |
CN1229544A (zh) | 无线和有线接入pacs无线技术中的综合电信系统结构 | |
CN100463404C (zh) | 利用媒体资源服务器实现电话会议业务的方法 | |
CN107508802A (zh) | 多方通系统 | |
CN100576863C (zh) | 动态资源管理方法及其媒体网关和媒体网关控制器 | |
WO2010043138A1 (zh) | 一种智能网业务库存取海量数据的系统、装置及方法 | |
EP2621154A1 (en) | System and method for achieving call traffic wholesale based on soft switch | |
WO2007048292A1 (en) | Method for executing flow in the integrated telecommunication platform and apparatus thereof | |
CN115967742A (zh) | 一种市域铁路调度通信方法、系统及集群 | |
CN100373901C (zh) | 用于媒体网关的端口动态绑定模块及其动态绑定方法 | |
CN100589435C (zh) | 一种软交换中控制媒体资源播放的装置及其方法 | |
CN1190941C (zh) | 一种融合包交换方式和电路交换方式的呼叫中心 | |
CN1332531C (zh) | 一种动态调整业务管理点系统服务性能的方法 | |
CN1889610B (zh) | 大容量分布式信令处理设备及其方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |