Monday, January 5, 2009

Name resolution in Cisco voice products

In Cisco documentations, there's no specific requirements for name resultion.  You may install Cisco voice products (such as CUCM, CUPS, CER) without worrying about name resolution.  The reason was - there's a process on those products called "ClusterManager'.

ClusterManager is the process takes care of IPSec communication between nodes in a cluster.  ClusterManager also takes care of host table (/etc/hosts).  Whenever a node was added to the cluster, ClusterManager will add the hostname into host table.  Hence every node in the cluster should be able to resolve each other's hostname without DNS involved.

Before we moving on, let's get familiar with some terminologies.
Hostname - The name for a computer.  e.g. ccm-1.  This name was entered during installation and used as the default "node name".  To show the host name, use CLI command "show status".
Node name (or process node name) - The name for a voice appliance(application).  By default, the node name was set to the hostname entered during installation.  You may change the node name to any value.  But the hostname stays the same.  To show the node name, use CLI command "run sql select * from processnode".
Domain name - A name for a domain (a group of computers).  e.g. sales domain, support domain, etc.  A domain name could be ambiguous.  For example, a sales domain could mean the sales domain in Asia Pacific or the sales domain in Europe.  To eliminate this ambiguity, we want to use Fully Qualified Domain Name (or FQDN).
Fully Qualified Domain Name (or FQDN) -   For example, is a FQDN.   (Technically, every FQDN should have a dot (.) at the end.  The dot means the root.  Without the dot, it's not a FQDN, it's a partial domain.)
Fully Qualified Host Name (or FQHN) - a FQHN consists of a hostname and a FQDN.  For example, a FQHN consists of a hostname ccm-1 and a FQDN
For the reason mentioned above (to avoid ambiguity), all DNS query should use FQHN or FQDN.  If a hostname was used, it's the client's responsibility to translate that into a FQHN.  For example, on client PC, we do a "nslookup ccm-1".  Windows actually translates "ccm-1" into "" before sending out the query to DNS server.  A sniffer capture could prove this.

The key point is - whether the client can translate the hostname into a correct FQHN.
This translation is controlled by the "DNS suffix" configuration on client side.  Client computers usually got this from DHCP.  To see the DNS suffix, use "ipconfig/all" command in Windows command prompt.

Though we don't have to worry about name resolution on voice servers (CUCM, CUPC, etc.), we do have to take end points (clients) into consideration.  End points might request hostname even though you thought you were using IP address.

IP Phones.

Let say, you just finish installing a CUCM 6.1.2 server (named ccm-1).  You registered Cisco IP phones to the CUCM.  You can make make/receive phone calls.  Everything looks good, right?  Right, until you press the "Directory" button on IP phone.

When you press the "Directory" button on IP phone, the phone actually acts like a web browser and initate a http request to http://ccm-1:8080/ccmcip/xmldirectory.jsp.  If the phone cannot resolve ccm-1 into an IP address, it won't be able to make that connection.

"ccm-1" is the node name.  By default, it's the hostname you entered during installation.  You may change the node name on CCMAdmin page > System > Servers.  Changing the node name does not change the hostname.

Application Clients (such as Attendant Console client)

On Attendant Console client logon, you specified IP address of the CUCM server.  You successfully logged in.  But you were not able to control the phones.  Looking at log files, you realized that Attendant Console client was trying to initiate the JTAPI connection to CUCM server by node name (ccm-1).  Adding ccm-1 to C:\Windows\system32\drivers\etc\hosts on client computer solved the problem.

CUPC (Cisco Unified Personal Client)

Things become more insteresting (complicated) when SIP comes into play.

On CUPC 7.x, some customer noticed an annoying behavior.  On the first logon, user specified HQHN of CUPS server (e.g. as the login server.  CUPC logged in successfully.  Exit and re-launch CUPC.  User noticed that the login server field was automatically poplated with the CUPS node name (e.g. cups1).  Since "cups1" was not resolvable from the client computer, logon failed.  User changed the login server to FQHN  Logon succeeded.  But on next logon, it changed to hostname again.

This annoying behavior is actually a new feature in CUPC.  We might have multiple CUPS servers in a cluster.  To better load-balancing between those servers, we specify a "home node" for each user.  A user's request should designated to his "home node" (unless the "home node" is down).  On the initial logon, CUPC gets "home node" information from CUPS.  CUPC will try to use "home node" as logon server afterwards.  This is why the login server field was populated with the node name (by default, it's the hostname).

You might want to ask "why does the client computer can resolve FQHN but not hostname?".  Please refer to the earlier section of this article.  It was because DNS suffix was "incorrect".  I put a quote around "incorrect" because sometimes, it can't be fixed.

Scenario #1.  The client computer is on a offsite location (mobile user, VPN, etc.), where the DNS suffix from DHCP is not the same as the corporate domain.  (e.g. "" instead of "")
Scenario #2.  Customer has multiple subdomains (e.g. "" and "").  The client computers are in different subdomains.

Workarounds (pick one below):
#1 On CUPC side, manually change the login server to FQHN on each login.
#2 On CUPC side, add the hostname to local hosts table (C:\Windows\System32\drivers\etc\hosts)
#3 On CUPS side, change the node name to FQHN.
#4 On CUPS side, change the node name to IP address.


  1. In CM 4.1, it was quite common (IMHO) to change the node name to IP address - precisely to prevent the DNS dependencies you've mentioned.

    In CM 6+, it begins to make more sense to have endpoints use DNS to resolve the name of CM and CUPS servers.

    I personally have used the option where CM and CUPS are configured with the hostname for the node name and relied on the endpoints (CUPC, IP Phones) to append the hostname and DHCP supplied domain name to make a FQDN to then resolve to IP and register, etc.

    I never knew it was possible to change the CM & CUPS node names to be a FQDN. If you change the node name to a FQDN value, does this value have to match the same FQDN that is configured in the server operating system? Or is the node name just an application level value that is independent of the underlying OS configuration?

    thanks alot, great blog by the way michael.

  2. If you change the node name to FQDN, you'd better make it match with the same FQDN configured on the OS (and in DNS). Otherwise, strange things could happen.

    For example, you may configure CUPS node name to any value you like (e.g. However, if CUPC clients cannot resolve this name, you won't be able to see presence (you may be able to login though).


  3. thanks for the reply.

    here are some things I've observed during some lab testing of CUP 7.0.2-10000-36.

    I installed CUP first node (CUPS7A) and changed the node name from hostname to FQDN. CUPC clients are happy and use this nodename/FQDN for both the 'logon server' and the 'presence server' within the 'show server health'.

    at this point, everything is good.

    Next, I installed a second CUP server (CUPS7B) into the CUP cluster. I added this CUP server to the same CUP subcluster along with CUPS7A.

    I changed the CUPS7B node name from hostname to FQDN.

    Now, I startup CUPC and it connects successfully to the logon server (CUPS7a) and to the presence server (also CUPS7a).

    However, if I unplug CUPS7a from the network I experience a problem that appears to be related to changing the CUPS7b server's node name to FQDN.

    The issue occurs when the CUPC client attempts to connect to the backup CUP server. When I look at the CUPC client and the 'show server health' I see that the 'logon server' has connected successfully to the nodename/FQDN ( However, the CUPC client can not connect to the backup "presence server". When I look at the 'show server health' the backup presence server is listed as Also in the show server health for the presence server is a setting titled "".

    From my testing, it seems that the CUPC client uses the value 'presence.primary.adddress' to connect to the primary CUP/presence server. But when the CUPC client attempts to connect to the backup CUP server it takes the value from 'presence.backup.address' and the value from 'presence.domain" concatenates them together and uses that value.

    this is causing trouble when CUPC tried to connect to the backup CUP server.

  4. Nice Article. Brings to mind MGCP gateway setup. In my current implimnetation, i fond a heavy reliabnce on DNS. I've never been comfortable using DNS on IOS devices, so I always end up creating a "host table" on my voice gateways using the "ip host foo" entries.