Try playing with real users. They *always* type ahead by their second or
third call to the same IVR. Handling type-ahead well - accepting the
string of entered digits, skipping the playback of prompts so you don't
slow things down, etc. - is one of the key tests of a good IVR.
On 10/25/2011 12:07 AM, Antonio Teixeira wrote:Well guys it depends on your application , generally i solve thiswith regexp , a buffer and a way to clear the buffer ofinvalid/duplicated data I'm extending it to support with min delaybetween keys.This is not as hard as you think when using min/max :) and your datais predictable :)Is a properly engineered solution so unattainable that such guesswork is
the only solution?Also in ivr menus humans don't generally guess whats the next menu soif len(dtmf) > 1: drop ...I play with this in our test environment not in our production and itworks :)Try playing with real users. They *always* type ahead by their second or
third call to the same IVR. Handling type-ahead well - accepting the
string of entered digits, skipping the playback of prompts so you don't
slow things down, etc. - is one of the key tests of a good IVR.
Steve
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