Ако обажданията от Webex към вашето предприятие не звънят от страна на предприятието, преминете през точките в този контролен списък, за да проверите двукратно конфигурацията си.

Преди да преминете през тези предложения за отстраняване на неизправности, вижте https://status.webex.com за най-новата информация за всякакви прекъсвания в облака. От тази страница на състоянието можете също да се абонирате за известия.

Проверете тези точки за отстраняване на неизправности, свързани с взаимната TLS връзка и сертификати:

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

• Конфигуриране на специализиран взаимен TLS порт на Експресуей-Е.

• Конфигуриране на DNS зона за облака на Expressway-E.

• Отворете номера на взаимния TLS порт във вашата защитна стена—5062, който може да не е отворен по подразбиране.

• Определете коя опция за главен сертификат използвате в облака на Webex–Опцията се използва за проверка на вашия Сертификат за SIP TLS на Expressway-E.

  • Хранилище по подразбиране—Подписано ли е вашият сертификат Expressway-E от някой от публичните органи? Ако не сте сигурни, използвайте опцията за персонализирано хранилище.

  • Персонализиран магазин—Инсталиран ли е вашият сертификат Expressway-E или неговият подписвач в облака? Сертификатът съдържа ли проверени хостове на Expressway-E?

От изгледа на клиента в , отидете на https://admin.webex.com Услуги > Хибридни > Хибридни настройки на > за обаждания . Проверете тези точки, които са свързани с вашата SIP дестинация, която сте задали по време на процеса на разполагане:

• Стойността сочи към вашия Expressway-E посветен взаимен TLS порт.

• Опитайте се да се свържете с IP адрес address:port. (Няколко адреса, ако сте конфигурирали SRV.)

• Ако сте конфигурирали IP адрес или хост име, задайте взаимния TLS порт.

• Ако сте използвали SRV, гарантирайте, че е във формата _sips._tcp.домейн, който поставяте като SIP местоназначение>.

• Ако не искате да настроите SRV, можете да въведете IP адрес:порт или hostname:port като SIP дестинация на вашата организация.

• Ако повикванията от Expressway-E към облака са неуспешни и използвате метода за ръчно управление на сертификати, уверете се, че следвате стъпките в Актуализация на сертификата на Webex Root CA и качете сертификата IdenTrust на вашите Expressway устройства възможно най-скоро.

• За обаждания, които маршрут от Webex към предприятието, проверете хронологията на търсенето и мрежовите регистрационни файлове на Expressway-E. Тази стъпка ви помага да изолирате проблема или на облака, или на предприятието.

• Ако използвате повторно съществуваща B2B зона и правила за търсене, помислете за създаване на посветени зони и правила за търсене вместо това. Тази настройка избягва смущения в съществуващите настройки на зоните за B2B/MRA, избягва линиите за маршрутизиране и улеснява отстраняването на неизправности.

• Проверете хронологията на търсенето и мрежовите регистрационни файлове на Expressway-E. Проверете дали SIP INVITE от облака пристига в Expressway-E и съвпада с DNS зоната, която сте конфигурирали за облака.

  • Ако SIP INVITE не пристигне или не съответства на конфигурираната DNS зона, следвайте маршрута на повикването към Unified Communications Manager. Тази стъпка ви помага да намерите къде повикването е неуспешно или загубено.

  • Вижте взаимния контролен списък за отстраняване на неизправности с 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.

• URIs на директорията трябва да съвпадат с всички домейни, които сте потвърдили във вашата организация.

• Проверете конфигурацията на кодека си.

  Услугите на 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 или пример*.com.
  Първи FQDN запис за хибридно извикване	В списък с няколко записа webex облакът използва първия запис отляво за Хибридно извикване, и че първият запис не трябва да съдържа заместващ символ. Вижте този пример за три FQDN записи от ляво на дясно (първото е за Хибридно извикване): cluster1.example.com *.example.com example*.com
  Различни от Експресуей-Е	Трябва да е различен от expressway-E системата, DNS и името на домейна. В противен случай Expressway-E лентира заглавката на маршрута.
  Нов запис за хибридно извикване	Ако текущият ви FQDN запис в Унифициран CM не отговаря на изискванията, изброени по-горе, можете да добавите нов елемент в началото на настройката на клъстера FQDN за Хибридно извикване. Например, ако съществуващата ви настройка за FQDN в Cisco Unified Communications Manager е *.example.com *.example.org, добавете уникален запис без заместващи символи в началото на полето: "cluster1.example.com *.example.com *.example.org"