Cisco Customer Voice Portal (CVP) Release 3.1 Solution Reference Network Design (SRND)
Cisco CallManager Originated Calls - Deployment Models and Sizing Implications
Downloads: This chapterpdf (PDF - 209.0KB) The complete bookPDF (PDF - 1.96MB) | Feedback

Cisco CallManager Originated Calls - Deployment Models and Sizing Implications

Table Of Contents

Cisco CallManager Originated Calls - Deployment Models and Sizing Implications

Why these Cisco CallManager Originated Calls Are Different

Call Flows (customer)

ICM Outbound with Transfer to IVR

Internal Help Desk

Warm Consultative Transfer

Call Flows (protocol)

Model #1, Standalone Self Service

Model #2, CVP Call Control

Model #3a, CVP Call Control with Queue and Collect

Model #3b, CVP Call Control with Queue and Self Service

Deployment Implications

ICM Configuration

Hosted Implementations

Cisco CallManager Configuration

Network Level

Sizing

CVP Call Servers

Gateways

MTP Resources


Cisco CallManager Originated Calls - Deployment Models and Sizing Implications


This chapter covers the following topics:

Why these Cisco CallManager Originated Calls Are Different

Call Flows (customer)

Call Flows (protocol)

Deployment Implications

Why these Cisco CallManager Originated Calls Are Different

A Cisco CallManager-originated call is any call which is first introduced into the ICM system by dialing a Cisco CallManager route point that is associated with the JTAPI interface into ICM.

Such calls initiate an ICM routing script which can be used to place the caller into queue or into a self service application, select an available agent, invoke App Gateway transactions, and so forth. A call invoked through the JTAPI interface to ICM is a typical postroute request: it provides a dialed number, ANI, variables, etc., and returns a label. Cisco CallManager then delivers the call to the destination specified by the returned label. As with other ACD postroute requests, the exchange ends there. ICM has no ability to send a subsequent label to that Cisco CallManager, unless Cisco CallManager issues another postroute request.

This limitation is the first difference between Cisco CallManager-originated calls and calls which originate through a CVP ingress gateway. CVP can continue to route and re-route the call as many times as necessary. For this reason, when calls are originated from Cisco CallManager, it is important to hand off routing client responsibilities to CVP as soon as possible.

The second difference has to do with how calls are transferred to a VRU. ACD routing clients such as Cisco CallManager might only be transferred using a TranslationRouteToVRU label. When CVP is the routing client, it can handle translation route labels as well as the CorrelationID labels which are generated by SendToVRU nodes.

The next sections provide more details on these differences.

Call Flows (customer)

The following types of calls are Cisco CallManager-originated calls, and must be treated differently than CVP-originated calls:

ICM Outbound with Transfer to IVR

Internal Help Desk

Warm Consultative Transfer

ICM Outbound with Transfer to IVR

The IPCC Outbound Dialer introduces an outbound call by impersonating an SCCP phone and asking Cisco CallManager to place the outbound call. When it detects that a person has answered, it transfers the call to an IPCC destination, taking itself out of the loop. If the customer requirement is to provide a CVP-based message or self service application to the callee, then the call is transferred to CVP using a Cisco CallManager route point. This fits the definition of a Cisco CallManager-originated call.

Internal Help Desk

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 which allows employees to sign up for health benefits. Or, the employee might actually be trying to reach an agent, such as the IT HelpDesk, and ends up waiting in queue. Both of these scenarios result in Cisco CallManager-originated calls to CVP.

We will also discuss scenarios where the internal caller is dialing into a self service application which is hosted on a VoiceXML Server which is deployed using Model #1, Standalone Self Service. No ICM is involved in this scenario, but it still qualifies as a Cisco CallManager-originated call.

Warm Consultative Transfer

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: blind transfer and warm transfer. In a blind transfer, the agent dials a number and hangs up; the caller then gets connected to the second agent, or placed in queue if necessary. There is no Cisco CallManager-originated call involved in this type of transfer.

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 who is placed into queue, not the caller. All of this processing can take place without involving CVP, except if the first agent needs to queue. In that case, the first agent's call must be transferred to CVP, creating a Cisco CallManager-originated call.

Call Flows (protocol)

We will now present the protocol-level call flow for Cisco CallManager-originated calls under each relevant deployment mode:

Model #1, Standalone Self Service

Model #2, CVP Call Control

Model #3a, CVP Call Control with Queue and Collect

Model #3b, CVP Call Control with Queue and Self Service


Note The Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service, is not discussed here since there is no NIC involved in Cisco CallManager-originated calls.


Model #1, Standalone Self Service

Model #1 does not involve ICM. It arises when a Cisco CallManager user dials a directory number which connects him to a CVP VXML gateway and invokes a CVP VoiceXML Server application. The VXML gateway is configured in Cisco CallManager as an H.323 Gateway device.

1. Caller dials a route pattern

2. Cisco CallManager directs the call to the VXML gateway

3. VXML gateway invokes a voice browser session based on the configured CVP self service application

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

5. VoiceXML Server starts a self service application

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

7. 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, CVP Call Control

Model #2 has no VRU leg. It is all switching. Therefore, Cisco CallManager-originated calls will always be delivered directly to targets, or rejected. No queuing or self service are involved.

We assume here that the call is truly originating from Cisco CallManager. This excludes calls which originally arrived through a CVP ingress gateway and were transferred to Cisco CallManager, and are now being transferred again. Such situations are rare, because Cisco CallManager can usually handle those transfers itself. There are exceptions however, such as when the target is a non-Cisco CallManager ACD - but that situation will not be covered here.

The following items must be configured for this flow to work:

Cisco CallManager route point which invokes an ICM script

CVP is a Type 2 NetworkVRU

VRU translation routes to CVP

Translation route DNISs configured in CVP Call Server

CVP Call Server configured as H.323 gateway in Cisco CallManager

Translation route DNISs configured in Cisco CallManager to request destination from gatekeeper

H.323 gatekeeper trunk configured in Cisco CallManager with MTP enabled

1. Caller dials a route point

2. ICM invokes a routing script

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

4. ICM returns the translation route label to Cisco CallManager

5. Cisco CallManager consults gatekeeper, gets address of CVP Call Server

6. Cisco CallManager connects the call to the CVP Call Server

7. Cisco CallManager briefly establishes a g.711 media connection between the caller and the CVP Voice Browser

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

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

10. CVP Call Server consults the gatekeeper for the address of the target device

11. CVP Call Server communicates via H.323 with target device and instructs Cisco CallManager to establish a media stream to it, removing the CVP Call Server's media stream

Now consider what happens if the target device issues another route request to ICM. This part would not be possible without the initial TranslationRouteToVRU shown above in step 3.

12. ICM invokes a new routing script

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

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

15. CVP Call Server consults the gatekeeper for the address of the target device

16. CVP Call Server communicates via H.323 with target device and instructs Cisco CallManager to establish a media stream to the device.

Model #3a, CVP Call Control with Queue and Collect

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

The following items must be configured for this flow to work:

Cisco CallManager route point which invokes an ICM script

CVP is a Type 2 NetworkVRU

VRU translation routes to CVP

Translation route DNIS's configured in CVP Call Server

Above route point configured in ICM as a DN with a Type 7 NetworkVRU

Above NetworkVRU has labels for CVP switch leg routing client

Above NetworkVRU labels configured in gatekeeper to point to VXML gateways

CVP Call Server configured as H.323 gateway in Cisco CallManager

Translation route DNIS's configured in Cisco CallManager to request destination from gatekeeper

H.323 gatekeeper trunk configured in Cisco CallManager with MTP enabled

1. Caller dials a route point

2. ICM invokes a routing script

3. The routing script encounters a TranslationRouteToVRU node, to transfer the call to CVP Call Server switch leg

4. ICM returns the translation route label to Cisco CallManager

5. Cisco CallManager consults gatekeeper, gets address of CVP Call Server

6. Cisco CallManager connects the call to the CVP Call Server

7. Cisco CallManager briefly establishes a g.711 media connection between the caller and the CVP Voice Browser

8. The routing script encounters a Queue node

Now assume that the call needs to be queued:

9. The routing script encounters a SendToVRU node

10. ICM sends a VRU transfer label with Correlation ID to CVP Call Server switch leg

11. CVP Call Server consults gatekeeper, gets address of a VXML gateway

12. CVP Call Server communicates via H.323 with VXML gateway and instructs Cisco CallManager to establish a media stream to it, removing the CVP Call Server's media stream.

13. The routing script executes one or more CVP Microapps via RunExternalScript nodes, plays media files, requests DTMF input, etc.(See protocol level call flow for Model #3a for details in "Deployment Models".)

14. While CVP Microapps are in progress, a target agent becomes available to take the call.

15. ICM determines a label for the target agent

16. ICM returns the target label to CVP Call Server

17. CVP Call Server consults the gatekeeper for the address of the target device

18. CVP Call Server communicates via H.323 with target device and instructs Cisco CallManager to establish a media stream to it, removing the VXML gateway's media stream.

If the target device later issues another route request to ICM, the call flows again exactly as above. The call must again be translation routed to the CVP switch leg Type 2 NetworkVRU, then Correlation ID transferred via SendToVRU to the CVP VXML gateway to create the VRU leg. Microapps might be executed, and eventually the new target label is delivered to the CVP switch leg, which transfers the call to that target.

Model #3b, CVP Call Control with Queue and Self Service

Model #3b does not differ significantly from Model #3a, CVP Call Control with Queue and Collect - at least as far as call control and signalling. The only departure is that the CVP Microapps which are executed might include subdialog requests to the 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 ICM routing script would therefore likely be postponed until after the self service application has completed, and control has returned to the ICM routing script.

Deployment Implications

Here is a sampling of items to be aware of when incorporating Cisco CallManager-originated calls into the deployment:

ICM Configuration

Hosted Implementations

Cisco CallManager Configuration

Network Level

Sizing

ICM Configuration

If you want CVP to be able to be involved in subsequent call control, always translation route the call to CVP, as a Type 2 NetworkVRU, before delivering the call to its next destination. This creates a handoff, putting CVP in charge of subsequent transfers for this call, since Cisco CallManager 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 RunExtScript node, but you should not rely on that always working. Always include an actual SendToVRU node.


Note This and all flows in this document assume ICM 7.0(0) or later.)


See the assumptions in the above protocol level call flows for additional configuration requirements, Call Flows (protocol).

Hosted Implementations

Translation routes sent by one ICM router must be received by a peripheral which is connected to the same ICM router. This means you can only translation route a call from a CICM level Cisco CallManager into CVP if CVP is also located at the CICM level.

In Hosted environments this means you need to provision CVP Call Servers at the CICM level, even if you already have other CVP Call Servers at the NAM level. VXML gateways and gatekeepers can of course be shared.

This subject is covered in great detail in Chapter 9, "Interacting with ICM".

Cisco CallManager Configuration

Cisco CallManager configuration includes:

Remember that the Cisco CallManager will be sending the call to a CVP Call Server, not to a gateway. However, the CVP Call Server must be configured in Cisco CallManager as an H.323 Gateway device. MTP does not need to be turned on for this device.

Configure the gatekeeper as an H.323 Gatekeeper trunk device with MTP enabled. Configure the VRU Translation route DNISs to consult that gatekeeper for routing instructions.

When configuring agent labels, it is important to remember which device is the routing client. For cases where the label will be returned directly to Cisco CallManager, the Cisco CallManager must be the routing client. For cases where the label will be sent to CVP, the labels must be associated with each of the CVP switch leg Call Servers.

Network Level

Codecs: either g.711 or g.729 might be used for the conversation between the caller's IP phone and the VXML gateway. However, for the brief period when the media stream is connected to the CVP Call Server, g.711 must be used.

Sizing

Most customer implementations are not primarily designed for Cisco CallManager-originated calls. The main driver is usually incoming customer calls, though Cisco CallManager-originated calls are frequently a component, particularly in the case of warm transfer. It is easy to forget to size equipment with those calls considered.

CVP Call Servers

As with normal incoming calls, 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 ICM Outbound as well as Internal Help Desk calls.

For warm transfer scenarios, CVP resources are not used for the Cisco CallManager-originated 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 which are required for the original incoming call. Therefore it is important to consider what percentage of incoming calls will be warm-transferred and be queued during that process, and for how long. Those additional call legs need to be considered.

Gateways

Cisco CallManager-originated calls do not use ingress gateways at all. Calls are delivered directly from the Cisco CallManager to the CVP Call Server. They do however use VXML gateways whenever a VRU leg is in use. It is important to consider each Cisco CallManager-originated call which is either in queue or conducting self service activities as a call for the purposes of sizing VXML gateways.

MTP Resources

The Cisco CallManagers must be sized and configured to allocate an MTP resource for every Internal Help Desk call, every ICM Outbound call which results in a transfer to CVP, and every warm transfer call which results in queuing of the first agent. If you follow the Cisco CallManager configuration guidelines presented in this chapter, it is no longer necessary to allocate MTP resources on a per-CVP Call Server basis, as it used to be.