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

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

Ознакомьтесь со следующими пунктами устранения неполадок, связанных с взаимным TLS-соединением и сертификатами:

• Установите пакет корневых сертификатов Webex cloud на Expressway-E.

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

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

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

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

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

  • Custom Store — установлен ли ваш сертификат Expressway-E или устройство для его подписи в облаке? Содержит ли сертификат проверенные имена хостов Expressway-E?

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

• Ценность указывает на выделенный порт Expressway-E Mutual TLS.

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

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

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

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

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

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

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

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

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

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

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

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

    • В данном примере полное доменное имя домашнего кластера — 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 должно соответствовать следующим рекомендациям:

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