Cisco Unified Customer Voice Portal (CVP) 7.x Solution Reference Network Design (SRND)
Functional Deployment Models
Downloads: This chapterpdf (PDF - 147.0KB) The complete bookPDF (PDF - 3.14MB) | Feedback

Functional Deployment Models

Table Of Contents

Functional Deployment Models

What's New in This Chapter

Unified CVP VXML Server (Standalone)

Protocol-Level Call Flow

Transfers and Subsequent Call Control

Call Director

SIP Protocol-Level Call Flow

H.323 Protocol-Level Call Flow

Transfers and Subsequent Call Control

Comprehensive

SIP Protocol-Level Call Flow

H.323 Protocol-Level Call Flow

Transfers and Subsequent Call Control

VRU Only

Protocol-Level Call Flow

Basic Video Service

Full Video Service

Protocol-Level Call Flow


Functional Deployment Models


Last revised on: October 13, 20010

 

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

Unified CVP VXML Server (Standalone)

Call Director

Comprehensive

VRU Only

For each model, this chapter provides a short discussion of the typical customer requirements for that deployment model, a list of the 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. Distributed deployment scenarios where components are separated across a WAN link are discussed in the chapter on Distributed Deployments, page 3-1. High-availability deployment options are covered in the chapter on Designing Unified CVP for High Availability, page 4-1.

What's New in This Chapter

Table 2-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

 

Table 2-1 New or Changed Information Since the Previous Release of This Document 

New or Revised Topic
Described in:

Use of a media termination point (MTP) with SIP trunks

SIP Protocol-Level Call Flow


Unified CVP VXML Server (Standalone)

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 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. Figure 2-1 illustrates this model.

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

This model requires the following components:

Ingress voice gateway(s)

VoiceXML gateway(s) (Can be co-resident with the ingress gateway)

Unified CVP VXML Server(s)

Cisco Unified Call Studio

Operations Console Server

Optional components for this model include:

ASR/TTS server(s)

Third-party media server(s)

Content Services Switch(es)

Egress voice gateway(s)

Unified CVP Reporting Server

Protocol-Level Call Flow

1. A call arrives at the ingress gateway via TDM, SIP, or H.323. 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 Server runs the application specified in the HTTP URL and returns a dynamically generated VoiceXML document to the VoiceXML gateway. The Unified CVP VXML Server application 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 dialogue 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, therefore there will be 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 Cisco Unified Call Studio's transfer element. Release Trunk Transfers are invoked by providing specially formatted return values in Cisco Unified Call Studio's 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 system 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 to the chapter on Call Transfer Options, page 10-1.

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, and they wish to use 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 cradle-to-grave 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 Cisco Unified Contact Center Enterprise, 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.

Call Director deployments can utilize either H.323, SIP, or a combination.

This model requires the following components:

Ingress voice gateway(s)

Egress voice gateway(s)

Unified CVP Server

Unified CVP Operations Console Server

Cisco Unified ICM Enterprise

H.323 gatekeeper (H.323 deployments)

SIP Proxy Server (for SIP deployments)

Optional components for this model include:

Unified CVP Reporting Server

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 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 selects a target and returns a translation route label to the Unified CVP Server SIP Service, which 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 previously run Unified ICM script to be passed to the selected termination. If the selected termination is a TDM IVR platform, then self-service will be 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 will be 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 (via its PG) to Cisco 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.

H.323 Protocol-Level Call Flow

VoIP-based Pre-Routing

1. A call arrives at the ingress gateway and sends a RAS request to the H.323 gatekeeper to find the IP address of an appropriate Unified CVP Server for that dialed number.

2. The ingress voice gateway then sends an H.225 call setup message to the Unified CVP Server H.323 Service. For a brief instance, a G.711 voice stream exists between the ingress voice gateway and the Unified CVP Server H.323 Service.

3. The Unified CVP Server H.323 Service sends a route request to Cisco Unified ICM via the Unified CVP Server IVR Service, Unified CVP ICM Service, and VRU PG. This request causes Unified ICM to run a routing script based upon the dialed number and other criteria.

4. The Unified ICM routing script selects a target and returns a translation route label (dialed number) to the Unified CVP Server H.323 Service, which then sends a RAS request to the H.323 gatekeeper to find the IP address of the selected termination (an egress voice gateway to the PSTN or front-ending a TDM peripheral).

5. The Unified CVP Server H.323 Service then sends an H.225 call setup message to the egress voice gateway and makes an Empty Capability Set (ECS) request to the ingress voice gateway to redirect the call. 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.

6. 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 previously run Unified ICM script to be passed to the selected termination. If the selected termination is a TDM IVR platform, then self-service will be 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 will be 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 will send a post-route request with call data (via its PG) to Cisco 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 H.323 Service to release the call leg to the originally selected termination and to extend the call to a new termination. The H.323 Service queries the H.323 gatekeeper in order to get an IP address for the 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, page 10-1.

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 cradle-to-grave reporting for all calls. Figure 2-2 illustrates this model.

Figure 2-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 either H.323, SIP, or a combination.

This model requires the following components:

Ingress voice gateway(s)

VoiceXML gateway(s) (Can be co-resident with the ingress gateway)

Unified CVP Server

Unified CVP Operations Console Server

Cisco Unified ICM Enterprise

H.323 gatekeeper (for H.323 deployments)

SIP Proxy Server (for SIP deployments)

Optional components for this model include:

Unified CVP VXML Server

Egress voice gateway(s)

ASR / TTS server(s)

Third-party media server(s)

Content Services Switch(es)

Unified CVP Reporting Server

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 to have the call sent to a VoiceXML gateway. The Unified CVP Server SIP Service sends an invite message to the VoiceXML gateway via 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 (via 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 then 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 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 then sends a SIP invite message to the SIP Proxy Server, which finds the Cisco Unified Communications Manager SIP Trunk IP address associated with this agent DN, and then forwards the SIP Invite message to Cisco Unified Communications Manager (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 will initiate 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 then executes a routing script that queues the call to another skill group. Assuming no agent is available, the Unified ICM script will use the Send to VRU node, which will signal 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. Unified ICM then 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 the selected agent.

4. The IVR Service then requests the SIP Service to transfer the caller to the dialed number of the selected agent. The SIP Service then 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 7.0(2) Release Notes for details about this limitation. Also note that there are certain situations where MTP usage is still required (for example, when there is a SIP DTMF capability mismatch).


H.323 Protocol-Level Call Flow

Initial Call Treatment and Self-Service

1. A call arrives at the ingress gateway and sends a RAS request to the H.323 gatekeeper to find the IP address of the Unified CVP Server for that dialed number.

2. The ingress voice gateway then sends an H.225 call setup message to the Unified CVP Server H.323 Service. For a brief instance, a G.711 voice stream exists between the ingress voice gateway and the Unified CVP Server H.323 Service.

3. The Unified CVP Server H.323 Service sends a route request to Cisco Unified ICM via the Unified CVP Server IVR Service, Unified CVP ICM Service, and VRU PG. This request causes Unified ICM to run a routing script based upon the dialed number and other criteria.

4. The Unified ICM routing script utilizes a Send to VRU node to return a label to the H.323 Service to have the call sent to a VoiceXML gateway. The H.323 Service sends a RAS request to the H.323 gatekeeper to find the IP Address of the VoiceXML gateway associated with the label returned by Unified ICM. The Unified CVP H.323 Service sends an H.225 setup message to the VXML Gateway.

5. 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 (via the IVR Service, ICM Service, and VRU PG), 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 then 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 selected agent.

3. The IVR Service then requests the H.323 Service to transfer the caller to the dialed number of the selected agent. The H.323 Service then sends a RAS message to the H.323 gatekeeper to find the Unified CM H.323 Trunk IP address associated with this agent DN, and then sends an H.225 call setup message to Unified CM.

4. Unified CM accepts the incoming H.323 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 will initiate 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 then executes a routing script that queues the call to another skill group. Assuming no agent is available, the Unified ICM script will use the Send to VRU node, which signals to the H.323 Service to release the call leg to the Unified CM H.323 Trunk and to connect the call back to a VoiceXML gateway. A RAS request to the H.323 gatekeeper is to find the IP address of the 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. Unified ICM then 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 the selected agent.

4. The IVR Service then requests the H.323 Service to transfer the caller to the dialed number of the selected agent. The H.323 Service sends a RAS request to the H.323 gatekeeper to get the IP address of the Unified CM H.323 trunk associated with the second agent DN. The H.323 Service then sends an H.225 setup message to Unified CM.

5. Unified CM accepts the incoming H.323 trunk call and routes it to the second agent.

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 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, page 10-1.

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.

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 via a Cisco Unified ICM PSTN Network Interface Controller (NIC). Two Unified ICM PSTN NICs are available that 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 2-3 illustrates this model.

Figure 2-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 (via 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 via a VoiceXML gateway, the Unified CVP Server IVR Service, the Unified CVP Server ICM Service, and Unified ICM. In this functional deployment model, neither the Unified CVP Server H.323 Service nor the Unified CVP Server SIP Service is 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 cradle-to-grave reporting for all calls.

This model requires the following components:

Ingress voice gateway(s)

VoiceXML gateway(s) (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:

Unified CVP VXML Server

ASR / TTS server(s)

Third-party media server(s)

Content Services Switch(es)

Unified CVP Reporting Server

H.323 gatekeeper (for H.323 deployments)

SIP Proxy Server (for SIP deployments)

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 via 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. An H.323 RAS request to an H.323 gatekeeper or 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. Either way, the Unified ICM VRU PG will recognize this call and send 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 via the PSTN NIC.

Caller Requests to Transfer to Live Agent

6. 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).

7. When a Unified CCE agent or a TDM ACD agent becomes available, Unified ICM immediately sends a connect message to the PSTN via the PSTN NIC. The connect message will contain 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 could be skipped and the TDM ACD could provide the queue treatment. Any call data associated with this call will be passed to the Unified ICM Peripheral Gateway (PG) for the selected peripheral.

Caller Requests to be Transferred to a Second Skill Group

8. If the caller requests to be transferred to a second agent, then the first agent will initiate 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.

9. 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 via 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 (via the Unified CM PG) to transfer the call.

Basic Video Service

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 Service:

Cisco Unified IP Phone 7985G

Cisco Unified Video Advantage

Cisco TelePresence

The Basic Video Service supports the following call flows with Cisco TelePresence:

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.

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.

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 Unified CVP dialed number that results in audio queuing, followed by connection 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. MTP must be enabled on the SIP trunk or else one-way audio is encountered.

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

Full Video Service

The Full Video call flow model is for customers who want to use video capabilities for every phase of the caller interaction with the call center. Figure 2-4 illustrates this model.

Figure 2-4 Functional Deployment Model for Full Service Video

Using the Radvision IVP platform in conjunction with Unified CVP and Cisco Unified Intelligent Contact Management Enterprise (Unified ICME) provides the following video capabilities:

Video IVR — Callers can see a visual representation of their menu choices, they can perform self-service functions, and they can select and view pre-recorded video clips or live video sources.

Video Queuing — Caller can view pre-recorded or live video while in queue for an agent.

Video Agent — Once the caller is connected to an agent, the agent and caller can communicate using video. Additionally, agents have the ability to select and "push" pre-recorded or live video content to the caller.

Video Hold — If the agent puts the caller on hold, the caller will view pre-recorded video clips and/or live streaming video and hear the Unified CM music on hold.

Video Recording — Any phase of the video interactions outlined above can be recorded.

The following video endpoints are supported when using the Unified CVP Full Video Service:

Cisco Unified IP Phone 7985G

Cisco Unified Video Advantage

Radvision 3G Video Gateway and 3G Mobile Video Phone

Protocol-Level Call Flow

The following step outline the call flow for Full Video Service.

Initial Call Treatment and Self-Service

1. A call arrives from a video-enabled endpoint. Either the 3G gateway (mobile phone caller) or Unified CM sends a SIP invite to the Radvision IVP via the Cisco Unified Presence proxy server.

2. The IVP sends an XML message to the Unified CVP call server notifying it of the new call.

3. Unified CVP sends a GED request to Unified ICM, which runs a script based on the DNIS of the new call. Unified ICM returns GED responses to Unified CVP, which translates the GED messages into IVP XML messages and sends them back to the IVP.

4. The IVP, through its own internal mechanisms, plays movies or collects DTMF tones, depending on the commands sent from Unified CVP. Responses from the action are sent back to Unified CVP, which in turn relays the responses to the Unified ICM script. If the script writer has enabled VCR controls on a microapplication definition, the caller may elect to stop, pause, resume, forward, or rewind the movie using administrator-configurable DTMF keys.

5. The Unified ICM script writer can set an ECC variable to start and stop recording the caller view, the agent view, or the omni view (meaning all call legs).

Caller Requests to Transfer to Live Agent

6. When an agent becomes available, Unified ICM sends a CONNECT request to Unified CVP, with instructions to transfer the caller to an agent extension. Unified CVP translates this message to IVP XML, fully formulates the target SIP URL, and sends it to IVP.

7. The IVP sends a SIP invite to the URL specified by Unified CVP, which will be either the proxy server or Unified CM. The IVP and Unified CM exchange SIP messages, and the caller is connected to the agent via video and/or audio.

8. During the dialog, the agent opts to show a movie to the caller. From either the CAD or CTIOS agent desktop, the agent presses a button on their desktop, which opens a browser to a predetermined URL. The URL had been determined originally by the Unified CVP call server and placed in an ECC variable.

9. The browser connects to the Video Media Server specified in the URL. The agent can search for a list of movies or live videos that match the keyword(s) entered. The agent can either click on a movie to retrieve additional metadata or may elect to preview the movie with a PREVIEW button. This will cause the movie to play locally to the agent (not to the caller). If it is the desired movie, the agent then presses PLAY, which then plays the movie or live video to the caller.

10. The Unified CVP call server receives the PLAY request (via the VMS) with the associated call GUID and instructs IVP via IVP XML messages to play the selected movie on the call. This will result in both the agent and caller hearing and seeing the movie at the same time.

11. While the movie is playing, the caller may elect to stop, pause, resume, forward, or rewind the movie using administrator-configurable DTMF keys. The IVP notifies Unified CVP when a DTMF key is pressed by the caller. If the DTMF key matches one of the configured DTMF tones for VCR control, Unified CVP notifies the IVP to take appropriate action on the movie. Additionally, the agent has the ability to stop, pause, resume, forward, or rewind the movie from buttons on the browser screen. Live video may only be stopped.

12. The agent has the ability to record the conversation using a Start/Stop recording button on their browser window. Whether this will record the caller view, the agent view, or the omni view will be controlled by a global configurable setting in the Operations Console.

13. If the agent puts the caller on hold, Unified CM sends a SIP message to IVP, which in turn plays the preconfigured video-on-hold movie to the caller.

Caller Requests to be Transferred to a Second Skill Group

14. If the caller requests to be transferred to a second agent, then the first agent will initiate a transfer from their agent desktop application. This action generates a route request from the PG to the Unified ICM central controller.

15. Unified CM in turn sends SIP re-invite messages to IVP, instructing it to move the caller's media streams. The blind transfer may also be performed as a network transfer via Unified CVP, in which case Unified ICM would instruct Unified CVP to blind-transfer the call. In this case, Unified CVP would send an asynchronous request via IVP XML to IVP, telling it to add the new agent leg to the call.