Звонки и конференции: настройка и эксплуатация

Актуально для: SimpleTwo 0.9.x · Проверено: 20.09.2026

Установка ролей sfu, turn и recorder описана в развёртывании on-premise. Эта статья — про то, что происходит после: что администратор настраивает, как ведёт себя пул, кто чем управляет в звонке и куда смотреть, когда «звонок соединился, а звука нет».

1. Из чего состоит звонок

Часть	Кто	Что делает
Сигналинг	messaging	приглашение, звонок, ответ, отбой едут по тому же соединению, что и переписка
Пропуск в комнату	координатор	подписывает участнику токен доступа к комнате: что ему можно, на какой срок
Медиа	sfu	принимает потоки и пересылает их остальным. Не микширует: каждый получает то, что нужно его экрану
Обход NAT	turn	релей для тех, кто иначе не соединится напрямую (порядка 15% участников)
Запись	recorder	пишет комнату целиком и кладёт результат в объектное хранилище

Комната ад-хок-звонка называется по разговору, из которого его начали, а комната встречи — по встрече. Из этого следует практичное: звонок в одном и том же чате всегда попадает в одну и ту же комнату, поэтому право войти туда даёт не имя комнаты, а пропуск с ограниченным сроком, который можно отозвать.

2. Что настраивает администратор

Settings → Calls — учётные данные медиасервера: API key и API secret. Ими координатор подписывает пропуска; адрес узла берётся из карточки развёртывания, а не вводится второй раз руками.

Settings → Recording — куда складывать записи: endpoint, регион, бакет, ключ доступа, секрет и префикс. Хранилище — роль s3 или ваше существующее S3-совместимое.

Адрес медиасервера — это адрес для клиента

Клиент подключается к SFU напрямую: сигналинг можно спрятать за общий TLS-фронт, а медиа — нет, каждый узел объявляет свои ICE-кандидаты. Если в адресе узла оказался приватный адрес, до которого клиент не дотягивается (типичная установка в DMZ), звонок соединится и будет молчать.

3. Пул SFU

Несколько узлов sfu работают как один медиасервер, а связывает их redis:

• комната живёт на том узле, где её открыли, и пул отвечает, на каком именно. Поэтому второй узел без шины поставить нельзя — установка откажет;
• два узла без общей шины — это два разных мира: двое участников одной встречи, попавшие на разные узлы, не увидят друг друга;
• действие ведущего выполняется на узле комнаты. Модерация, отправленная не туда, тихо отработает над пустой комнатой и вернёт успех — поэтому координатор сначала определяет узел по комнате и только потом обращается к нему.

Диагностика пула — карточка Calls в консоли (GET /admin/api/calls). Она отвечает на три вопроса: какие узлы развёрнуты, дотянется ли до каждого клиент для медиа, и связаны ли узлы шиной или это набор островов. Проверка здоровья самого LiveKit этого не покажет: она опрашивает 127.0.0.1 на хосте SFU и говорит только о том, что процесс жив.

4. Кто чем управляет в звонке

Три действия доступны только ведущему (в остальных случаях ответ — host permission required):

Действие	Что делает
mute	выключает микрофон участника
remove	удаляет участника из комнаты
promote / demote	выдаёт и отбирает право публиковать поток — режим докладчика

Отбор права публикации выполняет сервер: это не просьба к клиенту, а изменение прав живого участника. Каждое действие пишется в аудит (calls.moderate) с именем того, кто его сделал.

Лобби устроено так же — правами, а не флажком. Гость, ожидающий допуска, получает пропуск, который не даёт ни публиковать, ни подписываться: он подключён и при этом отсутствует — ничего не слышит и не слышен. Когда его впускают, меняются права живого участника; переподключаться и что-то нажимать ему не нужно. Клиент, который «не поддерживает лобби», обойти его не может.

Ссылка в идущий звонок приводит человека в ту же комнату — без переезда участников и без паузы в звуке, — и держит его в лобби, пока кто-то из участников не впустит. Посторонний получает комнату и ничего больше: ни разговор, ни историю, ни список участников.

5. Запись и расшифровка

Запись идёт композицией всей комнаты на стороне сервера и выгружается в объектное хранилище; старт и стоп доступны ведущему. Отдельная роль recorder считается по одновременным записям: 4 vCPU и 4 ГБ на одну.

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

Расшифровки в текст пока нет

Реализована первая половина: параметр встречи и автоматическая запись. Перевод записи в текст, который можно прочитать и поискать, — следующий этап и в 0.9.x недоступен. Если вы обещаете пользователям «протокол встречи», обещайте пока запись.

6. Переговорные и панели

Переговорная — это учётная запись особого вида: без пароля и без роли в консоли, зато с календарём и с возможностью привязать к ней панель — экран, который висит у входа. Заводится она как обычный пользователь с типом «комната» (Users → создать, вид «room»), а на вкладке комнат к ней добавляются и отзываются панели.

7. Если что-то не работает

Симптом	Причина
Звонок соединяется, звука нет	клиент не дотягивается до адреса узла SFU — в карточке узла приватный адрес, который не обслуживает ни одна группа шлюзов, либо закрыты порты
Двое в одной встрече не видят друг друга	два узла sfu без общей шины redis
Ведущий нажал «выключить микрофон», ответ успешный, ничего не произошло	действие ушло не на тот узел пула; проверьте, что карточка Calls видит все узлы и шину
Гость не может войти по ссылке	пропуск в комнату истёк или отозван; выдайте ссылку заново
Часть участников без звука в одну сторону	не поднят или недоступен turn: этим людям нужен релей
Запись не появляется в хранилище	не настроено Settings → Recording или роль recorder не видит шину и хранилище

Ёмкость и требования к каналу для sfu, turn и recorder — в развёртывании on-premise, раздел 2.

Дальше

• Звонки и конференции — та же функциональность глазами пользователя
• Встречи и календарь
• Архитектура