Nextcloud Talk вместо Zoom работает до определённого числа участников

MAATRIX

Zoom стоит денег за каждое место и держит записи звонков на чужих серверах — а у команды, которая уже поставила себе Nextcloud под файлы и календарь, встроенный Talk выглядит очевидной экономией: зачем платить за отдельный сервис, если видеозвонки уже есть в том же интерфейсе. Для регулярных созвонов на 4-6 человек это действительно работает без нареканий. Но стоит собрать планёрку на 15 человек с включёнными камерами — и звонок начинает рассыпаться, причём не потому, что сервер слабый, а потому, что у этой стены есть чёткая техническая природа. Разберём, где она проходит, почему именно там и что с этим можно сделать без миграции на Zoom обратно.

Что такое Nextcloud Talk и как он связан с остальным Nextcloud

Talk — не отдельный продукт, а приложение внутри Nextcloud, которое ставится через раздел «Приложения» в админке (или заранее включено в некоторых сборках). Технически это WebRTC-клиент на JavaScript, который живёт в том же веб-интерфейсе, что Files, Calendar и Deck, и это даёт реальные, а не маркетинговые преимущества интеграции:

• Разговор привязан к контексту. Открыли файл в Nextcloud — рядом кнопка «Позвонить» тому, с кем вместе редактируете документ. Не нужно искать ссылку в почте или отдельном мессенджере.
• Встречи из календаря создают комнату Talk автоматически. При создании события в Calendar можно сразу прикрепить видеозвонок — участники получают ссылку в приглашении, без ручного копирования из Zoom в письмо.
• Файлы внутри чата — это файлы Nextcloud, а не вложения. Кинули документ в чат Talk — он лежит в вашем хранилище с той же системой прав доступа, что и остальные файлы, а не улетает на сторонний сервер обмена файлами конференции.
• Гостевой доступ без регистрации. Внешнему участнику не нужен аккаунт — вы создаёте публичную ссылку на комнату, он переходит и присоединяется как гость. По удобству для одноразовых внешних встреч это ближе к Zoom, чем к системам, требующим завести аккаунт каждому.

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

Как технически устроен звонок: от P2P до mesh

Разговор один на один в Talk идёт по прямому WebRTC-соединению между двумя браузерами — классический peer-to-peer, сервер участвует только в установлении соединения (сигналинг: кто кому звонит, обмен параметрами сессии), сам медиапоток не проходит через сервер Nextcloud вообще. Это дёшево для сервера и быстро для пользователей.

Как только в комнате появляется третий участник, схема меняется. Без дополнительных компонентов (о них ниже) Talk использует внутренний сигнальный сервер — простую реализацию на PHP прямо в самом Nextcloud, которая координирует, кто кому должен передавать поток. Но координация — это ещё не пересылка. Внутренний сигнальный сервер не является SFU (Selective Forwarding Unit), то есть не ретранслирует видео через себя. Медиапотоки в групповом звонке по умолчанию идут mesh — каждый участник устанавливает прямое WebRTC-соединение с каждым другим участником и отправляет свой поток напрямую всем.

Это принципиальная разница с Zoom, Jitsi (через JVB) или BigBlueButton, где есть выделенный сервер, который принимает один поток от каждого участника и раздаёт копии остальным. При mesh-схеме нагрузка растёт не линейно, а квадратично по числу участников:

Звонок из N человек с видео (mesh, без SFU):
- каждый участник отправляет N-1 исходящих видеопотоков
- каждый участник принимает N-1 входящих видеопотоков
- итого в сети одновременно N × (N-1) потоков

При 4 участниках это 12 потоков — устройства и каналы обычно справляются. При 10 участниках — уже 90 потоков, и здесь начинает страдать не сервер (он вообще не в цепочке передачи медиа), а клиентские устройства и их исходящий канал: ноутбуку нужно одновременно кодировать и отправлять свой видеопоток девяти разным адресатам, и это ощутимая нагрузка на CPU и на аплинк домашнего интернета, который у большинства асимметричный (исходящая скорость заметно меньше входящей).

Реальный потолок без дополнительного медиасервера

Здесь важно не путать два разных предела: сколько человек могут находиться в комнате Talk (это ограничение почти отсутствует — можно пригласить десятки) и сколько из них могут одновременно говорить и показывать видео без деградации качества у всех участников. Именно второй показатель и упирается в mesh-архитектуру.

Официальная документация Nextcloud прямо и без обиняков говорит, что внутренний сигнальный сервер (тот, что работает «из коробки», без дополнительной установки) предназначен для звонков с небольшим числом участников, и рекомендует переходить на выделенный медиасервер, если регулярно собираются группы больше нескольких человек. Точная цифра, при которой у конкретной команды всё начнёт тормозить, зависит от:

• числа участников с включённой камерой одновременно (аудио-only участники почти не влияют — голосовой поток на порядки легче видео);
• разрешения, которое клиенты пытаются передавать (звонок в 720p ощутимо тяжелее, чем в 360p);
• качества исходящего канала у самого слабого участника — именно он обычно и «роняет» восприятие звонка для всех остальных, потому что видео от него будет прыгать или замерзать;
• мощности процессора на клиентских устройствах — кодирование нескольких одновременных потоков в реальном времени грузит CPU заметно сильнее, чем воспроизведение.

Практический ориентир, который стоит держать в голове (это не измеренный бенчмарк, а инженерная оценка по архитектуре и опыту эксплуатации подобных mesh-схем): для звонков с включённым видео у всех участников комфортная зона — это до 4-6 человек. С 7-8 участниками звонок обычно ещё технически «работает», но у части людей начинает подтормаживать видео или садится CPU ноутбука в вентилятор. За пределами 8-10 участников с видео без выделенного медиасервера смысла проверять почти нет — деградация станет заметна почти наверняка. У вас цифры могут отличаться в обе стороны в зависимости от железа участников и качества их интернета — это не гарантия, а стартовая точка для собственных наблюдений.

Важный нюанс: этот потолок — про видео. Голосовые конференции того же состава mesh переносит куда легче, потому что аудиопоток на порядки легче видеопотока по битрейту. Планёрка на 10 человек с выключенными камерами и включённым звуком у Talk без HPB отработает заметно спокойнее, чем та же планёрка с видео у всех.

High Performance Backend: что он добавляет

Ответ Nextcloud на mesh-ограничение — High Performance Backend (HPB), набор из нескольких дополнительных сервисов, которые ставятся отдельно от основного Nextcloud:

• nextcloud-spreed-signaling — выделенный сигнальный сервер на Go (в отличие от встроенного PHP-варианта), который умеет держать намного больше одновременных WebSocket-соединений и, в актуальных версиях, сам работает как медиа-релей (SFU) для звонков — то есть видео от каждого участника идёт один раз на сервер, а сервер уже раздаёт копии остальным. Это убирает квадратичный рост нагрузки на клиентов: каждый участник теперь отправляет один исходящий поток вместо N-1.
• coturn — TURN/STUN-сервер для прохождения NAT и файрволов. Это не опция «для масштаба», а базовая инфраструктура, нужная даже для звонков 1:1, если хотя бы один участник сидит за симметричным NAT или строгим корпоративным файрволом — без TURN такие звонки просто не устанавливаются, вне зависимости от числа людей в комнате.
• Recording backend (опционально) — отдельный сервис для записи звонков, устроен похоже на Jibri у Jitsi: headless-браузер, который «смотрит» звонок и пишет видео на диск. Если запись не нужна, можно не разворачивать.

С HPB схема меняется принципиально: клиент отправляет один поток на сервер signaling/SFU, сервер — уже сам, силами своего процессора и канала, — раздаёт этот поток нужным получателям (при необходимости в разных разрешениях, если включён simulcast). Это ровно та же логика, что у JVB в Jitsi или у медиасервера в BigBlueButton: сложность и нагрузка переносятся с клиентов на сервер, которым вы управляете и который можно отдельно масштабировать.

Ценой становится дополнительная эксплуатация: ещё один сервис, за которым нужно следить, ещё один процесс, потребляющий CPU и память пропорционально числу активных потоков (похожая логика разбиралась в статье про сколько RAM нужно Jitsi Meet — там тот же принцип: SFU-компонент становится главным потребителем ресурсов при росте параллельных видеопотоков). Разворачивать HPB ради звонков на 4 человека раз в неделю избыточно. Разворачивать его, когда у команды регулярно 15+ человек в видеозвонке — уже осмысленная инвестиция.

coturn нужен даже для маленьких звонков

Отдельная и частая ошибка — решить, что раз команда маленькая и HPB не нужен, то и TURN-сервер можно пропустить. Это не так. TURN нужен не для масштаба, а для гарантированного прохождения соединения через NAT, и без него звонки будут работать нестабильно даже вдвоём — у одних участников будет получаться, у других (за корпоративным файрволом, за мобильным оператором с CGNAT) звонок просто не установится, и разобраться, почему «у Маши не работает, а у всех остальных работает», без TURN в логах будет тяжело.

Минимальная установка coturn на Ubuntu:

apt update
apt install -y coturn

Базовый конфиг /etc/turnserver.conf:

listening-port=3478
tls-listening-port=5349
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=замените_на_длинный_случайный_ключ
realm=talk.вашдомен.ru
total-quota=100
stale-nonce=600
cert=/etc/letsencrypt/live/talk.вашдомен.ru/fullchain.pem
pkey=/etc/letsencrypt/live/talk.вашдомен.ru/privkey.pem
no-multicast-peers

Откройте нужные порты в фаерволе — TURN использует не только 3478/5349, но и диапазон портов для релея:

ufw allow 3478/tcp
ufw allow 3478/udp
ufw allow 5349/tcp
ufw allow 5349/udp
ufw allow 49152:65535/udp

После этого TURN подключается в самом Nextcloud: Настройки → Администрирование → Talk, поле «Серверы STUN/TURN», где указывается адрес сервера, тот же static-auth-secret и протоколы (UDP и TCP — TCP пригодится для сетей, где UDP целиком блокируется файрволом). Проверить, что TURN реально используется, а не просто прописан, можно через chrome://webrtc-internals во время звонка — там видно фактический тип ICE-кандидата (relay означает, что пошло через TURN).

Где Talk выигрывает у Zoom, а где стабильно проигрывает

Честное сравнение — не в пользу одной стороны целиком, а по конкретным сценариям.

Если у вас уже есть Nextcloud и команда до 6-8 человек, которая созванивается регулярно, но не проводит вебинары и большие летучки с видео у всех, — Talk без HPB закрывает эту задачу полностью, и переплачивать за Zoom нет смысла. Если нужны регулярные встречи на 15+ человек с видео или запись, разумнее либо сразу закладывать HPB, либо для конкретно этого сценария (большие звонки) держать отдельное решение — например, self-hosted Jitsi Meet, который изначально спроектирован вокруг SFU и переносит эту сложность на сервер с первого дня, а не только после апгрейда до HPB. Экономика такого перехода с подписки на self-hosted разбиралась отдельно в статье про цену часа конференции: Zoom против своего Jitsi — та же логика расчёта применима и к Talk, разница только в том, что у Talk стоимость размещения частично уже «оплачена», если Nextcloud и так стоит для файлов.

Отдельно стоит учесть ресурсы под сам Nextcloud, если Talk — не единственная причина его держать: базовые требования по памяти под облако разобраны в статье сколько RAM нужно для Nextcloud, и если планируете регулярные видеозвонки поверх обычной нагрузки файлового хранилища, закладывайте запас поверх этих цифр, а не впритык.

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