Posted: Tue Jun 19, 2007 9:18 pm Post subject: [asterisk-speech-rec] DTMF response time improved during spe
I ran into a problem a few days ago with speech recognition in
generic conversion of DTMF-based applications. We have several apps
here which rely upon single keypresses in order to take some action,
like most IVR apps. The problem was that the existing method by
which Asterisk was handing off DTMF was a bit on the sluggish side
for entries made on the DTMF keypad - there was around a 5 second
delay between a keypress and an action being returned to the
dialplan. This was a drastic performance cut from our existing apps,
so voice-enabling them wasn't possible until that bug was fixed.
I'm pleased to say a quick response by Lumenvox (StephenKeller) and
Digium (file) added an as-yet undocumented repair variable to solve
the problem. It was repaired and added to 1.4 on June 15th 2007, and
patches cleanly to other versions (it's only about 5 lines in
app_speech_utils.c)
You can now set a variable called "SPEECH_DTMF_MAXLEN" from within
the dialplan which indicates the maximum number if DTMF digits your
grammar is expecting. In our case, where menus were all
single-keypress to start with, we set the value to "1" and it returns
back the values immediately. I also created .gram files for
single-digit keypresses for both voice and DTMF, though I'm uncertain
if this is required now with this patch. Interestingly, if you
specify "2" as the length of digits, but your DTMF grammar only
indicates a single digit, the grammar is ignored and the number of
digits you enter with DTMF is returned. If you speak more than two
digits, the system acts properly according to the grammar and only
the first digit is returned. I've been told this is because Asterisk
is handling the DTMF (and is being instructed what to do with
SPEECH_DTMF_MAXLEN) and the voice recognition portion is using the
grammar.
Note: I've not been able to get "#" and "*" to work yet with the DTMF
signalling, but I've been talking with Lumenvox about if this is a
syntax problem with my attempts, or a deeper bug.
Examples below.
JT
[root@blah grammars]# more digit.gram
#ABNF 1.0 UTF-8;
Posted: Tue Jun 19, 2007 9:49 pm Post subject: [asterisk-speech-rec] DTMF response time improved during spe
DTMF digits from everything I have read in the source code and other
various places are indeed handled by Asterisk and not even passed to the
Speech Engine, this is done by SpeechBackground() in app_speech_utils. A
good way to show this is use ${SPEECH_SCORE(0)} and ${SPEECH_GRAMMAR(0)},
for dtmf digits they will return 1000, and dtmf respectively.
The 5 second delay you were experiencing, just for everyones info is a
default set in that application to wait for anymore digits and was
bypassed by using a '#' character after the digits you entered(the short
hack make your menus tell the users to press the # key after entering dtmf
digits). This does mean that you do not need dtmf grammars as the speech
engine will not get a chance to know that you have used any dtmf digits.
This new variable I can see where it will be widely valuable.
Brent
Quote:
I ran into a problem a few days ago with speech recognition in
generic conversion of DTMF-based applications. We have several apps
here which rely upon single keypresses in order to take some action,
like most IVR apps. The problem was that the existing method by
which Asterisk was handing off DTMF was a bit on the sluggish side
for entries made on the DTMF keypad - there was around a 5 second
delay between a keypress and an action being returned to the
dialplan. This was a drastic performance cut from our existing apps,
so voice-enabling them wasn't possible until that bug was fixed.
I'm pleased to say a quick response by Lumenvox (StephenKeller) and
Digium (file) added an as-yet undocumented repair variable to solve
the problem. It was repaired and added to 1.4 on June 15th 2007, and
patches cleanly to other versions (it's only about 5 lines in
app_speech_utils.c)
You can now set a variable called "SPEECH_DTMF_MAXLEN" from within
the dialplan which indicates the maximum number if DTMF digits your
grammar is expecting. In our case, where menus were all
single-keypress to start with, we set the value to "1" and it returns
back the values immediately. I also created .gram files for
single-digit keypresses for both voice and DTMF, though I'm uncertain
if this is required now with this patch. Interestingly, if you
specify "2" as the length of digits, but your DTMF grammar only
indicates a single digit, the grammar is ignored and the number of
digits you enter with DTMF is returned. If you speak more than two
digits, the system acts properly according to the grammar and only
the first digit is returned. I've been told this is because Asterisk
is handling the DTMF (and is being instructed what to do with
SPEECH_DTMF_MAXLEN) and the voice recognition portion is using the
grammar.
Note: I've not been able to get "#" and "*" to work yet with the DTMF
signalling, but I've been talking with Lumenvox about if this is a
syntax problem with my attempts, or a deeper bug.
Examples below.
JT
[root@blah grammars]# more digit.gram
#ABNF 1.0 UTF-8;
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
