Огляд

Щоб визначити ймовірну причину, рекомендується використовувати вікно усунення несправностей разом із сукупною інформацією, отриманою з інформаційної панелі <span data-id ="0"></span>Webex Calling Analytics <span data-id ="1"></span>. Використовуйте інформаційну панель Webex Calling Analytics, щоб переглянути проблеми, що впливають на кількох користувачів із спільною причиною, пов 'язаною з місцезнаходженням, мережею тощо; тоді як вікно усунення несправностей Webex Calling може виявити проблеми з окремими викликами.

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

Адміністратори можуть шукати за наступними критеріями, щоб отримати список дзвінків, для яких використовувався сеанс мультимедіа, принаймні з однією зареєстрованою кінцевою точкою <span data-id ="0"></span>Webex Calling<span data-id ="1"></span>:

  • Ідентифікатори електронної пошти

  • Номери телефонів (точна відповідність рядків)

  • MAC-адреса

  • Ідентифікатори викликів

Усунення несправностей, пов 'язаних з якістю медіа, дозволяє адміністраторам:

  • Переглянути наскрізний досвід учасників дзвінка.

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

  • Перегляньте, чи проходить медіа через хмару викликів Webex або безпосередньо між користувачами (за допомогою Interactive Connectivity Establishment (ICE)).

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

  • Перегляд дзвінків за останні 21 день.

  • Проаналізуйте показники якості дзвінків, які вплинули на досвід користувача. Наприклад, адміністратор може спостерігати високий джиттер на клієнтах через мережі Wi-Fi, але втрата пакетів і затримка можуть бути прийнятними.

  • Визначте, чи є проблема з абонентом або замовником.


Усунення несправностей, пов 'язаних з якістю медіа, застосовується лише для сеансів медіа, і в ньому не відображаються сеанси сигналізації викликів. Наприклад, Алекс викликає Боба, який налаштував CFA (Call Forward All), до Крістіни, і Крістіна відповіла на дзвінок. У цьому сценарії погляд на усунення несправностей у медіа показує, що дзвінок відбувся між Алексом та Крістіною, оскільки основна увага приділяється усуненню несправностей у медіа, а не потоку сигналів або життєвому циклу дзвінка.

Виклики, що використовують Webex Calling<span data-id ="1"></span>, з 'являються після завершення виклику.

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

  • Наскрізний досвід користувача.

  • Перегляд Hop Details (Подробиці переходу).

  • Надсилайте або отримуйте показники від користувача або медіарелейного пункту.

  • Незалежно від того, чи дзвінок відбувся до зовнішньої мережі або з неї, або між зареєстрованими кінцевими точками <span data-id ="0"></span>Webex Calling<span data-id ="1"></span>.

Підтримувані потоки дзвінків

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

  • Абонент або замовник

  • Шлях медіа до хмари <span data-id = "0"></span>Webex Calling<span data-id = "1"></span> або з неї.


Ноги виклику з 'являються, якщо під час сеансу мультимедіа було встановлено принаймні одну зареєстровану кінцеву точку <span data-id = "0"></span>Webex Calling<span data-id = "1"></span> під час виклику. Наприклад, для вихідного дзвінка від мисливської групи до восьми агентів, якщо лише один агент відповідає, то для інших семи агентів немає медіадосвіду для усунення несправностей.

Існує п 'ять типів мультимедійного досвіду або шляхів для усунення несправностей <span data-id = "0"></span>Webex Calling<span data-id ="1"></span>, а саме:

  • On-net Optimized – дзвінки всередині організації, де ICE успішно працює, а медіафайли передаються безпосередньо між користувачами. Див. Webex Calling Media Optimization with Interactive Connectivity Establishment (ICE) для отримання детальної інформації.

  • In-net Unoptimized – дзвінки всередині організації, де встановлення інтерактивного зв 'язку (ICE) було неможливим або неможливим. У цьому сценарії медіа протікає через хмару викликів Webex.

  • Хмарний хостинг в мережі – дзвінки всередині організації, де медіафайли надаються медіасервером, розміщеним у хмарі (наприклад, прослуховування голосової пошти, набір до автосекретаря).

  • Виклик поза мережею до або з зареєстрованої кінцевої точки Webex Calling -

    • через постачальника послуг хмарного зв 'язку PSTN - вхідні та вихідні дзвінки організації, де інша сторона знаходиться в мережі PSTN. Носій передається через постачальника PSTN, підключеного до хмари (CCPP), за допомогою високоякісного міжмережевого з 'єднання.

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


Якщо є 1 або 2 зареєстрованих користувача Webex Calling, які беруть участь у дзвінку "точка-точка" в мережі, то у вікні усунення несправностей відображаються показники для однієї або обох сторін. Якщо виклик вимкнено (користувач 1 отримує виклик від користувача PSTN), то у вікні усунення несправностей відображаються лише клієнтські показники користувача User1, а також показники, взяті з точки ретрансляції медіа.

Більшість сценаріїв дзвінків у вікні усунення несправностей показують два етапи дзвінка (абонент та замовник); однак деякі сценарії дзвінків (наприклад, паркування або отримання дзвінка) показують лише один етап дзвінка. У таких випадках інша нога виклику відображається окремо у вікні усунення несправностей. Це не перешкоджає усуненню несправностей під час виклику та виявленню місця виникнення проблеми. Однак він вимагає, щоб адміністратор вручну співвідносив дві ножки виклику, використовуючи загальну сутність, таку як час перекриття. Майбутні вдосконалення вікна усунення несправностей усунуть необхідність використання ручного пошуку.

Доступ до вікна <spandata-id ="0"></span>Webex Calling усунення несправностей

Щоб проаналізувати виклик Webex, виконайте наведені нижче дії.

1.

У перегляді клієнта в розділі <span data-id ="0"></span><span data-id ="1"></span><span data-id ="2"></span> перейдіть до розділу <span data-id ="3"></span>Моніторинг <span data-id ="4"></span> > <span data-id ="5"></span>Усунення несправностей<span data-id ="6"></span>.https://admin.webex.com/

2.

Виберіть <span data-id ="0"></span>Зустрічі та дзвінки<span data-id ="1"></span>, а потім знайдіть ідентифікатор електронної пошти користувача або пристрою, номер телефону (точну відповідність рядка), MAC-адресу користувача або пристрою або ідентифікатори дзвінків етапу дзвінка, який потрібно переглянути.

Відображає інформацію про всі дзвінки та зустрічі, пов 'язані з пошуком.


 

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

3.

Дзвінки Webex оцінюються за якістю. Однак для зустрічей Webex або сеансів Call on Webex ця оцінка не застосовується. Враження від дзвінка оцінюється як:

  • Погано – вказує на те, що або абонент, або замовник мали поганий наскрізний досвід (наприклад, нестабільний аудіосигнал).
  • Добре – вказує на наскрізний досвід для абонента, а зателефонований не перевищив порогових значень.
  • Немає– стосується зустрічей або сеансів Call on Webex.
  • Недоступно– стосується зустрічей або сеансів Call on Webex.
4.

Натисніть певний дзвінок у перегляді оголошення, щоб переглянути подробиці Hop. У вікні Hop Detail відображаються:

У розділі "Подробиці Hop" ви можете:

  • Перегляньте аналітичні дані про дзвінок в одному або обох цих сценаріях:

    • Не було жодного засобу масової інформації для будь-якого з хмелів, пов 'язаних із дзвінком

    • Налаштування оптимізації шляху було невдалим.

  • Наведіть курсор на пристрій, щоб переглянути наскрізні дзвінки.

  • Наведіть курсор на перехід між кінцевою точкою та хмарою Webex Calling<span data-id ="1"></span>, щоб переглянути подробиці переходу.

Досвід наскрізних дзвінків ґрунтується на даних якості мультимедійних даних, які збираються з кожної зареєстрованої кінцевої точки <span data-id ="0"></span>Webex Calling<span data-id ="1"></span> (додаток Webex або пристрій, наприклад 8865) наприкінці дзвінка. Виклик оцінюється як хороший, якщо він відповідає таким пороговим значенням:
  • Втрати пакетів менше 5%

  • Затримка або час відправлення в обидва кінці (RTT) менше 400 мс

  • Дрожіння менше 150 мс

Якість хопу походить від даних, які збираються з точки ретрансляції медіа в хмарі Webex Calling. Для викликів PSTN через CCPP або локальний шлюз збір даних здійснюється з хмари викликів Webex, а не з кінцевої точки PSTN. Хміль оцінюється як хороший, якщо він задовольняє ці порогові значення.

  • Втрата пакетів менше 2,5%.

  • Латентність або RTT менше 200 мс.

  • Дрожіння менше 75 мс.


 

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

Ми рекомендуємо використовувати вигляд усунення несправностей окремих викликів із сукупною інформацією, отриманою з <span data-id ="0"></span>Analytics<span data-id ="1"></span>.

Давайте проаналізуємо якість виклику для різних типів викликів за допомогою вікна усунення несправностей.

Дзвінки всередині організації, де ICE успішний, а медіа-реле в хмарі видаляється з шляху. Медіапотік відбувається безпосередньо між пристроями користувача.

Висновок:

1.

Дзвінок оцінюється так само добре, як і той, хто дзвонить, і той, хто дзвонить, мають хороший наскрізний досвід.

2.

Адміністратор може спостерігати, що медіапотоки проходять безпосередньо між двома користувачами і не проходять через хмару викликів Webex.


 

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

Дзвінки всередині організації, де виклик ICE не є успішним, і медіа протікають через хмару Webex Calling.

Висновок:

Адміністратор може спостерігати за наступним:

1.

Наскрізний досвід абонента оцінюється як поганий.

2.

Існує проблема з мережевим переходом абонента, яка впливає як на потік надсилання, так і на потік отримання.

3.

Мережевий стрибок замовника не має проблем.

4.

Наскрізний досвід замовника оцінюється як поганий через проблему з абонентом.

Дзвінки всередині організації, де медіа забезпечується медіа-сервером, розміщеним у хмарі.

Висновок:

Дзвінок оцінюється так само добре, як і наскрізний досвід абонента в межах прийнятих порогових значень. Адміністратор може помітити, що:

1.

Мережевий стрибок для абонента оцінюється як поганий, оскільки деякі показники перевищують прийнятний поріг.

2.

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

3.

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

4.

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

Дзвінки в організацію та з організації, де інша сторона знаходиться в мережі PSTN. Носій передається від постачальника PSTN, підключеного до хмари (CCPP).

У прикладі клієнтські медіа надходять від постачальника ТСОП через хмару.

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

1.

Проблема пов 'язана з переходом PSTN абонента, зокрема, з потоком надсилання.

2.

Мережевий стрибок замовника не має проблем.

3.

Наскрізний досвід замовника оцінюється як поганий через проблему з абонентом.

4.

Кінцеві показники та показники потоку отримання абонента, який перебуває в мережі PSTN, наразі недоступні, оскільки ці показники не передаються до хмари дзвінків Webex.

Дзвінки в організацію та з організації, де медіа абонента надходять з підприємства. Медіасесія може бути від користувача, розміщеного на підприємстві (наприклад, зареєстрованого в UCM), або від PSTN, де PSTN надається через підприємство.

Висновок

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

1.

Існує проблема з переходом абонента до хмари викликів Webex як на потоці надсилання, так і на потоці отримання.

2.

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

3.

Вхідний трафік до хмари дзвінків Webex з кінця виклику оцінюється як хороший.

4.

Показники наскрізного досвіду та потоку отримання виклику, який викликається з локального шлюзу, наразі недоступні, оскільки ці показники не передаються до хмари викликів Webex.

Усунення проблеми з якістю медіа

Перегляд "хміль за хмелем" допоможе вам визначити місце виникнення проблеми. Тепер, коли ви знайшли причину проблеми та ознайомилися з показниками (джиттер, втрата пакетів, затримка), ви можете спробувати виконати наведені нижче дії, щоб усунути проблему.

Типовими можливостями для проблем зі ЗМІ є:

  • Проблеми, пов 'язані з мережею/інтернет-провайдером/місцезнаходженням <span data-id ="0"></span> - через брандмауер, конфігурацію мережі або пропускну здатність існує шаблон поганого досвіду в певному місці або підмережі мережі. Використовуйте перегляд усунення несправностей для кожного виклику (визначте місцезнаходження, пов 'язане з поганою сесією) з переглядом аналітики, щоб переглянути сукупні шаблони для місцезнаходження.

  • Специфічні для користувача проблеми<span data-id ="0"></span> - користувач або пристрій підключений до поганої мережі (наприклад, Wi-Fi або працює з дому), що означає, що на їх роботу впливають пов 'язані з мережею можливості. Див. статтю Use CScan to Test Webex Calling Network Quality<span data-id ="1"></span>, щоб визначити проблему з мережею.

  • Проблеми, пов 'язані з типом виклику <span data-id ="0"></span> - поганий досвід користувача пов' язаний з якістю на дальньому кінці. Це характерно для сценаріїв PSTN, коли користувач розмовляє з іншим користувачем у мобільній мережі, а сеанс має високу втрату пакетів у мережі PSTN.

  • Проблема з відсутністю медіафайлів <span data-id = "0"></span>- у деяких стрибках може не бути передачі медіафайлів. Банер Insights відображає причину у верхній частині сторінки відомостей про хміль та відповідальну сторону в інформаційному полі сторінки відомостей про хміль. Деякі з можливих причин відсутності засобів масової інформації в дзвінках разом з відповідальними сторонами перераховані тут:

    • Webex не отримує медіафайли від відправника.

    • Webex не отримує медіафайли від приймача.

    • Webex не отримує медіа з будь-якого напрямку.

    • Webex не надсилає медіа на приймач. Компанія Webex Engineering вирішує цю проблему.

    • Webex не отримує медіафайли з Cloud PSTN. Компанія Webex Engineering вирішує цю проблему.

    • Webex не отримує медіафайли від хмарного сервісу. Компанія Webex Engineering вирішує цю проблему.

    • Webex не отримує медіафайли з локального шлюзу. Адміністратор клієнта повинен розслідувати проблему.

  • Помилка оптимізації мультимедійного шляху - Кілька викликів не можуть успішно налаштувати оптимізацію мультимедійного шляху. Банер Insights відображає причину невдалих дзвінків ICE та роздільну здатність у верхній частині сторінки подробиць Hop.

    Деякі з можливих причин

    • ICE не вдалося через доступ до сервера STUN - див. Довідкову інформацію порту виклику Webex

    • ICE не вдалося через перевірку зв 'язку - перевірте зв' язок між мережами

    • ICE не вдалося, оскільки час поїздки туди і назад за замовчуванням був подібним/кращим, ніж будь-який оптимізований шлях

Умовні позначення у вікні пошуку та усунення несправностей

Перегляньте наведені нижче подробиці дзвінка на правій панелі перегляду "хід за хопом".

Строк Визначення
Тата виклику Дата здійснення дзвінка.
Час виклику Час початку та завершення дзвінка відображається у часовому поясі, який ви вибрали у вікні пошуку.
Тип сеансу

Тип сеансу, який підтримується. Наприклад: Webex Call

учасники; Кількість учасників, які приєдналися до дзвінка.
Ім’я абонента, який телефонує Ім 'я абонента.
Електронна пошта абонента, який телефонує Електронна адреса абонента.
Номер абонента, який телефонує Номер телефону, який абонент використовував під час дзвінка.
Аудіо Тип використовуваного аудіо.
Відео Відображає Yes (Так), якщо відео ввімкнено учасником. Якщо відео взагалі не ввімкнено, відображається напис "Ні".
Оптимізація маршруту

Вказує, чи застосовується оптимізація шляху виклику до виклику. Прийняті значення:

ICE (встановлення інтерактивного зв 'язку)

PNC (підключення до приватної мережі).

Без оптимізації

Тип виклику

Тип виклику може бути одним з таких:

Екстрена служба

Enterprise

Міжнародні

Мобільний пристрій

Національний

Оператор

Premium

Шорткод

Безкоштовно

Невідомо

URI

Перегляньте ці показники дзвінків у режимі перегляду "хід за ходом":

Строк Визначення
Кінцевий пристрій

Відображає одне з наступного:

  • Настільний телефон для фізичної кінцевої точки.

  • Програма Webex

Апаратне забезпечення

Відображає одне з наступного:

  • Інформація про модель настільних телефонів для фізичної кінцевої точки.

  • "-" для додатка Webex

Розташування

Розташування виклику Webex, налаштоване для користувача.

Локальна IP-адреса

Локальна IP-адреса клієнта для мережевого інтерфейсу, що використовується для передачі медіа.

Загальнодоступна IP-адреса

Це публічна IP-адреса клієнта, яку бачить хмара. Для підприємств це адреса брандмауера, що забезпечує NAT.

MAC-адреси

MAC-адреса кінцевої точки клієнта.

Геолокація

Геопошук публічної IP-адреси. Ця адреса не є точною, якщо вона підключена через PNC. Якщо користувач використовує додаток Webex і підключається до підприємства через VPN, місцезнаходження не є точним.

Інтернет-провайдер

Інтернет-провайдер, який забезпечує мережеве підключення до хмари дзвінків Webex.

Мережа

Тип мережевого з 'єднання, яке клієнт використовував для обміну носіями. Можливі значення:

  • Wi-Fi

  • Ethernet

  • Стільниковий зв 'язок

  • Невідомо

Аудіокодек

(Надсилання або отримання) Формат кодування та декодування медіа, що використовується для медіа, які передаються клієнтом.

Відеокодек

(Надсилання або отримання) Формат кодування та декодування медіа, що використовується для медіа, які передаються клієнтом. Застосовується лише для відеодзвінка.

Ідентифікатор виклику

Внутрішній ідентифікатор, який використовується для ідентифікації етапу виклику.


Деякі показники маскуються на знімках екрана статті, щоб зберегти ідентичність користувача.

Обмеження

Показники якості медіа недоступні на наведених нижче пристроях.

  • Аналогові телефони

  • Сторонні пристрої

  • Кінцеві точки IPv6