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

Functional Deployment Models

Table Of Contents

Functional Deployment Models

Standalone VoiceXML Server

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


Functional Deployment Models


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

Standalone VoiceXML Server

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.

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

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

VoiceXML server(s)

VoiceXML 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 VoiceXML server.

4. The VoiceXML Server runs the application specified in the HTTP URL and returns a dynamically generated VoiceXML document to the VoiceXML gateway. The VoiceXML 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 VoiceXML Server. The VoiceXML 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 the VoiceXML Studio's transfer element. Release Trunk Transfers are invoked by providing specially formatted return values in VoiceXML Studio's subdialog_return element.

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 VoiceXML 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 VoiceXML 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.

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. The Unified CVP Call Server consults the gatekeeper to translate the label to the IP address of an appropriate Cisco Unified Communications Manager or other H.323 endpoint. The Unified CVP Call Server then sends an H.225 call setup to the selected endpoint and makes an Empty Capability Set (ECS) request to the ingress gateway to redirect.

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

This functional deployment model provides all the capabilities of the Standalone VoiceXML 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:

VoiceXML 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 VoiceXML server application. Upon completion of the VoiceXML 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 VoiceXML 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.

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.

5. The Voice XML gateway sends an HTTP new-call message to the Unified CVP Server H.323 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 VoiceXML server application. Upon completion of the VoiceXML 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 VoiceXML 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 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.

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:

VoiceXML 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 VoiceXML server application. Upon completion of the VoiceXML 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 VoiceXML 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.