С течением времени в мире OpenSource ПО появляется все больше и больше VoIP приложений, что очень и очень радует. Ещё 6 лет назад было сложно представить сегодняшнее развитие поддержки VoIP различными приложениями. Хотя стоит отметить, что за эти годы был получен неоценимый опыт и что-то просто не было понятно раньше. Сегодня речь пойдет о единственном в своем роде VoIP снифере, предназначенным для оценки и контроля качества VoIP связи — voipmonitor.org.

Конечно существует wireshark, его значение для VoIP администратора сложно переоценить, но он не предназначен для потоковой обработки вызовов. VoIPmonitor перехватывает вызовы в реальном времени и сохраняет статистику и дампы файлов в БД для последующего анализа.

VoIPmonitor использует снифер на базе libpcap, обнаруживает SIP INVITE пакет и перехватывает RTP в обоих направлениях. Далее используется код Jitter буфера Asterisk'а для имитации буфера и получения статистики потери пакетов и джиттера при различных величинах и типах буфера. При завершении вызова статистика считывается, с её помощью рассчитывается приблизительное значение MOS по методике описанной в спецификации G.107 (используется ограниченное количество параметров, sic!).

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

Проблемой при старте работы может явиться описание полей базы данных, используемой VoIPmonitor. Такое описание можно частично получить внимательным чтением обсуждений на SourceForge или чтением исходного кода. Делюсь результатами своих изысканий:

calldate — время и дата начала вызова
duration — общая длительность вызова (от INVITE)
connect_duration — длительность соединения (от 200 OK)
progress_time — время в течении которого производилась индикация прогресса
first_rtp_time — относительное время поступления первого RTP пакета (от момента поступления INVITE)
caller — Номер вызывающего абонента (сторона A)
callername — Имя вызывающего абонента
called — Номер вызываемого абонента (сторона B)
sipcallerip — IP адрес вызывающего абонента, используемый для отправки SIP сигнализации
sipcalledip — IP адрес вызываемого абонента, используемый для отправки SIP сигнализации
fbasename — Call-ID для вызова, до 1024 символов используется как основа для создаваемых файлов на диске
bye — корректность завершения вызова
  • 3 — вызов отвечен и корректно завершен
  • 2 — вызов отвечен, но одна из сторон не ответила на bye
  • 1 — вызов отвечен, но не был отправлен bye
  • 0 — вызов не отвечен
sighup — единица, если статистика внесена в БД во время завершения работы программы. В этом случае запись может отображать неполную статистику для данного  вызова

Далее следует статистика по RTP потокам от стороны A и B, названия параметров именуются соответственно, начинаясь с буквы a или b. Сохраняются лишь статистика по двум RTP потокам, которые содержат наибольшее количество пакетов:

a_index — индекс rtp потока, для A стороны — 0, для B — 1
a_payload — Тип полезной нагрузки (кодек), 0 если тип неизвестен. Соответствует типу применяемому в SDP.
a_saddr — Последний IP адрес источника RTP
a_received — Общее количество полученных пакетов
a_lost — Общее количество пропущенных пакетов (в соответствии с RFC 1889)
a_ua — Значение поля User-Agent передаваемого в SIP сообщении
a_avgjitter — Среднее значение джитера
a_maxjitter — Максимальная величина джитера
a_sl1-10
Подсчет потери RTP пакетов по количеству последовательно утерянных пакетов. Если последовательно утеряно более 10 пакетов — увеличивается параметр a_sl10
величина a_sl10
a_d50, a_d70, a_d90, a_d120, a_d150, a_d200, a_d300
Задержка при передачи последующего RTP пакета. Задержки до 50 мс не учитываются, задержки больше 300 мс записываются в одну категорию.

Последняя серия параметров отображает результат эмуляции джитер буфера в нескольких вариантах:

  • f1 — подсчет ведется при использовании фиксированного джитер буфера jitter_max = 50, jitter_resync_threshold = 50
  • f2 — подсчет ведется при использовании фиксированного джитер буфера jitter_max = 200, jitter_resync_threshold = 200
  • adapt — подсчет ведется при использовании адаптивного джитер буфера jitter_max = 500, jitter_resync_threshold = 500
a_mos_X — расчетная величина mos
a_lossr_X — процент потери пакетов (независимая модель / модель Бернули)
a_burstr_X — характеристика потери пакетов по модели Гилберта (burst rate)

Похожие сообщения:

автор igorg \\ теги: , , , , , , ,