前言
毅航互联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统一为一种语言。
看到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资源对接接入和软交换，中间通过硬交换连接起来。这样可以保证两端独立配置和变化，分别适应不同的场景。
如下图：
对于中继接入，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中间干扰
由于中间干扰的存在，可能会在软交换表现出重复识别的问题。此时，可以调整信号中断时长，用于避开中间干扰的问题。
中间干扰的例子：
返回
