RE: Question regarding DTMF buffering during fetchaudio

You cite the second text out of context - it specifies handling of barge-in:

While in the transitioning state various prompts are queued, either by the <prompt> element in executable content or by the <prompt> element in form items. In addition, audio may be queued by the fetchaudio attribute. The queued prompts and audio are played either

 *   when the interpreter reaches the waiting state, at which point the prompts are played and the interpreter listens for input that matches one of the active grammars, or
 *   when the interpreter begins fetching a resource (such as a document) for which fetchaudio was specified. In this case the prompts queued before the fetchaudio are played to completion, and then, if the resource actually needs to be fetched (i.e. it is not unexpired in the cache), the fetchaudio is played until the fetch completes. The interpreter remains in the transitioning state and no input is accepted during the fetch.

Note that when a prompt's bargein attribute is false, input is not collected and DTMF input buffered in a transition state is deleted (see Section 4.1.5<file:///C:\Users\adolecek\Documents\Manual\W3C\Voice%20Extensible%20Markup%20Language%20%28VoiceXML%29%20Version%202.0.html#dml4.1.5>).
So in reality the input IS "collected and buffered", but the buffer is cleared once the transition is done - effectively leading to "no input is accepted during fetch". But this is only for the case with fetchaudio. The interpreter thus should behave differently if fetching with/without fetchaudio. And the difference is only for input (DTMF or speech) not asynchronous events (like connection.disconnect.hangup).

First text you cite describes behavior in general - for both input and asynchronous events. Second describes behavior of in case of transition with "fetchaudio" and only for input.

Ales

From: Debasmita Bal [mailto:Debasmita.Bal@genesyslab.com]
Sent: Monday, November 18, 2013 11:57 AM
To: www-voice@w3.org
Subject: Question regarding DTMF buffering during fetchaudio

We have a question regarding whether DTMF should be buffered during a transition with a fetchaudio.

There are two sections in the VXML specs, one which indicates that DTMF should be buffered while the other indicates that the DTMF should be rejected.


The following suggests that DTMF should be buffered

A VoiceXML interpreter is at all times in one of two states:
*        waiting for input in an input item (such as <field>, <record>, or <transfer>), or
*        transitioning between input items in response to an input (including spoken utterances, dtmf key presses, and input-related events such as a noinput or nomatch event) received while in the waiting state. While in the transitioning state no speech input is collected, accepted or interpreted. Consequently root and document level speech grammars (such as defined in <link>s) may not be active at all times. However, DTMF input (including timing information) should be collected and buffered in the transition state. Similarly, asynchronously generated events not related directly to execution of the transition should also be buffered until the waiting state (e.g. connection.disconnect.hangup)
The following suggests that DTMF should NOT be buffered

*        when the interpreter begins fetching a resource (such as a document) for which fetchaudio was specified. In this case the prompts queued before the fetchaudio are played to completion, and then, if the resource actually needs to be fetched (i.e. it is not unexpired in the cache), the fetchaudio is played until the fetch completes. The interpreter remains in the transitioning state and no input is accepted during the fetch.
Can you please clarify?

Thanks,
Debasmita