[Asterisk-Users] Re: AGI and fast-entered DTMF codes

[Alan Murphy]

> 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.  

It must be the phone I was using - which is an internal phone system
phone, rather than your average PSTN phone one would have at home. I
think my concerns were that if I could cause a problem like that with
that particular phone, random users could also cause this.


> 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.

Sorry, I think I explained that a bit wrong. People will receive a code.
Then they must call in and enter the code. Once that is successfully
verified in the database, they proceed to enter details (for example,
date of birth) and then record a short message. The contest is based on
the message they enter. Therefore, they will not be in a rush to type in
the code faster than others, but my fear was that they might be quick
typers and cause a dead line. Again, I used the same (obviously
incorrectly configured) phone to call another IVR service that seemed to
be able to handle these quick-fire DTMF tones, so I thought that it
could be an Asterisk/Zaptel problem, rather than a problem with that
particular phone.


> If it isn't recognised as DTMF, it is sent as audio. There wouldn't be
any garbage.

I see. Unfortunately, my telecoms experience is very limited (I only
really started using Asterisk about 4 weeks ago!), so forgive my
understanding of it! Would that audio cause Asterisk problems in that
case, if Asterisk were listening out for X DTMF digits, causing it to
bomb out of the "GET DATA" routine?

> 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. 

Excellent point. My background is in the server-side J2EE arena and I
recently built a multi-threaded Java server to handle high volume SMS
messages routed through 3 network providers. This is a little bit of a
paradigm shift from what I was doing, as the calls through Asterisk are
interactive and the user knows if something is wrong and can redial. For
SMS messages, the user "fires and forgets" and if no reply is
forthcoming, does not know whether that is meant to happen, or the
message was lost. This would suggest that, with AGI, the most effective
way to go would be a single process that is created and destroyed per
call. It does require a trade-off between language functionality and
speed of development against the performance profile of that language.
Therefore Java might be a bit heavy handed in a large scale environment
on that basis.

As for the stability of a single server process, monitoring threads can
be put in place to ensure a process is in place. However, my preferred
way would be to allow the lightweight process that Asterisk calls first
to start or restart the server if communication fails. You might have
some extra delays, but for high volumes, the extra efficiency might be
worth the trade off.

Cheers for the help and sorry for going slightly off topic!

Alan.