Jingle/test

Статьи по этой теме на других вики-сайтах:
	Обсуждение:Jingle — JabberWorld

Какие генеральные проблемы мешают нормально общаться голосом и использовать видеокамеру.

1. Малое количество клиентов поддерживающих Jingle
2. Неотлаженность реализации Jingle в клиентах.
3. Конфигурация BSD-based NAT-ов - см. раздел ниже

Инструкция для пользователей

• В Psi для разговора надо в правокнопочном меню контакта, с которым вы хотите поговорить выбрать Voice Call.
• В Gajim в окне чата есть кнопка с пиктограммой старостильного микрофона и вебкамеры. Каждая из кнопок устанавливает свой тип связи. Если кнопки неактивны, а вы знаете что у собеседника все необходимое для мультимедийного звонка есть, то закройте окно и снова откройте - кнопки станут активными (это так проявляется еще неисправленная ошибка)
• В Pidgin - в правокнопочтом меню контакта появляется Audio Call с иконкой гарнтитуры, а также Audio/Video Call с иконкой вебкамеры. Появляются они в зависимости от того, поддерживает ли контакт эти способы связи.

Ситуация с FreeBSD

С FreeBSD и другими BSD-системами. По-видимому, в большинстве этим систем NAT реализуется способами, которые по умолчанию используют случайный выбор портов для установления соединения. Что является серьезным препятствием для работы Jingle. По-видимому, эта рандомизация применяется для повышения безопасности этих систем (защита от спуфинга?). На Linux такого поведения по умолчанию нет.

Системным администраторам можно порекомендовать изменять поведение NAT (по-видимому, это большого влияния на безопасность это не окажет), с тем чтобы порты оставались те, которые приложение запросило и согласовало с второй стороной.

pf

Вместо nat on $ext_if from $int_net to any -> $ext_addr следует писать

nat on $ext_if from $int_net to any -> ($ext_if) static-port 

Например, внутренняя сеть 192.168.5.0/24, IP на внешнем интерфейсе (единственный что есть, как указывая явно - надо уточнить), em0 - сетевой контроллер, смотрящий наруж:

nat on em0 from 192.168.5.0/24 to any -> (em0) static port

natd

проверить и написать

ipfw

проверить и написать

ipfilter

проверить и написать

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

• 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)

Сочетания клиентов

• Psi+,Ubuntu - Gajim,Gentoo - ок

Версии ПО

• 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) - голос в обе стороны работал. но проблема что после минуты-другой падал флэш хабовский.
• Jitsi 1.0 beta1 build 3593, Linux <=> Windows — голос работал, но видео тормозилось (фактически статично отображался первый кадр). Через пару минут завис Linux-клиент.
  Обновление: тестовый звонок через build 3820 ‒ качество видеосвязи улучшилось, клиент не вис.

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

• 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

Gajim не ниже версии 0.14.1 должно быть - до этого поддержки голоса не было. Старый клиент можно заметить еще и потому что в у него настройках нету вкладки Audio/Video.

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

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

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

Подробности установки 

{{{1}}}

На вкладке 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).

Также есть еще ошибка, при которой кнопки голосового и видеовызова неактивны (хотя клиент собеседника имеет необходимые возможности) - для этого надо закрыть окно чата и открыть его повторно.

Еще один баг заключается в том, что если вы один раз не приняли вызов, то он подвисает и нельзя уже согласиться с последующими вызовами. Это исправляется только перезапуском клиента.

Вариант NAT-NAT

На той же вкладке Audio/Video указывается stun.iptel.org

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)"