Corporate Directory "host niet gevonden" Problemen

Inleiding

Dit document beschrijft hoe u problemen met "Host Not Found" bij de Corporate Directory-functie van IP-telefoons kunt oplossen. Belangrijke informatie die voor dit document relevant is, is:

• De Corporate Directory is een door Cisco meegeleverde standaard IP-telefoonservice die automatisch wordt geïnstalleerd via Cisco Unified Communications Manager (CUCM).
• Informatie over telefoonabonnement op de verschillende telefoondiensten wordt opgeslagen in de database in de telecasterservice, telecasterservice, parameter voor telecasterabonnees, telecastersubscribedparameter, telecastersubscribedservice-tabellen.
• Op de telefoon wanneer u de optie "Corporate Directory" selecteert, verstuurt de telefoon een HTTP- of HTTPS-verzoek naar een van de CUCM-servers en wordt een XML-object teruggegeven als een HTTP(S)-respons. Als HTTPS dit ook afhankelijk is van de telefoon die met de TVS-dienst verbindt om het certificaat voor HTTPS te controleren. Op telefoons die midlets ondersteunen kan dit in de telefoon midlet worden geïmplementeerd en door de instelling Provisioning van services worden beïnvloed.

Belangrijke informatie

• Verduidelijk als het probleem zich voordoet wanneer u "Mappen" of "Hoofdmap" bekijkt.
• Wat is het veld "Service URL" ingesteld onder de Corporate Directory-service?
  • Als de URL is ingesteld op "Application:Cisco/CorporateDirectory" dan maakt de telefoon op basis van de firmware-versie van de telefoon een HTTP- of HTTPS-aanvraag.
  • Telefoons die firmware versie 9.3.3 gebruiken en later standaard een HTTPS-aanvraag indienen.
• Wanneer de service-URL is ingesteld op "Application:Cisco/CorporateDirectory", stuurt de telefoon het HTTP(S)-verzoek naar de server die eerst in de CallManager (CM)-groep staat.
• Identificeer de netwerktopologie tussen de telefoon en de server waaraan het HTTP(S) verzoek wordt verzonden.
• Let op firewalls, WAN-optimalisators... en ga zo maar door in het pad dat HTTP(S)-verkeer kan laten vallen/belemmeren.
• Als HTTPS in gebruik is, zorg er dan voor dat de verbinding tussen de telefoon en TVS server en TVS werkt.

Werkscenario

In dit scenario wordt de URL van de telefoondienst ingesteld op "Application:Cisco/CorporateDirectory" en wordt HTTPS gebruikt.

Dit voorbeeld toont het configuratiebestand van de telefoon met de juiste URL.

<phoneService  type="1" category="0">
<name>Corporate Directory</name>
<url>Application:Cisco/CorporateDirectory</url>
<vendor></vendor>
<version></version>
</phoneService>

Vanaf de logbestanden van de telefoonconsole kunt u deze stappen controleren.

1. De telefoon gebruikt de 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::getCdUrl:
   [thread=appmgr MQThread]
   [class=cip.app.ar] Using HTTPS URL

2. Het webcertificaat van Tomcat dat bij de telefoon van de directories server wordt aangeboden, is niet beschikbaar aan de telefoon. Vandaar dat de telefoon probeert om het certificaat te authentiseren via de Vertrouwingsdienst (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

3. De telefoon kijkt eerst in de TVS cache en als hij niet gevonden wordt, neemt hij contact op met de 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

4. Aangezien de verbinding met de TVS ook veilig is, wordt een certificatie van certificaten voltooid en wordt dit bericht afgedrukt als het succesvol is.

   8096 NOT 11:04:15.173585  SECD: -Successfully obtained a TLS connection
    to the TVS server

5. De telefoon stuurt nu een verzoek om het certificaat te echt te verklaren.

   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. De respons "0" van de TVS betekent dat de authenticatie succesvol was.

   8172 NOT 11:04:15.220060  SECD: -Authentication Response received, status : 0

7. Dit bericht wordt weergegeven en dan ziet u het antwoord.

   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>

   De certificeringsprocedure is vergelijkbaar met de procedure die wordt besproken in de telefooncontactdoos voor de verificatieservice voor onbekend certificaat.

   Van de pakketvastlegging (PCAPs) die aan het telefooneind wordt verzameld, dient u de TVS-communicatie met het gebruik van dit filter te kunnen verifiëren - "tcp.port==2445".

In de gelijktijdige TVS-documenten:

1. Bekijk de sporen met betrekking tot de handdruk van transportlaag (TLS).
2. Kijk vervolgens naar het inkomende hex-dumpen.

   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. De VS halen de gegevens van de emittent op.

   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. De TVS verifieert het certificaat.

   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. De TVS stuurt het antwoord naar de telefoon.

   04:04:15.272 |   debug 2:UNKNOWN:Sending CERT_VERIF_RES msg
   04:04:15.272 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_RES

URL voor telefoonservice is ingesteld op "Application:Cisco/Corporate Directory" en de telefoon gebruikt HTTP

Opmerking: In plaats van het gebruik van een eerdere versie van de telefoonfirmware, waren de service- en beveiligde URL zwaar gecodeerd naar de HTTP URL. Echter, de zelfde opeenvolging van gebeurtenissen wordt gezien in telefoon firmware die van HTTP standaard gebruik maakt.

Het configuratiebestand van de telefoon heeft de juiste URL.

<phoneService  type="1" category="0">
<name>Corporate Directory</name>
<url>Application:Cisco/CorporateDirectory</url>
<vendor></vendor>
<version></version>
</phoneService>

Vanaf de logbestanden van de telefoonconsole kunt u deze stappen controleren.

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

Van het pakket zal u een HTTP GET aanvraag en een succesvolle RESPONSE zien. Dit is het PCAP van CUCM:

Problemen oplossen

Voordat u een oplossing voor problemen hebt gevonden, verzamelt u de details van de eerder genoemde kwestie:

Aanmelden om te verzamelen, indien vereist

• Gelijktijdige pakketvastlegging van de IP-telefoon en de CUCM-server (de server die als eerste in de CM-groep zit waar het HTTP(S)-verzoek naar wordt verzonden).
• IP-telefoonconsole logt.
• Cisco TVS-bestanden (gedetailleerd).

  Wanneer u de TVS-logbestanden op gedetailleerde informatie instelt, moet de service opnieuw worden gestart zodat er wijzigingen in het spoorniveau kunnen worden aangebracht. Zie Cisco bug-ID CSCuq22327 voor de verbetering om aan te geven dat er een service-start nodig is wanneer de logniveaus worden gewijzigd.

Voltooi deze stappen om het probleem te isoleren:

Stap 1

Maak een testservice met deze 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

Stel deze service nu in op een van de betreffende telefoons:

1. Ga naar de pagina voor apparaatconfiguratie.
2. Selecteer Services onder Verwante links Abonneren/Niet-tekenen.
3. Subscriber de testservice die u hebt gemaakt.
4. Save, pas de configuratie toe en herstelt de telefoon.
   1. Wat je hebt gedaan is, ongeacht de FW versie van de telefoon die bepaalt of je de HTTP of HTTPS URL gebruikt, dwingen hem om de HTTP URL te gebruiken.
   2. Toegang tot de "Corporate Directory" service aan de telefoon.
   3. Indien dit niet werkt, verzamel dan de hierboven genoemde stammen en vergelijk ze met het in het "werkscenario" vermelde werkscenario en identificeer waar de afwijking is.
   4. Als het werkt, dan hebt u op zijn minst bevestigd dat er vanuit het serviceperspectief van de CUCM IP-telefoon geen problemen zijn.
   5. In dit stadium zou de kwestie waarschijnlijk kunnen zijn met de telefoons die de HTTPS URL gebruiken.
   6. Kies nu een telefoon die niet werkt en ga verder met de volgende stap.

Wanneer het met deze verandering werkt, moet u beslissen of het OK is om de configuratie te verlaten met het bedrijf folder verzoek/reactie dat over HTTP in plaats van HTTPS werkt. HTTPS-communicatie werkt niet vanwege een van de volgende redenen.

Stap 2

Verzamel de eerder genoemde stammen en vergelijk ze met het werkscenario dat in het "werkscenario" wordt genoemd en kies waar de afwijking is.

Het zou een van deze kwesties kunnen zijn:

1. De telefoon kan geen contact opnemen met de TVS server.
   1. Controleer in het PCAPS de mededeling over poort 2445.
   2. Zorg ervoor dat geen van de netwerkapparaten in het pad deze poort blokkeert.
2. De telefoon contacteert de TVS server, maar de TLS handdruk faalt.

   Deze lijnen zullen in de logboeken van de telefoonconsole worden afgedrukt:

   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>

   Zie Cisco bug-ID CSCua65618 voor meer informatie.
   
   

3. De telefoon neemt contact op met de TVS-servers en de TLS-handdruk is succesvol, maar de TVS is niet in staat de handtekening van het certificaat te controleren dat de telefoon heeft gevraagd om echt te verklaren.

   Hieronder vind je fragmenten uit TVS logs:

   De telefoon neemt contact op met de 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

   De TVS krijgt de naam van de emittent.

   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

   Hij kijkt het certificaat op, maar kan het niet vinden.

   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 verkeer is geblokkeerd/geworpen ergens in het netwerk.

   Geniet van gelijktijdige PCAP van de telefoon en de CUCM server om de communicatie te verifiëren.

Andere scenario's wanneer het "host Not found"-probleem zich voordoet

1. De CUCM server wordt gedefinieerd door de hostname samen met problemen in naamresolutie.
2. De lijst met TVS-servers is leeg aan de telefoon wanneer deze het bestand xmldefault.cnf.xml downloaden. (In versie 8.6.2 zal het standaardconfiguratiebestand niet de TVS-ingang in het bestand hebben dankzij Cisco bug ID CSCti64589.)
3. De telefoon kan het TVS-item in het configuratiebestand niet gebruiken omdat het bestand xmldefault.cnf.xml is gedownload. Zie Cisco bug-ID CSCuq3297 - telefoon om TVS-informatie uit het standaardconfiguratiebestand te verwijderen.
4. De Corporate Directory werkt niet na een CUCM-upgrade omdat de software van de telefoonfirmware upgrades naar een latere versie uitvoert die uiteindelijk standaard het gedrag van HTTPS wijzigt.