передача данных через модемы wavecom Опции

[dimonbest]

Доброго времени суток форумчане.
Возникла следующая задача:
Есть два устройства на модемамах wavecom модели М1206В.
Модемы к компу не будут подключаться, управлять ими будут микроконтроллеры (ATmega).
Общение должно проходить по такому принципу: один дает запрос, второй ответ, и наоборот. Будут участвовать только два модема. Обьмы даных передаваться будут небольшие.
Это направление для меня новое, поэтому есть трудности.
С АТ командами ознакомился (отправлял через терминалку).
А вот организовать пересылку данных через GPRS - для меня загадка.
В сети нашел такой код:

Код

Настройка и подсоединение к GPRS:
AT+CGATT=1
AT#APNSERV="xxxx", где xxxx - APN сервер провайдера сотовой связи.
AT#APNUN="yyyy", где yyyy - имя пользователя;
AT#APNPW="zzzz", где zzzz - пароль;
AT#CONNECTIONSTART

Ответ: xxx.xxx.xxx.xxx, где xxx.xxx.xxx.xxx - IP адрес выделенный сотовому терминалу.
Ответ: Ok_Info_GprsActivation

Подсоединение к TCP-Серверу
AT#DLEMODE=1,0
AT#TCPSERV=1,"xxx.xxx.xxx.xxx", где xxx.xxx.xxx.xxx - фиксированный IP адрес сервера (того терминала или компьютера с кем надо установить связь)

AT#OTCP=1

С ним разобраться не получилось: не понял что за пользователь и пароль. И как принимать данные?
Подскажите пожалуйста, от чего отталкиваться, куда рыть... Спасибо!

[gena_dj]

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

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

Сообщение отредактировал gena_dj - Mar 27 2008, 02:53

[AlexandrY]

Проблемы передачи 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]

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 сервером. Понятно, что это не реально.

Сообщение отредактировал gena_dj - Mar 28 2008, 06:26

[AlexandrY]

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

Представим простой сценарий.
У вас есть дивайс скажем на 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-сервер для установки тоннеля.