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.
- 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
- 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
- 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
- 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
- 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
- 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
- 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><<</Name><Position>2</Position><URL>SoftKey:<<</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:
- Analise os traços em relação ao aperto de mão TLS (Transport Layer Security).
- 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
- 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
- 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
- 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><<</Name><Position>2</Position><URL>SoftKey:<<</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:
- Vá para a página de configuração do dispositivo.
- Selecione Subscribe/Unsubscribe Services em Links Relacionados.
- Assine o serviço de teste que você criou.
- Salvar, aplicar a configuração e reiniciar o telefone.
- 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.
- Acesse o serviço "Diretório corporativo" no telefone.
- 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á.
- Se funcionar, você terá pelo menos confirmado que, do ponto de vista do serviço do Telefone IP CUCM, não há problemas.
- Neste estágio, o problema provavelmente está nos telefones que usam o URL HTTPS.
- 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:
- O telefone não consegue entrar em contato com o servidor TVS.
- Nos PCAPS, verifique a comunicação na porta 2445.
- Certifique-se de que nenhum dos dispositivos de rede no caminho bloqueie essa porta.
- 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.
- 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
- 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"
- O servidor CUCM é definido pelo nome do host, juntamente com problemas na resolução de nomes.
- 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.)
- 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.
- 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.