Контроль якості викликів для CUCM за допомогою Tariscope

Cisco Unified Communications Manager (CUCM) генерує не лише детальні дані про виконані виклики (CDR записи), але і інформацію про якість викликів (Call Management Record – CMR). CMR записи зберігають інформацію про якість аудіо потоку, який був під час виклику. CDR записи пов'язані з CMR записами через 2-а параметра: Globalcallid_callmanagerid і Globalcallid_called.

CMR підтримуються лише для Cisco Unified IP Phones, телефонів серії Cisco 7960 і для шлюзів Media Gateway Control Protocol (MGCP) gateways. Якщо один з таких пристроїв бере участь у виклику, то CMR записи можуть генеруватися. Якщо ж у виклику беруть участь якісь інші кінцеві пристрої, то подібні записи не генеруються.

CMR записи в CUCM за умовчанням вимкнені. Якщо вони необхідні для аналізу, то треба їх включити. Як це зробити, описано в статті. В цьому випадку CUCM формуватиме окремі файли, які містять ці записи. Слід враховувати, що облік CMR записів вимагає додаткових процесорних витрат CUCM (дивіться таблицю 15 в [1]).

Для того щоб зрозуміти, яку інформацію адміністратор CUCM може отримати з CMR записів, розглянемо перелік полів (Таблиця 1), які ці записи містять [1].

Таблиця 1

Для оцінки якості передачі голосу представляють інтерес наступні поля: numberpacketslost (Кількість втрачених пакетів), jitter (Джиттер), latency (Затримка) і метрики з поля varVQMetrics.

Втрата пакетів

Втрачені пакети в IP-телефонії порушують мову і створюють спотворення тембру. За деякими даними вважається, що втрата до 5% пакетів непомітна, а понад 10-15% - неприпустима. Причому дані величини істотно залежать від алгоритмів компресії / декомпресії, а також від типу втрати пакетів. Наприклад, у розмові 1 втрати пакетів були в різні моменти розмови невеликими групами або одинично, при цьому сумарно втрачено 100 пакетів, а в розмові 2 втрати були двома блоками по 40 і 60 пакетів, тобто сумарно також втрачено 100 пакетів. Звичайно, що в розмові 1 втрата пакетів практично не позначиться на чіткість мовлення, в той час, як у другому випадку це буде помітно.

Існує два типи втрати пакетів:

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

• мережеві затори: у якийсь момент виникає дуже великий трафік, і маршрутизатор або інший мережевий пристрій приймає рішення по відкиданню деяких пакетів. Якщо мережевий пристрій підтримує механізми якості обслуговування (QOS), то відкидання пакетів виконується з врахуванням цього параметра.
• мережеві помилки: помилки з’єднання, викликані фізичним середовищем, можуть привести до втрати або пошкодження пакетів. А якщо пакет пошкоджений і не може бути відновлений, то він також буде відкинутий мережевим пристроєм. Дублювання пакетів між мережевими картами і комутаторами також можуть бути причиною втрати пакетів.

2. Втрати, обумовлені джиттером: VoIP телефон отримує пакет, але або занадто рано чи пізно, що призводить до його відкидання.

Джиттер

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

Коли телефон посилає голосовий пакет, він встановлює тимчасову мітку в заголовку RTP пакету. Телефон, що отримав голосовий пакет також генерує тимчасову мітку і порівнює її з тимчасовою міткою відправника пакету. Ці тимчасові мітки використовуються для обчислення девіації затримки або величини джиттера. Щоб згладити вплив джиттера на відтворений голос використовується буфер джиттера, куди потрапляють отримані пакети. Проте, дуже велике значення джиттера, що означає, що пакети прийшли або занадто рано або занадто пізно, призводить до того, що вони не потрапляють в цей буфер, а, отже, це призводить до втрати цих пакетів.

Джиттер призводить до специфічних порушень передачі мови, чутних як тріски і клацання. Розрізняють три форми джиттера:

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

Затримка

Затримка створює незручність при веденні діалогу, приводить до перекриття розмов і виникнення відлуння. Все це стає помітним, коли затримка в одному напрямку передачі перевищує 150 - 200 мс. Можна виділити наступні джерела затримки при передачі голосу через IP:

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

У Рекомендаціях МСЕ G.114 встановлений поріг затримки при передачі мови: не більше 150 мс. При величині затримки, що перевищує 250 мс, вважається, що людина відчуває помітний дискомфорт під час розмови.

Метрики поля varVQMetrics називаються в документації в Cisco Systems [3] як K-factor (К-коефіцієнти), які є усередненими оцінками розбірливості мови (mean opinion score — MOS), визначувані алгоритмом стандарту P.VTQ. Оцінки MOS представляють число обернено пропорційне до втрати пакетів, являє собою зважену оцінку роздратованості користувача із-за спотворень, викликаних втратою пакетів. Оцінка виставляється в межах від 1 до 5, як показано в Таблиці 2.

Таблиця 2

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

У Таблиці 3 перераховуються K - коефіцієнти, які зберігаються в CMR записах в полі varVQMetrics.

Таблиця 3

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

У різних джерелах існують кілька відмінних оцінок MOS для різних кодеків. Наведемо один з них [2] в Таблиці 4.

Таблиця 4

Виходячи з цих даних і використовуваного кодека, слід оцінювати роботу телефону. Наприклад, для кодека G.729 марно вимагати MOS вище 4.

Підтримка CMR в Tariscope

Cистема Tariscope підтримує обробку як CDR, так і CMR записів. І користувач системи може переглянути та проаналізувати ці дані з використанням відповідних звітів.

Для того щоб Tariscope обробляв CMR файли, необхідно в Tariscope, в настройках CUCM, клацнути по кнопці Налаштування та в меню, що з'явиться, вибрати Розширена настройка обробки CDR. У вікні Налаштування параметрів (Малюнок 1) встановити прапорець у позиції Зберігати всі поля.

Малюнок 1

Для перегляду та аналізу опрацьованих даних необхідно відкрити подання з даними викликів CUCM і на панелі інструментів клацнути по іконці Новий звіт. У дереві звітів виберіть папку CUCM. Зараз доступні наступні звіти:

• по джиттеру,
• по затримці,
• за втраченими пакетам,
• по К-коефіцієнтам,
• всі CMR параметри.

Звіт по джиттеру відображає CMR записи, які мають ненульове значення джиттера. Дані звіту впорядковані за телефонними номерами. Приклад такого звіту показаний на Малюнку 2.

Малюнок 2

Звіт по затримці відображає CMR записи, які мають ненульову затримку. Дані звіту впорядковані по даті, часу. Приклад такого звіту показаний на Малюнку 3.

Малюнок 3

Звіт за втраченими пакетам відображає тільки ті CMR записи, у яких значення втрачених пакетів не дорівнює нулю. Дані впорядковані за значенням втрачених пакетів. Приклад такого звіту наведено на Малюнку 4.

Малюнок 4

Звіт по К-коефіцієнтам відображає тільки ті CMR записи, у яких значення поля MLQKmn має значення менш ніж 4. Приклад такого звіту показаний на Малюнку 5.

Малюнок 5

Звіт за всіма параметрами CMR записів частково подібний до звіту по К-коефіцієнтам, але ще відображає значення джиттера, затримки і втрачених пакетів. Приклад такого звіту показаний на Малюнку 6.

Малюнок 6

Користувач Tariscope, використовуючи програму Дизайнер Звітів, може самостійно модернізувати кожний із зазначених вище звітів під свої потреби або створити власні форми звітів.

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

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

Посилання

1. Cisco Unified Communications Manager. Call Detail Records Administration Guide. Release 10.0(1).

2. Mean opinion score.

Додаткова інформація

Налаштування Tariscope для використання функції обмеження з CUCM

Створення спеціальних форм звітів для CUCM

Обробка CDR з CUCM в Tariscope

Коди завершення викликыв в CUCM

Функції редакції Tariscope Enterprise

Функції редакції Tariscope Provider

Рішення на основі Tariscope