Развертывание видеоконференции на VPS: выбор сервера

Размещение систем видеоконференцсвязи на VPS упирается в пропускную способность сети

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

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

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

Начнем с mesh-топологии. Каждый браузер кодирует видео со своей камеры и отправляет копию напрямую каждому другому браузеру; медиа-сервер при этом не участвует в обработке видео. Для 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». Это скорость виртуальной сетевой карты, а не гарантия пропускной способности до следующего узла сети. Канал разделяется с другими арендаторами на том же физическом хосте, поэтому реальная пропускная способность в часы пиковой нагрузки будет ниже скорости порта, а конференц-связь — это именно постоянная нагрузка. Большинство тарифов также имеют ограничение на месячный объем трафика, после превышения которого скорость ограничивается или выставляется дополнительный счет.

Этот лимит — то самое место, где на счете появляются лишние цифры. Двадцать часов звонка на 30 человек в месяц передают 9.4 ТБ данных с сервера со скоростью 469.8 ГБ в час. Двадцать часов звонка на 50 человек передают 26.5 ТБ. Проверяйте лимит трафика до того, как смотреть на объем оперативной памяти, и если на странице тарифа об этом сказано расплывчато, эта расплывчатость и есть ваш ответ. Правильное чтение условий дешевого 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-запрос (challenge), поэтому если имя указывает на другой адрес, этот этап завершится ошибкой.

Затем откройте порты. Ниже приведены порты, указанные в руководстве; начните с 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 анонсирует адреса, которые обнаруживает на собственных сетевых интерфейсах. Если провайдер выдаёт виртуальной машине частный IP-адрес и транслирует на него публичный, 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 termination для других сервисов, перенесите BigBlueButton на отдельную машину или убедитесь, что вы понимаете, что делает ваша конфигурация обратного прокси nginx, прежде чем скрипт внесет в нее изменения.

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

Galène: компактное решение

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

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, установите актуальный toolchain с сайта 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-порту, поэтому reverse proxy обрабатывает только страницу и сигнализацию. Медиапотоки через него не проходят.

Документация 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 предлагайте одно или два качества. Пять вариантов загрузят процессор до предела, пока сеть будет простаивать.

Использование 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 — это отдельная задача, описанная в запуске homeserver Synapse на 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

В Debian и Ubuntu пакетная служба не запустится, пока вы не установите TURNSERVER_ENABLED=1 в файле /etc/default/coturn. Установленный, но не активированный coturn снаружи выглядит так же, как полное отсутствие TURN, поэтому эта единственная строка стоит людям целых вечеров отладки.

Теперь о скрытых издержках. Ретранслятор передает весь медиапоток каждого участника в обоих направлениях. Когда 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 runtime требуют значительного объёма памяти; в официальном руководстве для серьёзного развёртывания рекомендуется 8 ГБ, и ограничения по полосе пропускания станут критическими раньше, чем нехватка памяти. Если в вашем распоряжении только сервер с 1 ГБ ОЗУ, для этих целей лучше выбрать Galène, а не Jitsi.

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

Да. Проблема, которую решает TURN, находится на стороне участника. Пользователь в корпоративной сети, блокирующей исходящий UDP, или за 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. Обе группы цифр взяты из документации соответствующих проектов и являются отправными точками, а не результатами замеров вашей нагрузки.