I am writing this post more or less as a refresh for myself as well, as it has been a while since I last worked on UCCX. This post is based on UCCX version 8.5.1 and CUCM version 8.6.2. This post describes the basics of setting up UCCX once a a cluster has been built, to have CUCM successfully hand over calls to it.
Really, there is not much about UCCX if you think about it, all the call handling intelligence lies in the scripts. Outside of the scripts, there is not a hell of a lot to be configured.
1-Define Cisco Unified CM telephony Provider
First define the primary and secondary telephony provider.
2-Provision application users in CUCM for UCCX to use.
This is a requirement for the next step 3. creating the application users basically allows UCCX the appropriate permissions to communicate with CUCM using the following elements:
- JTAPI, Ensures communication between in the CRS engine in UCCX and CUCM (CTI manager).
- AXL, used to write into CUCM's database, for for instance the creating of CTI ports and CTI Route points. Very much the same as creating VM ports in Unity Connection.
- RmCm (Resource manager - Contact manager). this allows the monitoring of agents phones, routing/queueing of calls, control of agent states and management of historical reporting.
For AXL I will use UID "CRS_admin". In CUCM this application user requires Standard AXL API access.
For jtapi I will use UID "uccxjtapi". It will need to have Standard CTI enabled, but make sure all CTI ports and Route Points that are used by UCCX and its triggers are associated with this userID.
For RmCm I will use UID "uccxrmcm". it will need to have Standard CTI enabled as its role, and it will need to have all phones and/or profiles of agents associated with it as controlled devices.
Its best practice to keep these user IDs meaningful. and make sure the passwords do not expire! Doh!
3-Define CUCM configuration.
this is where the application user IDs and password get populated into UCCX
(System>Cisco Unified CM Configuration).
use the applicable user IDs set up in step 2 for the communication in these 3 subsystems.
4 - Call Control Groups.
Once the subsystems have been configured, the call control groups must be defined. Doing this, basically uses the AXL API in CUCM to create the CTI ports (and later the CTI Route points), to deliver calls to and from the various UCCX applications. the example below is an inbound call control group.
This call control group has 60 ports starting with 69000, once you hit save UCCX will populate CUCM with 60 CTI ports using <deviceprefix>_<
directoryno> as the naming convention. The CTI ports will register on the first CUCM defined in the Call Manager group, and will register with the IP address of the active UCCX server.
The main reason for call control groups is to allow various applications/IVRs/scripts to use different CTI ports. Say for instance you have a service desk with 100 agents and you want at least 100 concurrent calls into the application, then create a call control group with 100 ports that will only be used by the application running the service desk. If you run additional applications on the same UCCX cluster, create a separate Call Control Group for the other applications. What Call control group a certain application uses, gets defined in the trigger definition of that particular application. you can also use call control groups to use different Call Manager Groups so different CTI ports use at different CUCM's, thus spreading the load between servers. If you are not interested in this, create one happy Call Control group and max the amount of sessions into your applications in the application configuration window.
After the previous configuration steps, you should have basic communication between CUCM and UCCX and all your CTI ports should be registered. If your CTI ports are not added to CUCM or are somehow not registered, don't bother continuing as there is no way you can test your applications!
Ok so, now it is time to add an application to UCCX, you have your script ready as well as the prompts it uses.
As you can see the example above, uses trigger 1667 to invoke the scrip XXXX.aef. with a maximum of session consecutive calls. Extension 1667 exists on CUCM as a CTI Route Point, where it got created through AXL.
As I said, I will not go into detail on the scripting part of the application. I just wanted to cover off the basics and explain how to link UCCX and CUCM.