Diretório corporativo "Host não encontrado" Problemas

Introduction

Este documento descreve como solucionar problemas do "Host Não Encontrado" no recurso Corporate Diretory dos Telefones IP. Informações importantes relevantes para este documento são:

• O diretório corporativo é um serviço de telefone IP padrão fornecido pela Cisco que é instalado automaticamente com o Cisco Unified Communications Manager (CUCM).
• As informações sobre a assinatura do telefone para os vários serviços de telefone são armazenadas no banco de dados no telecasterservice, telecasterserviceparameter, telecastersubscribedparameter, telecastersubscribedservice tables.
• No telefone quando você seleciona a opção "Diretório corporativo", o telefone envia uma solicitação HTTP ou HTTPS para um dos servidores CUCM e retorna um objeto XML como resposta HTTP(S). Se HTTPS, isso também depende do telefone que se conecta ao serviço TVS para verificar o certificado para HTTPS. Em telefones que suportam midlets, isso pode ser implementado no midlet do telefone e afetado pela configuração do Provisionamento de Serviços.

Informações importantes

• Esclareça se o problema ocorre quando você acessa "Diretórios" ou "Diretório corporativo".
• Como é definido o campo "URL do serviço" no serviço Corporate Diretory?
  • Se o URL estiver definido como "Application:Cisco/CorporateDirectory", então, com base na versão do firmware do telefone, o telefone faz uma solicitação HTTP ou HTTPS.
  • Os telefones que usam a versão de firmware 9.3.3 e posterior por padrão fazem uma solicitação HTTPS.
• Quando a URL do serviço é definida como "Application:Cisco/CorporateDirectory", o telefone envia a solicitação HTTP(S) ao servidor, que está primeiro no grupo CallManager (CM).
• Identifique a topologia de rede entre o telefone e o servidor para o qual a solicitação HTTP(S) é enviada.
• Preste atenção a firewalls, otimizadores de WAN e assim por diante no caminho que pode derrubar/atrapalhar o tráfego HTTP(S).
• Se o HTTPS estiver em uso, verifique se a conectividade entre o telefone e o servidor TVS e o TVS está funcionando.

Cenário de trabalho

Neste cenário, o URL do serviço telefônico é definido como "Application:Cisco/CorporateDirectory" e o telefone usa HTTPS.

Este exemplo mostra o arquivo de configuração do telefone com a URL correta.

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

Nos registros do console do telefone, você poderá verificar essas etapas.

1. O telefone usa o URL HTTPS.

   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. O certificado Web Tomcat apresentado ao telefone a partir do servidor Diretórios não estará disponível no telefone. Assim, o telefone tenta autenticar o certificado através do Serviço de Verificação de Confiança (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. O telefone procura no cache TVS primeiro e, se não for encontrado, entra em contato com o servidor TVS.

   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. Como a conexão com o TVS também é segura, uma autenticação de certificado é concluída e essa mensagem é impressa se for bem-sucedida.

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

5. O telefone agora envia uma solicitação para autenticar o certificado.

   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. A resposta "0" do TVS significa que a autenticação foi bem-sucedida.

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

7. Essa mensagem é exibida e você verá a resposta.

   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>

   O processo de autenticação do certificado é semelhante ao discutido no Serviço de Verificação de Confiança de Contatos do Telefone para Certificado Desconhecido.

   Nas capturas de pacotes (PCAPs) coletadas na extremidade do telefone, você deve ser capaz de verificar a comunicação TVS com o uso desse filtro - "tcp.port==2445".

Nos registros TVS simultâneos:

1. Analise os traços em relação ao aperto de mão TLS (Transport Layer Security).
2. Em seguida, revise o despejo hexadecimal de entrada.

   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. O TVS recupera os detalhes do emitente.

   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. O TVS verifica o certificado.

   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. O TVS envia a resposta ao telefone.

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

A URL do serviço telefônico está definida como "Application:Cisco/CorporateDirectory" e o telefone usa HTTP

Note: Em vez do uso de uma versão anterior do firmware do telefone, o serviço e a URL do serviço seguro foram codificados no URL HTTP. No entanto, a mesma sequência de eventos é vista no firmware do telefone que usa HTTP por padrão.

O arquivo de configuração do telefone tem o URL correto.

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

Nos registros do console do telefone, você poderá verificar essas etapas.

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

Nas capturas de pacote, você verá uma solicitação HTTP GET e uma RESPOSTA bem-sucedida. Este é o PCAP do CUCM:

Troubleshoot

Antes de solucionar o problema, reúna os detalhes relacionados anteriormente:

Registros a serem coletados, se necessário

• O pacote simultâneo é capturado do telefone IP e do servidor CUCM (o servidor que é o primeiro no seu grupo CM para o qual a solicitação HTTP(S) seria enviada).
• Registros do console do telefone IP.
• Logs do Cisco TVS (detalhados).

  Quando você define os registros TVS como detalhados, o serviço precisa ser reiniciado para que as alterações de nível de rastreamento ocorram. Consulte o bug da Cisco ID CSCuq22327 para obter informações sobre o aprimoramento para notificar que uma reinicialização do serviço é necessária quando os níveis de log são alterados.

Conclua estes passos para isolar o problema:

Passo 1

Crie um serviço de teste com estes detalhes:

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

Agora, assine este serviço em um dos telefones afetados:

1. Vá para a página de configuração do dispositivo.
2. Selecione Subscribe/Unsubscribe Services em Links Relacionados.
3. Assine o serviço de teste que você criou.
4. Salvar, aplicar a configuração e reiniciar o telefone.
   1. O que você fez foi, independentemente da versão do FW do telefone que determina se deve usar o URL HTTP ou HTTPS, forçá-lo a usar o URL HTTP.
   2. Acesse o serviço "Diretório corporativo" no telefone.
   3. Se não funcionar, colete os registros mencionados acima e compare-os com o cenário de trabalho mencionado no "Cenário de trabalho" e identifique onde o desvio está.
   4. Se funcionar, você terá pelo menos confirmado que, do ponto de vista do serviço do Telefone IP CUCM, não há problemas.
   5. Neste estágio, o problema provavelmente está nos telefones que usam o URL HTTPS.
   6. Agora, escolha um telefone que não funcione e vá para a próxima etapa.

Quando ela funcionar com essa alteração, você precisará decidir se está OK deixar a configuração com a solicitação/resposta do diretório corporativo que funciona sobre HTTP em vez de HTTPS. A comunicação HTTPS não funciona devido a um dos motivos discutidos a seguir.

Passo 2

Colete os registros mencionados anteriormente e compare-os com o cenário de trabalho mencionado no "Cenário de trabalho" e identifique onde o desvio está.

Pode ser uma destas questões:

1. O telefone não consegue entrar em contato com o servidor TVS.
   1. Nos PCAPS, verifique a comunicação na porta 2445.
   2. Certifique-se de que nenhum dos dispositivos de rede no caminho bloqueie essa porta.
2. O telefone entra em contato com o servidor TVS, mas o handshake TLS falha.

   Essas linhas serão impressas nos registros do console do telefone:

   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>

   Consulte o bug da Cisco ID CSCua65618 para obter mais informações.
   
   

3. O telefone entra em contato com os servidores TVS e o handshake TLS é bem-sucedido, mas o TVS não consegue verificar o assinante do certificado que o telefone solicitou para autenticar.

   Os trechos dos registros TVS estão listados aqui:

   O telefone entra em contato com o 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

   O TVS obtém o nome do emissor.

   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

   Ele procura o certificado, mas não o encontra.

   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. O tráfego HTTPS é bloqueado/descartado em algum lugar da rede.

   Obtenha PCAPs simultâneos do telefone e do servidor CUCM para verificar a comunicação.

Outros cenários em que ocorre o problema "Host não encontrado"

1. O servidor CUCM é definido pelo nome do host, juntamente com problemas na resolução de nomes.
2. A lista de servidores TVS está vazia no telefone quando ele faz o download do arquivo xmldefault.cnf.xml. (Na versão 8.6.2, o arquivo de configuração padrão não terá a entrada TVS devido à ID de bug da Cisco CSCti64589.)
3. O telefone não pode usar a entrada TVS no arquivo de configuração porque fez o download do arquivo xmldefault.cnf.xml. Consulte o bug da Cisco ID CSCuq3297 - Phone para analisar as informações de TVS do arquivo de configuração padrão.
4. O diretório corporativo não funciona após uma atualização do CUCM porque o firmware do telefone é atualizado para uma versão posterior, o que eventualmente altera o comportamento do uso do HTTPS por padrão.