Нас это не остановит, ;-)
Хотя в каком-то моменте, стормозил вроде.
Тогда технология несколько меняется
Идея такая:
Усложним задачу предположив, что дивайсы не знают какой внешний IP или из какого пула внешних IP им присваивает оператор.
Тогда каждый дивайс узнает свой внешний IP адрес через какой-нибудь публичный STUN сервер.
Потом оставляет запись о себе где нить на публичном POP3 сервере или на HTTP майл сервере.
Найдя в общем каталоге через отдельный TCP коннект адрес своего партнера дивайс уже шлет ему пакеты. Но на какой порт? После сессии со STUN порт уже мог поменяться.
Тогда делаем ход конем.
NAT-ы не должны следить за сессиями они работают на уровне IP поэтому тупо шлем FTP команду PORT с запросом на активное FTP DATA соединение своему партнеру например на 21-й порт.
Команда не дойдет ясно, но как замечено NAT-ы не мапируют порт передаваеммый в этой команде.
Договорившись заранее о номере этого порта партнеры после обнаружения IP друг друга просто начинают что-то слать друг другу используя этот номер порта.
Цитата(edo @ May 21 2008, 19:57)

лень расписывать подробно, вкратце.
предоположим вы "пробили" nat.
вы написали, с какого адреса и порта вы будете слать пакеты. а на какой адрес?
с портами вам уже указали - при прохождении nat порты обычно не сохраняются.
и напоследок: вы посылаете пакет с "левым" src ip. скорее всего он будет отброшен, но даже если и нет - nat подменяет src ip.