Re: _outboundsip._udp

От: German Myzovsky <CGatePro_at_mx_ru>
Дата: Wed 22 Feb 2006 - 11:59:42 MSK

>> Всё это имеет смысл при организации массовой услуги. Если нужно 
>> подключить одного клиента за пиксом, вышеперечисленные рассуждения -- 
>> блажь. Тем не менее, я бы дорого дал за то, чтобы иметь это знание год 
>> назад.

>
> Я не совсем понял, о каком знании идет речь. У этих продуктов есть
> сеттинг - "посылать внутренние IP". Если надежды та то, что они умеют
> делать NAT нет, то надо просто сказать "Never". Если надежды есть - то
> можно играть.

Всё верно. Это игра в сеттинги, которая не проходит именно в условиях массовой услуги. До запуска [русифицированного] автоконфигуратора мы хлебнули по полной программе. Другое дело, если UAC резолвит себе outbound, и дефолтные сеттинги отрабатывают как положено. Или явное указание outbound позволяет оставить в покое все остальные настройки. В конце концов, если UAC умеет разделять Registrar, Proxy и Outbound, значит какой-то интеллект присутствует. Почему бы не воспользоваться, вместо игры в более тонкие сеттинги?

>> to Vladimir: хорошо работающие STUN/uPnP NAT/SIP inspect лучше 
>> CGatePro/far-NAT, проверено на людях.

>

[...]
> Но если на клиенте, который "вроде как работает" начать нажимать
> кнопочки - на Hold поставить, звонок Transfer, и так далее - то из него
> начнут сыпаться разные интересности. То есть - его внутренние адреса
> начнут сыпаться.

Дырочка зарубцовывается часто. Массовые случаи "мне не могут дозвониться, играет voicemail" гораздо критичнее единичных "дозваниваюсь нормально, transfer срывается". У меня дома из двух NAT'ed UAs звонит максимум один, причем случайным образом. Третий, WM5/uPnP, работает всегда.

> Вот есть хороший клиент - от SJLabs. Мы с ними это всё тестировали, и
> как только стало чуть посложнее, так даже у них пошли проблемы (которые
> они благополучно исправили - должно быть в текущих версиях). Да и у нас
> при этом кое-какие проблемы нашли (тоже исправили). А если всё, что надо
> - это просто дать Пете позвонить Васе - то таких клиентов, более менее
> сносно обрабатывающих один REGISTER и один INVITE - всё больше и больше,
> и, конечно, если их нужно использовать.
>
> Поэтому в начале треда я написал: для начала - отрубить все NAT-related
> мозги
> у клиента (и, что особо важно - у самого firewall). И добиться работы. А
> потом, когда будет время - проверить, не созрели ли собственные мозги
> клиента (UA) для прохода NAT/firewall в интересующих случаях.

Это разумеется.

> Плюс еще такой момент - не столь важный Вам, но важный в оригинальном
> контексте (офисный environment). Если клиент начнет сам все время слать
> свой внешний адрес, то два человека из-за одного файрвола - будут
> говорить через этот самый файрвол - и то, если он позволит. CGatePro в
> этом случае просечет, что они оба- за одним NAT/firewall, и заставит их
> говорить (media) напрямую, а через себя пустит только signalling.

Совершенно согласен. NAT'ы как правило умеют Hairpin, заворачивание пакетов, адресованных с внутреннего порта на внешний обратно вовнутрь, если в таблице NAT association найден слушатель. Без hairpin что угодно может произойти.

-- 

Герман Мызовский,
Tario Communications.

Получено Wed Feb 22 08:59:51 2006