记录freeswitch的一个2833问题

概述

freeswitch是一款简单好用的VOIP开源软交换平台。

运营商内部新老系统混用，互联互通的问题较多，其中以DTMF码的问题最多，花样也多。

环境

CentOS 7.9

freeswitch 1.10.7

问题描述

问题现象

正常的fs业务服务器，呼叫正常，部分呼叫报错DTMF收码失败。

内部测试，呼叫正常，信令正常，媒体流正常，DTMF收码失败，和号码有关系，有些号码收码正常，有些号码收码失败，号码固定。

问题分析

分析DTMF收码失败的号码信令。呼叫信令正常，媒体流正常，DTMF码流不正常。

B路发送到fs的DTMF码使用rfc2833的rtpevent格式，但是fs收到后没有转发到A路。

继续查看信令细节，B路响应183后，随后发送update修改媒体，update中SDP信息如下，其中的100表示rfc2833的payload。

audio 19480 RTP/AVP 8 18 100

rtpmap:100 telephone-event/8000

fs对update响应200OK，SDP信息如下，其中的101表示rfc2833的payload。

audio 53106 RTP/AVP 8 101

rtpmap:101 telephone-event/8000

查看B路的DTMF码，rtpevent包中Real-Time transport Protocol下的Payload type字段值为telephone-event(101)，B路使用了fs响应的101作为payload，而不是update中的100。

但是fs收到rtpevent后，发现payload type是101，而不是update中的100，就丢弃了该DTMF包（猜测，没有日志支持）。

临时方案

修改B路external.xml配置文件，从默认值101修改为100。

<param name="rfc2833-pt" value="100"/>

修改后测试，B路发送update携带payload为100，fs响应200OK携带payload为100，DTMF码转发正常。

总结

临时方案覆盖面不足，无法保证所有线路都能通过该方式修正该问题。

正式方案应该修改fs的200OK携带payload，可以动态的跟随update保持一致。

空空如常

求真得真