Anyone who has deployed Jabber knows of the cisco-uds SRV record that Jabber uses (or Expressway-C in the case of MRA) to discover it’s services. It’s also used for directory searches, and home cluster lookup with ILS.

UDS or User Data Services is a simple REST based API for CUCM. While the UDS API is not as extensive as what you can do with AXL through SOAP and WSDL, it makes a great use case for a front end to allow end users to manage their own devices: Change their single number reach destination, password, speed dials, and conference pins.

For security reasons, most browsers will block an XMLHttpRequest served on one page and originating on another (in the case of a front end making UDS calls to CUCM). To get around this, you would use CORS or Cross Origin Resource Sharing, defining the front end URL inside CUCM.

UDS supports REST queries POST/PUT/GET/DELETE in XML format. Some calls do not require authentication and some do. Ones that do will use Basic authentication built into the browser which encodes the username:password in Base64 format.

UDS resources that do not require authentication
clusterUser, installedLocales, models, options, phoneService(s), servers, timezones, users, version

GET https://{host}:8443/cucm-uds/users?last=Smit
GET https://{host}:8443/cucm-uds/clusterUser?username={userId}

UDS resources that require authentication
credentials, device(s), extension(s), remoteDestination(s), speedDial(s), subscribedService(s), user, userPolicy

POST https:­//{host}:8443/cucm-uds/user/{userId}/speedDials
<!–add speedDials example request body–>

CUCM UDS API Reference
CUCM UDS Developer Guide
CUCM UDS Authentication Guide
Base64 Encoder/Decoder

For a list of all jabber users and their last login time, you can run the following query:

run sql
select e.userid, cd.timelastaccessed from enduser as e, credentialdynamic as cd, credential as cr where e.pkid=cr.fkenduser and e.tkuserprofile=1 and e.primarynodeid is not null and cr.tkcredential=3 and cr.pkid=cd.fkcredential order by cd.timelastaccessed

This date is in something called “epoch” format. To convert to something that makes sense, you’ll need to use the following formula:


This is for Eastern Standard Time where -5 = UTC -5, you can change this accordingly.

Unlike other “report this problem” buttons, Jabber’s problem report doesn’t just fly into the cloud somewhere never to be seen again.

It actually contains a lot of useful information about things like: how services are discovered and assigned, what policies are defined, what devices are configured, etc. The problem report can be generated, but is located below:

\Users\AppData\Local\Cisco\Unified Communications\Jabber\CSF\Logs\csf-unified.log

One of the biggest questions I get is where configurations exist, and what takes priority ? Before looking at the file, I would have guessed 3 places, but as you can see below its actually 12!

1: TftpOverrideConfigStore [10] jabber-config.xml
2: LocalFileConfigStore [20] AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Config\jabberLocalConfig.xml
3: Ucm90ConfigStore [25]
4: PresenceAuthenticatorStore [28]
5: ServiceDiscoveryConfigStore [29]
6: PresenceConfigStore [30] Presence Server TFTP+CCMCIP Settings
7: RegistryConfigStore [31] HKCU\Software\Cisco Systems, Inc.\JabberWerxCpp
8: PresenceProductModeStore [35]
9: UrlProvisioningConfigStore [499]
10: BootstrapConfigStore [500] ProgramData\Cisco Systems\Cisco Jabber\
11: InMemoryConfigStore [600]
12: jabber-config-defaults.xml [2147483647] Program Files (x86)\Cisco Systems\Cisco Jabber\jabber-config-defaults.xml

Each of these stores contain configuration elements in the form of <tags>, retrieved from either the local machine, or through HTTP GET requests

When Jabber is launched, Jabber first tries to read jabberLocalConfig.xml for cached settings, if any exists. It then attempts to reach the domain controller of the machine you are running on for SSO. If both of those fail, only then will it give you a login prompt. If no cached username is found, email is prompted for and DISCOVERY begins.

retrieve email address and parse domain:

Getting LastLoggedInUserName from ConfigFeatureSet
Getting servicesDomain from ConfigFeatureSet
Getting PresenceDomain from ConfigFeatureSet
ServicesDomain key not found, parsing email address.
Retrieved Email Address
Retrieved DNS Domain ‘’ from ‘Email Address from UserInput’
Domain is set to:

check for webex im:

makeCasLookupForDomain result is ‘Code: NOT_WEBEX_CUSTOMER; CasUrl:;

check SRV records for on-prem and mra:

*—–* DNS query has succeeded.
*—–* DNS query has failed: DNS name does not exist.

determine home cluster:

*—–* Making HTTP request to:

fetch user data:

set location:

setCurrentLocationOption start: description: Jeffs House ,id: fff8ffb0-1332-4da7-ba78-647b35aa25b2
IsGatewayAddressSubnetExists: gateway address: 00::50::56::E3::E5::50, subnet:, locations: 1

The need to share dial plan information between multiple call control nodes has been around since gatekeeper, but I find the latest iteration, GDPR, particularly smooth.

Gatekeeper had its downsides: additional hardware costs, lack of URI or +E164 support, and reliance on H323 protocol. CUCM 8 introduced CCD (Call Control Discovery) using SAF (Service Advertisement Framework), but since it required end-to-end EIGRP and a complex configuration, I’ve never known anyone to actually use it. With CUCM 9 came Intercluster Lookup Service (ILS) I did a write up on a year or so ago. The first iteration only supported URIs but was onto something. ILS adds a route string to the database, which tags Directory URIs on each node. Route strings use sip route patterns as opposed to traditional route patterns to dynamically route.

GDPR is simply the addition of numbers and patterns tagged with a route string in ILS. GDPR is supported in CUCM 10+ and uses the following new system partitions:

Directory URI: As soon as the directory number is associated to the end user, this becomes the primary URI on the directory number page.

Global Learned E164 Numbers / Global Learned Enterprise Numbers:

On the directory number page, two new fields “add enterprise alternate number” and “add +E164 alternate number” have been added. Simply check “Advertise Globally via ILS” and these numbers will show up on ILS neighbor clusters as “Global Learned Enterprise Numbers” or “Global Learned E164 Numbers”


Global Learned E164 Patterns / Global Learned Enterprise Patterns:

Under Call Routing, a new option “Global Dial Plan Replication” has been added. Advertised Patterns is where you can add entire patterns you want to advertise. I find this is easier to manage rather than advertising each number individually; although its nice to have that granularity, it’s usually not necessary.


To view learned Numbers, Patterns, and Directory URIs, you can find these under “Global Dial Plan Replication” and “View…“, or you can run a traditional route plan report. This is much improved to the “utils ils lookup” needed with CUCM 9.

The default IM address scheme is to take the userid and append @defaultdomain to the end. This may work for smaller deployments, but caused a lot of confusion when multiple domains or subdomains were used. Flexible Jabber ID allows the IM address scheme to be mapped to Directory URI which is then mapped to either mail or msRTCSIP in LDAP.


Changing the IM address scheme to Flexible JID is simple:

    • Stop the following services:
      Cisco Presence Engine
      Cisco SIP Proxy
      Cisco XCP Router
      Cisco Sync Agent
      Cisco Client Profile Agent
    • Presence > Settings > Advanced Configuration:
      Change IM Address Scheme to Directory URI and save.


You can now browse to Presence > Domains to see a list of all domains in your presence environment.

You may find that some should not be there, as a lot of people like to add external contacts in their active directory with an ipPhone field populated. This will cause issues down the road if you deploy Mobile and Remote Access and want to do XMPP Federation. You’ll need to be able to sign for each domain. You’ll want to filter these out either by ldap filter into CUCM, or UC Service Profile. The Default Domain above also gets put into the CSR, so make sure to change that as well.

You can run the sql query below to clear the domains from the CSR once they are removed from the system:

run sql select * from impresencedomains

run sql delete from impresencedomains where pkid=’pkid_from_step_1′

To take advantage of Flexible Jabber ID, you must be running Jabber 10.6.6 or higher !

I’m not sure why Cisco didn’t include “custom file” option to update lines like you can phones, but if you have the list of numbers to change call forwarding rules, you can use the following queries which are a part of the numplan table. Call Forward All rules are in another table callforwarddynamic which i’ll cover later:

cfbvoicemailenabled = call forward busy external set to voicemail (boolean)
cfbdestination = call forward busy external destination
cfbintvoicemailenabled = call forward busy internal set to voicemail (boolean)
cfbintdestination = call forward busy internal destination
cfnavoicemailenabled = call forward no answer external set to voicemail (boolean)
cfnadestination = call forward no answer external destination
cfnaintvoicemailenabled = call forward no answer internal set to voicemail (boolean)
cfnaintdestination = call forward no answer internal destination

An example query below:

run sql update numplan set cfbvoicemailenabled = (‘f’), cfbintvoicemailenabled = (‘f’), cfnavoicemailenabled = (‘f’), cfnaintvoicemailenabled = (‘f’) where dnorpattern = “1111111”

Making bulk changes in CUCM can be done in 3 ways:

  1. bulk operations built into cucm – great but very limited
  2. import/export of tar file – all details – concise but requires change freeze
  3. sql operations – sometimes the best option

The following example I needed to update each line text label to add “Agent” to the beginning. Built in operations would only allow me to change the label all together, not append text. Import / Export would work fine, but for 10,000 phones this would take a full day to process. In this case SQL was my best option. The query below matches the line and updates the label. I used excel and the concatenate function to pump out all of the required operations.

run sql update devicenumplanmap set (label) = (‘Agent – 1112001’) where fknumplan = (select pkid from numplan where dnorpattern = “1112001”)

The vlookup function in excel is one of the most powerful tools to a voice engineer, which at times can seem more like being a database administrator. The logic here is simple: find the user id from the table on the left in the user id column on the table in the right. When you find it, return the value in the row x number of rows away.

=VLOOKUP(lookup_value, table_array, col_index_num, [range_lookup])

lookup_value = userid

table_array = the entire table on the right. the leftmost column must contain the lookup value

col_index_num = how many rows to the right to grab the value to return

range_lookup = false always!


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.


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