The Unified CCE Gateway PG allows either a site Unified CCE system, or a Cisco Unified Contact Center Express (Unified CCX) system, to connect to a Unified ICM. The Unified ICM parent views either as an ACD.

Figure 1. Unified CCE Gateway PG

For Unified CCE, this is important because it allows a "parent" Unified ICM to monitor and send calls to a "child" Unified CCE system. Previous to the Unified CCE Gateway feature, monitoring this using intelligent (PG based) routing was not possible. This allows better scaling, resiliency, and simpler, more standardized scripting across sites.

The Unified CCE Gateway PG looks to the Unified ICM like any other PG, it does not look like the Unified CCE. It has two different Peripheral types to allow connection to either a "child" Unified CCE system, or a Unified CCX system. These are listed as "Unified CCE Gateway" and "Unified CCX Gateway" respectively in the setup screen for the PG. The Gateway PG does not support third-party call control (CTI) so that all agent desktops, etc. are connected to the child Unified CCE system, or Unified CCX system. The link supports voice only. The child system may support multi-media but the Unified ICM only routes voice calls to the child.

Object tracking is accomplished the same as on all legacy PIMs, through matching Peripheral Numbers on the agent, skill group, and service table. Routing to the child is to peripheral targets (skill groups/services) as with all legacy TDMs, in contrast to the Unified CCE. All normal TDM functionality is supported: Pre-Routing, Pre-Routing with Translation routing, post routing, etc. Third-party call control is the only exception. Full variable passing is done between the parent and child (you can send/receive call variables 1-10 and ECC variables).

Scripting is consistent with traditional PGs, not Unified CCE. Scripts use LAA, MED, target services, and skill groups; but not agents.

Note	NCT is not supported with either the Express or Enterprise Gateway. This is due to the CTI control being on the ACD (Child) rather than on Unified ICM parent.

When a call is queued to a skill group because there are no agents available, the Queue to Skill Group node sets the call's priority. The Queue Priority node can then promote the call's priority based on time the caller has waited. The call can be queued to multiple skill groups with the same or different priorities.

If there are calls in the agent's skill group queues when an agent becomes available, the agent is presented with the highest priority (1-10 with 1 being the highest priority) call that has waited the longest within the skill group(s) that the agent is assigned to.

A script that routes to Unified CCE agents needs to check for an available agent within a skill group. If an agent is not available, then the script should use a Queue to Skill Group node. The script execution ends when an agent becomes available or when the caller disconnects.

You can use the Select node to check for the Longest Available Agent (LAA). However, the Select node cannot check for Minimum Expected Delay (MED) of a service, because Unified CCE skill groups do not have a valid expected delay because the calls in the queue are on Unified IP IVR PG service.

By default, the Queue to Skill Group node uses LAA for agent selection. Do not put LAA Select nodes before or after a Queue to Skill Group node for the same skill group. You can only use this node if the call is not already queued to a skill group.

There is, however, a lengthy workaround to determine the MED for a call using an IF node.

If agents are assigned to base skill groups, use base skill groups in this node.

If the script has both Queue to Skill Group and Queue to Enterprise Skill Group nodes, then do not include skill groups defined within the Queue to Skill Group nodes that belong to the enterprise skill groups that are defined within the Queue to Enterprise Skill Group node.

If the call needs to be taken out of a skill group, then use the Cancel Queuing node. The Cancel Queuing node takes the call out of all the skill groups it is queued to.

Use the Busy node for initial overflow conditions. Do not use this treatment if the call has already received ringback tone or given announcements or music. If a Busy CTI Route point and CTI port are defined on Unified IP IVR and the Cisco Unified Communications Manager, then Unified IP IVR tells Cisco Unified Communications Manager to return a busy signal. If a Busy CTI Route point and CTI port are not defined on Cisco Unified Communications Manager and Unified IP IVR and the call is already connected to an Unified IP IVR port, then Unified IP IVR port plays a busy tone from a .wav file for 30 seconds and then disconnects the call. If the VRU port plays a busy tone from a .wav file then, answer supervision returns to the far end. This causes charges to occur for the call. If the call is a toll free call (for example, 800#), then the Contact Center accrues the charges; otherwise the caller has to pay.

You must define a Busy CTI route point and one CTI port on the Cisco Unified Communications Manager and associated it with the Unified IP IVR user. The one CTI port can be used for multiple calls. In Unified IP IVR Administration, a new CTI Route point of Type Busy and a CTI port need to be defined whose Dialed Numbers match what was previously defined on the Cisco Communications Manager.

Define a label of type busy with a Label field that corresponds to the aforementioned CTI Route point dialed Number in the Cisco Unified Communications Manager and Unified IP IVR.

If the call is not at a VRU port and the Busy CTI Route point is not defined on the Cisco Unified Communications Manager and the Unified IP IVR, and the Unified ICM returns a busy label to the Cisco Unified Communications Manager, the Cisco Unified Communications Manager returns a fast busy to the caller for 30 seconds and then the call is disconnected.

You can use the Ring node for diverting blacklisted callers. It is supported as a post route from the Cisco Unified Communications Manager. The call is given ringback tone until the caller hangs up. No answer supervision is returned for this call because it is not connected to a VRU port. This means that if this is the initial treatment given the caller, then no charges will be accrued for this call.

You need to define a Ring No Answer CTI port group in the Cisco Unified Communications Manager, but you do not have to define CTI ports. In Unified IP IVR Administration, you need to define a new CTI Route Point of Type Ring No Answer whose Dialed Number matches what was previously defined on the Cisco Unified Communications Manager.

Define a label of type Ring with a Label field corresponds to the CTI Route Point Dialed Number in Cisco Unified Communications Manager and Unified IP IVR.

Use the Release Call node for initial overflow conditions. It is supported as a post route from the Cisco Unified Communications Manager. Do not use this node if the call has already received ringback tone or announcements or music. The call is given busy tone for 30 seconds before it is disconnected on the Cisco Unified Communications Manager. No answer supervision is returned for this call because it is not connected to a CTI port. This means that no charges will be accrued for this call.

No configuration needs to be done within the Cisco Unified Communications Manager or Unified IP IVR. No label needs to be defined within Unified ICM.

The End node either tries default routing, or if there is no default label, it sends an error (dialog fail) to the routing client.

You can use the Agent to Agent node for agent to agent transfers; the router checks agent availability before sending the call to the agent. If the agent is not available, the script queues the call to a skill group. You can also use the Agent to Agent node to send a call to the agent: the "caller" is not required to be an agent.

For a transfer to a specific target agent, the initiating agent enters the target agent ID. The DNP entry matching the dialed number (agent ID) must have a DNP type of PBX. For this DNP type, the PIM enters the dialed number (agent ID) into the Caller-Entered Digits (CED) field while sending the route request to the Router. To have the Router handle the call properly, specify the CED field as the location of the agent ID in the Agent to Agent node.

Agent IDs must not match any of the extensions on the Unified Communications Manager cluster. If you make all agent IDs of the same length and begin with the same number, a generic wildcard string can match all agent IDs. With that wildcard string, you need only one entry in the DNP for agent-to-agent routing.

The agent-to-agent node requires that you specify the PIM. If your environment has multiple PIMs, use an agent ID number plan to determine which PIM contains an agent. Agent IDs are associated with a specific PIM and are not unique by themselves. You can set up a consistent agent ID assignment plan (such as, all agent IDs on PIM 1 begin with 1, and so on). That pattern enables you not to repeat agent IDs across the enterprise. Then, you can parse the CED field in the script editor to determine which PIM contains a specific agent.

You do not need the Service node or Enterprise Service node to route calls to Unified CCE agents because services are not required for Unified CCE agents.

Cisco Communications Manager does not support the Scheduled Select node and Divert Label node. You cannot use these nodes to route calls to Unified CCE agents.

Unified CCE relies on the Unified IP IVR to queue the call while it is waiting for an available agent.

The Unified ICM sends the call to the VRU port for queuing:

• To provide the call with a termination point that allows the VoIP Gateway to return the correct signals or messages back to the PSTN.

• Provide announcements or music or expected wait time or initial position in queue to the caller while they are waiting for an agent. Allow the caller an option to leave a message if the caller does not want to wait for an agent.

• To obtain further information from the caller that is not sent from the network

The Unified IP IVR lets Unified ICM know when the caller disconnects through the Event Report Message with an Event Type of either DISCONNECT or ABANDON. When an agent becomes available, Unified ICM automatically instructsthe IVR to route the call to the agent through the Connect message.

Ensure your Unified ICM routing scripts do not reference the default skill group. This ensures that the default skill group does not capture statistics for any Unified ICM-routed calls.

For more information, see Cisco Unified Contact Center Enterprise Installation and Upgrade Guide and Administration Guide for Cisco Unified Contact Center Enterprise.

In a Unified CCE environment, if the router is disconnected from the two PGs (available on either side of the network/site between the routers) and the PG fails, the router cannot receive any information about the failure of the peripheral or about agents who are logged out. In such a scenario, the router uses low frequency heartbeats (60 seconds) to determine the failure of the peripheral and declares the peripheral to be offline at this point. The router discards the real time values for the peripheral (including service, skill group, enterprise agent, and agent state at their last known value) and continues to send calls to these agents who were in the "Ready" state before the connectivity to the PGs was lost. After the router suspends the peripheral and declares it offline, you need to use an "IF" node with "Peripheral.online=1" in the script to avoid sending or queuing calls to an offline peripheral. You should make this change manually.

In terms of scripting and routing, the Unified CCX environment is treated no differently than any other legacy ACD.

You can design Unified ICM scripts to interact with Unified CCX scripts in a Unified CCX system integrated with an Unified ICM system through the Unified CCE Gateway. In such an integrated system, Unified CCX software is linked as an ACD to the system software.

In Unified CCE Gateway PG deployments where the Unified CCX system is the child system, that is, connected to a Unified ICM; Unified CCX system can use the Unified ICM system for post-routing. Post-routing is typically used to enable the Unified ICM to determine the best routing solution based on the current situation of the call center.

The following are three sample post-routing scripts that illustrate three different ways of post-routing through the Unified CCE Gateway. In each of these examples, the script accepts the call from the Cisco Unified Communications Manager in the Unified CCX system and then queries the Unified ICM through the Request Route step. The Unified CCX then routes the call based upon the return value of the Request Route step supplied by the Unified ICM.

In the first sample script, the call is routed to a CSQ. In the second sample script, the call is routed to an agent. And in the third sample script, the call is routed to a route point.

These are the sample scripts:

• PostRouteSelectCSQ.aef:

  • The RouteRequest step returns a label corresponding to a CSQ which is used in the select resource step.

• PostRouteSelectAgent.aef:

  • The RouteRequest step returns a label corresponding to an agent extension which is used in the select resource step.

• PostRouteSelectSimple.aef:

  • The RouteRequest step returns a label containing an Unified CCX route point which is used in the call redirect step.

Each of the three sample Unified CCX scripts presume a Unified ICM script designed to interact with the Unified CCX script, depending on what Unified CCX resource is wanted: a CSQ, an agent, or a route point.

Note	The Unified ICM script developer must work with The Unified CCX script developer so that the correct Unified ICM script calls the correct Unified CCX script and vice versa.

Each of the following Unified ICM scripts are extremely basic (simply returning a label to either a CSQ, an agent, or a route point) and are used only for example purposes. The most important point from these examples is that the Unified ICM and the Unified CCX script writers need to work together during both design and implementation to ensure that the correct type of information is returned by the Unified ICM script through the Unified CCX Route Request step and is used properly by the Unified CCX script to route the call appropriately. The following figure displays labels used in these examples.

Figure 2. Label Node Properties

Outbound Option only supports both Type 2 (Generic PG environment) and Type 9 (Unified CCE System PG environment). For Unified CVP, Outbound Option supports Type 10, Type 7, and Type 5 (Unified CVP Comprehensive Model).

If using the transfer to VRU feature, create a transfer to VRU campaign. Transfer to VRU campaigns might require translation routes if using a Type 2 VRU. For more information about setting up translation routes, see Cisco Unified Contact Center Enterprise Installation and Upgrade Guide. (Note that translation routes are not required when using the Unified CCE System PG.)

Note	The transfer to VRU feature is only supported for Outbound Option on Unified CCE. You cannot use this feature in the Direct Preview or the regular Preview modes.

The dynamic routing client feature is used when an outbound agent transfers a call using the Unified CVP to a Type 2 VRU. Make sure the routing client for the translation route labels is the Cisco Unified Communications Manager, which makes the outgoing call.