Мониторинг качества голосовой связи.

[SolarW]

Добрый день уважаемые коллеги.

Такой вопрос - а кто как мониторит качество связи?
С ростом количества клиентов у которых IP-АТС в дата центре а телефоны разбросаны по офисам, встает вопрос как можно анализировать качество голоса.
Т.е. когда звонят и говорят "что-то мы нихрена не слышим друг друга" - как проанализировать где проблема, на участке "абонент - АТС" или "АТС - оператор"?
Ну и желательно чтобы можно было заранее получать оповещения, чтобы начинать реагировать на проблему не дожидаясь звонка от клиента.
В качестве основной системы мониторинга использую Zabbix.
В офисах в качестве маршрутизаторов - Mikrotik'и.
Мониторю пинг, потери, загрузку каналов.
Но частенько возникают случаи когда по моей статистики вроде как все ОК а жалобы на качество связи есть.
Сейчас вот думаю прикрутить еще мониторинг jitter'а.
И посматриваю в сторону еще вот этого руководства
Но насколько я вижу в данном руководстве упор делается на мониторинг общего количества звонков и количества звонков завершившихся с ошибками.
А судя по описанию VoIP monitor умеет считать MOS.
Тут пишут:

VoIP монитор пакетный сниффер-анализатор, WAV рекордер для SIP-вызовов. Он рассчитывает MOS (Значение Opinion Score) по электронной модели (ITU-T G.107) и сохраняет статистику в базу данных MySQL.
Основной задачей является обеспечение полноценной платформы для качества VoIP.

Так вот вопрос - как-нибудь можно в Zabbix и мониторинг MOS подтягивать, чтобы при его ухудшении начинать мигалками мигать и свистелками свистеть?

P.S. VoIP monitoring - похоже достаточно бойко развивающийся продукт судя по частоте выхода новых версий...

P.P.S. http://forum.asterisk.ru/viewtopic.php?f=13&t=1253 - свяжу эту тему с еще одной архивной.

[awsswa]

ставлю voipmonitor - без вебки
при разборках пользователей - прошу говорить время и номер телефона
скачиваю с voipmonitor сохраненный pcap файл и смотрю в чем проблема

ps проблема решается обычно довольно быстро - так что включаю монитор только когда жалуются

[SolarW]

включаю монитор только когда жалуются

Так вот в том то и беда - у меня, когда жалуются это уже поздно обычно.
Я потому и пытаюсь реализовать мониторинг, предупреждающий меня ДО того как начнут жаловаться...

Ладно, попробую поднять потестировать, глянуть что VoIP monitor пишет в табличку cdr и если там есть нужные значения попробую дергать их по образу и подобию тех, что даны в примере.

[awsswa]

если жалобы идет постоянно - у вас реальная проблема с настройками интернета
берите микротики - настраивайте очереди
меняйте провайдера

полностью настроенная система не должна приносить проблем за исключением аварий

[SolarW]

если жалобы идет постоянно - у вас реальная проблема с настройками интернета

Не все так просто...
Много офисов, много микротиков, на каждый заходит по 2-3 канала передачи данных (арендованные транспортные VLAN'ы, интернет и т.д.).
Настроены режимы работы для перехода на запасной канал в случае пропадания основного и т.д.
Соответственно в случае временного ухудшения сервиса на каком-то из каналов переключаться на альтернативу пока выносишь мозг оператору у которого канал взят в аренду и т.д.

берите микротики - настраивайте очереди

Дык это в первую очередь. Приоритеты, гарантированная полоса пропускания и т.д.

меняйте провайдера

Как я уже написал выше - у меня их в ассортименте
Причем в некоторых местах - я сам себе провайдер, т.е. используются личные каналы связи (радио, оптика).

полностью настроенная система не должна приносить проблем за исключением аварий

К этому и стремлюсь.
И надеюсь что VoIP monitor мне в этом поможет.
Для начала просто сигнализируя о проблемах, а в последствии как с этим разберусь - так постараюсь реализовать автоматический переход между основными/резервными каналами где качество лучше.

[MIKS]

Есть вариант выдергивать и анализировать RTCP обмен. Насколько я помню в последних версиях астера там даже функции стандартные есть (на уровне кода). RTCP же был разработан специально для этого чтобы автоматически в процессе сессии менять тип кодека если ухудшается качество канала. Просто это в астериске не работает (опять же не совсем уверен как в последних версиях)

[SolarW]

автоматически в процессе сессии менять тип кодека если ухудшается качество канала

Ну это уж чересчур

Добавил в мониторинг тестирование джиттера (статистику беру из пингов UDP а не ICMP пакетами, чтобы хоть как-то было похоже на RTP, теперь бы еще с размером пакетов определиться надо чтобы было совсем похоже).
Теперь нахожусь в задумчивости - при ухудшении до какой величины бить тревогу?
Погуглил, нашел навскидку несколько источников, все содержат несколько противоречивые данные.
http://sipofis.ru/connect/tehnical-requirements

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

задержка пакетов (промежуток времени, требуемый для передачи пакета через сеть) – не более 150 мс, до оборудования оператора связи
потери пакетов (доля пакетов, потерянных во время сеанса связи при передаче через сеть) – не более 3% для голоса и полное (0%) отсутствие для приема/передачи факсимильных сообщений.
джиттер (изменение задержки пакетов потока в течение сеанса связи) – не более 75 мс.
пропускная способность (максимальный объем пользовательских и служебных данных, которые она способна передать)- для кодека G.711 до 80 кбит/с, для кодека G.729 до 30 кбит/с на один разговорный канал связи.

http://www.voipservice.tamb.ru/technology1.htm

Требования к Интернет каналу.
Надёжность IP-телефонной связи в первую очередь зависит от качества используемого Вами Интернет канала и от варианта подключения Вашего компьютера к сети Интернет.
Требования к Интернет-каналу для обеспечения качественной и бесперебойной телефонной связи:
1) Отсутствие потерь пакетов. Но не более 2 процентов.
2) По возможности минимальные задержки пакетов. Но не более 150 миллисекунд.
3) По возможности минимальный джитер пакетов. Но не более 20 миллисекунд.
4) Ширина канала не менее 64 кбит/сек на каждую линию.

http://habrahabr.ru/post/108519/

1. При потерях >0.5% на канале, канал не должен использоваться.
2. При jitter > 10мс, канал не должен использоваться.

Пока остановился на оповещении если средний джиттер в течении 3 минут превышает 10.

А вообще, из личного опыта - кто нибудь может поделиться опытом эксплуатации, до каких значений задержки/потери пакетов/джиттера нормальное качество голоса будет?

И еще вопрос - если оборудование на всей цепочке поддерживает работу с Jitter-буффером стоит активировать его использование на Asterisk?
И если да - то какие разумно параметры задавать?

[SolarW]

Апну тему.

глянуть что VoIP monitor пишет в табличку cdr и если там есть нужные значения попробую дергать их по образу и подобию тех, что даны в примере.

Посмотрел более внимательно на VoIP monitor.
Состоит из двух частей.
Первая (backend) собирает статистику, пишет разговоры, распространяется бесплатно.
Вторая (frontend) представляет из себя веб-интерфейс к первой части, позволяющей удобно работать с первой частью, формировать отчеты, получать доступ к записанным данным. Распространяется за деньги, которые судя по всему готовы тратить операторы-транзитчики с большим потоком звонков.
В приведенной мной исходно ссылке на руководство по интеграции VoIP monitor'а с Zabbix'ом рассматривается мониторинг количественных показателей.
Т.е. сколько всего звонков прошло за прошлые 5 минут и сколько из них завершилось неудачно.
Меня же как написал ранее интересуют качественные показатели.
Исходя из этого в структуре формируемой backend'ом базой данных думаю что интересным будет анализ следующих полей:

ab_lost - number of lost RTP packets detected by holes in sequence numbers according to rfc3550
lost - max (a_lost, b_lost)
ab_avgjitter_mult10 - average jitter calculated according to rfc3550
ab_maxjitter - maximum jitter
ab_sl1 - ab_sl10 - number of consecutive packet loss. sl1 - number of one packet loss occurences. sl5 - number of 5 consecutive packet loss occurences.
ab_d50-300 - number of delay occurences within delay range. d50: 0-50ms, d70: 50-70ms, etc.
ab_mos_f1_mult10 - MOS score for fixed jitterbuffer 50ms. Divide it by 10 to get real number.
ab_mos_f2_mult10 - MOS score for fixed jitterbuffer 200ms. Divide it by 10 to get real number.
a_mos_adapt_mult10 - MOS score for adaptive jitterbuffer. Divide it by 10 to get real number.
ab_rtcp_loss - loss from RTCP
ab_rtcp_maxfr - max fraction loss from RTCP
ab_rtcp_avgfr_mult10 - average fraction loss - devidie it by 10 to get real number
ab_rtcp_maxjitter - maximum jitter from RTCP
a_rtcp_avgjitter_mult10 - average jitter from RTCP
jitter_mult10 - max(a_jitter, b_jitter)
mos_min_mult10 - minimum jitter from caller or called stream
a_mos_min_mult10 - minimum caller jitter
b_mos_min_mult10 - maximum called jitter
packet_loss_perc_mult1000 - maximum packet loss from caller or called
a_packet_loss_perc_mult1000 - maximum packet loss from caller
b_packet_loss_perc_mult1000 - maximum packet loss from called
delay_sum - sum of all delays (PDV) from caller or called
a_delay_sum - sum of all delays (PDV) from caller
b_delay_sum - sum of all delays (PDV) from called
delay_avg_mult100 - max average PDV from caller or called
a_delay_avg_mult100 - average PDV from caller
a_delay_avg_mult100 - average PDV from called
rtcp_avgfr_mult10 - max(a_avgfr, b_avgfr)
rtcp_avgjitter_mult10 - max(a_avgjitter, b_avgjitter)
delay_cnt -
a_delay_cnt -
b_delay_cnt -

Если кто-то меня направит в нужном направлении, указав на какие параметры обращать внимание в первую очередь - не обижусь

[gosha]

Считайте R-Factor, mos score сильно субективная штука. Для r-factor формула гуглится данные есть в voip-monitor.

[Vit]

Написал небольшую статью по выгрузке CDR с помощью Voipmonitor, может поможет в решение вашей задачи.
Скрипт можно расширить, и добавить данные, которые требуется.