Я понимаю, что этот вопрос довольно "необычный", но - имел ли кто-нибудь успех с VOIP через SIP за SonicWALL. У нас возникла проблема с односторонним входящим аудио.
По сути, звонящий (или вызываемый) человек может слышать меня (по телефону в той же локальной сети, что и УАТС), но мы не слышим их. Захваты пакетов показывают, что RTP-трафик возвращается к Sonic и предназначен для PBX, но он просто не может его достичь. Насколько я понимаю, SonicWALL использует симметричный NAT, и это проблема, поскольку STUN не работает с этим типом NAT.
Есть ли какое-нибудь обходное решение или кто-нибудь здесь с успехом?
У меня была такая же проблема с моей системой VoIP, есть две темы, которые вы можете использовать для восстановления.
Я решил свою проблему с туннелем P2P (IP-IP) с помощью Mikrotik и решил проблему со статическим маршрутом.
В главном меню sonicwall должна быть вкладка «VoIP». Выбрано ли "Включить согласованный NAT"? Это поможет. Вам не нужны преобразования SIP, но если вы можете опубликовать снимок экрана или этот экран, мы можем попробовать несколько вещей.
Если это sip-транк, вы можете обойтись без сообщения вашей УАТС, что ее IP-адрес является вашим «внешним» IP, и перенаправив на нее tcp / 5060 и udp / [диапазон rdp] в sonicwall. Диапазон rtp можно настроить на вашей АТС. Поскольку вам нужна только одна конечная точка sip (АТС - все ваши телефоны общаются с внешним миром через АТС), это не требует оглушения или чего-то «умного».
Похоже, вы уже сделали первый бит, если rtp-трафик действительно достигает вашего sonicwall, а не просто попадает в черную дыру, потому что он отправляется на адрес rfc 1918.
Убедитесь, что он поддерживает sip alg, и убедитесь, что вы используете стандартный порт sip (5060), или измените sip alg на «мониторинг» порта sip, который вы используете.
Расон для одностороннего звука связан с тем, что брандмауэр / маршрутизатор знают, куда отправлять входящие сообщения udp / аудио, и поэтому его сбрасывают.
Если включен sip alg, он будет отслеживать телефонные звонки и куда отправлять звук.