Контроль якості викликів для 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
|
Назва поля |
Тип поля |
Опис |
|
globalCallID_callManagerId |
Позитивне ціле |
Визначає унікальний ідентифікатор для CUCM. Це поле є половиною поля Global Call ID, яке включає: |
|
globalCallId_callId |
Позитивне ціле |
Визначає унікальний ідентифікатор для кожного виклику. CUCM призначає цей ідентифікатор незалежно для кожного сервера викликів. Величини ідентифікаторів вибираються послідовно, коли починається виклик. Значення призначається для кожного успішного або неуспішного виклику, Це поле являє собою половину поля Global Call ID, яке включає в себе: Усі записи, які пов'язані зі стандартним викликом, мають той же GlobalCallID. За умовчанням це поле завжди має бути заповненим. |
|
nodeId |
Позитивне ціле |
Поле визначає сервер або вузол усередині кластера CUCM, де був згенерований запис. За умовчанням це поле завжди має бути заповненим. |
|
callIdentifier |
Позитивне ціле |
Поле визначає гілку виклику, до якої запис відноситься. |
|
directoryNumber |
Ціле |
Визначає телефонний номер пристрою, з якого збирається інформація. За умовчанням це поле завжди має бути заповненим. |
|
dateTimeStamp |
Ціле |
Дата і час формування запису. За умовчанням це поле завжди має бути заповненим. |
|
numberPacketsSent |
Ціле |
Вказує кількість RTP пакетів, які послав пристрій з початку з'єднання. Матиме 0, якщо з'єднання було встановлено в режим "тільки для отримання". За умовчанням: 0. |
|
numberOctetsSent |
Ціле |
Вказує загальне число байт, яке пристрій послав в складі RTP пакетів. Поле матиме 0, якщо з'єднання було встановлено в режим "тільки для отримання". За умовчанням: 0. |
|
numberPacketsReceived |
Ціле |
Вказує кількість RTP пакетів, яке отримав пристрій з початку з'єднання. Поле матиме 0, якщо з'єднання було встановлено в режим "тільки для відправки". За умовчанням: 0. |
|
numberOctetsReceived |
Ціле |
Вказує загальне число байт, яке пристрій одержав у складі RTP пакетів. Поле матиме 0, якщо з'єднання було встановлено в режим "тільки для відправки". За умовчанням: 0. |
|
numberPacketsLost |
Ціле |
Поле визначає загальне число RTP пакетів, які були втрачені з початку їх прийому. Ця величина визначається як різниця числа очікуваних пакетів і числа реально отриманих пакетів, яке включає всі пакети, що запізнилися і продубльовані. Таким чином, пакети, що запізнилися, не вважаються втраченими, і значення цього параметра може бути негативним, якщо мале місце продубльовані пакети. Поле матиме 0, якщо з'єднання було встановлене в режим "тільки для відправки". За умовчанням: 0. |
|
jitter |
Ціле |
Це поле містить оцінку статистичної дисперсії часу прибуття RTP пакетів, виміряне в мілісекундах і яке виражається як ціле число без знаку. RFC 1889 містить детальні алгоритми обчислень джиттера. Поле матиме 0, якщо з'єднання було встановлене в режим "тільки для відправки". За умовчанням: 0. |
|
latency |
Ціле |
Це поле визначає величину, яка дозволяє оцінити мережеву затримку, виражену в мілісекундах. Значення цього поля представляє середню величину між часом RTCP повідомлень і часом здобуття приймачами цих повідомлень. CUCM обчислює середнє значення, підсумовуючи всі оцінки і потім ділячи їх на число RTCP повідомлень, які були отримані. Більш детальну інформацію дивіться в RFC 1889. Значення за умовчанням — 0. Примітка. CMR записи не показують затримку для всіх прошивок телефонів. Наприклад, для SIP 9.2.1 і 9.2.2 затримка не відображатиметься, так як її обчислення не реалізовано в цих прошивках. |
|
pkid |
Текст |
Поле відображає текстовий рядок, яку база даних використовує для унікальної ідентифікації кожного рядка. Система завжди заповнює це поле. |
|
directoryNumberPartition |
Текст |
Це поле відображає сегмент (partition), в який входить телефонний номер. Значення за умовчанням — порожній рядок, "". Поле може залишатися порожнім. |
|
deviceName |
Текст |
Поле відображає ім'я пристрою. Значення за умовчанням — порожній рядок, "". Поле може залишатися порожнім. |
|
globalCallId_ClusterId |
Текст |
Це поле відображає унікальний ідентифікатор для одиничного CUCM або для кластера Cucm-ов. |
|
varVQMetrics |
Текст |
Це поле містить змінне число метрик якості голосу. |
Для оцінки якості передачі голосу представляють інтерес наступні поля: numberpacketslost (Кількість втрачених пакетів), jitter (Джиттер), latency (Затримка) і метрики з поля varVQMetrics.
Втрата пакетів
Втрачені пакети в IP-телефонії порушують мову і створюють спотворення тембру. За деякими даними вважається, що втрата до 5% пакетів непомітна, а понад 10-15% - неприпустима. Причому дані величини істотно залежать від алгоритмів компресії / декомпресії, а також від типу втрати пакетів. Наприклад, у розмові 1 втрати пакетів були в різні моменти розмови невеликими групами або одинично, при цьому сумарно втрачено 100 пакетів, а в розмові 2 втрати були двома блоками по 40 і 60 пакетів, тобто сумарно також втрачено 100 пакетів. Звичайно, що в розмові 1 втрата пакетів практично не позначиться на чіткість мовлення, в той час, як у другому випадку це буде помітно.
Існує два типи втрати пакетів:
1. Втрати обумовлені мережею: одержувач пакетів не отримав їх оскільки вони були втрачені в мережі між відправником і одержувачем. Причин для втрати пакетів в мережі існує безліч, але найчастіше зустрічається два варіанти:
- мережеві затори: у якийсь момент виникає дуже великий трафік, і маршрутизатор або інший мережевий пристрій приймає рішення по відкиданню деяких пакетів. Якщо мережевий пристрій підтримує механізми якості обслуговування (QOS), то відкидання пакетів виконується з врахуванням цього параметра.
- мережеві помилки: помилки з’єднання, викликані фізичним середовищем, можуть привести до втрати або пошкодження пакетів. А якщо пакет пошкоджений і не може бути відновлений, то він також буде відкинутий мережевим пристроєм. Дублювання пакетів між мережевими картами і комутаторами також можуть бути причиною втрати пакетів.
2. Втрати, обумовлені джиттером: VoIP телефон отримує пакет, але або занадто рано чи пізно, що призводить до його відкидання.
Джиттер
Коли мова або дані розбиваються на пакети для передачі через IP-мережу, пакети часто прибувають в пункт призначення в різний час і в різній послідовності. Це створює розкид часу доставки пакетів (джиттер).
Коли телефон посилає голосовий пакет, він встановлює тимчасову мітку в заголовку RTP пакету. Телефон, що отримав голосовий пакет також генерує тимчасову мітку і порівнює її з тимчасовою міткою відправника пакету. Ці тимчасові мітки використовуються для обчислення девіації затримки або величини джиттера. Щоб згладити вплив джиттера на відтворений голос використовується буфер джиттера, куди потрапляють отримані пакети. Проте, дуже велике значення джиттера, що означає, що пакети прийшли або занадто рано або занадто пізно, призводить до того, що вони не потрапляють в цей буфер, а, отже, це призводить до втрати цих пакетів.
Джиттер призводить до специфічних порушень передачі мови, чутних як тріски і клацання. Розрізняють три форми джиттера:
- Джиттер, залежний від даних: відбувається у випадку обмеженої смуги пропускання або при порушеннях мережевих компонентах.
- Спотворення робочого циклу: обумовлено затримкою розповсюдження.
- Випадковий джиттер: є результатом теплового шуму.
Затримка
Затримка створює незручність при веденні діалогу, приводить до перекриття розмов і виникнення відлуння. Все це стає помітним, коли затримка в одному напрямку передачі перевищує 150 - 200 мс. Можна виділити наступні джерела затримки при передачі голосу через IP:
- Затримка пакетизації: обумовлена часом, який потрібен на кодування, декодування переданого голосу.
- Затримка черги: обумовлена часом затримки пакетів у чергах для їх обробки в комутаторах, маршрутизаторах.
- Затримка серіалізації: це час, який потрібний для передачі пакета в мережевий інтерфейс. Величина цієї затримки тим більше, чим більше величина пакету.
- Затримка розповсюдження: це час, який потребується для передачи пакета по мережі. Ця затримка може бути пов’язана з географічною віддаленістю учасників розмови.
- Затримка джиттера буферу: час знаходження пакету в буфері джиттеру.
У Рекомендаціях МСЕ G.114 встановлений поріг затримки при передачі мови: не більше 150 мс. При величині затримки, що перевищує 250 мс, вважається, що людина відчуває помітний дискомфорт під час розмови.
Метрики поля varVQMetrics називаються в документації в Cisco Systems [3] як K-factor (К-коефіцієнти), які є усередненими оцінками розбірливості мови (mean opinion score — MOS), визначувані алгоритмом стандарту P.VTQ. Оцінки MOS представляють число обернено пропорційне до втрати пакетів, являє собою зважену оцінку роздратованості користувача із-за спотворень, викликаних втратою пакетів. Оцінка виставляється в межах від 1 до 5, як показано в Таблиці 2.
Таблиця 2
|
Оцінка MOS |
Якість розбірливості мови |
|
5 |
відмінно |
|
4 |
добре |
|
3 |
задовільно |
|
2 |
погано |
|
1 |
дуже погано |
Ці оцінки ґрунтуються на мовних зразках великого числа мовних баз даних, де кожен тренувальний зразок має тривалість 8 секунд. Для точнішої оцінки якості мови система формує оцінки кожні 8 секунд активної телефонної розмови, які потім можуть усереднюватися.
У Таблиці 3 перераховуються K - коефіцієнти, які зберігаються в CMR записах в полі varVQMetrics.
Таблиця 3
|
Назва поля |
Повна назва |
Опис |
|
CCR |
Cumulative Conceal Ratio |
Коефіцієнт, рівний відношенню часу, який використовується на маскування, до загального часу розмови. |
|
ICR |
Interval Conceal Ratio |
Представляє інтервальний усереднений коефіцієнт маскування (приховування), рівний відношенню часу, який використовується на маскування, до часу розмови попередньому 3-х секундному інтервалі активного розмови. |
|
ICRmx |
Max Conceal Ratio |
Відображає максимальний коефіцієнт маскування, який спостерігався протягом розмови. |
|
CS |
Conceal Secs |
Відображає час, протягом якого спостерігалося маскування втрачених пакетів протягом розмови. |
|
SCS |
Severely Conceal Secs |
Відображає час в секундах, протягом якого спостерігалося маскування втрачених пакетів. |
|
MLQK |
MOS LQK |
Оцінка розбірливості мови за останні 8 секунд розмови на стороні приймача. |
|
MLQKmn |
Min MOS LQK |
Мінімальне значення оцінки розбірливості мови, яке спостерігалося з початку розмови, розбитого на 8-и секундні інтервали часу. |
|
MLQKmx |
Max MOS LQK |
Максимальне значення оцінки розбірливості мови, яке спостерігалося з початку розмови, розбитого на 8-и секундні інтервали часу. |
|
MLQKav |
Avg MOS LQK |
Середнє значення оцінки розбірливості мови, яке спостерігалося з початку розмови, розбитого на 8-и секундні інтервали часу. |
Слід розуміти, що оцінка роботи мережі, заснована на K-factor і MOS можливо більш наочна, але носить вторинний характер, оскільки дозволяє виявити проблеми з мережею тільки тоді, коли вони стають істотними. А ось облік кількості прийнятих (втрачених) пакетів, співвідношення приховування пакетів, затримка, джиттер є первинними статистичними даними і дозволяють адміністратору мережі виявляти проблеми з нею до того, як вони будуть робити істотний вплив на якість розмов.
У різних джерелах існують кілька відмінних оцінок MOS для різних кодеків. Наведемо один з них [2] в Таблиці 4.
Таблиця 4
|
Кодек |
Необхідна полоса, кбіт/сек |
MOS |
|
G.711 (ISDN) |
64 |
4,1 |
|
iLBC |
15,2 |
4,14 |
|
AMR |
12,2 |
4,14 |
|
G.729 |
8 |
3,92 |
|
G.723.1 r63 |
6,3 |
3,9 |
|
GSM ERF |
12,2 |
3,8 |
|
G.726 ADPCM |
32 |
3,85 |
|
G.729a |
8 |
3,7 |
|
G.723.1 r53 |
5,3 |
3,65 |
|
G.728 |
16 |
3,61 |
|
GSM FR |
12,2 |
3,5 |
Виходячи з цих даних і використовуваного кодека, слід оцінювати роботу телефону. Наприклад, для кодека 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).
Додаткова інформація
Налаштування Tariscope для використання функції обмеження з CUCM
Створення спеціальних форм звітів для CUCM
Обробка CDR з CUCM в Tariscope
Коди завершення викликыв в CUCM
Функції редакції Tariscope Enterprise
Функції редакції Tariscope Provider
Рішення на основі Tariscope
Особливості обробки CDR від CUCM в Tariscope
Система Tariscope (SoftPI) дозволяє збирати, обробляти і аналізувати дані про виконані виклики через різні телефонні системи, включаючи і голосове обладнання компанії Cisco Systems, таке як Cisco Unified Communications Server (CUCM).
Зміст
Переваги використання Tariscope для аналізу CDR від CUCM
Конфігурація CDR параметров в CUCM
Налаштування Tariscope для збору та обробки CDR, CMR файлів
Аналіз даних
Контроль якосты виклику
Створення спеціальних форм звітів
Управління бюджетом на телефонні розмови
Тестування та придбання Tariscope
Посилання
Переваги використання Tariscope для аналізу CDR від CUCM
Опис переваг використання Tariscope для аналізу інформації про виклики від CUCM можна знайти в статті.
Конфігурація CDR параметрів в CUCM
CUCM формує CDR інформацію, яка записується в CDR файли. Це - текстові файли, найменування яких представляється в наступному вигляді:
тип_кластер_вузол_час_номер, де:
- тип – вказує на тип файлу: CDR або CMR (Call Management Record - записи для адміністрування виклику);
- кластер – ідентифікує кластер або сервер, де розташована база даних CUCM;
- вузол – идентифицирует узел;
- час - Всесвітній координований час (UTC) у форматі РРРРММДДЧЧММ (РРРР - рік, ММ - місяць, ДД - день, ГГ - година, ММ - хвилина);
- номер – послідовний номер запису.
Приклади імен файлів:
cdr_StandAloneCluster_01_201602111456_55
cmr_StandAloneCluster_01_201602111456_237
CUCM може посилати одночасно CDR файли максимально на три білінгові сервери, використовуючи FTP або SFTP протоколи. Відправкою займається в CUCM служба CDR Repository Manager. Для налаштування основних параметрів цієї служби виберіть режим Cisco Unified Serviceability (малюнок 1).
Малюнок 1
Виконайте наступні дії:
Крок 1. Виберіть Tool → CDR Management. З'явиться вікно CDR Management.
Крок 2. Клацніть по параметру, який бажаєте змінити.
Крок 3. Введіть необхідні значення, відповідно до інформації Таблиці 1.
Крок 4. Клацніть Update.
Таблиця 1
| Поле | Опис |
| Disk Allocation (MB) |
Виберіть число мегабайт, яке ви хочете розподілити для зберігання CDR і CMR файлів. Цей розмір і величина за замовчуванням істотно залежать від розміру жорсткого диска сховища. Однак, максимальний розмір становить 6 Гбайт. |
| High Water Mark (%) |
Це поле визначає максимальний відсоток розподіленого дискового простору під CDR, CMR файли. Наприклад, в параметрі Disk Allocation задано 2000 Мбайта, а в High Water Mark - 80%, це означає, що верхня межа буде складає 1600 Мбайт. Коли зайнятий дисковий простір досягне заданої в цій позиції величини, і якщо не встановлено прапор в позиції Disable CDR / CMR Files Deletion Based on HWM, то система автоматично видалить все успішно передані CDR і CMR файли, починаючи з найбільш старих файлів до рівня, заданого в позиції Low Water Mark. |
| Low Water Mark (%) | Це поле задає відсоток дискового простору, яке розподіляється для CDR і CMR файлів, і яке завжди доступно для використання. |
| CDR/CMR Files Preservation Duration (Days) | Здається число днів, протягом яких будуть зберігатися CDR, CMR файли. Менеджер CDR сховища буде видаляти файли, які будуть перевищувати зазначену в цій позиції число днів. |
| Disable CDR/CMR Files Deletion Based on HWM | Если вы желаете, чтобы CDR файлы не удалялись даже после того, как будет достигнут верхний предел (High Water Mark – HWM), установите флаг в этой позиции. По умолчанию эта позиция неактивна. |
| CDR Repository Manager Host Name | Вкажіть ім'я хоста для сервера сховища (CDR Repository Manager). |
| CDR Repository Manager Host Address | Вкажіть IP адреса для сервера сховища. |
Для налаштування відправки CDR файлів на конкретний білінговий сервер, необхідно виконати наступні дії:
Крок 1. Виберіть в меню Tools → CDR Management. З'явиться вікно CDR Management.
Крок 2. Виконайте один з варіантів:
- додайте новий білінговий сервер, натиснувши кнопку Add New (малюнок 1), з'явиться вікно (малюнок 2);
- поновіть параметри раніше заданого біллінгового сервера, клацнувши по імені сервера або його IP адреси.
Крок 3. Введіть необхідні параметри, які описані в таблиці 2.
Крок 4. Переконайтеся, що FTP сервер, до якого буде підключатися налаштований FTP клієнт працює. Якщо FTP сервер недоступний, то зберегти введені дані не вдасться, так як перед їх збереженням перевіряється наявність з'єднання з FTP сервером. Клацніть Add (при додаванні) або Update (при оновленні даних).
Малюнок 2
Таблиця 2
| Поле | Опис |
| Host Name/IP Address | Введіть ім'я або IP адресу біллінгового сервера, на який збираєтеся посилати CDR файли. |
| User Name | Введіть ім'я користувача біллінгового сервера. |
| Password | Введіть пароль для доступу на FTP сервер біллінгового сервера. |
| Protocol | Виберіть протокол або FTP, або SFTP, який ви хочете використовувати для пересилки CDR файлів. |
| Directory Path | Введіть шлях до папки на білінговому сервері, куди потрібно буде пересилати CDR файли. Наприкінці зазначеного шляху необхідно ввести символ "\" або "/", в залежності від операційної системи. |
| Resendon Failure | Встановлення прапорця в цій позиції означає, що при розриві зв'язку, а потім її відновлення, CDR файли будуть передані на білінговий сервер. |
| Generate New Key | Клацніть по кнопці Reset для генерації нових ключів і скидання з'єднання з SFTP сервером. |
Далі слід налаштувати CDR параметри. Для цього в Cisco Unified Communications Manager Administration оберіть System → Enterprise Parameters:
- CDR File Time Interval – визначає часовий інтервал для збору CDR даних. Якщо, наприклад, задана величина 1, то кожен CDR файл буде містити дані за 1 хвилину. Значення за замовчуванням: 1. Мінімальне значення - 1, максимальне - 1440. Якщо ви бажаєте якомога частіше отримувати CDR дані, залиште значення за замовчуванням. Збільшення цього значення буде означати, що ви не зможете отримати CDR дані раніше, ніж закінчиться час, відповідний встановленному значенню.
- Cluster ID – це параметр, що забезпечує унікальний ідентифікатор для кластера. Використання цього параметра важливо при зборі CDR інформації з декількох кластерів. За замовчуванням задано: StandAloneCluster. Максимальна довжина значення, що задається: 50 символів. Допускаються наступні символи: "A"-"Z", "a"-"z". "0"-"9", ".", "-".
І, нарешті, слід налаштувати параметри CDR служби. Для цього відкрийте Cisco Unified Communications Manager Administration та виберіть System → Service Parameters. У списку Service виберіть Cisco CallManager, щоб відобразити весь список параметрів служби. У розділі System є наступні параметри:
- CDR Enabled Flag – цей параметр включає / відключає видачу CDR записів. Рекомендується включити цей параметр на кожному CUCM в кластері. При цьому не потрібно перезавантаження CUCM для того, щоб зміна цього параметра вступило в силу.
- CDR Log Calls With Zero Duration Flag – даний параметр визначає, чи будуть фіксуватися в CDR виклики з нульовою тривалістю або ті, які тривали менше ніж 1 секунду. Cisco Unified Communications Manager записує в CDR невдалі виклики незалежно від значення цього прапорця. Значення за замовчуванням: False.
У розділі Clusterwide Parameters (Device – General):
- Call Diagnostics Enabled – визначає, чи будуть генеруватися діагностичні записи (CMR), що містять інформацію про якість обслуговування. За замовчуванням: False (відключено).
- Show Line Group Member DN in finalCalledPartyNumber CDR Field – цей параметр визначає, чи буде поле finalCalledPartyNumber показувати внутрішній номер (directory number - DN) членів лінійної групи, з якого виклик отримав відповідь, чи пошуковий пілотний номер (hunt pilot DN). Значення True в цій позиції означає, що в полі finalCalledPartyNumber буде відображатися номер телефону, який відповів на виклик; значення False означає, що буде відображатися пошуковий пілотний номер. Цей параметр застосовується тільки до основних викликів, які маршрутизируются через список пошуку (hunt list) без таких функцій як трансфер, конференція, парковка виклику і т.п. У тому випадку, коли подібна функція була застосована під час виконання виклику, в поле finalCalledPartyNumber відображається пошуковий пілотний номер незалежно від значення, встановленого в цій позиції. Значення за замовчуванням: False.
Налаштування Tariscope для збору і обробки CDR та CMR файлів
Нижче ми розглянемо тільки специфічні особливості налаштування Tariscope для збору і обробки даних від CUCM. Опис всіх налаштувань ви можете знайти в документі "Tariscope 4.5. Керівництво адміністратора".
Ви можете конфігурувати Tariscope відразу ж після його першого запуску за допомогою Майстра початкового налаштування або використовувати майстер в будь-який інший час, вибравши в меню Tariscope: Вузли зв'язку → Майстер створення пристрою. При цьому ви можете налаштувати параметри телефонної системи, вибравши потрібний телекомунікаційний необходмости Вузол → Пристрої → Управління пристроями. Щоб додати CUCM, клацніть значок Додати (+) на панелі інструментів. У вікні Новий пристрій введіть ім'я телефонної системи, наприклад, CUCM. Відкриється сторінка Редагування CUCM. Опис сторінки дивіться в статті. У списку Пристрій зв'язку виберіть пункт Cisco CallManager і натисніть кнопку Додаткові налаштування, розташовану в правій частині списку. З'явиться вікно Додаткові налаштування, як показано на малюнку 3.
Малюнок 3
Формат CDR CUCM містить сотні різних полів. Деякі поля не використовуються для визначення рейтингу. Вони доповнюють один одного. Тому за замовчуванням тільки ті поля, які використовуються для оцінки дзвінків, обробляються і зберігаються в базі даних Tariscope. Щоб всі поля файлу CDR оброблялися і зберігалися в базі даних Tariscope, включите перемикач Зберігати всі поля. При цьому слід враховувати, що для зберігання всіх полів потрібно більше місця на диску.
Для правильного визначення внутрішнього і зовнішнього телефонних номерів слід використовувати номерний план. Для цього включіть перемикач Використовувати номерний план для визначення внутрішніх номерів.
Якщо ви використовуєте номерний план, але не хочете обробляти виклики, що не входять в номерний план включите перемикач Пропускати виклики не входять в номерний план. Це економить місце на диску і збільшує продуктивність.
Якщо ви не хочете обробляти інформацію про пропущених викликів, включите перемикач Ігнорувати пропущені виклики.
Щоб врахувати коди авторизації, включите перемикач Зберігати префікс, як код авторизації, якщо підпадає під шаблон і введіть шаблон, який буде використовуватися для визначення кодів авторизації.
Якщо у вас більше одного розділу в CUCM, включите перемикач Використовувати поділ (partitions) Це дозволяє правильно визначити абонента, яка вчинила дзвінок.
Якщо вам потрібно використовувати поле outpulsedCalledPartyNumber з CDR в якості набраного номера, включите перемикач Використовувати outpulsedCalledPartyNumber як набраний номер.
Клацніть Зберегти, щоб зберегти настройки.
Якщо ви використовуєте розділи (partitions), а додаткові номери не унікальні в CUCM, ви повинні вказати розділ (partition) разом з додатковим номером для кожного абонента. Для цього на сторінці Абоненти виберіть потрібного абонента і натисніть іконку Змінити на панелі інструментів. Відкриється сторінка з даними абонента. Натисніть на кнопку, розташовану поруч з полем Додаткові ідентифікатори. З'явиться таблиця додаткових ідентифікаторів. Натисніть Додати (+) на панелі інструментів. Відкриється вікно Новий додатковий ідентифікатор. Приклад вікна показаний на малюнку 4.
Малюнок 4
У текстовому полі Додатковий ідентифікатор введіть додатковий номер та розділ в наступному форматі: [extension number]@[partition]. Наприклад: 1234@old_city, де 1234 - додатковий номер, а old_city - partition (розділ). Клацніть Зберегти.
Цей параметр дозволяє Tariscope правильно визначати абонента при обробці даних CDR.
Послуги Tariscope Observer використовуються для збору даних CDR з телефонних систем в системі Tariscope. Ви повинні створити новий профіль Tariscope Observer для CUCM. В меню Tariscope виберіть Збір даних/Observer → Керування збором даних. Відкриється сторінка Збір даних/Observer. Натисніть по іконці Додати (+) на панелі інструментів і у вікні Новий Observer введіть ім'я служби в полі Назва. Наприклад, CUCM Observer. Клацніть Зберегти. Потім натисніть Змінити. Відкриється сторінка Налаштування Tariscope Observer, приклад якої показаний на малюнку 5.
Малюнок 5
Для CUCM ви можете вибрати один з наступних джерел в залежності від того, яке джерело ви хочете використовувати:
- FTP-сервер.
- SFTP-сервер.
- Папка/файл.
Щоб використовувати FTP-сервер, що входить в Tariscope, в вікні, показаному на малюнку 5, в списку Джерело даних виберіть пункт FTP-сервер і натисніть кнопку Налаштування джерела даних. Відкриється вікно Налаштування джерела даних.
В поле Порт введіть IP-порт FTP-сервера. Цей порт слід використовувати в FTP-клієнті CUCM. За замовчуванням: 21.
В поле Логін введіть ім'я для входу. У полі Пароль введіть пароль, який FTP-клієнт буде використовувати для підключення до FTP-сервера.
В поле Локальна тека введіть шлях до папки, в яку FTP-клієнт буде записувати файли CDR.
При необхідності в полі Шаблон файлів вкажіть шаблон, за яким вибираються потрібні файли в папці. Шаблон за замовчуванням - «*», який дозволяє вибрати всі файли в папці.
Якщо немає необхідності зберігати завантажені файли в папці, включите перемикач Не зберігати завантажені файли.
Щоб зберегти настройки, натисніть Готово.
Якщо ви плануєте використовувати SFTP-сервер в Tariscope, виберіть елемент SFTP-сервер і натисніть кнопку Налаштування джерела даних. Відкриється Налаштування джерела даних. Всі настройки вікна такі ж, як і для FTP-сервера.
Якщо ви плануєте використовувати сторонній FTP- або SFTP-сервер, в списку Джерело даних виберіть пункт Папка/файл і натисніть кнопку Налаштування джерела данни. Відкриється вікно Налаштування джерела даних. Опис вікна дивіться в статті.
Tariscope Observer він почне збирати і обробляти дані CDR від CUCM.
Аналіз даних
Основне призначення Tariscope - це аналіз інформації про дзвінки, створення звітів по дзвінках, білінгу і т. Д. Оскільки оброблювані дані з усіх типів телефонних систем в Tariscope зводяться до одного виду, немає функцій по фільтрації, сортування, звітності для CUCM в порівнянні з іншими типами телефонних мереж.
Ці функції виконуються в поданнях викликів. Щоб створити уявлення викликів, в меню Tariscope виберіть Подання → Доступні подання. Опис створення нового подання для дзвінків дивіться в статті.
Приклад подання викликів програми Tariscope з обробленими даними з CUCM показаний на малюнку 6.
Малюнок 6
Подання Tariscope дозволяє вам встановити список бажаних полів і їх порядок, фільтрувати дані різними способами, групувати дані за певними полях і т. Д.
Деякі дзвінки можуть складатися з декількох записів, наприклад, для перекладу дзвінка. В цьому випадку, якщо ви встановите фокус на одній з цих записів і клацніть по іконці Показати пов'язані записи на панелі інструментів (малюнок 7), Tariscope вибере всі рядки, пов'язані з цим викликом.
Малюнок 7
Ця функція дозволяє легко аналізувати дзвінки, що складаються з декількох етапів.
Крім того, для CUCM, а також для деяких інших АТС, які мають широкий діапазон полів CDR, є можливість обробляти всі поля CDR і зберігати їх в базі даних Tariscope. Це може бути корисно, якщо вам потрібно проаналізувати деякі поля CDR з CUCM, які відсутні в звичайному поданні викликів. У цьому випадку виберіть потрібні рядки в поданні викликів і клацніть значок Докладні відомості про записи на панелі інструментів. З'явиться меню, що містить два пункти:
- в поточному вікні. Докладні записи відображаються на цій сторінці.
- в новому вікні. Докладні записи відображаються на новій вкладці браузера.
Приклад подання з докладними записами показаний на малюнку 8.
Малюнок 8
Подання містить панель інструментів. Якщо ви натиснете на Заголовок зліва, таблиця змінить форму і досягне такого рівня, як показано на малюнку 9.
Малюнок 9
Подання дозволяє вам також шукати, фільтрувати дані і експортувати таблицю у зовнішній файл (PDF, Excel, Text, CSV). При необхідності ви можете створити форму звіту, яка буде містити тільки обов'язкові поля за бажаний період або для інших умов фільтрації. Сервіс Tariscope Tasks може автоматично формувати цей звіт за розкладом.
Якщо ви хочете проаналізувати телефонний трафік, вам слід вибрати список Подання, вибрати необхідне або необхідні і клацнути значок Обчислення трафіку на панелі інструментів. З'явиться вікно Підрахунок трафіку, в якому необхідно вказати подання, дані яких будуть використовуватися для розрахунку, шлюзи, період і початок періоду. В результаті ви отримаєте графік, що відображає трафік. Приклад сторінки показаний на малюнку 10.
Малюнок 10
Для повного аналізу даних CDR ми рекомендуємо створити бажану форму звіту за допомогою Дизайнера звітів або Microsoft SQL Server Report Builder. Як створити спеціальну форму звіту для CUCM в дизайнера звітів, ви можете знайти в статті.
Контроль якості виклику
Tariscope може збирати і обробляти записи управління викликами (CMR), які містять інформацію про якість аудіо- і відеопотоків, а також може створювати ряд звітів з даними CMR.
Щоб дізнатися більше про цю функцію Tariscope, перейдіть до наступної статті.
Створення форм звітів для CUCM
Tariscope дозволяє користувачам створювати звіти для аналізу будь-яких даних, що містяться в CDR файлах. Як це зробити, читайте в статті.
Управління бюджетом на телефонні розмови
Tariscope не тільки дозволяє враховувати всі виклики кожного співробітника компанії, клієнта, а й забезпечує повний контроль над витратами на телефонні розмови. Tariscope дозволяє встановити грошові або тимчасові обмеження будь-якої особи або групи осіб. Коли цей ліміт буде вичерпано, Tariscope відправляє команди в CUCM, який обмежує, наприклад, міжміські виклики до кінця періоду ліміту. На початку наступного лімітного періоду обмеження буде автоматично знято. Таким чином компанія може чітко виконувати заплановані витрати на телефонні розмови, а при необхідності скорочувати їх. Для використання цієї можливості ліцензія Tariscope повинна містити функцію обмеження.
Тестування і придбання Tariscope
Завантажте та протестуйте Tariscope з вашим CUCM прямо зараз. Ця можливість - безкоштовна.
Ви можете придбати Tariscope різними способами:
- безпосередньо у компанії SoftPI,
- у партнерів нашої компанії у вашій країні,
- купити онлайн зі сторінки сайту.
Посилання
1. Call Detail Records Administration Guide for Cisco Unified Communications Manager, Release 12.5 (1).
2. Cisco Unified Serviceability Administration Guide, Release 11.5 (1).
3. Cisco Unified CDR Analysis and Reporting Administration Guide, Release 12.5 (1).
Додаткова інформація
Завантажте і протестуйте Tariscope
Переваги Tariscope для збору і аналізу CDR і CMR від CUCM
Контроль якості зв'язку для CUCM за допомогою Tariscope
Конфігурація Tariscope для використання функції обмеження з CUCM
