On Wed, 2003-02-26 at 16:40, Alan Murphy wrote: > Hi Stephen, > > I tested the system using both a desk phone and my mobile phone. The > mobile phone had no problem, no matter the time between key presses, for > the reason you mention below (it sends the tones for a specific and > consistent period of time). The desk phone did not do this and thus > resulted in the problem. As for the actual speed between the tones, I'm > afraid I couldn't measure that, but it was quite fast with no pauses > between key presses.
Thats fine, didn't expect you to be able to measure it. The no pauses raises a bit of concern. There is supposed to be a set time between keypresses. > When I noticed this, I knew that I could either send the tones in a > reasonable amount of time, or use a better phone. Unfortunately, we are > bound to get users who will type fast and wonder why the line has gone > dead on the other end. We are running a small competition for people > here, so have no control over their type of phone. If they are typing fast due to a contest, chances are they already know that they can type faster than speed dial, but they can outrun the telco and have problems. This is something I did back when I tried to win things from the radio stations. At one point I started using a modem that I could tune the pause and tone length till I was getting only about 10% failures. The time to dial was significantly faster. > I tested the desk phone with a well known phone banking service here > (which requires DTMF tones), and it had no problem with fast sending > from the phone. It could be the hardware involved, I suppose. I thought > initially it was a buffering problem in Asterisk. The X100P driver could > be sending garbage to the application if it cannot decipher the tones > quick enough, thus resulting in the problem. When I get more time, I > will delve deeper into the code and attempt to find the source of the > problem. I thought someone else might have encountered this and would > save me some time :) If it isn't recognised as DTMF, it is sent as audio. There wouldn't be any garbage. > As for Java as a scripting language, I do most of my development in it, > so it was a matter of convenience. I also had reusable database code to > access some internal data that is required for this project. You are > right about scalability, though. The AGI script will create a new JVM > each time it is run. A lightweight client (in a language other than > Java) that establishes a connection to a multi-threaded Java server > would allow scalability, but that sounds like a lot of work for two > incoming lines :) Good, you didn't see that as the begining of a language holy war. For 2 lines you are correct it should be plenty enough. As for the idea of building a multi threaded java server, do you want to tie the system to another single process that could fail and take all lines down with it? We have a app we have been working with, and rather like the idea of the app starting and dieing on a per channel/per call basis so as to make sure the system is always respawning a fresh copy for a call. Our current software has threads that hang occasionally and tie up the phone line till we interactively reset it. This is why I spend so much time with asterisk since it will eliminate that interactive reseting. -- Steven Critchfield <[EMAIL PROTECTED]> _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
