Голосовая связь и система унифицированных коммуникаций : Cisco Unified Communications Manager (CallManager)

Корпоративный каталог "хост не найденные" проблемы

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ описывает, как устранить неполадки "Хоста Не Найденные" проблемы в Корпоративном каталоге. Важная информация, относящаяся к этому документу:

  • Корпоративный каталог является предоставленной Cisco телефонной службой IP по-умолчанию, которая устанавливает автоматически с Cisco Unified Communications Manager (CUCM).
  • Таблица "TelecasterService" хранит параметры для всех телефонных служб, которые настроены в системе.
  • По телефону при выборе опции "Corporate Directory" телефон передает или HTTP или Запрос HTTPS к одному из серверов CUCM и возвращен объект XML как HTTP (S) ответ.

Внесенный Гагариным Сатиянараянаном, специалистом службы технической поддержки Cisco.

Важная информация

  • Разъяснитесь, происходит ли проблема при доступе к "Каталогам" или "Корпоративному каталогу".
  • Во что установлено поле "Service URL" под сервисом Корпоративного каталога?
    • Если URL установлен в "Application:Cisco/CorporateDirectory" тогда, на основе версии микропрограммы телефона, телефон делает или HTTP или Запрос HTTPS.
    • Телефоны, которые используют версию микропрограммы 9.3.3 и позже по умолчанию делают Запрос HTTPS.
  • Когда сервисный URL установлен в "Application:Cisco/CorporateDirectory", телефон передает HTTP (S), запрашивают к серверу, который является первым в, он - CallManager (CM) группа.
  • Определите топологию сети между телефоном и сервером, которому передается HTTP (S) запрос.
  • Обратите внимание на межсетевые экраны, оптимизаторы глобальной сети (WAN), и так далее в пути, который может понижаться/препятствовать HTTP (S) трафик.

Рабочий сценарий

В этом сценарии URL телефонной службы установлен в "Application:Cisco/CorporateDirectory" и телефонный HTTPS использования.

Данный пример показывает файл конфигурации телефона с корректным URL.

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

От телефонных console log вы будете в состоянии проверить эти шаги.

  1. Телефон использует 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&colon;:getCdUrl:
    [thread=appmgr MQThread]
    [class=cip.app.ar] Using HTTPS URL
  2. Веб-сертификат Tomcat, представленный телефону от сервера Каталогов, не будет доступен по телефону. Следовательно телефон пытается аутентифицировать сертификат через службу проверки доверия (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. Телефон выглядит в theTVS кэше сначала и если не найденный это связывается с сервером 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. Так как соединение с theTVS также безопасно, проверка подлинности сертификата завершена, и это сообщение распечатано, если это успешно.
    8096 NOT 11:04:15.173585  SECD: -Successfully obtained a TLS connection
    to the TVS server
  5. Телефон теперь отправляет запрос для аутентификации сертификата.
    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. Ответ "0" от TVS означает, что аутентификация была успешна.
    8172 NOT 11:04:15.220060  SECD: -Authentication Response received, status : 0
  7. Это сообщение отображено, и затем вы будете видеть ответ.
    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>

    Процесс проверки подлинности сертификата подобен тому, что обсуждено в Телефонном Сервисе Проверки Доверия Контактов для Неизвестного Сертификата.

    От захватов пакета (PCAPs) собрал в телефонном конце, должна существовать возможность для проверки связи TVS с использованием этого фильтра - "tcp.port == 2445".

В одновременных журналах TVS:

  1. Анализ отслеживает в отношении рукопожатия Transport Layer Security (TLS).
  2. Затем, рассмотрите входящий шестнадцатеричный дамп.
    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. TVS получает подробные данные отправителя.
    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. TVS проверяет сертификат.
    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. TVS передает ответ на телефон.
    04:04:15.272 |   debug 2:UNKNOWN:Sending CERT_VERIF_RES msg
    04:04:15.272 | debug MsgType : TVS_MSG_CERT_VERIFICATION_RES

URL Телефонной службы Установлен в "Application:Cisco/CorporateDirectory" и Телефонный HTTP Использования

Примечание: Вместо использования более ранней телефонной версии микропрограммы сервис и безопасный сервисный URL были жестко закодированы к HTTP URL. Однако та же последовательность событий замечена в телефонном микропрограммном обеспечении, которое использует HTTP по умолчанию.

Файл конфигурации телефона имеет корректный URL.

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

От телефонных console log вы будете в состоянии проверить эти шаги.

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

От захватов пакета вы будете видеть HTTP-запрос GET и успешный ОТВЕТ. Это - PCAP от CUCM:

Устранение неполадок

Прежде чем вы устраните неполадки, заключите, что подробные данные проблемы перечислили ранее:

Журналы для Сбора, при необходимости

  • Одновременные захваты пакета от IP-телефона и от сервера CUCM (сервер, который является первым в, он - группа CM, куда HTTP (S) запрос был бы передан).
  • Console log IP-телефона.
  • Журналы TVS Cisco (детализированы).

    То, когда вы устанавливаете журналы TVS в подробный, сервис должен быть перезапущен для уровня трассировки, изменяется для имения место. Посмотрите идентификатор ошибки Cisco CSCuq22327 для усовершенствования, чтобы уведомить, что сервисный перезапуск требуется, когда изменены регистрационные уровни.

Выполните эти шаги для изоляции проблемы:

Шаг 1

Создайте тестовый сервис с этими подробными данными:

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

Теперь, подпишите этот сервис на один из телефонов, на которые влияют:

  1. Перейдите к странице конфигурации устройства.
  2. Выберите Subscribe/Unsubscribe Services под Ссылками по теме.
  3. Подпишите тестовый сервис, который вы создали.
  4. Сохраните, примените конфигурацию и перезагрузите телефон.
    1. То, что вы сделали, независимо от версии FW телефона, которая определяет, использовать ли HTTP или URL HTTPS, вынудить его использовать HTTP URL.
    2. Обратитесь к сервису "Корпоративного каталога" по телефону.
    3. Если это не работает, то собирает упомянутые выше журналы и сравнивает их с рабочим сценарием, упомянутым согласно "Рабочему Сценарию", и определяет, где отклонение.
    4. Если это работает, то вы, по крайней мере, подтвердили, что с точки зрения Сервиса IP-телефона CUCM нет никаких проблем.
    5. На данном этапе проблема могла по всей вероятности быть с телефонами, которые используют URL HTTPS.
    6. Теперь, выберите телефон, который не работает и продолжается к следующему шагу.

Когда это работает с этим изменением, необходимо решить, нормально ли оставлять конфигурацию с запросом/ответом корпоративного каталога, который перерабатывает HTTP вместо HTTPS. Связь HTTPS не работает из-за одной из причин, обсужденных затем.

Шаг 2

Соберите журналы, упомянутые ранее, и сравните их с рабочим сценарием, упомянутым согласно "Рабочему Сценарию", и определите, где отклонение.

Это могла быть одна из этих проблем:

  1. Телефон неспособен связаться с сервером TVS.
    1. В PCAPS проверьте связь на порту 2445.
    2. Гарантируйте, что ни одно из сетевых устройств в пути не блокирует этот порт.
  2. Телефон связывается с сервером TVS, но сбоями подтверждения связи TLS.

    Эти линии будут распечатаны в телефонных console log:

    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>

    Посмотрите идентификатор ошибки Cisco CSCua65618 для получения дополнительной информации.

  3. Телефон связывается с серверами TVS, и подтверждение связи TLS успешно, но TVS неспособен проверить подписывающее лицо сертификата, который телефон запросил аутентифицировать.

    Фрагменты от журналов TVS перечислены здесь:

    Телефон связывается с 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

    TVS получает имя запрашивающей стороны.

    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

    Это ищет сертификат, но не может найти его.

    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 блокируется/отбрасывается где-нибудь в сети.

    Получите одновременный PCAPs от телефона и сервера CUCM для проверки связи.

Другие сценарии, когда "хост не происходит найденная" проблема

  1. Сервер CUCM определен именем хоста наряду с проблемами в разрешении имен.
  2. Список серверов TVS пуст по телефону, когда это загружает xmldefault.cnf.xml файл. (В Версии 8.6.2 файл конфигурации по умолчанию не будет иметь записи TVS в нем из-за идентификатора ошибки Cisco CSCti64589.)
  3. Телефон неспособен использовать запись TVS в файле конфигурации, потому что это загрузило xmldefault.cnf.xml файл. Посмотрите идентификатор ошибки Cisco CSCuq33297 - Телефон для парсинга информации о TVS от файла конфигурации по умолчанию.
  4. Корпоративный каталог не работает, после обновления CUCM, потому что телефонные обновления микропрограммного обеспечения к более поздней версии, которая в конечном счете изменяет поведение использования HTTPS по умолчанию.


Document ID: 118699