概述
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很靈活，可以幫助我們在測試中構建各種模擬場景。
修復方案有多種，後續安排上。
空空如常
求真得真