These properties worked fine with a VXMLGW integration for over 6 years but we recently upgraded to CVP 12.5 with VVB and now the properties are causing session timeouts to be generated when a caller disconnects during a fetch. Seems VVB wants to fetch the fetchaudio wave file upon the disconnect and the disconnect event doesn't get sent back to the VXML Server. TAC and the BU have indicated the fetch* are not supported in the VXML root document with a VVB integration although it is not documented anywhere. Has anyone else seen this issue? Any suggestions on the best way to set the fetch* properties within the application?
With VVB I've definitely noticed weird things with fetchaudio property. For example, if you DON"T include it in a voice element before a slow rest lookup, then the VVB doesn't play anything to the caller (like, "please hold while we look up your account") until the app is waiting for the next caller input! Putting the fetchaudio property into an Audio element just before the REST (or any slow step) fixes that bug.
I've also noticed that having fetchaudio in the root document, makes the VVB not allow barge-in until the element that collects input is executing (so caller can't barge in during an Audio element, just the Digits or Form element).
You will need to set the fetching properties in the Settings tab of an Audio element that comes just before the rest lookup (or whatever set of slow steps you have in the app). At the bottom of the Audio element's Settings tab, you'll see VoiceXML Properties. Just enter the names and values there.
They'll only be in effect until the next voice element (square shape) executes. Each time you do another slow lookup, you will set it again there.
Thanks, Janine! I've taken several of your CVP classes and you're always on point! We will have to do some trial and error testing with these properties as we have about 20 self-service applications with numerous backend web and rest services. This will be a huge work effort to do it for every service call.
TAC indicated a defect will be opened for the development team to decide if it will be resolved in the next ES patch as it did appear to be an issue with the voice browser. However, my case had been the only instance so not sure what priority it will get.