PDF(52.4 KB) View with Adobe Reader on a variety of devices
ePub(93.1 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(84.3 KB) View on Kindle device or Kindle app on multiple devices
Updated:June 8, 2023
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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 subscription 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 as 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 can 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 UR 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 that 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 is not 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, can attempt via TVS
The phone looks in the TVS 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 the TVS 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 the TVS means the authentication was successful.
8172 NOT 11:04:15.220060 SECD: -Authentication Response received, status : 0
This message is displayed, and then you 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 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.
Choose Subscribe/Unsubscribe Services under Related Links.
Subscribe the test service you created.
Save, apply the configuration, and reset the phone.
What you have done, irrespective of the phone's FW version, which determines whether to use the HTTP or HTTPS URL, is 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 previously, and compare them with the working scenario mentioned under the Working Scenario section, 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 is most likely 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 section, 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 can 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 does 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.
Added TOC and Background Information.
Updated Title, Introduction, SEO, Alt Text, Machine Translation, Style Requirements and Formatting.