Jitsi Meet

Что такое Jitsi Meet

Jitsi Meet — платформа видеоконференций с открытым исходным кодом под лицензией Apache 2.0. Участник открывает ссылку в браузере и попадает в конференцию: ни аккаунта, ни установки клиента не нужно. Всё работает на WebRTC.

Ключевое отличие от Zoom и Google Meet — Jitsi можно поднять на собственном сервере целиком. Тогда медиапоток не проходит через чужую инфраструктуру, и это единственная причина, по которой большинство и связывается с самостоятельным развёртыванием.

Публичный инстанс meet.jit.si доступен бесплатно и без регистрации — им пользуются как обычным сервисом, не разворачивая ничего. Разработку ведёт компания 8x8.

Из чего состоит

Jitsi — не одна программа, а набор сервисов, и понимать их роли нужно до установки:

SFU: почему сервер не задыхается

Jitsi Videobridge работает как SFU — Selective Forwarding Unit. Он не микширует видео: каждый участник отправляет свой поток один раз, а бридж просто пересылает его остальным. Перекодирования нет.

Отсюда главный практический вывод: упор идёт в сетевой канал, а не в CPU. Считать нужно пропускную способность канала, а не ядра. GPU для Jitsi не нужен вовсе — его нечем занять там, где никто не кодирует видео.

Трафик растёт квадратично: в конференции из N человек бридж принимает N потоков и отдаёт до N×(N−1). Поэтому в больших конференциях включаются simulcast (клиент шлёт несколько качеств, бридж выбирает подходящее для каждого получателя) и last-N (передаются только последние говорившие, остальные — статикой).

Исключение по нагрузке — Jibri: он запускает headless-браузер и пишет картинку через ffmpeg, то есть кодирует по-настоящему. Jibri прожорлив по CPU, ставится на отдельную машину, и один процесс пишет одну конференцию.

Сеть — где ломается чаще всего

Самостоятельная установка Jitsi обычно упирается не в сам Jitsi, а в сеть:

• 10000/UDP — медиатрафик JVB. Порт должен быть открыт, и это UDP. Если он закрыт, конференция «подключается» и рассыпается: сигнализация по 443 прошла, медиа — нет.
• 443/TCP — веб-интерфейс и fallback для медиа, когда UDP недоступен у клиента.
• NAT — если VPS за NAT и видит только приватный IP-адрес, нужно явно указать бриджу его внешний адрес, иначе он раздаст участникам нерабочие кандидаты:

org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.0.0.5
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=203.0.113.10

• Задержка канала важнее его ширины. Для видеосвязи latency и джиттер решают больше, чем гигабиты: сервер стоит размещать географически ближе к участникам.

Установка

Официальный путь — пакеты Debian из репозитория Jitsi (apt install jitsi-meet) или docker-jitsi-meet для Docker. Инсталлятор сам поднимет все компоненты, попросит доменное имя и получит SSL-сертификат Let's Encrypt.

До установки понадобятся: домен с A-записью на сервер, публичный IP и открытые 443/TCP и 10000/UDP.

По умолчанию комнату может создать любой, кто знает адрес, — имя комнаты и есть весь «пароль». Для корпоративной установки первым делом включают аутентификацию (prosody internal auth или OIDC-связка с внешним провайдером) и enableGuestDomain, иначе ваш сервер быстро станет чужой бесплатной переговоркой.

Шифрование: важная оговорка

Трафик всегда шифруется на участке клиент—сервер (DTLS-SRTP). Но SFU по своей природе видит потоки в открытом виде — иначе он не смог бы ими управлять. Настоящее сквозное шифрование (E2EE) в Jitsi есть, но включается отдельно и накладывает ограничения на функциональность.

Вывод: конфиденциальность при self-hosting обеспечивается прежде всего тем, что сервер ваш, а не тем, что данные недоступны серверу.

Связанные термины

• TCP и UDP — почему медиа идёт по UDP, а не по TCP
• NAT — главный источник проблем при развёртывании
• latency — определяет качество связи сильнее ширины канала
• OBS — подключается к Jitsi как виртуальная камера
• Rocket.Chat — мессенджер, в который Jitsi встраивают для звонков
• VPS — где обычно разворачивают свой инстанс