Односторонняя слышимость: где ломается RTP при NAT и почему STUN не всегда спасает

Односторонняя слышимость: где ломается RTP при NAT и почему STUN не всегда спасает

Односторонний звук почти всегда означает, что SIP-сигнализация дошла, а RTP-поток застрял на маршруте. Типичный сценарий: INVITE/200 OK проходят, SDP содержит приватный адрес, и медиапоток уходит в никуда. Разбираем дамп трафика в Wireshark, и вот что мы там видим: signaling жив, media dead.

Причины обычно три:
— NAT подменяет адрес, но в SDP остаётся внутренний IP
— firewall пропускает SIP, но режет UDP-диапазон RTP
— endpoint шлёт media с одного порта, а получает на другой из-за symmetric NAT

STUN помогает только если клиенту нужно узнать внешний адрес и порт для публикации в SDP. Он бесполезен, когда NAT симметричный, когда между узлами несколько трансляторов или когда трафик идёт через CGNAT. В этих случаях нужен TURN: он не «чинит» NAT, а выносит RTP через relay, делая маршрут предсказуемым. Для WebRTC это часто единственный стабильный вариант.

На стороне SIP-платформы проверьте: rport и symmetric RTP, корректный rewrite SDP, pinhole для UDP, таймауты NAT-таблиц и совпадение RTP-порта с разрешённым диапазоном. Если Asterisk/FreeSWITCH видит пакет только в одну сторону, ищите асимметрию маршрута: иногда media уходит через один WAN, а ответ возвращается через другой.

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