RTCP для автоматического контроля качества VoIP-соединений и уведомления о проблемах

В статье будет рассмотрен протокол RTCP (Real-Time Transport Control Protocol) — протокол управления передачей в реальном времени, который используется совместно с RTP, суть работы данного протокола в том что он периодически рассылает управляющие пакеты всем участникам вызова.

Для начала необходимо внести рефренсные значения параметров, на которые можно опираться при анализе качества связи.

Основной параметр — это потеря пакетов (Packet Lost): для приемлемого качества связи должно быть менее 1%, предпочтительно даже не превышать 0,5%,  при превышении порога в 3% заметно ухудшение связи, но еще не критично, при превышении 10% качество становится практически полностью неприемлемым.

Существует два варианта мониторить показатели RTCP:
1) прослушивая и собирая AMI события
2) при выполнении Hangup получать и анализировать показатели RTCP напрямую в диалплане

Далее будут рассмотрены оба варианта.

Прослушивание AMI событий.

В данном варианте интересны следующие события (AMI Events):

— RTCPSent — событие отправки RTCP
— RTCPReceived — событие получения RTCP

Для тестирования была создана учетка AMI в которой с помощью eventfilter были отфильтрован показ только событий связанных с RTCP

Для более детального ознакомления с AMI рекомендуем ознакомиться со статьей: https://voxlink.ru/kb/book/interfejs-upravlenija-asterisk-ami/

На скриншоте ниже представлен пример учетки AMI c фильтрацией событий.

Далее будет рассмотрены события RTCP, приходят они в виде как указано на скриншоте:

Для оповещений интересны следующие поля:
Channel: — отслеживаемый канал
SentPackets: — количество отправленных пакетов
Report0CumulativeLost: — количество пакетов потерянных с начала вызова

To: — адрес назначения
From: — адрес источника

RTT: — Round Trip Time — время приема передачи, время задержки передачи между двумя точками, состоит из времени, затраченного на отправку сигнала и времени получения подтверждения, значение RTT менее 200-250 мс указывает на нормальное качество связи.

Самая простая формула аппроксимированного вычисления процента потерь выглядит следующим образом Lost = Report0CumulativeLost * 100 / SentPackets, анализируя это значение, можно высылать уведомления при превышении определенного процента потерь на канале.

Второй способ более простой, он заключается в анализе определенных переменных получаемых с помощью функции CHANNEL, для их получения переменная вызывается в следующем виде:
${CHANNEL(ARG1,ARG2,ARG3)},

в большинстве случаев аргументы будут следующие: ARG1 — rtpqos. ARG2 — audio, ARG3 — интересующие параметры

Ниже показано как получить эти параметры:
RTT — ${CHANNEL(rtpqos,audio,rtt)} — круговая задержка
To: ${CHANNEL(rtpdest,audio)} — адрес назначения
From: ${CHANNEL(rtpsource,audio)} — адрес источника
Packets Sent: ${CHANNEL(rtpqos,audio,txcount)} — количество отправленных пакетов
Packets Received: ${CHANNEL(rtpqos,audio,rxcount)} — количество полученных пакетов
Local RX Packet Loss: ${CHANNEL(rtpqos,audio,rxploss)} — количество потерянных полученных пакетов
Local TX Packet Loss: ${CHANNEL(rtpqos,audio,txploss)} — количество потерянных отправленных пакетов

Исходя из этих значений также можно посчитать приблизительный процент потерянных пакетов:

TX_Loss=  txploss * 100 / txcount
RX_Loss = rxploss * 100 / rxcount

Эти данные лучше всего получать при выполнении завершения вызова (Hangup), для этих целей служит навешивание на канал hangup_handler`а. Подробнее об этом методе можно прочитать в статье: https://voxlink.ru/kb/asterisk-configuration/mehanizm-hangup-handler-v-asterisk/

Ниже приведен пример диалплана, выполняющего проверку параметров и отправку оповещения на email, для подключения hangup-handler`а на канал оператора связи, при вызове в транк выполняется вызов sub-set-handler, через опцию Dial`а U.

[outbound]
exten => _8XXXXXXXXXX,1,Noop()
same  => n,Dial(SIP/operator/${EXTEN},30,TtrU(sub-set-handler,s,1))
same  => n,Hangup()

[sub-set-handler]
exten => s,1,Set(CHANNEL(hangup_handler_push)=sub-rtcp-handler,s,1)
same  => n,Return()

[sub-rtcp-handler]
exten => s,1,NoOp(Start QoS ${CHANNEL(peername)})
same  => n,Set(TX_PLOS=${CHANNEL(rtpqos,audio,txploss)})
same  => n,Set(RX_PLOS=${CHANNEL(rtpqos,audio,rxploss)})
same  => n,Set(TX_COUNT=${CHANNEL(rtpqos,audio,txcount)})
same  => n,Set(RX_COUNT=${CHANNEL(rtpqos,audio,rxcount)})
same  => n,Set(TX_LOSS_PERC=$[${TX_PLOS}*100/${TX_COUNT}])
same  => n,Set(RX_LOSS_PERC=$[${RX_PLOS}*100/${RX_COUNT}])
same  => n,Noop(RX_LOSS_PERC: ${RX_LOSS_PERC}  TX_LOSS_PERC: ${TX_LOSS_PERC})
same  => n,ExecIf($[$["${RX_LOSS_PERC}" != "0" | "${TX_LOSS_PERC}" != "0"]]?System(/usr/local/bin/sendEmail.pl -f [email protected] -t [email protected] -u "Packet Loss on trunk ${CHANNEL(peername)}" -m "RX Packet Loss ${RX_LOSS_PERC} TX Packet Loss ${TX_LOSS_PERC} on trunk ${CHANNEL(peername)}" -o message-charset=UTF-8))
same  => n,Return()

На скриншоте ниже показан лог вызова в котором были потери пакетов: