Question regarding DTMF buffering during fetchaudio

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Question regarding DTMF buffering during fetchaudio

Debasmita Bal
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
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding DTMF buffering during fetchaudio

Ian Sutherland

One person's opinion, but it looks like the first highlighted passage refers to transitions between input items, which (at least usually, in my experience) doesn't involve fetching a resource, and wouldn't have fetchaudio.

On 18-Nov-13 04:57, Debasmita Bal wrote:
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
 
 


ian_sutherland.vcf (290 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Question regarding DTMF buffering during fetchaudio

Michael Bodell-2

Fetchaudio processing can get very complex.  The second text block, if I remember correctly, is trying to express that there is no active listening going on (I.e., we are not listening to a “cancel” that would stop the fetch – a feature request for some).  DTMF should be buffered and that buffer should only be thrown out by doing a reco (using the buffer) or by playing a non bargeable prompt (which empties the buffered dtmf text).  Playing fetchaudio should not empty the buffer.  That said, the specification of DTMF buffering is at times vague, and given it is a SHOULD and not a MUST platforms likely would be able to not buffer at other times (or even not buffer at all) if they wished (I.e., have a limit to how far back in time you accept DTMF input [makes sense to me], decide if a speech ASR discards the dtmf buffer [I’d say it should], and/or decide if fetchaudio also clears the DTMF buffer [I’d say it shouldn’t] – but on all of them your mileage might vary).

 

There are other peculiarities with fetchaudio too, like when does the fetchaudio stop playing?  The most natural sounding to a user [and only thing sensible IMO] is only when the next audio (be it normal listen state, next fetchaudio, prompts before the next fetchaudio, or terminal audio [audio as the call is ending] – essentially the 4 different ways you could next have audio that should be not just queued but played) is ready to be played.  The spec says to stop playing the fetchaudio once the resource is “retrieved”, even if you’d then have “dead air” for several seconds while the parsing and/or processing and executing of the transition time continues.  And if you’d have a second slow fetch you could put a second fetchaudio, but then you might have a choppy fetchaudio experience (it would be cleaner to have the first slow fetch have an audio that plays until the next listen state is ready with the second slow fetch have no fetchaudio).  Of course the specification isn’t precise in what constitutes “retrieving” a document, especially when you can further change things with caching of documents and potential prefetching of resources.

 

And to Ian’s point the first text definitely includes loading documents and transitioning between dialogs (which are all done in the “transitioning” state).  That is the same delineation of state that governs post-processing which certainly can load documents and transition between dialogs (but which ends when the interpreter would enter a waiting for input state).  Also, with VXML 2.1 even inside a dialog transitioning between input states one might well have a fetchaudio on a data element (like in the executable content of an event handler).

 

 

From: Ian Sutherland [mailto:[hidden email]]
Sent: Monday, November 18, 2013 10:04 AM
To: Debasmita Bal
Cc: [hidden email]
Subject: Re: Question regarding DTMF buffering during fetchaudio

 

One person's opinion, but it looks like the first highlighted passage refers to transitions between input items, which (at least usually, in my experience) doesn't involve fetching a resource, and wouldn't have fetchaudio.

On 18-Nov-13 04:57, Debasmita Bal wrote:

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

 

 

 

Reply | Threaded
Open this post in threaded view
|

RE: Question regarding DTMF buffering during fetchaudio

DOLECEK Ales-2
In reply to this post by Debasmita Bal

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 <a href="file:///C:\Users\adolecek\Documents\Manual\W3C\Voice%20Extensible%20Markup%20Language%20%28VoiceXML%29%20Version%202.0.html#dml4.1.5">Section 4.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:[hidden email]]
Sent: Monday, November 18, 2013 11:57 AM
To: [hidden email]
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