Comments 79
тот еще квест.
https://github.com/jitsi/jicofo#secure-domain
Только вот у меня не заработало в Debian 9/Debian 10 на текущих пакетах. Раньше (до обновления) работало
А вот то, что пароль не генерируется автоматом при создании комнаты — тот еще фейл. Если по какой-либо причине сервак "упал и быстро поднялся", то народ попадет в комнату раньше, чем админ успеет ввести пароль заново
PRETTY_NAME=«Debian GNU/Linux 10 (buster)»
NAME=«Debian GNU/Linux»
VERSION_ID=«10»
VERSION=«10 (buster)»
VERSION_CODENAME=buster
ID=debian
HOME_URL=«www.debian.org»
SUPPORT_URL=«www.debian.org/support»
BUG_REPORT_URL=«bugs.debian.org»
dpkg -l|grep jitsi
ii jitsi-meet 2.0.4416-1 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.3992-1 all Prosody configuration for Jitsi Meet
ii jitsi-meet-turnserver 1.0.3992-1 all Configures coturn to be used with Jitsi Meet
ii jitsi-meet-web 1.0.3992-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.3992-1 all Configuration for web serving of Jitsi Meet
ii jitsi-videobridge2 2.1-169-ga28eb88e-1 all WebRTC compatible Selective Forwarding Unit (SFU)
# cat /etc/prosody/conf.d/ldap.cfg.lua
— modules.prosody.im/mod_lib_ldap.html
— modules.prosody.im/mod_auth_ldap2.html
authentication = 'ldap2'
ldap = {
hostname = 'local.domen.ru',
bind_dn = 'jitsi',
bind_password = 'password',
use_tls = false, --выключаем
user = {
basedn = 'dc=local,dc=domen,dc=ru',
filter = '(objectClass=person)',
usernamefield = 'sAMAccountName',
namefield = 'cn',
},
}
при входе просто указываем логин без доменов
еще удобно проверять так
Enter LDAP Password:
# search reference
ref: ldap://local.domen.ru/CN=Configuration,DC=local,DC=domen,DC=ru
# search result
search: 2
result: 0 Success
# numResponses: 986
# numEntries: 982
# numReferences: 3
Самое удивительное, что видео и звук работает, даже если сервер за NAT, проверялось на 3-собеседниках одновременно, которые тоже были за натом.
Крайне маловероятно, что Дата-центр «Миран» имеет непосредственное отношение к Jitsi Meet.
Jitsi — это продукт с открытым кодом который до 2018 года развивался Atlassian.
Конечно, у них могут работать контрибьюторы, да и использовать у себя они его могут, но конкурентами это их не не делает.
Вероятно, потому что это не сравнение Zoom и Jitsi Meet, а обзор статей по теневым практикам Zoom, с предложением альтернативы в виде Jitsi, что (неявно) предполагает, то что она не является "шпионской"? При этом дополнительно были описаны основные возможности Jitsi Meet.
Чуваки просто решили рассказать про продукт с выжимкой из разных источников. Какие-то тут комментаторы токсичные прямо как фанаты ксяоми.
Никак — это миф. Сервер обязан обрабатывать потоки участников при проведении групповых видеоконференций, поэтому на самом сервере медиаданные находятся в открытом виде. Шифрование используется между сервером и клиентами, но сквозное шифрование возможно только в звонках точка-точка.
Чтобы смикшировать (склеить) в общую раскладку в случае традиционного подхода (аля MCU), тогда клиенты получат один поток. Либо чтобы выбрать слои с нужным качеством из видеопотоков от каждого из участников (SVC), далее уже наборы таких потоков пойдут клиентам.
Можно, конечно, но как такие потоки получит пользователь с плохим каналом / слабым ЦП / мобильным устройством? В реальных ВКС системах очень важно индивидуально каждому клиенту регулировать битрейт в реальном времени.
Именно так и работают Jitsi, Webex Meeting, Google Hangouts (в некоторых сценариях) — это называется Simulcast. К сожалению такой подход не позволяет достаточно гибко регулировать битрейт и всегда найдётся такой участник из-за которого качество связи будет ухудшено для всех, иначе он вообще ничего не увидит.
всегда найдётся такой участник из-за которого качество связи будет ухудшено для всех, иначе он вообще ничего не увидит.Погодите-погодите, если каждый клиент может параллельно передавать серверу несколько исходящих потоков с разными битрейтами, а сервер уже будет передавать каждому только соответствующий ширине его канала, соответственно, то те клиенты, у которых проблем с шириной нет, страдать при этом не должны никак, их же это не коснётся.
Кроме того, сервер может и прямо передавать клиенту информацию о том, какого битрейта потоки сейчас от него нужны.
Возьмём для примера Jitsi он кодирует 720p, 360p, 180p от каждого участника. Получается всего три битрейта ~1024kbps, 512kbps и 256kbps. Предположим мой входящий канал 2048kbps, значит после 8 участников на экране Simulcast сервер начнёт выключать мне видео потоки от некоторых участников или даст команду всем остальным участникам ухудшить базовое качество (180p), в итоге они из-за меня будут страдать.
На мобильных устройствах будет другая проблема, они либо не смогут одновременно декодировать большое кол-во потоков даже с базовым качеством (из-за ограниений ЦП), либо будут быстро съедать батарею, т.к. сервер не может выдать им меньший битрейт.
Плюс такой набор из 3 битрейтов ограничивает нас всего двумя раскладками: один большой + все очень маленькие или все одного размера.
Ну и не стоит забывать, что Simulcast предъявляет повышенные требования к мощности ПК участников и их исходящему каналу связи.
В общем, все эти проблемы уже давно решены в SVC. Ждём когда разработчики браузеров реализуют внутри себя функции масштабируемого кодирования, которые уже есть в самом стандарте WebRTC.
В теории это возможно, но уже не нужно, т.к. есть SVC. На практике клиент просто не способен столько копий своего видео параллельно кодировать, чтобы всем угодить. Далеко не все абоненты имеют топовые ЦП и находятся в локальной сети.
Не забывайте, что разрашения экранов, качество каналов связи, возможности CPU+GPU, задержки от сервера и выбранные раскладки у каждого участника разные. Тут 2-3 "слоёв" с разным битрейтом не достаточно, чтобы каждому дать по его возможностями без ущерба остальным.
Ради интеграции с SIP-телефонами
Использовал jitsi для занятий, необходимо войти первым в комнату, чтобы стать модератором. Установил пароль и поделился ссылкой со студентами. Транслировал около 2 часов рабочий стол, студенты периодически завали вопросы, в общем все было хорошо. Есть плагин для Moodle. По сравнению с bigbluebutton понравилась скорость работы и качеств картинки. Чего не хватает: какой либо простой авторизации и постоянного модератора.
Хватает: и авторизация и модераторы (права на отдельных юзеров по их логинам- почтам) и даже ldap конторы на 300 человек прикрутил. И все это в докере закрутил. В целом вещь годная. Разве что на Сафари не заводится, но это уже мелочи.
из сложно там подобрать нужный фильтр (и на стороне АД если это мелкософт юзера сделать админом по умолчанию)
Уже лет 8 хватает опенсорсного bigbluebutton
Да, не без косяков, но всегда можно взять и поправить, что не нравится.
но отношение Zoom к приватности от этого не изменилось
У пользователей к Zoom тоже — все продолжают пользоваться Зумом, потому что большинству, как мы поняли, плевать с высокой колокольни на какие-то там данные. Работает — и ладно.
За обзор Jitsi спасибо, я уж и забыл что такой софт существует, а он, оказывается, ещё и развивается. Приятно, что опенсорс научился в качественные видеоконференции, да ещё и self-hosted, то есть без привязки к этим вот вашим облакам. Это греет душу.
Есть, конечно, и ложка дёгтя — отсутствие нативного клиента для Jitsi Meet. JS в браузере (и вне тоже) это, конечно, прикольно-модно-молодёжно, но не у всех есть настолько мощные компьютеры и смартфоны. Хотелось бы видеть нативные реализации клиентов Jitsi Meet, а не только браузерно-электронные поделия.
вот два примера
1) комната создана через портал jitsi (ссылка вида meet.jit.si) — вроде работает нормально
2) комната создана через self-hosted jitsi сервер (ldap, и т.п.) — приложение подключается, видно участников, но никого не слышно :-(
Ну и «работает только в хром» неравно «работает в браузере». Причем в том же edge chrome и chrome opera — так же не работает!
на удивление просто и удобно в нем жит при удаленно-карантинной работе.
Но скайп позволяет просто позвонить и оказаться «лицом к лицу» без назначения встреч, отправки ссылок и прочего. Моментально. Зачастую такой режим оказывается эффективнее.
Вроде в новостях было что микрософт разрешил присоединять по ссылке
Подскажите какой-либо бесплатный (или недорогой) вариант сервера, где можно развернуть Jisti, чтобы работало более или менее стабильно?
2) Джитси жрет очень много трафика, и использовать более менее нормально можно только с хромом
3) Если вы хотите записать или танслировать на ютуб одну сессию, вам понадобится отдельный сервер(!) на одну сессию, если я правильно помню.
4) До сих пор у кучи народа баг, когда кто-то присоединяется и получаем «something went wrong» ошибка, это прямо напасть настоящая
Я давно присматривался к джитси, и пробовал несколько раз его, но всегда «общение» прекращал с продуктом.
Я больше склоняюсь к Bigbluebutton, но там есть проблема с crackling звуками, которую надо решить тонкой настройкой джиттер буфера во freeswitch конфиге, сейчас там народ на форуме ихнем пытается подобрать работающие
вам понадобится отдельный сервер(!) на одну сессию, если я правильно помню.
А секрет в том, что jirecon запускает целый chromium в виртуальном фреймбуффере и сохраняет картинку/звук как видеопоток. При том, что сам Jitsi Meet/WebRTC довольно жаден до ресурсов процессора.
Джитси жрет очень много трафика
Да, абы на каком 3G он тупо не будет работать. Удивительно, но Zoom как-то умудряется
Удивительно, но Zoom как-то умудряетсяУ Зума данные через сервер передаются, причём, нешифрованными, т.ч. от каждого клиента только 1 исходящий поток, а входящий может даунскейлиться сервером в соответствии с шириной канала.
Но ведь у Jitsi Meet тоже Simulcast, и тот же SFU.
Но ведь у Jitsi Meet тоже SimulcastЭто вы к чему?
Jitsi — p2p. Там поток через сервер не проходит, насколько я понимаю.
тот же SFUServices for UNIX? Simon Fraser University?
Вы этим Jitsi Meet хоть раз пользовались? Там полноценный Selective Forwarding Unit, называется jitsi-videobridge2. P2P режим можно включить, когда участников в конференции два и только два. При подключении третьего траффик начинает идти через сервер
До 75 участников (до 35 при сохранении высокого качества связи)
Почему ограничение, если на своем сервере нужно устанавливать?
Дальше
Технически продвинутые пользователи могут поднять у себя собственный сервер Jitsu Videobridge, который обрабатывает в реальном времени тысячи видеопотоков по WebRTC
Так 75 — ограничения публичного сервера, если да — то какого именно?
Настройка «Minimize the main window instead of closing or hiding it» — делает прогу свернутой и в трее, и на панели задач. На панели задач она не нужна, руки у многих чешутся её закрыть совсем и у меня тоже :)
Jitsi Meet: опенсорсная альтернатива «шпионскому» видеоприложению Zoom