Cisco Unified Customer Voice Portal (CVP) 7.x Solution Reference Network Design (SRND)
Calls Originated by Cisco Unified Communications Manager
Downloads: This chapterpdf (PDF - 389.0KB) The complete bookPDF (PDF - 3.14MB) | 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 and Conferences

Protocol Call Flows

Model #1: Standalone Self-Service

Model #2: Call Director

Model #3a: Comprehensive Using ICM Micro-Apps

Model #3b: Comprehensive Using Unified CVP VXML Server

Deployment Implications

Unified ICM Configuration

Hosted Implementations

Cisco Unified Communications Manager Configuration

Gatekeeper or SIP Proxy Dial-Plan Configuration

Sizing

Gateways

MTP Resources


Calls Originated by Cisco Unified Communications Manager


Last revised on: August 18, 2009

 

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.

Locations-based call admission control is not supported for IP originated calls, including calls where the agent performs a warm transfer or conference

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 and Conferences

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 Unified CVP VXML 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 and Conferences

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 or warm consultative transfer (or conference).

In a blind transfer, the first 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 involve a call originated by Unified CM, and it is called Network Transfer. Network Transfer is also discussed in the section on ICM Managed Transfers, page 10-4.

In a warm transfer or conference, 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.


Note Multicast Music on Hold is not supported by Unified CVP.


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 Unified CVP VXML 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 VXML 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 Unified CVP VXML Server.

5. The Unified CVP VXML Server starts a self-service application.

6. The Unified CVP VXML 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 Unified CVP VXML 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 VXML 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 hand-off, 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 or SIP trunk. With Unified CVP 4.1 and later releases, an MTP is no longer required for H.323 trunks. Configure the gatekeeper to send calls to Unified CM using this trunk.

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, such as adding a ! to the end of the route pattern.

When configuring agent labels, consider which device is the routing client. For cases where the label will be returned directly to Unified CM, 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.

Gatekeeper or SIP Proxy Dial-Plan Configuration

If you are using a gatekeeper or SIP Proxy, the VRU label associated with the Unified CM routing client must be different than the VRU label associated with the Unified CVP routing clients. This is because the VRU label for a call originated by Unified CM is intended to send the call to the Unified CVP Call Server to hand off call control first, whereas the VRU label for a call where Unified CVP is already the routing client is intended to be sent to the VXML gateway for treatment. Once the call has been sent to Unified CVP to hand off call control, Unified CVP does a subsequent transfer to the VRU label associated with the Unified CVP routing client and delivers the call to the VXML gateway for treatment.

The dial plan in your gatekeeper or SIP Proxy should be structured as follows:

[Unified CM routing client VRU label + correlation-id]: pointing to CVP server(s)

[CVP routing client VRU label + correlation-id]: pointing to VXML gateway(s)

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.

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

With Unified CVP 4.1 and later releases, an MTP is no longer needed for calls originated by Unified CM H.323 trunks.

The Unified CM SIP trunk allocates an MTP resource when it determines the endpoints have not negotiated a common DTMF method. If one endpoint supports RFC 2833 and the other supports out-of-band KPML events, the SIP trunk allocates an MTP resource to convert the DTMF tones. For video calls, this might cause loss of video media if the MTP resource allocated does not support video passthrough. The IPVMS-based software MTP resource does not currently support video passthrough; however, a Cisco IOS Software MTP resource can be configured to support these calls.

Unified CVP requires the SIP trunk to be set for RFC 2833 due to one-way audio issues found in testing, as well as a lack of support for KPML on the Radvision IVP component. The Video Conference Bridge does not support RFC 2833 DTMF, and some of the IP phones (such as the Cisco Unified IP Phone 7985) do not support RFC 2833 DTMF either. Therefore, it is possible to experience video loss with such endpoints in use if the correct MTP resource is not configured for use on Unified CM.