RTCP-XR и MOS в Grafana: как не превратить мониторинг голоса в набор красивых, но бесполезных графиков

RTCP-XR и MOS в Grafana: как не превратить мониторинг голоса в набор красивых, но бесполезных графиков

Если в SIP-сети смотреть только на 200 OK и up/down у Asterisk, деградацию качества вы пропустите. Для голоса нужны метрики на уровне RTP/RTCP: packet loss, jitter, round-trip delay, concealment, burst loss, MOS/poor call rate. Разбираем дамп трафика в Wireshark, и вот что мы там видим: сигнализация жива, а медиа уже разваливается.

RTCP-XR удобен тем, что переносит в телеметрию не только базовые RTCP-поля, но и расширенные отчёты по качеству потока. Практика простая: собирайте event-driven метрики с SBC, media relay или шлюза, нормализуйте их в Prometheus и строьте не один общий график, а отдельные time series по caller/callee, trunk, codec и direction. Иначе средняя MOS по узлу замаскирует проблемы на конкретном маршруте.

В Grafana полезно держать минимум такой набор:
• MOS, jitter, packet loss, one-way delay
• количество вызовов с деградацией выше порога
• распределение по кодекам и транкам
• корреляцию с CPU, NIC drops, retransmits и очередями на медиа-интерфейсе

Главная ошибка — считать MOS “истиной”. Это производная метрика, и она должна читаться вместе с первичными параметрами RTP. Если MOS падает при нормальном loss, ищите джиттер-буфер, асимметрию маршрута, QoS на L3/L4 или перегрузку медиасервера. Если падает только на одном направлении — проверяйте NAT, SIP ALG и маршрутизацию RTP отдельно для каждого плеча.

Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Делайте алерты не по одной метрике, а по комбинации: рост loss + jitter + снижение MOS на конкретном trunk. Тогда мониторинг покажет не факт аварии, а место, где ломается качество.