手机打电话时将对方DTMF数字转为RFC2833发给局域网SIP坐席

手机打电话时将对方DTMF数字转为RFC2833发给局域网SIP坐席

--局域网SIP坐席呼叫

上一篇：手机打电话时由对方DTMF响应切换多级IVR语音菜单（完结）

下一篇：ADB识别手机系统弹授权框包含某段文字-并自动点击确定按钮

---

• 一、前言

在前期的《手机实时提取SIM卡打电话的信令声音》系列篇章中，我们针对局域网呼叫中心SIP坐席的用户，提供了将手机通话的语音拦截后转发到局域网坐席的能力。

此前的方案中，针对手机SIM卡通话过程中，对方手机拨号盘按键的DTMF数字；由于手机通话默认采用In-band的带内传输方式来传递DTMF，通话的语音数据中已经夹带了DTMF的按键内容。局域网SIP平台或呼叫中心，可以直接采用In-band的方式来直接解析出DTMF按键信息，并根据这个按键做出自己的业务响应和处理。

但是后来我们发现，SIP服务器中开启In-band的方式来解析语音中的内容本身也比较耗费时间，而且配置不同的网关线路识别DTMF按键分别识别【In-band、RFC2833、SIP-Info】这几个类型的解码方式本身也存在时延和准确性的差异，增加了SIP服务器配置的复杂度。（我们仍然建议局域网SIP平台或呼叫中心采用这种服务器解析的方式，因为服务器性能明显要比手机性能要好，准确率也高，而且可以根据原始语音数据挂载各种硬件DTMF解码器）

为了降低SIP服务器的部署复杂度，我们基于上一篇章《手机SIM卡打电话时识别对方按下的DTMF按键》中，在手机SDK中已经解析出DTMF数字的基础之上，针对局域网SIP平台的用户，在手机App的设置中增加了【转发解码出的DTMF】的功能：将蓝牙电话SDK中接收到的语音数据，通过软件解码器解析出“In-band的带内传输方式”来传递的DTMF按键值，经由SIP协议建立的RTP/RTCP通道，使用RFC2833，转发给SIP平台。

然而比较麻烦的问题是：

1、因为手机处理性能的原因，我们并没有抹去声音数据中In-band传输的DTMF按键内容。这也就意味着App开启这个开关后，按下DTMF一次按键将会有两份DTMF数据在信道中传输（一个In-band语音数据+一个新的RFC2833的RTP数据）。

2、手机SDK软DTMF解码，准确率并不是100%，可能存在解码的误码。

基于以上原因，由于蓝牙方案的SDK并未对通话过程中的语音进行任何加工，有条件的话，还是建议走局域网SIP平台和呼叫中心的用户，直接在服务器或网关中，自行挂载DTMF硬件解码器或软件解码器自己进行解析。手机App设置中，对【转发解码出的DTMF】的开关，默认也是不开启的。

体验和下载地址：

智能拨号器App：http://120.78.211.195:8060/Dialer.apk

拨号器SDK示例app：http://120.78.211.195:8060/sdk/SdkDemo.apk

USB蓝牙配件购买路径(参考)：https://item.taobao.com/item.htm?_u=pk10l4ccbcd&id=649368472986

• 二、手机App的界面开关

我们基于蓝牙电话SDK，封装出来的【智能拨号器App】的Android手机App，在插入USB蓝牙配件后默认就已经具有拦截电话通话和将通话语音数据转发给局域网内的SIP平台和坐席的能力。

在这个基础之上，在手机App的设置中增加了【转发解码出的DTMF】的功能：将蓝牙电话SDK中接收到的语音数据，通过软件解码器解析出“In-band的带内传输方式”来传递的DTMF按键值，经由SIP协议建立的RTP/RTCP通道，使用RFC2833，转发给SIP平台。

智能拨号器App中，设置界面的DTMF开关，大致如下图所示：

开启后即可在手机通话过程中，实时的将解码出的DTMF数字，通过RFC2833，转发给SIP平台。

• 三、SIP平台接收和打印DTMF数字

通话过程中，若对方手机的拨号盘按下了对应的DTMF数字，则局域网SIP平台中将会收到以RFC2833发过来的rtp数据（此处使用《蓝牙电话与FreeSwitch服务器和UA坐席的通话》篇章中搭建的FreeSwitch服务器为例，来介绍SIP平台日志打印和消息转发给坐席的方式）。

界面效果如下图所示：

可以看到，随着通话对方按下不同的按键，FreeSwitch日志中，会不停的刷新DTMF按键值的日志。

（此处有个缺陷：按下按键后，由于手机算力和网络原因，手机SDK解码和手机到局域网SIP平台的传输效率，FreeSwitch日志响应的有快有慢，基本会有三四百毫秒的延迟）

• 四、本地电脑SIP坐席的接听和抓包

我们通过在本地电脑中，使用Wireshark大白鲨进行抓包，并对通话过程内容进行VOIP的解析。可以清楚的看到，在手机App开启了【转发解码出的DTMF】开关后，SIP平台到本地电脑SIP坐席之间的链路，在通话对方按下DTMF按键后，抓包的数据内容中多出了不少以“RTP EVENT”开头的RFC 2833的rtp数据，传递给了本地电脑的SIP客户端。

界面的展示效果如下图所示：

我们直接使用EyeBeam或x-lite的SIP客户端，按下其数字按键，在抓包内容中也同样是以RFC 2833的rtp数据向SIP平台传输。

这样，SIP服务器就只需要开启对RFC 2833的DTMF识别，就能够捕获到通话双方之间的按键内容，不再需要又开启In-band、又开启RFC2833来进行分类识别了。

双向传输的抓包效果，如下图所示：

• 五、题外：画蛇添足的一章

前期预研的时候，我们本想在手机App开启了【转发解码出的DTMF】开关后，学FreeSwitch的【spandsp_start_dtmf】函数功能，将In-band带内DTMF转为RFC2833或SIP-Info时，主动抹去声音数据中In-band的DTMF的语音内容。经过一顿努力，发现效果不理想，就暂时不去改变通话声音的原始数据。主要风险有以下两点：

1、抹除算法感觉有点问题，担心消除的不干净（看下面的图）。

2、SDK拦截手机通话声音，之前都是透传原始语音，收发速度很快。现在手机先做DTMF去除的运算，运算完毕后再把结果的语音数据流发出到SIP平台，增大了延迟。

语音数据处理的的展示效果如下图所示：

经过深思熟虑，暂时还是别搞去除了，两份DTMF就两份吧，手机性能本身就比不上服务器性能。没有必要为了消除带内DTMF数据，把通话语音的延迟给增大。

• 六、总结

本文是为了简化SIP平台的部署难度，针对SIM卡电话通话中的DTMF按键的信息，在蓝牙电话SDK到SIP平台的这一段通路中，将蓝牙电话SDK解码出来的DTMF数字，通过RFC2833的协议，使用rtp将DTMF又多发了一份给SIP平台。使SIP平台可以不用特意专门去解析In-band带内DTMF，即可正常获取到对方的按键值。

有利于局域网SIP平台或呼叫中心，能保持原先的业务不动，在不引入新的DTMF解码器硬件和改动模块配置的情况下，快速的将蓝牙电话方案给对接到原有系统中，进行业务功能的使用。