Благодарим за обратната връзка.

Тази статия е предназначена за екип за техническа поддръжка в организацията доставчик на услуги, който поддържа себе си и своите клиенти. Те трябва да са запознати с общите отстранявания на неизправности, четенето на дневници и работата с абонатни случаи.

Тази статия е разделена на три основни раздела:

• Ресурси — предоставя списък с инструменти, материали за четене, дневници и контакти, от които може да се нуждаете.
• Процеси — описва някои от действията, които можете да предприемете, докато отстранявате проблем с клиента.
• Конкретни проблеми — категоризира и изброява проблемите, за които е известно, че са възникнали, как да ги откриете и как потенциално можете да ги разрешите.

Полезни регистрационни файлове

Списък за четене

• Webex за партньорския портал за знания на Cisco BroadWorks
• Ръководство за конфигуриране на платформата XSP (R23)
• Ръководство за управление на софтуера BroadWorks (R23)
• Ръководство за конфигуриране на управление на устройства на Cisco BroadWorks (R23)
• Ръководство за администриране на интерфейса на командния ред Broadworks Xsp
• Описание на функцията за токен за удостоверяване с дълготрайна версия 23.
• Ръководство за интегриране на удостоверяване на SAML, R23
• Ръководство за опции за поддръжка на Cisco BroadWorks SSL
• Описание на функцията за поддръжка на Cisco CI
• Push сървър за известия (описание на функцията)
• Поддръжка на Push Notification за повиквания Описание на функцията Версия 22.0
• Свързване (Android) Миграция към метод на процедура на Firebase
• Cisco BroadWorks Съхранение на токени на устройства за Push известия Описание на функцията Издаване 22.0
• Планиране на капацитета на системата Cisco Broadworks (електронна таблица)
• Ръководство за оразмеряване на платформата Cisco BroadWorks
• Ръководство за системно инженерство на Cisco Broadworks
• Изисквания за поддръжка на удостоверяване на CI Документ Версия 1.0 MR-7136

Известни проблеми и ограничения

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

Конектор за обслужване

Услугата Webex Serviceability увеличава скоростта, с която персоналът за техническа помощ на Cisco може да диагностицира проблеми с инфраструктурата. Той автоматизира задачите за намиране, извличане и съхранение на диагностични дневници и информация в SR случай. Услугата също така задейства анализ срещу диагностични подписи, така че TAC да може по-ефективно да идентифицира и разрешава проблеми с вашето локално оборудване.

За подробности как да разгърнете конектора за обслужване вижте Ръковод ство за внедряване на конектор за Cisco Webex обслужване.

Ескалация на проблем

След като следвате някои от указанията за отстраняване на неизправности, трябва да имате разумна представа къде се корени проблемът.

Процедура

1. Съберете възможно най-много информация от системите, свързани с проблема.
2. Свържете се със съответния екип в Cisco, за да отворите дело.

Каква информация за клиента да събира

Ако смятате, че трябва да отворите случай или да ескалирате проблем, съберете следната информация, докато отстранявате неизправности с потребителя:

• Идентификатор на потребителя: CI имейл адрес или User UUID (това е идентификаторът на Webex, но ако получите и идентификатора на BroadWorks на потребителя, включете го в подробностите за случая).
• Идентификатор на организацията.
• Приблизителна времева рамка, през която е възникнал проблемът.
• Клиентска платформа и версия.
• Изпращайте или събирайте дневници от клиента.
• Запишете идентификатора за проследяване, ако е показан на клиента.

Проверете данните за потребителя в Help Desk

Администраторите на партньори, които имат привилегии за роли в Help Desk Administrator (Basic или Advanced), могат да използват тази процедура, за да проверят данните за потребителя чрез изгледа на Help Desk.

Процедура

1. Влезте в бюрото за помощ.
2. Потърсете и след това щракнете върху потребителя. Това отваря екрана за обобщение на потребителя.
3. Щракнете върху потребителското име, за да видите подробната конфигурация на потребителя. Полезната информация в този изглед включва UUID на потребителя, клъстера за обща идентичност (CI), клъстер на Webex App, Поведение на повикване, GUID на акаунта в BroadWorks
4. Щракнете върху Ко пиране, ако трябва да използвате тази информация в друг инструмент или да я прикачите към калъф на Cisco.

Преглед на организацията на клиентите в Help Desk

Администраторите на партньори, които имат привилегии за роли за администратор на Help Desk (основни или разширени), могат да използват тази процедура, за да преглеждат подробностите за организацията на клиентите в изгледа на Help Desk.

Процедура

1. Влезте в бюрото за помощ.
2. Потърсете и след това щракнете върху името на организацията на клиента.
3. Превъртете надолу, докато видите Из глед на клиентския портал и щракнете върху Пре глед на името на клиента, за да видите изглед само за четене на организацията на клиента — включително потребители и конфигурация.

Извличане на потребителски дневници от партньорския център

При отстраняване на проблеми с настолния и мобилния клиент е важно партньорите (и TAC) да могат да преглеждат клиентските дневници.

Процедура

1. Помолете потребителя да изпрати дневници. За помощ вижте: Приложение Webex | Докладване за проблем.
2. Помолете потребителя да експортира средата за повикване и да ви изпрати файла ced.dat.
3. Вземете клиентските дневници от Partner Hub или Help Desk.

   Опция за партньорски център:

   1. Влезте в Partner Hub и намерете организацията на клиентите на потребителя.
   2. Изберете Отстран яване на проблеми.
   3. Изберете Д невници.
   4. Търсене на потребителя (по имейл).
   5. Преглеждайте и изтеглете клиентските дневници като zip файл.

   Опция Help Desk:

   1. Влезте в бюрото за помощ.
   2. Търсете организацията.
   3. Щракнете върху организацията (отваря екрана за обобщение).
   4. Превъртете надолу, за да кликнете върху Преглед на клиента.
   5. Изберете Отстран яване на проблеми.
   6. Изберете Д невници.
   7. Търсене на потребителя (по имейл).
   8. Преглеждайте и изтеглете клиентските дневници като zip файл.

Как да намерите клиентска версия

Процедура

1. Споделете тази връзка с потребителя: https://help.webex.com/njpf8r5
2. Помолете потребителя да ви изпрати номера на версията.

Клиентска проверка за услуга за обаждане

Процедура

1. Влезте в клиента на Webex.
2. Проверете дали иконата Опции за повикване (телефон със зъбно колело над нея) присъства в страничната лента. Ако иконата не присъства, потребителят може все още да не е активиран за услугата за повикване в Control Hub.
3. Отворете менюто Настройки/Предпочитания и отидете в секцията Телефонни услуги. Трябва да видите състоянието SSO сесия Вие сте влезли в системата. (Ако се покаже друга телефонна услуга, като напримерWebex Calling, потребителят не използва Webex за Cisco BroadWorks.)

   Тази проверка означава:

   • Клиентът успешно е преминал необходимите микроуслуги на Webex.
   • Потребителят успешно е удостоверявал.
   • На клиента се издава дълготраен JSON уеб токен от вашата система BroadWorks.
   • Клиентът е изворил профила си на устройството и се е регистрирал в BroadWorks.

Получавайте клиентски дневници или обратна връзка

• Вижте раздела Ресурси, за да намерите конкретни клиентски дневници за настолни клиенти на Webex или помолете потребителите да изпращат дневници. За помощ вижте: Приложение Webex | Докладване за проблем.
• Помолете потребителите на мобилни клиенти да изпращат дневници, след което можете да ги получите чрез Partner Hub или Help Desk.
  Изпращането на дневници е безшумно. Ако обаче потребител изпрати обратна връзка, той отива до екипа на Webex App devops. Не забравяйте да запишете номера на обратната връзка на потребителя, ако искате да проследите с Cisco. Например:

  

Получаване на данни за средата за повикване

Клиентските дневници на Webex са силно редактирани, за да премахнат личната информация. Трябва да експортирате данните на средата за повикване от клиента в същата сесия, когато забеле жите проблема.

Процедура

1. На клиента щракнете върху Помощ > Пр оверка на здравето.
2. Изберете Нули ране на базата данни. Това задейства пълно нулиране на клиента и зарежда екрана за вход в Webex App.

Проверете дали Webex трябва да се регистрира в BroadWorks

Webex App проверява следната информация, за да определи дали да се регистрира в BroadWorks:

• Право на потребителя на широкообхватен конектор.
• Поведение на повикване за организация и потребител.

Проверете поведението на повикването на потребителя и правото на свързване

1. Влезте в Help Desk с идентифика ционните данни на администратора на партньора си.
2. Търсете потребителя.
3. Кликнете върху потребителя и проверете записа Поведение на повикването. Трябва да е „Обаждане в Webex“.

   

4. Щракнете върху потребителското име, за да отворите екрана Данни за потребителя.
5. Превъртете надолу, за да намерите секцията за права и проверете дали е включен широкообхватен конектор

   

   Потребителят на Webex за Cisco BroadWorks не трябва да има право на bc-sp-стандарт, ако възнамерява да използва Webex за Cisco BroadWorks. Това е правото за „Webex Calling(Broadcloud)“, което е обаждане на Webex App чрез услуга за обаждания в облак, управлявана от Cisco.

Проверете поведението на повикването на организацията

1. Влезте в Help Desk с идентифика ционните данни на администратора на партньора си.
2. Търсете организацията.
3. Кликнете върху организацията и проверете записа Повед ение на пови кването. Трябва да е „Обаждане в Webex“.

Анализирайте PSlog за проблеми с предоставянето на потребители

Използвайте PSlog на сървъра за приложения, за да видите заявката HTTP POST към моста за осигуряване и отговора от Webex. В правилен работен случай отговорът е 200 OK и след няколко минути можете да видите потребителя - и новата клиентска организация, ако е първи потребител - е създа дена в Webex. Можете да потвърдите това, като потърсите Help Desk за имейл адреса, който виждате в POST.

Преди да започнете

Съберете PSlog от сървъра за приложения по време на опит за предоставяне на поток с тестов потребител.

Процедура

1. Първо проверете HTTP кода за отговор:
   • Всичко, различно от 200 OK, е неуспех в предоставянето на потребителя.
   • 200 OK все още може да показва неуспех, ако нещо относно профила на абоната не работи в услугите на Webex нагоре по веригата на осигурителния мост.
   • 400 може да съдържа възел за съобщение в отговора. Мостът за осигуряване не може да обработи нещо в профила на SubscriberProfile. Може да има нещо нередно с подробностите за абоната или несъвместимост с настройка в шаблона.
   • 401 означава, че идентификационните данни за предоставяне, въведени в AS, не съвпадат с въведените в шаблона в Partner Hub.
   • 403 може да показва нещо неправилно конфигурирано на сървъра за приложения. Проверете целта на заявката. това не трябва да е IP адрес, а URL адресът за предоставяне на мост, който можете да видите на вашия шаблон в Partner Hub.
   • 409 показва конфликт между предоставения SubscriberProfile и съществуващите данни на Webex. Възможно е да има съществуващ потребител с този имейл адрес. Проверете съобщ ението в отговора.
2. Можете също така да проверите оригиналния HTTP POST за всякакви подозрителни стойности, които биха могли да доведат до неуспех на предоставянето. POST съдържа XML структура SubscriberProfile. Вътре в това полезни възли за проверка са:
   • bwuserid: Използвайте това, за да намерите профила на абоната, ако трябва да го редактирате в BroadWorks.
   • група: Ако шаблонът е в режим „Доставчик на услуги“, това е с малки букви и става името на организацията на клиента, която виждате в партньорския център.
   • ServiceProvider: Ако шаблонът е в „Корпоративен режим“, това е с малки бу кви и става името на организацията на клиента, която виждате в партньорския център.
   • Първичен телефонен номер: Трябва да съществува. Осигуряването се проваля без него.
   • имейл: Става потребителски идентификатор в Webex. Трябва да е валиден и уникален за Webex, в противен случай предоставянето не успее.

     Игнори райте стро фата на услугите: тя е създадена от AS и приета, но не се използва от Webex.

Анализирайте XSP дневниците, за да отстраните неизправности при влизането на абоната

Този поток описва режима на удостоверяване на BroadWorks. Можете да видите режима на удостоверяване в шаблона BroadWorks в партньорския център. Вижте Кон фигуриране на вашите клиентски шаблони в https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Следващата диаграма на стълбата показва взаимодействието между потребителя, клиента, услугите на Webex и системата BroadWorks, когато потребителят извършва удостоверяване на BroadWorks в приложението Webex. Също така връзката между Webex и XSP е защитена от MTLS.

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

Потребителят взаимодейства с клиента, клиентът взаимодейства с услугите на Webex:

• Потребителят предоставя своя имейл адрес в приложението Webex (1 в диаграмата).
• CI знае да пренасочи този потребител, за да въведе паролата си за BroadWorks (чрез UAP) (2 в диаграмата).
• IDP прокси представя заявка за получаване на профил до Xsi интерфейса на XSP.

В регистъра за достъп на tomcat:

• Потърсете заявката GET за профила на абоната, от Webex към интерфейса Xsi-Actions (2.1 на диаграмата). Той има потребителския идентификатор на Webex. Например:

  ПОЛУЧИ /com.broadsoft.xsi-actions/v2.0/потребител/ webexuserid@example.com /профил

В XSiActionsLog:

• Потърсете заявката за профил GET от Webex (2.1 в диаграмата). Той има потребителския идентификатор на Webex. Например:

  GET /com.broadsoft.xsi-actions/v2.0/ user/ webexuserid@example.com /profile Заглавките включват оторизация: Основен и потребителски агент: BroadworkSteamsClient

• След това XSP извършва OCI-P Basic удостоверяване срещу BroadWorks (AuthenticationVerifyRequest и AuthenticationVerifyResponse, както всяко друго приложение , което извършва основно удостоверяване чрез Xsi), а също и UserGetRequest и ServiceProviderGetRequest за събиране на информацията за абоната.
• Отговорът на Xsi към Webex съдържа блок XML профил, съдържащ потребителския код (BroadWorks) и други подробности (2.2 в диа грамата).

Взаимодействия с клиенти и услуги на Webex:

• IDP прокси съответства на потребителския профил, получен от BroadWorks, и издава SAML твърдение на клиента (2.3 в диаграмата).
• Клиентът обменя твърдението SAML за CI токен (3 в диаграмата).
• Клиентът проверява дали вписаният потребител има право на широкообхватен конектор (4 на диаграма). Можете да проверите правата на потребителите в Help Desk.
• Клиентът използва CI токен, за да поиска JSON уеб токен (JWT) от IDP прокси (5 в диаграма).
• IDP прокси проверява CI токена в CI.
• IDP прокси изисква JWT от услугата за удостоверяване.

В дневника на услугата AuthenticationService:

• Потърсете заявката за токен от Webex (5.2 в диаграмата), Например: GET /authservice/token, който има заглавка http_bw_userid и други.
• XSP прави OCI-P UserGetLoginInForEquest, за да потвърди дали предоставеният потребителски идентификатор съответства на потребител на BroadWor ks (5.3 в диаграмата). AuthService е устан овил доверие с Webex по силата на връзката MTL, така че може да издава LLT.
• Потърсете отговора (5.4 в диаграма) от LongLiveDTokenManager - Генериран токен , тема: bwksUserId@example.com, емитент: BroadWorks... и StatusCode=200, който можете да свържете с оригиналната заявка, като използвате заглавката trackingid: CLIENT...

В XSiActionsLog:

• Клиентът може да представи дълготрайния токен в интерфейса Xsi-Actions, за да получи профила си на устройството (6 в диаграма). Например: GET /com.broadsoft.xsi-actions/v2.0/user/bwksuserID %40example.com/profile/device С оторизация на заглавките: Токен на носителя и потребителски агент: WebExTeams (вариант/версия)
• Интерфейсът Xsi-Actions изпраща токена към авторската услуга (конфигуриран да бъде в интерфейса за обратна връзка) Например: 127.0.0. 1:80 POST http://127.0.0.1:80/authService/token, който можете да корелирате с заглавката trackingid: CLIENT... в GET и X-BROADSOFT-CORRELATION-ID: CLIENT... в заглавката POST.

В дневника на услугата AuthenticationService:

• Получаване на POST от Xsi (обратна връзка)

• Код на състоянието = 200 обратно към Xsi

• И отговор за валидиране на токен, който има блок „token“ JSON в тялото.

• Свързани с помощта на тракингида: КЛИЕНТ...

В XSiActionsLog:

• След като получи 200 OK от authservice, който потвърди стокен на клиента, приложението Xsi-Actions сега изпраща OCI-P заявка за UserPrimaryAndScadeviceGetListRequest
• Получава OCI-P UserPrimaryAndScadeviceGetListResponse, съдържащ структурата AccessDeviceTable XML.
• Отговорът на OCI-P се кодира като Xsi отговор към клиента, включително XML структурата на AccessDevices, която има DeviceTypes. Например: Business Communicator — компютър и URL адресите, където клиентът може да извлече конфигурационните файлове на устройството.

Клиентът продължава както обикновено:

• Избира запис на устройството и взаимодейства с DMS, за да получи профил на устройството (6 на диаграмата).
• Регистрира се към BroadWorks чрез SBC, извлечен в конфигурация от DMS (7 в диаграма).

Проблеми с партньорския център

1. Администраторът не може да вижда организациите на клиентите

Като администратор на вашата партньорска организация в Webex трябва да имате ролята на пълен администратор. Тази роля се използва за управление на вашата партньорска организация, включително за предоставяне на административни привилегии на себе си и на другите. За да управлявате организациите на клиенти, трябва да предоставите на себе си (или на други хора) ролята на пълен администратор за продажби или ролята на Администра тор на продажбите. За подробности вижте Присвояване на роли на акаунти на организацията в Контролен център.

Проблеми с предоставянето на потребители

1. Интегрирани IM&P грешки за конкретни предприя тия/клиенти

Ако имате комбинация от предприятия, използващи различни услуги за сътрудничество в облак, например UC-One SaaS и Webex за Cisco BroadWorks, може да сте избрали да модифицирате адаптера за предоставяне на услуги на базата на всяко предприятие.

За да проверите какво е конфигурирано за Integrated IM&P (по подразбиране за предприятията, освен ако не съществува по- конкретна настройка), стартирайте AS _CLI/Interface/Messaging> get. За параметрите за осигуряване на конкретно предприятие отворете предприятието и отидете на Услуги > Инте гриран IM &P.

Проверете дали конфигурацията на интегрираната IM&P за това предприятие съвпада точно с това, което е показано в шаблона за клиенти в партньорския център. Следните настройки трябва да съвпадат или предоставянето не успее за всички потребители в предприятието:

2. Интегрирани IM&P грешки за конкретни потребители

Това важи, ако използвате проходно осигуряване и предполага, че осигуряването работи за няко/повечето потребители (така че можете да изключите проблем с конфигурацията). Ако виждате интегрирани IM&P грешки в BroadWorks, например „[Грешка 18215] Грешка при предоставяне на съобщения със сървъра за съобщения“ и „[Грешка 18211] Грешка в комуникацията със сървъра за съобщения“, трябва да проучите следните потенциални причини:

• Имейл адресът на потребителя вече може да съществува CI. Потърсете потребителя в помощното бюро, за да проверите дали имейл адресът му вече е там. Това не е непременно категорично, тъй като потребителят може да съществува в организация, чиито данни не ви е позволено да виждате в бюрото за помощ.
• Потребителят се регистрира самостоятелно в Webex, преди да му бъде възложена интегрираната IM&P услуга. В този случай една от опциите е потребителят да изтрие безплатните си акаунти, които може да стане част от организацията на клиентите, която предоставяте. Инструкциите са на адрес https://help.webex.com/5m4i4y
• Потребителят няма основен телефонен номер, присвоен на профила си (всички абонати на Webex за Cisco BroadWorks трябва да имат основен DID). Вижте темата за анализ на PSlog от AS.

3. Неизправности при предоставянето на потребители в отговор от осигурителен мост

Ако потребителите не се появяват в Control Hub, в рамките на няколко минути след задаването на Integrated IM&P разгледайте кодовете за отговор от услугата за осигуряване на мост. Стартирайте PSlog, за да разгледате HTTP кодовете за отговор.

200 OK

Отговор 200 OK не означава, че потребителят е успешно предоставен. Това означава, че услугата за предоставяне е получила заявката и успешно е изпращала съответната заявка за създаване на потребител към услугите нагоре по веригата. Транзакцията за осигуряване е асинхронна по дизайн. Услугата отговаря на 200 OK, защото процесът на създаване на потребител може да отнеме няколко минути и поради съображения за производителност не искаме да получаваме няколко заявки за създаване на един и същ потребител. Ако обаче потребителят в крайна сметка не се появи в Организацията на клиентите след отговор на 200 OK, това може да означава, че създаването на потребител е неуспешно в услугите на Webex нагоре от услугата за предоставяне на услуги. Трябва да ескалирате провал при осигуряването, който има 200 OK отговор.

400 Лоша заявка

Проверете HTTP отговора, който трябва да съдържа повече подробности относно потенциалните проблеми, които биха могли да причинят този отговор от услугата за предоставяне на услуги. Някои примери за възела:

• „Не мога да се доверим на имейла на BroadWorks със стария API за предоставяне.“ Имейл адресът, свързан с неуспешната заявка за предоставяне на потребителя, не е валиден или е написан погрешно, но в шаблона сте заявили, че на имейл адресите може да се вярва. Проверете профил ите на потребителите в BroadWorks, по-специално имейл идентификатора.
• Клиентската организация не се намира в базата данни и не е активиран нов флаг за създаване на организация.“ Тази неуспешна заявка за предоставяне на услуги трябва да създава нова организация на клиенти в Webex, но вашият шаблон е конфигуриран да предотвратява създаването на нови организации на клиенти. Ако искате да разрешите нови организации, за имейл домейни, които не съвпадат със съществуващи клиенти в Webex, можете да преконфигурирате шаблона си в Partner Hub и да тествате отново заявката за предоставяне на услуги. Ако обаче не очаквате нова организация да бъде създадена за този потребител, може би имейл адресът е погрешно написан (по-специално частта от домейна). Проверете имейл идентификатора на потребителя в BroadWorks.

403 Забранено

Заявката за предоставяне не може да успее, докато не поправите конфигурацията. В този случай ще трябва да разследвате искането и отговора. Например, ако видите IP адрес като цел на заявката за предоставяне — вместо подходящия URL адрес за предоставяне на мост за вашата организация (вижте темите за конфигуриране на защитната стена в Ръководство за решения) — това може да означава, че на вашия сървър за приложения липсва необходима корекция (ap373197).

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

409 Конфликт

Заявката за предоставяне не може да продължи, тъй като в Webex има съществуващ потребител, който съответства на имейл адреса в заявката.

4. Потребителят вече е в CI

Извадете имейла на абоната от заявката HTTP POST и го потърсете в Help Desk. Може да не виждате потребителя, ако нямате право, но може също така да видите, че потребителят е в „безплатна“ организация, напр. „Потребител“. Можете да помолите този потребител да изтрие безплатния си акаунт или да използвате друг имейл адрес, за да ги предоставите. Ви жте https://help.webex.com/ndta402.

Проблеми с влизането на потребителя

1. Порталът за активиране на потребителя не се зарежда

Нормалният поток за влизане на Webex за Cisco BroadWorks включва портал за активиране на потребителите, където потребителите въвеждат паролите си. Понякога този портал не се зарежда, след като потребителят е посочил своя имейл адрес в екрана за влизане в Webex App. Този проблем може да бъде причинен от страна на клиента или от страна на услугата. От страна на клиента обикновено се причинява от това, че родният браузър на клиента е несъвместим по някакъв начин с услугата.

2. Еднократно влизане неуспешно

• В BroadWorks проверете дали на потребителя са присвоени типовете устройства за приложението Webex (вижте раздела Проф или на устройства в раздела Под готовка на вашата среда в Ръководството за решения).
• Проверете дали потребителят използва правилната парола. Ако шаблонът, който сте използвали за предоставяне на организацията на клиенти на потребителя (в партньорския център), е конфигуриран за удостоверяване на BroadWorks, потребителят трябва да въведе паролата си за BroadWorks „Web Access“. Потреб ителят може също да се наложи да въведе своя потребителски идентификатор на BroadWorks, ако имейл адресът му не е конфигуриран като алтернативен потребителски идентификатор. Уверете се, че потребителят е въвел правилно главни и малки букви.

Проблеми с конфигурацията и регистрацията на извик

След като потребителят е предоставен в Webex и той успешно влезе в приложението Webex, приложението се регистрира в BroadWorks. Следват очакваната последователност на регистрация и произтичащите от това признаци на здравословна регистрация (както се вижда от приложението Webex):

1. Очаквана последователност на регистрация

1. Клиентът се обажда на XSI, за да получи токен за управление на устройството и URL адреса към DMS.
2. Клиентът изисква своя профил на устройството от DMS, като представя токена от стъпка 1.
3. Клиентът чете профила на устройството и извлича SIP идентификационните данни, адресите и портовете.
4. Клиентът изпраща СИП РЕГИСТЪР до SBC, използвайки информацията от стъпка 3.
5. SBC изпраща SIP REGISTER до AS (SBC може да извърши търсене в NS, за да намери AS, ако SBC вече не познава потребителя на SIP.).

2. Очаквани признаци за успешна регистрация на клиента

Иконата Опции за извикване се появява в интерфейса на Webex.

В раздела за телефонни услуги на Webex App (напр. На стройки > Телефонни услуги в Windows, Предпочитания > Телефонни услуги на Mac) съобщението „SSO Session: You are login“ означава, че приложението е регистрирано успешно (в този случай към BroadWorks).

3. Клиентът няма икона за повикване

През повечето време това означава, че потребителят няма правилния лиценз /права.

Това е неуспешна регистрация. Има няколко причини, поради които клиент на Webex App не успее да се регистрира в BroadWorks:

4. Услугите за множество разговори се тестват с едни и същи клиенти

Този известен проблем може да бъде причинен от промяна на клиента между различните краища на обратно повикване. Най-вероятно е да се случи по време на тестове на различни услуги за разговори, предлагани чрез (същите) клиенти на Webex App. Можете да нулирате клиентската база данни (връзка), за да отстраните този проблем.

5. Неправилно конфигуриране на услугата за удостоверяване

Проверете XSP (ите), хостващи услугата за удостоверяване, спрямо Ръководството за решения (вижте Конфигу риране на услуги на вашия Webex за Cisco Broad Works XSPs). По-конкретно:

• RSA ключовете (които генерирате на един XSP) се копират във всички XSP
• URL адресът на услугата за удостоверяване е предоставен на уеб контейнера на всички XSP и е въведен правилно в клъстера в Partner Hub
• Външно удостоверяване чрез сертификати е конфигурирано:

  XSP_CLI/Система/Комуникационна помощна/Настройки по подразбиране/Външно удостоверяване/Удостоверяване на удостоверителност>Вземи

  allowUserApp = false

  allowClientApp = true

• Когато използвате MTLS, трябва да качите клиентския сертификат на Webex в XSP (можете да получите сертификата от Partner Hub, на страницата Настройки на BroadWorks).

6. Грешна конфигурация на таговете на BroadWorks

Проверете дали сте конфигурирали необходимите тагове на BroadWorks за приложението Webex. Вижте Ръководството за конфигуриране на Webex за Cisco BroadWorks за информация относно конфигура ционните маркери. Уверете се, че няма конфликти или неправилни стойности. По-конкретно, маркерът %SBC_ADDRESS_WXT% трябва да бъде SBC към вашия SIP регистър за клиенти на Webex App.

7. Настолният клиент изключва телефонните услуги след успешна SSO връзка

Този проблем може да бъде причинен от един и същ потребител, влизащ в множество клиенти на един и същ тип платформа. Например, ако потребител влезе успешно в приложението Webex в Windows и след това влезе в приложението Webex на друга машина с Windows, има само активна сесия на SSO на една от машините. Това е по дизайн. Ако абсолютно трябва да заобиколите този проблем, можете да конфигурирате BroadWorks да има няколко екземпляра от един и същ тип устройство, но те трябва да имат уникални SIP адреси. Тази конфигурация е извън обхвата на Webex за Cisco BroadWorks.

8. Настолното устройство не е предоставено за потребителя

Този подпис се вижда в дневника на клиента:

[0x70000476b000] ШирокоработиConfigDownloader.cpp:106 <Error>

onAccessDeviceListSucceded:bwc:scf: configDownload - профилът на устройството „Бизнес комуникатор - компютър“ не е намерен.

9. Входящите мобилни обаждания звънят веднъж или не могат да бъдат отговорени

Входящите обаждания към мобилния телефон Webex звънят само веднъж или потребителят не може да отговори на входящото повикване. Други крайни точки за същия потребител могат да продължат да звънят.

Как да идентифицираме?

В дневниците на мобилните клиенти на Webex потърсете XSI код за грешка 101002 в потока на push повиквания. Например:

Код за отговор: 400

<callID>HandlePushCallInfoFailure:BWC:Вътрешен: Push call: xsi състояние за CalliD: xsi код за грешка: 101002

<callID>ClosePushCallWithReason:BWC:Internal: Опитайте се да затворите push повикването с id =, reason = callAbandoned

Причина: К од за грешка 101002 може да показва, че грешният сървър на приложения (AS) е върнат в отговора на Loc ateUser. Това може да се случи, когато потребителят е мигрирал към вторичен AS.

Препоръчителни проверки:

От ADP или XSP, където е разположен Push, стартирайте LocateUser за засегнатия потребител:

<FQDN or IP address of NS Server>къдрене 'http: //:80/сервлет/локализиращ потребител? <BW userID @domain >URL = & връщане съвместимеXSP=True&callPrequest=True'

Пример: къдрене 'http://1.1.1.1:80/servlet/LocateUser? url = 9721112222@gmail.com & връщане съвместимеXSP=True&callPrequest = True '

Разделителна способност: Ако LocateUser върне вторичния AS за потребителя, стартирайте скрипта MigrateUserToDefaultNode.pl на основния NS сървър, за да мигрирате потребителите обратно към основния сървър за приложения за клъстера.

Влезте в NS сървъра чрез SSH, отидете в директорията /usr/local/broadworks/bw_base/bin и стартирайте: migrateU serToDefaultNode.pl <hostingNE>

Пример: Migrate UserToDefaultNode.pl bwas1

За да получите стойността на HostingNE, изпълнете: NS_CLI/System/Device/Hostingne> получете

Скриптът първо проверява дали може да намери хостинг NE, който предоставяте като аргумент. След като провери дали хостингът NE е валиден, той актуализира DN, разширението и URL адреса до възела по подразбиране за този хостинг NE.

Стартирайте скрипта по време на период с нисък трафик, когато е възможно. Въпреки това, като цяло е приемливо скриптът да се стартира по всяко време, ако е необходимо, за да се възстанови услугата за засегнатите потребители.

Скриптът не може да се изпълнява само за един потребител. Той мигрира всички потребители, изброени в изхода LocateUser. Ако не можете да стартирате скрипта, изтрийте и възстановете засегнатия потребител в BroadWorks, така че потребителят да бъде възстановен на правилния AS.

Всяко SIP съобщение от потребителското устройство към вторичния AS може да доведе до мигриране на потребителя. Потребителите обикновено се връщат към основния AS след 15-минутния интервал по подразбиране, освен ако входящите заявки продължат да достигат вторичния AS. Например, ако SBC не може да се свърже с AS1 и се повтаря към вторичния AS, засегнатите потребители могат да преминат към вторичния AS. В зависимост от внедряването, една група или потребител може да остане прикрепен към вторичния AS, ако SBC продължава да има проблеми с достигането до първичния AS.

За повече информация вижте следните документи:

• Раздели 3.4.5 Възможност за връщане на потребителя на сървъра на приложения и 5.4.5 Автоматично връщане в Ръководство за резервиране на Cisco BroadWorks

• Описание на функцията за подобрения на Cisco BroadWorks ASR

9. Телефонните услуги са изключени

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

За клиенти на Windows и Mac Webex App се регистрира за SIP и поддържа активна SIP регистрация, докато потребителят е влязъл в системата.

Проверете следното:

1. Проверете дали config-wxt.xml е изтеглен успешно.

В клиентските дневници потърсете ConfigDownload.

Успешното изтегляне показва:

ConfigDownload - завършен успешно

Ако дневниците показват следната грешка, проверете регистрационните файлове на AuthService за грешки, свързани с токените:

ConfigDownload - неуспешно с код за грешка: 1511

2. Проверете дали профилът на устройството Webex е намерен.

В клиентските дневници потвърдете, че устройството за достъп е намерено и че used_value е 1. Ако used_value е 0, проверете дали основният ред е активиран или деактивиран и проверете стойността на маркера. За повече подробности вижте раздел 6.1.44 Основен профил в Ръководството за конфигу риране на Webex за BroadWorks.

Примерни записи в дневника:

:BWC:SCF: ConfigDownload - намерено устройство за достъп

:BWC:SCF: ConfigDownload - устройство за достъп: deviceType = Бизнес комуникатор - компютър, deviceLevel = група, allowTermination = 1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndPointType: Споделен външен вид на повикване

:BWC:SCF: ConfigDownload - устройство за достъп: deviceType = Свързване - мобилно, deviceLevel = група, allowTermination = 1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndPointType: Изглед на споделено повикване

:BWC:SCF: ConfigDownload - устройство за достъп: deviceType = Свързване - таблет, deviceLevel = група, allowTermination = 1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndPointType: Изглед на споделено повикване

3. Проверете за повреди на DNS при разрешаване на SIP прокси адреса.

За подробности относно откриването на SIP прокси сървъри вижте раздел 6.1.6 Динамично откриване на SIP прокси сървъри в Р ъководството за конфигу риране на Webex за BroadWorks.

Успешното откриване на прокси показва:

Откриването на прокси приключи, получи <number>х резултати

4. Проверете дали регистрацията на SIP не е успешна.

Ако логовете показват mRegistration: TCPTimeout или Причина: SIP; cause=200; text="last=TCP-Timeout“, клиентът на Webex не може да установи T CP връзка с SBC на ниско ниво. SIP регистрацията не завършва, когато възникне тази грешка. Проверете дали TCP е блокиран в мрежата на потребителя или дали SBC отхвърля TCP връзката.

Ако заявката SIP REGISTER бъде отхвърлена или не получи отговор, потърсете в регистрите за REGISTER sip и проверете дали SIP/2.0 200 OK е върнато. Ако не бъде върнат, проверете дали мрежата на потребителя блокира SIP или SBC отхвърля заявката.

В администратора на BroadWorks отидете на User > Utilities > Регистра ции и проверете дали има валидна SIP регистрация за Webex клиента.

За мобилни клиенти с Android и iOS Webex App не се регистрира за SIP, докато не бъде направено или получено обаждане. Регистрацията се премахва, когато повикването приключи. Мобилните клиенти се регистрират за push известия.

За мобилни клиенти проверете следното:

1. Проверете дали config-wxt.xml се изтегля успешно и дали профилът на устройството е намерен, както е описано за клиенти на Windows и Mac.

2. Проверете дали push регистрацията е успешна.

В дневниците на Webex потърсете състоянието на регистрация push:

OnPushRegistrationStateChanged: :Променено е състоянието на регистрация на Push, state=Нерегистрирано

OnPushRegistrationStateChanged: :Променено е състоянието на регистрация на Push, state=Регистриран

В администратора на BroadWorks отидете на User > Utilities > Push Notification Registrations и проверете дали има валидна push регистрация за Webex клиента.

Проблеми с уеб преглед с настройките на повик

1. Бутон/връзка за самообслужване не се показва в приложението Webex

Друг симптом на този проблем е, когато се покаже бутонът/връзката, но щракването върху него отваря вън шен браузър.

• Проверете дали необходимия шаблон за конфигурация на клиента е внедрен и CSW маркерите са правилно зададени. (Вижте раздела Webview за настройки на оба жданията в ръководството за решения на Webex за Cisco BroadWorks).
• Проверете дали приложението Webex е регистрирано за обаждания в BroadWorks.
• Проверете дали приложението Webex е скорошна версия, която поддържа CSWV.

2. Празна страница или грешка, след като щракнете върху бутон/връзка за самообслужване

Обикновено това поведение в приложението Webex показва проблем с конфигурацията или внедряването на приложението CSWV на BroadWorks XSP. Съберете подробности за по-нататъшно разследване, включително CSWV дневници, дневници за достъп, хранилище config-wxt.xml и файл с шаблони, и след това повдигнете дело.

Проблеми с претендирането на

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

• Доставчиците на услуги не трябва да претендират за домейните на клиентските организации, които управляват. Те трябва да претендират само за домейните на онези потребители, които са във вътрешната организация на Доставчика на услуги. Заявяването на домейна на потребители в отделна организация (дори тази, която Доставчикът на услуги управлява) може да доведе до грешки при регистрацията на потребителите в организацията на клиентите, тъй като заявките за удостоверяване на потребителите се насоч ват през Доставчика на услуги, а не от организацията на клиентите.
• Ако две клиентски организации (компания А и компания Б) споделят един и същ домейн и Компания А е претендирала за домейна, регистрацията за потребители на компания Б може да се провали поради факта, че заявките за удостоверяване на потребителя се насочват през организацията, която е претендирала домейна (компания А).

  Ако претендирате за някакви домейни по грешка и трябва да премахнете рекламация , вижте статията Управление на вашите домейни на Webex.

Кодове за грешки на крайния потребител

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

Кодове за грешки за синхронизиране на директория

Следните кодове за грешки се прилагат за синхронизиране на директории.