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

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

Если абонент слышит вас, а вы его — нет, проблема почти всегда в RTP-пути, а не в SIP-сигнализации. SIP может успешно пройти через прокси, а медиапоток застрянет на приватном адресе, из-за symmetric NAT, неправильного c= в SDP или отсутствия проброса портов на SBC/шлюзе.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: INVITE уходит, 200 OK приходит, но RTP-адрес в SDP указывает на 192.168.x.x или другой недоступный хост. Сервер отвечает на адрес из SDP, а клиент ждёт медиа на другом порту. Для диагностики проверяйте три точки: куда отправлен RTP, откуда он возвращается и совпадает ли источник пакетов с тем, что реально открылся в NAT-таблице.

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

Практика: на стороне Asterisk/FreeSWITCH/SBC фиксируйте правильный external address, включайте symmetric RTP, проверяйте rport, contact rewriting и keepalive для NAT-binding. На клиентах отключайте «умные» автонастройки, если они маскируют ошибку SDP. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Если RTP не проходит напрямую, сначала чините маршрут и только потом трогайте кодеки: в большинстве случаев односторонняя слышимость — это не аудиопроблема, а ошибка в медиатопологии.