EDI (Enhanced Directory Integration) can use the logged on user domain credentials to search LDAP directory, or a saved set of credentials in either the Service Profile or jabber-config.xml via the <ConnectionUsername> and <ConnectionPassword> tags. It’s only supported with Jabber for Windows since it uses the built-in Windows API.

BDI (Basic Directory Integration) uses stored credentials in either the Service Profile or jabber-config.xml via the <BDIConnectionUsername> and <BDIConnectionPassword> tags to search LDAP directory. Storing credentials in the service profile is highly recommended, since the jabber-config.xml is plaintext.

When both service profile and jabber-config.xml define a parameter, the service profile will take priority.

UDS (User Directory Service) uses CUCM to provide directory lookup services. UDS is the only supported method when MRA is used, however because CUCM is now providing directory lookups and not LDAP, the load must be considered: a node can support UDS contact service connections for up to 50% of the maximum device registrations supported by the server.


Multiple Unity Connection Clusters may be networked together to provide cross-server features such as sign-in, transfer and live reply. An example would be a dial by name in a company directory being able to search multiple clusters and route the call appropriately.

First thing you’ll need is to define a route pattern in CUCM that will point to each Unity cluster. The CSS of each Unity Connection cluster should have access to this route pattern. In the following example I will use: ##991 to Site A and ##992 to Site B.

Next, add a HTTP(S) link under Networking, Branch Management. This adds the site under Networking, Locations. Notice you’ll only need to do this on one cluster- it will automatically add it to the neighbor cluster.

Now you’ll add the route pattern you created in step one to each cluster’s respective locations and check both “Allow Cross-Server..” options. This is the target dial string, so the route pattern going to site B will go on site A’s cluster.

Under Advanced, Conversations you’ll need to check “Respond to Cross-Server Handoff Requests”

OK at this point you can check under Users and you should see users from both clusters to tell you HTTP(s) networking is working, but before we can make the features work, take the steps below to create some partitioning:

  1. Create a “hidden” and an “intersite” partition on both clusters.
  2. Create a site-specific “reply-all” search space including each sites default partition (it’s own first, then its neighbors) and the intersite partition.
  3. Create a shared “master distribution list” search space, including all partitions, starting with site specific partitions, then the intersite partition, then the hidden.
  4. Rename the system distribution list on each cluster and change it to use the hidden partition.
  5. Create a new “master distribution list” to use the master distribution list partition.
  6. Change the system directory handler to use the new master distribution list search space

Now we just need to configure the clusters to respond to cross cluster requests. This uses a series of dtmf codes to hand the call off between servers. You’ll need to run the following via CLI to enable this:

run cuc dbquery unitydirdb execute procedure csp_ConfigurationCreate
(pName=’HandoffForwardRemoteForward’::lvarchar, pParentFullName=’System.Conversations.CrossBox’::lvarchar, pType=11, pValueBool=1, pRequiresRestart=1)

run cuc dbquery unitydirdb execute procedure csp_ConfigurationModify (pName=’HandoffForwardRemoteForward’::lvarchar, pParentFullName=’System.Conversations.CrossBox’::lvarchar, pValueBool=1)

Almost done – the only thing left is a call handler to answer the call.

  1. Copy the opening greeting to create a “CrossCluster_CallHandler.
    1. Under caller input, uncheck “ignore further input” under #.
  2. Create a Direct Routing Rule.
    1. Condition “Dialed Number Equals ##992” (this is what it answers to)
    2. “Send Call to” should go to the “CrossCluster_CallHandler”

See the official documentation here

Conference Now is a new feature in CUCM 11.0 for ad-hoc authenticated meet-me within CUCM without the need for any other application such as WebEx or UCCX.

Both internal and external callers can use Conference Now. The host needs the meeting number (their primary DN) and pin, while the participants only need the meeting number (access code is optional) and will hear MOH until host has joined.

First thing- you’ll notice a new link in 11.0. Media Resources > Interactive Voice Response, this was created automatically when I upgraded from 10.5. You’ll need to ensure these resources are made available to all parties.

Next, User Management > End User, enable the feature for each host, and add an optional attendee access code.

Last, Call Routing > Conference Now, setup the conference now number and partition. Interesting enough the documentation says that Video on Hold is not supported, but I was able to get this to work simply by leaving MOH Source to <none>.

Read the Official Feature Configuration Guide for CUCM 11.0

So for a g711 call with default payload carried over ethernet:

Total Packet Size: 40 + 18 + 160 = 218 bytes = 1744 bits

PPS = 64,000 (bitrate) / 1280 (payload size) = 50

Bandwidth = 1744 * 50 = 87,200 (or 87.2 kbps)

You could also use the Voice Bandwidth Calculator from TAC:

Sometimes working with a large amount of phones (10,000+) it can take a whole day to export into a csv, and makes more sense to view and manipulate data in the live database. Caution should be taken when handling the live database, so if you are not a programmer, you may want to stick to the canned scripts below as an overly broad query could lock up your server!

I was recently tasked with running firmware updates on a large amount of phones, various models for over 100 device pools. Anything that can help organize and divide workload and cut down on unnecessary bulk jobs is a huge help!

UC Guerilla has a good blog on this here
Cisco’s documentation you can find here, but a tough read for a non-programmer

Count the number of devices per type, total:

run sql select count(Device.name) Device_count, typemodel.name Device_Type from Device inner join typemodel on device.tkmodel=typemodel.enum group by typemodel.name

Count the number of phones in each device pool, sorted by device pool name:

run sql select count(d.name), dp.name as DevicePool, tc.name as DeviceType from Device as d inner join DevicePool as dp on d.fkDevicePool=dp.pkid inner join typeClass as tc on tc.enum=d.tkClass group by dp.name, tc.name order by dp.name

Count the number of each type of phone per device pool, sorted by device pool name:

run sql select count(Device.name) Device_count, DevicePool.name Device_Pool, typemodel.name Device_Type from Device inner join DevicePool on Device.fkDevicePool=DevicePool.pkid inner join typemodel on device.tkmodel=typemodel.enum group by DevicePool.name,typemodel.name order by DevicePool.name


ILS is a new feature service in CUCM 9.0 that allows for sharing of Directory-URIs between clusters.

A Directory URI is much like an email address, formatted like jlevensailor@ciscolab.com where jlevensailor is the user portion and ciscolab.com is the host portion. The user portion is actually case sensitive, but only in the context of CUCM, and is actually an enterprise parameter that can be set to fix this.

The internet uses dns via _sip._udp/tcp or _sips._tls SRV records to route calls between Directory URIs much like email uses mx records. CUCM uses sip route patterns for Directory URIs much like they use standard route patterns for DNs. To tell CUCM that a particular Directory URI is on-net within a particular multi-cluster environment, ILS was introduced.

*It is recommended to first change the Cluster ID enterprise parameter in both clusters to something unique.

To get started, I’ll assume you have a sip trunk has been created already between the two clusters, directly or via SME. Go to Advanced Features and ILS Configuration.

You’ll change the role to “Hub Cluster” and enter the corresponding clusters domain name or ip-address in the popup. For authentication you can either use TLS certificates and exchange certs (default), or you can use a password. Note: The password does require a restart of the ILS service, in case you were already running this.

The advertised route string is what you will create a sip route pattern for on the other cluster, pointing to the ICT so calls can work. When you are done, you can go ahead and start the service if you haven’t already, wait until synchronization finishes and run a route plan report to confirm:

As you can see, any URI on the remote hub cluster will be discovered, not just those that happen to match the advertised route string, which by default is the cluster FQDN.

The call flow is: nbates@car.lab wants to call test@dur.lab. CUCM checks the CSS of nbates@car.lab and proceeds to search for the URI in the list of ordered partitions as usual. When it finds test@dur.lab, it sees that it is a “Learned URI” from sbcucm.dur.lab, and uses the target from the sip route pattern of “dur.lab” I created to call the remote user.

The benefit of this is that sip route patterns won’t have to be created for each remote domain, just one for each ILS partner cluster. I would imagine you’ll start seeing a blank sip route pattern pointed to VCS/Expressway-C for outside domains and a specific ILS route pattern for internal domains/on-net traffic.

Official Documentation HERE