Functional Deployment Models and Call Flows for Cisco Unified Customer Voice Portal

This chapter covers the following subjects:

• Functional deployment models: Standalone, Call Director, Comprehensive, VRU-only.
• Detailed call flows: Call flow details for each Functional Deployment Model.
• Unified CCE interactions: Network VRUs in Cisco Intelligent Contact Management Enterprise and IP originated calls with Cisco Unified Communications Manager.

Functional Deployment Models

As discussed briefly in the previous chapter, Unified CVP has some well-defined and commonly referenced functional deployment models. This chapter provides more details for these models and examines what each model accomplishes, its call flow, and even which native and non-native components are used. Understanding these models is critical to designing, implementing, and troubleshooting a Unified CVP solution. The chapter ends with a discussion that encompasses Unified CVP and its relationship and interactions with Unified CCE components, such as Unified ICM and Cisco Unified Communications Manager.

Standalone Model

Although this model is the simplest of all the functional deployment models, the flexibility available in Unified Call Studio applications is astounding. This model gives an organization the capability to replace legacy IVR systems using applications built using Unified Call Studio and hosted via the Unified CVP VoiceXML Server. The standalone model provides a standalone, automated self-service IVR solution that callers can access via TDM and VoIP terminating at Unified CVP’s Ingress voice gateways. In addition callers could also access this solution via VoIP endpoints. Figure 3-1 shows the components used with this solution and their protocols.

Table 3-1 identifies which components are required, optional, and not used by this model. In addition, the Native column identifies components native to the Unified CVP solution.

Table 3-1 Unified CVP Standalone Native and Non-Native Component Usage

Component	Required	Optional	Not Used	Native
SIP Service (Call Server)	—	—	Yes	Yes
IVR Service (Call Server)	—	—	Yes	Yes
ICM Service (Call)	—	Yes		Yes
H323 Service (Call Server)	—	—	Yes	Yes
VoiceXML Server	Yes	—	—	Yes
Unified Call Studio	Yes	—	—	Yes
Ingress Gateway		Yes	—	—
VXML Gateway	Yes	—	—	—
SIP Proxy	—	—	Yes	—
Gatekeeper	—	—	Yes	—
Operations Console	Yes	—	—	Yes
Reporting Server	—	Yes	—	Yes
ASR/TTS	—	Yes	—	—
Media Server	—	Yes	—	—
DNS Server	—	Yes	—	—
Content Services Switch	—	Yes		—
Unified ICM	—	Yes	—	—
Unified Call Manager	—	Yes	—	—
Egress Gateway	—	Yes	—	—

Component and Protocol-Level Call Flow

This section examines how components interact with each other at the protocol level. Figure 3-2 illustrates the steps of a typical standalone call flow with each step detailed.

Following are the details of each step referenced in Figure 3-2:

Step 1. The call arrives from either the PSTN or a VoIP connection to the gateway. In this illustration, the gateway is functioning as both an Ingress Gateway and as a VoiceXML Gateway. The reason an Ingress Gateway is optional in Table 3-1 is because this initial call could be just a VoIP connection, which would require only a VoiceXML Gateway to terminate it and kick off the self-service application.

Step 2. The gateway sends an HTTP request to the Unified CVP VoiceXML Server. Prior to this occurring, the gateway performs the following actions:

1. The gateway matches an incoming Dialed Number Identification Service (DNIS) against its dial-peer configuration and kicks off a preconfigured application dial-peer. Example 3-1 provides a sample of how this dial-peer is configured for DNIS 1931 on the VoiceXML Gateway:

Example 3-1 Incoming Dial-Peer for Kicking Off a Self-Service Application

dial-peer voice 1 voip

 description —— Self Service SIP Calls from IP ——

 service myapp

 codec g711ulaw

 incoming called-number 1931

 dtmf-relay rtp-nte h245-signal h245-alphanumeric

 no vad

1. The application dial-peer invokes a self-service TCL script located in the router’s flash memory, which invokes the Unified CVP standalone bootstrap VoiceVXML document. Example 3-2 provides a sample of how this is configured on the VoiceXML Gateway.

Example 3-2 Self-Service Application Configuration on Gateway

application

 service myapp flash:CVPSelfService.tcl

  paramspace english language en

  paramspace english index 0

  param CVPSelfService-port 7000

  param CVPSelfService-app MyApp

  param CVPPrimaryVXMLServer 192.168.1.100

  param CVPSecondaryVXMLServer 192.168.1.101

  paramspace english location flash

  paramspace english prefix en

 !

service CVPSelfService flash:CVPSelfServiceBootstrap.vxml

!

1. This VoiceXML document, also located in the router’s flash memory, performs an HTTP request to the configured IP address of the Unified CVP VoiceXML Server. This IP address is preconfigured as a parameter when the self-service application is set up (refer to Example 3-2).

Step 3. The Unified CVP VoiceXML Server runs the application specified in the HTTP URL provided in Step 2. The result of running the application returns a dynamically generated VoiceXML document to the VoiceXML Gateway. Prior to building this dynamic VXML document, the Unified CVP VoiceXML Server can access backend systems as instructed by the application to incorporate personalized data into the VoiceXML document.

Step 4. The VoiceXML Gateway parses and renders the VoiceXML document. Following are the details pertaining to the rendering of this VoiceXML document:

1. If the VoiceXML instructions require a media file fetch operation, prior to fetching a prerecorded media file from a media server, the gateway first determines if the required prompt file is already cached in the gateway’s http client cache. If so, that file is played to the caller; if not, the gateway resolves the media server name located in the fetch URL provided by the VoiceXML document. This media server name can either be a locally configured ip host entry or resolved via DNS.
2. If the VoiceXML instructions require the use of an ASR or TTS server, the VoiceXML Gateway sets up a connection to an ASR/TTS Server and streams media from the server. Caller input can be captured via DTMF detection on the Ingress Gateway or via DTMF/speech recognition on an ASR Server.
3. As defined by the VXML document, the VoiceXML submits an HTTP request containing the results of the caller input to the Unified CVP VoiceXML Server. The Unified CVP VoiceXML Server again runs the application specified in the HTTP request URL, passing it the results provided by the previous VoiceXML Gateway request and dynamically generates another VoiceXML document for rendering by the VoiceXML Gateway. This dialog continues until either the call is deemed as treated by the Unified Call Studio application or the caller terminates the call.

Step 5. The Ingress Gateway can, optionally, transfer the call to any destination that it can deliver a call to, such as Cisco Unified Communications Manager (CUCM).

Step 6. UCM can set up the call between an agent phone and the Ingress Gateway using a specific agent DNIS or a DNIS that corresponds to a hunt group or IP-IVR port. For this call flow this transfer is purely bridged, blind, or released trunk in nature and has no agent selection intelligence other than what CUCM can provide.

A slight variant of this call flow model is the use of Unified ICM to provide a lookup and return a label via the Unified CVP PG integration. Figure 3-3 illustrates this call flow followed by a detailed discussion about the involved steps.

Step 1. The call arrives from either the PSTN or a VoIP connection to the gateway. In this illustration, the gateway is functioning as both an Ingress Gateway and as a VoiceXML Gateway.

Step 2. The gateway sends an HTTP URL request to the Unified CVP VoiceXML Server. The same configurations and substeps apply that were covered in the previous call flow.

Step 3. As a result of executing the application hosted by the Unified CVP VoiceXML Server, the server sends a message to the Unified CVP Call Server requesting that Unified CVP requests a label from Unified ICM.

Step 4. The Unified CVP Server sends Unified ICM a new call request via its Voice Response Unit (VRU) Peripheral Interface Manager (PIM), which is configured and hosted by the Peripheral Gateway (PG). This new route request invokes a new incoming route response that in turn invokes a routing script in Unified ICM.

Step 5. Unified ICM returns a Unified ICM routing label to the Unified CVP Call Server via the Unified CVP VRU PIM hosted by the PG.

Step 6. The Unified CVP Server returns a message to the VoiceXML Server with the routing label returned by Unified ICM.

Step 7. As in the previous call flow, the VoiceXML returned to the VoiceXML Gateway can include references to ASR/TTS, Media Servers for playing media, and the collections of digits or can be transfer instructions based on the Unified ICM label.

Step 8. The Ingress Gateway can, optionally, transfer the call to any destination that it can deliver a call to, such as CUCM.

Step 9. The Ingress Gateway signals the CUCM server for connection to either an IP Phone or IP IVR Port.

Step 10. CUCM can set up the call between an agent phone and the Ingress Gateway using a specific agent DNIS or a DNIS that corresponds to a hunt group or IP-IVR port. For this call flow this transfer is purely bridged, blind, or released trunk in nature and has no agent selection intelligence other than what CUCM can provide.

Call Flow Ladder Diagram

Figure 3-4 illustrates the call flow by showing the interaction between native and non-native CVP components. In addition, both call flows previously discussed are illustrated. However, the interaction with Unified ICM would not exist for the Unified CVP Standalone without ICME lookup call flow.

By examining the previous ladder diagram, it is obvious that the Unified CVP call server services such as the Session Initiation Protocol (SIP), H.323, or Interactive Voice Response (IVR) service are not used with this deployment model. The Intelligent Contact Management (ICM) service is engaged only in the execution of a Unified ICM lookup, and at no point in the call flow does CVP have any call control responsibilities.

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, IVR application data cannot be passed to the new endpoints with this deployment model. Therefore, there will be no agent screen pop if the endpoint is a TDM ACD.

As noted earlier, this model supports the following types of transfers:

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

VoiceXML Blind Transfer: With VoiceXML 2.0 Blind Transfers, the call remains connected through the Ingress Voice Gateway, but Unified CVP does not have any method to provide any subsequent call control.

Release Trunk Transfer (TNT, hookflash, TBCT, SIP Refer): As with VoiceXML 2.0 Blind Transfers, the Ingress Gateway port is released, and no subsequent call control is possible.

The Call Director Model

The purpose of this functional deployment model is to give organizations the ability to route and transfer calls across their existing VoIP networks. Because this functional deployment is often found in organizations preparing for or migrating to a VoIP contact center, it is no surprise that its strengths lie in its capability to switch calls to multiple TDM-based ACDs and IVRs without having to use PSTN prerouting or release trunk transfer services. When the organization is ready to implement CVP-based IVR services and Cisco Unified Contact Center Enterprise, it can migrate its Unified CVP deployment to the comprehensive functional deployment model discussed later in this chapter.

Furthermore, this particular deployment model gives Unified CVP and Unified ICM the capability to pass call data between these ACD and IVR locations. Unified ICM can also provide cradle-to-grave reporting for all calls. Although a customer can have a Unified CVP Reporting Server in this deployment model, it is optional because there is little call information stored in the Unified CVP reporting database. Both TDM and VoIP call originations are supported in this deployment model.² Figure 3-5 shows the components used with this solution and their protocols.

Table 3-2 identifies which components are required, optional, and not used by this model. In addition, the Native column identifies components that are native to the Unified CVP solution.

Table 3-2 Unified CVP Call Director Native and Non-Native Component Usage

Component	Required	Optional	Not Used	Native
SIP Service (Call Server)	Yes (if SIP)	—	—	Yes
IVR Service (Call Server)		—	Yes	Yes
ICM Service (Call Server)	Yes	—	—	Yes
H323 Service (Call Server)	Yes (If H323)	—	—	Yes
VoiceXML Server	—	—	Yes	Yes
Unified Call Studio	—	—	Yes	Yes
Ingress Gateway	Yes	—	—	—
VXML Gateway		—	Yes	—
SIP Proxy	Yes (if SIP)	—	—	—
Gatekeeper	Yes (If H323)	—	—	—
Operations Console	Yes	—	—	Yes
Reporting Server	—	Yes	—	Yes
ASR/TTS	—	—	Yes	—
Media Server	—	—	Yes	—
DNS Server	—	Yes	—	—
Content Services Switch	—	—	Yes	—
Unified ICM	Yes	—	—	—
Unified Call Manager	—	Yes	—	—
Egress Gateway	—	Yes	—	—

SIP-Based Protocol-Level and Component Call Flow

This section examines how the components interact with each other at the protocol level. As illustrated for the Unified CVP Standalone model, Figure 3-6 reviews the steps of a typical call director call flow.

Step 1. The call arrives from either the PSTN or a VoIP connection to the gateway.

Step 2. The Ingress Gateway sends a SIP INVITE message either directly to the Unified CVP call server or to a SIP Proxy Server, which forwards the request to the Unified CVP Server SIP Service.

Step 3. The Unified CVP Server SIP Service sends a route request to Unified ICM via the Unified CVP Server ICM Service and the PG.

Step 4. The Unified CVP Server sends Unified ICM a new call request via its VRU PIM that is configured and hosted by the PG. This new call request invokes a new incoming dialed number that in turn invokes a routing script in Unified ICM.

Step 5. The Unified ICM routing script selects a target and returns a translation route label to the PG via the Unified CVP VRU PIM hosted by the PG.

Step 6. The Unified CVP Server’s ICM Service processes the instructions provided by the VRU PIM and hands the label over to the SIP Service for call setup.

Step 7. The Unified CVP Call Server’s SIP Service signals either the Ingress Gateway or the proxy server, depending on its configuration. This enables the call to be set up between either an Egress Gateway or a Unified Communications Manager cluster. Depending on the solution requirements, the call server can connect calls to either an Egress Gateway or Unified Communications Manager. As depicted in Figure 3-6, Real-time Transport Protocol (RTP) or voice bearer traffic flows directly between the Ingress Gateway and an Egress Gateway or a Unified Communications Manager IP Phone. Call control signaling continues to flow through the Unified CVP to enable subsequent call control.

Step 8. When the call arrives at the selected termination, the termination equipment sends a request to its PG for routing instructions.

Step 9. When the call arrives at the selected termination, the termination equipment sends a request to its PG for routing instructions. This step involves the translation route and enables any call data from the previously run Unified ICM script to be passed to the selected termination. In the case of a TDM-based IVR, the self-service can occur with the caller either being released or transferred to a live agent. In the case of a TDM-based ACD, the call may be queued until an agent is available.

VoIP Transfers Using SIP

Figure 3-7 illustrates how VoIP transfers using SIP are accomplished within this model. Because the Unified CVP call server still maintains call control, it has the capability to signal the Ingress Gateway to move the call from one termination point to another. This is accomplished via PG messages from the original termination point, which may have been a legacy ACD/IVR or Unified Communications Manager. Although Figure 3-7 illustrates this transfer using a second Egress Gateway, this transfer could occur to the same or a different Egress Gateway or Unified Communications Manager cluster.

Following are the details for the steps previously referenced:

Step 1. A caller from a previously routed call, which is currently controlled by the Unified CVP Call Server, requests to be transferred to another location.

Step 2. The TDM IVR, ACD, or Unified Communications Manager sends a post-route request with call data (via its PG) to Unified ICM.

Step 3. When Unified ICM receives this post-route request, it runs an associated routing script based on the transferred dialed number. The Unified ICM routing script selects a target and returns a translation route label to the PG via the Unified CVP VRU PIM hosted by the PG.

Step 4. The Unified CVP Server’s ICM Service processes the instructions provided by the VRU PIM and hands the label over to the SIP Service for call setup.

Step 5. The Unified CVP Server’s SIP Service releases the call leg to the originally selected termination devices. In Figure 3-7, these devices were either an Egress Gateway or a Unified Communications Manager.

Step 6. The Unified CVP Call Server’s SIP Service signals either the Ingress Gateway or the proxy server, depending on its configuration, which enables for the call to be set up between either the second Egress Gateway or a different Unified Communications Manager cluster. The call can also be extended to the same devices that the originating call terminated on. However, Steps 1 through 6 are still required. Existing RTP streams are torn down and brought back up with the second termination device, as depicted in Figure 3-7.

Step 7. When the call arrives at the second termination device, the termination equipment sends a request to its PG for routing instructions.

Step 8. This step involves the translation route and enables any call data from the previously run Unified ICM script to be passed to the selected termination. In the case of a TDM-based IVR, self-service can occur with the caller either being released or transferred to a live agent. In the case of a TDM-based ACD, the call may be queued until an agent is available.

SIP Call Flow Ladder Diagram

Figure 3-8 illustrates the call flow showing the interaction between native and non-native CVP components. Expanding from Figure 3-3, additional services are engaged with this deployment model than what was illustrated for the standalone model. For example, the SIP Service is now used with a SIP proxy server, Egress Gateways, and even a Unified Communications Manager cluster.

H.323 Protocol-Level and Component Call Flow

Although it has been mentioned a few times in this book that H.323 is still supported for upgrades and not for green-field deployments, you need to understand the basic protocol call flow and component interaction for H.323. Migrations require engineers to migrate these call flows to SIP. Understanding how they currently operate can provide important insight for performing migrations. Figure 3-9 illustrates the H.323 call flow, which has striking similarities to the previous SIP call flow shown earlier in Figure 3-6.

Following are the details for the steps previously referenced:

Step 1. The call arrives from either the PSTN or a VoIP connection to the gateway.

Step 2. The Ingress Gateway sends an H.225 Registration, an Admission, and a Status (RAS) request to the H.323 gatekeeper to find the IP address of an appropriate Unified CVP Server for the incoming dialed number.

Step 3. The Ingress Gateway sends an H.225 call setup message to the Unified CVP Server’s H.323 Service.

Step 4. The Unified CVP Server’s H.323 Service sends a route request to Unified ICM via the Unified CVP Server’s IVR Service, the Unified CVP Server’s ICM Service, and the PG.

Step 5. The Unified CVP Server sends Unified ICM a new call request via its VRU PIM that is configured and hosted by the PG. This new call request invokes a new incoming dialed number that in turn invokes a routing script in Unified ICM.

Step 6. The Unified ICM routing script selects a target and returns a translation route label to the PG via the Unified CVP VRU PIM hosted by the PG.

Step 7. The Unified CVP Server’s ICM Service processes the instructions provided by the VRU PIM and hands the label over to the H.323 Service for call setup.

Step 8. The Unified CVP Call Server’s H.323 Service sends a RAS request to the H.323 gatekeeper to find the IP address of the appropriate termination (an Egress Voice Gateway to the PSTN, an Egress Voice Gateway front-ending a TDM peripheral or a Unified Communications Manager Cluster).

Step 9. The Unified CVP Server’s H.323 Service then sends an H.225 call setup message to the termination location (Egress Voice Gateway or Unified Communications Manager cluster) and makes an Empty Capability Set (ECS) request to the Ingress Voice Gateway to redirect the call. RTP or voice bearer traffic flows directly between the Ingress Gateway and the selected termination point (refer to Figure 3.9). Call control signaling continues to flow through the Unified CVP call server to allow subsequent call control.

Step 10. When the call arrives at the selected termination, the termination equipment sends a request to its PG for routing instructions.

Step 11. This step involves the translation route and enables any call data from the previously run Unified ICM script to be passed to the selected termination. In the case of a TDM-based IVR, self-service can occur with the caller either being released or transferred to a live agent. In the case of a TDM-based ACD, the call may be queued until an agent is available.

VoIP Transfers Using H323

Figure 3-10 illustrates how VoIP transfers work with H.323. The call flow is similar to SIP; however, a gatekeeper lookup using RAS is required in the middle of the call flow.

Following are the details for the steps previously referenced:

Step 1. A caller from a previously routed call, which is currently controlled by the Unified CVP Call Server, requests to be transferred to another location.

Step 2. The TDM IVR, ACD, or Unified Communications Manager sends a post-route request with call data (via its PG) to Unified ICM.

Step 3. When Unified ICM receives this post-route request, it runs an associated routing script based on the transferred dialed number and other criteria. The Unified ICM routing script selects a target and returns a translation route label to the PG via the Unified CVP VRU PIM hosted by the PG.

Step 4. The Unified CVP Server’s ICM Service processes the instructions provided by the VRU PIM and hands the label over to the H.323 Service for call setup.

Step 5. The Unified CVP Server’s H.323 Service queries the H.323 gatekeeper to get an IP address for the new termination.

Step 6. The Unified CVP Server’s H.323 Service releases the call leg to the originally selected termination devices. These devices were either an Egress Gateway or a Unified Communications Manager (refer to Figure 3-10).

Step 7. The Unified CVP Call Server’s H.323 Service signals the original termination device, which enables the call to be set up between either the second Egress Gateway or a different Unified Communications Manager cluster. The call could also be extended to the same devices that the originating call terminated on. However, Steps 1 through 6 are still required. Existing RTP streams are torn down and brought back up with the second termination device (refer to Figure 3-10).

Step 8. When the call arrives at the second termination device, the termination equipment sends a request to its PG for routing instructions.

Step 9. This step involves the translation route and enables any call data from the previously run Unified ICM script to be passed to the selected termination. In the case of a TDM-based IVR, self-service can occur with the caller either being released or transferred to a live agent. In the case of a TDM-based ACD, the call may be queued until an agent is available.

Transfers and Subsequent Call Control

In addition to the transfers managed by Unified ICM, the Call Director Deployment model can transfer calls to non-ICM terminations or invoke a Release Trunk Transfer to the PSTN. However, if a call is transferred to a non-ICM controlled termination, call data cannot be passed to the termination, further call control is impossible for the call, and the cradle-to-grave call reporting that Unified ICM gathers is complete. In the case of a Release to Trunk Transfer on the Ingress Voice Gateway, call data or call control cannot be maintained. However, if the call is a translation routed to another ICM peripheral, call data and cradle-to-grave reporting can be maintained.

If a transfer fails or the termination device returns a 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 Re-query operation within Unified ICM, enabling a different target to be selected or execution of a remedial action.³

Comprehensive Model

This next function deployment model provides organizations with a mechanism to route and transfer calls across a VoIP network, offers IVR services, and queues calls before routing to a selected agent. These features are usually found in situations in which an organization is interested in providing a pure IP-based contact center. A caller can initially be directed into an IVR service, exit, and be queued for the next available agent. In addition, transfers are supported between Unified CCE Agents. The passing of data between Unified CVP and ICM is fully supported, and cradle-to-grave reporting for all calls is also supported. Figure 3-11 shows the components used with this solution and their protocols.

Table 3-3 identifies which components are required, optional, and not used by this model. In addition, the Native column identifies components native to the Unified CVP solution.

Table 3-3 Unified CVP Comprehensive Native and Non-Native Component Usage

Component	Required	Optional	Not Used	Native
SIP Service (Call Server)	Yes	—	—	Yes
IVR Service (Call Server)	Yes	—	—	Yes
ICM Service (Call Server)	Yes	—	—	Yes
H323 Service (Call Server)	Yes (If H323)	—	—	Yes
VoiceXML Server	—	Yes	—	Yes
Unified Call Studio	—	Yes	—	Yes
Ingress Gateway	Yes	—	—	—
VXML Gateway	Yes	—	—	—
SIP Proxy	—	Yes	—	—
Gatekeeper	Yes (If H323)	—	—	—
Operations Console	Yes	—	—	Yes
Reporting Server	—	Yes	—	Yes
ASR/TTS	—	Yes	—	—
Media Server		Yes	—	—
DNS Server	—	Yes	—	—
Content Services Switch	—	Yes	—	—
Unified ICM	Yes	—	—	—
Unified Communications Manager	—	Yes	—	—
Egress Gateway	—	Yes	—	—

SIP-Based Protocol-Level and Component Call Flow

This section examines the detailed call flow steps performed in a typical comprehensive call flow. As its name indicates this model is the most complex from a call flow perspective. Figure 3-12 illustrates a typical comprehensive call flow with a SIP proxy server as part of the solution. Figure 3-13, provided later in this section, covers a similar SIP call flow without a proxy server.

Following are the details for the steps previously referenced:

Step 1. The call arrives from either the PSTN or a VoIP connection to the gateway.

Step 2. The Ingress Gateway sends a SIP INVITE message the SIP Proxy Server.

Step 3. The SIP Proxy Server forwards this SIP INVITE to the Unified CVP Server’s SIP Service.

Step 4. The SIP Service sends a new call request to Unified ICM via the Unified CVP Server ICM Service and the PG.

Step 5. The Unified CVP Server sends Unified ICM a new call request via its VRU PIM that is configured and hosted by the PG. This new call request invokes a routing script in Unified ICM based on the dialed number provided by Unified CVP.

Step 6. The Unified ICM routing script determines that the caller must be transferred to the VRU and passes a Connect to VRU request to the PG, which will be forwarded to the ICM Service on the Unified CVP Call Server.

Step 7. PG passes the information provided in Step 6 to the ICM Service on the Unified CVP Call Server.

Step 8. Invitation to Connect to VRU goes from SIP Service back to the SIP Proxy Server requiring the SIP Proxy Server to determine which VXML Gateway based on its routing table should handle the Connect to VRU and subsequent call treatment session for the VRU leg of the call.

Step 9. Invitation (including information about Ingress Gateway) is sent from the SIP Proxy Server to a VXML Gateway, which then connects the audio path back to the Ingress Gateway.

Step 10. The VRU label causes the VXML Gateway to fire off an application dial-peer, which starts the VRU or application leg of the call. The VXML Gateway connects to the Unified CVP Call Server via HTTP and requests instructions for treating the connected call. This HTTP new call request is handled by the Unified CVP Server’s IVR Service, which then passes this request to the Unified CVP Server’s ICM Service.

Step 11. ICM Service sends Request Instructions to Unified ICM via the PG.

Step 12. Unified ICM continues the script that was started in Step 5 and processes additional nodes that produce Run Script requests to the Unified CVP Server’s ICM Service. It hands these instructions over to the Unified CVP Server’s IVR Service that converts them into VXML pages that are forwarded back to the VXML Gateway for rendering and execution. This process can also include prompt and collect instructions and continues between Unified ICM, Unified CVP, and the VXML Gateway until an agent becomes available. The VoiceXML Gateway also fetches any media files requested in the VXML pages from the media server (refer to the top of Figure 3-12).

Step 13. The agent becomes available, so Unified ICM dequeues the call and asks to be disconnected from the VXML Gateway. Unified ICM passes a connect-to-agent request to the Unified CVP Server’s ICM Service via the VRU PG.

Step 14. PG passes the information provided in Step 13 to the ICM Service on the Unified CVP Call Server. The ICM Service passes this connect request to the Unified CVP Server’s SIP Service.

Step 15. The Unified CVP Server’s SIP Service passes this VRU disconnect request to the SIP Proxy Server.

Step 16. The SIP Proxy Server passes a disconnect message to the VXML Gateway. SIP Service passes a connect-to-agent request to the SIP Proxy Server. The SIP Proxy Server passes this connect-to-agent request back via a SIP INVITE to the Cisco Unified Communications Manager Subscriber server responsible for handling the configured SIP Trunk. Because the audio path was torn down between the Ingress Gateway and the VXML Gateway, a new one is established between the Ingress Gateway and the Unified CCE Agent IP Phone hosted on the CUCM cluster.

Step 17. Unified Communications Manager informs the PG that a call was delivered to a Unified CCE Agent.

Step 18. PG notifies Unified ICM that a call has been delivered to the Unified CCE Agent.

Although a previous call flow detailed how the Comprehensive model uses a SIP Proxy Server, a SIP Proxy Server is an optional non-native component. This indicates that a second call flow can occur when a SIP Proxy is not part of the solution. Figure 3-13 provides a look at this call flow, which is similar to the previous call flow (refer to Figure 3-12).

Following are the details for the steps previously referenced:

Step 1. The call arrives from either the PSTN or a VoIP connection to the gateway.

Step 2. The Ingress Gateway sends a SIP INVITE message to the Unified CVP Call Server’s SIP Service.

Step 3. The SIP Service sends a new call request to Unified ICM via the Unified CVP Server ICM Service and the VRU PG.

Step 4. The Unified CVP Server sends Unified ICM a new call request via its VRU PIM configured and hosted by the PG. This new call request invokes a new incoming dialed number that invokes a routing script in Unified ICM.

Step 5. The Unified ICM routing script determines that the caller must be transferred to the VRU and passes a Connect to VRU request to the PG, which will be forwarded to the ICM Service on the Unified CVP Call Server.

Step 6. PG passes the information provided in Step 5 to the ICM Service on the Unified CVP Call Server.

Step 7. The Unified CVP Server’s SIP Service determines which VXML Gateway should handle the Connect to VRU and the subsequent call treatment session by examining it’s local static SIP routing table configured on the all Server.

Step 8. The VRU label causes the VXML Gateway to fire off an application dial-peer, which starts the VRU or application leg of the call. The VXML Gateway connects to the Unified CVP Call Server via HTTP and requests instructions for treating the connected call. This HTTP new call request is handled by the Unified CVP Server’s IVR Service, which then passes this request to the Unified CVP Server’s ICM Service.

Step 9. The ICM Service sends Request Instructions to Unified ICM via the PG.

Step 10. Unified ICM continues the script that was started in Step 5 and processes additional nodes that produce Run Script requests to the Unified CVP Server’s ICM Service, which then hands these instructions over to the Unified CVP Server’s IVR Service that converts them into VXML pages forwarded back to the VXML Gateway for rendering and execution. This process can also include prompt and collect instructions and continues between Unified ICM, Unified CVP, and the VXML Gateway until an agent becomes available. The VoiceXML Gateway also fetches any media files requested in the VXML pages from the media server (refer to the top of Figure 3-13).

Step 11. The agent becomes available, so Unified ICM dequeues the call and requests to be disconnected from the VXML Gateway. Unified ICM passes a connect-to-agent request to the Unified CVP Server’s ICM Service via the PG.

Step 12. PG passes the information provided in Step 11 to the ICM Service on the Unified CVP Call Server. The ICM Service passes this connect request to the Unified CVP Server’s SIP Service.

Step 13. The Unified CVP Server’s SIP Service passes disconnect to the VXML Gateway. The SIP Service then passes the connect-to-agent request via a SIP INVITE to the Cisco Unified Communications Manager Server responsible for handling the configured SIP Trunk for the cluster. Because the audio path was torn down between the Ingress Gateway and the VXML Gateway, a new one is established between the Ingress Gateway and the Unified CCE Agent IP Phone hosted on the CUCM cluster.

Step 14. Unified Communications Manager informs the PG that a call was delivered to a Unified CCE agent.

Step 15. PG notifies Unified ICM that a call has been delivered to the Unified CCE Agent.

VoIP Transfers using SIP

Figure 3-14 illustrates how a VoIP transfer is handled when a Unified CCE agent initiates the transfer via its agent desktop application.

The following detailed steps cover two options supported in the configuration of this transfer: the use of an ICM Dialed Number Plan and Unified Communications Manager Route Points. Both options follow the same call flow but are quite different in how they engage during a transfer.

The ICM Dialed Number plan is configured within Unified ICM and enables a dial plan matrix to exist where translations can be configured and scripts can be executed before the Unified Communications Manager is asked to decide how to route the label returned by Unified ICM. This enables a transfer to be intercepted as soon as it is initiated on the agent desktop and keeps the dial plan for the contact center stored inside the Unified ICM database and not entirely within the CUCM database.

A second approach is to use Route Points configured within CUCM. This approach is far less desirable simply because of the amount of provisioning and that the dial plan exists both in Unified ICM and Unified Communications Manager. It increases the difficulty around provisioning and troubleshooting the solution.

The details are included in these steps:

Step 1. The Unified CCE Agent initiates a transfer, either by dialing a route point configured on CUCM or dialing a number that has been configured in the ICM Dialed Number Plan. For the route point, because it is under the control of the Communications Manager PG, ICM is notified when the route point is called, which kicks off a routing script. For the ICM Dialed Number Plan, the agent desktop application sends the dialed digits via the Computer Telephony Integration Object Server (CTIOS) Server, which interacts with ICM without CUCM knowing yet that a transfer has been initiated.

Step 2. Unified ICM executes a transfer script associated with either the route point dialed or the result of the number mapping configured in the ICM Dialed Number Plan.

Step 3. The Unified ICM script executed in Step 2 either finishes by finding an available Unified CCE agent and returns the DN of that agents phone, or it returns a label that is then sent by CUCM to a Unified CVP Call Server to gain call control on the new call transfer leg.

Step 4. CUCM matches the label returned by Unified ICM in Step 3 and determines that it must be sent to the SIP Proxy Server via the SIP trunk configured for the CUCM cluster.

Step 5. The SIP Proxy Server consults its routing table and determines that the label dialed by CUCM in Step 4 must be sent to a Unified CVP Call Server and processed by its internal SIP Service.

Step 6. The Unified CVP Call Server’s SIP service accepts the SIP INVITE from the SIP Proxy Server and hands the existing call request over to the ICM Service, which forwards it to the VRU PG.

Step 7. The Unified CVP Server sends Unified ICM an existing call request via its VRU PIM that is configured and hosted by the PG. This existing call request causes Unified ICM to continue the execution of the script that began in Step 2.

Step 8. The Unified ICM routing script determines that the caller must be transferred to the VRU and passes a Connect to VRU request to the PG, which will be forwarded to the ICM Service on the Unified CVP Call Server. The new label generated here is for the Unified CVP Server because it is now the routing client. A single SendToVRU Node can be used to generate two labels: one from execution in Step 3 and one from its continued script execution in this step. Unified ICM is smart enough to determine which routing client label to return, and it accomplishes this with a single node in the script.

Step 9. VRU PG passes the information provided in Step 8 to the ICM Service on the Unified CVP Call Server.

Step 10. The Invitation to Connect to VRU goes from SIP Service back to the SIP Proxy Server requiring the SIP Proxy Server to determine which VXML gateway, based on its routing table, should handle the Connect to VRU and subsequent call treatment session for the VRU leg of the call.

Step 11. The Invitation (including information about the Ingress Gateway) goes from SIP Proxy Server to a VXML Gateway, which then connects the audio path back to the transferring the Unified CCE Agent’s phone. The transferring Unified CCE Agents’ Phone establishes audio connection with the VXML Gateway.

Step 12. The VRU label causes the VXML Gateway to fire off an application dial-peer on the VXML gateway, which starts the VRU or application leg of the call. The VXML Gateway connects to the Unified CVP Call Server via HTTP and requests instructions for treating the connected call. This HTTP new call request is handled by the Unified CVP Server’s IVR Service, which then passes this request to the Unified CVP Server’s ICM Service. Steps 11–18 (refer to Figure 3-12) continue to execute enabling the new transfer leg to either be treated on the VXML Gateway or connected to an agent in the new skill group.

SIP Call Flow Ladder Diagram

Figure 3-15 illustrates this model’s call flow, which provides details on how comprehensive it truly is.

In addition to this SIP call flow ending with the call being received by an agent, Figures 3-16 and 3-17 provide a ladder diagram for warm transfers using a CUCM route point to an available agent and to a queue treated by the VXML Gateway, respectively.

Dialing the CUCM route point initiates a connection to the CUCM PG that causes it to immediately execute a script within Unified ICM based on the dialed number of the route point (refer to Figures 3-16 and 3-17). The interaction when an agent is available and the call does not need to be queued to the VRU leg after the CVP has call control and has communicated with Unified ICM on what its next steps should be (refer to Figure 3-16).

Unified ICM discovers that a Unified CCE Agent is unavailable to take the call and instead makes a decision that the call should be queued and treated at the VRU (refer to Figure 3-17). Further communication is illustrated for the subsequent VRU or application leg of the call with conversations firing off between the VXML router and the Unified CVP Call Server.

Transfers initiated by using ICM’s Dialed Number Plan are similar except for how they are initiated. Figures 3-18 and 3-19 provide the equivalent ladder diagrams for transfer to an agent or a queue when initiating the transfers using an ICM Dialed Number Plan configuration.

The most important observation with respect to these ladder diagrams is how the transfer actually begins. When an Unified CCE Agent initiates the warm transfer via their agent desktop application, the ICM DNP application is engaged before CUCM must resolve and route the dialed number. ICM DNP enables the dialed number to translate within ICM and even have a script that executes the process of returning a completely different dialed number than the one the agent dialed. This is passed to CUCM for routing. The remainder of the ladder diagram displayed in Figures 3-18 and 3-19 are identical to the previous ones provided in Figures 3-16 and 3-17.

H.323 Protocol-Level and Component Call Flow

Figure 3-20 illustrates how the comprehensive call flow works when using H.323 as the call control protocol. The call closely resembles the previous SIP call flows presented in Figure 3-12. However, because H.323 is a peer-to-peer call control protocol, the gatekeeper provides only admission control services, which is different than how a SIP proxy handles the SIP invites in the SIP call flow. In the H.323 call flow for comprehensive, the gatekeeper replaces the SIP proxy from a call flow perspective. However, it is a mandatory component for H.323. In other words, there is no capability for Unified CVP to bypass the use of a gatekeeper as in the previously illustrated SIP without proxy call flow. Even if a Set transfer label configuration is used with H.323, enabling calls to be sent to the originating gateway during the switch leg of the H.323 call flow, the H.323 service does not go into an UP state unless a gatekeeper is configured. Without the H.323 service active on the call server, H.323 connections cannot be made during the switch leg of a call or connected to a VXML gateway after the VRU leg of the call is engaged. This creates a classic “chicken before the egg” stalemate situation.

Following are the details for the steps previously referenced:

Step 1. The call arrives from either the PSTN or a VoIP connection to the gateway.

Step 2. The Ingress Gateway sends a Registration, Admission, and Status (RAS) request to the H.323 Gatekeeper to find the IP address of the Unified CVP Call Server.

Step 3. The H.323 Gatekeeper executes its call routing decision tree and matches the E.164 number (DNIS) to a registered Unified CVP Call Server. The gatekeeper returns an Admission Confirm (ACF) message containing the IP address of the Unified CVP Call Server to the Ingress Gateway.

Step 4. The Ingress Voice Gateway sends a H.225 call setup message to the Unified CVP Server’s H.323 Service.

Step 5. The Unified CVP Server sends Unified ICM a new call request via its VRU PIM configured and hosted by the PG.

Step 6. This new call request invokes a new incoming dialed number that in turn invokes a routing script in Unified ICM.

Step 7. The Unified ICM routing script determines that the caller must be transferred to the VRU and passes a Connect-to-VRU request to the PG, which will be forwarded to the ICM Service on the Unified CVP Call Server.

Step 8. PG passes the information provided in Step 6 to the ICM Service on the Unified CVP Call Server.

Step 9. 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 VRU label returned by Unified ICM.

Step 10. The H.323 Gatekeeper executes its call routing decision tree and matches the VRU label to a registered VoiceXML Gateway. The gatekeeper returns an Admission Confirm (ACF) message containing the IP address of the VoiceXML Gateway to the Unified CVP Call Server.

Step 11. The Unified CVP Server’s H.323 Service sends an H.225 setup message to the VoiceVXML Gateway returned in Step 10 by the Gatekeeper’s ACF message.

Step 12. The VRU label causes the VXML Gateway to fire off an application dial-peer on the VXML Gateway, which starts the VRU or application leg of the call. The VXML Gateway connects to the Unified CVP Call Server via HTTP and requests instructions for treating the connected call. This HTTP new call request is handled by the Unified CVP Server’s IVR Service, which then passes this request to the Unified CVP Server’s ICM Service.

Step 13. ICM Service sends Request Instructions to Unified ICM via the PG.

Step 14. Unified ICM continues the script that was started in Step 7. It processes additional nodes that produce Run Script requests to the Unified CVP Server’s ICM Service, which then hands these instructions over to the Unified CVP Server’s IVR Service that converts them into VXML pages forwarded back to the VXML Gateway for rendering and execution. This process can also include prompt and collect instructions and continues between Unified ICM, Unified CVP, and the VXML gateway until an agent becomes available. The VoiceXML Gateway also fetches any media files requested in the VXML pages from the media server (refer to the top of Figure 3-20).

Step 15. An agent becomes available, so Unified ICM dequeues the call and asks to be disconnected from the VXML Gateway. Unified ICM passes a Connect-to-Agent request to the Unified CVP Server’s ICM Service via the VRU PG.

Step 16. PG passes the information provided in Step 15 to the ICM Service on the Unified CVP Call Server. The ICM Service passes this connect request to the Unified CVP Server’s IVR Service.

Step 17. The Unified CVP Server’s IVR Service requests the H.323 Service to transfer the caller to the dialed number of the selected agent or Egress Gateway. The H.323 service then sends a RAS message to the H.323 Gatekeeper to find the desired endpoint, either an Egress Gateway or a H.323 CUCM trunk. The gatekeeper then returns an ACF message containing the IP address of the termination point. This causes the Unified CVP Server’s H.323 service to send a H.225 call setup message to the termination point. Because the audio path was torn down between the Ingress Gateway and the VXML Gateway, a new one is established between the Ingress Gateway and an Egress Gateway or a Unified CCE Agent IP Phone hosted on the CUCM cluster.

Step 18. The Unified Communications Manager notifies its Call Manager PG that the agent has received the call.

Step 19. The Call Manager PG informs Unified ICM that the call was received by the agent.

VoIP Transfers Using H.323

As discussed earlier with VoIP transfers using SIP, H.323 implements the same call flow when using ICM DNP or CUCM Route Points. The only difference in the two call flows is the use of a SIP Proxy for SIP and a gatekeeper for H.323 transfers. In addition, the CUCM server that sets up the transfer call leg also uses a H.323 trunk connected to a gatekeeper versus a SIP trunk connected to a SIP Proxy. Other than these two small differences, the call flow is essentially the same. The SIP INVITE messages are replaced with H.323 ACF messages enabling the Unified CCE agents to connect to either a VoiceXML Gateway for treatment, an Egress Gateway connected to TDM endpoints, or an H.323 CUCM trunk passing the transfer call to an available agent handling a different Unified ICM skill group. The fundamentals that enable Unified CVP to gain call control for the transfer leg exists both in SIP and H.323 transfers. Only the component that holds the dial plan and decision on where the call is transferred changes, in this case from a SIP Proxy to a H.323 Gatekeeper. Figure 3-21 outlines a VoIP transfer when using H.323.

Following are the details for the steps referenced in Figure 3-21:

Step 1. The Unified CCE Agent initiates a transfer, either by dialing a route point configured on CUCM or dialing a number that has been configured in the ICM Dialed Number Plan. For the route point, because it is under the control of the Communications Manager PG, ICM is notified when the route point is called, which invokes a routing script. For the ICM Dialed Number Plan, the agent desktop application sends the dialed digits via the CTIOS server, which interacts with ICM without CUCM knowing yet that a transfer has been initiated.

Step 2. Unified ICM executes a transfer script associated with either the route point dialed or the result of the number mapping configured in the ICM Dialed Number Plan.

Step 3. The Unified ICM script executed in Step 2 either finishes by finding an available Unified CCE agent and returns the label of the agents extension, or it returns a label that must then be sent by CUCM to a Unified CVP Call Server to gain call control on the new call transfer leg.

Step 4. CUCM matches the label returned by Unified ICM in Step 3 and determines that it must be checked against the gatekeeper accessible via a RAS message over an H.323 trunk configured for the CUCM cluster.

Step 5. The H.323 Gatekeeper executes its call routing decision tree and matches the E.164 number (DNIS) to a registered CVP Call Server and processed by its internal H.323 Service. The H.323 Gatekeeper returns an ACF message to the CUCM subscriber processing the H.323 trunk information, which contains the IP address of the Unified CVP Call Server.

Step 6. CUCM sends a H.225 setup message with the Unified CVP Call Server’s H.323 service.

Step 7. The Unified CVP Call Server’s H.323 service hands the existing call request over to the ICM Service, which forwards it to the PG.

Step 8. The Unified CVP Server sends Unified ICM an existing call request via its VRU PIM configured and hosted by the PG. This existing call request causes Unified ICM to continue the execution of the script started in Step 2.

Step 9. The Unified ICM routing script determines that the caller must be transferred to the VRU and passes a Connect-to-VRU request to the PG. This is forwarded to the ICM Service on the Unified CVP Call Server. The new label generated here is for the Unified CVP Server because it is now the routing client. You can use a single SendToVRU Node to generate two labels: one from execution in Step 3 and one from its continued script execution in this step. Unified ICM is smart enough to determine which routing client label to return, and it accomplishes this with a single node in the script.

Step 10. PG passes the information provided in Step 9 to the ICM Service on the Unified CVP Call Server.

Step 11. The message to connect to VRU travels from the H.323 Service back to the H.323 Gatekeeper. Based on its prefix table, it requires the gatekeeper to determine which VoiceXML Gateway should handle the Connect to VRU and subsequent call treatment session for the VRU leg of the call.

Step 12. The Unified CVP Call Server’s H.323 Service sends an H.225 setup message with the VoiceXML Gateway, which then connects the audio path back to the transferring Unified CCE Agent’s phone. The transferring Unified CCE Agents’ phone establishes audio connection with the VXML Gateway.

Step 13. An ACF message is returned to the Unified CVP Call Server’s H.323 service that contains the IP address of the VoiceXML Gateway that should handle the VRU leg of the call.

Step 14. The VRU label causes the VXML Gateway to fire off an application dial-peer on the VXML Gateway, which starts the VRU or application leg of the call. The VXML Gateway connects to the Unified CVP Call Server via HTTP and requests instructions for treating the connected call. This HTTP new call request is handled by the Unified CVP Server’s IVR Service, which then passes this request to the Unified CVP Server’s ICM Service. As shown in Figure 3-20, Steps 13 through 19 continue to execute enabling the new transfer leg to either be treated on the VXML Gateway or connected to an agent in the new skill group.

H.323 Call Flow Ladder Diagram

Figure 3-22 illustrates a call flow ladder diagram when the H.323 protocol is engaged by a Unified CVP comprehensive deployment. This ladder diagram is similar to the diagram presented in Figure 3-15, with the SIP Proxy server replaced by an H.323 Gatekeeper. As noted in the previous section, H.323 transfers using ICM DNP or a CUCM Route Point are exactly the same as they are when using SIP, with the exception of the use of an H.323 trunk and a gatekeeper for admission control.

Figures 3-23 and 3-24 provide a ladder diagram for warm transfers using a CUCM route point to an available agent and to a queue treated by the VXML Gateway, respectively.

All the observations noted for similar ladder diagrams found in Figures 3-16 and 3-17 for SIP-based transfers also apply here. One additional but equally significant observation with H.323 is how the H.323 Gatekeeper is never involved in call setup or control, only providing registration, access, and status services. Because H.323 is a peer-to-peer call control protocol, when the ACF messages are received, the endpoints set up calls between each other. They do not require a proxy or broker to complete on their behalf.

For consistency, Figures 3-25 and 3-26 provide the equivalent ladder diagrams for transfer to an agent or a queue when initiating the transfers using an ICM Dialed Number Plan configuration and H.323.

As in SIP transfers that use ICM DNP, the transfer starts and ends the same way. The usage of the gatekeeper (refer to Figures 3-22 and 3-23) is also identical when employing this type of transfer.

Transfers and Subsequent Call Control

In addition to the transfers managed by Unified ICM, the Comprehensive Deployment model can transfer calls to non-ICM terminations or invoke a Release Trunk Transfer to the PSTN. However, if a call is transferred to a non-ICM controlled termination, call data cannot be passed to the termination, further call control is impossible for the call, and the cradle-to-grave call reporting that Unified ICM gathers is complete. For a Release to Trunk Transfer on the Ingress Voice Gateway, call data or call control cannot be maintained. However, if the call is translation routed to another ICM peripheral, call data and cradle-to-grave reporting can be maintained.

If a transfer fails or the termination device returns a 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 within Unified ICM, enabling a different target to be selected or execution of a remedial action.⁴

The VRU-Only Model

The last functional deployment model for Unified CVP exists for organizations that use advanced PSTN switching services controlled via a Cisco Unified ICM PSTN Network Interface Controller (NIC). There are two Unified ICM PSTN NICs available that enable subsequent call control of calls in the PSTN: the SS7 NIC and the Carrier Routing Service Protocol (CRSP) NIC. These NICs provide Unified ICM the capability to preroute calls intelligently to Unified ICM peripherals (such as ACDs and IVRs) and perform mid-call transfers in the PSTN.⁴ Figure 3-27 shows the components used with this solution and their protocols.

Table 3-4 identifies which components are required, optional, and not used by this model. In addition, the Native column identifies components that are native to the Unified CVP solution.

Table 3-4 Unified CVP VRU-Only Native and Non-Native Component Usage

Component	Required	Optional	Not Used	Native
SIP Service (Call Server)	—	—	Yes	Yes
IVR Service (Call Server)	Yes	—		Yes
ICM Service (Call Server)	Yes	—		Yes
H323 Service (Call Server)	—	—	Yes	Yes
VoiceXML Server	—	Yes	—	Yes
Unified Call Studio	—	Yes	—	Yes
Ingress Gateway	—	Yes	—	—
VXML Gateway	Yes	—	—	—
SIP Proxy	—	Yes	—	—
Gatekeeper	—	Yes	—	—
Operations Console	Yes	—	—	Yes
Reporting Server	—	Yes	—	Yes
ASR/TTS	—	Yes	—	—
Media Server	—	Yes	—	—
DNS Server	—	—	Yes	—
Content Services Switch	—	Yes	—	—
Unified ICM	Yes	—	—	—
Unified Call Manager	—	Yes	—	—
Egress Gateway	—	Yes	—	—

Although Table 3-4 lists the Unified Communications Manager and Egress Gateway as optional components, typically at least one of these components exists to enable a call to be transferred to either a legacy ACD agent via an Egress Gateway or to a Unified CCE Agent hosted by a Unified Communications Manager cluster. The component to be deployed depends entirely on the organization’s requirements. In addition, the use load balancers, media servers, and even an ASR/TTS Server are also optional because the Unified CVP VXML Gateways can be configured in such a way to enable them to operate without these components. For ASR/TTS, this would be true only if the organization does not have requirements to perform ASR/TTS treatment for incoming calls. If the IOS Ingress Gateway does not perform VoiceXML Gateway duties, a SIP Proxy or H.323 Gatekeeper can be used to route the VRU label to an available VoiceXML Gateway. The most important takeaway for this model is that Unified CVP does not perform call control for the switch leg of the call. The PSTN Switch or a Cisco Packet Data Network Gateway PGW with Unified ICM handles all call control and prerouting for the switch leg of the call leaving Unified CVP to handle only the VRU leg of the call—therefore the name for this model. Unified ICM can pass call data between termination points (for screen pop or other intelligent treatment) and provide cradle-to-grave reporting for all calls.

Component Call Flow

This section details the call flow steps performed in a typical VRU-Only implementation. As the name indicates, this call flow focuses on the VRU leg of the call. It leaves the call control and switch leg the responsibility of the PSTN’s carrier switch and Unified ICM. Figure 3-28 illustrates this call flow with an optional SIP Proxy injected to load balance the VRU leg of the call.

Following are the details for the steps referenced in Figure 3-28:

Step 1. The call arrives at the PSTN Switch or PGW.

Step 2. The PSTN Switch sends a new-call message to Unified ICM via either a CRSP NIC or a SS7 NIC.

Step 3. The NIC forwards the request to Unified ICM where a routing script is invoked based on the dialed number provided by the PSTN Switch.

Step 4. This routing script uses either a Send to VRU node or a Translation Route to VRU node to send a result back to the ICM PSTN NIC.

Step 5. The NIC sends the result back to the PSTN Switch to have the call routed to the Unified CVP Ingress Voice Gateway. Depending on 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 a correlation ID.

Step 6. The PSTN routes the call to an available Ingress Voice Gateway port. At this point in the call flow, the VRU leg is beginning because the switch leg was completed when Step 5 was executed.

Step 7. The Ingress Voice Gateway performs normal inbound POTS dial-peer matching to deliver the call to an available VoiceXML Gateway port. It is at this point that the use of a SIP Proxy or H.323 Gatekeeper can be used to aid in the load balancing and routing of the call. Figure 3-28 illustrates the use of a SIP Proxy. It also assumes that the Ingress Gateway and VoiceXML Gateway are separate devices.

Step 8. The SIP Proxy extends an INVITE message to the VoiceXML Gateway to terminate the call between it and the Ingress Gateway.

Step 9. The SIP INVITE is forwarded from the SIP Proxy Server to a VXML Gateway, which then connects the audio path back to the Ingress Gateway.

Step 10. The VRU label causes the VXML Gateway to fire off an application dial-peer on the VXML Gateway, which starts the VRU or application leg of the call. The VXML Gateway connects to the Unified CVP Call Server via HTTP and requests instructions for treating the connected call. This HTTP new call request is handled by the Unified CVP Server’s IVR Service, which then passes this request to the Unified CVP Server’s ICM Service.

Step 11. The Unified CVP Call Server’s ICM Service sends a Request Instructions message to the VRU PG.

Step 12. The Unified CVP Server sends the Unified ICM a new call request via its VRU PIM configured and hosted by the PG.

Step 13. Unified ICM continues the script that was initiated in Step 3 and processes additional nodes that produce Run Script requests to the Unified CVP Server’s ICM Service via the VRU PG.

Step 14. The VRU PG provides Run Script requests produced in Step 13 to the ICM Service located on the Unified CVP call server.

Step 15. The ICM Service hands these instructions over to the Unified CVP Server’s IVR Service that converts them into VXML pages that are forwarded back to the VXML Gateway for rendering and execution. This process can also include prompt and collect instructions and continues between the Unified ICM, Unified CVP, and VXML Gateway until an agent becomes available. The VoiceXML Gateway also fetches any media files requested in the VXML pages from the media server (refer to the top of Figure 3-28). Steps 10 through 15 continue until the call is handled or needs to be transferred to an agent or other termination point.

Step 16. 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. This connect message contains either a translation route label or a dialed number plus correlation ID (depending on the PSTN switches capabilities).

Step 17. Upon receipt of the connect message, the PSTN releases the existing call leg with Ingress Gateway and connects the call to the new termination point. In this example call flow, the same Ingress Gateway is used to connect the call to a Unified CCE Agent, so the PSTN connects back to the Ingress Gateway with a different dialed number.

Step 18. The Ingress Voice Gateway performs normal inbound POTS dial-peer matching to deliver the call to an available Unified Communications Manager SIP trunk. It is at this point that the use of a SIP Proxy or H.323 Gatekeeper can be used to aid in the load balancing and routing of the call. Figure 3-28 illustrates the use of a SIP Proxy. It also requires that a SIP trunk be configured on the CUCM cluster pointing at the SIP Proxy server. If a H.323 Gatekeeper is used instead, a H.323 trunk must be configured and registered between the gatekeeper and the CUCM cluster.

Step 19. The SIP Proxy forwards an INVITE message to the CUCM SIP trunk to terminate the call between the SIP trunk and the Ingress Gateway.

Step 20. The Ingress Gateway sets up an audio path with the Unified CCE Agent.

Step 21. CUCM notifies Unified ICM that an agent has received the call.

VoIP Transfers

VoIP transfers in this model are quite similar to the Comprehensive model with the exception of the component that has call control. In the Comprehensive model, Unified CVP has call control, and as illustrated earlier in this chapter, Unified ICM instructs Unified CVP to move the call to a new termination point. However, in the VRU-Only model, the PSTN has call control, so Unified ICM instructs the PSTN via the NIC to move the call to the new termination point. The previous call flow illustrated this beginning at Step 16, when a Unified CCE Agent became available and the call needed to be delivered to that agent. In addition, if a transfer is initiated by a Unified CCE Agent to another Unified CCE Agent on the same CUCM cluster, Unified ICM instructs Unified CM via its PG to transfer the call. As shown in the comprehensive model, this warm transfer leg is a new call leg, and the PSTN does not have call control scope over that type of transfer.

Call Flow Ladder Diagram

Figure 3-29 illustrates a call flow ladder diagram without the use of a SIP Proxy or gatekeeper. The PSTN connects directly to the VoiceXML Gateway, which kicks off the VRU leg of the call.

2. Network VRU Types | Next Section