SIP ALG против SIP Helper

У тебя есть пример? Я тщательно проверял это некоторое время назад и обнаружил только одну проблему, о которой расскажу позже, если она отличается от твоей. Просто интересно, не пропустил ли я что-то. В целом у меня всё работает нормально, серьёзных проблем нет.

Думаю, он перехватывает SIP-сообщения на настроенных портах и меняет локальные IP на публичные адреса в полях Contact, Via и т.п. Также он меняет адрес медиапотока в SDP, так что можно не париться с STUN и подобным. Но при этом он не помогает с входящими медиапотоками, поэтому нужно задавать диапазон портов для RTP на вашем SIP-клиенте и делать dst-nat на клиент.

У меня никогда не было проблем при включённом SIP helper. Я решил проблему с VoIP, используя ROS с SIP helper, в то время как Watchguard X550 с этим не справился.

Очень полезно. Я не знаком с этой функцией SIP в конфигурации MT.

Не только это, но и RFC довольно открыта для интерпретации (по крайней мере, так говорили мне инженеры из нескольких разных SIP-вендоров), потому что протокол слишком общий. (например, именно он стал отправной точкой для старого клиента MSN Messenger). В общем, желательно, чтобы обход NAT выполнял только один устройство. Если таких устройств несколько, ситуация может потихоньку скатываться в странности. (я называю это «забытыми телефонами»). К примеру, наш SIP-шлюз распознавал телефоны за NAT и разрешал «короткое замыкание» (short circuit) — если два телефона в одной виртуальной АТС пытались позвонить «от внутреннего номера к внутреннему» и он видел, что они за одним NAT, то направлял их использовать друг у друга приватный IP как адрес для медиапотока. Но ALG видел этот SIP-сообщение с приватным IP для медиапотока и изменял его на какой-то другой IP (либо SIP-шлюза, либо самого роутера), и из-за этого ломался звук… SIP-шлюз реально хотел, чтобы телефон посылал медиа на приватный IP, а ALG решал «помочь» и скрывал этот IP в сообщениях до того, как они доходили до телефонов… Иногда же некоторые конечные устройства считали, что они зарегистрированы, а сервер думал, что они оффлайн. Иногда телефон звонил, а когда пользователь нажимал принять — ничего не происходило, звонок продолжал идти, или он слышал короткий гудок занятости, а вызывающий при этом слышал гудки вызова… Короче, ALG нужен только если у вас клиентов SIP, стоящих за NAT, которые не умеют сами обходить NAT, и при этом они разговаривают с другими простыми SIP-устройствами, которые тоже не пытаются обойти NAT.

Много непоняток с sip alg. Насколько я понимаю, это никак не связано с записью sip в service ports. Это порты, на которых MT слушает входящие INVITE. Sip alg — это настройка в вашем шлюзовом роутере (если, конечно, вы не используете pppoe на MT). Работает она примерно как STUN — заменяет ваши приватные адреса в sip-пакетах на публичный адрес роутера. Это может обмануть вашего VoIP-провайдера, заставив его думать, что sip-клиент не за NAT, и тогда аудиопорт в SDP используется провайдером для RTP.

Если же sip-клиент находится за NAT, то NAT может изменить ваш локальный порт на другой публичный, и тогда может возникнуть односторонний звук. Если в sip-пакете остается локальный приватный адрес, провайдер понимает, что вы за NAT, и игнорирует порт из SDP, ожидая первых RTP-пакетов, чтобы узнать, с какого публичного порта они приходят, и начинает отправлять RTP туда. Не все VoIP-провайдеры ведутся на это, но на всякий случай лучше отключить sip alg в вашем роутере.

Я только что провёл презентацию по теме SIP ALG на Mikrotik MUM в Денвере, Колорадо, в 2017 году, где подробно объяснил всё, что связано с SIP ALG в RouterOS. Смотрите здесь: https://youtu.be/tM7wyKdnIKA