[gena_dj 0]

Вот именно, что получится. Иначе бы и STUN-а не было (почитайте кстати rfc3489, это очень интересно) В случае, если кто-то из-под NAT-а выпустил пакет наружу, NAT держит этот тоннель. Наружний порт становится проброшен на внутренний локальный порт. Исключение - symmetric NAT.

 

Ниже - цитата из rfc

Binding requests are used to determine the bindings allocated by NATs. The client sends a Binding Request to the server, over UDP. The server examines the source IP address and port of the request, and copies them into a response that is sent back to the client

....

The STUN client is typically embedded in an application which needs to obtain a public IP address and port that can be used to receive data. For example, it might need to obtain an IP address and port to receive Real Time Transport Protocol (RTP) [12] traffic.

[AlexandrY 3]

Ну что ж, я проверил вашу гипотезу.

Надо признать, что наши интеграторы собаку съевшие на интеграции GSM решений, нифига не могли сказать на тему свойств NAT-а у их же партнерских GSM операторов.

Сами же операторы для ответа на такие вопросы требуют официальный запрос и организацию митинга с участвием почти всего менеджерского состава.

Поэтому пришлось поэкспериментировать.

Вообщем несимметричный NAT оказался только на моей Business Internet SIM карте от одного из операторов (партнер Vodafone). На карте другого оператора и предоплаченных картах NAT был симметричный т.е. непропускающий ананонимные запросы, короче c firewall-ом

 

Соответсвенно с первой картой Skype соединился напрямую из внешнего интернета.

С другими он соединиться напрямую не смог.

Но связь всетаки была.

Нюанс в том, что Skype сразу при запуске соединяется по UDP с 6-ю...10-ю серверами в инете (настоящее хакерское исчадие ), а потом с одним из них и TCP коннект налаживает. Трафик весь зашифрован и понятно, что STUN-ом там и не пахнет.

 

Вообщем ваше решение наверно было бы самым простым если бы оно не было бы таким редким. ;)

 

Вот именно, что получится. Иначе бы и STUN-а не было (почитайте кстати rfc3489, это очень интересно) В случае, если кто-то из-под NAT-а выпустил пакет наружу, NAT держит этот тоннель. Наружний порт становится проброшен на внутренний локальный порт. Исключение - symmetric NAT.

 

Ниже - цитата из rfc

[gena_dj 0]

Это довольно странно, только с одним оператором удалось проверить. Я подробно тестировал эту ситуацию на МТС, работало стабильно.

 

Кстати, работа skype здест не авляется критерием. Напишите подробнее, как тестировали. Лучше пробовать с правильным sip-оператором и с sip-телефоном, поддерживающим stun. (например, x-lite (eyeBeam, Bria))

Изменено 27 марта, 2008 пользователем gena_dj

[AlexandrY 3]

Проблемы передачи VoIP в поднятой теме как бы вопрос второстепенный.

Я бы обратил внимание на вот этот драфт.

http://tools.ietf.org/html/draft-ietf-behave-turn-06

 

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

Но публичных релейных агентов никто не даст.

TURN как стандарт еще не закончен.

Да и STUN публичных не так уж и много и находятся далеко.

Сам проткол STUN предусматривает авторизацию, т.е. если STUN, то не значит халявный.

 

Да и тунелем метод со STUN назвать нельзя.

Сервер за NAT-ом желающий открыть все свои порты должен по идее для каждого порта из 65536 провести сеанс со STUN сервером. Понятно, что это не реально.

 

Это довольно странно, только с одним оператором удалось проверить. Я подробно тестировал эту ситуацию на МТС, работало стабильно.

 

Кстати, работа skype здест не авляется критерием. Напишите подробнее, как тестировали. Лучше пробовать с правильным sip-оператором и с sip-телефоном, поддерживающим stun. (например, x-lite (eyeBeam, Bria))

[gena_dj 0]

1. Передавать RTP с голосом не нужно, вместо него можно передавать любые UDP-пакеты

2. Когда я тестировал с МТС, я контролировал, что трафик ходит напрямую с NAT-NAT, а не через релеи

3. STUN есть практически у любого провайдера VoIP, в интернете полно публичных сервисов. Чтобы задействовать STUN достаточно зарегистрироваться у публичного провайдера. Небольшой список здесь.

4. Все порты открывать не нужно, достаточно открыть по одному порту с каждой стороны.

5. Если не хочется городить огород с выделенными серверами - можно задействовать любой публичный SIP-сервер для установки тоннеля.

 

 

Проблемы передачи VoIP в поднятой теме как бы вопрос второстепенный.

Я бы обратил внимание на вот этот драфт.

http://tools.ietf.org/html/draft-ietf-behave-turn-06

 

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

Но публичных релейных агентов никто не даст.

TURN как стандарт еще не закончен.

Да и STUN публичных не так уж и много и находятся далеко.

Сам проткол STUN предусматривает авторизацию, т.е. если STUN, то не значит халявный.

 

Да и тунелем метод со STUN назвать нельзя.

Сервер за NAT-ом желающий открыть все свои порты должен по идее для каждого порта из 65536 провести сеанс со STUN сервером. Понятно, что это не реально.

Изменено 28 марта, 2008 пользователем gena_dj

[AlexandrY 3]

Это понятно, что не о голосе идет речь.

Просто технологии не очень подходящие из той области.

 

Представим простой сценарий.

У вас есть дивайс скажем на PIC18 cо встроенным WEB сервером, SMTP сервером, POP3 клиентом TELNET клиентом.

Все это можно скачать бесплатно с сайта Microchip.

Все это отлично работает в открытых Ethernet сетях.

Есть LwIP стек с PPP.

 

И что вы полагаете будет проще прикрутить?

Нормальный тунель PPTP (один из простейших протоколов для организации VPN) который есть вообще в любом компьютере с Win XP и Vista по умолчанию, и во многих даже домашних роутерах.

И требующий минимальной обертки IP пакетов в PPP пакеты.

 

Или пытаться делать на каждый открываемый сервером порт отдельную сессию STUN, причем сделать сессию STUN с неясной перспективой удастся ли она через текущий NAT, да еще заточенную

под UDP пакеты? (WEB, SMTP, POP, TELNET - все работают только по TCP пакетам)

Кстати не факт, что VoIP провайдер дает беспрепятственный доступ к STUN.

Логично ожидать авторизацию STUN у них позволяющую подключаться только их дивайсам.

 

Ну и конечно количестов STUN серверов довольно мало по сравнению с VPN серверами.

 

Причем VPN сервер как релейный агент в результате может дать лучший трафик чем открытый канал по публичным сетям.

 

 

1. Передавать RTP с голосом не нужно, вместо него можно передавать любые UDP-пакеты

2. Когда я тестировал с МТС, я контролировал, что трафик ходит напрямую с NAT-NAT, а не через релеи

3. STUN есть практически у любого провайдера VoIP, в интернете полно публичных сервисов. Чтобы задействовать STUN достаточно зарегистрироваться у публичного провайдера. Небольшой список здесь.

4. Все порты открывать не нужно, достаточно открыть по одному порту с каждой стороны.

5. Если не хочется городить огород с выделенными серверами - можно задействовать любой публичный SIP-сервер для установки тоннеля.

[stream 0]

Удивили вы меня...

Burst ON time это время переходного процесаа наростания сигнала, регламентируется в стандарте, так как изменение амплитуды приводит к изменению частоты. Burst OFF соответственно время спада.

 

:a14: Спасибо за хорошее настроение, уже несколько минут буквально валяюсь под столом от смеха! "Трудности перевода", 2-я серия.

 

Посмотрите хотя бы остальной текст в стандарте адемки (если он у вас есть) - в каком контексте там используется слово Burst. Там это все-таки означает полную длительность тональной посылки.