RTCP-XR и MOS: как измерять качество голоса, а не гадать по жалобам

RTCP-XR и MOS: как измерять качество голоса, а не гадать по жалобам

Если в мониторинге есть только SIP 200 OK и uptime, вы видите доступность, но не качество. Для голосовой платформы нужны минимум три слоя метрик: сигнализация, RTP и end-to-end качество. RTCP-XR дает структурированный отчет по потерям, джиттеру, round-trip delay и speech quality; MOS — удобная сводная оценка для дашборда и алертов.

Схема простая: SBC, Asterisk или FreeSWITCH собирают RTCP/RTCP-XR, нормализуют поля в exporter и отдают в Prometheus. В Grafana полезно строить не один красивый график, а связку: jitter, packet loss, one-way delay, post-jitter loss, MOS по направлениям и по trunk’ам. Так сразу видно, где деградация: у абонента, в ядре, на транке или на NAT-пути.

Критичные правила:
— не смешивайте inbound и outbound в одну метрику, иначе потеря направления убьет диагностику;
— отдельно считайте по codec payload, потому что G.711 и Opus ведут себя по-разному;
— алертите не по среднему MOS, а по p95/p99 и длительности деградации;
— коррелируйте качество с SIP-ошибками 4xx/5xx и ростом retransmit в signaling. Разбираем дамп трафика в Wireshark, и вот что мы там видим...

Если RTCP-XR недоступен, собирайте хотя бы RTP-статистику на медианоде и экспортируйте packet loss/jitter в Prometheus. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.