Jingle/test

Конфигурация сети

• Binary: Primary: Indepndent Mapping, Port Dependent Filter, preserves ports, no hairpin
• Leksey: Primary: Indepndent Mapping, Port Dependent Filter, random port, no hairpin (nat на базе pf с nat on $ext_if from $int_net to any -> $ext_addr)
• leksey@дома: Primary: Port Restricted Nat, preserves ports, no hairpin (natd, FreeBSD 7.0 natd_enable="YES")
• b108: Primary: Indepndent Mapping, Port Dependent Filter, preserves ports, no hairpin (Return value is 0x000017)

Версии ПО

• Empathy версия 2.30.2 из Ubuntu 10.04.1 LTS (lsb_release -a) - настройки STUN в этом клиенте нету. Может брать из SRV? Но надо тогда чтобы у обоих JID был прописан у сервера?

Результаты

• Empathy leksey => Gmail leksey' pal в браузере под MS Windows (ставится плагин бинарный в браузер, чтоб можно было звонить) = голос слышали на стороне MS Windows, изображения не было (не умеет? или не сработало?)
• Empathy leksey => Gajim binary - не получилось установить соединение, кроме того, встретился баг Gajim с тем что клиент после первой попытки соединения полагает что оно уже установлено и отвергает последующие
• Empathy leksey <=> Empathy leksey' soworker - все работало - кроме звука в одну сторону. Но машины были в одной локалке при этом.
• Empathy leksey <=> Empathy b108 (21 April 2011) - не установилось даже соединение
• HabaHaba leksey <=> Empathy b108 (21 April 2011) - голос в обе стороны работал. но проблема что после минуты-другой падал флэш хабовский.

Клиенты которые следует проверить

• Psi c Psimedia (в генте есть пакет psimedia, который вроде ставится и на обычную пси)
• Psi+ c Psimedia
• Gajim
• Jitsi
• Habahaba

---

• В дебиане кривая сборка Psi+ - падает.
• Jitsi нет в репозитариях Ubuntu

Которые нет смысла проверять

• Gajim для MS Windows - тот фреймворк что они используют для виндоза отсутствует

Определение конфигурации

Берется из вывода stun-клиента, запущенного следующим образом. Версия для MS Windows, FreeBSD, Ubuntu (sudo apt-get install stun)

stun_client stun.xten.com

MS Windows

client.exe stunserver.org

Описание NAT

Random port означает, что данная реализация NAT не заботится о том, чтобы номер порта источника в исходящем наружу пакете оставался таким же, каким он был получен от хоста локальной сети, и заменяет его на случайное значение в диапазоне от 1024 до 65535. Можно предположить, что по замыслу автора идеи «random ports» такая замена уменьшает вероятность конфликта между записями, если несколько хостов локальной сети одновременно попытаются отправить наружу пакеты с совпадающим номером порта источника.

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

Как видно из примера, наш маршрутизатор старается сохранять номер порта неизменным (11.22.33.44:1053 и 192.168.0.141:1053), из чего следует, что запущенный в его локальной сети STUN-клиент сообщил бы о нем preserves ports.

К слову, на FreeBSD этот результат достигается ключом «-same_ports» или «-s» в строчке запуска или конфигурационном файле демона natd. Есть возможность поставить ключ и проверить?

FreeBSD, Psi 0.14 + Psi-media

Внешний IP с единственной настройкой в rc.conf ifconfig_age0="dhcp"

Проблема - случайно выбирается порт для установления соединения, что не позволяет работать когда на одной из сторон NAT. Видимо, psi не делает специального указания, с какого порта слать

• Сменен порт в настройках Psi (в поле Data transfer base port) с 8010 на 49152 (в соответствие с The Ephemeral Port Range). Поле Data transfer externak adress для указания "внешнего" адреса при работе со STUN и поэтому оно должно быть пустым.

Не помогло.

• Выключена рандомизация (Ports are allocated at random within the specified port range in order to increase the difficulty of random spoofing attacks) sysctl net.inet.ip.portrange.randomized=0

После этого вместо рандовного выбора - стало последовательно наращивать адреса, но тоже выбирая рандомно их диапазон.

18:42:24.588741 IP 89.250.8.14.51357 > 217.25.221.127.60529: UDP, length 92
51357 != 49152

Лог (в комменте)

FreeBSD, Gajim

С моей стороны публичный IP, у собеседников NATы неизвестного типа. У первого Gentoo, у второго Debian.

Обновил порты, установил на днях обновившийся gajim-0.14.3. Все OPTIONS по умолчанию оставлены. Соответственно, [x]DBUS взведен

make install clean -C /usr/ports/net-im/gajim

На вкладке Audio/Video в настройках Gajim все контролы заблокированы.

Установил програмный каркас Farsight.

make install clean -C /usr/ports/net-im/farsight2

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

Собеседник с Debian выполнил

apt-get install gajim
apt-get install python-farsight

В окне чата, контакта который поддерживает передачу звука (в этом случае был другой Gajim) кнопки с изображением микрофона и камеры активные. По нажатию на первую установилось соединение. Но меня не слышно. В самом окне после установления соединения появляется уровень микрофона и звука, но все равно не слышно.

Выполнил в консоли (до этого было Mixer mic is currently set to 0:0)

mixer mic 100

Стало меня слышно. Регулятор микрофона тоже стал влиять на уволень звука.

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

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

FreeBSD + Empathy

Сломана сборка из порта - см вывод Make. Отписал на gnome@freebsd.org