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

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

Насколько мне известно, в GSM сети невозможно установить соединение между двумя GPRS модемами.

Вы можете установить соединение между GPRS модемом и, например, каким нибудь сервером в интернете, зная его IP адрес и если на этом сервере на определенном порту работает слушающая программа, которая и будет обмениваться/получать данные от вашего модема.

APN - это точка доступа для соединения с Internet, предоставляемая GSM провайдером. Ее можно узнать по телефону сервис центра или на сайте того GSM оператора, чъей GSM SIM карточкой вы пользуетесь. Логин и пароль для такого подключения, как правило, пустые.
Некоторве GSM операторы предоставляют услугу типа "Корпоративный GPRS" без выхода в publuic Internet на тот случай, если у вас есть сеть GPRS теминалов, например в банковском оборудовании и свой сервер со статическим IP адресом, с которым они связываются. В этом случае логин и пароль будут.

А можно такое сделать: Одним модемом подключится к gprs и стать сервером, а второй будет к нему подключаться и передавать информацию?

В подавляющем большинстве случаев ответ отрицательный, т.к. во-первых GSM оператор после установки соединения выдаст вашему GPRS модему динамическиий IP адрес, который второму модему заранее не известен, чтобы подключаться к первому, как к серверу. Ну а во-вторых, этот IP адрес скрыт за их NAT-сервером и к нему нет доступа из интернета.
Вообще-то эта тема уже обсуждалась. Например, здесь: http://electronix.ru/forum/index.php?showtopic=18970

Опишите подробнее, какая перед вами стоит задача?

Как вариант - договориться с оператором о предоставлении статического IP.

Лучше использовать свой сервер для обмена информацией между модемами. Это будет универсальное решение не зависящее от оператора.

Задача следующая: в одном месте находится модем, который управляется микроконтроллером. В другом находится точно такой же модем. Общение должно быть двустронним - один дает запрос - второй ответ.

А такое решение можно использовать? Один модем стает TCP сервером, второй соответственно клиентом. А для того чтоб они ip адреса узнали друг друга, можно их передать по смс. Получится так или бредовая идея?



А можете подробней написать,что это за сервер должен быть?

Получится, если сервер будет иметь статический IP. Иначе они оба будут за NAT-ом оператора.



Сервер-ретранслятор с известным обеим модемам IP-адресом (вот он-то может настраиваться по СМС), с которым они устанавливают соединение. Сервер должен пересылать данные от одного абонента к другому.

Оставьте идею сделать один из модемов сервером.
Для решения данной задачи подойдет любой, самый "чахлый" сервер со статическим IP адресом в интернете. Не знаю, в каком городе вы находитесь, но получить статику у местного интернет провайдера намного проще ( и в будущем, полезнее ), чем у GSM оператора. Если вы делаете этот проект на заказ и заказчик готов платить, то ему нужно будет получить статический IP и поставить у себя сервер ( а может быть у него уже и есть такой, только он об этом не знает ).
Затем для этого компьютера необходимо написать программу, которая будет слушать на определенном порту, естественно, известном всем GPRS модемам и принимать/передавать от них данные. Логично реализовать это на основе базы данных, тогда потом можно будет получать какую нибудь статистику по обмену данными и т.п.
Т.е. этот сервер будет выступать в роли коммутатора между модемами, причем количество модемов, теоретически, может быть любым.

Есть другой способ, без использования своего сервера. Можно реализовать это на каком нибудь платном/бесплатном WEB сервере, поддерживающим, например, PHP и MySQL. И общаться с ним через 80-й порт, но в этом случае сложнее парсить ответы от сервера на стороне модема.

По каким причинам? Из-за сложности?
Такой еще вопросик: а возможно организовать соединение между модемами по протоколу PPP?
С модемами никогда не работал, по этому вопросов много, возможно и глупых...

Еще вычитал, что можно открыть TCP сервер и TCP клиент и передавать данные напрямую. Как такой вариант?
А что можно сказать про отправку данных через SMTP и прием через pop3? Бред?

Оставь надежду всяк сюда входящий...
Организовать надежный и недорогой GPRS канал данных думаю у вас не получится, вот причины из горького опыта
1. ОпСоС не гарантирует надежность канала передачи данных, надо контролировать socket вручную
2. Постоянный коннект встанет вам в копеечку, даже если вы ничего не передаете из-за их програмных фишек
3. В праздники GPRS отдыхает или работает через раз, правда это у кого как...
4. так как ваш фиксированный IP виден всем из интернета, то существует минимум способов 100, как завалить сервер, и никакой файервол не поможет!
Покритикуйте меня если наврал...

Некоторых результатов уже добился.
С помощью одного модема создал сервер. В нем выбираю порт, фильтрацию ро IP адрессам клиентов не делаю. Этот модем передает с помощью смс клиенту свой IP. Тот в свою очередь подключается к серверу по тому же порту, и происходит двусторонний обмен данных. То что нужно...
По поводу замечаний Ndf:
1. Не понимаю что такое ОпСоС
2. У нас в Украине у одного мобильного оператора есть возможность покупать 1GB траффика за 12$, так что вопрос о стоимости передачи не стоит.
3. В выходные и праздники будем тестировать, будет видно.
4. IP адресс не фиксированный, а динамический. К тому же чтоб завалить сервер надо еще и знать порт...

Какие еще могут быть замечания?

Если сервер всегда on-line то динамический IP не очень-то отличается от фиксированного, а если дисконнекты часто будут, будете поливать клиентов SMS? Да и очередность SMS может нарушиться.
ОпСоС - оператор сотовой связи.
На счет п 2 вам везет...

Мужуки! А зачем так сложно?
Для такой тривиальной задачки достаточно чтобы любой из контроллеров выдал в модем команду
ATDxxx..xxxx, где: xxx..xxxx - телефонный номер абонента. Модемы установят DATA соединение
и после этого считайте, что Serial порты Ваших контроллеров просто соединены проволокой!

А тарифицироваться как будет? Получается как голосовой звонок!? Дороже так будет...

Да, в общем случае, дороже. Но, вопервых о цене базару небыло, а вовторых есть куча вариантов.
Выберите оператора с нулем за соединение, посадите SIM-карты на какой-нибуть "семейный" или
вообще "ноль в сети" тариф и не так уж оно и дорого.
Десятки пользователей нашего оборудования сидят на GSM DATA, качают сотни килобайт
(правда не слишком часто) и вполне довольны.

А вобщем-то, справедливости ради, следует сказать, что задачка сформулирована довольно неопределенно.
Если нужно раз в час или реже сплюнуть с десяток килобайт и бросить трубку, то DATA вполне конкурентна. Если-же действительно необходим постоянный CONNECT, тогда GPRS - адназачна .

Можно сравнительно легко решить проблему используя VPN сервер.
Тут либо покупаете услугу VPN у кого-нибудь в инете (50$ в год),
либо покупаете и ставите дома роутер с VPN и прикручиваете его к Dinamic DNS если нет статического адреса.
После чего все мобильные дивайсы могут быть и серверами и клиентами и все видны друг другу по любым портам.

Но в этом случае все девайсы должны постоянно находиться в коннекте с сервером. Так?

По своему опыту могу сказать, что CSD-соединение (GSM DATA) и голос (VOICE) у операторов мобильной связи (Украина) тарифицируются по разному, т.е. даже при нулевой стоимости разговора передача будет стоить дорого + время соединения модема до 30 секунд. Поэтому говорить о дешевизне этого способа не приходится.

wavecom сейчас единственный кто умеет работать в CSD transparent mode.
там соединение 1-2 секунды занимает. обычно 1,5
и получается очень даже дешево.

многие операторы предлагают тарифы где первые 3-5 сек идут без тарификации.

А можно подробнеее про "CSD transparent mode"?

Вы наверное забыли добавить что это только для voice-call, и на CSD это не распространяется.

да. только для голоса. НО,
вейвкомы 26хх умеют генерить и декодировать DTMF.
и например задачи вроде постановки/снятия охранки, аварийных вызовов с кодами событий и других задач где в 3-4 сек можно уложить DTMF посылки решаются очень даже бесплатно

И с какой версии они научились декодировать DTMF?

Я думаю, что тоннель между двумя пользователями, сидящими за NAT-ами (в общем случае разными), установить можно. В VoIP для этого применяется STUN. Как я себе это представляю - объясню.

1. Пользователь 1 (П1) отсылает UDP-пакет STUN - серверу. При этом сервер "видит" host:port реального интерфейса на NAT-сервере
2. П1 узнает от сервера host:port
3. П1 регистрируется на sip-сервере со своим реальными host:port
4. Шаги 1 - 3 выполняет Пользоваетль 2 (П2)
5. П1 и П2 регистрируются на SIP-сервере с учетом своих реальных host:port
6. Далее SIP - сессиия проходит с учетом реальных host:port пользователей.

Как я вижу организацию тоннеля между двумя пользователями за NAT-ами.
1. Инициатор отсылает UDP-пакет выделенному серверу в реальной сети. При этом сервер "видит" host:port реального интерфейса на NAT-сервере
2. П2 получает от выделенного сервера host:port инициатора
3. П2 отсылает на host:port инициатора UDP-пакет.
4. Инициатор отвечает на этот пакет по адресу отправителя.
Это все, установили тоннель

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

Но так или иначе, можно использовать публичные SIP и STUN сервера.

>>>>и например задачи вроде постановки/снятия охранки

для этой задачи не катит !

Объясняю - централизованые охранные пульты создаются под специально укороченый DTMF чтобы нельзя было снять/поставить на охрану используя биппер или телефон - только абонентский пульт. Поэтому там длительнсть посылки ровно половина от того что по стандарту умеют модули. Это только под самодельную охранку можно, но сертификацию она не пройдет именно из-за требования к длительности сигналов.
Можно сгенерить поверх разговора своей задачей или внешним контролером . То что генерит приемная сота (на самом деле, а не модуль как многие думают - модуль только дает соте команду что генерить и дублирует уже тоном в ухо передающему ) пульт не воспринимает.
Попробуйте запихнуть DTMF в аудиоканал и принять его с той стороны.... А потом дайте команду генерить модулем....
И посмотрите на разность фазовых искажений....
Кстати еще о DTMF - многие операторы транслируют только 12 знаков из 16 - цифры, звездочка, решетка. Остальные 4 могут быть запрещены сотам к передаче.
Пример - Украинский Билайн - служебные символы транслируются тишиной.

VPN - не слишком ли круто для микроконтроллеров? Да и вообще, это лишнее (пропускать трафик через третье место - лишние проблемы, в то время, когда можно пропускать напрямую) Читайте мой предыдущий пост.

to CADiLO.
Вот например широко распространенный стандарт. в инете полно ссылок:
Digital Communication Standard - Ademco ® Contact ID Protocol -
for Alarm System Communications.
это достаточно распространенный в россии протокол.

DTMF в вейвкоме генерится внутренним DSP. и никакой не сотой.
можно выдавать как в GSM аудио канал, так и в динамик.
Декодировать модуль умеет и с аудио канала и с микрофонного входа.

и у нас очень даже все работает.
не знаю как на украине. возможно и не прокатит.

to Sobr,
CSD transparent mode это прозрачный режим протокола V.110.
настраивать на него нужно обе связываемые точки.

DTMF декодируется с 26-й серии. в аттаче сишный пример.

>>>>DTMF в вейвкоме генерится внутренним DSP. и никакой не сотой. Можно выдавать как в GSM аудио канал, так и в динамик.
Декодировать модуль умеет и с аудио канала и с микрофонного входа.

Опять Вы все перекручиваете.
Я не говорил что вейвком не умеет генерить DTMF.

Пусть генерит себе на здоровье, вот только достоверность приема DTMF прошедшего аудиотракт и DTMF сгенеренного сотой будет разная. Скажутся искажения кодеков на приемной и передающей стороне.... Да и сама специфика сотовой связи такова.
Простой пример - через аудио тракт (не в цифре) практически невозможно передать факс - причина та же, нарастающие с количеством сот искажения. Я еще не видел ни одного сотового моста который справился бы с этой задачей.
Повторяю - речь идет об аналоговом подключении факса, а не через COM порт.

Вопрос ведь тут не плохой или хороший модуль - суть именно в принципе связи.

Теперь по поводу стандартов - кому нужна такая охрана, если любой может прозвонив на пульт зная код снимет его биппером или мобилкой ? Почитайте про длительность сигналов в стандаре.
Подчеркиваю - пульты не воспринимают СТАНДАРТНЫЙ DTMF.
А если будете генерить его сами согласно требованиям, так вопрос остается только в качестве декодирования.

Указаный Вами стандарт прилагаю.
там есть следующее:

4.1.2.3 Data Tones
The message is sent using standard DTMF tones.

The timing of the tones shall be as follows:

Burst ON time - 50 msec. (50 min.,60 max.)
Burst OFF time- 50 msec. (50 min.,60 max.)

А для стандартного DTMF:

The minimum duration of the tone should be at least 70 msec

Так что стандартный DTMF по вышеуказаному стандарту не примется !!!
Частоты совпадают - длительность другая.
И общая длина блока короче чем из памяти телефона номер в DTMF выдается.

2СADiLO
работает все без проблем. именно по этому протоколу и по другому тоже. есть проект

Еще раз напоминаю. Вейвком это не GSM приемопередатчик. вернее приемопередатчик там тоже есть, но как состовная часть. это в первую очередь мощный МК ARM9 c кучей памяти и встроенной операционкой.
поэтому декодирует DTMF он очень быстро и без проблем.
кто не верит, исходник постом выше. можете проверить сами его работу.

ну и до кучи по поводу передачи данных через GSM голосовой тракт. не путать с CSD!
и это возможно. скорость правда не очень, около 500-600bps получается.
это чисто вейвкомовская технология, вроде называется iQLink.

Удивили вы меня...
Burst ON time это время переходного процесаа наростания сигнала, регламентируется в стандарте, так как изменение амплитуды приводит к изменению частоты. Burst OFF соответственно время спада. Никаких отличий в части длительности, стандарт Ademco от обычного DTMF не имеет. И мобилкой снять с охраны панель Vista например, зная коды проще простого. Вот потому то эти приборы и отсутствуют в российском "Перечне разрешенных к применению..." если вы слышали о таком.

Конечно слышал и даже сталкивался когда заставляли на бакинских 155ТМ2 городить огород потому что 155ИЕ7 были на то время не в перечне....

Могу сказать что будучи на двух заводах в командировке столкнулся с тем что пульты устанавливаемые для охраны в службах
МВД - СТАНДАРТНЫЙ DTMF НЕ ВОСПРИНИМАЮТ. Все, точка.
Может быть в России по другому и у нас в частных структурах тоже, но государственным службам запрещено использовать несоответствующее требованиям оборудование. Хочешь стыковать с ними свои устройства - будь добр соответствовать.
Потому разработчики и не могут воспользоваться способностью модуля генерить DTMF - ну не умеет он короткий генерить - а генерят внешними контроллерами.

Есть присутствующий факт и думаю что спор можно закрыть.

Кроме того всем желающим предлагаю провести тестирование на достоверность приема DTMF поданого в голосовой канал и сгенеренного сотой.
наберите статистику на сотню номеров и все вопросы отпадут сами. Причем можете принимать хоть програмно, хоть аппаратно.
Причину я называл выше.

CADiLO вам бы в госдуму нашу... цены бы не было

.... что за бред?
Я вам об этом:
МИНИСТЕРСТВО ВНУТРЕННИХ ДЕЛ РОССИЙСКОЙ ФЕДЕРАЦИИ Департамент государственной защиты имущества
Утвержден
Департаментом государственной защиты имущества МВД России
« 16» января 2006 года
Бюллетень технических средств безопасности,рекомендованных к использованию
вневедомственной охраной в 2006 году


...это это с какого фонаря?????
Хочу задать вопрос - вы читать по английски умеете? В документе на который вы ссылаетесь на странице 1 написано черным по белому:
This communications format utilizes standard DTMF tones for transmission of the information.
И на странице 5: The message is sent using standard DTMF tones.

DTMF, ContactID придуман не нами, устройства типа охранных панелей все привезенные из-за рубежа и МВД их не использует, так как ЗАПРЕЩЕНО. Ни одно устройство нельзя продать ни в России ни в Украине если нет двух базовых сертификатов: охранно-пожарный серт. и сертификат минсвязи (он же ССС). При сертификации обе организации делают одну и туже проверку на соответствие ВСЕХ заявляемых параметров, уж поверьте.

Отвечаю по порядку:

1. Это не бред. Вы наверное при СССР не сталкивались с перечнем допущеных к применению в военных разработках микросхем. И наверняка не знаете что такое микросхемы изготовленые в Баку, в простонародье - "чайники" - из-за значка завода. Хорошо если она еще первые 10 минут работала, а бывало просто корпус с ножками попадался.....

По сравнению с этим перечнем и зорким глазом военпредов
"Бюллетень технических средств безопасности...." просто детская книжка.

Ну а то что принимает Россия сейчас.... Так к нашим законам это как-то не касается. И клоунов у нас своих три сотни в Киеве сидит....
Похлеще Жириновского особи есть....

2. Я ни в чем не ошибся - практически все зарубежные устройства принимают СТАНДАРТНЫЙ DTMF. Что не есть хорошо и потому у нас запрещено, точнее не рекомендовано.

Вы сказали то же самое, но другими словами.

Есть МЕСТНЫЙ основаный на DTMF но с укороченными посылками протокол рекомендованый для применения в пультах.
Хочешь поставить фирменый пульт в госслужбе - пожалуйста, но приведи протокол обмена в соответствие тому что рекомендуют службы безопастности.

Ну нельзя по этим требования снять с охраны объект стандартными средствами способными генерить DTMF - НЕЛЬЗЯ!

Потому можете выпускать, использовать, хоть свой обмен написать, но как только дойдет до сертификации и применению в госслужбах - то усе... приехали....

2CADiLO

забудьте вы про СССР,155ТМ2 и 155ИЕ7 ... украину вообще скоро вроде в НАТО запишут...
и будете их стандарты юзать

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

и вообще разговор изначально был о том что процессоры вейвком умеют ДЕКОДИРОВАТЬ DTMF без внешних DSP и всяких обвесов с голосового GSM тракта или микрофонного входа.

Действительно умеют. Правда вместо обвеса голосового GSM тракта надо обвешивать процессор внешней памятью

процессор может быть и в модульном исполнении (с памятью) c 60-и контактным разъемом.
в виде модуля Q64

http://www.wavecom.com/modules/movie/scene...productName=Q64


кстати и серия Q26xx тоже все это умеет делать.

Удачи!

Да, есть. Но оно еще более золотое чем вариант с памятью.

>>>>и вообще разговор изначально был о том что процессоры вейвком умеют ДЕКОДИРОВАТЬ DTMF без внешних DSP и всяких обвесов с голосового GSM тракта или микрофонного входа.

С этим я и не спорил! Что есть то есть....

Вопрос то был совсем в другом, а никто так и не понял увлекшись технической стороной.

Нельзя в охранной системе допускать чтобы любой узнав случайно (или не случайно) код, мог снять ее при помощи копеечного биппера с охраны. На кой хрен тогда такая охрана.....

И второй вопрос - я все же рекомендую провести статистический анализ качества приема DTMF прошедшего аудиотракт и сгенеренного сотой.

ПОДЧЕРКИВАЮ !!! можете это делать любыми модулями и приемниками.

А Уважаемого alexQ попрошу передать через его хваленый вейвком
FAX в АНАЛОГОВОМ РЕЖИМЕ.

И результаты в студию.
Ничего лично не имею против вейвкомовского модуля, просто есть вещи которые зависят от самого принципа связи.....

Ну, честно говоря....
В 90% охранных систем если узнать случайно (или не случайно) код, то для снятия с охраны нужны только пальцы .

Не понял, в предыдущем посте сказано что нужен внешний сервер. Где решение для связи напрямую?




Ну так категорично не надо. Свойства кодеков все таки известны, плюс их можно варьировать.
У нас могут в GSM модуль в принципе любой кодек всунуть, но от российских дилеров не было таких идей.
Т.е. фича на самом деле не востребована. В европе все смотрят как на дурака когда говоришь. что можно как-то стырить несколько нетарифицируемых секунд.
Тем более что SIM карты с планон для телеметрии и запасом трафика без голоса гораздо дешевле карт с голосом.
А уж какой бардак у нас на частных охранных пультах твориться и говорить нечего.
Там один самопальный концентратор на другом стоит. Никто никаких сертификатов не справшивает, лишь бы подешевле был. И на Украине так будет, когда ее Евросоюз и НАТО заставят законодательство поменять.
Вот по ссылке дивайс http://aly.ogmis.lt/OpenProjects/GSMA/GSMA.htm применяется в нескольких охранных фирмах.
Вооще принимает и переконвертирует как хочет Contact ID и SIA и ничего никто не цепляется.

В том то и фокус ,что связь происходит напрямую. Внешний сервер задействуется только для начала сеанса связи (в отличие от VPN, где через внешний сервер идет весь трафик). Если не ставить свой сервер, можно задействовать публичные (бесплатные) SIP и STUN сервера.

Дешевый тарифный план телеметрии, не подсажите название?
Что-то не пойму я вас - говорите одно, а предлагаете девайс с не гарантированным SMS сервисом, это вместо ненадежной ретрансляции DTMF посылок от панели или чего-то там еще по голосовому каналу. На чем основано такое смелое утверждение? Я заметил, это у нас национальная особенность такая, делать ни чем не обоснованные заявления, а потом говорить - извините, вы просто меня не поняли. Читаешь иногда РЭ на разные девайсы и, просто диву даешся, полету фантазии авторов, когда творческий вымысел переплетается с технической реальностью. Берите пример с западных коллег, раз уж вы их вспомнили.
Про DTMF over voice-call скажу вот что: все частоты находятся внутри диапазона ТЧ 0,1-3кГц, стандарт разработан с УЧЕТОМ всевозможных потерь в реальных каналах связи. Да, потери в соте есть, но вот к примеру MT8870 спокойно с этим справляется, не говоря уже о навороченных "повышающих" ифровых фильтрах. Проверял прием в голосовом тракте и в зашумленном радио канале 433Мгц. После голосового соединения ввод 6-ти цифр пароля и 3-х значной команды - все прекрасно работает.

Ваш вариант предпологает, что NAT пропустит UDP пришедший с другого IP, но на тот же порт с которого ушел предыдущий UDP на STUN сервер?
Этого не получится думаю. NAT не должен пропустить такой UDP.
Т.е. коннекта минуя сервер не произойдет.

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

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

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

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

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

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

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

Проблемы передачи VoIP в поднятой теме как бы вопрос второстепенный.
Я бы обратил внимание на вот этот драфт.
http://tools.ietf.org/html/draft-ietf-behave-turn-06

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

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

1. Передавать RTP с голосом не нужно, вместо него можно передавать любые UDP-пакеты
2. Когда я тестировал с МТС, я контролировал, что трафик ходит напрямую с NAT-NAT, а не через релеи
3. STUN есть практически у любого провайдера VoIP, в интернете полно публичных сервисов. Чтобы задействовать STUN достаточно зарегистрироваться у публичного провайдера. Небольшой список здесь.
4. Все порты открывать не нужно, достаточно открыть по одному порту с каждой стороны.
5. Если не хочется городить огород с выделенными серверами - можно задействовать любой публичный SIP-сервер для установки тоннеля.