support: Here is a slightly modified version. The difference is in how precise the timing are calculated, and it is possible to "sneak" a digit despite a 10ms interdigittimeout. You will have to enable one of our newer features that forces grammars that specify a length to terminate once that length has been reached. So in this case with a type of digits?length=1, the system will stop listening for dtmf input after the first digit without exception. This feature is off by default because it breaks previous systems that request a # termination while still setting digits?length=n.
Code: Select all
<?xml version='1.0'?>
<vxml version="2.0">
<var name="startTime"/>
<var name="endTime"/>
<var name="elapsedTime"/>
<form id="replay">
<property name="interdigittimeout" value="10ms"/>
<property name="termmaxdigits" value="true"/>
<block>
<audio src="http://banfield/~mjones/qa/plumvp/prompts/audio/internet.wav"/>
<assign name="startTime" expr="(new Date()).getTime()"/>
</block>
<field name='pressed' type="digits?length=1">
<filled>
<assign name="endTime" expr="(new Date()).getTime()"/>
<assign name="elapsedTime" expr="Math.round((endTime - startTime)/1000)"/>
at <value expr="elapsedTime"/> seconds
<if cond="pressed==4">Jump Back
<elseif cond="pressed==6"/>Jump Ahead
<elseif cond="pressed==8"/>Insert
<elseif cond="pressed==0"/>Menu
<else/>No Action
</if>
<goto nextitem="catchall"/>
</filled>
<catch event="nomatch noinput">
<goto next="#replay"/>
</catch>
</field>
<!-- this catchall prevents queuing of #replay -->
<property name="timeout" value="10ms"/>
<field name="catchall" type="digits">
<filled>
<goto next="#replay"/>
</filled>
<catch event="nomatch noinput">
<goto next="#replay"/>
</catch>
</field>
</form>
</vxml>
I copy/pasted the code below and changed only the audio src file. The problem actually seems more prevalent now - in 24 calls the problem manifested itself consistently every call w/i 3 button presses, many times on the first; previously it seemed less consistent. On my audio, I'm waiting about 3 seconds each time before I press.
Is the new feature on the murrow machine (or whichever is serving the 617.712.3548 number)? This no doubt worked fine on an internal support machine, but does not seem to have an effect on the production machine.
Thanks,
Thom