« Videoport.ru - сервис для видео-звонков и конференций | Main | Первая видео-конференция »

сент. 15, 2006

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Photo gros seins naturels film amateur porno gratuit

> MHO, разработчикам SIP приложений давно пора
> применять подобные решения

Есть... У нас такая фича есть года три уже.

Проблема NAT traversal почти идеально решена в Google Talk. Протокол Jingle Audio использует ICE, STUN, "hole punching" и некоторое число распределенных STUN релейев, что позвляет двум пользователям практически 99% случаев установить соединение находясь за любым количеством NAT-ов, чем мне очень нравится. Видно, что парни из Google Talk team приложили не мало усилий для решения проблемы.

Еще одно достоинство Jingle в том, что трафик в нем по возможности идет наикратчайшим путем. Т.е. если например два пользователя сидят в локалке, то трафик не выйдет дальше локального сегмента ethernet.

IMHO, разработчикам SIP приложений давно пора применять подобные решения.

'The problem with SIP is that it only works out of the box when you have either no NAT-Router or Firewall at all in front of you, or if you have SIP capable Firewalls/Routers. In other cases, you have to start dealing with STUNNEL, UPnP or similar stuff - and that does not work in every case. Especially when there is a NAT setup with more restricted rules on both sides SIP is impossible. And that’s the fault of SIP which is designed in such a way.'

WRONG!

Еще раз, _серьезные_ ITSP проблему NAT Traversal решают _без_ участия пользователей, и да, проблема решаемая, было бы желание искать решение. Такие солюшены уже лет 5 как существуют, и как Петр правильно сказал, называються они Session Border Controller.

Специально для скептиков - если хочеться проверить, пишите через емыл, дам адрес hosted demo SBC и если firewall перед клиентом позволяет выйдти UDP наружу, то не имеет значение, сколько NAT-ов стоят перед клиентом, они друг другу звонить будут.

Статья довольно любопытна. Для корпоративщиков же есть выход в виде openvpn и httptunnel.

httptunnel позволяет пробросить openvpn через http прокси, где нет возможности пройти через https (для него прокси сервера поддерживают метод CONNECT). Правда как мне кажется голос передать по такой матрешке туннелей не удасться , но если httptunnel нет и можно воспользоваться openvpn, то возможно латентность будет достаточно низкой для использования IP-телефонии.

The comments to this entry are closed.

My Photo

Поиск по блогу