Jingle/test

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

• Binary: Primary: Indepndent Mapping, Port Dependent Filter, preserves ports, no hairpin
• Leksey: Primary: Indepndent Mapping, Port Dependent Filter, random port, no hairpin
• leksey@home: to check
• 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

Описание 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. Есть возможность поставить ключ и проверить?