Cisco Unified Customer Voice Portal (CVP) 4.x Solution Reference Network Design (SRND)
Calls Originated by Cisco Unified Communications Manager
Downloads: This chapterpdf (PDF - 386.0KB) The complete bookPDF (PDF - 2.46MB) | Feedback

Calls Originated by Cisco Unified Communications Manager

Table Of Contents

Calls Originated by Cisco Unified Communications Manager

Differences in Calls Originated by Cisco Unified Communications Manager

Customer Call Flows

Unified ICM Outbound Calls with Transfer to IVR

Internal Help Desk Calls

Warm Consultative Transfers

Protocol Call Flows

Model #1: Standalone Self-Service

Model #2: Call Director

Model #3a: Comprehensive Using ICM Micro-Apps

Model #3b: Comprehensive Using CVP VoiceXML Server

Deployment Implications

Unified ICM Configuration

Hosted Implementations

Cisco Unified Communications Manager Configuration

Sizing

Unified CVP Call Servers

Gateways

MTP Resources


Calls Originated by Cisco Unified Communications Manager


This chapter covers the following topics:

Differences in Calls Originated by Cisco Unified Communications Manager

Customer Call Flows

Protocol Call Flows

Deployment Implications

Differences in Calls Originated by Cisco Unified Communications Manager

A call originated by Cisco Unified Communications Manager (Unified CM) first enters the Unified ICM system when someone dials a Unified CM route point that is associated with the JTAPI interface into Unified ICM. Such calls initiate a Unified ICM routing script that can be used to place the caller into queue or into a self-service application, select an available agent, invoke Application Gateway transactions, and so forth. A call invoked through the JTAPI interface to Unified ICM is a typical post-route request; it provides a dialed number, ANI, variables, and so forth, and returns a label. Unified CM then delivers the call to the destination specified by the returned label. As with other ACD post-route requests, the exchange ends there. Unified ICM has no ability to send a subsequent label to that Unified CM unless Unified CM issues another post-route request.

This limitation is the first difference between calls originated by Unified CM and calls originated through a Unified CVP ingress gateway. Unified CVP can continue to route and re-route the call as many times as necessary. For this reason, when calls are originated from Unified CM, routing client responsibilities should be handed off to Unified CVP as soon as possible.

The second difference has to do with how calls are transferred to a VRU. ACD routing clients such as Unified CM may be transferred only by using a TranslationRouteToVRU label. When Unified CVP is the routing client, it can handle Translation Route labels as well as the Correlation ID labels that are generated by SendToVRU nodes.

The next sections provide more details on these differences.

Customer Call Flows

The following types of calls are originated by Unified CM and must be treated differently than calls originated by Unified CVP:

Unified ICM Outbound Calls with Transfer to IVR

Internal Help Desk Calls

Warm Consultative Transfers

Unified ICM Outbound Calls with Transfer to IVR

The Cisco Unified CCE Outbound Dialer introduces an outbound call by impersonating a Skinny Client Control Protocol (SCCP) phone and asking Unified CM to place the outbound call. When it detects that a person has answered, it transfers the call to a Unified CCE destination, taking itself out of the loop. If the customer requirement is to provide a Unified CVP message or a self-service application to the called party, then the call is transferred to Unified CVP using a Unified CM route point. This process fits the definition of a call originated by Unified CM.

Internal Help Desk Calls

Enterprises that place IP phones on employees' desks often want to provide those employees with the capability to call into a self-service application. An example might be an application that allows employees to sign up for health benefits. Or the employee might be trying to reach an agent, such as the IT help desk, and ends up waiting in queue. Both of these scenarios result in calls originating from Unified CM to Unified CVP.

The internal caller could also dial into a self-service application hosted on a VoiceXML Server that is deployed using Model #1, Standalone Self-Service. No ICM is involved in this scenario, but it still qualifies as a call originated by Unified CM.

Warm Consultative Transfers

In a typical contact center call flow, most companies want to provide their agents with the ability to transfer callers to a second agent, who might or might not currently be available. There are two ways to do this transfer: blind transfer and warm consultative transfer. In a blind transfer, the agent dials a number and hangs up; the caller then gets connected to the second agent or placed into a queue if necessary. This type of transfer does not involved a call originated by Unified CM.

In a warm transfer, the agent dials a number and is connected to the second agent while the caller is placed on hold. The two agents can talk, then they can conference in the caller, and the first agent can then drop off. If the second agent is not available, it is the first agent (and not the caller) who is placed into a queue. All of this processing can take place without involving Unified CVP, unless the first agent needs to be queued. In that case, the first agent's call must be transferred to Unified CVP, thus creating a call originated by Unified CM.

Protocol Call Flows

This section describes the protocol-level call flows for calls originated by Unified CM in each of the following relevant deployment models:

Model #1: Standalone Self-Service

Model #2: Call Director

Model #3a: Comprehensive Using ICM Micro-Apps

Model #3b: Comprehensive Using CVP VoiceXML Server


Note Model #4, VRU Only with NIC Controlled Routing, is not discussed here because there is no NIC involved with calls originated by Unified CM.


Model #1: Standalone Self-Service

Model #1 does not involve Unified ICM. It arises when a Unified CM user dials a directory number that connects to a Unified CVP VoiceXML gateway and invokes a Unified CVP VoiceXML Server application. The VoiceXML gateway is configured in Unified CM as an H.323 gateway or SIP trunk. The call flow for this model is as follows:

1. A caller dials a route pattern.

2. Unified CM directs the call to the VoiceXML gateway.

3. The VoiceXML gateway invokes a voice browser session based on the configured Unified CVP self-service application.

4. The Unified CVP self-service application makes an HTTP request to the VoiceXML Server.

5. The VoiceXML Server starts a self-service application.

6. The VoiceXML Server and VoiceXML gateway exchange HTTP requests and VoiceXML responses.

7. The caller hangs up.


Note The script must not execute a Transfer node, unless it is to a TDM destination. Transfers to an IP destination will result in an IP-to-IP call, which is not supported.


Model #2: Call Director

Model #2 has no VRU leg; it is all switching. Therefore, calls originated by Unified CM will always be delivered directly to their targets or else rejected. No queuing or self-service is involved.

This model assumes that the call is truly originating from Unified CM. This model excludes calls that originally arrived through a Unified CVP ingress gateway and were transferred to Unified CM, and are now being transferred again. Such situations are rare because Unified CM can usually handle those transfers itself. There are exceptions, however, such as when the target is an ACD other than Unified CM, but those situations are not covered here.

This model requires that the following items be configured:

Unified CM route point that invokes a Unified ICM script

Unified CVP configured as a Type 2 NetworkVRU

VRU translation routes to Unified CVP

Translation route Dialed Number Identification Service (DNIS) numbers configured in the Unified CVP Call Server

Unified CM configured with an H.323 trunk or SIP trunk

An H.323 gatekeeper trunk with MTP enabled, configured in Unified CM

Unified CM route patterns for Translation Route DNIS

The call flow for this model is as follows:

1. A caller dials a route point.

2. Unified ICM invokes a routing script.

3. The routing script encounters a TranslationRouteToVRU node to transfer the call to Unified CVP. (Unified CVP is configured as a Type 2 NetworkVRU.)

4. Unified ICM returns the translation route label to Unified CM.

5. Unified CM consults the gatekeeper, DNS SRV, or SIP Proxy to locate the Unified CVP Call Server.

6. Unified CM connects the call to the Unified CVP Call Server.

7. Unified CM briefly establishes a G.711 media connection between the caller and the Unified CVP H.323 Service (for H.323 only).

8. The routing script encounters a Select or Label node, and it selects a target label.

9. Unified ICM returns the target label to the Unified CVP Call Server (not to the device that issued the route request).

10. The Unified CVP Call Server consults the gatekeeper, DNS SRV, or SIP Proxy to locate the destination device.

11. The Unified CVP Call Server communicates via H.323 or SIP with the target device and instructs Unified CM to establish a media stream to it.

Now consider what happens if the target device issues another route request to Unified ICM. This part of the call flow would not be possible without the initial TranslationRouteToVRU mentioned step 3.

12. Unified ICM invokes a new routing script.

13. The routing script encounters a Select or Label node, and it selects a target label.

14. Unified ICM returns the target label to the Unified CVP Call Server (not to the device that issued the route request).

15. The Unified CVP Call Server consults the gatekeeper, DNS SRV, or SIP Proxy to locate the destination device.

16. The Unified CVP Call Server communicates via H.323 or SIP with the target device and instructs Unified CM to establish a media stream to the device.

Model #3a: Comprehensive Using ICM Micro-Apps

Model #3a involves both call switching and VRU activity. It differs from Model #2, therefore, in that calls must be transferred to the Unified CVP VoiceXML gateway after they are transferred to the Unified CVP Switch leg. Queuing is possible in this model, as is basic prompt-and-collect activity.

This model requires that the following items be configured:

Unified CM CTI route point that invokes a Unified ICM script

Unified CVP configured as a Type 10 NetworkVRU

The CTI route point configured in Unified ICM as a DN with a Type 10 NetworkVRU

The NetworkVRU must have labels for the Unified CVP Switch leg routing client

The NetworkVRU labels must be configured in a gatekeeper or SIP Proxy to point to VoiceXML gateways

Unified CM configured with an H.323 trunk or SIP trunk

The call flow for this model is as follows:

1. A caller dials a route point.

2. Unified ICM invokes a routing script.

3. The routing script encounters a SendToVRU node to transfer the call to Unified CVP. (Unified CVP is configured as a Type 10 NetworkVRU.)

4. Unified ICM returns the VRU label with Correlation ID to Unified CM.

5. Unified CM consults the gatekeeper, DNS SRV, or SIP Proxy to locate the Unified CVP Call Server.

6. The call is connected to the Unified CVP Call Server.

7. Unified CM briefly establishes a G.711 media connection between the caller and the Unified CVP H.323 Service (for H.323 only).

8. Unified ICM sends a VRU transfer label with Correlation ID to the Unified CVP Call Server.

9. The Unified CVP Call Server consults the gatekeeper, DNS SRV, or SIP Proxy to locate the VoiceXML gateway.

10. The Unified CVP Call Server communicates via H.323 or SIP with the VoiceXML gateway and instructs Unified CM to establish a media stream to it.

11. The routing script executes one or more Unified CVP Microapplications via RunExternalScript nodes, plays media files, requests DTMF input, and so forth.

12. While the Unified CVP Microapplications are in progress, a target agent becomes available to take the call.

13. Unified ICM determines a label for the target agent.

14. Unified ICM returns the target label to the Unified CVP Call Server.

15. The Unified CVP Call Server consults the gatekeeper, DNS SRV, or SIP Proxy to locate the destination device.

16. The Unified CVP Call Server communicates via H.323 or SIP with the target device and instructs Unified CM to establish a media stream to it, removing the VoiceXML gateway's media stream.

If the target device later issues another route request to Unified ICM, the call flow is again exactly as described above. The call must again be transferred with Correlation ID via SendToVRU to the Unified CVP Call Server and VoiceXML gateway to create the VRU leg. Microapplications might be executed, and eventually the new target label is delivered to the Unified CVP Switch leg, which transfers the call to that target.

Model #3b: Comprehensive Using CVP VoiceXML Server

Model #3b does not differ significantly from Model #3a as far as call control and signaling are concerned. The only difference is that the Unified CVP Microapplications executed in Model #3b might include subdialog requests to the Unified CVP VoiceXML Server as well. Of course, self-service applications are not likely to be invoked during the period when the call is queued. Any agent selection nodes or queue nodes in the Unified ICM routing script would therefore likely be postponed until after the self-service application has completed and control has returned to the Unified ICM routing script.

Deployment Implications

This section presents guidelines for the following aspects of incorporating calls originated by Unified CM into the deployment:

Unified ICM Configuration

Hosted Implementations

Cisco Unified Communications Manager Configuration

Sizing

Unified ICM Configuration

With Cisco Unified ICM 7.0, if you want Unified CVP to be able to perform subsequent call control, always translation-route the call to Unified CVP as a Type 2 NetworkVRU before delivering the call to its next destination. This practice creates a handoff, putting Unified CVP in charge of subsequent transfers for the call because Unified CM is not able to receive any further labels.

If you want to perform any queuing treatment, prompt and collect, or self-service applications, always follow the above translation route with a SendToVRU node. SendToVRU can sometimes be invoked implicitly by a Queue node or a RunExternalScript node, but you should not rely on that method. Always include an actual SendToVRU node.

With Cisco Unified ICM 7.1, if you want Unified CVP to be able to perform subsequent call control, a translation route is not necessary if you use a Type 10 NetworkVRU. The Type 10 VRU uses the Correlation ID mechanism to perform a transfer from Unified CM to Unified CVP using a SendToVRU node. When the SendToVRU node is used with a Type 10 VRU, an initial transfer to Unified CVP hands off call control to Unified CVP, and then an automatic second transfer to the VRU leg is performed to deliver the call to a VoiceXML gateway for IVR treatment.


Note This call flow and all others in this document assume Cisco Unified ICM 7.0(0) or later.


For additional configuration requirements, see Protocol Call Flows.

Hosted Implementations

Translation routes sent by one ICM router must be received by a peripheral that is connected to the same ICM router. Therefore, you can translation-route a call from a Unified CM at the CICM level into Unified CVP only if Unified CVP is also located at the CICM level. In Hosted environments, this means you must provision Unified CVP Call Servers at the CICM level even if you already have other Unified CVP Call Servers at the NAM level. VoiceXML gateways and gatekeepers can, of course, be shared.

For more details on this subject, see the chapter on Interactions with Cisco Unified ICM, page 5-1.

Cisco Unified Communications Manager Configuration

The following guidelines apply to Unified CM configuration:

Configure a gatekeeper-controlled H.323 trunk, but do not check MTP required. This trunk will be used for inbound calls only. Configure the gatekeeper to send calls to Unified CM using this trunk.

Configure a second gatekeeper-controlled H.323 trunk and check MTP required. This trunk will be used for outbound calls to Unified CVP only. Configure the appropriate route patterns for the Translation Route DNIS or VRU Label with Correlation ID appended. The Correlation ID method is used with a Type 10 VRU, and the route pattern in Unified CM must be configured to allow the extra digits to be appended.

When configuring agent labels, consider which device is the routing client. For cases where the label will be returned directly to Unified CM, then Unified CM must be the routing client. For cases where the label will be sent to Unified CVP, the labels must be associated with each of the Unified CVP Switch leg Call Servers.

Sizing

Most customer implementations are not primarily designed for calls originated by Unified CM. The main driver is usually incoming customer calls, although calls originated by Unified CM are frequently a component, particularly in the case of warm transfers. Remember to consider those calls when sizing equipment.

Unified CVP Call Servers

As with normal incoming calls, Unified CVP Call Servers must be sized to handle two call legs when the call is either in queue or performing self-service activity, and one leg once the call has been delivered to a destination. These rules apply for Unified ICM outbound calls as well as internal help-desk calls.

For warm transfer scenarios, Unified CVP resources are not used for the Unified CM portion of the call unless the first agent needs to go into queue. At that point two call legs are engaged, and once the first agent drops off, both legs are released. These legs are above and beyond those required for the original incoming call. Therefore, it is important to consider what percentage of incoming calls will be warm-transferred and queued, and for how long. Those additional call legs must be considered for sizing purposes.

Gateways

Calls originated by Unified CM do not use ingress gateways at all. Calls are delivered directly from Unified CM to the Unified CVP Call Server. They do, however, use VoiceXML gateways whenever a VRU leg is in use. Therefore, for the purposes of sizing VoiceXML gateways, consider each Unified CM call that is either in queue or conducting self-service activities.

MTP Resources

When H.323 is used, Unified CMs must be sized and configured to allocate an MTP resource for every internal help-desk call, every Unified ICM outbound call that results in a transfer to Unified CVP, and every warm-transfer call that results in queuing of the first agent. Be sure to use separate gatekeeper-controlled H.323 trunks for inbound and outbound calls from Unified CM to Unified CVP, as explained previously. This practice allows you to use MTPs on the outbound trunk only; normal inbound calls do not need an MTP.