Design Guide for Cisco Unified Customer Voice Portal, Release 11.0(1)
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter
describes the functional deployment models with the customer requirements, the
required and optional components, and a step-by-step call flow. To deploy each
model, all of the components should be located in a single site.
The VXML
Server (standalone) functional deployment model provides organizations with a
standalone IVR solution for automated self-service. Callers can access Unified
CVP from a local, long-distance, or toll-free numbers that terminate at Unified
CVP Ingress Voice Gateways. Callers can also access Unified CVP from VoIP
endpoints number that terminates at Unified CVP Ingress Voice Gateways. Callers
can also access Unified CVP from VoIP endpoints. The following figure
illustrates this model.
This model includes
the following optional components:
Ingress Voice
Gateway
VoiceXML Gateway
VXML Server
Unified Call
Studio
Operations
Console Server
Following are the
optional components of this model:
Automatic Speech
Recognition/Text-to-Speech (ASR/TTS) Server
Third-Party
Media Server
Application
Control Engine (ACE)
Egress Voice
Gateway
Reporting
Server
Protocol-Level
Call Flow
A call arrives
at the Ingress
VoiceXML Gateway
through TDM or SIP. The gateway performs inbound Plain Old Telephone Service
(POTS) or VoIP dial-peer matching.
Note
Ingress Voice
Gateway and VoiceXML Gateway deployment can either be separate entities or
co-located (using IOS VoiceXML Gateway). The self-service application is
invoked on VoiceXML Gateway.
The selected
VoiceXML Gateway port invokes the Unified CVP self-service
script.
The
self-service script invokes the
Unified CVP standalone bootstrap VoiceXML document, which sends an HTTP request
to the configured IP address of the VXML Server.
The
VXML service function, which resides in the CVP Server, runs the application
that is specified in the HTTP URL and returns a dynamically generated VoiceXML
document to the VoiceXML Gateway. The Unified CVP VXML Service may access
back-end systems to incorporate personalized data into the VoiceXML document
that is sent to the VoiceXML gateway.
The VoiceXML
Gateway parses and renders the VoiceXML document. For spoken output, the
VoiceXML Gateway either retrieves and plays back prerecorded audio files that
are referenced in the VoiceXML document, or it streams media from a
text-to-speech (TTS) server.
DTMF is detected on
VoiceXML Gateway.
The VoiceXML
Gateway submits an HTTP request containing the results of the caller input to
the VXML Server. This server runs the application that is specified in the HTTP
URL again and returns a dynamically generated VoiceXML document to the VoiceXML
Gateway. The dialog continues through repetition of Steps 5 and 6.
The IVR dialog
ends when the caller hangs up, the application releases, or the application
initiates a transfer.
Transfers and
Subsequent Call Control
You can use
the VXML Server (Standalone) functional deployment to transfer callers to
another endpoint. Transfers to either VoIP (for example, Cisco Unified
Communications Manager) or TDM (for example, Egress Voice Gateway to PSTN or
TDM ACD). IVR application data cannot be passed to the new endpoint with this
deployment model. If the endpoint is a TDM ACD, the agent screen popup window
does not appear.
This model
supports the following call transfers:
VoiceXML Bridged
Transfer
VoiceXML Blind
Transfer
Release Trunk
Transfer (TNT, hookflash, TBCT, and SIP Refer)
The Call
Director functional deployment model provides an organization with a method to
route and transfer calls across a VoIP network. For example, organizations can
use this model with multiple TDM ACD and TDM IVR locations that are integrated
with Unified ICM through an ACD or IVR Peripheral Gateway. The organization
wants to use the Cisco Unified Intelligent Contact Management (Unified ICM) to
route and transfer calls intelligently across these locations without using
PSTN prerouting or Release Trunk Transfer services. In this model, Unified CVP
and Unified ICM can also pass call data between these ACD and IVR locations. In
this model, Unified ICM can also provide beginning-to-end reporting for all
calls.
The Call
Director model is often the first step in the migration from a TDM-based
contact center to a VoIP-based contact center. When an organization is ready to
implement CVP-based IVR services and Cisco Unified Contact Center Enterprise
(Unified CCE), the organization can migrate their Unified CVP deployment to the
Comprehensive functional deployment model.
Callers can
access Unified CVP from local, long-distance, or toll-free numbers that
terminate at Unified CVP Ingress Voice Gateways. Callers can also access
Unified CVP from VoIP endpoints.
Following are the
required components of this model:
Ingress Voice
Gateway
Egress Voice
Gateway
CVP Server
Operations
Console Server
Cisco Unified
ICM Enterprise
SIP Proxy Server
(for SIP deployments)
The reporting server
is an optional component of this model because there is very little call
information stored in the Unified CVP reporting database.
SIP-Level Call
Flow
VoIP-Based Prerouting
A call arrives
at the Ingress
Voice Gateway and
sends a SIP INVITE/SIP/SIP message to the SIP Proxy Server, which forwards the
request to the CVP Server SIP Service.
The SIP Service
sends a route request to Unified ICM using the CVP Server ICM Service and the
VRU Peripheral Gateway. This route request invokes Unified ICM to run a routing
script based on the dialed number and other criteria.
The Unified ICM
routing script selects a target and returns a translation route label to the
CVP Server SIP Service. The Server SIP Service then signals through the SIP
Proxy Server to the Egress Voice Gateway (which connects to the TDM termination
point) and the Ingress Voice Gateway to enable the call to be set up between
the Ingress and Egress Voice Gateways. While the RTP stream flows directly
between the Ingress and Egress Voice Gateways, call control signaling flows
through Unified CVP to allow subsequent call control.
When the call
arrives at the selected termination, the termination equipment sends a request
to its Peripheral Gateway for routing instructions. This step resolves the
translation route and allows any call data from the previous Unified ICM script
to be passed to the selected termination. If the selected termination is a TDM
IVR platform, self-service is provided and the caller can either release or
request to be transferred to a live agent. If the selected termination is a TDM
ACD platform, then the caller is queued until an available agent is selected by
the TDM ACD. Call data can then be displayed on the agent screen. After
receiving live assistance, the caller can either release or request to be
transferred to another agent.
VoIP-Based Transfer
Regardless of
whether the call is initially routed to a TDM IVR or ACD location, a caller can
request a call to be transferred to another location. When the transfer occurs,
the TDM IVR or ACD sends a postroute request with call data (with its
Peripheral Gateway) to Unified ICM.
When Unified ICM
receives this postroute request, it runs a routing script based on the transfer
dialed number and other criteria. The Unified ICM routing script selects a new
target for the call and then signals to the CVP Server SIP Service to release
the call leg to the originally selected termination and to extend the call to a
new termination.
When the call
arrives at the new termination, the termination equipment sends a request to
its PG for routing instructions. This step resolves a translation route that is
allocated for this call to this new termination location, and it allows any
call data from the previous location (IVR port or agent) to be passed to the
new termination. Calls can continue to be transferred between locations using
this same VoIP-based transfer call flow.
Transfers and
Subsequent Call Control
In
addition to transfers that are manager by Unified ICM, the Comprehensive
deployment model can transfer calls to non-ICM terminations or invoke a Release
Trunk Transfer in the PSTN. If a call is transferred to a non-ICM termination,
no call data can be passed to the termination and no further call control is
possible for that call. The call reporting that Unified ICM captures is
completed. In the case of a Release Trunk Transfer, the Ingress Voice Gateway
port is released, no call data can be passed to the termination, and no further
call control is possible for that call. If the Release Trunk Transfer is
translation routed to another ICM peripheral, call data and reporting can be
maintained. For more information about Call Transfer, see
Call Transfer Options.
Call Server cancels
the transfer request and sends a transfer failure indication to Unified ICM.
Following are the reasons for it:
A selected termination
(for either a new or transferred call) returns a connection failure or busy
status.
The destination phone rings
until it exceeds the ring-no-answer (RNA) timeout setting of Call Server.
These
scenario causes a Router Requery operation. The Unified ICM routing script
recovers control and selects a different target or takes other remedial action.
Comprehensive
The
Comprehensive functional deployment model provides organizations with a method
to route and transfer calls across a VoIP network, to offer IVR services, and
to queue calls before they are routed to a selected agent. The most common
usage scenario for this functional deployment model is when organizations want
a pure IP-based contact center. Callers are provided IVR services initially and
then upon request are provided queue treatment and are transferred to a
selected Unified CCE agent. On request callers can also be transferred between
Unified CCE agents. In this model, Unified CVP and Unified ICM pass call data
between these endpoints and provide reporting for all calls. The following
figure illustrates this model.
This model has the
following features:
Allows callers to access
Unified CVP through local, long distance, or toll-free numbers terminating at
the Unified CVP ingress voice gateways, and from VoIP endpoints.
Provides the capabilities
of the VXML Server (Standalone) and Call Director functional deployment models
Provides the ability to
route and queue calls to UCCE agents.
Can utilize SIP.
Following are the
required components of this model:
Ingress Voice
Gateway
VoiceXML Gateway
CVP Server
Unified Call
Studio
SIP Proxy Server
(for SIP deployments)
Following are the
optional components of this model:
Automatic
Speech Recognition/Text-to-Speech (ASR/TTS) Server
Third-Party
Media Server
Supported Load
Balancers
Egress Voice
Gateway
Reporting
Server
SIP-Level Call
Flow
Initial Call Treatment and
Self-Service
A call arrives
at the Ingress
Voice Gateway and
sends a SIP invite message to the SIP Proxy Server, which forwards the request
to the Unified CVP Server SIP service.
The SIP service
sends a route request to Unified ICM through the Unified CVP Server ICM service
and the VRU Peripheral Gateway. This route request invokes Cisco Unified ICM to
run a routing script based on the dialed number and other criteria.
The Unified ICM
routing script utilizes a Send to VRU node to return a label to the SIP service
and send a call to a VoiceXML Gateway. The Unified CVP Server SIP service sends
an invite message to the VoiceXML Gateway using the SIP Proxy Server, which
translates the label DN to the IP address of the VoiceXML Gateway.
The Voice XML
Gateway sends an HTTP new call message to the VXML Server IVR Service with the
label DN provided by Unified ICM. The IVR service then sends a route request
message to Unified ICM (using the Unified ICM service), which then allows
Unified ICM to re-enter the previously started routing script. You should
reenter the routing script at the successful exit path of the Send to VRU node.
The Unified ICM routing script uses Run Script nodes to instruct the IVR
service about the desired call treatment. If call treatment requires complex
IVR self-services, service control can be redirected to a VXML Server
application. Upon completion of the VXML Server application or a request by the
caller to transfer to a live agent, service control is returned to the VXML
Server IVR service. The initial call treatment is simple by using few prompts,
then the IVR service can utilize Unified CVP microapplications to generate
VoiceXML documents for the VoiceXML Gateway. VXML Server is not required.
Caller Requests to Transfer
to Live Agent
When the caller requests to transfer to a live agent, the Unified ICM routing script queues the caller for an appropriate
skill group and sends RunExternalScript messages to the IVR Service to have queue treatment provided (assuming that no agent
is available).
When a Unified
CCE agent becomes available, Unified ICM requests the Unified CVP Server SIP
service to transfer the call to selected agent.
The SIP service
transfers the caller to the dialed number of the selected agent. The SIP
service sends a SIP INVITE/SIP message to the SIP Proxy Server, which finds the
Unified CM SIP Trunk IP address associated with this agent DN and then forwards
the SIP INVITE/SIP message to Unified Communications Manager.
Unified
Communications Manager accepts the incoming SIP Trunk call and routes it to the
selected agent.
Caller Requests to be
Transferred to a Second Skill Group
If the caller
requests to be transferred to a second agent, then the first agent initiates a
transfer from the Unified CCE agent desktop application. This action generates
a route request from the agent Peripheral Gateway to the Unified ICM central
controller. Unified ICM executes a routing script that queues the call to
another skill group. Assuming that no agent is available, the Unified ICM
script uses the Send to VRU node, which signals to the SIP service to release
the call leg to the Unified CM SIP Trunk and connect the call back to a
VoiceXML Gateway.
The VoiceXML Gateway sends an HTTP new call request to the VXML server, which forwards that request to Unified ICM to allow
the routing script to be reentered at the exit of the Send to VRU node. The Unified ICM sends RunExternalScript messages
to the VXML server to allow queue treatment to be provided to the caller while the caller waits for a second agent.
When a second
Unified CCE agent becomes available, Unified ICM requests the Unified CVP
Server SIP service to transfer the call to the selected agent.
The SIP service
transfers the caller to the dialed number of the selected agent. The SIP
Service sends a SIP INVITE/SIP message to the SIP Proxy Server, which finds the
Unified CM SIP Trunk IP address associated with the second agent DN and then
forwards the SIP INVITE/SIP message to Unified Communication Manager.
Unified Communication Manager accepts the incoming SIP trunk
call and routes it to the second agent.
Transfers and
Subsequent Call Control
In addition
to the transfers managed by Unified ICM, the Call Director deployment model can
transfer calls to non-ICM terminations or invoke a Release Trunk Transfer in
the PSTN. If a call is transferred to a non-ICM termination, then no call data
can be passed to the termination; no further call control is possible for that
call; and the cradle-to-grave call reporting, that Unified ICM captures, is
completed. In the case of a Release Trunk Transfer, the Ingress Voice Gateway
port is released; no call data can be passed to the termination; and no further
call control is possible for that call. If the Release Trunk Transfer is
translation-routed to another ICM peripheral, call data and cradle-to-grave
reporting can be maintained. For information on call transfers, see
Call Transfer Options.
Call Server cancels
the transfer request and sends a transfer failure indication to Unified ICM.
Following are the reasons for it:
A selected termination
(for either a new or transferred call) returns a connection failure or busy
status.
The destination phone rings
until it exceeds the ring-no-answer (RNA) timeout setting of Call Server.
These
scenario invokes the Router Requery operation. The Unified ICM routing script
then recovers control and selects a different target or takes a remedial
action.
VRU-Only
The VRU-Only functional
deployment model provides self-service applications and queueing treatment for
organizations that use advanced PSTN switching services that are controlled
using a Cisco Unified ICM PSTN Network Interface Controller (NIC). Two Unified
ICM PSTN NICs allow subsequent call control of calls in the PSTN: the NIC and
the Carrier Routing Service Protocol (CRSP) NIC. These NICs allow Unified ICM
to route calls intelligently to Unified ICM peripherals, such as ACDs and IVRs.
They also allow Unified ICM to invoke mid-call transfers in the PSTN. The
following figure illustrates this model.
In the VRU-Only
functional deployment model:
Unified ICM
routes a call before it is routed to another calls to Ingress Voice Gateway for
call treatment and queuing. When an agent becomes available, Unified ICM
instructs the PSTN to transfer the call to that agent. The agents can be Cisco
Unified Contact Center Enterprise agents, Cisco Unified Contact Center Express
agents, or ACD agents. If necessary, Unified ICM can request the PSTN (using
the NIC) to transfer the call, just as Unified ICM can request Unified CVP to
transfer the call.
Ingress Voice
Gateway is a Unified ICM-managed PSTN termination point that provides VRU
services using a VoiceXML Gateway, the VXML server, the ICM Service, and
Unified ICM.
The SIP Service
is not used for call control. All call control and switching is controlled by
Unified ICM and the PSTN.
Unified ICM can
pass call data between these termination points (for a pop-up window or other
intelligent treatment) and provide reporting for all calls.
Following are the
required components of this model:
Ingress Voice
Gateway
VoiceXML Gateway
CVP Server
Unified Call
Studio
Cisco Unified
ICM Enterprise and NIC (CRSP)
Following are the
optional components of this model:
ASR/TTS Server
Third-Party
Media Server
Application
Control Engine (ACE)
SIP Proxy
Server (for SIP deployments)
Reporting
Server
Protocol Call
Flows
The following are
the protocol-level call flows for calls originated by Unified CM in each of the
deployment models:
Model #4, VRU
Only with NIC Controlled Routing, is not discussed here because no NIC is
involved with calls originated by Unified CM.
Video
The Video
service is an extension of the Comprehensive deployment model that allows for a
video caller to interact with a video agent. IVR and queuing are audio-only.
The
following video endpoints are supported when using the Unified CVP Video:
Cisco Unified
Video Advantage
Cisco
TelePresence
The Video
service supports the following call flows:
A TelePresence
caller dials into Unified CVP, receives audio-only IVR queuing treatment, and
then is transferred to an agent on a second TelePresence unit.
The
TelePresence agent can conference in a second agent on an audio-only IP phone
by dialing a direct extension from the TelePresence phone.
The TelePresence
agent can conference in a Unified CVP dialed number that results in audio
queuing, followed by connecting to a second agent on an audio-only IP phone.
A TelePresence
caller dials into Unified CVP, receives audio-only IVR queuing treatment, and
then is transferred to an agent on an audio-only IP phone. Enable Media
Transfer Protocol (MTP) on the SIP trunk to listen to audio both ways.
Note
Because
Video is an extension of the SIP-based Comprehensive deployment model, the
required components and SIP protocol-level call flow details remain same. See
Comprehensive
for details.
Video in
Queue
Video in Queue (VIQ)
is an optional Basic Video feature in Unified CVP. It allows the caller to
interact through high-definition video prompt or navigate a video menu using
DTMF keys. The following figure displays the topology and call flow for Basic
Video.
Note
Cisco VVB does
not support Video in Queue.
The Unified CVP
Studio VideoConnect element allows the specific video prompt to be played for
video endpoints. It also allows the DTMF input during video-prompt playback to
be collected and integrated with the Unified Call Studio or Unified CCE
scripting environment.
Note
Video in Queue is
not played during a CUCM failover.
See the
Configuration Guide for
Cisco Unified Customer Voice Portal
for specific Cisco Unified Border Element or VXML Gateway configuration
information for VideoConnect.
See the
Element Specifications for
Cisco Unified CVP VXML Server and Cisco Unified Call Studio
for using the VideoConnect element.
See
"Incoming Call
Configuration and Media File Management" in the
MediaSense User Guide
to use media files.
Note
When
configuring the Video in Queue for Unified CVP, set the MediaSense Incoming Call
Configuration
> Action to play once.