Хостинг видеоконференций на VPS: выбор сервера и расчеты

Самостоятельный хостинг видеоконференций на VPS упирается в пропускную способность канала

Самостоятельно развернутые системы видеоконференций на небольших серверах не работают по одной причине, и дело почти никогда не в процессе установки. Каждый современный инструмент использует серверный компонент SFU (selective forwarding unit). Он принимает один видеопоток от каждого участника и пересылает его копию всем остальным, поэтому исходящий трафик сервера растет пропорционально квадрату количества участников. VPS с 1 ГБ или 2 ГБ оперативной памяти и общим каналом связи успешно запустит программное обеспечение. Однако он не потянет общую конференцию, которую вы планируете.

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

Почему пропускная способность растет пропорционально квадрату числа участников?

Начнем с mesh-топологии. Каждый браузер кодирует видео со своей камеры и отправляет копию напрямую каждому другому браузеру; медиасервер при этом не участвует в обработке видео. Для звонка между двумя участниками нужен только сервер сигнализации, поэтому хостинг звонков один на один практически бесплатен. Mesh перестает работать при участии четырех или пяти человек, так как ноутбук с домашним интернет-соединением вынужден одновременно загружать четыре или пять отдельных копий собственного видео.

SFU работает иначе. Каждый браузер загружает одну копию на сервер. Сервер считывает заголовки RTP (real-time transport protocol) и пересылает эти пакеты другим участникам без декодирования видео. В этом заключается основной принцип: SFU потребляет мало ресурсов CPU, но требует высокой пропускной способности сети.

Более старый подход — MCU (multipoint control unit). Он декодирует каждый входящий поток, объединяет их в одну картинку и перекодирует её заново. Исходящий трафик при этом минимален, но нагрузка на CPU огромна. Сейчас MCU почти не используется для видео, и в данном руководстве он не применяется.

Теперь перейдем к расчетам для SFU. Допустим, каждый участник отправляет видео с битрейтом 1.2 Mbps, и никто не выключает камеру. Сервер получает N умножить на 1.2 Mbps — это линейная и безопасная нагрузка. Сервер отправляет N умножить на (N минус 1) умножить на 1.2 Mbps, так как каждый из N участников должен получить остальные N минус 1 потоков. Именно эта вторая цифра становится критической для проектов.

[
  {
    "label": "4 people",
    "sfu_egress_mbps": 14.4,
    "egress_gb_per_hour": 6.5,
    "monthly_volume_tb": 0.13
  },
  {
    "label": "8 people",
    "sfu_egress_mbps": 67.2,
    "egress_gb_per_hour": 30.2,
    "monthly_volume_tb": 0.6
  },
  {
    "label": "15 people",
    "sfu_egress_mbps": 252,
    "egress_gb_per_hour": 113.4,
    "monthly_volume_tb": 2.3
  },
  {
    "label": "30 people",
    "sfu_egress_mbps": "1,044",
    "egress_gb_per_hour": 469.8,
    "monthly_volume_tb": 9.4
  },
  {
    "label": "50 people",
    "sfu_egress_mbps": "2,940",
    "egress_gb_per_hour": "1,323",
    "monthly_volume_tb": 26.5
  }
]

Эти строки — арифметический расчет, а не замеры конкретного сервера. В столбце с ежемесячными данными предполагается двадцать часов звонков в месяц. Сначала посмотрите на последнюю строку. Пятьдесят человек с включенными камерами требуют 2,940 Mbps постоянного исходящего трафика с одной машины. Тридцать человек требуют 1,044 Mbps. Четыре человека требуют 14.4 Mbps, с чем справится любой VPS. Между строкой для четырех человек и строкой для тридцати количество участников увеличивается в семь с половиной раз, в то время как исходящий трафик растет более чем в семьдесят раз.

В реальных внедрениях показатели ниже, и важно понимать почему. Jitsi и LiveKit используют simulcast: отправитель публикует несколько слоев качества одновременно, а SFU пересылает низкий слой тем, кто не находится в фокусе. В Jitsi также есть настройка last-N, которая пересылает видео только от последних активных спикеров. Оба метода значительно экономят трафик. Однако они не меняют характер кривой роста и перестают помогать в тот момент, когда все участники включают камеры и закрепляют изображения друг друга на экранах.

Что на самом деле дает аплинк VPS?

На странице тарифа указано «порт 1 Gbps». Это скорость виртуальной сетевой карты, а не гарантия пропускной способности до следующего узла сети. Канал разделяется с другими арендаторами на том же физическом хосте, поэтому стабильная пропускная способность в часы пиковой нагрузки будет ниже скорости порта, а конференц-звонок — это именно стабильная нагрузка. Большинство тарифов также имеют ограничение на ежемесячный объем трафика, после превышения которого скорость ограничивается или выставляется дополнительный счет.

Именно этот объем трафика влияет на итоговую сумму в счете. Двадцать часов звонка на тридцать человек в месяц передают 9.4 ТБ данных с сервера со скоростью 469.8 ГБ в час. Двадцать часов звонка на пятьдесят человек передают 26.5 ТБ. Проверяйте лимит трафика до того, как смотреть на объем RAM, и если на странице тарифа об этом сказано расплывчато, эта расплывчатость и есть ваш ответ. Правильное чтение условий дешевых VPS для такой нагрузки важнее, чем почти для любой другой задачи.

Jitsi Meet: стандартный выбор и требования

Jitsi Meet — это решение, с которого стоит начать большинству пользователей. Оно устанавливается из собственного репозитория Debian, автоматически настраивает nginx и сертификат в процессе установки, а videobridge (JVB) использует всего один UDP-порт, что упрощает правила межсетевого экрана. Требуется Debian 11 или новее, либо Ubuntu 22.04 или новее.

sudo apt update
sudo apt install -y apt-transport-https curl gnupg
sudo add-apt-repository universe
sudo apt update
sudo curl -sL https://prosody.im/files/prosody-debian-packages.key -o /usr/share/keyrings/prosody-debian-packages.key
echo "deb [signed-by=/usr/share/keyrings/prosody-debian-packages.key] http://packages.prosody.im/debian $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/prosody-debian-packages.list
sudo apt install -y lua5.2
curl -sL https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /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 -y jitsi-meet

Установщик запрашивает имя хоста, а затем предлагает выбрать вариант сертификата. Выберите Let's Encrypt и укажите доменное имя, которое уже указывает на публичный IP-адрес этого сервера. Сертификат выдается через HTTP-запрос, поэтому если имя указывает на другой адрес, этот этап завершится ошибкой.

Затем откройте порты. Ниже приведены порты, указанные в руководстве; начните с SSH, чтобы ufw enable не заблокировал вам доступ:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable

TCP 80 и 443 используются для веб-приложения и обновления сертификатов. UDP 10000 передает весь аудио- и видеопоток, и именно этот порт часто забывают открыть. UDP 3478 и TCP 5349 относятся к серверу coturn, который пакет Jitsi устанавливает вместе с мостом; это резервный путь для пользователей, чьи сети блокируют UDP.

sudo systemctl status jitsi-videobridge2
sudo ss -ulnp | grep 10000

Первая команда должна показать, что сервис активен. Вторая должна подтвердить, что мост ожидает соединений на UDP 10000. Если вывод пуст, значит, мост не запустился, и /var/log/jitsi/jvb.log покажет причину.

Что касается ресурсов, руководство Jitsi предлагает свои рекомендации, а BigBlueButton — значительно более высокие требования:

[
  {
    "label": "Jitsi Meet",
    "ram_gb": 8,
    "cpu_cores": 4,
    "uplink_mbps": "1,000"
  },
  {
    "label": "BigBlueButton 3.0",
    "ram_gb": 16,
    "cpu_cores": 8,
    "uplink_mbps": 250
  }
]

В руководстве Jitsi для серьезного сервера рекомендуется 8 ГБ оперативной памяти и 4 выделенных ядер, при этом пропускной способности сети в 1,000 Мбит/с часто бывает достаточно. Также отмечается, что небольшие инсталляции работают на 4 ГБ или 2 ГБ ОЗУ. Важная деталь из документации: Prosody, XMPP-сервер, отвечающий за сигнализацию, может использовать только одно ядро. Дополнительные ядра помогают работе моста, но не влияют на производительность сигнализации.

Почему все подключаются к звонку, но никто не видит видео?

Это типичная проблема Jitsi при работе на VPS. Список участников заполняется, чат работает, но все окна видео остаются чёрными. Videobridge анонсирует адреса, которые находит на своих сетевых интерфейсах. Если провайдер выдаёт виртуальной машине частный адрес и транслирует на него публичный, JVB находит только частный адрес. В результате каждый клиент пытается отправить медиапоток на адрес вроде 10.0.0.5, и пакеты теряются.

Укажите мосту оба адреса. Добавьте статическое сопоставление в /etc/jitsi/videobridge/jvb.conf:

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "10.0.0.5"
          public-address = "203.0.113.10"
        }
      ]
    }
  }
}

Перезапустите службу командой sudo systemctl restart jitsi-videobridge2. Используйте локальный адрес из ip -4 addr show и публичный адрес из панели управления вашего провайдера. В старых руководствах эти же параметры задавались в /etc/jitsi/videobridge/sip-communicator.properties с помощью ключей org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS и org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS. Они по-прежнему работают, но в новых установках следует использовать блок сопоставления, приведённый выше.

Другая причина — не настроенный вами межсетевой экран. Большинство провайдеров используют сетевой экран в панели управления, который работает независимо от ufw на самой машине, поэтому порт UDP 10000 должен быть открыт в обоих местах. Чтобы выяснить, на каком уровне отбрасываются пакеты, запустите sudo tcpdump -ni any udp port 10000 на сервере в момент, когда кто-то подключается извне. Отсутствие пакетов означает, что до машины ничего не доходит, значит, блокировка происходит выше уровня операционной системы. Если пакеты приходят, а окна остаются чёрными, значит, мост отвечает адресом, недоступным для клиента — проблема в сопоставлении. Если вы не уверены в настройках самого ufw, правила ufw, действительно необходимые для VPS описывают порядок правил, на котором часто ошибаются пользователи.

BigBlueButton: тяжелое, бескомпромиссное решение, требующее выделенного сервера

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

По состоянию на август 2026 года поддерживаемым вариантом является BigBlueButton 3.0 на Ubuntu 22.04, который выбирается с помощью флага версии jammy-300. Заявленные требования проекта для продакшена: 16 ГБ оперативной памяти с включенным swap, 8 ядер CPU с высокой производительностью на одно ядро, 250 Мбит/с симметричной полосы пропускания и 500 ГБ дискового пространства при хранении записей (50 ГБ, если их отключить). Используемые порты: TCP 80 и 443, а также диапазон UDP от 16384 до 32768.

wget -q https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh
less bbb-install.sh
bash bbb-install.sh -w -v jammy-300 -s bbb.example.com -e info@example.com -g

Примеры из документации проекта предлагают передавать скрипт установки напрямую в bash. Сначала скачайте и изучите его, так как он перезаписывает конфигурацию Nginx, устанавливает собственный стек для обработки медиа и аудио, фиксирует версии пакетов и захватывает имя хоста. Это не недостаток, а особенность архитектуры: BigBlueButton рассчитывает на полный контроль над машиной. Флаг -w настраивает межсетевой экран, -s задает имя хоста, -e — адрес для регистрации в Let's Encrypt, а -g добавляет фронтенд Greenlight. Если на этом же сервере настроено TLS-терминирование для других сервисов, перенесите BigBlueButton на другой узел или убедитесь, что вы понимаете как работает ваша конфигурация обратного прокси Nginx, прежде чем скрипт внесет в нее изменения.

Внимательно сравните две строки в этой таблице. BigBlueButton требует в два раза больше оперативной памяти и ядер CPU, чем Jitsi, при этом потребляя в четыре раза меньше полосы пропускания. Эти показатели измерены по разным методикам и рассчитаны на разный размер комнат, поэтому рассматривайте их как отправные точки для каждого проекта, а не как прямое сравнение. Разрыв в требованиях к CPU реален, так как он обусловлен всем тем функционалом, который BigBlueButton выполняет помимо простой передачи видео.

Galène: компактный вариант

Galène — это компактный SFU, написанный на Go. Он собирается в единый статический бинарный файл, поставляется с собственным веб-клиентом и включает в себя TURN-сервер. Вам не нужно поддерживать работу XMPP-сервера, среды выполнения Java или приложений на Rails. Если вам требуется надежная связь для десяти человек на скромном оборудовании, попробуйте это решение, прежде чем делать вывод о необходимости более мощного сервера.

sudo apt update && sudo apt install -y git golang-go
git clone https://github.com/jech/galene
cd galene
CGO_ENABLED=0 go build -ldflags='-s -w'
mkdir groups

Пакет golang-go в Ubuntu 24.04 содержит Go 1.22. Если go build сообщает, что модулю требуется более новая версия Go, установите актуальный инструментарий с сайта go.dev, вместо того чтобы пытаться адаптировать пакет из дистрибутива.

Группа (group) в терминологии Galène — это комната, а сама группа представляет собой JSON-файл:

echo '{"users": {"vimes": {"password":"sybil", "permissions":"op"}}}' > groups/night-watch.json
./galene &

Откройте https://your.server:8443/group/night-watch/ и войдите под учетной записью vimes. Эти учетные данные взяты непосредственно из README проекта, поэтому измените их, прежде чем порт станет доступен извне. Для реального развертывания в документации проекта приводится systemd-юнит:

[Unit]
Description=Galene
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/galene
User=galene
Group=galene
ExecStart=/home/galene/galene
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Используются следующие порты: TCP 8443 для веб-интерфейса, TCP и UDP 1194 для встроенного TURN-сервера, а также диапазон высоких UDP-портов для медиаданных. Зафиксируйте этот диапазон, чтобы создать для него одно правило межсетевого экрана:

./galene -udp-range 40000-40100

Опция -turn является наиболее важной при работе на VPS. -turn ':1194' прослушивает все публичные IPv4-адреса. -turn '203.0.113.1:1194' указывает Galène адрес, который будут видеть клиенты; это необходимо, если собственный адрес машины является приватным. -turn '' отключает встроенный сервер, что позволяет указать внешний сервер через data/ice-servers.json. Значение по умолчанию — auto, которое ведет себя как :1194, если файл ice-servers.json отсутствует.

Вы можете разместить nginx перед веб-интерфейсом, установив proxyURL в data/config.json и настроив проксирование локации /ws с заголовками обновления WebSocket. Учитывайте границы этого решения: клиенты по-прежнему открывают прямые UDP-потоки и прямые TCP-соединения к TURN-порту, поэтому обратный прокси обрабатывает только страницу и сигнализацию. Медиаданные через него не проходят.

Документация Galène утверждает, что приложению требуются весьма умеренные серверные ресурсы, но конкретных цифр не приводит, поэтому не стоит их ожидать. Приведенные выше расчеты пропускной способности остаются полностью актуальными. Вы экономите память и избавляетесь от лишних компонентов, не относящихся к SFU.

Owncast: вещание «один ко многим» с линейным потреблением полосы пропускания

Многие задачи, которые ошибочно относят к «видеоконференциям», на самом деле представляют собой выступление одного докладчика перед аудиторией, которая общается в чате. Если ваш случай именно такой, то SFU — неподходящий инструмент, так как экономика решения меняется кардинально. Owncast принимает RTMP-поток из OBS или аналогичного энкодера и раздает его по протоколу HLS через обычный HTTPS. Потребление полосы пропускания на одного зрителя здесь линейно, а не квадратично. Поскольку на выходе получаются обычные HTTP-сегменты, вы можете разместить их за объектным хранилищем или CDN и перестать платить за трафик с исходного сервера.

curl -sL https://owncast.online/install.sh -o install-owncast.sh
less install-owncast.sh
bash install-owncast.sh

Документация проекта рекомендует не запускать его от имени root и проверять любые удаленные скрипты перед выполнением, поэтому загрузка выделена в отдельный шаг выше. Установщик скачивает актуальный релиз и бинарный файл ffmpeg, если он еще не установлен в системе. Запустите ./owncast из каталога установки и откройте панель администратора по адресу /admin на порту 8080. Учетные данные по умолчанию: пользователь admin, пароль — ключ потока abc123. Измените их, прежде чем направлять домен на сервер.

Из архитектуры HLS следуют два вывода. Зрители видят трансляцию с задержкой в несколько секунд или минут, так как HLS передает поток целыми сегментами, поэтому интерактивный диалог невозможен. В пути передачи данных отсутствуют UDP и TURN, поэтому трансляция работает в сетях, где WebRTC-соединение установить невозможно.

Owncast — единственный инструмент в этом списке, который выполняет транскодирование намеренно. Каждое включенное вами качество — это отдельный процесс кодирования входящего потока через ffmpeg, работающий на протяжении всей трансляции. На небольшом VPS предлагайте одно или два качества. Пять вариантов загрузят CPU до предела, пока сеть будет простаивать.

Запуск Element Call на собственном сервере Matrix

Если вы уже используете Matrix, видеосвязь станет дополнением к существующей инфраструктуре, а не вторым продуктом для обслуживания. Тем не менее, это потребует настройки нескольких компонентов. Для работы Element Call за вашим homeserver необходимы два элемента. Первый — это LiveKit SFU, который отвечает за пересылку медиапотоков. Второй — служба авторизации MatrixRTC, element-hq/lk-jwt-service, которая предоставляет клиенту WebSocket URL для LiveKit и подписанный JWT (JSON web token) для подключения. Эта служба использует API федерации Matrix, поэтому перед ней необходимо настроить TLS reverse proxy и доменное имя, доступное для федерации.

Документированные порты LiveKit:

• TCP 7880 для API и клиентского WebSocket, за прокси с TLS termination
• TCP 7881 для ICE поверх TCP, используется, если клиент не может передавать данные через UDP
• UDP 50000–60000 для медиапотоков, где каждый участник конференции занимает два порта
• UDP 3478 и TCP 5349, если вы активируете встроенный TURN-сервер; порт 5349 необходимо перенаправить на 443, если перед ним не установлен балансировщик нагрузки

Два порта на участника звучат пугающе, но это не так. Диапазон из 10000 портов покрывает тысячи участников, а пропускная способность вашего канала связи закончится гораздо раньше, чем порты в этом диапазоне. Откройте весь диапазон целиком: частичное открытие портов приводит к тому, что у одних пользователей связь работает, а у других нет, что является худшим типом неисправности для отладки. Настройка стороны homeserver — это отдельная задача, описанная в запуске Synapse homeserver на VPS.

Почему один пользователь не может подключиться? TURN и сети, блокирующие UDP

Для начала определимся с терминологией. ICE (interactive connectivity establishment) — это процесс, который используют два WebRTC-клиента для поиска рабочего пути соединения. STUN (session traversal utilities for NAT) — это небольшая служба, сообщающая клиенту его публичный IP-адрес, видимый извне. TURN (traversal using relays around NAT) — это ретранслятор: если прямой путь отсутствует, обе стороны отправляют медиаданные на TURN-сервер, который пересылает их дальше.

TURN необходим для участников, чьи сети недоступны для прямого соединения. Один из них может находиться в корпоративной или университетской сети, где исходящий UDP заблокирован полностью. Другой может быть за NAT провайдера (carrier-grade NAT), который назначает разные порты источника для каждого направления (симметричный NAT), из-за чего адрес, полученный через STUN, становится бесполезным.

Симптомы проблемы специфичны. Большинство пользователей подключаются без ошибок. Один участник видит список присутствующих и чат, но вместо видео наблюдает черный экран и индикатор загрузки. Его браузер собрал кандидатов, но ни одна пара не сработала, и процесс ICE завершился с ошибкой. В Chrome консоль chrome://webrtc-internals, открытая во время попытки подключения, покажет список пар кандидатов и причину сбоя. Попросите этого пользователя повторить попытку через мобильный интернет. Если там всё работает, значит, причина в его сети, и TURN решит проблему.

TURN поверх TCP на портах 443 или 5349 — это резервный вариант, который работает почти везде, так как сеть, блокирующая TLS на 443 порту, фактически блокирует доступ ко всему вебу. Пакет Jitsi устанавливает и настраивает coturn автоматически, поэтому в документации к нему указаны правила для UDP 3478 и TCP 5349. В Galène сервер TURN встроен и работает на порту 1194. В LiveKit есть встроенный TURN-сервер, который включается в конфигурации. Если вы запускаете coturn самостоятельно:

sudo apt install -y coturn
sudo systemctl enable --now coturn

listening-port=3478
tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_STRING
realm=turn.example.com
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
min-port=49152
max-port=65535
no-multicast-peers

Эти настройки вносятся в /etc/turnserver.conf. В Debian и Ubuntu пакет запускает coturn сразу после установки с настройками по умолчанию, поэтому команда enable --now выше обнаружит уже запущенный процесс и ничего не изменит. Ваши настройки вступят в силу после выполнения sudo systemctl restart coturn; каждое последующее изменение файла требует такой же перезагрузки. В старых руководствах также рекомендуется установить TURNSERVER_ENABLED=1 в файле /etc/default/coturn. Этот параметр считывается только старым скриптом инициализации. Современный systemd-юнит, используемый в актуальных пакетах, его игнорирует, поэтому эта строка ни на что не влияет, а coturn, который вы не перезапустили, продолжает использовать старую конфигурацию.

Теперь о скрытых расходах. Ретранслятор передает весь медиапоток каждого участника в обоих направлениях. Когда coturn работает на одном сервере с SFU, большая часть трафика проходит через loopback, нагружая CPU, а не канал связи, при этом TLS-слушатель шифрует каждый пакет повторно поверх уже имеющегося DTLS-шифрования медиаданных. Если вы выносите TURN на отдельную машину, для неё потребуется такой же расчет пропускной способности канала, как и для SFU. Кроме того, TURN поверх TCP превращает медиапоток реального времени в надежный поток данных: потерянный пакет будет передан повторно, а не пропущен, поэтому у участника с нестабильным соединением будет накапливаться задержка вместо кратковременных помех. Ретрансляция — это резервный способ подключения, качество которого всегда будет ниже, чем при прямом соединении.

Когда SFU выполняет транскодирование и сколько это стоит?

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

Первая функция — запись. Jitsi выполняет запись с помощью Jibri, и в документации к Jibri точно описано, как это работает: запускается экземпляр Chrome, который отрисовывается в виртуальном фреймбуфере, а затем захватывается и кодируется с помощью ffmpeg. Это полноценный браузер, который отрисовывает всю вашу встречу, плюс видеокодировщик, работающий непрерывно на протяжении всего вызова. В той же документации указано, что на одном Jibri поддерживается только одна запись одновременно, и что Jibri предназначен для работы на отдельном физическом или виртуальном сервере, где никакие другие приложения не используют устройства отображения или аудио. Запись — это отдельный сервер, а не просто настройка.

Вторая функция — телефонный дозвон. Объединение телефонной линии с конференцией означает преобразование Opus с частотой 48 кГц в формат, принимаемый телефонной сетью (обычно G.711 с частотой 8 кГц), в обоих направлениях и непрерывно в течение всего вызова. Транскодирование аудио обходится значительно дешевле, чем транскодирование видео, но оно выполняется для каждого участника и никогда не прерывается, поэтому затраты ресурсов растут пропорционально количеству звонящих. Если вам нужен номер для дозвона, собственный VoIP-сервер — это тот компонент, который выполняет данную работу, и по тем же причинам, что и Jibri, его следует размещать на отдельном сервере.

Какой мощности сервер вам действительно нужен?

Для двух человек почти никакой. Jitsi по умолчанию включает peer-to-peer режим, когда в конференции ровно два участника. В этом режиме конференция перестает передавать данные через videobridge и использует прямое соединение. При подключении третьего человека система переключается обратно на мост. Поэтому VPS с 1 GB оперативной памяти отлично подходит для звонков один на один, но плохо справляется с четырьмя участниками. Именно поэтому так часто можно услышать: «все работало, когда я тестировал».

Для группы до десяти человек с включенными камерами 67.2 Mbps при восьми участниках укладываются в возможности исходящего канала обычного VPS. Два виртуальных CPU и 4 GB RAM обеспечат работу Jitsi или Galène при такой нагрузке, если вы не ведете запись. Следите за счетчиком трафика, а не за графиком загрузки CPU.

Для тридцати человек худший сценарий — это 1,044 Mbps постоянной нагрузки, что за двадцать часов составит 9.4 TB. На этом этапе стоимость трафика становится важнее стоимости самого сервера. Включите last-N, чтобы мост транслировал только последних выступавших, сделайте выключенные камеры настройкой по умолчанию для участников и разместите SFU там, где лимит трафика позволяет покрыть такие объемы.

При большем количестве участников один VPS — неверное решение. Либо мероприятие по сути является трансляцией (в этом случае Owncast вместе с CDN обойдется значительно дешевле), либо вам требуется несколько videobridge за единым уровнем сигнализации, что является задачей другого уровня сложности.

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

FAQ

Почему участники могут подключиться к конференции Jitsi, но не видят и не слышат друг друга?

Чат и список участников передаются по сигнальному каналу, который использует TCP 443, в то время как аудио и видео используют UDP 10000 для связи с videobridge. Если список участников заполняется, а все окна остаются черными, значит, путь передачи медиаданных нарушен, хотя сигнальный путь работает исправно. Проверьте порт UDP 10000 в обоих файрволах: на самом сервере и во внешнем сетевом файрволе в панели управления вашего провайдера. Затем убедитесь, что bridge знает свой публичный адрес: на виртуальной машине с частным адресом и привязанным публичным, добавьте статическое сопоставление в ice4j.harvest.mapping в файле /etc/jitsi/videobridge/jvb.conf и перезапустите jitsi-videobridge2. Запуск sudo tcpdump -ni any udp port 10000 во время подключения пользователя поможет определить причину: если пакеты вообще не поступают, значит, блокировка происходит до уровня операционной системы.

Какую пропускную способность потребляет видеозвонок на 30 человек?

В худшем случае, когда у всех включена камера, а SFU пересылает поток полного качества каждому участнику, сервер покидает примерно 1,044 Мбит/с, что составляет 469.8 ГБ в час. Это арифметический расчет для N умножить на (N минус 1) потоков по 1,2 Мбит/с каждый, а не замер вашей конкретной конфигурации. Технологии simulcast и настройка last-N значительно снижают нагрузку при обычном использовании, так как большинство участников не отображаются на экране в каждый конкретный момент времени. Тем не менее, планируйте ресурсы исходя из значений, близких к худшему сценарию, так как именно на общих собраниях все участники включают камеры одновременно.

Можно ли запустить Jitsi Meet на VPS с 1 ГБ ОЗУ?

Установка пройдет успешно, и звонок между двумя участниками будет работать, отчасти потому, что Jitsi использует режим peer-to-peer для двух человек и полностью обходит videobridge. Однако такой сервер не пригоден для групповых звонков. Prosody, videobridge и среда выполнения Java требуют значительного объема памяти; в официальном руководстве для серьезного развертывания рекомендуется 8 ГБ, и ограничения по пропускной способности проявятся раньше, чем нехватка памяти. Если в вашем распоряжении только сервер с 1 ГБ ОЗУ, для этой задачи лучше подойдет Galène, чем Jitsi.

Нужен ли TURN-сервер, если у моего VPS есть публичный IP-адрес?

Да. Проблема, которую решает TURN, находится на другом конце соединения. Участник, находящийся в корпоративной сети, блокирующей исходящий UDP, или за NAT провайдера (carrier-grade NAT), который назначает разные порты источника для разных направлений, не сможет установить прямой медиа-путь, независимо от того, насколько публичен адрес вашего сервера. TURN поверх TCP на портах 443 или 5349 предоставляет им ретранслятор, который выглядит для их файрвола как обычный веб-трафик. Пакетная установка Jitsi по умолчанию настраивает coturn для этих целей, поэтому в документации к файрволу указано открытие портов UDP 3478 и TCP 5349.

Почему для BigBlueButton требуется значительно больше аппаратных ресурсов, чем для Jitsi Meet?

Потому что он выполняет гораздо больше функций, чем просто пересылка видео. Опубликованные требования для промышленной эксплуатации составляют 16 ГБ ОЗУ и 8 ядер, против 8 ГБ и 4 ядер в руководстве Jitsi. BigBlueButton запускает полноценный стек аудиоконференций, общую доску и уровень презентаций, конвейер записи и постобработки, а также веб-интерфейс с учетными записями пользователей — и всё это на одной машине. Проект также предъявляет строгие требования к платформе: по состоянию на август 2026 года поддерживаемой версией является 3.0 на Ubuntu 22.04. Оба набора цифр взяты из документации соответствующих проектов и являются отправными точками, а не результатами замеров вашей нагрузки.