Cisco Cisco Customer Voice Portal 8.0(1)
Unified CVP Comprehensive Call Flows for Pre-Routed Calls
This class of call flows is similar to the Unified CVP Comprehensive call flow models, except
that calls are first introduced into Unified ICME or Unified ICMH using some path other than
through Unified CVP. A Unified ICME routing script is given the chance to "pre-route" such
calls before Unified CVP ever sees them. Once the script transfers the call to Unified CVP, for
either self-service or queuing, a more standard Unified CVP Comprehensive call flow model
is used.
that calls are first introduced into Unified ICME or Unified ICMH using some path other than
through Unified CVP. A Unified ICME routing script is given the chance to "pre-route" such
calls before Unified CVP ever sees them. Once the script transfers the call to Unified CVP, for
either self-service or queuing, a more standard Unified CVP Comprehensive call flow model
is used.
In this section we will discuss the following call flows:
•
•
•
•
. A VXML Server running as a Standalone with ICME
Lookup call flow model also falls into this category, if the goal of the ICM Lookup is to
transfer the call into a Unified CVP Comprehensive call flow model deployment.
transfer the call into a Unified CVP Comprehensive call flow model deployment.
All these call flows share the characteristic that the original routing client (a NIC, Unified CM,
an ACD, or a VRU) is capable of a single route request only. By definition, the routing client
makes a single request to Unified ICME, and Unified ICME returns a destination label and the
routing client affects the transfer. At that point the route request dialog is ended, and Unified
ICME has no ability to send a subsequent label or conduct any other form of third-party call
control.
an ACD, or a VRU) is capable of a single route request only. By definition, the routing client
makes a single request to Unified ICME, and Unified ICME returns a destination label and the
routing client affects the transfer. At that point the route request dialog is ended, and Unified
ICME has no ability to send a subsequent label or conduct any other form of third-party call
control.
The routing script might continue, however. This would be the case if the returned label was a
translation route to VRU label, or if it was a correlation ID label resulting from a SendToVRU
node. In those cases the call is transferred to Unified CVP, and the routing script continues
executing once Unified CVP successfully receives the call. The script then invokes
micro-application requests as part of its queuing or self service treatment. If the call will then
be transferred to an agent or skill group, that label must go to Unified CVP rather than to the
original routing client. If the call will later be blind-transferred to another agent or skill group,
or back into Unified CVP for additional queuing or self service, that label too must go to Unified
CVP rather than to the original routing client.
translation route to VRU label, or if it was a correlation ID label resulting from a SendToVRU
node. In those cases the call is transferred to Unified CVP, and the routing script continues
executing once Unified CVP successfully receives the call. The script then invokes
micro-application requests as part of its queuing or self service treatment. If the call will then
be transferred to an agent or skill group, that label must go to Unified CVP rather than to the
original routing client. If the call will later be blind-transferred to another agent or skill group,
or back into Unified CVP for additional queuing or self service, that label too must go to Unified
CVP rather than to the original routing client.
When the call is delivered to Unified CVP, in order for micro-applications to be supported, it
must establish both the Switch and the VRU leg. In short, it must enter a normal Unified CVP
Comprehensive call flow model. The only difference between the pre-routed case and a normal
Unified CVP Comprehensive call flow model case is in how the call first arrives at Unified
CVP. In the pre-routed case, it arrives using either a translation route or correlation-id transfer,
whereas in the more typical case it arrives as a new call from the PSTN. In either case, a
subsequent transfer to Unified CVP's VRU leg is required.
must establish both the Switch and the VRU leg. In short, it must enter a normal Unified CVP
Comprehensive call flow model. The only difference between the pre-routed case and a normal
Unified CVP Comprehensive call flow model case is in how the call first arrives at Unified
CVP. In the pre-routed case, it arrives using either a translation route or correlation-id transfer,
whereas in the more typical case it arrives as a new call from the PSTN. In either case, a
subsequent transfer to Unified CVP's VRU leg is required.
Configuration and Administration Guide for Cisco Unified Customer Voice Portal Release 8.0(1)
119
Chapter 2: High-level Configuration Instructions for Call Flow Models
Unified CVP Comprehensive Call Flows for Pre-Routed Calls