Комментарии 79
А что в этом замечательном Jitsi с авторизацией и ограничением доступа? Не говоря уже о ролях…
Вот и я о чем… Пароль на вход установить редко кому получается, если коннектиться на собственный сервер. Да и создание комнат любому желающему запретить — тот еще квест.
тот еще квест.

https://github.com/jitsi/jicofo#secure-domain
Только вот у меня не заработало в Debian 9/Debian 10 на текущих пакетах. Раньше (до обновления) работало


А вот то, что пароль не генерируется автоматом при создании комнаты — тот еще фейл. Если по какой-либо причине сервак "упал и быстро поднялся", то народ попадет в комнату раньше, чем админ успеет ввести пароль заново

Работает,
Скрытый текст
cat /etc/os-release
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',
},
}

при входе просто указываем логин без доменов
еще удобно проверять так
ldapsearch
ldapsearch -x -b «dc=local,dc=domen,dc=ru» -H ldap://local.domen.ru -D «jitsi» -W "(objectClass=person)" cn samaccountname | tail
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-собеседниках одновременно, которые тоже были за натом.

Справедливости ради надо заметить, что аутентификация по LDAP — не то, про что рассказывается в ридми jicofo

Я правильно понял, что, обосрали конкурента и вот на этом говне выехали, типа, смотрите, какие мы хорошие и бесплатные? Вот только воняет от вас, ребят(((

Крайне маловероятно, что Дата-центр «Миран» имеет непосредственное отношение к Jitsi Meet.
Jitsi — это продукт с открытым кодом который до 2018 года развивался Atlassian.


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

НЛО прилетело и опубликовало эту надпись здесь

Вероятно, потому что это не сравнение Zoom и Jitsi Meet, а обзор статей по теневым практикам Zoom, с предложением альтернативы в виде Jitsi, что (неявно) предполагает, то что она не является "шпионской"? При этом дополнительно были описаны основные возможности Jitsi Meet.


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

НЛО прилетело и опубликовало эту надпись здесь

Извините, но указано что Jitsi опенсорсный, это в том числе значит что тип шифрования можно проверить

Я наверное отстал от жизни. Но как реализуется end-to-end шифрование для видеоконференции? Весь рендеринг лежит на клиентских устройствах?

Никак — это миф. Сервер обязан обрабатывать потоки участников при проведении групповых видеоконференций, поэтому на самом сервере медиаданные находятся в открытом виде. Шифрование используется между сервером и клиентами, но сквозное шифрование возможно только в звонках точка-точка.

Чтобы смикшировать (склеить) в общую раскладку в случае традиционного подхода (аля MCU), тогда клиенты получат один поток. Либо чтобы выбрать слои с нужным качеством из видеопотоков от каждого из участников (SVC), далее уже наборы таких потоков пойдут клиентам.

Но можно же просто передавать потоки как есть, мультиплексировать шифрованные потоки в один и отдавать всем без декодирования.

Можно, конечно, но как такие потоки получит пользователь с плохим каналом / слабым ЦП / мобильным устройством? В реальных ВКС системах очень важно индивидуально каждому клиенту регулировать битрейт в реальном времени.

Ну, вот поэтому у Зума качество лучше, а защита хуже. А так, в принципе, каждый клиент может генерировать несколько (2-3) исходящих потоков с разным качеством, например. Либо всегда, либо по запросу от сервера или клиента с плохим каналом.

Именно так и работают Jitsi, Webex Meeting, Google Hangouts (в некоторых сценариях) — это называется Simulcast. К сожалению такой подход не позволяет достаточно гибко регулировать битрейт и всегда найдётся такой участник из-за которого качество связи будет ухудшено для всех, иначе он вообще ничего не увидит.

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

Возьмём для примера Jitsi он кодирует 720p, 360p, 180p от каждого участника. Получается всего три битрейта ~1024kbps, 512kbps и 256kbps. Предположим мой входящий канал 2048kbps, значит после 8 участников на экране Simulcast сервер начнёт выключать мне видео потоки от некоторых участников или даст команду всем остальным участникам ухудшить базовое качество (180p), в итоге они из-за меня будут страдать.


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


Плюс такой набор из 3 битрейтов ограничивает нас всего двумя раскладками: один большой + все очень маленькие или все одного размера.


Ну и не стоит забывать, что Simulcast предъявляет повышенные требования к мощности ПК участников и их исходящему каналу связи.


В общем, все эти проблемы уже давно решены в SVC. Ждём когда разработчики браузеров реализуют внутри себя функции масштабируемого кодирования, которые уже есть в самом стандарте WebRTC.

Я совсем не это имел в виду. Зачем вообще постоянно отдавать по три фиксированных потока? Каждый клиент знает, какие потоки и с каким битрейтом ему нужны, соответственно, эту информацию он может передавать серверу, а тот — всем остальным. И если вам и ещё кому-то нужен входящий поток низкого битрейта, скажем, 128kbps, а всем остальным — нет, сервер просто должен раздать всем участникам кроме вас команду кодировать исходящее видео в 128 (для вас двоих) и в 1024 (для всех остальных). То же и с раскладками: вы имеете в виду, что в зависимости от того, какого размера у вас области отображения на экране, для них должны использоваться разные потоки? Ну, перекодировать на сервере каждый поток под каждый лишний пиксель экрана каждого клиента вряд ли осмысленно, но и зная потребности клиентов, можно выбрать какие-то наиболее востребованные разрешения (1-2), в которые попросить клиентов кодировать исходящие потоки, не привязываясь к фиксированному набору «из коробки».

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


Не забывайте, что разрашения экранов, качество каналов связи, возможности CPU+GPU, задержки от сервера и выбранные раскладки у каждого участника разные. Тут 2-3 "слоёв" с разным битрейтом не достаточно, чтобы каждому дать по его возможностями без ущерба остальным.

Ну, если SVC позволяет просто дропать лишние пакеты, то можно же и шифрование на уровне пакетов делать, тогда серверу не придётся их расшифровывать для регулировки битрейта.

Да, вы правы, мой тезис про миф неверен. Но вот почему-то Zoom этого не делал.

Но вот я про общий случай. Всё это нужно только для отдельных частных фич.
P.S. А для SIP-телефонов всё равно нужен SIP-шлюз, не обязательно его интегрировать с сервером конференций.
Уже довелось опробовать Jitsi. Iphone 11 Pro Max за два часа видеочата из 12 человек продержался со 100% до 56%. Видеочат работает хорошо и качество картинки не оставляет плохих впечатлений, у модератора канала есть опция кика и заглушить всех, что очень полезно. Так что кому требуется видеосвязь — хорошая альтернатива.
На «старом», т.е. не Pro, iPad/iPhone приложение не работает, в браузере серый экран.
Я на iphone 6 plus запускал приложение с последней доступной 12.4.6 — подтупливает при количестве участников более 5, но работает.
Вероятно, браузер нужен более свежий из appstore
Искал на днях свободный софт для видеосвязи. Jitsi находил, ещё и Jami нашёлся. Для обоих есть клиенты в F-Droid. Сам не смотрел пока, но может кто-нибудь может прокомментировать, что из этого лучше или перспективнее?
Как на счёт Nextcloud Talk? Есть клиенты и под Андроид и под iOS, но всё работает и в браузере (и в мобильном). Есть видео-аудио конференции, есть просто чат, плюс интеграция с остальными сервисами Nextcloud.

Использовал jitsi для занятий, необходимо войти первым в комнату, чтобы стать модератором. Установил пароль и поделился ссылкой со студентами. Транслировал около 2 часов рабочий стол, студенты периодически завали вопросы, в общем все было хорошо. Есть плагин для Moodle. По сравнению с bigbluebutton понравилась скорость работы и качеств картинки. Чего не хватает: какой либо простой авторизации и постоянного модератора.

Хватает: и авторизация и модераторы (права на отдельных юзеров по их логинам- почтам) и даже ldap конторы на 300 человек прикрутил. И все это в докере закрутил. В целом вещь годная. Разве что на Сафари не заводится, но это уже мелочи.

Скажите, пожалуйста, можно ли там быстро выборочно приглушить несколько человек, чтобы слышать только свою подгруппу и учителя (например когда надо для занятия разбиться попарно или по трое)? Что-то такое есть в дискорде, но надо прям на каждом слазить в меню, не получается быстро прокликать как в Zoom. А Zoom нынче тормозит до безобразия, даже просто вход
Там все в одной комнате и всем всё слышно. Но есть кнопка «Ну ка все заткнулись».

Уже лет 8 хватает опенсорсного bigbluebutton
Да, не без косяков, но всегда можно взять и поправить, что не нравится.

К BBB еще можно прикрутить интеграцию с SIP, очень удобно в случае если нет микрофона/наушников, но есть телефон.
но отношение Zoom к приватности от этого не изменилось

У пользователей к Zoom тоже — все продолжают пользоваться Зумом, потому что большинству, как мы поняли, плевать с высокой колокольни на какие-то там данные. Работает — и ладно.

За обзор Jitsi спасибо, я уж и забыл что такой софт существует, а он, оказывается, ещё и развивается. Приятно, что опенсорс научился в качественные видеоконференции, да ещё и self-hosted, то есть без привязки к этим вот вашим облакам. Это греет душу.

Есть, конечно, и ложка дёгтя — отсутствие нативного клиента для Jitsi Meet. JS в браузере (и вне тоже) это, конечно, прикольно-модно-молодёжно, но не у всех есть настолько мощные компьютеры и смартфоны. Хотелось бы видеть нативные реализации клиентов Jitsi Meet, а не только браузерно-электронные поделия.
android работает посредственно
вот два примера

1) комната создана через портал jitsi (ссылка вида meet.jit.si) — вроде работает нормально
2) комната создана через self-hosted jitsi сервер (ldap, и т.п.) — приложение подключается, видно участников, но никого не слышно :-(

Ну и «работает только в хром» неравно «работает в браузере». Причем в том же edge chrome и chrome opera — так же не работает!
У нас свой hosted, всех видно и слышно. Надо смотреть на конфиг hosted у вас :-)
2) комната создана через self-hosted jitsi сервер (ldap, и т.п.) — приложение подключается, видно участников, но никого не слышно :-(

Так у вас может быть сетевая проблема.
Спасибо, надо попробовать, сегодня буквально огорошили такой-же задачей, с вводной «нужно было вчера!»
все почему-то обходят внимаем самый обычный Skype.
на удивление просто и удобно в нем жит при удаленно-карантинной работе.
В нём нужно регистрироваться и указывать номер телефона. Чтобы начать использовать Jitsi Meet достаточно просто открыть ссылку на чат-комнату.
Да, в этом варианте зум и прочие удобнее. можно не палить контакты коллег если надо.
Но скайп позволяет просто позвонить и оказаться «лицом к лицу» без назначения встреч, отправки ссылок и прочего. Моментально. Зачастую такой режим оказывается эффективнее.

Вроде в новостях было что микрософт разрешил присоединять по ссылке

Скайп тормозит. По этому показателю он перегнал абсолютно все средства коммуниации.
Возможно он более прожорлив. Но это не вызывало никогда проблем ни с телефона ни с ноута.
У меня правда конференции макс на 10..15 человек были.

Я не то чтобы евангелист скайпа — просто к нему зачастую относятся предвзято, хотя он удобен и прост.
Он прост, и всё. Никакого удобства в отвисающем интерфейсе нет. На телефоне он вжирает батарею и греет процессор, на компьютере просто тормозит и отъедает оперативую память как не в себя.
В одной из версий Firefox была встроена подобная функция Firefox Hello, но потом ее почему то выпилили. И предлагают пользоваться альтернативами в числе которых и Jitsi.
Насколько я понимаю все мессенжеры с поддержкой видеоконференций упираются в необходимость наличия сервера, который будет пропускать через себя видеопотоки всех пользователей. Да, наверное где-то есть P2P, но только до того момента пока у всех участников есть адрес не за NAT. Это довольно внушительный трафик и мощность. В чем профит предоставлять такое бесплатно?
Там чистый p2p, даже за NAT. Для тех, кто за NAT, используется STUN сервер, который нужен только при коннекте.

Если вы о Jitsi, то потоки в групповых конференциях проходят через их сервер, т.е. это не P2P.

Подскажите какой-либо бесплатный (или недорогой) вариант сервера, где можно развернуть Jisti, чтобы работало более или менее стабильно?

1) Последние билды Джитси стали очень багованые и если следовать руководству по быстрой установке, то чаще всего у вас что-то не заработает

2) Джитси жрет очень много трафика, и использовать более менее нормально можно только с хромом

3) Если вы хотите записать или танслировать на ютуб одну сессию, вам понадобится отдельный сервер(!) на одну сессию, если я правильно помню.

4) До сих пор у кучи народа баг, когда кто-то присоединяется и получаем «something went wrong» ошибка, это прямо напасть настоящая

Я давно присматривался к джитси, и пробовал несколько раз его, но всегда «общение» прекращал с продуктом.

Я больше склоняюсь к Bigbluebutton, но там есть проблема с crackling звуками, которую надо решить тонкой настройкой джиттер буфера во freeswitch конфиге, сейчас там народ на форуме ихнем пытается подобрать работающие
вам понадобится отдельный сервер(!) на одну сессию, если я правильно помню.

А секрет в том, что jirecon запускает целый chromium в виртуальном фреймбуффере и сохраняет картинку/звук как видеопоток. При том, что сам Jitsi Meet/WebRTC довольно жаден до ресурсов процессора.


Джитси жрет очень много трафика

Да, абы на каком 3G он тупо не будет работать. Удивительно, но Zoom как-то умудряется

Удивительно, но Zoom как-то умудряется
У Зума данные через сервер передаются, причём, нешифрованными, т.ч. от каждого клиента только 1 исходящий поток, а входящий может даунскейлиться сервером в соответствии с шириной канала.
Но ведь у Jitsi Meet тоже Simulcast
Это вы к чему?
Jitsi — p2p. Там поток через сервер не проходит, насколько я понимаю.
тот же SFU
Services for UNIX? Simon Fraser University?

Вы этим Jitsi Meet хоть раз пользовались? Там полноценный Selective Forwarding Unit, называется jitsi-videobridge2. P2P режим можно включить, когда участников в конференции два и только два. При подключении третьего траффик начинает идти через сервер

У Jitsi схема по-лучше, чем обычный SFU, там полноценный Simulcast. Каждый клиент кодирует три потока (720p, 360p и 180p) и отправляет на сервер, т.е. сервер получает 3*N потоков. Далее сервер, в зависимости от выбранной раскладки у участника, формирует для него индивидуальный набор потоков.

Здравствуйте, у меня вопрос
До 75 участников (до 35 при сохранении высокого качества связи)


Почему ограничение, если на своем сервере нужно устанавливать?

Дальше
Технически продвинутые пользователи могут поднять у себя собственный сервер Jitsu Videobridge, который обрабатывает в реальном времени тысячи видеопотоков по WebRTC


Так 75 — ограничения публичного сервера, если да — то какого именно?
Jitsi Desktop тоже очень удобная программа, она правда legacy, но тем не менее работает и позволяет устраивать конференции
Кто знает, как в Jitsi Desktop под Windows сделать сворачивание проги исключительно в трей. Чтобы на панели задач значок не оставался, а только в трее?
Настройка «Minimize the main window instead of closing or hiding it» — делает прогу свернутой и в трее, и на панели задач. На панели задач она не нужна, руки у многих чешутся её закрыть совсем и у меня тоже :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
miran.ru
Численность
51–100 человек
Дата регистрации

Блог на Хабре