Hi. I am having a problem with the freeswitch ivr. If someone types a number of digits equal to the maximum length, and then types a #, the # is saved and passed to wherever the transfer or whatever the menuexecapp wants to go. Now I have an app which responds to # by hanging up, so this makes it difficult. Is there a way that either the app could flush the dtmf queue when it comes in, or could (and this would be much better) the # be ignored when the maximum length is reached? I thought this was the way it was supposed to work, anyway. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com
The problem here is its already out of the dtmf listener right after it gets to max digits. You would have to flush at the start of your app, and even then its a race condition depending on how slow they type. On Aug 10, 2013, at 11:22 PM, covici@ccs.covici.com wrote:
Hi. I am having a problem with the freeswitch ivr. If someone types a number of digits equal to the maximum length, and then types a #, the # is saved and passed to wherever the transfer or whatever the menuexecapp wants to go. Now I have an app which responds to # by hanging up, so this makes it difficult. Is there a way that either the app could flush the dtmf queue when it comes in, or could (and this would be much better) the # be ignored when the maximum length is reached? I thought this was the way it was supposed to work, anyway.
Or, make the max lengthlarger and never use that many digits -- I thought it used to work differently, but may be not. Michael Jerris <mike@jerris.com> wrote:
The problem here is its already out of the dtmf listener right after it gets to max digits. You would have to flush at the start of your app, and even then its a race condition depending on how slow they type.
On Aug 10, 2013, at 11:22 PM, covici@ccs.covici.com wrote:
Hi. I am having a problem with the freeswitch ivr. If someone types a number of digits equal to the maximum length, and then types a #, the # is saved and passed to wherever the transfer or whatever the menuexecapp wants to go. Now I have an app which responds to # by hanging up, so this makes it difficult. Is there a way that either the app could flush the dtmf queue when it comes in, or could (and this would be much better) the # be ignored when the maximum length is reached? I thought this was the way it was supposed to work, anyway.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com
First, the wiki page about fail2ban http://wiki.freeswitch.org/wiki/Fail2ban has this bit of tantalizing, but cryptic advice: "Enable "log-auth-failures" on each Sofia profile to monitor -- this requires a high enough loglevel on your logs to save these messages. " What does "high enough" mean? ( It looks like the default in autoload_configs/syslog.conf.xml is warning ) Why isn't log-auth-failures the default? ,., Looking at simple ways to block lists of IP addresses - there are WRONG ways to do this. Huge lists blocked as dynamic will reduce performance of your firewall. Looks like the best way is via ipsets: http://www.shorewall.net/ipsets.html So if you want to use Brain West’s blacklist ( http://daffy.bkw.org/blacklist.txt ) best to read up on ipsets. ,., The other bit is that it is best to block at the firewall if possible - this looks like it can be done by setting up fail2ban on the freeswitch box and setting up the action to use the ban command over ssh. actionban = ssh user@firewall.com shorewall drop <ip> actionunban = ssh user@firewall.com shorewall allow <ip> fail2ban using shorewall uses the dynamic method (appropriately due to the smaller number of IPs) If you want to see a list of what is currently blocked: $ shorewall show dynamic Will dump out a list of the currently banned IP addresses. -------------------------------------------------------------------------------- Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 The society that puts equality before freedom will end up with neither. The society that puts freedom before equality will end up with a great measure of both. - Milton Freidman --------------------------------------------------------------------------------
Huge lists blocked as dynamic will reduce performance of your firewall.
FWIW, one of my firewalls (a rather low-end machine by today's standards) sees a hundred of Go of daily traffic, most of it hitting a standard iptables chain with 4000+ blacklist rules before being accepted, and the load average / CPU usage are close to 0. The rules are a mix of source ips/nets, protocol and packet size checks, etc. In comparison, Brian's blacklist is only 142 lines so ipset is not really needed for performance (but of course, if it's packaged for your distro why not use it - in my case it was not and I was lazy compiling/maintaining it). BTW a way to flush/repopulate a chain *very* quickly is to create a file in the iptables-restore format and restore it: LIST=/path/to/blacklist RULES=/path/to/some/rules echo "*filter" > $RULES echo ":blacklist - [0:0]" >> $RULES for i in $(cat "$LIST"); do echo "-A blacklist -s $i -j DROP" >> $RULES done echo "COMMIT" >> $RULES /sbin/iptables-restore --noflush $RULES
participants (4)
-
covici＠ccs.covici.com
-
Ivan
-
Karl Schmidt
-
Michael Jerris