Дякуємо за відгук.

Ця стаття призначена для команди технічної підтримки в організації постачальника послуг, яка підтримує себе та своїх клієнтів. Вони повинні бути знайомі із загальним усуненням несправностей, читанням журналів та роботою з абонентськими кейсами.

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

• Ресурси — містить перелік інструментів, матеріалів для читання, журналів та контактів, які вам можуть знадобитися.
• Процеси — описує деякі дії, які можна вжити під час усунення проблеми клієнта.
• Конкретні проблеми — класифікує та перераховує проблеми, які, як відомо, виникли, як їх виявити та як їх потенційно можна вирішити.

Корисні файли журналів

Список читання

• Портал знань партнерів Webex для Cisco BroadWorks
• Посібник з налаштування платформи XSP (R23)
• Посібник з управління програмним забезпеченням BroadWorks (R23)
• Посібник з налаштування керування пристроями Cisco BroadWorks (R23)
• Посібник з адміністрування інтерфейсу командного рядка Broadworks Xsp
• Опис функції довготривалого токена аутентифікації Випуск 23.0
• Посібник з інтеграції автентифікації SAML, R23
• Посібник із параметрів підтримки Cisco BroadWorks SSL
• Опис функції підтримки Cisco CI
• Push-сервер сповіщень (опис функції)
• Підтримка push-сповіщень для дзвінків Опис функції Випуск 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 або UUID користувача (це ідентифікатор Webex, але якщо ви також отримуєте ідентифікатор користувача BroadWorks, включіть його в деталі справи).
• Ідентифікатор організації.
• Приблизні часові рамки, протягом яких виникла проблема.
• Клієнтська платформа і версія.
• Відправляти або збирати журнали від клієнта.
• Запишіть ідентифікатор відстеження, якщо він відображається на клієнті.

Перевірте дані користувача в довідковій службі

Адміністратори-партнери, які мають права адміністратора служби підтримки (базові або розширені), можуть скористатися цією процедурою для перевірки відомостей про користувача за допомогою перегляду служби підтримки.

Порядок

1. Увійдіть у службу підтримки.
2. Шукайте користувача, а потім клацніть його. Відкриється екран резюме користувача.
3. Натисніть ім'я користувача, щоб побачити детальну конфігурацію користувача. Корисна інформація в цьому поданні включає UUID користувача, кластер спільної ідентичності (CI), кластер додатків Webex, поведінку викликів, GUID облікового запису BroadWorks
4. Натисніть Копіювати, якщо вам потрібно використовувати цю інформацію в іншому інструменті, або прикріпіть її до корпусу Cisco.

Перегляд організації клієнтів у службі підтримки

Адміністратори-партнери, які мають привілеї адміністратора служби підтримки (базові або розширен і), можуть скористатися цією процедурою для перегляду відомостей про організацію клієнтів у представленні служби підтримки.

Порядок

1. Увійдіть у службу підтримки.
2. Знайдіть назву організації клієнта, а потім клацніть її.
3. Прокрутіть униз, доки не з'яви ться Перегляд порталу клієнтів, і натисніть Переглянути ім'я клієнта, щоб побачити лише для читання організацію клієнта, включаючи користувачів та конфігурацію.

Отримати журнали користувачів з Partner Hub

Під час усунення проблем настільного та мобільного клієнта важливо, щоб Партнери (та TAC) мали змогу переглядати журнали клієнтів.

Порядок

1. Попросіть користувача надіслати журнали. Щоб отримати довідку, див. розділ: Додаток Webex | Повідомити про проблему.
2. Попросіть користувача експортувати викликове середовище і надіслати вам файл ced.dat.
3. Отримайте журнали клієнтів з Центру партнерів або служби підтримки.

   Варіант партнерського центру:

   1. Увійдіть у Партнерський центр і знайдіть організацію клієнта користувача.
   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.
   • Користувач успішно пройшов аутентифікацію.
   • Вашою системою BroadWorks клієнту видається довговічний веб-токен JSON.
   • Клієнт отримав свій профіль пристрою та зареєструвався в BroadWorks.

Отримати журнали клієнтів або зворотній зв'язок

• Перегляньте розділ Ресурси, щоб знайти конкретні журнали клієнтів у настільних клієнтах Webex або попросити користувачів надсилати журнали. Щоб отримати довідку, див. розділ: Додаток Webex | Повідомити про проблему.
• Попросіть користувачів мобільних клієнтів надсилати журнали, тоді ви можете отримати їх через Partner Hub або Help Desk.
  Надсилання журналів мовчить. Однак, якщо користувач надсилає відгук, він переходить до команди devops Webex App. Обов'язково запишіть номер зворотного зв'язку користувача, якщо ви хочете зв'язатися з Cisco. Наприклад:

  

Отримати дані про середовище виклику

Журнали клієнтів Webex сильно редагуються, щоб видалити особисту інформацію. Ви повинні експортувати дані середовища виклику з клієнта в той самий сеанс, коли ви помі тили проблему.

Порядок

1. На клієнті натисніть Дов ідка > Перевір ка стану здоров'я.
2. Виберіть С кинути базу даних. Це запускає повне скидання клієнта та завантажує екран входу в програму Webex.

Переконайтеся, що Webex повинен зареєструватися в BroadWorks

Додаток Webex перевіряє наступну інформацію, щоб визначити, чи потрібно зареєструватися в BroadWorks:

• Право користувача на широкоформатний з'єднувач.
• Поведінка викликів для організації та користувача.

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

1. Увійдіть у служ бу підтримки за допомогою облікових даних адміністратора партнера.
2. Пошук користувача.
3. Натисніть на користувача та перевірте запис Поведінка виклику. Це має бути «Виклик у Webex».

   

4. Натисніть ім'я користувача, щоб відкрити екран Відомості про користувача.
5. Прокрутіть униз, щоб знайти розділ прав, і переконайтеся, що включений роз'є м broadworks

   

   Користувач Webex для Cisco BroadWorks не повинен мати права стандарту bc-sp, якщо він має намір використовувати Webex для Cisco BroadWorks. Це право на «Webex Calling(Broadcloud)», що є викликом програми Webex через службу хмарних дзвінків, керовану Cisco.

Перевірте поведінку організації дзвінків

1. Увійдіть у служ бу підтримки за допомогою облікових даних адміністратора партнера.
2. Пошук організації.
3. Натисніть на організацію та перевірте запис Пов едінка викликів. Це має бути «Виклик у Webex».

Аналізуйте PSLog на предмет проблем із забезпеченням користувача

Використовуйте PSLog сервера додатків, щоб побачити запит HTTP POST до мосту забезпечення та відповідь від Webex. У правильному робочому випадку відповідь 200 ОК, і через кілька хвилин ви можете побачити користувача - і нову організацію клієнта, якщо це перший користувач - створен о у Webex. Ви можете підтвердити це, знайшовши в службі підтримки адресу електронної пошти, яку ви бачите в POST.

Перш ніж почати

Зберіть PSLog з сервера додатків під час спроби створення поточного резервування з тестовим користува чем.

Порядок

1. Спочатку перевірте код відповіді HTTP:
   • Все інше, крім 200 OK, є помилкою надання користувачем.
   • 200 OK все ще може вказувати на збій, якщо-небудь з профілю абонента не працює в службах Webex вище за мостом забезпечення.
   • 400 може містити вузол повідомлення у відповіді. Міст забезпечення не зміг обробити щось у Subscri ber Profile. Може бути щось не так з реквізитами абонента, або несумісність з налаштуванням в шаблоні.
   • 401 означає, що облікові дані для забезпечення, введені в АС, не збігаються з обліковими даними, введеними у шаблоні в Partner Hub.
   • 403 може вказувати на щось неправильно налаштоване на сервері додатків. Перевірте цільову адресу запиту. це не повинна бути IP-адреса, це має бути URL-адреса мосту для забезпечення, яку ви можете бачити у своєму шаблоні в Partner Hub.
   • 409 вказує на конфлікт між наданим Subscri berProfile та існуючими даними Webex. Може бути існуючий користувач з цією адресою електронної пошти. Перевір те повідомлення у відповіді.
2. Ви також можете перевірити вихідний HTTP POST на наявність будь-яких підозрілих значень, які можуть спричинити не вдалу підготовку. POST містить структуру XML Sub scriberProfile. Всередині цього корисними вузлами для перевірки є:
   • bwuserid: Використовуйте це, щоб знайти профіль передплатника, якщо вам потрібно від редагувати його в BroadWorks.
   • group: якщо шаблон перебуває в режимі «Постачальника послуг», цей шаблон буде малою літерою і стає назвою організації клієнта, яку ви бачите в центрі партнерів.
   • ServicePro vider: якщо шаблон перебуває в «Корпоративному режимі», він буде використаний малими літерами і стає назвою організації клієнта, яку ви бачите в центрі партнерів.
   • Первинний номер телефону: Повинен існувати. Забезпечення не вдається без нього.
   • електронна пош та: стає ідентифікатором користувача у 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 /профіль

У журналі XSIActions:

• Шукайте профіль GET запит від Webex (2.1 на діаграмі). Він має ідентифікатор користувача Webex. Наприклад:

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile Заголовки включають авторизацію: Базовий та агент користувача: BroadworkSteamsClient

• Потім XSP виконує базову аутентифікацію OCI-P проти BroadWorks (AuthenticationVerifyRequest та AuthenticationVerifyResponse, як і будь-яка інша програма, яка виконує базову аутентифікацію через Xsi), а також UserGetRequest та ServiceProvider GetRequest для збору інформації про абонента.
• Відповідь Xsi на Webex містить блок профі лю XML, що містить ідентифікатор користувача (BroadWorks) та інші деталі (2.2 на діаграмі).

Взаємодія з клієнтом і службами Webex:

• Проксі-сервер IDP відповідає профілю користувача, отриманому від BroadWorks, і видає заяву про SAML клієнту (2.3 на діаграмі).
• Клієнт обмінює твердження SAML на токен CI (3 на діаграмі).
• Клієнт перевіряє, чи має зареєстрований користувач право на роз'єм broadworks (4 на діаграмі). Ви можете перевірити права користувача в довідковій службі.
• Клієнт використовує токен CI для запиту веб-токена JSON (JWT) від проксі IDP (5 на діаграмі).
• Проксі-сервер IDP перевіряє токен CI в CI.
• Проксі-сервер IDP запитує JWT від служби автентифікації.

У журналі AuthenticationService:

• Шукайте запит токена від Webex (5.2 на діаграмі), Наприклад: GET /AuthService/token, який має заголовок http _bw_ userid та інші.
• XSP виконує OCI-P UserGetLoginInForQuest, щоб перевірити, чи вказаний ідентифік атор користувача відповідає користувачеві BroadWorks (5.3 на діаграмі). AuthService встановила довіру до Webex завдяки підключенню MTLS, тому може видавати LLT.
• Шукайте відповідь (5.4 на діаграмі) з LongLivedTokenManager - створений токен, тема: bwksUserId@example.com, емітент: BroadWorks... та statusCode=200, які ви можете пов'язати з початковим запитом за допомогою заголовка trackingid: CLIENT...

У журналі XSIActions:

• Клієнт може представити довговічний токен на інтерфейсі 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

• І відповідь на перевірку токенів, що має бло к JSON "то кен" в тілі.

• Корельовано за допомогою ідентифі катора відстеження: CLIENT...

У журналі XSIActions:

• Отримавши 200 ОК від authservice, яка підтвердила протокол клієнта, додаток Xsi-Actions тепер надсилає запит OCI-P для UserPrimaryAndScaDeviceGetListRequest
• Отримує OCI-P UserPrimaryAndS caDeviceGetListResponse, що містить структуру XML AccessDeviceTable.
• Відповідь 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, можливо, ви вирішили змінити адаптер забезпечення для кожного підприємства.

Щоб перевірити, що налаштовано для інтегрованого 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. Збої у забезпеченні користувача у відповідь від мосту забезпечення

Якщо користувачі не з'являються в Центрі керування, протягом декількох хвилин після призначення інтегрованого IM&P перегляньте коди відповідей служби мосту забезпечення. Запустіть PSlog, щоб переглянути коди відповіді HTTP.

200 OK

Відповідь 200 OK не означає, що користувач успішно забезпечений. Це означає, що служба надання послуг отримала запит і успішно надіслала відповідний запит на створення користувача до вищих служб. За задумом транзакція забезпечення є асинхронною. Сервіс відповідає 200 ОК, оскільки процес створення користувача може зайняти кілька хвилин, і з міркувань продуктивності ми не хочемо отримувати кілька запитів на створення одного і того ж користувача. Однак, якщо користувач зрештою не з'являється в Організації клієнта після відповіді 200 ОК, це може означати, що створення користувача не вдалося у службах Webex перед службою надання послуг забезпечення. Вам потрібно посилити помилку забезпечення, яка має відповідь 200 ОК.

400 Поганий запит

Перевірте відповідь HTTP, яка повинна містити більш детальну інформацію про потенційні проблеми, які можуть спричинити цю відповідь від служби надання послуг. Кілька прикладів вузла:

• «Не можна довіряти електронній пошті BroadWorks із застарілим API забезпечення.» Адреса електронної пошти, пов'язана з невдалим запитом на надання користувачем, є недійсною або введена неправильно, але ви підтвердили у шаблоні, що адреси електронної пошти можна довіряти. Перевірте профі лі користувачів у BroadWorks, зокрема ідентифікатор електронної пошти.
• Організація клієнта не знайдена в базі даних, а також новий прапор створення організації не ввімкнено.» Цей невдалий запит на забезпечення повинен створювати нову організацію клієнтів у Webex, але ваш шаблон налаштований на запобігання створенню нових організацій клієнтів. Якщо ви хочете дозволити нові організації для доменів електронної пошти, які не відповідають існуючим клієнтам у Webex, ви можете переналаштувати шаблон у партнерському центрі та повторно перевірити запит на надання послуг. Однак, якщо ви не очікуєте створення нової організації для цього користувача, можливо, адреса електронної пошти введена неправильно (зокрема частина домену). Перевір те ідентифікатор електронної пошти користувача в BroadWorks.

403 Заборонено

Запит на надання не може бути успішним, доки ви не виправляєте конфігурацію. Вам потрібно буде дослідити запит і відповідь у цьому випадку. Наприклад, якщо ви бачите IP-адресу як цільову адресу запиту на створення — замість відповідної URL-адреси мосту забезпечення для організації (див. теми конфігурації брандмауера в Посібнику з вирішення проблем) — це може означати, що на сервері додатків відсутня необхідна виправлення (ap373197).

Переконайтеся, що всі необхідні виправлення застосовані до сервера додатків і що ви завершили відповідну конфігурацію для успішного забезпечення поточного забезпечення.

409 Конфлікт

Запит на надання не може продовжуватися, оскільки у Webex є існуючий користувач, який відповідає адре сі електронної пошти у запиті.

4. Користувач вже в CI

Вийміть електронну пошту абонента із запиту HTTP POST та знайдіть його в довідковій службі. Ви можете не бачити користувача, якщо вам заборонено, але ви також можете побачити, що користувач знаходиться в «вільній» організації, наприклад «Споживач». Ви можете попросити цього користувача видалити свій безкоштовний обліковий запис, або ви можете використовувати іншу адресу електронної пошти, щоб надати їх. Див. https://help.webex.com/ndta402.

Проблеми з входом користувача

1. Портал активації користувача не завантажується

Звичайний потік входу в систему Webex для Cisco BroadWorks включає портал активації користувачів, де користувачі вводять свої паролі. Іноді цей портал не завантажується після того, як користувач вказав свою адресу електронної пошти на екрані входу в програму Webex. Ця проблема може бути викликана на стороні клієнта або на стороні сервісу. На стороні клієнта це, як правило, викликано тим, що рідний браузер клієнта певним чином несумісний із сервісом.

2. Помилка одноразового входу

• У BroadWorks перевірте, чи призначено користувачеві типи пристроїв для програми Webex (див. Розділ Профілі пристроїв у розділі Під готовка середовища керівництва з рішеннями).
• Перевірте, чи користувач використовує правильний пароль. Якщо шаблон, який ви використовували для надання організації клієнтів користувача (у партнерському центрі), налаштований для ав тентифікації 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 до АС (SBC може виконати пошук у NS, щоб знайти AS, якщо SBC ще не знає користувача SIP.).

2. Очікувані ознаки успішної реєстрації клієнта

Значок «Параметри виклику» з'являється в інтерфейсі Webex.

На вкладці служб телефону Webex App (наприклад, Н алаш тування > Телефонні служби в Windows, Н алаш тування > Телефонні служби на Mac) повідомлення «Сеанс SSO: Ви ввійшли в систему» означає, що програма успішно зареєстрована (у цьому випадку на BroadWorks).

3. Клієнт не має значка дзвінка

У більшості випадків це означає, що користувач не має правильної ліцензії/прав.

Це невдала реєстрація. Існує кілька причин, чому клієнт Webex App не вдасться зареєструватися в BroadWorks:

4. Кілька служб дзвінків тестуються з тими ж клієнтами

Ця відома проблема може бути викликана тим, що клієнт змінює різні зворотні виклики. Швидше за все, це станеться під час випробувань різних служб дзвінків, пропонованих через (ті ж) клієнти Webex App. Ви можете скинути клієнтську базу даних (посилання), щоб виправити цю проблему.

5. Неправильна настройка служби аутентифікації

Перевірте XSP, на якому розміщено службу автентифікації, відповідно до Посібника з рішень (див. Налаштування служб на вашому Webex для Cisco BroadWorks XSP). Конкретно:

• Ключі 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] Широкоформатний конфігурЗавантажувач.cpp: 106 <Error>

onAccessDeviceListSucceded:bwc:scf: configDownload - профіль пристрою «Бізнес-комунікатор - ПК» не знайдено.

9. Вхідні мобільні дзвінки дзвонять один раз або на них не можна відповісти

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

Як ідентифікувати?

У журналах мобільних клієнтів Webex знайдіть код помилки XSI 101002 у потоці push-дзвінків. Наприклад:

Код відповіді: 400

<callID>HandlePushCallInfoFailure:bwc:внутрішній: push-виклик: статус xsi для callID: код помилки xsi: 101002

<callID>ClosePushCallWithReason:bwc:Internal: Спробуйте закрити push-виклик з id =, reason = callAbandoned

Причина: Код помилки 101002 може вказувати на те, що у відповіді Loc ateUser повертається неправильний сервер додатків (AS). Це може статися, коли користувач перейшов до вторинного AS.

Рекомендовані перевірки:

З ADP або XSP, де розгорнуто Push, запустіть LocateUser для постраждалого користувача:

<FQDN or IP address of NS Server>завивка «http: //:80/сервлет/LocateUser? <BW userID @domain >url=&ReturnCompatibleXSP=True&callpRequest=True'

Приклад: curl 'http://1.1.1.1:80/servlet/LocateUser? URL= 9721112222@gmail.com &returnCompatibleXSP=True&callpRequest=правда '

Рішення: якщо LocateUser повертає вторинну АС для користувача, запустіть скрипт 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> get

Спочатку скрипт перевіряє, чи може він знайти хостинг NE, який ви вказуєте як аргумент. Після того, як він перевірить, що хостинг NE дійсний, він оновлює DN, розширення та URL-адресу до вузла за замовчуванням для цього хостингу NE.

Запустіть скрипт протягом періоду з низьким трафіком, коли це можливо. Однак, як правило, прийнятно запускати скрипт у будь-який час, якщо це необхідно для відновлення служби для постраждалих користувачів.

Скрипт не може бути запущений лише для одного користувача. Він мігрує всіх користувачів, перелічених у виході LocateUser. Якщо ви не можете запустити скрипт, видаліть та відновіть постраждалого користувача в BroadWorks, щоб користувач був перебудований на правильному AS.

Будь-яке SIP-повідомлення від пристрою користувача до вторинного АС може призвести до міграції користувача. Зазвичай користувачі повертаються до основного АС після 15-хвилинного інтервалу за замовчуванням, якщо вхідні запити не продовжують надходити до вторинного AS. Наприклад, якщо SBC не може підключитися до AS1 і рекурсує до вторинного AS, користувачі, які постраждали, можуть перейти на вторинний AS. Залежно від розгортання, одна магістральна група або користувач можуть залишатися прикріпленими до вторинного AS, якщо SBC продовжує мати проблеми з доступом до основного АС.

Для отримання додаткової інформації див. Наступні документи:

• Розділи 3.4.5 Можливість відкату користувача сервера додатків та 5.4.5 Автоматичний відкат у посібнику із резервування Cisco BroadWorks

• Опис функцій вдосконалення Cisco BroadWorks ASR

9. Телефонні служби відключені

Якщо телефонні служби відображаються як відключені після входу користувача до програми Webex або якщо телефонні служби відключаються, коли користувач використовує клієнт, перевірте тип клієнта та процес реєстрації.

Для клієнтів Windows і Mac додаток Webex реєструється для 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 [має_значення: 0, використання_значення: 1], hasOwnerDevice: 1, EndpointType: Зовнішній вигляд спільного виклику

:BWC:SCF: configDownload - пристрій доступу: DeviceType=Підключитися - Мобільний, DeviceLevel=група, AllowTermination=1, IsDeviceOwner [має_значення: 0, використання_значення: 1], hasOwnerDevice: 1, EndpointType: Зовнішній вигляд спільного виклику

:BWC:SCF: configDownload - пристрій доступу: DeviceType=Підключити - Планшет, DeviceLevel=Група, AllowTermination=1, IsDeviceOwner [має_значення: 0, використання_значення: 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 не може встановити TCP-з'єднання низького рівня до SBC. Реєстрація SIP не завершується, коли виникає ця помилка. Перевірте, чи заблоковано TCP в мережі користувача, або SBC відхиляє TCP-з'єднання.

Якщо запит SIP REGISTER відхилено або не отримує відповіді, шукайте в журналах REGISTER sip і перевірте, чи повернуто SIP/2.0 200 OK. Якщо він не повернувся, перевірте, чи мережа користувача блокує SIP або SBC відхиляє запит.

У Адміністраторі BroadWorks перейдіть до пункту Користувач > Слу жб ові програми > Реєстрації та перевірте, чи є дійсна реєстрація SIP для клієнта Webex.

Для мобільних клієнтів Android та iOS додаток Webex не реєструється для SIP, доки дзвінок не буде здійснено або отримано. Реєстрація знімається після завершення дзвінка. Мобільні клієнти реєструються для push-повідомлень.

Для мобільних клієнтів перевірте наступне:

1. Переконайтеся, що файл config-wxt.xml успішно завантажується та чи знайдено профіль пристрою, як описано для клієнтів Windows та Mac.

2. Переконайтеся, що push-реєстрація успішна.

У журналах Webex шукайте стан реєстрації push:

onPushRegistrationStateChanged: :Стан реєстрації Push змінено, state=Незареєстрований

onPushRegistrationStateChanged: :Стан реєстрації Push змінено, state=зареєстрований

У Адміністраторі BroadWorks перейдіть до розді лу Користувач > Слу жб ові програми > Реєстрації push-повідом лень і перевірте, чи є дійсна реєстрація push для клієнта Webex.

Проблеми веб-перегляду налаштувань дзвінків

1. Кнопка самообслуговування/посилання не відобража ється в додатку Webex

Інший симптом цієї проблеми - коли кнопка/посилання відображається, але натискання на неї відкриває зовнішній браузер.

• Переконайтеся, що необхідний шаблон конфігурації клієнта розгорнуто, і теги CSW правильно встановлені. (Див. Роз діл веб-перегляду налашт увань викли ків у посібнику з рішень Webex для Cisco BroadWorks).
• Переконайтеся, що додаток Webex зареєстровано для дзвінків у BroadWorks.
• Переконайтеся, що додаток Webex є останньою версією, яка підтримує CSWV.

2. Порожня сторінка або помилка після натискання кнопки/посилання Self Care

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

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

Помилки реєстрації користувачів можуть виникати в результаті помилок, які допускаються при претензії доменів. Перш ніж претендувати на будь-які домени, переконайтеся, що ви розумієте наступне:

• Постачальники послуг не повинні претендувати на домени організацій-клієнтів, якими вони керують. Вони повинні претендувати лише на домени тих користувачів, які знаходяться у внутрішній організації Постачальника послуг. Заявка на домен користувачів в окремій організації (навіть тієї, якою керує Постачальник послуг) може призвести до помилок реєстрації користувачів в організації-замовника, оскільки запити на аутентифікацію користувачів спрямовуються через По стачальника послуг, а не організацію-замовника.
• Якщо дві організації-клієнти (Компанія А та Компанія В) мають один і той же домен, а компанія A претендувала на домен, реєстрація для користувачів Компанії B може не відбутися через те, що запити на автентифікацію користувачів маршрутизуються через організацію, на яку заявлений домен (Компанія А).

  Якщо ви помилково заявляєте про будь-які домени і вам потрібно видалити пре тензію, зверніться до статті Керування домен ами Webex.

Коди помилок кінцевого користувача

У наступній таблиці наведено коди помилок кінцевого користувача, які можна побачити на порталі активації користувача клієнта.

Коди помилок для синхронізації каталогів

Наступні коди помилок застосовуються до синхронізації каталогів.