Итак, как оказывается, за нас уже все придумали, нам лишь нужно взять инструмент в руки и адаптировать его под себя. Нам понадобиться Asterisk версии старше 11 и умение немного программировать. Краткая справка от вики:
RTCP (англ. Real-Time Transport Control Protocol — протокол управления передачей в реальном времени) — протокол, используемый совместно с RTP. Протокол описан в RFC 3550,[1]. RTCP базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных.
Протокол RTCP используется для передачи информации о задержках и потерях медиа-пакетов, джиттер-буфере, уровне звукового сигнала. Также передаются метрика качества сигнала (Call Quality Metrics) и Echo Return Loss.
Начиная с 11 версии, астериск через AMI присылает событие RTCPReceived и RTCPSent. Наиболее интересно для нас RTCPReceived, поскольку оно несет важную для нас информацию.
Выглядит оно так:
Event: RTCPReceived
privilege: reporting,all
sequencenumber: 23177
file: manager.c
line: 1696
func: manager_default_msg_cb
channel: SIP/MainAsterisk-0000113f
channelstate: 6
channelstatedesc: Up
calleridnum: 79914099
calleridname: RC
connectedlinenum: unknown
connectedlinename: unknown
language: ru
context: TO_REGION
exten: 680000130
priority: 1
uniqueid: 1481711487.11714
linkedid: 1481711487.11714
to: Адрес астериска:12611
from: Адрес пира:14555
rtt: 0.0272
ssrc: 0x73f52b22
pt: 200(SR)
reportcount: 1
sentntp: 1481712636.17532474232832
sentrtp: 9159680
sentpackets: 57246
sentoctets: 9159360
report0sourcessrc: 0x3098e4b3
report0fractionlost: 0
report0cumulativelost: 0
report0highestsequence: 7177
report0sequencenumbercycles: 1
report0iajitter: 3
report0lsr: 2726085614
report0dlsr: 0.0590
Интересные для нас поля:
channel — имя ассоциированного канала
from — IP удаленного пира
rtt — «задержка», точнее круговая задержка
sentpackets — колличество отправленых пакетов
sentoctets — колличество байт отправленых
report0cumulativelost — количество потерянных пакетов, с начала сессии
Схема хождения пакетов RTCP:
R-Фактор lite
Конечно, интересно получить итоговое качество канала в виде %. Для этого есть два параметра:
R-фактор и MOS. Более подробно ознакомиться сними можно тут.
Вычислить их точно мы, конечно же не можем, но можем сделать свою lite-вресию.
Общий алгоритм вычисления может выглядеть так:
— Считаем максимальную задержку (RTT) на всех плечах и берем за аксиому, что проблемы со слышимостью начинаются при 1000 мс.
— Считаем процент потерь (максимальный) и берем за аксиому, что при 40 процентах качество связи не приемлемое.
Итого, вычисление R-фактора может выглядеть так:
R=100-(MaxRTT/10+2*MaxLostPackets)
Оценка:
80-100% — хорошее качество звука
60-79% — удовлетворительно
<60% — Качество звука ужасное
Где применить?
На данный момент «играемся» с этим. Была написана программа для визуальной оценки.
Кроме того есть в планах вычислять автоматически для каждого звонка и класть в CDR дополнительным полем, что позволит оценить не только качество определенного звонка, но и направлений в целом в разрезе временных периодов.
Ссылка на программу
Проверенно для Asterisk 13, будет ли работать в младших версиях — не знаю.
UPD:
Как положить вычисленное значение в CDR?
На самом деле тут все проще, чем кажется. Не нужно делать интеграцию в своем скрипте или программе с базой данных и делать UPDATE. Достаточно после каждого вычисления R-фактора через тот же AMI интерфейс установить канальную переменную:
Action: Setvar
Channel: Имя канала, для которого вычислили R-фактор
Variable: CDR(r-factor)
Value: Значение, которое вычислили
И если в таблице CDR, есть столбец r-factor, оно заполниться этим значением. Кончено же, в эту переменную лучше класть усредненное значение за весь звонок.
Комментарии (11)
sergarcada
16.12.2016 14:54Это все интересно. НО:
1. Непонятно, как включить в астериске поддержку rtcp. Или с 11-й версии она там включена по умолчанию?
2. … астериск через AMI присылает событие RTCPReceived и RTCPSent. — присылает куда? кому? где это посмотреть?
3. Программа (под windows?) у меня вообще не запускается.
Итог: все, что я понял из статьи — есть такая штука rtcp и ей надо пользоваться.
xomiakba
16.12.2016 15:211. Особых телодвижений делать не нужно, все уже сделано… за нас, разработчиками.
2. Посмотреть — легко. Заводите пользователя в manager.conf в Asterisk по образцу. Далее делаете:
telnet localhost 5038
после приглашения, авторизуетесь:
Action: Login
Username: Имя пользователя
Secret: Пароль пользователя
Events: on
Два раза нажимаете Enter и погружаетесь в увлекательный мир AMI event's.
3. — Фи, Windows? Не совсем понял, что Вы хотели этим сказать. Проверил ссылку — работает. Вполне возможно, она запуститься не у всех (требует SSL библиотек, у нас на предприятии только SSL возможен, если касаемся передачи авторизации — но на большинстве компьютеров работает), писалось оно для визуализации RTCP на тестовом стенде, чтобы сделать вывод — оно нам вообще нужно. Потрогали — нужно.sergarcada
16.12.2016 15:36-1Ок, допустим в реальном времени я могу посмотреть. А как насчет логов? Почему и спрашиваю про windows — если астериск крутится на линуксе, то что я увижу в вашей программе? Хотя бы скриншот приложили бы.
Я сам телефонией на предприятии не занимаюсь, для этого у нас есть «специально обученный человек». И мне нужна какая-то информация, чтобы я с ним мог поговорить на общем языке. Понять, используется ли это уже у нас и можно ли, например, как-то это прикрутить к zabbix для полноты картины.xomiakba
16.12.2016 15:46Программа работает через сеть, сам астериск может находиться хоть в Китае. AMI это текстовый сетевой протокол поверх TCP/IP.
Акцентирую внимание на том, что эта программа — просто демка, а не готовый рабочий продукт для мониторинга.
Что касается заббикса, можно написать скрипт, например на том же perl, который будет вычислять R и отдавать забиксу через агент. Но тогда Вы не получите привязку к конкретным звонкам, а сам график качества звонков не сильно интересен со статистической точки зрения без привязки к направлениям.sergarcada
16.12.2016 15:56-1Понятно. То есть если мне скажут, что «вот только что звонил — связь была ужасна, сделай что-нибудь с инетом», то я уже не могу посмотреть что же там было с прошедшим звонком. А сама ваша программа не более чем парсер текущего потока. Ну что ж, теперь хотя бы понятно о чем речь.
xomiakba
16.12.2016 16:16Суть статьи не в программе, суть в том чтобы обозначить достаточно эффективный инструмент — а именно протокол RTCP.
Как я уже писал в статье — данный параметр можно писать в CDR, что позволит смотреть в истории качество отдельных звонков и целых направлений.sergarcada
16.12.2016 20:19-1Обозначить — это хорошо. Но неплохо было бы объяснить что к чему, как этим пользоваться и какие есть сценарии, что и как вы использовали в своей работе. Для меня ваша статья получилось вообще ни о чем. Можно было бы свести к двум словам — RTFM RTCP. Как я уже сказал, сам я имею лишь косвенное отношение к телефонии на своем предприятии. Но что я могу сказать связисту? «Вот посмотри по этим ключевым словам...»?
Тема потенциально интересная. Я ожидал от статьи большего.xomiakba
19.12.2016 09:35лишь косвенное отношение к телефонии на своем предприятии.
Но что я могу сказать связисту
Обычно в этом случае советуют ничего связисту не говорить :)
Иначе может случиться беда.
neumeika
16.12.2016 16:17R Factor сильно lite :) но всё равно спасибо. Рассмотреть бред вида PESQ, POLQA, AQuA не желаете?
Про мониторинг транков не рассказали (rtpqos и кучка параметров, хотя, возможно, уже многое поменялось) :(
Уважаемые воипщики, обратите внимание на эту статью, почитайте про voipmonitor.
Ибо по моим данным 95% не знает что это, считать не умеют, а мониторинг звонков у большинства выглядит как разбор полётов после жалобы от клиентов, никакой проактивщины.
Emily_Rose
Вторая стаття уже от вас, что то дельное и не затёртое по астериску, спасибо. Вот только мне не ясно чего вы call legs плечами называете, первый раз такое слышу. Пишите еще, сам с Астериском уже 7 лет роботаю, у вас полезные статти. Очень жаль что в астере поддержка RTCP стандартов хилая.