проблемы с RTMFP, возможно из-за NAT
 

сделал видео/текстовый чат на основе RTMFP, всё отлично работает. начал показывать заказчику и не выходит с ним соединиться, дал ему тестилку ту что по адресу cc.rtmfp.net у него в самой последней строке горит красная лампочка и написано "Source UDP port number is preserved from original connection" почитал, пишут что такое возможно из-за NAT'а через который юзер выходит в сеть, узнал у заказчика он действительно сидит за NAT'ом. Счас думаю что всё из-за того что или провайдер как то фильтрует UDP трафик, или NAT пропускает UDP пакеты только в одну сторону и не могу найти решения. Может кто то сталкивался с подобным и знает решение или может дело совсем не в UDP и NAT. В общем буду рад любой помощи.

На его роутере настройте проброс портов. Спека от Adobe расскажет по какому порту FP слушает поток RTMFP. На роутере настройте, что приходящие данные (UDP, а можно и both) на порт (см. спецификацию) переправлять на тот же порт, для конкретного IP (пропишите IP хоста, на который желаете получать контент во внутренней сети заказчика)
В целом, процедура такая же, как будто вы в Корбине и хотите торрентов.

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

Тогда подождем еще вариантов.

up.
столкнулся с подобной ситуацией при разработке приложения на основе сервиса суть которого передача медиа данных p2p.
кратко процесс: клиент соединяется с сервером adobe, получает peerId, отправляет его в бд сервера, сервер на запрос клиентов рассылает все имеющиеся peerId клиентам, клиенты пробуют проигрывать публикуемые от этих пиров данные.
Проблема в том, что находятся те, кто друг друга не видят. Заказчики ссылаются на чатрулет, в котором якобы все работает - смотрел реализацию, ничего нового не увидел, поэтому ставлю под сомнение этот аргумент.
На хабре вырвал фразу, что мол для работы нужен хотя бы один белый ip. Судя по тестам можно сделать такой вывод.
Поделитесь инфой, кто в теме.
Спасибо.

Что-то не правдоподобно звучит. Так называемый "белый" айпи отличается от серого только тем, что не меняется после переподключения. Работает на них все абсолютно так же. Проблема точно не в этом.

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

Ребята привет. У меня та же ситуация. Делаю игру на основе протокола RTMFP. у некоторых работает у некоторых нет. Причем тот юзер что не видит меня, он видит соседа который видит меня и я его вижу... Раздаю данные о пользователях при помощи sendToNearest. Уже пережевал все исходники либы Тома Крха. Теперь с закрытыми галазми можно делать любой сервис, но проблема эта не ушла...
Как что узнаю отпишусь тут... И жду от вас решений тоже... Вот кстати тут можно проверить связь http://vk.com/app2938490 тестировать с несколькими юзерами... Для входа нажать кнопку СОЗДАТЬ

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

Тут дело не в роутерах а в наших кривых руках, я уверен. Вот например есть приложение для проверки http://flashrealtime.com/demos/share...Movements.html у всех оно нормально открывается и все друг друга видят, а вот у меня чтото не то...