Jingle/test
Contents
Конфигурация сети
- 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
Стало меня слышно. Регулятор микрофона тоже стал влиять на уволень звука.
Интерфейс для звонков достаточно простой - кнопкой с трубкой нажал - вызов пошел. У собеседника появляется окно с предложением ответить на звонок.
При работе столкнулись с тем, что при одновременном вызове друг друга мессаджбоксы с запросам зависают и не реагируют на выбранный в них вариант.
В Gajim существует баг (нужно указать номер в траке для контроля), что для видеосвязи камеры должны быть у обоих участников. также есть момент с тем что кнопка видеовызова активна вне зависимости от возможностей оппонента и собственных - она всегда активна, когда есть возможность общения голосом (т.е. есть Jingle).
FreeBSD + Empathy
Сломана сборка из порта - см вывод Make. Отписал на gnome@freebsd.org
FreeBSD + Jitsi
В портах отсутствует.
FreeBSD + Psi+
В портах нет, готовые сборки только под i386. Собрать по инструкции самостоятельно пока не получилось.
Отладка
У Psi выводятся сообщения в STDOUT, но все равно единственный вариант это tcpdump:
tcpdump -n -i age0 "udp and (src 217.25.221.127 or dst 217.25.221.127)"