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

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

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

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

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

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

• Уебекс за портал за знания за партньори на Cisco BroadWorks
• Ръководство за конфигуриране на платформата XSP (R23)
• Ръководство за управление на софтуера на BroadWorks (R23)
• Cisco BroadWorks ръководство за конфигуриране на управление на устройства (R23)
• Ръководство за администриране на интерфейс на команден ред на Broadworks XSP
• Описание на функцията за маркер за удостоверяване с дълъг живот, издание 23.0
• Ръководство за интегриране на SAML удостоверяване, R23
• Ръководство за опции за поддръжка на SSL на Cisco BroadWorks
• Описание на функцията за поддръжка на Cisco CI
• Пуш сървър за известия (описание на функцията)
• Поддръжка за пуш известия за повиквания, версия 22 с описание на функцията.0
• Метод на процедурата за свързване (Android) с Firebase
• Описание на функцията за съхранение на маркери за устройства за пуш известия в Cisco BroadWorks, издание 22.0
• Планиране на капацитета на Cisco BroadWorksSystem (електронна таблица)
• Ръководство за оразмеряване на платформата Cisco BroadWorks
• Ръководство за системно инженерство на Cisco Broadworks
• Документ за изисквания за поддръжка на CI удостоверяване версия 1.0 MR-7136

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

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

Serviceability Connector

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

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

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

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

Процедура

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

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

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

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

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

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

Процедура

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

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

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

Процедура

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

Извличане на регистрационни файлове на потребители от Partner Hub

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

Процедура

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

   Опция за Partner Hub:

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

   Опция на помощния център:

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

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

Процедура

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

Проверка на клиента за услуга за повиквания

Процедура

1. Влезте в клиента на Webex.
2. Проверете дали иконата "Опции за извикване" (слушалка със зъбно колело над нея) присъства в страничната лента. Ако иконата не присъства, потребителят може все още да не е разрешен за услугата за извикване в контролния център.
3. Отворете Settings/Preferences менюто и отидете в Phone Services раздел. Трябва да видите статуса SSO Session You're signed in. (Ако е показана друга телефонна услуга, като Webex Calling, потребителят не използва Webex за Cisco BroadWorks.)

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

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

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

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

  

Вземете данни за средата на повикванията

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

Процедура

1. На клиента щракнете върху Help > Health Checker.
2. Избор Reset Database. Това задейства пълно нулиране на клиента и зарежда екрана за влизане в приложението Webex.

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

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

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

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

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

   

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

   

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

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

1. Влезте в помощния център с идентификационните данни на вашия администратор на партньор.
2. Потърсете организацията.
3. Щракнете върху организацията и проверете Calling Behavior влизане. Трябва да е „Повикване в Webex“.

Анализиране на PSLog за проблеми с осигуряването на потребители

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

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

Съберете PSLog от сървъра на приложението по време на поточен опит за осигуряване с тестов потребител.

Процедура

1. Първо проверете кода на HTTP отговор:
   • Всичко, различно от 200 OK, е неуспешно осигуряване на потребителя.
   • 200 OK все още може да посочи неуспех, ако нещо за профила на абоната не работи в услугите на Webex над моста за обезпечаване.
   • 400 може да съдържа message възел в отговора. Мостът за обезпечаване не може да обработи нещо в subscriberProfile. Възможно е да има нещо нередно с подробностите за абоната или несъвместимост с настройка в шаблона.
   • 401 означава въведените в AS идентификационни данни за осигуряване не съвпадат с въведените в шаблона в Partner Hub.
   • 403 може да покаже нещо, което е неправилно конфигурирано на сървъра за приложения. Проверете целта на заявката. Това не трябва да е IP адрес, а трябва да е URL адресът на моста за обезпечаване, който можете да видите в шаблона си в Partner Hub.
   • 409 показва конфликт между доставените subscriberProfile и съществуващи данни на Webex. Възможно е да има съществуващ потребител с този имейл адрес. Проверете message в отговора.
2. Можете също да проверите оригиналния HTTP POST за всякакви съмнителни стойности, които биха могли да доведат до неуспешно осигуряване. POST съдържа subscriberProfile XML структура. Вътре в това полезни възли за проверка са:
   • bwuserid: Използвайте това, за да намерите профила на абоната, ако трябва да го редактирате в BroadWorks.
   • group: Ако шаблонът е в режим на доставчик на услуги, това е с малки букви и става името на организацията на клиента, която виждате в Partner Hub.
   • serviceProvider: Ако шаблонът е в корпоративен режим, той е с малки букви и става името на организацията на клиента, която виждате в Partner Hub.
   • primaryPhoneNumber: Трябва да съществува. Неуспешно осигуряване без него.
   • email: Става потребителският ИД в Webex. Трябва да е валидна и уникална за Webex – в противен случай осигуряването е неуспешно.

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

Анализиране на регистрационните файлове на XSP за отстраняване на неизправности при влизане на абонати

Този поток описва режима на удостоверяване на BroadWorks. Можете да видите режима на удостоверяване в шаблона на BroadWorks в Partner Hub. Вижте Конфигуриране на вашите шаблони за клиенти в 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 access_log:

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

  GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

В XsiActionsLog:

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

  GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile Заглавките включват authorization: Basic и user-agent: broadworksTeamsClient

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

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

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

В регистрационния файл на authenticationService:

• Потърсете заявката за маркер от Webex (5.2 на диаграмата), например: GET /authService/token който има http_bw_userid заглавка и други.
• XSP прави OCI-P UserGetLoginInfoRequest, за да потвърдите, че предоставеният ИД на потребител съответства на потребител на BroadWorks (5.3 на диаграмата). AuthService установи доверие с Webex по силата на mTLS връзката, така че може да издава LLT.
• Потърсете отговора (5.4 на диаграмата) от LongLivedTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks … и StatusCode=200 които можете да асоциирате с оригиналната заявка, като използвате trackingid: CLIENT… заглавка.

В XsiActionsLog:

• Клиентът може да представи маркера с дълъг живот в интерфейса на Xsi-Actions, за да получи профила на устройството си (6 на схемата). Например: GET /com.broadsoft.xsi-actions/v2.0/user/bwksUserId%40example.com/profile/device Със заглавките authorization: Bearer token и user-agent: WebexTeams (variant/version)
• Интерфейсът на 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 (loopback)

• О: StatusCode=200 назад към Xsi

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

• Корелация чрез използване на trackingid: CLIENT…

В XsiActionsLog:

• След като получи 200 OK от authservice, която потвърди stoken на клиента, приложението Xsi-Actions вече изпраща OCI-P заявка за UserPrimaryAndSCADeviceGetListRequest
• Получава OCI-P UserPrimaryAndSCADeviceGetListResponse съдържащи accessDeviceTable XML структура.
• OCI-P отговорът е кодиран като Xsi отговор към клиента, включително AccessDevices XML структура, която има deviceTypes. Например: Business Communicator – PC и URL адресите, където клиентът може да извлече конфигурационните файлове на устройството.

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

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

Проблеми с Partner Hub

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

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

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

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

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

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

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

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

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

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

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

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

200 ОК

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 и го потърсете в помощния център. Възможно е да не виждате потребителя, ако не сте разрешени, но също така може да видите, че потребителят е в „безплатна“ организация, например. "Консуматор". Можете да помолите този потребител да изтрие безплатния си акаунт, или можете да използвате друг имейл адрес, за да го осигурите. Вижте https://help.webex.com/ndta402.

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

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

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

2. Неуспешна еднократна идентификация

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

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

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

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

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

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

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

В раздела за телефонни услуги в приложението Webex (напр. Settings > Phone Services в Windows, Preferences > Phone Services на Mac), съобщението „SSO сесия: Влезли сте“ означава, че приложението е регистрирано успешно (в този случай в BroadWorks).

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

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

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

4. Множество услуги за повиквания, които се тестват с едни и същи клиенти

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

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

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

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

  XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CertificateAuthentication>get

  allowUserApp = false

  allowClientApp = true

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

6. Неправилно конфигуриране на етикетите на BroadWorks

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

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

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

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

Този подпис се вижда в регистрационния файл на клиента:

<Error> [0x70000476b000] BroadWorksConfigDownloader.cpp:106

onAccessDeviceListSucceeded:BWC:SCF: ConfigDownload - the device profile 'Business Communicator - PC' is not found.

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

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

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

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

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

handlePushCallInfoFailure:BWC:ВЪТРЕШЕН: Статус на насочено повикване: xsi за callID: <callID> код на грешка xsi: 101002

closePushCallWithReason:BWC:ВЪТРЕШЕН: Опитайте да затворите повикването с идентификатор = <callID>, причина = CallAbandoned

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

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

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

curl 'http://<FQDN or IP address of NS Server>:80/servlet/LocateUser?url=<BW userID@domain>&returnCompatibleXSP=true&callPRequest=true'

Пример: curl 'http://1.1.1.1:80/servlet/LocateUser?url=9721112222@gmail.com&returnCompatibleXSP=true&callPRequest=true'

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

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

Пример: migrateUserToDefaultNode.pl bwas1

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

Скриптът първо проверява дали може да намери хостинга 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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