Звонки и конференции: настройка и эксплуатация
Актуально для: 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.
Дальше
- Звонки и конференции — та же функциональность глазами пользователя
- Встречи и календарь
- Архитектура