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

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

Чаще всего симптом один: вызов устанавливается, SIP 200 OK проходит, а RTP идёт только в одну сторону. Причина почти всегда в том, что сигнализация и медиа проходят разными путями, а NAT переписывает адреса в SDP или режет «молчащий» UDP-сеанс по таймауту.

Проверка начинается не с SIP, а с RTP:
— в SIP/SDP смотрим, какой IP и порт отданы под медиа;
— в Wireshark сверяем, совпадает ли c= и m= с реальным адресом клиента;
— проверяем symmetric RTP, rport, comedia и корректный keepalive;
— убеждаемся, что firewall не закрывает обратный поток после первой пачки пакетов.

STUN полезен только когда клиенту нужно узнать внешний адрес и порт для регистрации медиа-сессии. Но если за NAT несколько уровней, есть CGNAT или медиапуть должен проходить через жёсткий firewall, STUN даст лишь частичное решение. Тогда нужен TURN: он не «чинит» NAT, а становится relay-узлом, через который оба направления гарантированно проходят.

На стороне SBC или Asterisk обычно спасает принудительная подмена адресов в SDP, включение RTP relay и строгая фиксация портового диапазона. Для WebRTC без TURN односторонняя слышимость почти гарантирована в сложных сетях: браузер может отправлять ICE candidates, но выбирать будет только те, что реально достижимы.

Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Схема диагностики простая: сначала трассируем SIP, потом RTP, затем проверяем NAT-таймауты и только после этого трогаем STUN/TURN. Именно так находят проблему, а не маскируют её переадресацией медиа.