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

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

Для SIP-платформы недостаточно считать только CPS, ASR и количество активных каналов. Качество голоса ломается раньше: растёт jitter, появляются потери RTP, сдвигается one-way delay — и только потом приходит тикет. Поэтому в контур наблюдаемости нужно тащить RTCP-XR, MOS, packet loss, jitter buffer under/overruns и R-factor, а не ограничиваться статусом транков.

Схема рабочая: Asterisk/FreeSWITCH/Kamailio отдают события в экспортер, экспортер публикует метрики в Prometheus, а Grafana собирает их в один дашборд с разрезом по trunk, codec, destination, NAT-площадке и медиасерверу. Для алертов лучше смотреть не абсолютный MOS, а отклонение от базовой линии по конкретному маршруту: один и тот же кодек на LAN и через VPN ведёт себя по-разному.

Полезный минимум для метрик:
— rtp_packet_loss_ratio
— rtp_jitter_ms
— rtcp_xr_mos
— rtcp_xr_r_factor
— call_duration_seconds
— media_retransmits_total
— no_rtp_timeout_total

В Grafana держите не только графики, но и таблицу топ-N маршрутов с худшим MOS за окно времени. Это быстро показывает, где деградирует SBC, где перегружен медиасервер, а где проблема в последней миле или в неверном QoS на пограничном роутере. Разбираем дамп трафика в Wireshark, и вот что мы там видим...

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