【freeswitch】IVR按键输入的分析

Posted

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了【freeswitch】IVR按键输入的分析相关的知识，希望对你有一定的参考价值。

参考技术A

IVR按键输入的一个核心能力的处理DTMF。

Freeswitch自身有处理DTMF的能力。

FS共支持三种DTMF处理方式，分别为inband、rfc2833、sipinfo

1.1.INBAND
INBAND为带内检测方式，而且与普通的RTP语音包混在一起传送。
1.2.RFC2833
RFC2833即识别一种特殊RTP报文，报文格式如下，其中Event ID表示按键值，同一个DTMF按键通常会对应多个RTP包，这些RTP数据包的时间戳均相同，此可以作为识别同一个按键的判断依据，最后一包RTP数据包的end标志置1表示DTMF数据结束。
另外，很多SIP UA默认的TeleponeEvent都为101，但可以人为修改，这时要求在进行RFC2833 DTMF检测之前需事先获取SDP协商的TeleponeEvent参数；
1.3.SIPINFO
SIPINFO为带外检测方式，通过SIP信令通道传输DTMF数据。这种方式甚至比RFC2833更有效。但是由于SIP信令和RTP收发采用的是不同的端口，所以可能会造成收到DTMF和实际的声音不同步。

配置文件conf/sip_profile/internal.xml和external.xml
internal和external是单独配置的，关于DTMF都有相同的配置项
<param name="dtmf-type" value="rfc2833"/>
这个值默认好像是注释的。注释的默认为inband。
value的值可以是none或者rfc2833。

使用rfc2833的情况下，FS只需要解析RTP流程中的event事件即可。
不过使用rfc2833要求线路或者对端支持这种方式，如果不支持，可以使用inband方式交给FS处理。

某些语音网关可以处理inband的DTMF，然后生成rfc2833rtp event。但是一些设备会存在准确率的问题

FS内部使用了一个队列dtmf_inqueue存储了dtmf结构体。 所有从rtp中获取的dtmf事件压入到该队列。
然后供需要使用的地方从队列中弹出

FS处理inband的DTMF需要调用两个APP。
start_dtmf/stop_dtmf。
在dialplan里直接调用这两个APP即可。网上大部分的教程是通过dialplan的。
如果使用命令，在发起呼叫的时候可以通过originate的参数带上。如下

start_dtmf/stop_dtmf是默认的mod_dptool里的,于此类似的还有一个模块 mod_spandsp 也提供了两个APP：spandsp_start_dtmf/spandsp_stop_dtmf
个人感觉这个效果会更好一点。

如果使用inband的方式的话请注意几点：

存在一些场景，在一条腿上获取到了dtmf事件，但是需要转给其他腿。特别是在bridge的时候。

FS在bridge的时候，默认会处理这种情况。

它会把腿1的dtmf都传给腿2.
如果不想传的话，设置参数bridge_filter_dtmf。

FreeSWITCH收到重复的DTMF信号

一、背景

用户是运营商手机，拨打的是运营商的固话号码进入的FreeSWITCH的IVR，进入IVR语音播报后，按指定的分机号呼相关人员。

二、现象

用户反映拨打124870找不到指定人员，以前是正常的。

三、排查

跟踪日志。

1772094 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:57.950006 [DEBUG] switch_ivr_async.c:3200 DTMF DETECTED: [1][0]
1772095 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:57.950006 [INFO] switch_channel.c:515 RECV DTMF 1:0
1772096 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:57.950006 [DEBUG] switch_channel.c:524 sofia/internal/15367900000@172.18.0.220 SHORT DTMF DIGIT LEN [0]
1772099 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:58.190012 [DEBUG] switch_rtp.c:7193 RTP RECV DTMF 1:800
1772100 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:58.190012 [INFO] switch_channel.c:515 RECV DTMF 1:800
1772101 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:58.790011 [DEBUG] switch_rtp.c:7193 RTP RECV DTMF 1:800
1772102 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:58.790011 [INFO] switch_channel.c:515 RECV DTMF 1:800
1772124 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:59.370014 [DEBUG] switch_rtp.c:7193 RTP RECV DTMF 2:800
1772125 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:59.370014 [INFO] switch_channel.c:515 RECV DTMF 2:800
1772128 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:59.690013 [DEBUG] switch_ivr_async.c:3200 DTMF DETECTED: [4][320]
1772129 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:59.690013 [INFO] switch_channel.c:515 RECV DTMF 4:320
1772130 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:59.690013 [DEBUG] switch_channel.c:524 sofia/internal/15367900000@172.18.0.220 SHORT DTMF DIGIT LEN [320]
1772131 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:59.930011 [DEBUG] switch_rtp.c:7193 RTP RECV DTMF 4:800
1772132 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:59.930011 [INFO] switch_channel.c:515 RECV DTMF 4:800
1772133 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:59.930011 [DEBUG] switch_ivr_menu.c:424 digits 111244
1772134 daadbfe3-1cbf-47b3-a2eb-f97d0ad38911 2018-05-03 17:16:59.930011 [DEBUG] switch_ivr_menu.c:559 action regex [111244] [/^(\\d{6})$/] [2]

四、分析日志

发现收到了DTMF信号是111244。一个一个看，

第一个DTMF信号1是inband信号，从音频信号里分析出来的（看日志打印DTMF DETECTED表明了这种方式）。
第二个DTMF信号1是RFC2833信号，从RTP包里分析出来的（看日志打印RTP RECV DTMF表明了这种方式）。
第三个DTMF信号1是RFC2833信号，从RTP包里分析出来的（看日志打印RTP RECV DTMF表明了这种方式）。
第四个DTMF信号2是RFC2833信号，从RTP包里分析出来的（看日志打印RTP RECV DTMF表明了这种方式）。
第五个DTMF信号4是inband信号，从音频信号里分析出来的（看日志打印DTMF DETECTED表明了这种方式）。
第六个DTMF信号4是RFC2833信号，从RTP包里分析出来的（看日志打印RTP RECV DTMF表明了这种方式）。

也就是说，运营商同时用两种方式给我传输了DTMF信号，关键FreeSWITCH还同时解了两种信号源，拼成一个DTMF字串，所以BUG就出现了。

以前是正常的，是以前运营商没有传rfc2833信号。

联系运营商，说关闭两种协议同时发的配置了。现在只使用inband方式。

五、继续测试

还是能收到号码重复的现象，这次再看日志，变化了：

这次所有的信号都是使用inband方式传递过来的了，但是依然重复了。

2546518 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:18.530004 [DEBUG] switch_ivr_async.c:3200 DTMF DETECTED: [1][0]
2546519 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:18.530004 [INFO] switch_channel.c:515 RECV DTMF 1:0
2546520 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:18.530004 [DEBUG] switch_channel.c:524 sofia/internal/15367900000@172.18.0.220 SHORT DTMF DIGIT LEN [0]
2546523 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:18.830006 [DEBUG] switch_ivr_async.c:3200 DTMF DETECTED: [1][640]
2546524 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:18.830006 [INFO] switch_channel.c:515 RECV DTMF 1:640
2546525 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:19.350005 [DEBUG] switch_ivr_async.c:3200 DTMF DETECTED: [7][0]
2546526 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:19.350005 [INFO] switch_channel.c:515 RECV DTMF 7:0
2546527 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:19.350005 [DEBUG] switch_channel.c:524 sofia/internal/15367900000@172.18.0.220 SHORT DTMF DIGIT LEN [0]
2546531 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:19.650004 [DEBUG] switch_ivr_async.c:3200 DTMF DETECTED: [7][640]
2546532 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:19.650004 [INFO] switch_channel.c:515 RECV DTMF 7:640
2546533 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:20.610004 [DEBUG] switch_ivr_async.c:3200 DTMF DETECTED: [8][0]
2546534 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:20.610004 [INFO] switch_channel.c:515 RECV DTMF 8:0
2546535 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:20.610004 [DEBUG] switch_channel.c:524 sofia/internal/15367900000@172.18.0.220 SHORT DTMF DIGIT LEN [0]
2546536 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:20.890004 [DEBUG] switch_ivr_async.c:3200 DTMF DETECTED: [8][640]
2546537 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:20.890004 [INFO] switch_channel.c:515 RECV DTMF 8:640
2546538 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:20.890004 [DEBUG] switch_ivr_menu.c:424 digits 117788
2546539 e6e0ab6c-dec7-4713-a235-a5c9254011e3 2018-05-09 09:57:20.890004 [DEBUG] switch_ivr_menu.c:559 action regex [117788] [/^(\\d{6})$/] [2]

六、继续处理

联系运营商，说需要抓包分析。想一想也是，这种日志毕竟是我们的软件打印的，不排除我们软件的检测问题。

七、奇妙的过程

让我们自己从源头定位一下吧，首先，抓包。因为业务电话很多。抓到的wireshark包很大。

1. 拆包和并包，参考http://www.cnblogs.com/yoyotl/p/8579217.html。从1个GB的包里拆出一个1.5MB的小包。

2. 查看并导出RTP流。

2.1 电话->RTP->RTP流；

2.2 在弹出的RTP流中选中需要导出那一条记录->分析；

2.3 在弹出的对话框中选择->Save->同步的正向音频；

2.4 得到一个*.au格式的音频文件。

赞一下wireshark，可以很直观的看出来声音波形，如图：

3. 问题来了，怎么知道这些波形里是否含有DTMF信号呢？是的话又是哪个信号呢？

这时候就需要借助另外一款神奇的产品了Cool Edit，真是够酷的！

4. 下载安装，打开au文件，得到这样的一个图。

5. 乍一看和wireshark看到的波形一样，但是这款软件提供了量化分析的功能。

6. 选中想要分析的波形区域->Analyze->Show Frequency Analysis，弹出如下一个图：

读出两个峰值，分别代表了低频和高频频率。
低频695.3，高频1210

7. 对照标准的DTMF频率表，如图：

8. 哈哈，得到了这段波形代表的DTMF信号了，就是1。

以此类推，读出这段波形中的DTMF信息是117788661100。

确定是运营商多送了重复的DTMF信号，不抓虾的感觉真好。

 

以上是关于【freeswitch】IVR按键输入的分析的主要内容，如果未能解决你的问题，请参考以下文章

freeswitch开启IVR按键

FreeSWITCH收到重复的DTMF信号

freeswitch可以把手机电话转成voip吗

freeswitch esl outbound中如何放音采集按键？

asterisk怎么配置IVR

如何在FreeSWITCH开源软交换安装Sangoma-A400模拟卡