<b>Как связать RTCP-XR, MOS и Prometheus, чтобы видеть деградацию голоса до жалоб абонентов</b>

<b>Как связать RTCP-XR, MOS и Prometheus, чтобы видеть деградацию голоса до жалоб абонентов</b>

Качество голоса нельзя мерить только по «вызов упал / не упал». Для SIP-платформы нужны метрики на уровне RTP-сессии: packet loss, jitter, RTT, burst loss, discard rate и оценка MOS. RTCP-XR здесь полезен тем, что дает не усреднённую картину, а профиль деградации по конкретному плечу медиа.

Схема обычно такая: SBC, Kamailio или шлюз собирает RTCP/RTCP-XR, нормализует поля в текстовый формат и отдает их в exporter. Дальше в Prometheus уезжают метрики вида call_rtp_jitter_ms, call_rtp_loss_percent, call_rtp_mos, call_rtcp_rtt_ms. Главное — не смешивать показания по codec, direction и trunk, иначе Grafana покажет красивую, но бесполезную кашу.

Полезные правила:
• хранить метки trunk, codec, site, direction;
• строить не только average, но и p95/p99 по jitter и RTT;
• алертить по сочетанию loss + jitter + MOS, а не по одному порогу;
• отдельно считать долю звонков с деградацией, а не только среднее MOS 📊

Если есть только сигнал MOS, без контекста сети, диагностика будет слепой. Низкий MOS может быть следствием NAT timeout, asymmetric routing, перегруза очереди на WAN или неправильного ptime. Разбираем дамп трафика в Wireshark, и вот что мы там видим: RTP идет стабильно, а RTCP reports показывают рост jitter bursts на одном сегменте.

Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Стройте дашборд так, чтобы он отвечал на три вопроса: где деградация, на каком плече, и это сеть, кодек или маршрут.