-
Cisco Customer Voice Portal (CVP) Release 3.1 Solution Reference Network Design (SRND)
-
Preface
-
Introduction
-
CVP Components
-
Deployment Models
-
Sizing
-
Designing CVP for High Availability
-
Call Survivability in Distributed Deployments
-
Call Transfer Options
-
Network Level Considerations (The IP Infrastructure)
-
Interacting with ICM
-
Cisco CallManager Originated Calls - Deployment Models and Sizing Implications
-
Using the GKTMP NIC
-
Gateway Options
-
Design Implications for VoiceXML Server
-
Media File Options
-
Licensing
-
Reporting and Monitoring
-
Glossary
-
Index
-
Feedback
Table Of Contents
Cisco CallManager Originated Calls - Deployment Models and Sizing Implications
Why these Cisco CallManager Originated Calls Are Different
ICM Outbound with Transfer to IVR
Model #1, Standalone Self Service
Model #3a, CVP Call Control with Queue and Collect
Model #3b, CVP Call Control with Queue and Self Service
Cisco CallManager Configuration
Cisco CallManager Originated Calls - Deployment Models and Sizing Implications
This chapter covers the following topics:
•
Why these Cisco CallManager Originated Calls Are Different
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
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:
•
•
•
Note
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.
2.
3.
4.
5.
6.
7.
Note
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:
•
•
•
•
•
•
•
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
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.
13.
14.
15.
16.
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:
•
•
•
•
•
•
•
•
•
•
1.
2.
3.
4.
5.
6.
7.
8.
Now assume that the call needs to be queued:
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
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
•
•
Note
•
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:
•
•
•
Network Level
•
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.
