<b>Односторонняя слышимость в SIP/WebRTC: где ломается RTP и как это чинить</b>

<b>Односторонняя слышимость в SIP/WebRTC: где ломается RTP и как это чинить</b>

NAT ломает не сигнализацию, а медиапоток: INVITE проходит, а RTP идёт в «чёрную дыру». Типовой сценарий — в SDP указан приватный IP, удалённая сторона шлёт аудио туда, где пакетам просто некуда вернуться. Разбираем дамп трафика в Wireshark, и вот что мы там видим: SIP-сессия установлена, но RTP идёт только в одну сторону.

Базовая проверка всегда одна и та же:
— в SDP должны быть корректные <code>c=</code> и <code>m=</code> поля;
— <code>rport</code>, <code>comedia</code>/<code>rewrite_contact</code> должны быть включены там, где endpoint сидит за NAT;
— на Asterisk/FreeSWITCH нужно контролировать, кто реально становится источником RTP, а не доверять адресу из SIP-заголовка.

STUN помогает клиенту узнать внешний адрес и порт, но только если NAT симметричный не режет сценарий. Для WebRTC это часто достаточно для установления прямого канала, но для корпоративных сетей с жёстким firewall нужен TURN: медиатрафик идёт через релей, и односторонняя слышимость исчезает за счёт предсказуемого пути пакетов.

Если проблема плавающая, ищите не «сбой звонка», а расхождение трёх вещей: SIP-сигнализация, SDP-адреса и фактический RTP-flow. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Оптимизируем обработку RTP-трафика и минимизируем джиттер в сети.

Практика простая: сначала докажите в pcap, куда уходит RTP, потом уже трогайте NAT, STUN или TURN. Без этого любые «переоткрытия портов» — это гадание, а не инженерная диагностика.