Голосовая связь и система унифицированных коммуникаций : Cisco Unified Communications Manager (CallManager)

Управление качеством голоса при помощи Cisco Voice Manager (CVM) и Telemate

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Отзыв


Содержание


Введение

В данной документации описывается использование Cisco Voice Manager и Telemate для управления качеством голосовых данных в сети VoIP. Все содержимое основано на реально применяемой технологии IP-телефонии. Данный документ сосредоточен на приложении продуктов, а не их использовании. Необходимо обладать знаниями о CVM и Telemate, а также иметь доступ к необходимой документации по продуктам. Посмотрите Дополнительные сведения для списка связанной документации.

При управлении крупномасштабной сетью передачи голоса (VoIP) необходимы средства объективного мониторинга и создания отчетов о качестве речи в сети. Зависимость от обратной связи пользователя недопустимо, так как она субъективная и недостаточна. CVM совместно с Telemate может предоставить часть этой функциональности. Это сообщает относительно качества голосовой связи при помощи Impairment/Calculated Impairment Planning Factor (Icpif), вычисленный IOS-шлюзом для каждого вызова. Это позволяет диспетчеру сети определять сайты, которые характеризуются низким качеством звука, и выполнять соответствующие действия.

После определения проблемных сайтов могут понадобиться другие средства для устранения возможных неполадок сети QoS. Могут понадобиться монитор производительности объединенной сети (IPM) и агент гарантированного обслуживания Cisco (CSAA). Эти темы обсуждены в другом документе, зарегистрированном на нашем вебе - узлы/URL.

Предварительные условия

Требования

Для использования данного документа требуется знание следующих тем:

  • Cisco Voice Manager и Telemate

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.

Обзор качества голосовой связи

Описание проблем с качеством звука содержится в следующих разделах:

Измерение качества голоса

Стандарт G.113, разработанный ITU, служит для определения качества голосовой связи. Этот метод диктует, что можно определить качество голосовых вызовов путем вычисления Icpif. Шлюзы на основе программного обеспечения IOS вычисляют значение Icpif для каждого вызов и записывают его в журнал как часть записи CDR., Кроме того, если Значение Icpif вызова превышает заданное значение, это может передать trap-сообщение Качества голоса (QoV) через SNMP. Это означает, что у шлюзов есть встроенные возможности измерения качества голосовой связи. Все, что необходимо, собирают эти измерения и анализируют данные для определения любых тенденций.

Качество голосовой связи VoIP главным образом зависит от QoS сети. Поэтому при анализе вызова акцент делается на поузловом определении проблем качества голосовой связи. Если возможно выявить сайты, обслуживающие большое количество вызовов с низким качеством звука, можно устранить любую проблему QoS на сетевом пути, ведущем к этим сайтам или от них.

Описание ITU G.113

Следующий раздел является только кратким обзором; консультируйтесь со стандартом G.113 для более подробной информации.

Основная идея метода, основанного на рекомендации G.113, состоит в расчете параметра ухудшения качества передачи речи на каждом участке соединения в сети связи и сложения этих величин для получения общего параметра. Существуют различные типы помех (шум, задержка, эхо и другие), и ITU подразделяет их на пять категорий. Сложите их для получения общего Itot ухудшения:

Itot = Io + Iq + Idte + Idd + Ie

Каждый из них определяется следующим образом (используя терминологию ITU):

  • Io — ухудшения, вызванные неоптимальной полной оценкой громкости и/или высокой зашумленностью канала.

  • IQ — ухудшения вызваны искажением квантования типа икм.

  • Idte — ухудшения вызваны эхосигналом источника.

  • Idd — трудности с речевой связью вызваны длинными временами односторонней передачи (задержка).

  • Ie — ухудшения, вызванные специальным оборудованием, в определенной неформе сигнала низкоскоростные кодеки.

Когда программное обеспечение Cisco IOS вычисляет Itot, оно игнорирует Io и Iq, как являющийся незначительным, и устанавливает Idte в 0. Значение Idd берётся из следующей таблицы, приходящей от G.113:

Задержка Idd
150 0
200 3
250 10
300 15
400 25
500 30
600 35
800 40

Обычно Ie является фиксированным значением, завися только от типа кодека. G.113 задает значения для кодеков, как правило, используемых шлюзами Cisco как показано в следующей таблице:

Код Ie
G.711 0
G.729/G.729a 10

Однако, потому что эти кодеки используются в среде пакета речевых сигналов, фактическое искажение зависит от потери пакета. Чем выше уровень потерянного пакета, тем больший урон наносится работе. Техника Cisco измерила голосовое качество PSQM (ITU P.861) на дискретных уровнях потери пакетов. Следующая таблица показывает значения искажения речевого сигнала относительно уровней потери пакетов для данных кодеков:

Потеря пакета G.711 G.729/G.729a
0 0 10
1 8 15
2 12 20
3 18 25
4 22 30
5 26 34
6 28 38
7 30 40
8 32 42
9 34 44

Как ожидалось G.729 более восприимчив к потере пакета, чем G.711.

Качество голоса говорит все о человеческом восприятии и ожиданиях. Ожидаемое пользователями качество обслуживания для сотовых телефонов ниже, чем для стационарных. Когда вычисление Icpif путем сокращения Itot человеческим ожиданием разлагает на множители A, мы принимаем это во внимание. Формула:

Icpif = Itot - A

G.113 также поддерживает факторы ожидания для типичных голосовых сетей. См. следующую таблицу:

Метод доступа к сети телефонной связи Ожидать фактор A
Обычная фиксированная линия PSTN 0
Локальный беспроводной телефон 5
Глобальная беспроводная связь (сотовые телефоны) 10
Спутник 20

В G.113 также имеется таблица, в которой задано соответствие между значением Icpif и качеством голосовой связи. Это показывают в следующей таблице:

Метод доступа к сети телефонной связи Ожидать фактор A
5 Очень хороший
10 Хороший
20 Соответствующий
30 Крайний случай
45 Особенно крайний случай
55 Пользователи, вероятно, для жалобы строго

Пустое значение параметра Icpif для вызова является идеальной оценкой. Это должно стать целью сетей VoIP.

Проектирующий традиционную голосовую сеть стал бы вычислять общий уровень искажений.

Например, Io = 0; IQ = 0; Idte = 0; Idd = 3; Ie = 7, который дает Itot = 10.

Если пользователь подключается к сети с беспроводного телефона, максимальный фактор ожидания, который следует вычесть, равен 5, т.е. конечный результат равен:

Icpif = Itot - = 10 - 5 = 5

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

Данный документ содержит анализ решения, которое использует значение Icpif для контроля качества звука, а не для планирования.

Управление качеством голоса с помощью CVM и Telemate

Следующие разделы обсуждают, как управлять качеством голосовой связи с CVM и Telemate:

Ограничения

Хотя предлагаемое решение имеет некоторые ограничения, других доступных масштабируемых средств не обнаружено. В числе известных ограничений:

  • Контроль качества распространяется только на вызовы, проходящие через шлюз. Вызовы с IPhone на IPhone измерить нельзя. Шлюз не видит данные вызовы, а CallManager в настоящий момент не поддерживает G.113.

  • Расчет lcpif учитывает только потери пакетов и задержки. Эхо не включено в Расчеты фактора ICPIF. Поэтому для вызова может быть характерно выраженное эхо и тем не менее идеальное значение Icpif.

  • Качество голосовой связи только измерено в направлении IPHONE К ШЛЮЗУ. Значение Icpif в сети для речевых пакетов может быть асимметричным в двух направлениях. Любые проблемы QoS в односторонней сети в направлении шлюз-IP-телефон не отразятся на значении Icpif, рассчитанном шлюзом.

  • Качественные характеристики голосового соединения зависят обычно больше от WAN. Данное решение наиболее подходит к среде с централизованными шлюзами, поскольку вызовы от IP-телефонов на удаленных сайтах должны пересечь глобальную сеть (WAN), чтобы получить доступ к шлюзам. Если шлюзы будут распределены (т.е. каждый удаленный сайт обслуживается локальным шлюзом), то большинство вызовов шлюза не пересечет глобальную сеть (WAN). Вызовами VoIP по глобальной сети (WAN) будет в основном ОТ IPHONE К IPHONE, и они не видимы к шлюзу.

Конфигурация шлюза

Предлагаемое решение, в частности, предусматривает настройку всех шлюзов для сбора записей CDR:

dial-control-mib max-size <max-number-of-cdr>
dial-control-mib retain-timer 600

Все шлюзы должны также иметь активированную опцию trap-сообщения QoV. По умолчанию эта функция отключена:

Calibra#show dial-peer voice 99 | include QOV|Icpif
Expect factor = 0, Icpif = 20,
VAD = enabled, Poor QOV Trap = disabled,

Эта функция активируется для каждой точки вызова VoIP при добавлении таких настроек:

dial-peer voice XYZ voip
snmp enable peer-trap poor-qov
icpif <threshold>
expect-factor 0

После завершения вызова шлюз вычисляет для данного вызова общее ухудшение (Itot). Это тогда вычитает настроенного expect-factor из Itot для достижения фактического Значения Icpif. Если это количество превышает пороговое значение Icpif, то trap-сообщение QoV передается. Вызовы должны длиться как минимум 10 секунд, чтобы шлюз мог подсчитать значение Icpif вызова.

Рассмотрим пример, где шлюз настроен следующим образом:

dial-peer voice XYZ voip
icpif 10
expect-factor 5

Предположите, что вызов завершает со значением Itot 20. Шлюз тогда вычитает ожидать фактор 5 от этого количества, давая Значение Icpif 15. Поскольку 15 более тогда 10, шлюз генерирует trap-сообщение SNMP QoV.

Глобально необходимо включить прерывания QoV для отправки CVM:

snmp-server enable traps voice poor-qov
snmp-server host 10.x.x.x.x public<----- CVM station

Будьте осторожны, голосовые шлюзы создают SNMP-прерывания включения/отключения канала каждый раз, когда вызов устанавливается или срывается. Это может составить огромное количество trap-сообщений на шлюзе высокой плотности. Следует отключить данные ловушки с помощью такой команды:

interface serial1/0:15no snmp trap link-status

CVM и архитектура Telemate

CVM и Telemate являются абсолютно отдельными приложениями. Как следует из имени, CVM является продуктом, разработанным Cisco. Telemate, с другой стороны, является продуктом стороннего разработчика, который Cisco продает связанный с CVM.

CVM выполняет ряд функций. Воспользуемся двумя следующими функциями:

  • Сбор записей деталей вызова (CDR) шлюзов через SNMP.

  • Получение trap-сообщений SNMP Качества голоса (QoV) от шлюзов.

После сбора этой информации CVM задаёт формат данных и передаёт их на Telemate при помощи простого совместного использования файлов. Программа Telemate затем обрабатывает эти данные и сохраняет их в базе данных Microsoft SQL. Конечный результат является базой данных со списком вызовов с их соответствующими подробными данными, включая Значение Icpif. Затем в базе данных можно создать различные отчеты, включая отчеты QoV.

Интересующий нас отчет Telemate QoV – это отчет "Пакетные голосовые вызовы с прерываниями качества обслуживания" (Packet Voice Calls with Quality of Service Trap). В этом отчете перечислены все вызовы, для которых шлюзом были сгенерированы прерывания QoV. Мы не интересуемся отдельными вызовами; скорее мы интересуемся определением сайтов, если таковые имеются, которые имеют вышеупомянутый средний процент от вызовов с качеством голосовой связи. Для этого программа Telemate должна иметь возможность группировать вызовы по сайтам. Это описано в следующем разделе.

Каталог Telemate

Заполнив каталог Telemate данными о том, на каких узлах находятся те или иные расширения, можно использовать Telemate для систематизации вызовов по узлам.

Каталог Telemate обладает пятиступенчатой иерархией со следующими уровнями:

  • 1 уровень - компания

  • Уровень 2 – Подразделение

  • Уровень 3 - отдел

  • Уровень 4 - Пользователь

  • Уровень 5 - добавочный

Можно связывать несколько расширений с одним пользователем.

Идеально, мы хотели бы, чтобы каждый вызов в отчёте о QoV был перечислен с именем отдела. Затем можно будет использовать имя отдела для представления данного веб-узла. Это позволяет нам вызовам вида отдела/сайта. Но поскольку расширения могут быть связаны только с пользователями, этого можно достичь не очень удобным способом. По существу на каждом узле создан один фиктивный пользователь, имя которого совпадает с именем узла или кодом узла. Этот фиктивный пользователь назначен всем добавочным номерам данного узла. Таким образом, существует возможность сортировать звонки пользователя, которые затем становятся эквивалентом для сортировки их по узлам.

В целях QoV-отчетности три верхних уровня иерархии каталогов не учитываются, и им может быть присвоено произвольное значение.

Для реализации существует 200 сайтов с 45000 расширениями, присвоенными, хотя и не обязательно, всем., Таким образом, каталог содержит 200 фиктивных пользователей, и каждый фиктивный пользователь привязан к диапазону расширений для их сайта. Начальная загрузка каталога вручную была бы невыполнимой задачей, таким образом, мы делаем это полуавтоматически путем генерации Файла csv с одной линией на расширение, и мы тогда используем Средство импорта Telemate для импортирования файла в каталог. Каждая линия в этом Файле csv имеет придерживающийся формат:

Company,Division,Department,User,Extension

Формирование файла CSV также выполняется в полуавтоматическом режиме путем выполнения сценария оболочки Unix. Данный сценарий в качестве входных данных использует файл прототипа. В этом файле прототипа перечисляются сайты и связанные диапазоны расширения. Каждая линия в файле прототипа имеет этот формат:

site_name,extention_start,extension_end

Сам основной сценарий очень прост и выглядит так:

#--------------------------- Telemate script start ------------------------

#!/bin/ksh
 
 for i in `cat ./$1`
 do (
   echo $i | awk 'BEGIN{FS=","}{for (j=($2+0);j<($3+0);++j) printf "Company,Division,Dept,%s,%s\n", $1,j}'
) done
#--------------------------- Telemate script end ------------------------

Предположение, что сам сценарий называют 'make_dir' и что файл прототипа называют 'seedfile.csv', CSV импорта telemate_dir.csv файл, создано путем выполнения следующей команды в приглашении Unix:

unix$ make_dir seedfile.csv > telemate_dir.csv

Затем выходной файл telemate_dir.csv импортируется в Telemate. Подробные инструкции о том, как это сделать, см. в документации Telemate.

Создание отчетов

При запуске отчета Telemate, можно указать исходящего получателя. Если отчеты большие, то рекомендуется использовать файлы в формате CSV. Затем можно работать с отчетом в Excel, и это будет выглядеть так:

Продолжительность Набранный номер Местоположение Дата Время Сайт Ext.
0:00:57 3-573-7783 10.200.16.33 05.10.2000 16:49:45 BLM 37569
0:00:57 3-573-7783 10.200.16.33 05.10.2000 16:49:45 BLM 37569
0:00:38 3-577-2958 10.200.16.33 05.10.2000 16:28:28 BLM 37576
0:00:38 3-577-2958 10.200.16.33 05.10.2000 16:28:28 BLM 37576
0:00:52 3-577-2985 10.200.16.33 05.10.2000 21:26:33 BLM 37593
0:01:19 3-577-1770 10.200.16.33 05.10.2000 19:26:05 BMC 34270
0:00:23 3-577-1770 10.200.16.33 05.10.2000 20:08:27 BMC 34270
0:00:23 3-577-1770 10.200.16.33 05.10.2000 20:08:27 BMC 34270
0:00:11 4-566-5302 10.132.16.33 05.10.2000 19:05:33 COR 42791
0:00:32 4-567-0417 10.132.16.33 05.10.2000 17:29:51 COR 42805
0:00:32 4-567-0417 10.132.16.33 05.10.2000 17:29:51 COR 42805
0:00:36 4-232-8545 10.132.16.33 05.10.2000 17:42:07 COR 42823
0:00:36 4-232-8545 10.132.16.33 05.10.2000 17:42:07 COR 42823
0:00:39 4-472-5011 10.132.16.33 05.10.2000 17:59:23 COR 46578
0:00:39 4-472-5011 10.132.16.33 05.10.2000 17:59:23 COR 46578
0:00:28 4-236-7687 10.132.16.33 05.10.2000 19:17:51 COR 46578
0:00:17 6-867-9766 10.132.16.35 05.10.2000 16:08:02 ГИС 64197
0:00:17 6-867-9766 10.132.16.35 05.10.2000 16:08:02 ГИС 64197
0:00:30 6-868-6889 10.132.16.35 05.10.2000 18:15:48 ГИС 68549
0:00:30 6-868-6889 10.132.16.35 05.10.2000 18:15:48 ГИС 68549
0:01:26 6-876-5223 10.132.16.35 05.10.2000 19:10:23 HAH 68369
0:01:26 6-876-5223 10.132.16.35 05.10.2000 19:10:23 HAH 68369
0:00:52 6-876-2223 10.132.16.35 05.10.2000 17:37:58 HAH 68397
0:01:05 4-477-5402 10.132.16.33 05.10.2000 16:23:20 JVL 47162
0:00:24 4-478-8848 10.132.16.33 05.10.2000 19:07:09 JVL 47168
0:00:24 4-478-8848 10.132.16.33 05.10.2000 19:07:09 JVL 47168
0:00:44 4-387-1333 10.132.16.33 05.10.2000 19:49:16 KIB 49252
0:00:44 4-387-1333 10.132.16.33 05.10.2000 19:49:16 KIB 49252
0:01:14 4-389-4299 10.132.16.33 05.10.2000 16:07:10 KIB 49254
0:01:14 4-389-4299 10.132.16.33 05.10.2000 16:07:10 KIB 49254
0:00:29 4-387-1337 10.132.16.33 05.10.2000 16:06:45 KIB 49256
0:00:29 4-387-1337 10.132.16.33 05.10.2000 16:06:45 KIB 49256
0:00:41 4-384-9269 10.132.16.33 05.10.2000 16:09:38 KIB 49261
0:00:41 4-384-9269 10.132.16.33 05.10.2000 16:09:38 KIB 49261
0:00:41 4-384-9269 10.132.16.33 05.10.2000 16:09:38 KIB 49261
0:00:17 4-387-1344 10.132.16.33 05.10.2000 16:33:04 KIB 49263
0:00:17 4-387-1344 10.132.16.33 05.10.2000 16:33:04 KIB 49263
0:00:31 6-367-5103 10.132.16.35 05.10.2000 20:44:46 LEV 64233
0:00:31 6-367-5103 10.132.16.35 05.10.2000 20:44:46 LEV 64233
0:00:30 6-368-9088 10.132.16.35 05.10.2000 16:11:06 LEV 64247
0:00:30 6-368-9088 10.132.16.35 05.10.2000 16:11:06 LEV 64247
0:00:38 4-570-2450 10.132.16.33 05.10.2000 16:08:26 LHT 43636
0:00:38 4-570-2450 10.132.16.33 05.10.2000 16:08:26 LHT 43636

С помощью функции Excel "Промежуточные итоги" подсчитайте количество неправильных вызовов для заданного пользователя или сайта. Затем создайте макрос Excel для полуавтоматического расчета промежуточных итогов. Рассмотрим следующий пример:

Продолжительность Набранный номер Местоположение Дата Время Сайт Ext.
        Счетчик BCM 5  
        Номер BMC 3  
        Счет COR 8  
        Счетчик GIS 4  
        HAH количество 3  
        Количество JVL 3  
        Счетчик KIB 11  
        Количество LEV 4  
        Счетчик LHT 2  
        Общее количество 43  

Столбец Site теперь содержит количество плохого к/ота вызовов тот сайт. В отчете в столбце '' Location'' приведены IP-адреса другого конца ветви VoIP, источником которых служат записи CDR шлюза. В CallManager (CCM) средой, сигнализацией и оконечная точками сред являются два отдельных IP-адреса. Перечисленный IP-адрес является конечной точкой передачи сигналов (т.е. CallManager). Был отправлен DDTS (CSCds23283) для запроса ручки управления, которая позволяет записи CDR внести в журнал IP-адреса носителей. Это позволит сортировать вызовы с ошибками на основе подсети. Это предоставляет более высокую детализацию, так как на один узел обычно будет приходиться несколько подсетей. Если только некоторые из этих подсетей испытывают проблемы QoV, это можно выяснить.

Мы рекомендуем установить планировщика Telemate для автоматического выполнения "Пакетных голосовых вызовов с отчётом о" Trap-сообщений Качества обслуживания один раз в день. Завершенные отчеты затем могут быть отосланы указанному рабочему персоналу. Эти штатные сотрудники тогда делают ежедневный QoV контролирует в течение прошлых 24 часов. Отчеты следует архивировать хотя бы на один месяц с тем, чтобы любое ухудшение в QoV можно было скоррелировать с любыми изменениями сети, случившимися в это время.

Примечание: Версия Telemate 4.7 или позже требуется для создания отчетов работать должным образом со шлюзами, работающими в Среде CallManager. Более ранние версии Telemate предполагают, что локальные расширения всегда находятся на стороне POTS шлюза. В среде CallManager локальные расширения (IP-телефоны) располагаются на стороне шлюза VoIP. В результате более ранние версии Telemate запутываются, и отчёты имеют ограниченное значение.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения