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

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

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

Схема проверки всегда одна:
— сравнить c= и m= в SDP с реальным адресом клиента;
— посмотреть, открывается ли обратный RTP-порт на NAT;
— проверить симметричный RTP и фиксацию source IP/port на SBC или B2BUA;
— убедиться, что firewall не режет UDP-таймаутом сам медиапоток.

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

Разбираем дамп трафика в Wireshark, и вот что мы там видим: если INVITE приходит с одного адреса, а RTP — с другого, значит нужно смотреть pinhole, keepalive и корректность rewrite контактных адресов на границе сети.

Практика простая: для внешних клиентов включайте ICE/STUN, для проблемных сетей — TURN, а на ядре инфраструктуры полагайтесь на SBC с нормальным NAT traversal. Иначе вы будете чинить «нет звука» там, где проблема уже давно в маршрутизации пакетов.