Cisco Cisco Unified Customer Voice Portal 10.5(1) Release Notes
10
Release Notes for Cisco Customer Voice Portal, Release 3.0(0) Updated 6/24/05
CVP 3.0 Considerations
ASR/TTS Server Redundancy for Cisco CVP VXML Server Applications
The CVP 3.0 VoiceXML Server does not support backups for ASR/TTS servers. CVP VoiceXML Server
applications rely on the gateway’s configured default for ASR and TTS servers, which allow only a
single host name or IP address to be specified for each. This differs from the CVP micro-applications
based applications, which support automatic retries to specifically named backup ASR and TTS servers.
Refer to the CVP Configuration and Administration Guide for more information.
applications rely on the gateway’s configured default for ASR and TTS servers, which allow only a
single host name or IP address to be specified for each. This differs from the CVP micro-applications
based applications, which support automatic retries to specifically named backup ASR and TTS servers.
Refer to the CVP Configuration and Administration Guide for more information.
Using barge-in with Record
For any VXML used with the Cisco Gateway, prompts which precede a Record can only be barged-in
with DTMF, not with voice.
with DTMF, not with voice.
Bridged Transfers are not supported in Standalone CVP VoiceXML Server
In Standalone CVP mode, blind transfers are the only type of transfers that are supported. Script writers
will need to select "Bridge=false" on the settings tab of the transfer element. This is not enabled by
default.
will need to select "Bridge=false" on the settings tab of the transfer element. This is not enabled by
default.
In the Full CVP Solution with ICM, the transfer element in the CVP Builder Studio is not supported.
Bridged and Blind transfers are performed using the ICM Script Editor."
Bridged and Blind transfers are performed using the ICM Script Editor."
Voice Barge-In with Audio Element with CVP Voice XML Server
Voice barge-in with CVP Voice XML Server is supported, but only when prompts are followed by an
input element which allows voice input. If the input element only allows DTMF input, then only DTMF
can barge in to the prompts which precede it.
input element which allows voice input. If the input element only allows DTMF input, then only DTMF
can barge in to the prompts which precede it.
The VoiceXML specification does not provide a way to indicate whether barge-in with voice , or barge-in
with DTMF, or both, should be allowed. The rule is that whatever kind of input is allowed in the
subsequent blocking element is the kind of input that can cause a barge-in. For example, prompt that
allow bargein which precede an input element in which both voice and DTMF input are allowed can be
interrupted by either voice or DTMF. But if the input element only allows voice, then only voice will be
able to interrupt its prompts. There are some caveats to this rule, however. If the blocking state is caused
by a Record element, then only DTMF will be able to interrupt its prompts. The ability to interrupt
prompts ahead of a Record element using voice is a very complicated subject. In some implementations
the prompt will only be interrupted if an actual voice grammar is matched. In any case, this is an optional
feature in VoiceXML 2.0 and is not supported by the IOS voice browser. The other significant caveat
comes into play when the blocking state is caused by a Transfer element. A Transfer element is not
actually an input state; it contains no grammar definition, and more to the point, does not contain a way
to indicate whether input with voice or DTMF should be accepted. The IOS voice browser avoids using
ASR resources in this case, and only allows bargeinable prompts ahead of a Transfer element to be
interrupted using DTMF.
with DTMF, or both, should be allowed. The rule is that whatever kind of input is allowed in the
subsequent blocking element is the kind of input that can cause a barge-in. For example, prompt that
allow bargein which precede an input element in which both voice and DTMF input are allowed can be
interrupted by either voice or DTMF. But if the input element only allows voice, then only voice will be
able to interrupt its prompts. There are some caveats to this rule, however. If the blocking state is caused
by a Record element, then only DTMF will be able to interrupt its prompts. The ability to interrupt
prompts ahead of a Record element using voice is a very complicated subject. In some implementations
the prompt will only be interrupted if an actual voice grammar is matched. In any case, this is an optional
feature in VoiceXML 2.0 and is not supported by the IOS voice browser. The other significant caveat
comes into play when the blocking state is caused by a Transfer element. A Transfer element is not
actually an input state; it contains no grammar definition, and more to the point, does not contain a way
to indicate whether input with voice or DTMF should be accepted. The IOS voice browser avoids using
ASR resources in this case, and only allows bargeinable prompts ahead of a Transfer element to be
interrupted using DTMF.
ICM timeout errors
If this CVP Application Server or Voice Browser is being upgraded from ISN 2.0 directly to CVP 3.0
using the upgrade program, you may experience ICM timeout errors. Read this section if you are
experiencing this problem.
using the upgrade program, you may experience ICM timeout errors. Read this section if you are
experiencing this problem.