Ако обажданията от 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 адрес:порт. (Няколко адреса, ако сте конфигурирали SRV.)

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

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

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

• Ако повикванията от Expressway-E към облака са неуспешни и използвате метода за ръчно управление на сертификати, се уверете, че следвате стъпките в Webex Root CA Certificate Update и качете сертификата 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:

  • Маршрут: ,

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