Ако обажданията от 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. _ткп. < домейн, който сте въвели като SIP дестинация >.

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

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

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

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

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

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

  • Вижте взаимния контролен списък за отстраняване на неизправности на TLS.

• Проверете заглавката на маршрута. Проверете дали тя съдържа стойността на клъстера с напълно квалифицирано име на домейн (FQDN), която е конфигурирана в настройките на предприятието на Unified Communications Manager и в правилата за търсене на бързи пътища. Вижте този пример за заглавка на маршрута и маркирания клъстер 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, среща в Personal Room или среща на Webex App от SIP устройство. Ние не поддържаме G.729 за набиране на 1:1 от Webex App към 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“