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

Решите проблемы интеграции HTTPS между проводником и CUCM

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

Введение

Этот документ описывает проблему, с которой встречаются с интеграцией HTTPS между Проводником Cisco и Cisco Unified Communications Manager (CUCM).

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

Проблема

Интеграция HTTPS между Проводником и CUCM для сбоев разовых конференций. Когда эта проблема происходит, существует два основных признака:

  • Состояние регистрации для Проводникового Моста конференц-связи на CUCM показывает как Незарегистрированное.

  • Попытки создать сбой разовой конференции.

Разделы, которые придерживаются, объясняют эти два признака более подробно.

Состояние регистрации показывает незарегистрированный

Этот признак наблюдается в этих двух сценариях:

  • Назначение магистрали SIP Замены как флажок HTTP Address неконтролируемо на Проводниковой странице конфигурации, и cвязанный транк Протокола SIP для Проводникового Моста конференц-связи имеет адрес назначения (DA), который настроен как IP-адрес или Полное доменное имя (FQDN).

    Совет: Для получения дополнительной информации о сценарии магистрали SIP FQDN, обратитесь к магистрали SIP, Настроенной с разделом FQDN этого документа.

  • Назначение магистрали SIP Замены как флажок HTTP Address проверено на Проводниковой странице конфигурации и настроено как IP-адрес.

Эти образы показывают состояние регистрации для обоих из этих сценариев:

Основная причина для этой ошибки регистрации является библиотекой, которой пользуются для HTTPS / Transport Layer Security (TLS). Подтверждение связи TLS отказывает с Зашифрованным предупреждением, потому что библиотека не поддерживает Идентификаторы Uniform Resource (URIs) в Формате IP-адреса для HTTPS/TLS.

На высоком уровне подтверждение связи TLS происходит подобное этому:

  1. CUCM передает сообщение Сообщения приветствия клиента TLS к Проводнику.

  2. Проводник передает Приветствие сервера сообщение и информация о сертификате к CUCM.

  3. Проводник передает Приветствие сервера Сделанный и Сообщения Exchange Серверного ключа к CUCM.

  4. CUCM передает Клиентский Обмен ключами, Спецификацию Шифра Изменения и Зашифрованные Сообщения квитирования к Проводнику.

  5. Проводник передает Спецификацию Шифра Изменения и Зашифрованные Сообщения квитирования к CUCM.

  6. CUCM передает Зашифрованное предупреждение к Проводнику.

Сбои Создания разовой конференции

Этот признак наблюдается, когда обходной путь применен для вышеупомянутого признака, который заставляет создание разовых конференций отказывать:

Основной причиной для этого признака является Проводник, который не в состоянии обрабатывать conference.create вызов Прикладного программного интерфейса (API) от CUCM, когда URI создан с FQDN.

Проводник тогда регистрирует это событие:

Event="An API request could not be processed." Command="conference.create"
Conference_name="001035060001" Detail="<Fault 201:
'Request received to a non ad-hoc IP address'>

Примечание: Значение Conference_name является другим для каждого вызова.

Решение

Для интеграции HTTPS и создания разовой конференции для функционирования должным образом между CUCM и Проводником исправление требуется для идентификатора ошибки Cisco CSCut22572. Это исправление должно позволить адресу назначения (DA) HTTPS быть настроенным как FQDN.

Примечание: FQDN должен решить к Виртуальному IP (VIP), который привязан к Проводниковому оперативному местоположению и должен быть включен как атрибут альтернативного имени субъекта (SAN) в Проводниковом Сертификате.

Длительный срок усовершенствование функции, которое описано в идентификаторе ошибки Cisco CSCut10254, позволит адресу назначения (DA) HTTPS быть настроенным с IP-адресом, или от конфигурации руководства/замены или от магистрали SIP.

Магистраль SIP, настроенная с FQDN

Состояние сервиса магистрали SIP может иногда появляться как No Service или Выключенный. Это происходит когда:

  • Адрес назначения (DA) в магистрали SIP настроен с FQDN.

  • FQDN решает к VIP, который привязан к оперативному местоположению, которое обозначено на Проводниковой странице конфигурации.

Например:

Основной причиной для этого является Проводник, который не отвечает на сообщение Опций SIP, которое передается от CUCM. URI SIP создан на основе адреса назначения (DA), который является FQDN в данном примере, и Проводник ожидает нотацию IP-адреса:

2015-03-27T18:00:23+01:00 conductorcucm b2bua[28262]: UTCTime="2015-03-27 17:00:23,269"
Module="network.sip" Level="DEBUG": Action="Received" Local-ip="10.48.36.195"
Local-port="5061" Src-ip="10.48.36.128" Src-port="40523"
Msg-Hash="17750686918648045057"

 SIPMSG:
 |OPTIONS sip:condcucmadhoc.vngtp.lab:5061 SIP/2.0
 Via: SIP/2.0/TLS 10.48.36.128:5061;branch=z9hG4bK1539977cd7264
 Call-ID: c0a17300-51518ca7-15313-8024300a@10.48.36.128
 CSeq: 101 OPTIONS
 Contact: <sip:10.48.36.128:5061;transport=tls>
 From: <sip:10.48.36.128>;tag=1335522536
 To: <sip:condcucmadhoc.vngtp.lab>
 Max-Forwards: 0
 User-Agent: Cisco-CUCM10.5
 Date: Fri, 27 Mar 2015 17:00:23 GMT
 Content-Length: 0
2015-03-27T18:00:23+01:00 conductorcucm b2bua[28262]: UTCTime="2015-03-27 17:00:23,322"
Module="developer.applicationmanager.search" Level="INFO"
CodeLocation="ppcmains/ivy/search/SearchFsmState_Idle.cpp(82)"
Method="SearchFsmState_Idle::handleRequest" Thread="0x7feea9888700":
AppId="59" LegId="ASide[1]" CurState="SearchFsmState_Idle"
 Detail="Received search" searchContext="mTarget : sip:condcucmadhoc.vngtp.lab
 mRouteSet:
 "
2015-03-27T18:00:23+01:00 conductorcucm b2bua[28262]: UTCTime="2015-03-27 17:00:23,325"
Module="developer.applicationmanager.search" Level="INFO"
CodeLocation="ppcmains/ivy/search/SearchFsmState_Idle.cpp(96)"
Method="SearchFsmState_Idle::performSearch" Thread="0x7feea9888700":
AppId="59" LegId="BSide[1]" CurState="SearchFsmState_Idle"
 Detail="Initiating search" searchContext="mTarget : sip:condcucmadhoc.vngtp.lab
 mRouteSet:
 "
2015-03-27T18:00:23+01:00 conductorcucm b2bua[28262]: UTCTime="2015-03-27 17:00:23,344"
Module="developer.modulefactory.threadeddispatcher" Level="ERROR"
CodeLocation="ppcmains/ivy/threadeddispatcher/ThreadedDispatcher.cpp(106)"
Method="ThreadedDispatcher::run" Thread="0x7feea9888700": Detail="Caught
std::exception" what="DefaultRouteHeaderStrategy::manipulateOutgoingRouteSet:
Policy routing configured, but no outgoing route found."

Это происходит даже при том, что проводник может решить оперативный FQDN:

Примечание: Пока иначе не задокументировано, эта проблема также отслежена в идентификаторе ошибки Cisco CSCut22572.



Document ID: 118964