This document describes load balance between two IP Interactive Voice Response (IVR) units. It centers on the even distribution of calls that arrive between two IP IVRs so no single IP IVR is overwhelmed through the Translation Route to VRU (voice response unit) node in a Cisco IP Contact Center (IPCC) Enterprise Edition environment.
Readers of this document should have knowledge of these topics:
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
For more information on document conventions, refer to Cisco Technical Tips Conventions.
Some of the parameters below can be used to route calls to the IP IVR, when a script is developed for the Translation Route to VRU node:
Confirm the peripheral is online, as shown in Figure 1. Figure 1 – Formula Editor—Peripheral Online
Check the available idle ports for a specific trunk group on the IP IVR. Then select the IP IVR with either the maximum idle trunks or the minimum trunks in service. In Figure 2, the choice is based on the maximum idle trunks. Figure 2 – Formula Editor—Maximum of Trunk Idle or Minimum of Trunk in Service
Check the peripheral status, as shown in Figure 3. If everything runs normally, the peripheral status number should be equal to zero, or the peripheral status number should be less than the number of sub-systems which are expected to be offline. For example, IP IVR is installed with database capability. If the database is not used, the database sub-system is offline. This would increment the peripheral status number. Figure 3 – Formula Editor—Peripheral Status
The purpose is to achieve load balance between two IP IVRs, as shown in Figure 4.
Figure 4 – Load Balance Between Two IP IVRs
Figure 5 shows an actual ICM script. First the call arrives at the Translation Route to VRU node. The call is then routed to either the Run VRU Script node (indicated by the B arrow) or the Run VRU Script node (indicated by the A arrow). In this example, the failure condition is not taken into consideration.
Figure 5 – Actual Script—Call Flow
In the configuration process of the Translation Route to VRU node, you can change the type of target, click Change in the Select Type field, as shown by the A arrow in Figure 7. The Select Type dialog box opens, as shown in Figure 6.
For Target Type, select Enterprise Service, Service, or Service Array. In this example, Service is selected.
For call distribution, select Distribute Among Targets or Select Most Eligible Target, indicated by the A arrow in Figure 6. Specify whether the Translation Route to VRU node is to act like a Select or Distribute node. If you select the Distribute Among Targets option, the Translation Route to VRU node is to act like a Distribute node, which distributes calls among the targets based on the relative values. If you select the Select Most Eligible Target option, you must define the following:
Figure 6 – Select Type
Whether to pick the target with the maximum value or the minimum value, as shown by the B arrow in Figure 6.
A formula that determines which target is to be accepted.
The type of target search, as shown by the C arrow in Figure 6.
In this example, the first step is to check if the peripheral is online, as shown in the Consider If column in Figure 7. Next, check the maximum idle trunks, as shown under the Select Max Value Of column in Figure 7. The maximum value option is set in the Success connection field, indicated by the B arrow in Figure 6. When you configure the Translation Route to VRU node for multiple routes, it is necessary to select Per-target success Connections in the Success connection field.
Figure 7 – Translation Route to VRU Properties—Selection Criteria