Prevent IVR/VXML speech recognizer timeouts with long pre-recognition audio?

Question

A portion of my VXML/GRXML IVR app plays 2-3 minutes of audio and then runs a customcontext Nuance OSDM via a <subdialog>, afterwards, as a menu.

This causes a timeout error on the recognizer, as the OSDM is listening for the 2-3 minutes of prompts, rather than starting to listen only after the prompts have concluded.

I remember fixing a similar issue quite some time ago, but can't remember how I fixed it.

Is there a VXML or OSDM property for fetching or timeout that I can use to "force" the recognizer to wait until the OSDM prompts, themselves, start playing?

Answer 1

In VoiceXML, prompts are not really played when the prompt element is executed, they are rather queued.

The prompts in the queue will be played only

1. when the interpreter reaches a waiting state (e.g. recognition), or
2. when the interpreter fetches a resource while a fetchaudio attribute is set on the corresponding fetch element.

More details in the VoiceXML 2.0 spec, 4.1.8 Prompt Queueing and Input Collection

As you see, there's no VoiceXML directive that you can use to explicitly flush the prompt queue. The trick is to specify a fetchaudio somewhere in order to satisfy #2.

So I would suggest that you force the prompt queue to be played by specifying a fetchaudio attribute on the subdialog element. Since you don't really want to hear the fetchaudio, it can be a 10ms silence audio file.

<block>
   <prompt>
     <audio src="audio/very_long_message.wav">
   </prompt>
</block>

<subdialog src="osdm/custom" fetchaudio="audio/10ms_silence.wav"/>
   ...
</subdialog>

Note that the user won't be able to barge-in during the long prefix prompt but will be able to do so in the OSDM subdialog.

Answer 2

Given you've stated you're using Nuance and OSDM, I'm going to answer for Nuance Recognizer 9 and Nuance Speech Server.

This normally happens because when the recognizer doesn't receive any requests for a period of time, it thinks the call is over and deletes the session.

There is configuration in NSSserver.cfg (The Nuance Speech Server config):

server.mrcp1.rtsp.sessionTimeout  VXIInteger  60000
or
server.mrcp2.rtsp.sessionTimeout  VXIInteger  60000

I believe there would be a trade-off for this. While you could double or triple this value, it may mean that your speech license would be tied up for longer after the call is ended. I guess the value you choose depends on your load, length of the prompt, and how often you see this.

While we still get the occasional one, normally when the caller is using DTMF, we've minimised the instances significantly.