This document describes how to troubleshoot "Host Not Found" issues in the Corporate Directory feature of IP Phones. Important information relevant to this document is:
The Corporate Directory is a Cisco-provided default IP phone service which installs automatically with Cisco Unified Communications Manager (CUCM).
Information about phone subcription to the various phone services are stored in the database in the telecasterservice, telecasterserviceparameter, telecastersubscribedparameter, telecastersubscribedservice tables.
On the phone when you select the option "Corporate Directory", the phone sends either an HTTP or HTTPS request to one of the CUCM servers and is returned an XML object as an HTTP(S) response. If HTTPS then this also depends on the phone connecting to TVS service to verify the certificate for HTTPS. On phones that support midlets this may be implemented in the phone midlet and affected by Services Provisioning setting.
Clarify if the issue occurs when you access "Directories" or "Corporate Directory".
What is the "Service URL" field set to under the Corporate Directory service?
If the URL is set to "Application:Cisco/CorporateDirectory" then, based on the phone's firmware version, the phone makes either an HTTP or HTTPS request.
Phones that use firmware version 9.3.3 and later by default make an HTTPS request.
When the service URL is set to "Application:Cisco/CorporateDirectory", the phone sends the HTTP(S) request to the server which is first in it's CallManager (CM) group.
Identify the network topology between the phone and the server to which the HTTP(S) request is sent.
Pay attention to firewalls, WAN optimizers., and so on in the path which can drop/hamper HTTP(S) traffic.
If HTTPS is in use then ensure connectivity between the phone and TVS server and TVS is functioning.
In this scenario, the phone service URL is set to "Application:Cisco/CorporateDirectory" and the phone uses HTTPS.
This example shows the configuration file of the phone with the correct URL.
The Tomcat web certificate presented to the phone from the Directories server will not be available on the phone. Hence the phone attempts to authenticate the certificate via the Trust Verification Service (TVS).
7989 ERR 11:04:15.038637 SECD: -HTTPS cert not in CTL, <10.106.111.100:8443> 7990 NOT 11:04:15.038714 SECD: -TVS service available, will attempt via TVS
The phone looks in theTVS cache first and if not found it contacts the TVS server.
7995 NOT 11:04:15.039286 SECD: -TVS Certificate Authentication request 7996 NOT 11:04:15.039394 SECD: -No matching entry found at cache
Since the connection to theTVS is also secure, a certificate authentication is completed and this message is printed if it is successful.
8096 NOT 11:04:15.173585 SECD: -Successfully obtained a TLS connection to the TVS server
The phone now sends a request to authenticate the certificate.
8159 NOT 11:04:15.219065 SECD: -Successfully sent the certificate Authentication request to TVS server, bytes written : 962 8160 NOT 11:04:15.219141 SECD: -Done sending Certificate Validation request 8161 NOT 11:04:15.219218 SECD: -Authenticate Certificate : request sent to TVS server - waiting for response
The response "0" from theTVS means the authentication was successful.
8172 NOT 11:04:15.220060 SECD: -Authentication Response received, status : 0
This message is displayed and then you will see the response.
8185 NOT 11:04:15.221043 SECD: -Authenticated the HTTPS conn via TVS
Phone Service URL is Set to "Application:Cisco/CorporateDirectory" and the Phone Uses HTTP
Note: Instead of the use of an earlier phone firmware version, the service and secure service URL were hard-coded to the HTTP URL. However, the same sequence of events is seen in phone firmware which makes use of HTTP by default.
The configuration file of the phone has the correct URL.
From the packet captures you will see an HTTP GET request and a successful RESPONSE. This is the PCAP from CUCM:
Before you troubleshoot, gather the details of the issue listed earlier:
Logs to Collect, if Required
Simultaneous packet captures from the IP phone and from the CUCM server (the server which is first in it's CM group where the HTTP(S) request would be sent to).
IP phone console logs.
Cisco TVS logs (detailed).
When you set the TVS logs to detailed, the service needs to be restarted for the trace level changes to take place. See Cisco bug ID CSCuq22327 for the enhancement to notify that a service restart is required when log levels are changed.
Complete these steps in order to isolate the issue:
Create a test service with these details:
Service Name : <Any Name> Service URL : http://<CUCM_IP_Address>:8080/ccmcip/xmldirectoryinput.jsp Secure-Service URL : http://<CUCM_IP_Address>:8080/ccmcip/xmldirectoryinput.jsp Service Category : XML Service Service Type : Directories Enable : CHECK Enterprise Subscription : DO NOT CHECK
Now, subscribe this service to one of the affected phones:
Go to the device configuration page.
Select Subscribe/Unsubscribe Services under Related Links.
Subscribe the test service you created.
Save, apply the configuration, and reset the phone.
What you have done is, irrespective of the phone's FW version which determines whether to use the HTTP or HTTPS URL, force it to use the HTTP URL.
Access the "Corporate Directory" service on the phone.
If it does not work, then collect the logs mentioned above and compare them with the working scenario mentioned under the "Working Scenario" and identify where the deviation is.
If it works, then you have at least confirmed that from CUCM IP Phone service perspective there are no issues.
At this stage the issue could most probably be with the phones that use the HTTPS URL.
Now, pick a phone that does not work and proceed to next step.
When it works with this change, you need to decide if it is OK to leave the configuration with the corporate directory request/response that works over HTTP instead of HTTPS. HTTPS communication does not work due to one of the reasons discussed next.
Collect the logs mentioned previously and compare them with the working scenario mentioned under the "Working Scenario" and identify where the deviation is.
It could be one of these issues:
The phone is unable to contact the TVS server.
In the PCAPS, verify the communication on port 2445.
Ensure that none of the network devices in the path block this port.
The phone contacts the TVS server, but the TLS handshake fails.
These lines will be printed in the phone console logs:
05:54:47.836 | debug CertificateCTLCache::getCertificateInformation - Looking up the certificate cache using Unique MAP ID : 62E09123B09A61D20E77BE5BF5A82CD4CN=cucmpub9;OU=TAC;O=Cisco;L=Bangalore;ST=KN;C=IN 05:54:47.836 |<--debug 05:54:47.836 |-->debug 05:54:47.836 | debug ERROR:CertificateCTLCache::getCertificateInformation - Cannot find the certificate in the cache 05:54:47.836 |<--debug 05:54:47.836 |-->debug 05:54:47.836 | debug getCertificateInformation(cert) : certificate not found
HTTPS traffic is blocked/dropped somewhere in the network.
Get simultaneous PCAPs from the phone and the CUCM server in order to verify the communication.
Other Scenarios When the "Host Not Found" Issue Occurs
The CUCM server is defined by the hostname along with issues in name resolution.
The TVS server list is empty on the phone when it downloads the xmldefault.cnf.xml file. (In Version 8.6.2 the default configuration file will not have the TVS entry in it due to Cisco bug ID CSCti64589.)
The phone is unable to use the TVS entry in the configuration file because it downloaded the xmldefault.cnf.xml file. See Cisco bug ID CSCuq33297 - Phone to parse TVS information from the default configuration file.
The Corporate Directory does not work after a CUCM upgrade because the phone firmware upgrades to a later version which eventually changes the behavior of the use of HTTPS by default.