Односторонняя слышимость в SIP/WebRTC: где ломается NAT и как чинят STUN/TURN

Односторонняя слышимость в SIP/WebRTC: где ломается NAT и как чинят STUN/TURN

Если абонент слышит оператора, а в ответ — тишина, проблема почти всегда не в кодеке, а в пути RTP. Сигнализация SIP может проходить нормально, но медиапоток упрётся в NAT: в SDP уезжает приватный адрес, а удалённая сторона шлёт RTP “в никуда”.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: INVITE идёт с Contact и c= на 192.168.x.x, ответ приходит, но RTP не появляется на внешнем интерфейсе. Типовой набор причин: неверный rewritten address на SBC, отключённый symmetric RTP, таймаут NAT-мэппинга, hairpinning, а также firewall, который разрешил SIP, но режет UDP-порт медиаканала.

STUN нужен только чтобы узнать внешний mapped address и порт; он не проксирует медиа и не лечит CGNAT. TURN — это уже relay: клиент шлёт RTP на релей, а тот доставляет поток второй стороне. Для браузеров и сетей с агрессивным NAT это часто единственный стабильный путь. В Asterisk/FreeSWITCH критично проверить external address, local nets, RTP port range и keepalive, иначе через 30–60 секунд NAT-сессия просто схлопывается.

Практика такая: для SIP-транка включайте symmetric RTP, корректный SDP rewrite и фиксированный диапазон RTP; для WebRTC — ICE с STUN/TURN, при этом TURN держите как fallback, а не как основной маршрут. Если односторонняя слышимость плавает, первым делом сравните SIP trace и RTP capture на обеих сторонах: сигнализация может быть идеальной, а медиа — уже потеряно.

Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Если RTP не проходит предсказуемо, сначала чинят маршрутизацию медиапотока, потом уже кодеки и настройки АТС.