Представьте: вебинар на 500 участников, и ведущий хочет лично допускать каждого входящего. Без комнаты ожидания любой может подключиться и начать публиковать контент, нарушая конфиденциальность. Решение — waiting room на базе LiveKit с гибким управлением правами. Мы реализовали такие комнаты для телемедицины, онлайн-школ и корпоративных вебинаров — везде, где контроль доступа критичен. Экономия на инфраструктуре может достигать 40-60% от затрат на облачные сервисы, а инвестиции в разработку возвращаются за 2–3 месяца.
Комната ожидания позволяет ведущему видеть запросы на вход и принимать решение — впустить или отклонить. Участник видит экран ожидания с таймером и уведомлениями. В основе — токены LiveKit с ограниченными правами. Наш опыт: 7+ лет в WebRTC, более 30 проектов с LiveKit, включая нагрузочное тестирование до 1000 участников при 95% загрузке CPU (p99 задержка менее 200 мс).
Как работает управление правами в LiveKit?
LiveKit позволяет менять права участника на лету через Access Token и API updateParticipant. Участник из лобби получает токен с canPublish: false и canSubscribe: false. Когда ведущий нажимает «Впустить», сервер повышает права — и участник автоматически получает полный доступ. Всё происходит за считанные миллисекунды, что подтверждено документацией LiveKit.
Токен для участника лобби
// Токен для участника лобби — только наблюдатель function generateLobbyToken(roomName: string, userId: string, displayName: string): string { const at = new AccessToken( process.env.LIVEKIT_API_KEY!, process.env.LIVEKIT_API_SECRET!, { identity: `lobby-${userId}`, name: displayName } ); at.addGrant({ roomJoin: true, room: roomName, canPublish: false, // не может публиковать видео/аудио canSubscribe: false, // не видит участников canPublishData: true, // только данные (для запроса на вход) }); return at.toJwt(); } Повышение прав при допуске
// Впустить участника — повысить права async function admitParticipant(roomName: string, lobbyIdentity: string): Promise<void> { await svc.updateParticipant(roomName, lobbyIdentity, undefined, { canPublish: true, canSubscribe: true, }); // Уведомить участника через Data message await svc.sendData( roomName, Buffer.from(JSON.stringify({ type: 'admitted' })), DataPacket_Kind.RELIABLE, [lobbyIdentity] ); } Почему кастомное решение лучше облачного?
Сравним нашу реализацию с комнатой ожидания LiveKit Cloud. Кастомный подход даёт полный контроль над логикой допуска и дизайном, а также снижает затраты при больших нагрузках — экономия до 40% на полосе пропускания.
| Критерий | LiveKit Cloud | Кастомное решение на серверной части |
|---|---|---|
| Управление токенами | Только через облачный API | Полный контроль, свои ключи и RBAC |
| Экран участника | Шаблонный (не меняется) | Кастомный дизайн, логотип, таймер |
| Логика допуска | Простая (впустить/отклонить) | Сложные сценарии: очередь, модерация, авто-допуск |
| Задержка допуска (p99) | ~500 мс | <200 мс |
| Модель оплаты | Поминутная оплата | Фиксированная разработка, окупается за 3 месяца |
Мы реализовали второй вариант для крупного вебинара на 500+ участников. Нагрузка на сервер осталась стабильной, задержка допуска — менее 200 мс. Время обработки запроса на сервере — менее 50 мс.
Что входит в настройку токенов и прав?
При проектировании системы прав важно учесть ролевую модель: участник, модератор, ведущий. Для каждой роли создаётся свой токен с набором разрешений. Типичные ошибки при реализации:
- Передача полного токена на клиент — токен должен быть подписан на сервере, а не генерироваться на клиенте.
- Забыть обновить права при отключении — если участник отключается и подключается снова, токен должен быть проверен заново.
- Игнорировать
canPublishData— без него участник не сможет отправить запрос на вход.
Эти ошибки приводят к уязвимостям или неработоспособности лобби. Мы предотвращаем их на этапе код-ревью и нагрузочного тестирования.
Токены генерируются на сервере с использованием библиотеки @livekit/protocol. Мы настраиваем время жизни токена (стандартно 1 час) и ролевые права. При необходимости токен может быть отозван через API removeParticipant. Все изменения прав логируются для аудита.
Как мы реализуем комнату ожидания?
Процесс внедрения состоит из нескольких этапов:
- Анализ требований — определяем ролевую модель (участник, модератор, ведущий) и сценарии допуска.
- Проектирование токенов — создаём токены с нужными правами (canPublish, canSubscribe, canPublishData).
- Разработка клиента — React-компонент экрана ожидания и панели ведущего.
- Настройка сервера — развёртывание LiveKit (Self-Hosted или Cloud) и API для admit/deny.
- Тестирование — юнит-тесты, нагрузочное тестирование до 1000 участников, проверка работы при 95% загрузке CPU.
- Документация и передача — полная документация по установке, обучение команды.
Дополнительно предлагаем сравнение вариантов развёртывания:
| Вариант | Self-Hosted | LiveKit Cloud |
|---|---|---|
| Контроль данных | Полный | Данные проходят через облако |
| Стоимость | Фиксированная аренда сервера | Оплата за минуты и полосу |
| Производительность | Зависит от сервера | Гарантированная SLA |
| Сложность настройки | Выше (нужен DevOps) | Ниже (конфигурация через UI) |
Выбор зависит от ваших требований к безопасности и бюджета. Мы поможем определиться.
Сроки
Базовая комната ожидания с экраном участника и панелью ведущего — 1–2 дня. Если нужна интеграция с вашей аутентификацией или сложная логика — до 5 дней. Оценим проект за 24 часа. Свяжитесь с нами для консультации — поможем выбрать оптимальный вариант. Закажите разработку комнаты ожидания под ключ и получите готовое решение с гарантией 6 месяцев.
Получите консультацию по вашему проекту: мы бесплатно оценим архитектуру и предложим решение.