UCCX Architecture

UCCX is an application server in the Cisco’s Unified Communications suite that provides basic or advanced IVR, call queuing, Automatic Call Distribution (ACD), agent management like reporting and recording (both built in, and using the Quality Management and Advanced Quality Management products. The basic components required to process calls in UCCX are a Unified Communications Manager cluster, gateways for PSTN access, and a UCCX node or HA cluster.

A CCX HA cluster is based on a Publisher/Subscriber relationship, like UCM, but is an active/passive cluster. One node performs all call processing and the other node is available as a hot standby. When a failover occurs, either administrative, based on a failure, or for instance if a node is restarted, the node will stay active until something causes it to fail back the other node. This is because, since calls can be actively terminated to the UCCX server, failover can cause an interruption of call processing. When a failover occurs, call that are terminated to the CCX server will be lost, while calls actively talking to agents should not be.

The basis of call handling in UCCX is the application, which is a combination of a script, one or more triggers, and zero or more parameters. There are also prompts, queues, agents, and a lot of other pieces, but they center around these 3.

Scripts: Created by a dedicated editor (Cisco Unified CCX Editor) can preform a wide variety of call handling operations (answer calls, transfer calls, collect DTMF digits, play prompts, etc.), interact with CCX queues and agents, process data, etc.

Triggers: CTI route points registered with Unified CM. Ports are used to route a call to a specific application. Triggers can also set the language in a multi-language environment, and can be referenced in a script, so the script can handle calls to individual triggers differently.

Parameters: Values that can be fed to a script to customize it for a specific application.

A single script can be used for multiple applications. For instance, a script could be created that answers a call, plays a welcome prompt, and places the caller in a queue, playing music on hold and a periodic announcement until an agent becomes available. The company using it needs 2 call flows, one for sales, and one for repairs. The call flows are identical, except that the welcome prompt should reflect the department called, and the callers should be placed in the queues called “sales” and “repairs,” respectively. Rather than create a separate script for each department, a single script can be used, that expects parameters for the welcome prompt and the queue name. Then, “sales” and “service” applications are created, with the appropriate values configured as parameters. Then, triggers are assigned to each of them, say 1000 for sales, and 1001 for service. When a person called 1000, UCM rings the trigger 1000 on CCX, and CCX handles the call using the application (script and parameters) assigned to that trigger.

Note that it is possible to create a single script, single application, with multiple triggers, and route the call based on that. I tend to prefer the first way, as it tends to allow for easier administration.

Over some upcoming posts, I will take a deeper dive into these topics, and provide some examples.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.