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保持一致。
空空如常
求真得真
工作中难免会遇到各种各样的数据结构,较为全面的了解数组操作,对于复杂数据结构的处理会非常有用且节省时间。所以想在这里总结一下工作中常用的数组操作,都是一些非常基础的知识,大家看个乐就好~
记录一次开发中遇到的关于 ThreadLocal 问题,场景是数据库表中的操作人总是无缘无故的被更改,排查了几遍代码才发现是 ThreadLocal 没有及时清理导致的。