国产SBC,会话边界控制器,中继网关,语音网关,多媒体交换机,融合通信平台提供商
SBC中的DTMF以及优化
更新时间:2023-03-08

前言
毅航互联SBC具有非常多的功能来连接和适配能力存在差异的两端。在呼叫中心/客服对接场景,适配线路接入和客服软交换平台的DTMF能力差异非常关键:不单纯IVR菜单由DTMF按键驱动,一些业务场景也需要可靠的DTMF按键(比如:输入密码、语音验证等)。
国内的软交换核心大都基于开源的freeswitch实现,在freeswitch中,对DTMF按键的检测采用识别RFC 2833/4733规范的DTMF传输包来完成的。因此,需要SBC将接入线路的各种DTMF传输模式转换为RFC 2833/4733规范后再传递给软交换。
SBC通过SIP信令和前后端交换DTMF传输的能力,协调好DTMF的传输。比如将SIP INFO传递的DTMF转换成RFC 2833/4733 DTMF,或者将带内语音传输的DTMF转换为RFC 2833/4733 DTMF。
但是,现网经过各种各样设备的传输和转换,现实和理想有非常大的差异:比如信令表示为RFC 2833/4733 DTMF,实际上采用带内语音传递;甚至两种传输同时存在,导致还原出现相互干扰。带内DTMF语音存在畸变和断裂,导致还原失败或者多出DTMF等等。
毅航互联在项目中遇到过输入手机号码和身份证的业务场景,这些场景对DTMF输入的准确性要求极高(想想少一个或者多一个DTMF数字的场景,就是想一想都可怕!!!),毅航互联SBC针对上述问题提供一些优化手段,尽量完好的适配各种场景,保证DTMF准确传输到软交换。

注:freeswitch可以支持针对带内语音的DTMF检测。此时需要开启spandsp的检测功能,这会涉及到代码层面的配置和修改,以及CPU开销。如果采用类似于G.729这类高压缩率的编解码,CPU开销会非常大。


1 DTMF困境
对于普通的通话甚至于客户和客服的通话,因为人可以通过对话识别意图,DTMF是否完整,的确是无关紧要。但是,大量的基于DTMF的IVR业务系统却至关重要,它是人和机器的交互基础。电话系统是为人与人交互设计的,对人和机器的交互并不友好(对比通过web访问www.10086.cn和打电话到10086就完全感受到了)。DTMF本质上就是一串连续的语音流,在电信网络传输时,可能经过了很多设备的处理和转换,最终通过类似毅航互联SBC来到软交换,此时,可能已经出现畸变、误解。为了便于讨论,我们将基于PRI/SS7这类基于中继传输的接入归类到带内语音。

1.1鸡同鸭讲
如下图,软交换一般只接受RFC 2833/4733 DTMF,而接入前端有各种各样的模式,如果直接转给软交换,将导致极大的困惑,因此,必须在SBC统一为一种语言。

1.1.1 PRI/SS7中继接入
看到PRI/SS7中继,很容易联想到一致性/可靠性,高质量的语音和DTMF,但这是10几年前的场景了。随着运营商网络的全光化、IP化、5G/IMS等,对接的中继实际上也是在运营商某个机柜通过中继网关将SIP/VoIP转换成中继接入送出,同样面临复杂VoIP网络带来的各种DTMF问题。
毅航互联SBC将PRI/SS7信令根据规范转换为SIP信令,并通过SDP和后端协商DTMF的承载方式(软交换一般采用RFC 2833)。在媒体面,将中继电路传递的语音流,通过VoIP芯片的DSP功能,识别出DTMF的开始和结束,并转换为RFC 2833包传输给后端软交换,达到翻译的目的。

1.1.2 SIP带内语音
带内语音传递DTMF是用协商的编码将DTMF编码为语音包,通过RTP语音包传递。SBC会匹配两端DTMF能力的差异,并通过SIP信令传递的SDP中标识出来。
同样,VoIP的DSP功能会将前端的语音包转换为连续的语音流,然后再识别出DTMF的开始和结束,转换为RFC 2833包传输给后端软交换,达到翻译的目的。

1.1.3 SIP RFC 2833/4733 DTMF
看起来前端和后端操相同的语言,SBC直接转发即可。但仔细分析,还是会存在很多的差异,这种差异可能比类比的方言口音更突出。
前端接入可能采用AMR WB(如VoLTE接入)或者OPUS(如WebRTC),而后端大部分采用G.711 Alaw,两者存在比较大的采样率差异,直接转发会产生大的问题。这同样也需要由SBC进行信令和媒体的翻译,达到适配目的。
SBC的SIP信令的SDP会反映采样率的不同来适配这种差异。VoIP的DSP功能将接收到的DTMF转换为语音流,然后用另外一个资源识别出DTMT的开始和结束,转换为后端软交换支持的RFC 2833包传输,达到翻译的目的。

注:
1、AMR WB是16000Hz的采样率,因此在SDP中用telephone-event/16000表示此宽带DTMF。
2、OPUS一般采用48000Hz的采样率,因此在SDP中用telephone-event/48000表示此超宽带DTMF。
3、像常见的G.711 alaw/G.729等均为窄带编码,采样率为8000Hz,因此在SDP中用telephone-event/8000表示。

1.1.4 SIP INFO
协商DTMF采用SIP INFO传递暂时未找到相应的RFC定义,在cisco的系统中,可以在SIP头域中看到:Allow-Events: telephone-event 来暗示采用SIP INFO传输DTMF。
在与5G/VoLTE对接时,可能遇到这种情况。此时,SBC需要在信令中与后端协商为RFC 2833的DTMF,并且将INFO中表示的DTMF用VoIP DSP转换为DTMF对应的tone音,然后由另外的VoIP DSP资源识别出DTMT的开始和结束,转换为后端软交换支持的RFC 2833包传输,达到翻译的目的。

1.2语音质量
1.2.1双模
在某些情况下,会出现RFC 2833和带内DTMF同时送的情况,可能会导致VoIP DSP通道恢复DTMF出现问题,从而影响对DTMF的识别。

1.2.2信令和媒体不一致
在某些情况下,可能出现信令和实际媒体不一致的情况:比如信令协商为RFC 2833,而实际上却采用带内或者SIP INFO传递DTMF。或者相反,协商为带内,传递的DTMF为SIP INFO。

1.2.3短时畸变
这种常见于带内和中继接入的情况,通过抓包还原DTMF语音时,可以明显看到波形中间插入了几ms或者十几ms的畸变波形,如果不做一些处理,会导致识别不了或者识别成多个DTMF。

1.2.4短时断裂
此种情况和“短时畸变”差不多,只是在DTMF完整的波形中发现有几ms或者十几ms的静音。同样的,如果不做一些特别的处理,也会导致识别不了或者设备成多个DTMF。

1.2.5 DTMF包end标志丢失
在freeswitch中,对DTMF的识别非常依赖RFC 2833 telephone-event的end包(也就是收到end包才触发事件),这也是直接转发前端的包会导致不可靠的一个原因。
由于毅航SBC是采用另外一个VoIP DSP资源对接后端的软交换,这样可以保证在DSP识别到DTMF结束后产生end包。

2 SBC优化方案
毅航互联SBC会在信令和媒体两个层面做一些优化,尽量匹配接入和软交换在DTMF层面的差异,在后端准确产生DTMF事件。

2.1信令的DTMF自适应
在SBC上,提供固定和自适应的多种模式来应对接入的差异。如下图:

固定模式表示参数是固定的,用于强制按此模式工作。而适应模式则会根据对端的回应或者请求消息中的模式进行转换,达到自适应的目的。因此,针对接入部分,可以采用适应模式,而针对软交换,可以采用固定模式。由于SIP信令的灵活性太大,接入的设备差异太多,即使都是RFC 2833,DTMF传递采用的payload值也许都是千差万别,SBC必须根据对方的值来做调整,保证正确收到对方的DTMF数据。有些接入点通过SIP Proxy接入,远端设备可能各种模式都有,此时也需要采用适应模式,根据远端的能力来调整本端的参数。

2.2 SBC媒体处理机制
毅航互联SBC分别用不同的VoIP DSP资源对接接入和软交换,中间通过硬交换连接起来。这样可以保证两端独立配置和变化,分别适应不同的场景。
如下图:
而每一个资源都有如下图的能力(功能示意):
对于IP接入,DTMF的处理在接入对应的VoIP通道进行,也就是上图的 “VoIP DSP资源1”。
对于中继接入,DTMF的处理在软交换对应的VoIP通道进行,也就是上图的 “VoIP DSP资源2”。

2.3媒体的DTMF自适应
此能力为针对IP接入的情况。

为了规避信令和DTMF的不一致,特别是双流现象,在媒体控制程序上回进行特别处理:同时监视带内DTMF和RFC 2833语音包。当先收到RFC 2833 DTMF语音包,就自动启动带内DTMF消除功能,避免双流导致DTMF还原的相互影响。当先从带内语音中检测到DTMF,将自动屏蔽RFC 2833 DTMF功能,同样避免双流导致DTMF还原的相互影响。这样就不管信令和DTMF媒体协商是否一致,还是送双流,都可以可靠的还原DTMF。
注:如果信令协商DTMF能力为带内,此时不知道RFC 2833 DTMF的payload值,采用最常见的缺省值101,可能和现场并不一致,需要现场做一些调整。

2.4语音质量
针对DTMF的语音质量问题主要发生在中继或者带内情况下,现象为对DTMF语音波形的干扰(比如:短时的畸变和断裂),导致DSP采用缺省参数时,对DTMF的识别产生问题。干扰可能发生在DTMF波形的任何地方,导致识别的结果会有所不同。
比如:前端干扰,可能会导致DTMF识别不出(DTMF识别存在规范,对波形的持续时间有要求)。中间干扰,可能导致重复识别。

2.4.1前端干扰
CCITT或者国标对DTMF的持续时长有规定(一般不低于45ms),如果在前端产生干扰,可能导致DTMF时长低于标准,从而导致DTMF识别失败,在软交换发现丢失了DTMF按键。
毅航SBC DSP采用优化算法,可以大大缩短识别时间,大概在15ms~20ms的时间周期内识别出DTMF,这样就可以很好的应对前端干扰的情况。
前端干扰的例子:

2.4.2中间干扰
由于中间干扰的存在,可能会在软交换表现出重复识别的问题。此时,可以调整信号中断时长,用于避开中间干扰的问题。
中间干扰的例子:




返回