Thursday, 21 September 2017

Troubleshooting Causes of "host not found" Error When Using Extension Mobility or Phone Services

There's several common causes for a phone to display "host not found" when pressing the Services or Directories buttons, or accessing Extension Mobility. Contrary to what the error message implies, often it's not actually a DNS issue that's the cause. Phone services rely on HTTP or HTTPS, with services hosted by CUCM handled by the Tomcat web server & using TCP ports 8080 or 8443.

First of all it's important to understand which server the phone is trying to access, as the default services built into CUCM use a load balancing mechanism by default, a detailed explanation of which can be found in the SRND. In summary by default built in services (i.e. service URLs starting Application:) use HTTPS & use a load balancing mechanism so that the phone will rewrite the service URL to point to the CUCM server with which it is currently registered.

DNS
DNS is only an issue if the service URL contains an FQDN or hostname, or in the case of built in services, if the Servers in CUCM are defined as an FQDN or hostname. Confirm that the phone actually has DNS servers configured, that these DNS servers are reachable & can resolve the FQDN or hostname.

SSL
You can confirm whether a service will be accessed via HTTPS by looking at the configuration to see if a Secure Service URL has been set, or for built in services, if the phone's configuration file contains <phoneServices useHTTPS="true">. This will allow you to confirm which port the phone will try to use to access the service.

Web Server
Check if the web server is inaccessible, try telnetting to the relevant port or viewing the service URL. For CUCM's built in services, also confirm that the Tomcat service is running on the relevant server.

Certificate Trust
If the web server's certificate isn't present in the phone's ITL/CTL file, the inability to verify the certificate can cause the host not found error.
Confirm that the phone has learnt TFTP server addresses via DHCP option 150 or manual configuration, otherwise it won't be able to update its configuration & may be caching out of date ITL/CTL files.
For certificates that aren't in the ITL/CTL, the phone should attempt to contact the Trust Verification Service on CUCM via TCP port 2445. If the TVS service isn't enabled or isn't running, or cannot be reached then certificate verification will fail. Note that the TVS service also uses a certificate that must in the ITL for the phone to trust it.

Phone Logs
The phone's logs provide insight into what's happening, for example failure to access the TVS service will show up in the logs. Accessing these logs requires that the phone's web server is enabled, which isn't the case by default in CUCM. Also network settings, such as DNS or TFTP server(s) can be verified via the phone's web server.

No comments:

Post a Comment