Re: _outboundsip._udp

От: Vladimir A. Butenko <CGatePro_at_mx_ru>
Дата: Wed 22 Feb 2006 - 11:23:58 MSK

On Wed, 22 Feb 2006 10:54:16 +0300
  "German Myzovsky" <CGatePro@mx.ru> wrote:

>Outbound Proxy. При отсутствии Outbound Proxy бросить эту затею, или
>использовать внешний IP адрес "на удачу".
>
> Так поступают, например, eyeBeam и X-Lite, популярные продукты от
>CounterPath Solutions, Inc. При симметричном NAT'е в поле Via:
> -- если Outbound отсутствует: внешний IP;
> -- если явно прописан Outbound: внутренний IP, что и требовалось!
>
> Всё это имеет смысл при организации массовой услуги. Если нужно подключить
>одного клиента за пиксом, вышеперечисленные рассуждения -- блажь. Тем не
>менее, я бы дорого дал за то, чтобы иметь это знание год назад.

Я не совсем понял, о каком знании идет речь. У этих продуктов есть сеттинг

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

Если продукт ПРАВИЛЬНО разобрался с NAT (неважно, какой метод он использовал), то работать он будет "лучше" - в том смысле, что траффик его не надо будет проксировать через CGAtePro, где при нагрузках могут получаться задержки, и вообще "путь до CGatePro" может быть неблизкий. Поэтому, КОНЕЧНО, если бы все эти клиенты работали - то всё бы было хорошо.

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

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

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

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

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

Sincerely,
Vladimir Получено Wed Feb 22 08:23:32 2006

Этот архив был сгенерирован hypermail 2.1.8 : Fri 24 Apr 2015 - 16:14:44 MSK