Если вызовы из Webex не поступают в вашу организации, выполните пункты перечня действий для повторной проверки конфигурации.

Прежде чем приступить к рассмотрению этих рекомендаций по устранению неполадок, просмотрите актуальную информацию о простоях облака здесь: https://status.webex.com. На этой странице состояния можно также подписаться на рассылку уведомлений.

Выполните приведенные далее действия по устранению неполадок, связанных с соединением Mutual TLS и сертификатами.

• Установите пакет корневого сертификата облака Webex на Expressway-E.

• Настройте выделенный порт Mutual TLS в Expressway-E.

• Настройте зону DNS для облака в Expressway-E.

• Откройте номер порта Mutual TLS в брандмауэре – 5062. Он может не быть открыт по умолчанию.

• Определите, какой параметр корневого сертификата используется в облаке Webex. Этот параметр используется для проверки сертификата TLS SIP Expressway-E.

  • Хранилище по умолчанию: подписан ли ваш сертификат Expressway-E одним из общедоступных центров? Если вы затрудняетесь ответить, воспользуйтесь параметром пользовательского хранилища.

  • Пользовательское хранилище: установлен ли ваш сертификат Expressway-E или подписывающая его сторона в облаке? Содержит ли сертификат проверенные имена узлов Expressway-E?

В окне просмотра информации о клиенте на веб-сайте https://admin.webex.com перейдите в раздел Службы > Вызовы > Вызовы гибридного типа > Настройки. Выполните приведенные далее действия, связанные с назначением SIP, заданным в процессе развертывания.

• Значение указывает на выделенный порт Mutual TLS Expressway-E.

• Попробуйте подключиться к IP-адресу address:port. (Несколько адресов, если вы настроили SRV.)

• Если IP-адрес или имя узла настроены, укажите порт Mutual TLS.

• Если вы использовали SRV, убедитесь, что он имеет формат _sips._tcp. <домен, который вы указали в качестве SIP-назначения>.

• Если в настройке SRV нет необходимости, в качестве назначения SIP организации можно ввести IP-адрес: порт или имя узла: порт.

• Если вызовы из Expressway-E в облако не удается, и вы используете метод ручного управления сертификатами, обязательно выполните действия, описанные в Обновление корневого сертификата центра сертификации Webex и как можно скорее загрузите сертификат IdenTrust на ваши устройства Expressway.

• Для вызовов, маршрутизируемых из Webex в организацию, проверьте журнал поиска и сетевые журналы в Expressway-E. На этом этапе можно изолировать проблему в рамках облака или организации.

• При повторном использовании существующих зон B2B и правил поиска вместо этого следует создать выделенные зоны и правила поиска. С помощью этой настройки можно избежать помех с существующими настройками зоны для B2B и MRA, а также появления циклов маршрутизации. Кроме того, она упрощает устранение неполадок.

• Проверьте журнал поиска и журналы сети в Expressway-E. Убедитесь в том, что запрос INVITE SIP из облака поступает в Expressway-E и соответствует зоне DNS, настроенной для облака.

  • Если SIP INVITE не приходит или не соответствует настроенной DNS-зоне, то следуйте по маршруту вызова к менеджеру унифицированных коммуникаций. На этом этапе можно определить, где возникает ошибка вызова или потеря соединения.

  • См. перечень действий по устранению неполадок Mutual TLS.

• Проверьте заголовок маршрута. Убедитесь, что оно содержит полное доменное имя кластера (FQDN), настроенное в параметрах предприятия Unified Communications Manager и в правилах поиска Expressway. Ниже приведен пример заголовка маршрута и выделенного кластера FQDN.

  • Маршрут: <sip:[Obfuscated];transport=tls;lr>,<sip:myucmcluster.example.com;lr>

    • В этом примере FQDN домашнего кластера – myucmcluster.example.com.

• Электронные письма в Unified Communications Manager должны точно соответствовать электронным письмам (синхронизированным из Active Directory или любого другого источника) в облаке Webex.

• URI каталога должны совпадать со всеми проверенными доменами в вашей организации.

• Проверьте конфигурацию вашего кодека.

  Службы Webex поддерживаются перечисленным ниже кодеками.

  • Аудио – G.711, G.722, AAC-LD

  • Видео – H.264

  Мы поддерживаем стандарт G.729 для присоединения к совещаниям Webex, совещаниям в персональной комнате или совещаниям в приложении Webex с устройства SIP. Мы не поддерживаем G.729 для набора номера. 1:1 от приложения Webex к SIP-устройству или мосту.

• На главном сервере кластера Unified Communications Manager затронутых пользователей выберите Система > Параметры предприятия; В разделе Конфигурация домена в масштабе кластерапроверьте настройку полного доменного имени кластера (FQDN). Используемое FQDN необходимо задать согласно приведенным ниже рекомендациям.

  Рекомендации относительно FQDN	Описание и пример
  Несколько кластеров	Для каждого кластера с гибридным вызовом запись должна быть уникальной — например, cluster1.example.com, cluster2.example.com, и так далее.
  Отсутствие знаков подстановки	Не используйте записи со знаками подстановки, например *.example.com или example*.com.
  Первая запись FQDN для службы вызовов гибридного типа	В списке с несколькими записями облако Webex использует первую запись слева для вызовов гибридного типа, при этом эта запись не должна содержать знаков подстановки. См. приведенный пример трех записей FQDN слева направо (первая из них для вызовов гибридного типа): cluster1.example.com *.example.com example*.com
  Отличие от Expressway-E	Должно отличаться от значения, заданного для системы Expressway-E, DNS и доменного имени. В противном случае Expressway-E будет использовать заголовок маршрута.
  Новая запись для вызовов гибридного типа	Если текущая запись FQDN в Unified CM не соответствует перечисленным выше требованиям, можно добавить новый элемент в начале настройки FQDN кластера для вызовов гибридного типа. Например, если в настройках Cisco Unified Communications Manager указано полное доменное имя (FQDN) в формате . *.example.com *.example.org, добавьте уникальную запись без подстановочных символов в начало поля: "cluster1.example.com *.example.com *.example.org"