Как мониторить качество голоса: RTCP-XR, MOS и метрики SIP/RTP без слепых зон

Качество VoIP нельзя оценивать только по доступности SIP. Нужны метрики, которые видят сам голосовой тракт: packet loss, jitter, RTT, concealment, post-dial delay и расчетный MOS. Разбираем дамп трафика в Wireshark, и вот что мы там видим: сигнализация может быть чистой, а RTP уже деградирует.

RTCP-XR дает прикладные показатели качества на уровне сессии: burst loss, gap loss, round trip delay, jitter buffer, VoIP metrics. Если шлюз, SBC или B2BUA умеет экспортировать эти данные, их стоит нормализовать в Prometheus как labels: trunk, endpoint, codec, direction. Не пытайтесь строить графики только по среднему MOS — усреднение скрывает краткие провалы, которые и ломают восприятие абонента.

В Grafana полезно собирать не одну панель, а связку:
— SIP response codes и долю 4xx/5xx/6xx;
— RTP loss, jitter, packet reorder, out-of-order;
— RTCP-XR MOS, R-factor, burst metrics;
— ASR, ACD, one-way audio, post-dial delay.
Так видно, где проблема: в маршрутизации, в медиапути, в NAT или в перегрузе транка.

Для Prometheus лучше отдавать метрики из edge-компонента: Kamailio, Asterisk, FreeSWITCH, RTPproxy, SBC. Если источник не умеет RTCP-XR напрямую, можно парсить CDR/AMI/ESL или логи медиасервиса и публиковать агрегаты через exporter. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Порог тревоги задавайте не по одному числу, а по сочетанию: рост loss + рост jitter + падение MOS на одном trunk. Тогда алерт ловит деградацию до того, как абоненты начнут жаловаться.