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

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

Односторонний звук почти всегда связан не с SIP-сигнализацией, а с тем, куда именно уходит RTP. Типовой сценарий: INVITE/200 OK проходят, вызов устанавливается, а аудио идет только в одну сторону. Разбираем дамп трафика в Wireshark, и вот что мы там видим: в SDP указан приватный адрес 192.168.x.x или 10.x.x.x, а удаленная сторона пытается слать RTP именно туда.

Основные причины:
• NAT переписывает только SIP-порт, но не RTCP/RTP-диапазон
• телефон за symmetric NAT не принимает входящий RTP без предварительного исходящего пакета
• в SDP объявлен неверный c= и m= адрес, а SBC/шлюз не подменяет его
• firewall пропускает SIP, но режет UDP-порты медиапула

STUN решает только обнаружение внешнего адреса клиента и подходит, если NAT предсказуемый. Он не пробивает связь сам по себе: клиент все равно должен корректно объявить внешний IP и открыть медиасессию исходящим пакетом. TURN нужен, когда прямой P2P-маршрут нестабилен или невозможен: тогда медиа релейится через сервер, и оба конца видят один и тот же публичный anchor. Это дороже по трафику, но резко снижает процент “я слышу, меня нет”.

На практике проверяйте три точки: 1) SDP до и после NAT, 2) совпадение RTP-портов с разрешенным диапазоном на firewall, 3) есть ли симметрия в маршруте медиа. Если у вас Asterisk, FreeSWITCH или Kamailio, смотрите, кто именно переписывает SDP и не отключен ли rport/ symmetric RTP. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Если односторонняя слышимость повторяется, лечите не “звонок”, а медиа-путь: сначала SDP, потом NAT, затем relay через TURN или SBC.