summarize
freeswitch is a simple and easy to use VOIP open source softswitch platform.
But fs has a bug in handling update message, to reproduce the problem, use sipp to simulate uas, send update and send DTMF code.
This document documents the sipp configuration scheme.
matrix
CentOS 7.9
freeswitch 1.10.7
sipp.3.6.2
Description of the problem
In the process of interfacing with the operator, the operator will return 183 internally, and then the B-way landing end will modify the media parameters through UPDATE.
However, when fs processes the update message, the sofia-sip stack responds directly with 200 OK, and the media parameters of the sdp in the 200 response message are not the result of negotiation.
When the update message is reported to the business layer of fs, the business layer of fs will negotiate and set the media parameters according to the sdp of the update, but the negotiation result of the business layer of fs and the result of the landed end of the B-channel may be different, resulting in the media loss problem.
sipp script
Test Environment Module.
eyebean --> fs-reg --> fs --> sipp
The sipp acts as the uas side and sends the update message after the 183 message.
Where 101 is used as the payload of the rfc2833 in the 183 message and 103 is used as the payload of the rfc2833 in the update message.
The script reads as follows.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "">
<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>
The file directory structure is as follows.
sipp.3.6.2/conf/
sipp.3.6.2/pcap/dtmf_2833_9.pcap
Start sipp-uas.
cd sipp.3.6.2/conf
sudo sipp -i 10.55.55.138 -p 5555 -sf
Initiate a call test.
Initiate a call using eyebean and hang up after 10 seconds to see how the fs node handles the DTMF. fs has received the DTMF code from sipp, but it is not forwarded to the A-road, which is the same phenomenon as the problem described above.
sip signaling and media screenshots
Screenshots of sip signaling and media for the entire call flow.
summarize
sipp is flexible enough to help us build a variety of simulation scenarios in our tests.
There are a variety of restoration options on the follow-up schedule.
nothing but the usual
seek the truth and obtain it