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, sales.apac.acme.com. 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 ccm-1.acme.com. consists of a hostname ccm-1 and a FQDN acme.com.

 

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 "ccm-1.acme.com" 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. cups1.acme.com) 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 cups1.acme.com.  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. "isp.com" instead of "acme.com")

 

Scenario #2.  Customer has multiple subdomains (e.g. "apac.acme.com" and "emea.acme.com").  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.