Односторонняя слышимость почти всегда прячется в NAT, а не в SIP-сигнализации
Когда INVITE и 200 OK проходят, это ещё не значит, что RTP пойдёт в обе стороны. Типовая картина: в SDP уходит приватный адрес, медиапоток утыкается в NAT, а на стороне абонента слышен только один голосовой путь. Разбираем дамп трафика в Wireshark, и вот что мы там видим: сигнализация жива, а UDP-порты для медиа либо не проброшены, либо уже переписаны промежуточным устройством.
— STUN нужен только для обнаружения внешнего адреса и порта, когда NAT позволяет симметричный обмен без релея.
— TURN включается, когда прямой RTP нестабилен или невозможен: сервер становится медиатором и снимает зависимость от проброса портов.
— ICE полезен не сам по себе, а как механизм выбора лучшего кандидата: host, srflx, relay. Если relay не в приоритете, односторонняя слышимость вернётся.
На серверной стороне проверяйте: совпадает ли c= в SDP с реальным публичным адресом, не режет ли firewall диапазон RTP-портов, не включён ли symmetric RTP только наполовину. Для Asterisk и FreeSWITCH критично корректно задать external/public IP и локальные сети, иначе PBX будет рекламировать внутренний адрес наружу. На шлюзах и SBC не экономьте на keepalive: NAT-мэппинг должен жить дольше пауз между пакетами.
Если связь ломается только через мобильную сеть или домашний роутер, почти всегда виноват не SIP-логин, а медиа-путь. Лечится не «перезагрузкой», а дисциплиной: SDP-анализ, RTP-трассировка, STUN для диагностики, TURN для надёжного релея и жёсткий контроль портов на границе сети.
Работа с API телефонии
@phone_api_gateway_arb
Односторонняя слышимость почти всегда прячется в NAT, а не в SIP-сигнализации
Этот пост опубликован в Telegram-канале Работа с API телефонии. Подписаться можно по ссылке: @phone_api_gateway_arb.