Here is the following scenario. In the call studio, I have two menu element consecutively, e.g Menu_1 and Menu_2. The way suppose work is after user hear the Menu_1's menu, do the selection, then go to the Menu_2.
But some random hardware issue happens like when u press 1 on your phone, it becomes double press somehow, that means user didn't hear any voice for Menu_2, but the selection for Menu_2 already made.
Do we have any way to force user to hear the whole voice for menu first, then do the selection?
Yes, in the Audio tab of the Menu element, select the Audio Group named
Initial. Then in the middle of the window, you can de-select the
checkbox for Bargein.
This forces the caller to listen to the entire audio prompt before
pressing a touch tone.
I believe its horrible to force users to listen to entire menus, especially when they are repeat callers.
What you could do is between your two menus have a Digits number collect element with a silent wav file (use the CVP supplied .1 sec silent wav files) which would timeout after 1 second and proceed to Menu 2 if nothing entered.
This should effectively clear the buffer before menu 2.
I agree that it's nice for caller's not to listen to entire prompts.
But your solution will only clear the dtmf buffer if they also de-select
BargeIn on the audio group of the Digits element you suggest adding.
And they'd want to set the NoInputTimeout to 10ms - so the system plays
the audio and then doesn't delay for too long.
Or explicitly flush the buffer using the proprietary <cisco-typeaheadflush/> element as in the enhanced audio element I posted a while ago that did sync play, max-time and flushing.
Just FYI for anyone making use of the extended audio custom elements and not picking it up via Twitter, there's some modified versions posted that will work with VVB.
What's the difference between the 3 elements at the link you posted?
I've added a few notes in the Box folder for clarification.
There's source for 2 elements plus a JAR provided for convenience.
- Consolidated element with all extended features merged into it: sync play, buffer flush and maxtime.
- Element with just synchronous prompt playing feature. Clearly you could just use the all-features version but I included this one as well for anyone already using it and migrating to VVB, to avoid having to make any application changes.
Thx Paul, what's different about the vxml code for the VVB versus the
gateway based voice browser?
Pretty small fix to the dummy <object> element that's used to block until the prompt has played. Had to add a submit to the <object> block, otherwise the VVB exits and the session hangs.
So far this is the only thing I've come across although still very early days investigating the custom add-ons with VVB.
<submit next="/CVP/Server" method="post" namelist="audium_vxmlLog" />
<assign name="audium_vxmlLog" expr="''" />
<goto next="#sync" />
<object name="dummyobj" classid="builtin://com.cisco.callhandoff">
<param name="return" expr="true" valuetype="data" />
<param name="app-uri" expr="'builtin://dummyobj'" valuetype="data" />
<submit next="/CVP/Server" method="post" namelist="dummyobj audium_vxmlLog" />
That is current solution I have right now with my manager
That is the solution we are currently using. For all the menu, we have have a subflow(named silentSecond) to clear the extra value to make sure user each menu was played to the user. Also if it have audio element followed by a menu element, we add the silentSecond flow after the audio element, so user can skip that element, but he still can hear the menu selection before he selected