MRFC概念
ETSI ES 283 031, 3GPP 23.333 and 29.333中规定了MRFC与MRFP之间的H.248协议功能,基于IMS域。
媒体资源功能(MRF, Multimedia Resource Function)设备,是媒体资源的控制和处理设备,它为应用服务器AS(或S-CSCF)的业务流程服务。AS可以通过控制媒体资源功能(MRF)设备实现放音、收号、会议、IVR、Transcoding 等业务功能。
媒体资源功能(MRF)由MRFC(Multimedia Resource Function Controller)和MRFP(Multimedia Resource Function Processor)两部分组成,如下图所示。IMS网络通过MRFC和MRFP完成对媒体资源的控制。
3GPP\IETF\W3C中对于多媒体应用,定义了多种媒体资源控制协议:RFC4240(NetAnn协议),RFC5022(MSCML协议),RFC5707(MSML协议) ,VoiceXML,CCXML,SCXML,Media Control Channel Framework,它们大部分是基于SIP的。
ISC接口:是AS与S-CSCF之间的SIP接口。当AS与MRFC通过S-CSCF为中介进行通信时,这个接口上可以执行上述媒体控制协议。
Mr接口:是S-CSCF与MRFC之间的SIP接口。这个接口上可以执行上述媒体控制协议。
Mr’接口:是AS与MRFC之间的SIP接口,用于AS与MRFC之间直接通信。这个接口上可以执行上述媒体控制协议。
Cr接口:AS与MRFC之间的非SIP接口,用于资源(scripts,announcement files and other resources)交换的接口,包括HTTP(s)接口、TCP\SCTP接口。
Mp接口:是MRFC与MRFP间的H.248或SIP接口(如MSML)。MRFC用它来控制MRFP完成媒体操作功能。
Mb接口:MRFP与媒体面设备\终端之间的RTP\RTCP接口。
SDP介绍
MRFC标准列表
H.248标准
ITU-T H.248系列协议,RFC 3525 GATEWAY CONTROL PROTOCOL
ETSI ES 283 031:H.248 Profile for controlling Multimedia Resource Function Processors(MRFP) in the IP Multimedia System(IMS)
3GPP标准
3GPP TS 23.333 Multimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp interface: Procedures Descriptions
3GPP TS 29.333 Multimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp Interface
3GPP TS 23.228 IP Multimedia Subsystem (IMS);Stage 2
3GPP TS 24.229 Session Initiation Protocol (SIP) and Session Description Protocol (SDP);Stage 3
SIP RFC(放音流程控制)
RFC 4240 Basic Network Media Services with SIP
RFC 5022 Media Server Control Markup Language (MSCML)
RFC 5707 Media Server Markup Language (MSML)
RFC 5552 SIP Interface to VoiceXML Media Services
RFC6230 Media Control Channel Framework
RFC6231 An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework
draft-ietf-mediactrl-mixer-control-package-14.txt
draft-ietf-mediactrl-sip-control-framework-03 [146] and draft-ietf-mediactrl-ivr-control-package [147]. ?\\
W3C
W3C VoiceXML 2.0
W3C VoiceXML 2.1
W3C CCXML1.0
W3C SCXML
呼叫中心
MRFC功能分类
放音(audio、video、多媒体)
放音在PSTN、PLMN中属于基本功能,传统网络中的终端属于傻终端,只能显示简单的字符、号码,复杂信息只能通过音频媒体来传递。多媒体放音在后期引入,作为增值型业务,比如彩铃、彩像。
大多数电信运营商对于各种业务场景中放什么音、如何放音均作了详细的规定,
放音按业务功能可分为:
1,回铃音、彩铃音:基本呼叫流程中,在被叫终端振铃期间,主叫用户需要听到回铃音或彩铃音,以理解被叫终端当前的状态是振铃状态。而当被叫摘机后会儿停止播放。传统网络中由被叫侧交换机播放,Voip网络中也允许由主叫终端来播放。
彩像音是主叫侧提供给被叫侧的业务,用于增强主叫号码显示业务的体验。
2,异常失败音:比如被叫终端正处于忙、被叫无应答、被叫拒绝接受呼叫等情况下,网络侧会给主叫终端放特殊失败音。大多是一段信号音。
3,提示音:用户可以在终端上使用特别的接入码来要求激活某个业务,当激活成功或失败时,用户均会听到一段提示音。比如话机激活某业务,或在话务台类业务(如呼叫中心)中经常会被要求输入号码。
4,业务音:如呼叫保持业务执行时会给另一方播放保持音、免打扰音等。
这些音大多是由AS控制MRFC/MRFP进行播放,也可能由终端自己播放。这些音可以在通话前播放,也可能在通话中播放。
音在MRFP上以两种形式存在: 1,文件形式的wav格式音、MP3音。2,按特定频率播放(即下面的固定音)。
所以还可按放音的内容分为:
1,固定音(或称信号音):以规定的频率与断续比播放、且代表规定的含义的数字语音称为固定音或信号音,如拨号音(dial tone)、忙音(Busy Tone)、回铃音(Ringing Tone)、拥塞音(Congestion Tone)等。
举例如下:前者表示频率,后者表示每段音持续、中断的时间。
在中国,信号音含义及结构如下
2,可变音:每次播放时内容均发生动态变化的业务音称为可变通知音,它是由MRFP根据其内部的语法分析程序将电话号码、整数、时间、日期、星期、价格等语音元素按照一定的规则组合而成的一条不固定的(即可变的)、代表一定意义的数字语音。常见的可变通知音如报时音、追查恶意呼叫音、IVR等。
比如报时音:当前时间是2011年1月1日7点29分。
3,固定业务音:每次播放时内容均保持不变的业务音称为固定业务音,大部分业务音均属于固定业务音。比如被叫设置了呼入限制业务时,主叫会听到一段音:您没有权限完成这次呼叫。或者大部分彩铃音也属于固定业务音。
MRFC通过Mp接口控制MRFP实现音频和视频的播放控制功能,包括开始和停止音频和视频的播放,播放时长,播放次数,要求播放结束通知,要求DTMF探测功能等。
三种音在H.248接口中的表示方法见 H.248协议有关文章中的介绍。
放音控制的三种基本协议:
Basic Network Media Services, RFC 4240
AS发一个sip invite给MRFC,携带了一个要播放的音URL。它可能是一个MRFP本地文件或HTTP URL(存放在媒体仓库中)。
Media Server Markup Language (MSML), RFC 5707
AS发一个sip invite给MRFC,指示使用MSML。后续SIP Info方法包括了MSML消息体,它包括了要播放的URL。它可能是一个MRFP本地文件或HTTP URL(存放在媒体仓库中)。
Media Server Control Markup Language (MSCML) ,RFC 5022
AS发一个sip invite给MRFC,指示使用MSCML。后续SIP Info方法包括了MSML消息体,它包括了要播放的URL。它可能是一个MRFP本地文件或HTTP URL(存放在媒体仓库中)。
DTMF收号
允许 用户把DTMF号码发送给MRFC/MRFP。
DTMF(Dual Tone Multi-Frequency,双音多频信号)号码指按键式话机上的0、1、2、*、#等按键后产生的对应数字号码,用户通过拨话机上的号码来发起呼叫。
在基于电路的PSTN网络中,DTMF信号使用特殊的电信号频率来表示(一个DTMF信号由两个频率的音频信号唯一表示),而在基于IP的IMS网络中,仍采用DTMF来称呼用户拨的号码。
在PSTN中,DTMF的用户侧信号是一种双音频的组合信号,由高频群 4 个频率中的一个频率和低频群4 个频率中的一个频率组成。两个4 中取1,共有 16 种组合,其组合情况如下表所示。
DTMF号码由高低两个音组成,如表1:
见《YDN 065-1997》
用户通过在话机上输入DTMF号码来发起通信,网络侧设备可以有两种办法得到被叫号码:
1, 终端能够识别出用户所拨的DTMF号码,将其转换为相应的数字,封装在信令中传送至网络侧设备。
2, 终端可以将该DTMF号码与其它语音信号一样封装成RTP包,作为媒体流发出。
对于DTMF号码,终端经常是根据呼叫所处的不同阶段采用不同的传送方法。若处于呼叫建立阶段,终端将号码封装在信令(invite\中传送给网络侧设备。若已处于通话状态,终端经常将用户所拨的号码与其它语音信号一样封装在RTP包中传送,即第2种方法。
第2种办法即收号(DTMF Collection),MRFC控制MRFP作为媒体流的接受方,MRFP具有从RTP流中检测DTMF号码的能力,且会通过MRFC传送给AS。AS可以根据号码进行路由等处理。在话务台、IVR等业务中会用到收号场景。
比如用户呼入运营商自助缴费系统后,会听到“请输入您的手机号码,按#号键结束输入”,此时用户输入手机号码,终端一般会以RTP包形式把用户输入信息传送给网络。
与语音信号相比,每一位DTMF号码对于业务执行都有重要意义,语音包的丢失或延时会降低语音质量,降低客户满意度,但DTMF号码传递错误则直接引起业务执行失败(比如上述的手机号码识别错误会引起缴费失败或识别成他人号码)。所以在信令面、媒体面中均特别考虑了DTMF信号的传递。
有2种DTMF收号方式(对MRFP能力有要求)
In-band DTMF
DTMF号码与语音信号在同一个RTP链接上传输。这种方式的缺点是接收端(MRFP)要完全重现DTMF号码存在困难。
RFC 2833 encoded in RTP
RFC 2833定义了专门用于携带DTMF号码、电话信号音和电话信令的RTP载荷格式(Payload Type)的RTP包,是推荐使用的编码方式。(depends on MRFP)
有多个业务需要收号功能(如:话务台、呼叫中心 等)。
MRFC能够控制MRFP进行DTMF检测,并要求MRFP通知检测到的DTMF信号.
overlap收号
PSTN中经常采用overlap(重叠发号)机制(见七号信令的IAM信令),部分SIP终端支持这种方式。这时:invite中携带的被叫号码不全,它只能够帮助呼叫触发到IMS核心网,核心网无法找到被叫用户,这时核心网返回18x响应,指示主叫侧通过Info发送后续号码过来,可能有多个info发来。直到号码收全,才会呼出真正的被叫用户。
在3GPP 24.229-920中提出了实现overlap的两种机制,multiple-invite方式与in-dialog方式。Multiple-invite方式会触发多次呼叫建立与选路过程,而且proxy还可能对invite产生fork,处理流程复杂、效率也比较低。多对话方式完全修改了现在SIP呼叫流程(现在只有涉及超过2方用户的呼叫才可能产生多对话方式)。
in-dialog方式是在dialog内通过Info方式收取后续号码的方式。
invite、refer、message、subscriber都可以使用overlap。
这种方式的收号与MRFP、媒体面无关。
会议混音
会议功能是一个常见媒体业务,也可能是其它媒体业务的一个子集。这个功能允许混音资源在多个会议应用、会议AS间共享。
用户能加入音频会议或多媒体会议。用户可以是SIP用户或PSTN/PLMN用户。
RFC 4240 可以支持简单的会议功能。而MSCML 、MSML、Voice XML、CCXML可以支持复杂的会议控制,其逻辑各有不同。
在INVITE消息中携带媒体SDP,完成媒体协商建立会话后,在会话内的INFO中携带的MSML脚本,指示会议逻辑操作(创建会议,加入会议,将一方退出会议,修改会议方属性等)。
参与会议的媒体端点可能是终端或网关端点,它们与MRFP之间收发媒体,包括了以下功能:
- 建立会议。MRFC能够控制MRFP为会议预留资源
- 加入会议,MRFC能够为用户建立资源以加入到现有会议
- 启动会议。每个媒体端点的媒体被分配给其它参与方的媒体端点。
- 媒体编解码转换。MRFC能够控制MRFP改变媒体属性, 如调整音视频编解码等(媒体端点间的媒体如果不兼容的话,需要转换,比如AMR转换为G.711)。
- 退出会议。MRFC能够释放退出会议的用户占用的资源。MRFC从会议中移除一个媒体端点,并终结有关的对话。
- 结束会议。MRFC从会议中移走最后一个媒体端点,释放会议资源,并终结最后一个对话。
媒体编码转换
编解码转换(Transcoding)可以提高接通率,它允许不同编解码类型的终端进行通信。
IMS网络要求具有转换媒体编解码能力,即建立呼叫时,主被叫如果没有公共的编解码方式时,在收到相应的失败消息后,需要 AS控制MRFC,由MRFP来进行编解码的转换,使得呼叫能继续下去,见3GPP TS 23.228 的Annex B中的B.2.3流程。
在IMS中,由于不同的终端或者网元采用的编解码格式不同,因此有可能呼叫双方媒体协商不成功,导致呼叫失败。例如固网SIP用户只支持G.711,而在CDMA2000网络中,移动终端只支持EVRC或AMR,这两个用户呼叫时由于支持的编解码格式不同,因此呼叫会失败。对此需要有网元来进行转换双方的媒体,即作为媒体中介。在3GPP TS23.228 的5.14.4以及Annex P中进行了定义,采用了MRFC/MRFP来完成transcoding。
没有transcoding时的媒体流如下图:
使用transcoding时的媒体流如下图:
H.248协议没有对transcoding规定特定的包。
交互式语音应答 IVR
IVR(Interactive Voice Response,互动式语音应答、交互式语音应答)功能使用户在拨打指定号码后,可以参与互动式的服务、通过多级菜单得到所需信息、接受人工话务员服务等。
IVR应用于多种业务系统中,比如运营商声讯台、语音点歌、语音聊天交友、银行呼叫中心等系统。
IVR提高呼叫服务的质量,节省业务提供方的人力费用。它允许业务系统(如呼叫中心)的大部分呼叫(如查询信息、改变信息等日常业务)实现自动化,减轻人工话务员的负担,使之仅处理确实需要人工处理的呼叫。
IVR系统使得用户可以随时随地进行访问,因此得到了用户的普遍认可。顾客通过按键或语音选择,向业务系统输入信息,自助得到多种服务。
IVR可以同时处理多路来话,加上遇忙自动处理流程,会极大降低顾客听到忙音或途中放弃的概率,提高顾客满意程度。
IVR支持根据用户的选择给出下一步提示直至操作成功,根据用户输入的不同信息播放对应的语音信息,即语音导航功能。
IVR支持放音过程中用户挂断、按键终止以及超时终止。
比如用户呼叫电话银行系统时,会听到 “请输入提示语言的种类,1为普通话,2为英语”、“请输入您的卡号,按#号键结束输入”等。用户会在多级菜单中输入信息进行选择,最终在电话银行中查询到自己需要的信息。用户听到的多种音都是由AS控制MRFC/MRFP进行播放的,起始放音的时间、结束放音的时间、放音次数、放音时长等重要参数都受AS的控制。用户输入的信息(如卡号)通过收号功能上报给AS。
可以使用CCXML定义复杂的IVR流程,放音操作由VXML来控制。
录音
允许运营商提供音频、视频的录音能力。由MRFC控制MRFP实现录音功能。
- MRFC能够控制MRFP开始进行录音
- MRFC能够控制MRFP在录音的过程中检测DTMF信号(指示收号,并从录音文件中去除DTMF音)。
- MRFC能够控制MRFP停止录音,并保留录制的文件:录音过程中用户挂断、按键终止以及超时终止,均可以结束录音。
- MRFC能够指示录音文件的格式[ 使用何种编码和文件格式(codec(s) and file format) ]及存储录音文件的URI
- MRFC能够指示MRFP的最大录音时间
- MRFC要求能够接收MRFP录音中发生的错误通知
有些AS的业务场景中要求对于通话音进行录音,比如语音信箱业务。录音的结果保存为音文件(用URI表示),则由AS控制MRFC进行录音操作。
其它
媒体面优先级
DTMF音传递
DTMF音在IMS中的传递方法:带内、带外、订阅,涉及的RFC标准。
DTMF定义:由高频音和低频音的两个正弦波合成表示数字按键(0~9 * # A B C D)。
VOIP中 检测DTMF通常有三种方法,sip info, inband, out band(rfc2833), 此外,在3gpp ims规范中 对dtmf的要求已经采用最新的rfc 4733 取代rfc 2833.
1. sip info
为带外检测方式,通过SIP信令通道传输DTMF数据。没有统一的实现标准,通过SIP INFO 方法 发送,包中的signal字段识别DTMF按键。注意当DTMF为“*”时不同的标准实现对应的signal=*或signal=10。SIP INFO的好处就是不影响RTP数据包的传输,但可能会造成不同步。
2.out band (rfc2833)
为带内检测方式,通过RTP传输,由特殊的rtp PayloadType即TeleponeEvent来标示RFC2833数据包。同一个DTMF按键通常会对应多个RTP包,这些RTP数据包的时间戳均相同,此可以作为识别同一个按键的判断依据,最后一包RTP数据包的end标志置1表示DTMF数据结束。另外,很多SIP UA 包括IAD都提供TeleponeEvent的设置功能如3CX Phone,Billion-IAD,ZTE-IAD等默认的TeleponeEvent都为101,但可以人为修改,这时要求在进行RFC2833 DTMF检测之前需事先获取SDP协商的TeleponeEvent参数。
3. in band
为带内检测方式,而且与普通的RTP语音包混在一起传送。在进行INBAND DTMF检测时唯一的办法就是提取RTP数据包进行频谱分析,经过频谱分析得到高频和低频的频率,然后查表得到对应的按键,进行频谱分析的算法一般为Goertzel,这种算法的实现也很简单,网上有很多可以下到,但建议采用定点算法,浮点算法效率很低。
从使用情况看,一般使用rfc283 即out band 方式,一般软交换服务器这几种方式都支持,所知道的asterisk 支持 sip info , rfc 2833及inband 方式,但是rfc2833 兼容性最好, 由于Ims 里对dtfm 这块采用了rfc 47233 而取代了rfc2833, 所以在ims客户端与软交换对接时可能存在兼容性问题。