Видеосвязь для компании без зарубежной подписки: свой сервер вместо Zoom

MAATRIX

Zoom, Microsoft Teams, Google Meet — к концу лета 2026 года для многих российских компаний сама оплата зарубежной подписки превратилась в отдельный квест: банк режет платёж по SWIFT или Visa/Mastercard, сервис требует адрес выставления счёта из «поддерживаемой» страны, а бесплатный тариф с лимитом в 40 минут на звонок годится разве что для коротких пятиминуток. Поднять видеоконференции на собственном сервере — рабочее и не такое сложное решение, как может показаться: за вечер разворачивается система, которая закрывает регулярные созвоны команды без ежемесячной платы за место в чужом облаке. Разберём, какую платформу брать, что заложить в сервер по сети и процессору, и на каких граблях почти всегда спотыкаются при первом запуске.

Что выбрать: обзор open source платформ для видеосвязи

Для замены Zoom под регулярные рабочие созвоны реалистично рассматривать три направления.

Jitsi Meet — самый распространённый выбор для этой задачи. Участник заходит по ссылке в браузере без установки клиента, платформа построена вокруг Jitsi Videobridge (JVB) — Selective Forwarding Unit, который пересылает потоки между участниками, а не перекодирует их на лету. Это даёт умеренную нагрузку на CPU при обычных звонках и простую модель масштабирования. Из коробки есть демонстрация экрана, чат, поднятие руки, запись через отдельный компонент Jibri (тяжелее в настройке и ресурсоёмкий, если он вам не критичен — на старте можно обойтись без него).

BigBlueButton — платформа с прицелом на образование и вебинары: встроенная интерактивная доска, комнаты для групповой работы (breakout rooms), опросы, презентации со слайдами прямо в интерфейсе. Функциональнее Jitsi для обучающих форматов, но и тяжелее в развёртывании — требует больше сервисов под капотом (FreeSWITCH, Kurento/mediasoup, отдельная БД) и заметно прожорливее по ресурсам на то же число участников.

Nextcloud Talk — вариант, если у компании уже развёрнут Nextcloud для файлов: видеозвонки идут как встроенный модуль, без отдельного сервера под конференции. Плюс в интеграции с остальной экосистемой (файлы, календарь, чат), минус — как отдельный видеосервис Talk уступает Jitsi по качеству SFU-пересылки при большом числе участников, и для этого его придётся донастраивать (внешний сигнальный сервер, coturn).

Для типовой задачи «команда из 5–30 человек, регулярные созвоны, минимум администрирования» разумный дефолт — Jitsi Meet: он проще всего разворачивается, не требует установки клиента у участников и достаточно экономен по ресурсам. Подробный процесс установки и конфигурации разобран в статье как установить и настроить Jitsi Meet на VPS; там же честное сравнение Jitsi с более тяжёлым BigBlueButton — в материале Jitsi Meet или BigBlueButton: что выгоднее и когда.

Требования к серверу: сеть и вычисления

Ключевая ошибка при первом расчёте сервера — думать в первую очередь про CPU и забывать про канал. У видеоконференций именно ширина полосы обычно упирается в потолок раньше процессора.

Полоса пропускания. Каждый участник в звонке отправляет свой видеопоток на сервер (аплинк) и получает потоки остальных (даунлинк). При стандартном разрешении для веб-камеры (условно 480p–720p с адаптивным битрейтом) один поток занимает ориентировочно от 0,3 до 1,5 Мбит/с в зависимости от движения в кадре и настроек кодека — это грубый ориентир, реальные цифры у вас будут отличаться в зависимости от кодека (VP8/VP9/AV1), включённого simulcast и качества исходной картинки. Критично то, что нагрузка на сервер асимметрична и растёт быстрее числа участников: при N участниках сервер отдаёт около N×(N-1) потоков в худшем случае без ограничений, поэтому Jitsi по умолчанию включает механизм last-N и адаптивный битрейт, чтобы не отправлять всем все потоки в полном качестве одновременно. Для команды до 15–20 человек в звонке с включённым last-N канала в 100–200 Мбит/с на сервере с запасом хватает; для больших вебинаров с десятками зрителей стоит закладывать канал от 500 Мбит/с и выше и проверять тариф VPS на предмет реального ограничения полосы, а не только заявленной цифры.

Вычислительные ресурсы. Сам JVB как SFU не перекодирует видео — он копирует и пересылает пакеты, поэтому нагрузка на CPU от него умеренная и растёт с числом одновременных потоков, а не квадратично. Транскодирование (перекодирование видео в другой битрейт или разрешение на лету) в классической Jitsi-связке не задействуется для обычного звонка — его требует запись через Jibri (там по сути браузер в headless-режиме захватывает картинку и кодирует её заново) или стриминг в RTMP. Если запись и трансляции вам не нужны на старте, можно обойтись без Jibri и сэкономить заметную часть ресурсов сервера — Jibri сам по себе рекомендуют выносить на отдельную машину именно из-за нагрузки на CPU при кодировании. Для звонков без записи 2–4 ядра и 4–8 ГБ RAM закрывают команды среднего размера; точную раскладку по числу участников и компонентам стоит свериться в материале сколько RAM нужно для Jitsi Meet.

Развёртывание: от установки до первого звонка

Официальный путь для Debian/Ubuntu — репозиторий Jitsi и мета-пакет, который сам подтягивает и настраивает связку Prosody (XMPP-сервер для сигналинга), Jicofo (координатор конференций) и JVB:

curl -sL https://download.jitsi.org/jitsi-key.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/jitsi-keyring.gpg
echo 'deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/' | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
sudo apt update
sudo apt install jitsi-meet

Установщик спросит доменное имя (заранее направьте A-запись на IP сервера) и способ получить TLS-сертификат — можно сразу выбрать автоматический Let's Encrypt, если 80/443 порты доступны снаружи. После установки конференция уже доступна по адресу вашего домена в браузере.

Кто предпочитает контейнеры — готовый docker-compose.yml с той же связкой компонентов (web, prosody, jicofo, jvb) избавляет от возни с системными пакетами и упрощает откат к предыдущей версии при обновлении:

git clone https://github.com/jitsi/docker-jitsi-meet
cd docker-jitsi-meet
cp env.example .env
# отредактировать .env: PUBLIC_URL, домен, включить/отключить компоненты
docker compose up -d

Оба пути равноценны по функциональности; готовый файл для запуска через Docker Compose с пояснением каждого сервиса разобран в статье Jitsi Meet в Docker Compose: готовый файл. Дальше остаётся создать первую комнату по ссылке https://ваш-домен/название-встречи, разослать её команде — и это уже рабочий сервер для созвонов.

NAT и firewall: как открыть WebRTC для внешних участников

WebRTC устанавливает не одно соединение, а по сути отдельный медиапоток на каждого участника, и именно тут чаще всего теряют полдня при первом запуске. Логика простая: браузер участника договаривается с JVB о доставке аудио/видео пакетов через UDP, и если между ними стоит NAT или файрвол, который не пропускает нужный диапазон, — участник видит чёрный экран или зависшую картинку при формально «успешном» подключении к комнате.

Что нужно открыть на сервере (типовая конфигурация Jitsi Meet):

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 4443/tcp
sudo ufw enable

Если сам сервер арендован как VPS с прямым публичным IP (типичный случай для облачного сервера), NAT на стороне сервера обычно не проблема — открыть нужно только файрвол. Но JVB всё равно нужно явно сказать, какой у него публичный адрес, иначе он попытается разослать участникам свой внутренний IP из докер-сети или локальной подсети провайдера, и соединение не установится. В jvb.conf (или sip-communicator.properties в классической установке без Docker) задаётся:

videobridge {
  ice {
    udp {
      port = 10000
    }
  }
}
org.jitsi.videobridge.SINGLE_PORT_HARVESTER_LOCAL_ADDRESS=<локальный_IP_сервера>
org.jitsi.videobridge.ADVERTISE_PRIVATE_CANDIDATES=false

и переменная DOCKER_HOST_ADDRESS / JVB_ADVERTISE_IPS в .env при Docker-развёртывании — туда прописывается именно публичный IP сервера. Отдельный случай — если сервер стоит не в облаке, а физически в офисе за роутером компании: тогда нужен полноценный проброс портов на роутере плюс либо STUN (для определения внешнего адреса), либо TURN-релей (coturn) как запасной путь для участников, чьи собственные сети NAT не дают установить прямое P2P-соединение даже после STUN — например, из-за симметричного NAT на их стороне. Механику того, почему устройства за NAT в принципе не видят друг друга напрямую и когда без релея не обойтись, подробно разбирает статья как работает NAT и почему устройства не видят друг друга — тот же принцип напрямую применим к WebRTC.

Типичные проблемы первого запуска и их решение

Видео замерзает или рассыпается на артефакты при 8+ участниках. Обычно это упирается в канал сервера, а не в CPU: проверьте исходящий трафик во время звонка (iftop или vnstat покажут реальную загрузку интерфейса) и сопоставьте с заявленной полосой тарифа. Если канал реально узкий, включите или проверьте настройку last-N (сколько потоков сервер реально пересылает каждому участнику) — по умолчанию она уже активна, но при кастомной сборке могло быть отключено. Второй частый источник — CPU достиг потолка на приёме/пересылке пакетов: тут помогает вынести Jibri (если он используется для записи) на отдельный сервер, чтобы он не делил ресурсы с JVB.

Участник не слышит и не видит остальных, хотя формально «в комнате». В девяти случаях из десяти это как раз незакрытый UDP 10000 или неверно указанный публичный IP в конфиге JVB (см. раздел выше). Диагностика быстрая: открыть chrome://webrtc-internals в браузере участника и посмотреть, устанавливается ли ICE-соединение вообще, или candidate остаётся в состоянии checking бесконечно.

Эхо и обрезанная речь в начале фразы. Как правило, проблема не на сервере, а в клиентском аудиопроцессинге браузера или гарнитуре — попробуйте отключить встроенное шумоподавление ОС, если оно конфликтует с WebRTC-обработкой, а не тюнить сервер.

Сертификат не обновляется, и через 90 дней все падают на ошибку HTTPS. Проверьте, что cron-задача Let's Encrypt (certbot renew) реально стоит и порт 80 остаётся открытым для валидации — частая причина сбоя обновления в том, что после первичной настройки 80-й порт закрыли файрволом «для безопасности».

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

Если проект вырос за рамки одного сервера, масштабирование делается добавлением второй ноды JVB и включением octo-режима (распределение конференции между несколькими мостами) — но для команды из нескольких десятков человек до этого обычно не доходит, разбор частых ошибок эксплуатации на одном сервере собран в статье Jitsi Meet на сервере: частые ошибки и решения.

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

Прямое сравнение цены зависит от размера команды, частоты созвонов и региона, поэтому здесь стоит сверять цифры со своими условиями, а не с усреднённым расчётом. Общая логика такая:

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

Частые вопросы