[Freeswitch-users] DTMF Digits Lost when Under Load
Michael Toop
michaelt at voxcore.voxtelecom.co.za
Mon Nov 30 04:12:18 PST 2009
Hi All,
Thought I would share my solution to this DTMF problem: it turns out my
ISP was capping my bandwidth & dropping packets to keep the connection &
1Mbps, so the experienced DTMF loss was actually packets being discarded.
On my way to this discovery I tested Freeswitch & DTMF quite thoroughly &
never actually found any problems even at hundreds of concurrent calls.
Here is how I tested, who knows this might be useful to someone:
- I used SIPp to generate calls & a Python script to log the received
DTMF digits
- SIPp command line:
- sipp -sf dtmfSenario.xml -d 10000 -s 451 -l 96 -mp 5606 -i
xxx.xxx.xxx.xxx
- dtmfSenario.xml below
- Dialplan:
- <extension name="test_dtmf_capture_test">
<!--Grab calls for dialing -->
<condition field="destination_number" expression="(^100100$)">
<action application="answer"/>
<action application="python" data="writeDtmfStats"/>
</condition>
</extension>
- Python:
- import sys
from freeswitch import *
def get_number(session,invalid,num=20):
digits = session.getDigits(num, "", 15000)
consoleLog("info","Got '%s' digits from user.\n" % digits)
if digits == '':
# Invalid call
if invalid == 3:
consoleLog("info","Three invalid
attempts!!\n")
session.streamFile("/usr/local/freeswitch/sounds/en/us/callie/misc/8000/invalid_extension.wav")
session.hangup()
sys.exit(0)
else:
session.streamFile("/usr/local/freeswitch/sounds/en/us/callie/misc/8000/invalid_extension.wav")
get_number(session,invalid + 1)
else:
consoleLog("info","Got a valid number: %s,
proceeding...\n" % digits)
return digits
def handler(session, args):
session.streamFile("/usr/local/freeswitch/sounds/en/us/callie/ivr/8000/ivr-please_enter_extension_followed_by_pound.wav")
numberToDial = get_number(session,2,num=10)
consoleLog('info','Got 10 DTMF digits. Writing "1" to file...\n')
fo = open('/tmp/dtmfData.csv','a')
fo.write('"1"\n')
fo.close()
# Do some stuff & wait for SIPP to hangup
session.streamFile("/usr/local/freeswitch/sounds/en/us/callie/ivr/8000/ivr-please_enter_extension_followed_by_pound.wav")
session.streamFile("/usr/local/freeswitch/sounds/en/us/callie/ivr/8000/ivr-please_enter_extension_followed_by_pound.wav")
return
- DTMF senario file:
- # cat dtmfSenario.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<!-- This program is free software; you can redistribute it
and/or -->
<!-- modify it under the terms of the GNU General Public License
as -->
<!-- published by the Free Software Foundation; either version 2 of
the -->
<!-- License, or (at your option) any later
version. -->
<!--
-->
<!-- This program is distributed in the hope that it will be
useful, -->
<!-- but WITHOUT ANY WARRANTY; without even the implied warranty
of -->
<!-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
the -->
<!-- GNU General Public License for more
details. -->
<!--
-->
<!-- You should have received a copy of the GNU General Public
License -->
<!-- along with this program; if not, write to
the -->
<!-- Free Software Foundation,
Inc., -->
<!-- 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA -->
<!--
-->
<!-- Sipp 'uac' scenario with pcap (rtp)
play -->
<!--
-->
<scenario name="UAC with media">
<!-- In client mode (sipp placing calls), the Call-ID MUST
be -->
<!-- generated by sipp. To do so, use [call_id]
keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[local_ip_type] [local_ip]
t=0 0
m=audio [auto_media_port] RTP/AVP 18 100
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
]]>
</send>
<!-- a=rtpmap:8 PCMA/8000 -->
<recv response="100" optional="true">
</recv>
<recv response="180" optional="true">
</recv>
<!-- By adding rrs="true" (Record Route Sets), the route
sets -->
<!-- are saved and used for following messages sent. Useful to
test -->
<!-- against stateful SIP
proxies/B2BUAs. -->
<recv response="200" rtd="true" crlf="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message
by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100]
percent. -->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: sut
<sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- Play a pre-recorded PCAP file (RTP
stream) -->
<!--
<nop>
<action>
<exec play_pcap_audio="g711a.pcap"/>
</action>
</nop>
-->
<!-- Pause 8 seconds, which is approximately the duration of
the -->
<!-- PCAP
file -->
<pause milliseconds="5000"/>
<!-- Play an out of band DTMF
'1' -->
<nop>
<action>
<exec play_pcap_audio="dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="1000"/>
<!-- Play an out of band DTMF
'1' -->
<nop>
<action>
<exec play_pcap_audio="dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="1000"/>
<!-- Play an out of band DTMF
'1' -->
<nop>
<action>
<exec play_pcap_audio="dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="500"/>
<!-- Play an out of band DTMF
'1' -->
<nop>
<action>
<exec play_pcap_audio="dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="500"/>
<!-- Play an out of band DTMF
'1' -->
<nop>
<action>
<exec play_pcap_audio="dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="500"/>
<!-- Play an out of band DTMF
'1' -->
<nop>
<action>
<exec play_pcap_audio="dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="500"/>
<!-- Play an out of band DTMF
'1' -->
<nop>
<action>
<exec play_pcap_audio="dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="500"/>
<!-- Play an out of band DTMF
'1' -->
<nop>
<action>
<exec play_pcap_audio="dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="500"/>
<!-- Play an out of band DTMF
'1' -->
<nop>
<action>
<exec play_pcap_audio="dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="500"/>
<!-- Play an out of band DTMF
'1' -->
<nop>
<action>
<exec play_pcap_audio="dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="2000"/>
<!-- The 'crlf' option inserts a blank line in the statistics
report. -->
<send retrans="500">
<![CDATA[
BYE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: sut
<sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 2 BYE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<recv response="200" crlf="true">
</recv>
<!-- definition of the response time repartition table (unit is
ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is
ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
Cheers,
Michael
On Mon, Nov 16, 2009 at 5:25 PM, Anthony Minessale <
anthony.minessale at gmail.com> wrote:
> That's a pretty small problem description to be so sure about something.
> It would probably be better to capture some evidence of the exact problem
> you are having since we are using computers and we need to see the computers
> in action doing something specifically incorrect to diagnose any sort of
> problem. Take the time to describe the origin and destination of your
> calls, the call flow, the hardware in use on both ends of the call, detailed
> console logs on debug level, (maybe even uncomment the 2833 debug ifded in
> switch_rtp.c) and gather something to go on besides "I seem to be losing
> dtmf) maybe a packect capture of the networking interface on both ends of
> these calls.
>
> Also problems should be reported to http://jira.freeswitch.org not this
> mailing list.
> Save us a step if you report a jira and provide all the info above or we
> will just have to ask for it again.
>
>
> On Mon, Nov 16, 2009 at 1:07 AM, Michael Toop <
> michaelt at voxcore.voxtelecom.co.za> wrote:
>
>> Hi All,
>>
>> I have an issue that when my call volumes on my FS IVR box > 30 calls
>> DTMF digits are lost (using RFC2833). It is definitely load related as it
>> all works perfectly under 30 calls.
>>
>> Any pointers or a solution to the problem?
>>
>> Thanks,
>>
>> Michael
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
> Twitter: http://twitter.com/FreeSWITCH_wire
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20091130/227f9d35/attachment-0002.html
More information about the FreeSWITCH-users
mailing list