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@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@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@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@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org