Hi,
 
In the process of upgrading our CVP version to CVP 8.x, we ran into a bargein issue with the IOS image: c5350-is-mz.151-2.T2.bin, as summarized below:
 
Our test consists of two simple VXML test pages as given in 1) and 2) below. The first page plays a TTS prompt (highlighted in blue) and navigates to the 2nd page, which contains a <field> element that plays a 2nd TTS prompt (highlighted in blue), listens for a boolean input, and when filled plays the result and loops back to the first page.
 
To simplify the communication, I'll refer to the two prompts (highlighted in blue) as "Prompt #1" and "Prompt #2".
 
When we tested 1) and 2) as is (i.e. by commenting out the "fetchaudio" property, as highlighted in red), barge in works as expected at BOTH prompts. Not only were we able to barge in on either Prompt #1 or Prompt #2, our bargein input (e.g. dtmf-1) was also buffered correctly till the next input state.
 
However, if we uncomment the "fetchaudio" property line, barge in no longer works with Prompt #1. (It only works with Prompt #2.) So, say I press dtmf-1 right after hearing TTS "First prompt", it will NOT stop Prompt #1 from playing, nor will my DTMF input be buffered.

We believe the bargein behavior detailed in the last paragraph is not per VXML 2.0 standards, with regards to "prompt quequeing" and "DTMF buffering". As the issue has a fairly extensive impact on our CVP applications, we need your feedback on the following:
 
a) Is this a bug or known issue with the 15.1(2)T2 IOS image?
b) Do you have a fix to this in a later image? If so, what is the image #?
 
Your earliest assistance much appreciated!
 
Thanks,
Rachel

----------------------------------------------
1) bargeinTest_page1.vxml:

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
<!-- <property name="fetchaudio" value="http://SomeServerName/audio/earcon.wav"/> -->
  <form id="start">
    <block>
      <prompt bargein="true">
          First prompt. Welcome to barge in test page 1.
      </prompt>
      <goto next="/Test/bargeinTest_page2.vxml"/>
    </block>
  </form>
</vxml>

2) bargeinTest_page2.vxml:
 
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
<form id="f1">  
    <field name="foundation_fld" type="boolean">   
      <prompt bargein="true">
           2nd prompt. Please say or enter your input.
      </prompt> 
      <catch event="nomatch">
        <prompt bargein="true">form no match</prompt>   
      </catch>    
      <catch event="noinput">
        <prompt bargein="true">form no input</prompt>
      </catch>     
      <filled>       
        You entered <value expr="foundation_fld"/>       
        <goto next="/Test/bargeinTest_page1.vxml"/>
      </filled>
    </field>
  </form>
</vxml>

Hi Raghavendra,

I never heard the fetchaudio as there was no latency in my tests. All i heard were the first and second prompts, and i was trying to barge in on the first.

Will send you the logs with the suggested debugs soon.

Thanks,
Rachel

Hi Rachel,

Please find below description about fetchaudio.
Fetchaudio summary

* All prompts queued prior to the fetchaudio will be played prior to the
fetchaudio.
* All prompts played before the fetchaudio are non-bargeable.
* Audio associated with fetchaudio is also non-bargeable.
* All prompts before the fetchaudio are guaranteed to be played to
completion, regardless of when the fetch finishes. See Known issues for
important information regarding this point.
* Audio associated with fetchaudio will be interrupted as soon as the
interpreter is ready to flush the next set of prompts from the queue.
* When a sequence of elements specify fetchaudio, the interpreter
interrupts the previous fetchaudio when it begins to process the next
element that has a fetchaudio attribute.

hope this helps!

Thanks,
Raghavendra

Hi Rachel,

Here is the snapshot from the following link http://www.cisco.com/en/US/docs/ios/voice/ivr/configuration/guide/ivrapp02.html for your reference.

VoiceXML Before Version 2.0 and Version 2.0 Behavior

The default VoiceXML behavior is compatible with versions earlier than W3C VoiceXML 2.0. You can enable W3C VoiceXML 2.0 behavior by entering the vxml version 2.0 command in global configuration mode. This command enables the following features:

¿An audio error event, error.badfetch, is not thrown when an audio file cannot be played, for instance, because the file is in an unsupported format, the src attribute references an invalid URI, or the expr attribute evaluates to an invalid URI.

¿Support for the beep attribute of the <record> element.

¿Blind transfer compliant with W3C VoiceXML 2.0 and not the same as consultation transfer.

¿A semantic error is generated if an undeclared variable is used. You must declare variables before using them.

Use the no vxml version 2.0 command to revert to the default behavior.

You can turn on the audio error feature only, which is compatible with versions earlier than W3C VoiceXML 2.0, by entering the vxml audioerror command in global configuration mode. Use the no vxml audioerror command to disable this feature. The vxml audioerror command overrides the vxml version 2.0 command, so that if both commands are entered, the audio error event will be thrown when an audio file cannot be played.

Thanks,
Anusha