PRESENCE FUNDAMENTALS - CONFIGURATION OVERVIEW
In working with Cisco Unified Presence Server (CUPS) over the past few years, my personal experience has been that the process of configuring the interdependencies between it and Cisco Unified Communications Manager (CUCM) tend to be the most confusing aspects. Available installation documentation tends to be somewhat vague when it comes to describing the interaction between CUPS and CUCM. This brief discussion is aimed squarely at dispelling some of the fog associated with that process. The focus of this discussion will be on CUPS 7.x as it constitutes the highest concentration of current installations. Version 8 is available, but has only just become so. With that in mind, a future discussion will focus on CUPS 8.x installation, interdependencies with CUCM 8.x and how CUPS 8.x differs from version 7.x.
CUPS and CUCM maintain multiple methods of communication at any given time. Figure 1 will provide a frame of reference for the basic architecture.
Figure 1 shows three separate communication flows between CUPS and CUCM. Each of the three means of communication requires an individual series of configuration tasks to be performed in order to get it working properly. There is an Administrative XML Layer (AXL)/Simple Object Access Protocol (SOAP) connection, Computer Telephony Integration (CTI) connection and a Session Initiation Protocol (SIP) connection. The basic function(s) of these are as follows:
While it may seem simple, there are a number of not-so-intuitive dependencies which must be considered and configured in order to get all three aspects to a functional state. Each of these will be discussed shortly.
Introductions Are in Order
Prior to any communication, be it social or digital, a protocol is required. A protocol is simply a set of rules agreed upon by all parties that will govern communications. Taking a step back, no communications can take place if we don't introduce the relevant parties. In this case, we must introduce the CUCM and the CUPS clusters so that they become aware of one another. Sadly, my analogy falls apart a bit when one considers the slight detail that much of the CUCM side of the configuration must be completed prior to the installation of the CUPS software on its hardware platform.
The addition of the Application Server is done through the addition of an Application Server on the CUCM cluster. As with any CUCM configuration, this will be done via the CCMAdmin utility. In the course of the configuration, you'll provide the type of Application server as well as the name of said server.
Note: The name entered when defining the CUPS Application Server in CUCM is not the DNS name or FQDN of the Presence server. It is solely the hostname assigned to the Presence server during its installation.
The AXL Application Programming Interface (API) provides a means of updating the database by using an eXtensible Markup Language (XML) SOAP interface. SOAP is an XML remote procedure call (RPC) protocol. Users perform requests by sending XML data to the Cisco UC server. The server then returns the AXL response, which is also a SOAP message. Using this interface, a programmer may send and receive UC-related data in XML form, rather than having to use a binary library or Dynamic Link Library (DLL).
Note: It is critical that the Cisco Web AXL Service be activated and running on the CUCM Publisher in order for these functions to work properly.
In order to create the connection between CUCM and CUPS, an AXL Group and Application User must be created on the CUCM. The username and password used here will be entered on the Presence server in order to establish connectivity. The AXL Group you create should be configured with the Standard AXL API Access role. The AXL user need only be a member of that group to inherit the necessary rights.
It is imperative that this step be completed PRIOR to the installation of the CUPS server software as the CUPS post-installation wizard will request the username and password created at this point as part of the finalization of the installation.
Once the wizard is complete, upload the license files and start the services on the Presence server. Without the license files, the Presence services will not start.
CUPS/CUCM SIP Trunk
The SIP connection between the CUCM and CUPS handles information regarding phone state. When a phone goes off-hook, for example, a status update will be sent that will alter the user's presence status from Available to On the Phone.
On the CUCM side of the connection, a SIP PUBLISH trunk is configured while the CUPS side will have a Presence Gateway added which points to the IP Address of the CUCM. The Presence Gateway is very straightforward. The SIP Trunk on the CUCM requires a SIP Trunk Security Profile as well as a SIP Trunk. The SIP Trunk Security Profile should have the following settings:
Be sure to name the profile in a meaningful, descriptive manner so that it can be easily referenced later on.
At this point, we're ready to add the SIP PUBLISH Trunk. Ensure that the SIP Trunk configuration references the newly created SIP Trunk Security Profile and that it points to the IP Address of the Presence server. With that complete, log back into the CUPS Admin utility. Navigate to the Presence Settings page (Presence > Settings). Check both the Enable Instant Messaging and Enable SIP Publish on CUCM boxes. Be sure to use the drop-down box to select the SIP trunk you created on the CUCM. This will complete the configuration of the SIP connectivity between CUPS and CUCM.
As mentioned, CTI is required in order for the Presence server to maintain control of phones. That said, this is one of the more important aspects of the overall configuration simply due to the potential for impact on the user experience. As with the previous configurations, there are pieces that must be configured on both CUPS and CUCM in order to ensure proper functionality.
On the CUCM side of the configuration, Presence users need to be associated with a CTI-enabled group and phones need to be given CTI capabilities as well. Like the AXL configuration, the CTI configuration requires the creation of an Application User that will be referenced on the Presence server in the form of a CTI Gateway configuration. A new group may be created, or an existing one altered. Regardless of the choice, simply check the Standard CTI Allow Control of All Devices box in the chosen/created group. All Presence users will need to be a member of this group. With that done, create a new Application User. Use a name which is both meaningful and descriptive, of course. I typically use the name CtiGw. There's no question what its purpose might be. Once the user is created, be sure to make it a member of the CTI-enabled group. Be sure to make a note of the username and password. You'll be needing that information shortly.
On the Presence server, the configuration is much simpler. In the CUPS Admin utility, click on Application > Gateway > Settings. Set the Application Status to On and enter the CTI user name and password in the fields provided. Also, on this screen, enter the IP Addresses of all of the CUCM nodes in the cluster (Publisher first, then Subscribers). As always, don't forget to click the Save button. The final step is to restart the Cisco UP SIP Proxy service on the Presence server.
A quick glance at this discussion makes it clear that there are more than a few details and steps left out of the mix. Hopefully, this quick discussion provides a bit of additional clarity to the CUPS installation and configuration guides. As a recap, Table 1 provides a snapshot of the interdependencies discussed here.
Table 1 - CUCM/CUPS Dependency Snapshot
There are a number of other settings and configuration options which will be needed in order to get the client side of things functioning properly. However, those will need to be addressed in a follow-up discussion. For now, your Presence server should be functioning happily. Be sure to check the System Troubleshooter if there's any doubt. It will take you straight to the source of any issues it perceives.
About the Author: