Как измерять качество звонков в Prometheus: RTCP-XR, MOS и метрики, которым можно доверять

Как измерять качество звонков в Prometheus: RTCP-XR, MOS и метрики, которым можно доверять

RTCP-XR — это не «красивый бонус», а источник телеметрии о джиттере, потере пакетов, задержке и пост-обработке речи. Если эти поля не собрать на границе SIP/RTP, в Grafana останется только симптом: жалоба абонента на «металлический» голос или обрывы.

Схема рабочая: SBC, Kamailio или Asterisk экспортируют счетчики вызовов, а RTP-агрегатор или медиашлюз отправляет latency/jitter/loss в Prometheus. Для MOS не храните только одно число — держите исходные компоненты расчета, иначе вы не поймете, это деградация сети, кодека или NAT-таймаутов.

Что обязательно выносить в метрики:
• rtp_packets_lost_total, rtp_jitter_ms, rtp_rtt_ms
• rtcp_xr_fraction_lost, rtcp_xr_max_jitter, rtcp_xr_mos
• sip_calls_active, sip_calls_failed, rtp_oneway_audio_detected
• отдельные лейблы для trunk, codec, direction, media_node

В Grafana строят не один «средний MOS», а разрез по транкам, кодекам и медианодам. Среднее значение скрывает короткие провалы, а именно они рвут разговоры. Полезнее смотреть p95/p99 по MOS, корреляцию с packet loss и список вызовов, где RTP есть только в одну сторону.

Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Если алерт приходит только по падению SIP-сервиса, вы уже опоздали: алертить нужно по росту jitter, ухудшению MOS и всплеску one-way audio. Разбираем дамп трафика в Wireshark, и вот что мы там видим: проблема часто начинается задолго до полного отказа.

Практика простая: сначала нормализуйте метрики на стороне медиасервера, затем стройте SLO по качеству голоса, и только после этого добавляйте алерты. Иначе Prometheus будет считать всё, кроме реальной деградации разговора.