Contents

• Functional deployment models
• Unified CVP VXML standalone server
• Protocol-level call flow
• Transfers and subsequent call control
• Call director
• SIP protocol-level call flow
• Transfers and subsequent call control
• Comprehensive
• SIP protocol-level call flow
• Transfers and subsequent call control
• VRU only
• Protocol-level call flow
• Basic Video
• Video in Queue

Functional deployment models

---

For each deployment model, this chapter provides a short discussion of the typical customer requirements, a list of required and optional components, and a step-by-step call flow.

The functional deployment models presented in this chapter assume all components are located in a single site, and no discussion of failover is covered. For information on Distributed deployment scenarios where components are separated across a WAN link, see the Distributed deployments. For High-availability deployment options, see the Unified CVP design for high availability.

This chapter covers the following functional deployment models for Unified CVP:

• Unified CVP VXML standalone server
• Call director
• Comprehensive
• VRU only
• Basic Video

Unified CVP VXML standalone server

This deployment model is the simplest of the Unified CVP functional deployment models. It provides organizations with a standalone IVR solution for automated self-service. Callers can access Unified CVP from either local, long distance, or toll-free numbers terminating at Unified CVP Ingress voice gateways. Callers can also access Unified CVP from VoIP endpoints. Figure 1 illustrates this model.

Figure 1. Functional Deployment Model for a Unified CVP VXML Server (Standalone)

This model requires the following components:

• Ingress voice gateway
• VoiceXML gateway (Can be co-resident with the ingress gateway)
• Unified CVP VXML Server
• Cisco Unified Call Studio
• Unified CVP Operations Console Server

Optional components for this model include:

• ASR/TTS server
• Third-party media server
• Application Content Engine (ACE)
• Egress voice gateway
• Unified CVP Reporting Server

• Protocol-level call flow
• Transfers and subsequent call control

Protocol-level call flow

1. A call arrives at the ingress gateway via TDM, or SIP. The gateway performs normal inbound POTS or VoIP dial-peer matching.
2. The selected VoiceXML gateway port invokes the Unified CVP self-service TCL script.
3. The TCL script invokes the Unified CVP standalone bootstrap VoiceXML Document, which performs an HTTP request to the configured IP address of the Unified CVP VXML Server.
4. The Unified CVP VXML Service function is resident in the CVP Server. The Unified CVP VXML Service runs the application 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.
5. The VoiceXML gateway parses and renders the VoiceXML document. For spoken output, the VoiceXML gateway either retrieves and plays back prerecorded audio files referenced in the VoiceXML document, or it streams media from a text-to-speech (TTS) server. Caller input can be captured either by DTMF detection on the Ingress Gateway or via DTMF/speech recognition on an ASR server.
6. As defined in the VoiceXML document, the VoiceXML gateway submits an HTTP request containing the results of the caller input to the Unified CVP VXML Server. The Unified CVP VXML Server again runs the application specified in the HTTP URL and returns a dynamically generated VoiceXML document to the VoiceXML gateway. The dialog continues by repeating steps 5 and 6.
7. The IVR dialog ends when either the caller hangs up, the application releases, or the application initiates a transfer.

Transfers and subsequent call control

In addition to providing self-service, the Standalone VoiceXML deployment model can transfer callers to another endpoint – either VoIP (for example, Cisco Unified Communications Manager) or TDM (for example, egress voice gateway to PSTN or TDM ACD). However, no IVR application data can be passed to the new endpoint with this deployment model, so there is no agent screen pop if the endpoint is a TDM ACD.

This model supports the following types of transfers:

• VoiceXML Bridged Transfer
• VoiceXML Blind Transfer
• Release Trunk Transfer (TNT, hookflash, TBCT, and SIP Refer)

The VoiceXML transfers are invoked using the transfer element from Cisco Unified Call Studio. Release Trunk Transfers are invoked by providing specially formatted return values in subdialog_return element.

Agent transfers from agent phones are not supported in standalone deployments. Agent transfers from an agent's IP phone must be controlled by a Unified CCE supported with Unified CVP comprehensive deployments.

In the case of a VoiceXML Bridged Transfer, the outcome of the transferred call leg (transfer failed, transfer call leg released, and so forth) is submitted back to the Unified CVP VXML Server. The VoiceXML session is then resumed, and further iterations of IVR call treatment and transfers can be performed. During the period of time that the call is transferred, a Unified CVP VXML Server port license is utilized with a bridged transfer.

In the case of a VoiceXML 2.0 Blind Transfer, the call remains connected through the ingress voice gateway, but Unified CVP does not have any method to provide any subsequent call control.

In the case of a Release Trunk Transfer, the ingress voice gateway port is released and no subsequent call control is possible.

For more details on transfers, see the chapter on Call transfer options.

Call director

This functional deployment model provides organizations with a mechanism to route and transfer calls across a VoIP network. The most common usage scenario for this model is for organizations with multiple TDM ACD and TDM IVR locations that are integrated with Unified ICM via an ACD or IVR PG. The organization wants to use the Unified ICM to route and transfer calls intelligently across these locations without having to utilize PSTN pre-routing or release trunk transfer services. In this functional deployment model, Unified CVP and Unified ICM can also pass call data between these ACD and IVR locations. In this deployment model, Unified ICM can also provide beginning-to-end reporting for all calls. Although customers can have a Unified CVP Reporting Server in this deployment model, it is optional because there is very little call information stored in the Unified CVP reporting database.

This functional deployment model is often the initial step in the migration from a TDM-based contact center to a VoIP-based contact center. When the organization is ready to implement CVP-based IVR services and Unified CCE, the organization can migrate their Unified CVP deployment to the comprehensive functional deployment model.

Callers can access Unified CVP via either local, long distance, or toll-free numbers terminating at Unified CVP ingress voice gateways. Callers can also access Unified CVP from VoIP endpoints.

This model requires the following components:

• Ingress voice gateway
• Egress voice gateway
• Unified CVP Server
• Unified CVP Operations Console Server
• Cisco Unified ICM Enterprise
• SIP Proxy Server (for SIP deployments)

Optional components for this model include:

• Unified CVP Reporting Server

• SIP protocol-level call flow
• Transfers and subsequent call control

SIP protocol-level call flow

VoIP-based Pre-Routing

1. A call arrives at the ingress gateway and sends a SIP INVITE message to the SIP Proxy Server, which forwards the request to the Unified CVP Server SIP Service.
2. The SIP Service sends a route request to Unified ICM using the Unified CVP Server ICM Service and the VRU PG. This route request causes Unified ICM to run a routing script based upon the dialed number and other criteria.
3. The Unified ICM routing script selects a target and returns a translation route label to the Unified CVP Server SIP Service. The Server SIP Service then signals via the SIP Proxy Server to the egress voice gateway (which connects to the TDM termination) 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 in order to allow subsequent call control.
4. When the call arrives at the selected termination, the termination equipment sends a request to its PG 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, then 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 popped onto the agent screen. After receiving live assistance, the caller can either release or request to be transferred to another agent.

VoIP-based Transfer

1. Regardless of whether the call was initially routed to a TDM IVR or ACD location, the caller can request to be transferred to another location. When this occurs, the TDM IVR or ACD sends a post-route request with call data (with its PG) to Unified ICM.
2. When Unified ICM receives this post-route request, it runs a routing script based upon the transfer dialed number and other criteria. The Unified ICM routing script selects a new target for the call and then signals to the Unified CVP Server SIP Service to release the call leg to the originally selected termination and to extend the call to a new termination.
3. 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 was 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 the transfers managed by Unified ICM (as described above), 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 was translation-routed to another ICM peripheral, call data and cradle-to-grave reporting can be maintained. For more details on transfers, see the chapter on Call transfer options.

If a selected termination (for either a new or transferred call) returns a connection failure or busy status, or if the target rings for a period of time that exceeds the Unified CVP Call Server's ring-no-answer (RNA) timeout setting, the Unified CVP Call Server cancels the transfer request and sends a transfer failure indication to Unified ICM. This scenario causes a Router Requery operation. The Unified ICM routing script then recovers control and has the opportunity to select a different target or take other remedial action.

Comprehensive

This functional deployment model provides organizations with a mechanism to route and transfer calls across a VoIP network, to offer IVR services, and to queue calls before being routed to a selected agent. The most common usage scenario for this functional deployment model is for organizations wanting 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. Upon request, callers can also be transferred between Unified CCE agents. In this functional deployment model, Unified CVP and Unified ICM can also pass call data between these endpoints and provide reporting for all calls. Figure 1 illustrates this model.

Figure 2. Comprehensive Functional Deployment Model

This functional deployment model provides all the capabilities of the Standalone Unified CVP VXML Server and Call Director functional deployment models, plus the ability to route and queue calls to Unified CCE agents.

Callers can access Unified CVP via either local, long distance, or toll-free numbers terminating at the Unified CVP ingress voice gateways. Callers can also access Unified CVP from VoIP endpoints.

Comprehensive deployments can utilize SIP.

This model requires the following components:

• Ingress voice gateway
• VoiceXML gateway (Can be co-resident with the ingress gateway)
• Unified CVP Server
• Unified CVP Operations Console Server
• Cisco Unified ICM Enterprise
• SIP Proxy Server (for SIP deployments)

Optional components for this model include:

• Egress voice gateway
• ASR / TTS server
• Third-party Media server
• Application Control Engine (ACE)
• Unified CVP Reporting Server

• SIP protocol-level call flow
• Transfers and subsequent call control

SIP protocol-level call flow

Initial Call Treatment and Self-Service

1. A call arrives at the ingress gateway and sends a SIP invite message to the SIP Proxy Server, which forwards the request to the Unified CVP Server SIP Service.
2. The SIP Service sends a route request to Unified ICM via the Unified CVP Server ICM Service and the VRU PG. This route request causes Cisco Unified ICM to run a routing script based upon the dialed number and other criteria.
3. 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.
4. The Voice XML gateway sends an HTTP new call message to the Unified CVP 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. The routing script is re-entered 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 Unified CVP VXML Server application. Upon completion of the Unified CVP VXML Server application or a request by the caller to transfer to a live agent, service control is returned to the Unified CVP Server IVR Service. If the initial call treatment is simple with just a few prompts, then the IVR Service can utilize Unified CVP microapplications to generate VoiceXML documents for the VoiceXML gateway, and a Unified CVP VXML Server is not required.

Caller Requests to Transfer to Live Agent

1. 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 Run VRU Script messages to the IVR Service to have queue treatment provided (assuming no agent is available).
2. When a Unified CCE agent becomes available, Unified ICM requests the Unified CVP Server IVR Service to transfer the call the to selected agent.
3. The IVR Service then requests the SIP Service to transfer the caller to the dialed number of the selected agent. The SIP Service sends a SIP invite 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 message to Unified CM.
4. Unified CM accepts the incoming SIP Trunk call and routes it to the selected agent.

Caller Requests to be Transferred to a Second Skill Group

1. If the caller requests to be transferred to a second agent, then the first agent initiates a transfer from their Unified CCE agent desktop application. This action generates a route request from the agent PG to the Unified ICM central controller. Unified ICM executes a routing script that queues the call to another skill group. Assuming 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.
2. The VoiceXML gateway sends an HTTP new call request to the IVR Service, which forwards that request to Unified ICM in order to allow the routing script to be re-entered at the exit of the Send to VRU node. The Unified ICM sends Run VRU Script messages to the IVR Service to allow queue treatment to be provided to the caller while waiting for a second agent.
3. When a second Unified CCE agent becomes available, Unified ICM requests the Unified CVP Server IVR Service to transfer the call to the selected agent.
4. The IVR Service requests the SIP Service to transfer the caller to the dialed number of the selected agent. The SIP Service sends a SIP invite 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 message to Unified CM.
5. Unified CM accepts the incoming SIP trunk call and routes it to the second agent.

Note

Due to a limitation in earlier versions of Cisco IOS, Cisco recommended configuring an MTP because it was required for call flows in which the first agent consulted and was queued and then completed the transfer before connecting to a second agent. This limitation no longer applies, and MTP configuration is not required on SIP trunks if you are running the latest versions of Cisco IOS. Consult the Cisco Unified CVP 9.0(1) Release Notes for details about this limitation. Also note that there are certain situations where MTP usage can still be allocated dynamically (for example, when there is a SIP DTMF capability mismatch).

Transfers and subsequent call control

In addition to transfers manager by Unified ICM (as described above), the comprehensive deployment model can transfer calls to non-ICM terminations or it can 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 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 was translation routed to another ICM peripheral, call data and reporting can be maintained. For more details on transfers, see the chapter about Call transfer options.

If a selected termination (for either a new or transferred call) returns a connection failure or busy status, or if the target rings for a period of time that exceeds the Unified CVP Call Server's ring-no-answer (RNA) timeout setting, the Unified CVP Call Server cancels the transfer request and sends a transfer failure indication to Unified ICM. This scenario causes a Router Requery operation. The Unified ICM routing script recovers control and has the opportunity to select a different target or take other remedial action.

VRU only

This functional deployment model provides self-service applications and queueing treatment for organizations that are utilizing 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. They are the SS7 NIC and the Carrier Routing Service Protocol (CRSP) NIC. These NICs go beyond allowing Unified ICM to pre-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. Figure 1 illustrates this model.

Figure 3. Functional Deployment Model for VRU Only

A typical call in this model would be pre-routed by Unified ICM to a Unified CVP Ingress Voice Gateway for call treatment and queueing. 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 traditional ACD agents. If necessary, Unified ICM can request the PSTN (using the NIC) to transfer the call again and again, just as Unified ICM can request Unified CVP to transfer the call again and again. In this functional deployment model, the Unified CVP Ingress Voice Gateway is just a Unified ICM-managed PSTN termination point that is capable of providing VRU services using a VoiceXML gateway, the Unified CVP Server IVR Service, the Unified CVP Server ICM Service, and Unified ICM. In this functional deployment model, the Unified CVP Server SIP Service is not used for call control. All call control and switching is controlled by Unified ICM and the PSTN. In this functional deployment model, Unified ICM can pass call data between these termination points (for a screen pop or other intelligent treatment) and provide reporting for all calls.

This model requires the following components:

• Ingress voice gateway
• VoiceXML gateway (Can be co-resident with the ingress gateway)
• Unified CVP Server running IVR Service and ICM Service
• Unified CVP Operations Console Server
• Cisco Unified ICM Enterprise and NIC (SS7 or CRSP)

Optional components for this model include:

• ASR / TTS server
• Third-party Media server(s)
• Application Control Engine (ACE)
• Unified CVP Reporting Server
• SIP Proxy Server (for SIP deployments)

• Protocol-level call flow

Protocol-level call flow

Initial Call Treatment and Self-Service

1. A call arrives at the PSTN, and the PSTN sends a new call message to Unified ICM using either a CRSP NIC or SS7 NIC. Unified ICM invokes a routing script based upon the dialed number, and the routing script uses either a Send to VRU node or a Translation Route to VRU node to send a result to the PSTN to have the call routed to the Unified CVP ingress voice gateway. Depending upon the PSTN capability and Unified ICM VRU type for the Unified CVP deployment, the response returned to the PSTN is either a translation route label (dialed number) or a dialed number plus correlation ID.
2. The PSTN routes the call to an available ingress voice gateway port. The ingress voice gateway performs normal inbound POTS dial-peer matching to deliver the call to an available VoiceXML gateway port. A SIP Invite message to a SIP Proxy server could be used to aid in the routing of the call to an available VoiceXML gateway port, if desired.
3. The Voice XML gateway sends an HTTP new call message to the Unified CVP Server IVR Service with the dialed number delivered from the PSTN. This dialed number represents either a translation route label or a correlation ID. The Unified ICM VRU PG recognizes this call and sends a request instruction message to the in-progress Unified ICM routing script. The next routing script node is typically a Run VRU Script node to instruct the VRU which microapplication is to be executed.
4. The Unified CVP Server IVR Service sends a dynamically generated VoiceXML document to the VoiceXML gateway for rendering.
5. The VoiceXML gateway parses and renders the VoiceXML document. If call treatment requires complex IVR self-services, service control can be redirected to a Unified CVP VXML Server application. Upon completion of the Unified CVP VXML Server application or a request by the caller to transfer to a live agent, service control is returned to Unified CVP Server IVR Service. If the initial call treatment is simple with just a few prompts, then the IVR Service can utilize Unified CVP microapplications to generate VoiceXML documents for the VoiceXML gateway, and a Unified CVP VXML Server is not required. If desired, the Unified ICM routing script can terminate the call, and a disconnect message will be sent by the Unified ICM to the PSTN using the PSTN NIC.

Caller Requests to Transfer to Live Agent

1. 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 Run VRU Script messages to the IVR Service to have queue treatment provided (assuming no agent is available).
2. When a Unified CCE agent or a TDM ACD agent becomes available, Unified ICM immediately sends a connect message to the PSTN using the PSTN NIC. The connect message contains either a translation route label or a dialed number plus correlation ID (depending upon the PSTN capabilities). Upon receipt of the connect request, the PSTN releases the call leg to the Unified CVP ingress voice gateway and connects the call to the new termination. If the new termination is a TDM ACD, the previous queueing treatment may be skipped and the TDM ACD could provide the queue treatment. Any call data associated with this call is passed to the Unified ICM Peripheral Gateway (PG) for the selected peripheral.

Caller Requests to be Transferred to a Second Skill Group

1. If the caller requests to be transferred to a second agent, then the first agent initiates a transfer from their agent desktop application (Unified CCE or TDM). This action generates a route request from the PG to the Unified ICM central controller.
2. Unified ICM executes a routing script. If the caller needs to be placed back into queue on Unified CVP or to another ACD location (TDM or IP), then Unified ICM sends a connect message to the PSTN using the PSTN NIC to have the call transferred. If the caller needs to be transferred to an agent on the same Unified CM peripheral, then Unified ICM instructs Unified CM (using the Unified CM PG) to transfer the call.

Basic Video

The Basic Video service is simply an extension of the existing Comprehensive deployment model, but it 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 Basic Video:

• Cisco Unified Video Advantage
• Cisco TelePresence

The Basic Video service supports the following call flows:

• A TelePresence caller dials into Unified CVP, receives audio-only IVR and/or 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 their 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 and/or queuing treatment, and then is transferred to an Agent on an audio-only IP Phone.The MTP must be enabled on the SIP trunk or else one-way audio is encountered.

Because the Basic Video is simply an extension of the SIP-based Comprehensive deployment model, the required components and SIP protocol-level call flow details are identical.

• Video in Queue

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.

Figure 4. Basic in Queue. The following figure display the topology and call flow for Basic Video.

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.

See the Configuration and Administration Guide for Cisco Unified Customer Voice Portal for specific CUBE/ 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.