Контроль качества IP вызовов через CUCM, используя Tariscope

Cisco Unified Communications Manager (CUCM) компании Cisco Systems генерирует не только подробные данные о выполненных вызовах (CDR записи), но и информацию о качестве вызовов (Call Management Record – CMR). CMR записи хранят информацию о качестве аудио потока, который был во время вызова. CDR записи связаны с CMR записями через 2-а параметра: GlobalCallID_callManagerId и GlobalCallID_Called [1].

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 [1] как 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

Биллинговая система Tariscope поддерживает обработку как CDR, так и CMR записей. И пользователь системы может просмотреть и проанализировать эти данные с использованием соответствующих отчетов.

Для того чтобы Tariscope обрабатывал CMR файлы, необходимо в настройках CUCM в системе выбрать Расширенная настройка обработки CDR и в появившемся окне Настройка параметров (Рисунок 1) установить флаг в позиции Сохранять все поля (CDR и CMR).

Рисунок 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 записей и в зависимости от их содержимого выполнять требуемые действия.

Ссылки

Конфигурация Tariscope для использования функции ограничения с CUCM

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

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

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

Функции редакции Tariscope Enterprise

Функции редакции Tariscope Provider

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