概述
freeswitch是一款简单好用的VOIP开源软交换平台。
但是fs在处理update消息时候有BUG，为了复现问题，使用sipp模拟uas，发送update并发送DTMF码。
本文档记录sipp的配置方案。
环境
CentOS 7.9
freeswitch 1.10.7
sipp.3.6.2
问题描述
在与运营商对接的过程中，运营商内部会先返回183，然后B路落地端再通过update修改媒体参数。
但是fs在处理update消息时，sofia-sip协议栈会直接响应200 OK，并且200响应消息中sdp的媒体参数不是经过协商后的结果。
当update消息上报fs的业务层后，fs的业务层会根据update的sdp协商并设置媒体参数，但是fs业务层的协商结果和B路落地端的结果可能会存在差异，造成媒体丢失问题。
sipp脚本
测试环境模块。
eyebean --> fs-reg --> fs --> sipp
sipp作为uas端，并在183消息后发送update消息。
其中，183消息中使用101作为rfc2833的payload，update消息中使用103作为rfc2833的payload。
脚本 uas-test-update.xml 内容如下。
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic UAS responder">
<recv request="INVITE" crlf="true" >
<action>
<ereg regexp=".*"
search_in="hdr"
header="From:"
check_it="true"
assign_to="1" />
<ereg regexp=".*"
search_in="hdr"
header="To:"
check_it="true"
assign_to="2" />
<ereg regexp="sip:[^;>]+"
search_in="hdr"
header="Contact:"
check_it="true"
assign_to="3" />
<ereg regexp=".*"
search_in="hdr"
header="CSeq:"
check_it="true"
assign_to="4" />
</action>
</recv>
<send>
<![CDATA[
SIP/2.0 100 Trying
[last_Via:]
[last_From:]
[last_To:];tag=sippTag01
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Length: 0
]]>
</send>
<pause milliseconds="1000"/>
<send>
<![CDATA[
SIP/2.0 183 Session Progress
[last_Via:]
[last_From:]
[last_To:];tag=sippTag01
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 8 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
]]>
</send>
<pause milliseconds="1000"/>
<!-- The 'crlf' option inserts a blank line in the statistics report. -->
<send retrans="500" crlf="true">
<![CDATA[
UPDATE [$3] SIP/2.0
[last_Via:]
To: [$1]
From: [$2];tag=sippTag01
[last_Call-ID:]
CSeq: 11 UPDATE
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 8 18 103
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 telephone-event/8000
a=fmtp:103 0-15
a=ptime:20
]]>
</send>
<recv response="200" crlf="true"> </recv>
<pause milliseconds="1000"/>
<send retrans="500">
<![CDATA[
SIP/2.0 200 OK
[last_Via:]
From: [$1]
To: [$2];tag=sippTag01
[last_Call-ID:]
CSeq: [$4]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Type: application/sdp
Content-Length: 0
]]>
</send>
<recv request="ACK" crlf="true"> </recv>
<pause milliseconds="2000"/>
<nop>
<action>
<exec play_pcap_audio="../pcap/dtmf_2833_9.pcap"/>
</action>
</nop>
<pause milliseconds="500"/>
<nop>
<action>
<exec play_pcap_audio="../pcap/dtmf_2833_5.pcap"/>
</action>
</nop>
<pause milliseconds="500"/>
<nop>
<action>
<exec play_pcap_audio="../pcap/dtmf_2833_2.pcap"/>
</action>
</nop>
<pause milliseconds="500"/>
<nop>
<action>
<exec play_pcap_audio="../pcap/dtmf_2833_7.pcap"/>
</action>
</nop>
<pause milliseconds="500"/>
<recv request="BYE">
</recv>
<send>
<![CDATA[
SIP/2.0 200 OK
[last_Via:]
[last_From:]
[last_To:]
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Length: 0
]]>
</send>
<timewait milliseconds="3000"/>
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
文件目录结构如下。
sipp.3.6.2/conf/uas-test-update.xml
sipp.3.6.2/pcap/dtmf_2833_9.pcap
启动sipp-uas。
cd sipp.3.6.2/conf
sudo sipp -i 10.55.55.138 -p 5555 -sf uas-test-update.xml
发起呼叫测试。
使用eyebean发起呼叫，并在10秒后挂机，查看fs节点对DTMF的处理情况，fs有收到sipp的DTMF码，但是并没有转发到A路，和上述的问题现象一致。
sip信令和媒体截图
整个呼叫流程的sip信令和媒体截图。
总结
sipp很灵活，可以帮助我们在测试中构建各种模拟场景。
修复方案有多种，后续安排上。
空空如常
求真得真