cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays

why does the Audio element seem to generate request for input?

41
Views
0
Helpful
0
Comments
This document was generated from CDN thread

Created by: null on 28-09-2004 07:33:21 AM
HelloWorld generates the output below (extract only). The app does behave correctly in that it just speaks a vocab and hangs up, but why the VoiceXML entries that appear to be asking for input from the caller?

<property name="inputmodes" value="dtmf voice" />
<property name="timeout" value="15ms" />
  • <grammar mode="dtmf" type="application/x-gsl">
  • <![CDATA[ 
]]>
</grammar>

Thanks in advance.

Subject: RE: why does the Audio element seem to generate request for input?
Replied by: null on 28-09-2004 10:27:52 PM
Ok, so this was added to the Audio element to support one thing: bargein. In the Builder, you have the option to turn bargein on or off for each audio group. The problem is that most voice browsers require an input in order to allow bargein to an audio group. Without it, that audio will not allow bargein. As a result, we placed this "fake" DTMF grammar to provide that input. No matter what happens we simply go onwards to the next element.

Now, this actually causes some problems and in Call Services (the next version of Audium), we actually got rid of this behavior. That is because most browsers (Holly included), do what is called "pre-fetching". They are smart enough to realize that there is a page that contains just audio and no input, so it prefetches the page that follows that one to see if the following page has an input. It will continue to prefetch pages until it finds one with an input. It will then allow you to barge into ALL the audio that is found on ALL the pages that came before the page with the input. That resolves the problem we were trying to fix with this bargein hack. The one issue that this hack also presents is that if the caller tries to bargein to a page that has only audio, that DTMF fake input will "swallow" the first utterance. So for example, if someone was entering in their account numebr as "one two three", and they said this in an Audio element followed by a Digits element, the digits element will capture the account number as "two three" because the "one" was used for the bargein. That was the reason why we eliminated it in Call Services.

Now, in Audium 3.3, its pretty easy to make an Audio element that does not do this, and we can provide anyone with this element should they need it with Call Services.

One more note on pre-fetching. Sometimes, pre-fetching can cause problems, especially when used with Audium. Since Audium dynamically produces each VoiceXML page, if there is any time-sensitive content in the page, it will not be accurate if the browser prefetched it. So you will notice that if you use Call Services, or you used an Audio element that did not have the bargein hack in Audium 3.3, the logs created may look like two elements occurred at the same time, and that is because the browser requested a page, saw that it contained only audio, then requested the next page all within a few microseconds, making the Audium logs look like the caller blew threw the Audio element when they did not. Prefetching will not cause crashes, but it just may make things innacurate. So in certain situations, you may actually want to use the only Audio element!

Hope this clarifies things.
Content for Community-Ad