概述

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:[^;&gt;]+"
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很灵活，可以帮助我们在测试中构建各种模拟场景。

修复方案有多种，后续安排上。

空空如常

求真得真