Cisco Unified Presence LDAP integration, Jabber for Mac / Personal Communicator and Photos

I’ve seen some confusion regarding LDAP and Presence, why it’s used and how you configure it. I can see why it’s not clear considering you most likely have LDAP already configured in your Callmanager, so why configure it again? Let me break it down for you.


Let’s look at a brief overview. There are two types of LDAP functionality you can enable – Synchronization and Authentication.

Synchronization enables you to import end user from an LDAP server, such as Microsoft Active Directory. Why manually add every single end user in the Callmanager when you can just import an up to date list from the company’s Active Directory. When LDAP synchronization is enabled, the local database is still used for Authentication.

Authentication enables Unified CM to authenticate end user passwords against a corporate LDAP directory instead of using the local database. You can see the benefit of having a central system for handling both user and password management.


When you login to the Presence web interface for the first time you will see a post-installation wizard. It will prompt you for the CUCM Publisher hostname, IP, cluster security password etc. It will also ask you for the CUCM AXL account username and password.

The Administrative XML (AXL) interface enables Provisioning Applications to remotely access configuration data stored in the Cisco Unified Communication Manager database. This includes Create, Read, Update, and Delete objects such as gateways, users, devices, route-patterns and much more.

That means the Presence server will import all end users from the Callmanager using AXL. So you can see there is no need for the Presence server to Synchronize (import) end users from the Microsoft Active directory.

Jabber for Mac / Personal Communicator

LDAP integration is actually not done for the Presence server itself, but rather for the Jabber for Mac / Personal Communicator client to perform user lookup.
This becomes even more apparent when you see that you configure LDAP profiles per user, and not globally for the entire CUP server.

There is no local database that the Jabber or CUPC client can use to search for users and find their details such as phone number, email address and photo. In order to find this information you must use LDAP.

Update: Cisco introduced UDS mode in Jabber for Windows which allows you to use the Callmanagers database for user lookup.

Callmanager / Presence LDAP scenarios

You integrate Cisco Unified Communications Manager and Cisco Unified Personal Communicator with an LDAP directory. Cisco strongly recommend this configuration.

You integrate Cisco Unified Communications Manager with an LDAP directory, but you do not integrate Cisco Unified Personal Communicator. Cisco do not recommend this configuration because it will impact Cisco Unified Personal Communicator functionality and you will experience performance issues.

You integrate Cisco Unified Personal Communicator with an LDAP directory, but you do not integrate Cisco Unified Communications Manager. Cisco do not recommend this configuration because you will have to manually configure all your users on Cisco Unified Communications Manager at initial installation, and each time a change is made on the LDAP directory.

Photos in Jabber for Mac / Personal Communicator

In order to see photos of users in your contact list you must first integrate LDAP with your Jabber for Mac / Personal Communicator.

Go to Application -> Cisco Jabber / Personal Communicator – LDAP Server. Enter the IP address of your LDAP server.

Goto Application -> Cisco Jabber/Personal Communicator – LDAP Profile. Enter username, password and user search base where your end users are located in the AD. Add end users to this profile or make it default for the system.

Jabber for Mac supports fetching photos from LDAP server with the jpegPhoto LDAP attribute. You may need to extend the schema of your AD to support this.

CUPC 8.x does not support fetching photos from LDAP.

Both Jabber for Mac and CUPC can also fetch photos from a web server.

Goto Application -> Cisco Jabber/Personal Communicator -> Settings.

Scroll down to LDAP Attribute Mapping. Select the LDAP server type from the drop down menu. In the Photo field, enter the URL to the web server where your photos are stored, e.g.
If you are using Microsoft AD use %%sAMAccountName%%.jpg or %%uid%%.jpg if you are using iPlanet, Sun ONE or OpenLDAP.

Upload the photos to the web sever and make sure the filename is the same as the userid in the Active Directory.

If you’re having problems when searching for users and photos, phone numbers and email etc is not showing up you can empty cache in the Jabber menu.


How to find SCCP version on a phone

I wrote a post earlier about SIP delayed-offer to early-offer with CUBE etc. There I mentioned that with CUCM 8.6 you can use SIP early-offer without invoking an MTP if your devices are running at least SCCP ver 20.

But how do you know what SCCP version your phone has? Well it’s based on the phone load (firmware) on the phone.
The problem is there’s no information about SCCP version in the release notes for the phone loads. But there is a way to see what version you are running if you force your phone into SRST mode.

I’m running CUCM 8.6 with a 7941 phone load SCCP41.9-2-1S. I put a simple ACL on the switchport that blocks TCP port 2000 to the CUCM, when the phone re-register to the SRST router just do a “show ephone” and you will see what SCCP version that phone has.

ephone-1[0] Mac:aaaa.bbbb.cccc TCP socket:[1] activeLine:0
whisperLine:0 REGISTERED in SCCP ver 20/17 max_streams=5

How to install a fresh CUCM 8.x RESTRICTED version on a system running UNRESTRICTED

Starting with CUCM 7.1.5 there are two flavors of the software – restricted and unrestricted.
In this case, restricted actually means more features. In countries where encryption is illegal you must use the unrestricted version.

– Signaling & media encryption is permanently disabled in the unrestricted version.
– Signaling & media encryption capabilities are unchanged in the restricted version.
– Migration from the unrestricted version to the restricted version is not supported.

Note: No impact exists to other security features such as HTTP(s), SSH, password encryption and authentication (for example, SIP digest authentication), mechanisms used by unrestricted Unified CM clients such as JTAPI, TSP, encryption of SNMP traffic, encryption of data related to database that is done by using IPSEC and IMS on the server side.
The communication between CTL client and provider remains encrypted.

So if you install an unrestricted version of CUCM on your server, you cannot upgrade or do a fresh installation of a restricted version.
If you insert the restricted version DVD and start the installation you will see a warning that the current partition contains an unrestricted version and the installation will halt.

The only way around this is to format the disk and reinstall the restricted software.

Here’s how I did it:

1. I had a Debian 6.0.4 CD lying around that I booted the server with.
2. Select the standard installation and continue with the basic settings such as keyboard, passwords etc.
3. When you see the disk partition menu, select the option to manually configure the disks.
4. You will see 3 primary ext3 partitions and 2 logical partitions.
5. Hit enter on the first partition and select erase data on this partition.
6. When that’s done hit the back button twice and exit the installation and reboot the server with the restricted CUCM DVD.

Now the installation won’t find any previous software and you can continue as normal.

Note: Any bootable disk utility software should work. Also you should be able to just delete the partitions, however I was not sure if IBM/HP had some sort or recovery/utility/diagnostics partition.

Call Forward Behaviour with and without Local Route Group in Cisco Unified Communications Manager 8.x

Call Forward overview

CFA is configured on each line via CSS. This is done individually from the CSS on the device/line used for regular calls.
There are two CSS used for CFA, “Forward All” and “Secondary Calling Search Space for Forward All“.
These can be used together for CFA call routing/blocking, just as the line/device approach for regular calls.

Forward All CSS is the same as line CSS, I.E. used for blocking. You can apply international blocking here for example.
Secondary CFA CSS is the same as device CSS, I.E. allows everything and handles routing.

Note that if you’re not using the Cisco line/device approach you will only use the Forward All CSS.

This way you can allow the phone to dial international numbers, but not CFA to one.

Use system default will use (unless changed) “With Configured CSS” which means you have to manually configure one or more CSS for CFA.
“With Activating Device/Line CSS” will inherit the CSS applied on the device/line.

Use the latter option if you are using Extension Mobility as you don’t want to hard code the CFA CSS because that will break routing when you roam. You want the CFA CSS to follow you in the same way the device CSS does.

The downside of using “With Activating Device/Line CSS” is that you cannot have split CoS between your regular calls and CFA. I.E. if you can call international numbers, you can also CFA to international.

Local Route Group overview

The Local Route Group feature helps reduce the complexity and maintenance efforts of provisioning in a centralized Cisco Unified Communications Manager deployment that uses a large number of locations. The fundamental breakthrough in the Local Route Group feature comprises decoupling the location of a PSTN gateway from the route patterns that are used to access the gateway.

Release 7.0(1) of Cisco Unified Communications Manager introduces a special Local Route Group that can be bound to a provisioned route group differently based on the Local Route Group device pool setting of the originating device. Devices, such as phones, from different locales can therefore use identical route lists and route patterns, but Cisco Unified Communications Manager selects the correct gateway(s) for their local end.

What does this mean? Well let’s say you have 3 sites in the US – NY, LA and AZ. All three sites have local H.323 gateways with ISDN.
Without LRG, you would have to create 3 set of Route Patterns for US, all identical, the only difference is that they are pointing to different Route Lists/gateways for each site.

With LRG, you only need to create 1 set of Route Patterns for the entire US, and point that to the Standard Local Route List.
The connection between the Route Patterns/Local Route List and the site Route Group/gateway is done via the Device Pool.
So your device/phone will select its gateway based on whats configured in that particular Device Pool.

Same site CFA without Local Route Group

Phone 1000 is configured with an internal only CSS. He can only call OnNet IP Phones. Calls to PSTN are blocked and CFA is not allowed.

Phone 2000 is configured with an unrestricted CSS. He can place calls both internally and to the PSTN. CFA CSS is set to “with activating device/line” so it will inherit the same Class of Service as the device/line.

In this scenario Phone 1000 calls 2000. CFA is set on Phone 2000 to a PSTN number, the CSS configured for CFA will be used to determine where to route the PSTN call to, also if it’s allowed or not. In this case it is allowed and the call is routed to the PSTN via the gateway.

Important to note here is that the Calling number will be 1000, and not 2000. So even if Phone 1000 has no PSTN access, he uses Phone 2000 CFA CSS to still be able to reach that CFA destination that Phone 2000 set.

Let’s say for argument’s sake you have a bunch of public numbers on the PSTN trunk. When placing outbound calls you must send the Calling number in the correct format. But what if 1000 is not one of your public numbers? This might be a lobby phone. Then you must ensure you have a catch-all rule on the gateway. A common practice is to translate any unknown number to the switchboard number.

This is especially important when dealing with SIP trunks where the ITSP often authenticate on the Calling number.

Different sites CFA without Local Route Group

Same scenario as above except that Phone 1000 and Phone 2000 are in two different sites.
As the call will leave the gateway over at Site B, it’s especially important to fix the Calling number. These two sites may even be in different countries.

Same site CFA with Local Route Group

Assuming that Phone 1000 and Phone 2000 are using the same Device Pool, and thus the same Local Route Group, it works the same way as without Local Route Group.

Different sites CFA with Local Route Group

When using Local Route Group, the Call Forward behaviour changes.

For forwarded calls, Cisco Unified Communications Manager must use the Local Route Group that is provisioned in the device pool settings that are associated with the redirected party to find the provisioned local route group. Thus, if phone A calls (local) phone B and phone B forwards the call to (remote) phone C, the Local Route Group value from the phone A device pool gets used rather than the corresponding value for phone B.

Let’s look at the details below.

Again you have site A(NY) and site B(LA). Both sites are configured with Local Route Group. Phone 1000 with internal only access calls Phone 2000. Phone 2000 has CFA to a local LA number on the PSTN.

Now here’s the kicker, as the CFA CSS on Phone 2000 is pointing to Route Patterns that points to a Local Route Group, Phone 1000 will use the Route Group/gateway configured in his Device Pool, and thus sending the call out via the site A(NY) gateway.

Problems with CFA and Local Route Group

First of all, we are calling a local LA number from NY. Most likely Phone 2000 put the CFA destination number in local format, and not as long distance, so this call will fail.

Second, the Calling party was restricted to internal only access, but now he has to pay for this forwarded call. The discussion is really who pays for the call, the Calling party or the Called party. I think it’s weird that the Calling party totally unaware of any CFA call has to pay.
On the other hand the old way of doing it is a form of TEHO and might not be allowed.

Third, what if these two sites are in different countries? Let’s say site A is in London, in the same CFA scenario a call will be sent out via the London gateway to a local LA number, this will of course fail.

Now you are probably thinking: I will just instruct the user to always put the CFA destination as international format. While that might work if you are in the same country, it will not work between countries with different international access codes.
Example, US use 011, and most European countries use 00.

The solution to the number routing problems is called E.164 globalization. Every number you dial, or CFA or whatever has to be expanded to E.164 with +. E.G. that local LA number has to be expanded to +1818-xxx-yyyy.

However, most PSTN providers do not support sending calls in this format, they want you to send local, long distance and international in corresponding format. You solve this by localize/normalize the number with transformation patterns on the gateways in the outbound direction.

Example, if London now calls +1818-xxx-yyyy, you will normalize this call with the proper international access code and country code for USA, 001818-xxx-yyyy. The CFA call will now successfully be sent from London to US in the correct format.

Note: A workaround is to use specific CFA CSSes that you point to route patterns without Local Route List/Group, this creates more work and will not work with Extension Mobility when roaming.

Update: Rumor has it that Cisco will enable you to control the Local Route Group CFA behavior with a service paramter in CUCM 9.0. I guess we’ll have to wait and see.

I will cover E.164 globalization/normalization at another time.

Software Media Resources in Cisco Unified Communications Manager 8.x

The Cisco IP Voice Media Streaming Application provides the following resources in software:

•Music on Hold (MoH)
•Software conference bridge
•Media termination point (MTP)

Music on Hold (MoH) capacity 

Unicast streams

Annunciator (ANN) capacity

By default, the annunciator is configured to support 48 simultaneous streams, which is the maximum recommended for an annunciator running on the same server (co-resident) with the Unified CM service. If the server has only 10 Mbps connectivity, lower the setting to 24 simultaneous streams.

A standalone server without the Cisco CallManager Service can support up to 255 simultaneous announcement streams, and a high-performance server with dual CPUs and a high-performance disk system can support up to 400 streams. You can add multiple standalone servers to support the required number of streams.

Software conference bridge (CFB) capacity

The maximum number of audio streams for this type equals 128. With 128 streams, a software conference media resource can handle 128 users in a single conference, or the software conference media resource can handle up to 42 conferencing resources with three users per conference.

Media termination point (MTP) capacity

A single MTP provides a default of 48 MTP (user configurable) streams, and two streams make one resource because you need one stream for each side (send/receive) of the MTP. For a 10-MB Network/NIC card, approximately 24 MTP resources can be provided; however, the exact number of MTP resources that are available depends on the resources that other applications on that PC are consuming, the speed of the processor, network loading, and various other factors.

You can change the values for all software media resources in System -> Service Parameter -> Server/Cisco IP Voice Media Streaming App

However, increasing this value above the recommended default may cause performance degradation on a Cisco Unified Communications Manager that is running on the same server. If you need to increase this value above the default, you should consider installing the Cisco IP Voice Media Streaming Application on a separate server.