Ways to Populate the CUCM Enterprise Directory with External Contacts

Basically, the enterprise phone book addresses two simple business needs – you need to see who’s calling you and you need to find quickly any contact and call him.

In Cisco UC environment this works well for employees  phones – if every employee is registered in Active Directory, you can find him on Cisco IP phone or Cisco Jabber and his name will be shown during the incoming call to you.

But what if you need your enterprise directory to contain not only employees, but also clients, partners and other external contacts? Or maybe your correct employees info is stored in 3^rd party HR software, but not in AD?

There are several ways to populate the Cisco Unified Communications Manager corporate directory with contacts stored in 3^rd party database.

1. If you use Cisco Jabber you can use the Enhanced Directory Integration (EDI). This allows you to configure Cisco Jabber to search the contacts in any LDAP-based contact source. This contact source must be specified in Cisco Jabber config file (jabber-config.xml) and applied to all Jabber instances through TFTP server. So if you’re able to export all external contacts to some LDAP source and then maintain it up-to-date, you can use it as the search base for Cisco Jabber.
2. If your CUCM version is 10 you can use the ECC (External Call Control) feature and CURRI (Cisco Unified Route Rules XML Interface) API. This approach supported in Cisco UCM 10.0 allows you to modify the caller name in telephony signaling on-the-fly. Aurus, one of the Cisco Solutions Partners offers the free CUCM External Caller ID web-application (with the source code) that connects to SQL DB to extract the contact name based on his phone number and set it as caller name using Cisco ECC and CURRI. Going this way you’ll be able to see, for example, the name of the client who is calling you. But you won’t be able to find the client on the IP phone or Cisco Jabber.
3. If you’re open for the 3^rd party solutions, consider applications provided by Cisco Solution Partners. Most of them provide the “Enterprise directory” XML-service for Cisco IP phones. Few vendors also provide the global phonebook for Cisco Jabber as well. With commercial app you’ll be able to import the contacts from any enterprise database, manage the synchronization schedule, setup the field mapping, use the phone numbers normalization feature and much more.

The post is provided by Aurus, Cisco Solution Partner developing software solutions for Cisco Collaboration and Contact Centers.

Aurus PhoneUP bundle, designed for Cisco Unified Communications Manager provide the full-featured enterprise directory for CUCM with Cisco IP phone and Cisco Jabber support.

Filed under: CUCM, Cisco Phone Directory, Cisco Unified Communications Manager, Corporate Directory, CUCM

Network Segmentation in Virtualized Enviornments

Anyone involved in the information technology sector should be aware of how ubiquitous virtualization has become in the data center. The benefits of virtualization may have been first seen in the server farm, however, it is no longer restricted to that part of that network. Today, we are gearing towards the virtualization of practically everything from the network to the end user stations. Virtualization is especially important to people who work closely with Cisco’s Collaboration suite of products.

A couple of days ago a colleague asked me an interesting question that he was queried upon by a client. The client wanted to place their CUCM and IM & Presence (IM&P) servers that were running on the same VmWare ESXi host, in different security zones. I knew this was certainly possibly, but I hadn’t explored it enough to be able to provide a definitive answer. After some exploration, I found a great document on VmWare’s website that made things a lot clearer about the concept of separating VMs across security boundaries. There are apparently three high-level methodologies through which this can be achieved:

1) Server Virtualization only – Placing application servers that share a security zone on the same physical server, thus connecting that server to an external security device such as a firewall.
2) Network Virtualization – In this configuration, we would could have multiple virtual machines from all types of security zones on the same physical server. Here, we would aggregate machines sharing the same security policies (zone) via a virtual switch. Creating multiple virtual switches will segment the security boundaries on a layer 2 level. These virtual switches can then be mapped to separate physical NICs on the server, which can then be terminated on an external network security device. It is also possible to map these virtual switches to a single physical NIC and trunking (use 802.1q VLAN tagging) them over to a physical network switch and then terminating connections from each VLAN to a separate physical port on a firewall.
3) Network + Security Virtualization – This final scenario virtualizes practically all three layers of the environment, starting from the application servers to the security zones. Here, we not only virtualize the servers and the network as we did in the second method, we include a virtualized firewall, IDS or IPS on the same physical server. The application servers can be connected to the virtual firewall through the segmentation of the network at layer 2, thus virtualizing the physical connection used in the previous step where we mapped the virtual switches to a separate physical interface card.

The last solution is clearly a very powerful one, however, transitioning to this type of an environment immediately may not be practical solution. Hence, I recommended the second solution to my colleague since they were already running CUCM and IM&P on the same server without virtual network security. In this case, the client would need to create a logical separation between the CUCM and IM&P server using virtual switches, and map each virtual switch to a separate security zone on the external firewall.

In addition, I also reminded him that ensure that the proper ports are allowed through the firewall between the CUCM and IM&P in order for the Presence and Jabber client to function correctly. I am sharing the links to VmWare’s document on network segmentation in a virtualized environment in the hopes that it may be helpful to others.

http://www.vmware.com/files/pdf/network_segmentation.pd

Happy reading!

Filed under: Virtualization, CUCM, IM & Presence, IM&P, Network Security, Network Segmentation, Presence, Security boundaries, Security Zone, Virtualization, Zone

Upgrading CUCM to provide support for new IP phones

Hello everyone! It’s been quite some time since I’ve posted anything here. It has mostly been due to my incredibly tough schedule. I have yet to update the previous post about configuring a basic AA service on Unity Connection. I have the material ready in my head, but I wanted to get my hands on some screenshots to explain the process better. Basically, it will happen whenever I am able to gather all the screenshots.

Moving on to the topic of interest, this article will focus on provisioning support on Cisco Unified Communications Manager (CUCM) for IP phones that are not natively supported on your production system. In my example, I am trying to provide support for 7841 IP phones on CUCM version 8.6.2.

There are a several ways of finding out if your version of CUCM has built-in support for the phone model you would like to register. The easiest way to find out is to log into the web interface and navigate to Device -> Phones. Once on this page, click on “Add New”, which will take us to the page where we would normally add a new phone. Under the device type drop down menu, if the phone model does not exist, it means that the phone is not currently supported and a “device pack” will need to be installed on CUCM.

To successfully register an IP phone with CUCM, we will need to install a “device pack”. I am not certain if all device packs contain the firmware files, so I have included options to download and install these as well. This information can be verified by going through the release notes for the relevant release notes. Both the device pack and reloease notes can be downloaded through Cisco’s website under the Support -> Downloads section. (Note: A CCO ID with a valid service contract is required to obtain these files). To find out the what files need to be downloaded, we will need to first refer to the ‘Release Notes’ for the IP Phone model to find out the name of the device pack file. For the firmware files, we will need to download the file for the IP phone we are looking to support. Also, please ensure that this file is particular to the CUCM version you are running.

The screenshots below show the page where these files can be downloaded for our example upgrade:

 

The page above displays the device pack file for our example. The image below shows the firmware files for the phones and CUCM version we are using in our example, that is, 7841.

Before we begin uploading these files, I recommend taking a system backup through DRS and a VM snapshot if the server is running on a virtualized platform. Also, this process should be performed during a scheduled maintenance window.

Warning: I do not take responsibility for any system failure that may result from the procedures outlined in this document. This document is solely intended to provide general guidance to the reader, and it is the responsibility of the person performing this task, to ensure that all information particular to the upgrade is compatible with the production system. This includes for example, the correct CUCM version (Major and minor), IP phone firmware files, device pack file, and any other relevant system information.

Once the backup is complete, we will need to log in through the OS Administration portal and navigate to Software Upgrades -> TFTP File Management, as shown in the screenshot below.

Once on this page, click on the “Upload File” button, browse to the firmware files and upload

Here, we will upload the IP Phone firmware files to the TFTP server. (Note: These files will need to be uploaded separately to all TFTP servers in the cluster).

Once the TFTP files have been uploaded, we will need to apply the device pack file by navigating through the OS administration page, as follows: Software Upgrades -> Install/Upgrade. On this next page, we have the option to either install the device pack through a DVD/CD, or via the network. The network option is labeled “Remote destination”, which is what I have selected for our example. The screenshot below provides an example of how the necessary fields need to be filled out:

We have the choice to upload these files via FTP or SFTP. Free SFTP/FTP utilities are easily available for download on the internet. Before we proceed, I would like to mention that I had some trouble uploading the device pack from the root folder. Like any modern-age techie, I turned to the helpful technical forms on the internet and found that we will need to create another folder inside the root FTP/SFTP folder (give it any name) and place this file inside the new folder. Strangely, that seemed to work for me as well, so I thought it would be worth mentioning.

Before we proceed, I would like to add a word of caution; once the file has successfully completed, if the device pack contains the firmware files, it will most likely contain the firmware files for all other phones too. In addition, the “device defaults” page will be updated with the new firmware file names of all the IP phones. This means that for any new phone being added to the system, or an existing phones that are rebooted or restarted, will look for the new firmware files on the TFTP server. Use the following path to navigate to the device defaults page under CM administration: Device -> Device Settings -> Device Defaults

The device default page is shown in the image below:

If these firmware files are not present (they have to be uploaded separately, as mentioned earlier in this post), the upgrade process will fail and the phone will boot up normally using the existing firmware file stored in its storage.  In a production environment, this could wreak havoc, so my suggestion would be to read through the device pack release notes and ensure if the firmware files for all phones are present inside the device pack.

If the firmware files are present in the device pack, we will have to upgrade the firmware files for all the IP phone models. However, this may not necessarily be a practical option in every scenario in which case, we will have to ensure that the firwmare filenames for all other IP phones that should not be affected by the upgrades, remain the same.

Unfortunately, there is no way at this time to retain the names, therefore, we will have to let the upgrade change the filesnames to the newer version, then go back to the device defaults page and reenter the old firmware file names from before running the upgrade. We could either take a screenshot of the device default page(s), or copy-paste the information on this page into a spreadsheet. I have not tried the latter and it may not work.

Once we hit the “Next” button, we may will be asked to ensure that the correct filename has been selected for upgrade. Clicking “Next” again may take us to a page where we are asked to ensure that the “MD5 hash authentication value” is correct for the file being uploaded. This can be verified by looking up the value in the release notes for the device pack. Proceeding to the next page will begin the installation.

Once the installation is complete we will need to perform a cluster-wide reboot, which can be done one server at a time. Again, I would advise caution when performing reboot of the servers because if the phones failover to a server that contains the newer firmware filenames, the phones will begin downloading the new files.

Once the servers have been restarted, the new IP phone model support will be available for registering with CUCM. I hope this article has been helpful to the reader. Please feel free to provide your feedback.

Filed under: CUCM, Technical, 7841, Callmanager, Cisco IP Phone 7841, Cisco Unified Communications Manager, CUCM, device pack, devpack, firmware, phone support, sip