Якщо дзвінки з Webex на ваше підприємство не дзвонять на стороні підприємства, пройдіть пункти цього контрольного списку, щоб перевірити свою конфігурацію.

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

Перевірте ці пункти усунення несправностей, пов'язані із взаємним з'єднанням TLS та сертифікатами:

• Встановіть комплект хмарних кореневих сертифікатів Webex на Expressway-E.

• Налаштуйте виділений взаємний порт TLS на Expressway-E.

• Налаштуйте зону DNS для хмари на Expressway-E.

• Відкрийте номер взаємного порту TLS у вашому брандмауері — 5062, який може не бути відкритим за замовчуванням.

• Визначте, який параметр кореневого сертифіката ви використовуєте в хмарі Webex. Параметр використовується для перевірки сертифіката SIP TLS вашого Expressway-E.

  • Магазин за замовчуванням — ваш сертифікат Expressway-E підписаний одним із державних органів? Якщо ви не впевнені, скористайтеся параметром спеціального магазину.

  • Призначений для користувача магазин — чи встановлено ваш сертифікат Expressway-E або його підписувач у хмарі? Чи містить сертифікат перевірені імена хостів Expressway-E?

У поданні клієнта на сторінці https://admin.webex.com перейдіть до розділу Служби > Гі бри дний > Гі бридний дзвінок > Н алаштування. Перевірте ці пункти, пов'язані з вашим призначенням SIP, який ви встановили під час процесу розгортання:

• Значення балів у вашому спеціальному взаємному порту TLS Expressway-E.

• Спробуйте підключитися до IP-адреси: порт. (Кілька адрес, якщо ви налаштували SRV.)

• Якщо ви налаштували IP-адресу або ім'я хоста, вкажіть взаємний порт TLS.

• Якщо ви використовували SRV, переконайтеся, що він у форматі _sips. _tcp. < домен, який ви ввели як пункт призначення SI P>.

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

• Якщо виклики з Expressway-E до хмари не вдаються, і ви використовуєте метод ручного керування сертифікатами, переконайтеся, що ви виконуєте дії в розділі Оновлення сертифіката кореневого сертифіката Webex і завантажте сертифіка т IdenTrust на свої пристрої Expressway якомога швидше.

• Для дзвінків, які спрямовуються від Webex до підприємства, перевірте історію пошуку та журнали мережі на Expressway-E. Цей крок допоможе вам виділити проблему в хмарі або на підприємстві.

• Якщо ви повторно використовуєте існуючу зону B2B та правила пошуку, спробуйте створити виділені зони та правила пошуку. Це налаштування дозволяє уникнути втручання в існуючі налаштування зони для B2B/MRA, дозволяє уникнути циклів маршрутизації та полегшує усунення несправностей.

• Перевірте історію пошуку і мережеві журнали на Expressway-E. Переконайтеся, що SIP INVITE з хмари надходить до Expressway-E і відповідає зоні DNS, яку ви налаштували для хмари.

  • Якщо SIP INVITE не надходить або не відповідає налаштованій зоні DNS, дотримуйтесь маршруту виклику до диспетчера уніфікованих комунікацій. Цей крок допоможе вам знайти, де дзвінок не вдається або втрачено.

  • Див. контрольний список взаємного усунення несправностей 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 підтримують наступні кодеки:

  • Аудіо — Г.711, Г.722, ААС-ЛД

  • Відео—H.264

  Ми підтримуємо G.729 для приєднання до наради Webex, наради особистої кімнати або зустрічі Webex App з SIP-пристрою. Ми не підтримуємо G.729 для набору номера 1:1 з програми Webex на SIP-пристрій або міст.

• У домашньому кластер і Unified Communications Manager для користувачів, яких це стосується, виберіть «Система» > «Параметри підприємства»; у розділі «Кон фігурація домену в усьому кластер і» перевірте параметр повністю кваліфікованого доменного імені кластера (FQDN). Значення FQDN, яке ви використовували, має відповідати наступним вказівкам:

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