Inhalt

Einleitung

Hintergrundinformationen

Wichtige Informationen

Arbeitsszenario

Die Telefondienst-URL ist auf "Application:Cisco/Corporate Directory" (Anwendung:Cisco/Firmenverzeichnis) festgelegt, und das Telefon verwendet HTTP.

Fehlerbehebung

Andere Szenarien, in denen das Problem "Host nicht gefunden" auftritt

Einleitung

In diesem Dokument wird beschrieben, wie Sie Probleme mit dem Eintrag "Host nicht gefunden" in der Funktion "Firmenverzeichnis" von IP-Telefonen beheben.

Hintergrundinformationen

Wichtige Informationen zu diesem Dokument:

- Das Firmenverzeichnis ist ein von Cisco bereitgestellter Standard-IP-Telefondienst, der automatisch mit Cisco Unified Communications Manager (CUCM) installiert wird.

- Informationen über Telefonabonnements für die verschiedenen Telefondienste werden in der Datenbank in den Tabellen für den Telecasterservice, den Telecasterserviceparameter, den Telecastersubscribedparameter und den Telecastersubscribedservice gespeichert.

- Wenn Sie auf dem Telefon die Option Firmenverzeichnis auswählen, sendet das Telefon entweder eine HTTP- oder HTTPS-Anforderung an einen der CUCM-Server und wird als XML-Objekt als HTTP(S)-Antwort zurückgegeben. Bei HTTPS hängt dies auch vom Telefon ab, das sich mit dem TVS-Dienst verbindet, um das Zertifikat für HTTPS zu überprüfen. Bei Telefonen, die Midlets unterstützen, kann dies im Telefon-Midlet implementiert werden und von den Services Provisioning-Einstellungen beeinflusst werden.

Wichtige Informationen

- Klärung, ob das Problem beim Zugriff auf Verzeichnisse oder Firmenverzeichnisse auftritt

- Wie lautet die Service-URL im Corporate Directory-Dienst?

- Wenn die URL auf Application:Cisco/CorporateDirectory festgelegt ist, sendet das Telefon basierend auf der Firmware-Version des Telefons eine HTTP- oder HTTPS-Anforderung.

- Telefone, die die Firmware-Version 9.3.3 oder höher verwenden, stellen standardmäßig eine HTTPS-Anforderung.

- Wenn die Service-URL auf Application:Cisco/CorporateDirectory festgelegt ist, sendet das Telefon die HTTP(S)-Anforderung an den Server, der sich zuerst in der CallManager (CM)-Gruppe befindet.

- Identifizieren Sie die Netzwerktopologie zwischen dem Telefon und dem Server, an den die HTTP(S)-Anforderung gesendet wird.

- Achten Sie auf Firewalls, WAN-Optimierer usw. in dem Pfad, der HTTP(S)-Datenverkehr verwerfen/behindern kann.

- Wenn HTTPS verwendet wird, stellen Sie die Verbindung zwischen dem Telefon und dem TVS-Server sicher, und stellen Sie sicher, dass der TVS funktioniert.

Arbeitsszenario

In diesem Szenario wird die Telefondienst-URL auf Application:Cisco/CorporateDirectory festgelegt, und das Telefon verwendet HTTPS.

Dieses Beispiel zeigt die Konfigurationsdatei des Telefons mit der richtigen URL.

<phoneService  type="1" category="0">

<name>Corporate Directory</name>

<url>Application:Cisco/CorporateDirectory</url>

<vendor></vendor>

<version></version>

</phoneService>

Aus den Telefonkonsolenprotokollen können Sie diese Schritte überprüfen.

1. Das Telefon verwendet die HTTPS-URL.
7949 NOT 11:04:14.765155  CVM-appLaunchRequest: [thread=AWT-EventQueue-0]

[class=cip.app.G4ApplicationManager] Creating application module -

Corporate Directory

7950 ERR 11:04:14.825312  CVM-XsiAppData&colon;:getCdUrl:

[thread=appmgr MQThread]

[class=xxx.xxx.xx] Using HTTPS URL

2. Das Tomcat-Webzertifikat, das dem Telefon vom Verzeichnisserver übermittelt wird, ist auf dem Telefon nicht verfügbar. Daher versucht das Telefon, das Zertifikat über den Trust Verification Service (TVS) zu authentifizieren.
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

3. Das Telefon sucht zuerst im TVS-Cache und kontaktiert den TVS-Server, falls es nicht gefunden wird.
7995 NOT 11:04:15.039286  SECD: -TVS Certificate Authentication request

7996 NOT 11:04:15.039394  SECD: -No matching entry found at cache

4. Da die Verbindung zum TVS ebenfalls sicher ist, ist eine Zertifikatsauthentifizierung abgeschlossen, und diese Nachricht wird ausgegeben, wenn sie erfolgreich ist.
8096 NOT 11:04:15.173585  SECD: -Successfully obtained a TLS connection

to the TVS server

5. Das Telefon sendet jetzt eine Anforderung zur Authentifizierung des Zertifikats.
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

6. Die Antwort "0" vom TVS bedeutet, dass die Authentifizierung erfolgreich war.
8172 NOT 11:04:15.220060  SECD: -Authentication Response received, status : 0

7. Diese Meldung wird angezeigt, und dann wird die Antwort angezeigt.
8185 NOT 11:04:15.221043  SECD: -Authenticated the HTTPS conn via TVS

8198 NOT 11:04:15.296173  CVM-[truncated] Received

HTTP/1.1 200 OK^M

X-Frame-Options: SAMEORIGIN^M

Set-Cookie: JSESSIONID=660646D3655BB00734D3895606BCE76F;

Path=/ccmcip/; Secure; HttpOnly^M

Content-Type: text/xml;charset=utf-8^M

Content-Length: 966^M

Date: Tue, 30 Sep 2014 11:04:15 GMT^M

Server:  ^M

^M

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><CiscoIPPhoneInput>

<Title>Directory Search</Title><Prompt>Enter search criteria</Prompt><SoftKeyItem>

<Name>Search</Name><Position>1</Position><URL>SoftKey:Submit</URL></SoftKeyItem>

<SoftKeyItem><Name>&lt;&lt;</Name><Position>2</Position><URL>SoftKey:&lt;&lt;</URL>

</SoftKeyItem><SoftKeyItem><Name>Cancel</Name><Position>3</Position>

<URL>SoftKey:Cancel</URL></SoftKeyItem>

<URL>https://10.106.111.100:8443/ccmcip/xmldirectorylist.jsp</URL>

<InputItem><DisplayName>First Name</DisplayName>

<QueryStringParam>f</QueryStringParam><InputFlags>A</InputFlags>

<DefaultValue></DefaultValue></InputItem><InputItem>

<DisplayName>Last Name</DisplayName><QueryStringParam>l</QueryStringParam>

<InputFlags>A</InputFlags><DefaultValue></DefaultValue></InputItem><InputItem>

<DisplayName>

Der Zertifikatauthentifizierungsprozess ähnelt dem unter Telefonkontakte - Vertrauensverifizierungsdienst für unbekanntes Zertifikat beschriebenen Prozess.

Aus den telefonisch erfassten Paketerfassungen (PCAPs) können Sie die TVS-Kommunikation mithilfe dieses Filters überprüfen - tcp.port==2445.

Bei gleichzeitigen TVS-Protokollen:

1. Überprüfen Sie die Rückverfolgungen hinsichtlich des TLS-Handshakes (Transport Layer Security).

2. Überprüfen Sie anschließend den eingehenden Hex Dump.
04:04:15.270 |   debug ipAddrStr (Phone) 10.106.111.121

04:04:15.270 |<--debug

04:04:15.270 |-->debug

04:04:15.270 |   debug 2:UNKNOWN:Incoming Phone Msg:

.

.

04:04:15.270 |   debug

HEX_DUMP: Len = 960:

04:04:15.270 |<--debug

04:04:15.270 |-->debug

04:04:15.270 |   debug 57 01 01 00 00 00 03 ea

.

<< o/p omitted >>

.

04:04:15.271 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_REQ

3. Der TVS ruft die Details zum Aussteller ab.
04:04:15.272 |-->CDefaultCertificateReader::GetIssuerName

04:04:15.272 |   CDefaultCertificateReader::GetIssuerName got issuer name

04:04:15.272 |<--CDefaultCertificateReader::GetIssuerName

04:04:15.272 |-->debug

04:04:15.272 |   debug tvsGetIssuerNameFromX509 - issuerName :

CN=cucm10;OU=TAC;O=Cisco;L=Blore;ST=KN;C=IN and Length: 43

04:04:15.272 |<--debug

4. Der TVS verifiziert das Zertifikat.
04:04:15.272 |   debug tvsGetSerialNumberFromX509 - serialNumber :

6F969D5B784D0448980F7557A90A6344 and Length: 16

04:04:15.272 |   debug CertificateDBCache::getCertificateInformation -

Looking up the certificate cache using Unique MAP ID :

6F969D5B784D0448980F7557A90A6344CN=cucm10;OU=TAC;O=Cisco;L=Blore;ST=KN;C=IN

04:04:15.272 |   debug CertificateDBCache::getCertificateInformation -

Certificate compare return =0

04:04:15.272 |   debug CertificateDBCache::getCertificateInformation -

Certificate found and equal

5. Der TVS sendet die Antwort an das Telefon.
04:04:15.272 |   debug 2:UNKNOWN:Sending CERT_VERIF_RES msg

04:04:15.272 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_RES

Die Telefondienst-URL ist auf "Application:Cisco/Corporate Directory" (Anwendung:Cisco/Firmenverzeichnis) festgelegt, und das Telefon verwendet HTTP.

Hinweis: Anstatt eine frühere Telefon-Firmware-Version zu verwenden, wurden der Service und die sichere Service-URL als feste Codes für die HTTP-URL festgelegt. Die gleiche Ereignissequenz tritt jedoch auch in der Telefon-Firmware auf, die standardmäßig HTTP verwendet.

Die Konfigurationsdatei des Telefons hat die richtige URL.

<phoneService  type="1" category="0">

<name>Corporate Directory</name>

<url>Application:Cisco/CorporateDirectory</url>

<vendor></vendor>

<version></version>

</phoneService>

Aus den Telefonkonsolenprotokollen können Sie diese Schritte überprüfen.

7250 NOT 11:44:49.981390  CVM-appLaunchRequest: [thread=AWT-EventQueue-0]

[class=cip.app.G4ApplicationManager] Creating application module -

Corporate Directory/-838075552

7254 NOT 11:44:50.061552  CVM-_HTTPMakeRequest1: Processing Non-HTTPS URL

7256 NOT 11:44:50.061812  CVM-_HTTPMakeRequest1() theHostname: 10.106.111.100:8080

7265 NOT 11:44:50.233788  CVM-[truncated] Received

HTTP/1.1 200 OK^M

X-Frame-Options: SAMEORIGIN^M

Set-Cookie: JSESSIONID=85078CC96EE59CA822CD607DDAB28C91;

Path=/ccmcip/; HttpOnly^M

Content-Type: text/xml;charset=utf-8^M

Content-Length: 965^M

Date: Tue, 30 Sep 2014 11:44:50 GMT^M

Server:  ^M

^M

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><CiscoIPPhoneInput>

<Title>Directory Search</Title><Prompt>Enter search criteria</Prompt><SoftKeyItem>

<Name>Search</Name><Position>1</Position><URL>SoftKey:Submit</URL></SoftKeyItem>

<SoftKeyItem><Name>&lt;&lt;</Name><Position>2</Position><URL>SoftKey:&lt;&lt;</URL>

</SoftKeyItem><SoftKeyItem><Name>Cancel</Name><Position>3</Position>

<URL>SoftKey:Cancel</URL></SoftKeyItem>

<URL>http://10.106.111.100:8080/ccmcip/xmldirectorylist.jsp</URL><InputItem>

<DisplayName>First Name</DisplayName><QueryStringParam>f</QueryStringParam>

<InputFlags>A</InputFlags><DefaultValue></DefaultValue></InputItem><InputItem>

<DisplayName>Last Name</DisplayName><QueryStringParam>l</QueryStringParam>

<InputFlags>A</InputFlags><DefaultValue></DefaultValue></InputItem><InputItem>

<DisplayName>Number</D

Bei der Paketerfassung werden eine HTTP GET-Anforderung und eine erfolgreiche ANTWORT angezeigt. Dies ist das PCAP vom CUCM:

Fehlerbehebung

Bevor Sie die Fehlerbehebung durchführen, sollten Sie die Details zu dem zuvor aufgeführten Problem ermitteln:

Bei Bedarf zu erfassende Protokolle

- Simultane Paketerfassung vom IP-Telefon und vom CUCM-Server (dem Server, der sich zuerst in seiner CM-Gruppe befindet, an den die HTTP(S)-Anforderung gesendet werden würde).

- Konsolenprotokolle des IP-Telefons

- Cisco TVS-Protokolle (detailliert).
Wenn Sie die TVS-Protokolle auf "detailliert" festlegen, muss der Dienst neu gestartet werden, damit die Änderungen der Ablaufverfolgungsebene stattfinden. Unter der Cisco Bug-ID CSCuq22327 finden Sie Informationen zur Erweiterung, um anzuzeigen, dass ein Neustart des Service erforderlich ist, wenn die Protokollstufen geändert werden.

Gehen Sie wie folgt vor, um das Problem zu isolieren:

Schritt 1:

Erstellen Sie einen Testservice mit folgenden 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

Jetzt abonnieren Sie diesen Service für eines der betroffenen Telefone:

1. Gehen Sie zur Seite für die Gerätekonfiguration.

2. Wählen Sie Services abonnieren/abbestellen unter Zugehörige Links.

3. Abonnieren Sie den von Ihnen erstellten Testservice.

4. Speichern, Konfiguration übernehmen und Telefon zurücksetzen

1. Unabhängig von der FW-Version des Telefons, die bestimmt, ob die HTTP- oder HTTPS-URL verwendet werden soll, müssen Sie die Verwendung der HTTP-URL erzwingen.

2. Greifen Sie auf das Firmenverzeichnis am Telefon zu.

3. Wenn es nicht funktioniert, sammeln Sie die oben genannten Protokolle, vergleichen Sie sie mit dem im Abschnitt "Arbeitsszenario" genannten Arbeitsszenario, und geben Sie an, wo die Abweichung liegt.

4. Wenn es funktioniert, haben Sie zumindest bestätigt, dass es aus Sicht des CUCM-IP-Telefondienstes keine Probleme gibt.

5. In dieser Phase ist das Problem am wahrscheinlichsten bei Telefonen, die die HTTPS-URL verwenden.

6. Wählen Sie nun ein Telefon aus, das nicht funktioniert, und fahren Sie mit dem nächsten Schritt fort.

Wenn diese Änderung durchgeführt wird, müssen Sie entscheiden, ob es in Ordnung ist, die Konfiguration mit der Anforderung/Antwort des Unternehmensverzeichnisses zu belassen, die über HTTP statt HTTPS funktioniert. Die HTTPS-Kommunikation funktioniert aus einem der im Folgenden genannten Gründe nicht.

Schritt 2:

Sammeln Sie die oben genannten Protokolle, und vergleichen Sie sie mit dem im Abschnitt "Arbeitsszenario" genannten Arbeitsszenario. Ermitteln Sie, wo die Abweichung liegt.

Dabei könnte es sich um eines der folgenden Themen handeln:

1. Das Telefon kann keine Verbindung zum TVS-Server herstellen.

1. Überprüfen Sie im PCAPS die Kommunikation an Port 2445.

2. Stellen Sie sicher, dass keines der Netzwerkgeräte im Pfad diesen Port blockiert.

2. Das Telefon kontaktiert den TVS-Server, aber der TLS-Handshake schlägt fehl.
Die folgenden Zeilen können in den Telefonkonsolenprotokollen ausgegeben werden:

5007: NOT 10:25:10.060663 SECD: clpSetupSsl: Trying to connect to IPV4,

IP: 192.168.136.6, Port : 2445

5008: NOT 10:25:10.062376 SECD: clpSetupSsl: TCP connect() waiting,

<192.168.136.6> c:14 s:15 port: 2445

5009: NOT 10:25:10.063483 SECD: clpSetupSsl: TCP connected,

<192.168.136.6> c:14 s:15

5010: NOT 10:25:10.064376 SECD: clpSetupSsl: start SSL/TLS handshake,

<192.168.136.6> c:14 s:15

5011: ERR 10:25:10.068387 SECD: EROR:clpState: SSL3 alert

read:fatal:handshake failure:<192.168.136.6>

5012: ERR 10:25:10.069449 SECD: EROR:clpState: SSL_connect:failed in SSLv3

read server hello A:<192.168.136.6>

5013: ERR 10:25:10.075656 SECD: EROR:clpSetupSsl: ** SSL handshake failed,

<192.168.136.6> c:14 s:15

5014: ERR 10:25:10.076664 SECD: EROR:clpSetupSsl: SSL/TLS handshake failed,

<192.168.136.6> c:14 s:15

5015: ERR 10:25:10.077808 SECD: EROR:clpSetupSsl: SSL/TLS setup failed,

<192.168.136.6> c:14 s:15

5016: ERR 10:25:10.078771 SECD: EROR:clpSndStatus: SSL CLNT ERR,

srvr<192.168.136.6>

Weitere Informationen finden Sie unter Cisco Bug-ID CSCua65618.

3. Das Telefon kontaktiert die TVS-Server, und der TLS-Handshake ist erfolgreich, aber der TVS kann den Unterzeichner des Zertifikats, das das Telefon authentifizieren soll, nicht überprüfen.
Ausschnitte aus TVS-Protokollen werden hier aufgelistet:
Das Telefon kontaktiert den TVS.

05:54:47.779 |   debug 7:UNKNOWN:Got a new ph conn 10.106.111.121 on 10, Total Acc = 6..

.

.

05:54:47.835 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_REQ

Der TVS ruft den Namen des Ausstellers ab.

05:54:47.836 |-->CDefaultCertificateReader::GetIssuerName

05:54:47.836 |   CDefaultCertificateReader::GetIssuerName got issuer name

05:54:47.836 |<--CDefaultCertificateReader::GetIssuerName

05:54:47.836 |-->debug

05:54:47.836 |   debug tvsGetIssuerNameFromX509 - issuerName :

CN=cucmpub9;OU=TAC;O=Cisco;L=Bangalore;ST=KN;C=IN and Length: 49

Er sucht nach dem Zertifikat, kann es jedoch nicht finden.

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

4. HTTPS-Datenverkehr wird im Netzwerk blockiert/blockiert.
Rufen Sie gleichzeitig PCAPs vom Telefon und vom CUCM-Server ab, um die Kommunikation zu überprüfen.

Andere Szenarien, in denen das Problem "Host nicht gefunden" auftritt

1. Der CUCM-Server wird durch den Hostnamen und die Probleme bei der Namensauflösung definiert.

2. Die TVS-Serverliste ist auf dem Telefon leer, wenn die Datei "xmldefault.cnf.xml" heruntergeladen wird. (In Version 8.6.2 enthält die Standardkonfigurationsdatei aufgrund der Cisco Bug-ID CSCti64589 keinen TVS-Eintrag.)

3. Das Telefon kann den TVS-Eintrag in der Konfigurationsdatei nicht verwenden, da es die Datei "xmldefault.cnf.xml" heruntergeladen hat. Siehe Cisco Bug-ID CSCuq3297 - Phone, um TVS-Informationen aus der Standardkonfigurationsdatei zu analysieren.

4. Das Firmenverzeichnis funktioniert nach einem CUCM-Upgrade nicht, da die Telefon-Firmware auf eine neuere Version aktualisiert wird, die das Verhalten der Verwendung von HTTPS standardmäßig ändert.