Cisco Cisco Unified Customer Voice Portal 10.0(1) Release Notes

If ISN 2.0 Hotfix 1 has already been applied, or if you are using the Advanced Speech deployment 
model, you do not need to do anything else.

The following information should only be used by customers that are using the CVP as a type 3 VRU 
with an ICM NIC.

Symptoms: ICM timeout errors are logged for each call that is successfully transferred or released 
following a “Run VRU Script” node result.

Conditions: ISN is used as a type 3 VRU with a NIC as the routing client in the release 2.0 “Queue and 
Transfer” deployment model. This results in benign errors in the logs for each call that is successfully 
transferred or released following a “Run VRU script” result.

Solution: This fix provides a capability that should only be used by customers that are using the ISN as 
a type 3 VRU with a NIC, and is turned off by default. It allows the ISN Voice Browser to send a 
Disconnect message to the Application Server after the inbound call goes away, instead of a retry. A 
timeout parameter change is needed on the VoiceBrowser. To change the parameter, run VBAdmin on 
the VoiceBrowser and type:

 SetAppServerTimeout  <value, default=7>, where the new value is 1 second less than the value 
specified in the Application Server's "AppAdmin->Engine->EngineConfiguration->ICM Timeout”.

If you are using all default timeouts, this “ICM Timeout” parameter is 4 seconds, so you would then 
type in VBAdmin:

 SetAppServerTimeout 3

With the fix configured properly, the call can be seen going away at the Application Server without any 
errors in the log files, after the timeout period configured in the Voice Browser. 

You may see a problem where the CVP VXML Server call log shows application duration of 0 seconds, 
or shorter than expected.

This may occur when one CVP VXML application uses the Application Transfer element to call a second 
VXML application, and the Application Transfer element is preceded by an Audio element.

You may want to add an explicit input element just prior to the Application Transfer element, if it is 
important that all prompts finish playing before the second application begins.

The VoiceXML specification indicates that queued prompts are not to begin playing until the next wait 
state, which in most cases means the next input element or subdialog_return element. An Application 
Transfer element does not constitute a wait state, so prompts queued in the first application will not begin 
playing, and therefore will not be accounted for in the first application's duration statistics, until a wait 
state is encountered in the second application. 

By design, prompts will not begin to be played until the first input state or subdialiog_return is 
encountered. Since your first application did not have any input states, the prompt got queued but didn't 
begin playing until the first application had already ended and the second application had already started. 
Therefore, all the duration will be spent in the second application.

There are no known caveats in CVP 3.0.