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

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

Полезни лог файлове

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

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

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

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

Serviceability Connector

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

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

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

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

Процедура

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

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

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

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

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

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

Процедура

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

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

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

Процедура

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

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

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

Процедура

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

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

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

   Опция за помощно бюро:

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

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

Процедура

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

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

Процедура

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

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

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

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

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

  

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

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

Процедура

1. В клиентската програма щракнете върху Помощ > Проверка на състоянието.
2. Изберете Нулиране на базата данни. Това задейства пълно рестартиране на клиента и зарежда екрана за вход в приложението 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. Кликнете върху организацията и проверете записа Поведение при повикване. Трябва да е „Извикване на Webex“.

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

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

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

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

Процедура

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

     Игнорирайте строфата services : Създаден е от 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.

В котарака 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 Basic удостоверяване срещу 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 от услугата за удостоверяване.

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

• Потърсете заявката за токен от 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.

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

• Получаването на POST от Xsi (loopback)

• A StatusCode=200 обратно към Xsi

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

• Корелирано с помощта на trackingid: CLIENT…

В XsiActionsLog:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ако потребителите не се показват в Control Hub, в рамките на няколко минути след задаване на интегрирани IM & П, виж кодовете за отговор от услугата за осигуряване на мост. Пуснете 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 съществува потребител, който съответства на имейл адреса в заявката.

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

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

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

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

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

Единичното влизане не беше успешно

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

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

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

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

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

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

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

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

Клиентът няма икона за обаждане

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

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

Тестват се множество услуги за обаждания с едни и същи клиенти

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

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

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

• 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).

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

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

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

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

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

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

[0x70000476b000] BroadWorksConfigDownloader.cpp:106

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

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

Грижа за себе си button/link не се показва в приложението Webex

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

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

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

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

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

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

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

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

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

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

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

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