Ok but in our case its not the case anyway , people don't like to comeback to our ivr's ....
So regarding the initial topic getting DTMF/RTP Events from the main trunk :)
On 10/25/2011 12:07 AM, Antonio Teixeira wrote:
> Well guys it depends on your application , generally i solve this
> with regexp , a buffer and a way to clear the buffer of
> invalid/duplicated data I'm extending it to support with min delay
> between keys.
> This is not as hard as you think when using min/max :) and your data
> is 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 so
> if len(dtmf) > 1: drop ...
>
> I play with this in our test environment not in our production and it
> works :)
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