Сессионные залы: дизайн, состояние и возврат в общий зал

Кратко

Сессионный зал – временная малая группа внутри живого класса: несколько учащихся отделяются, чтобы поговорить между собой, а потом возвращаются. Хорошо построить залы – задача прежде всего про состояние, а не про видео. Видео уже обеспечивает ваш медиасервер. Сложно другое: всё время иметь один надёжный ответ на вопрос «кто в каком зале прямо сейчас», пока преподаватель распределяет людей, переводит их из зала в зал, рассылает сообщения, ведёт таймер и наконец возвращает всех в общий зал. Правильных способов построить залы два: переключать подписки внутри одного медиасервера или поднимать отдельную сессию на каждую группу. Первый проще в эксплуатации, второй лучше изолирует группы. В статье – что должна уметь система сессионных залов, обе архитектуры с их ценой, модель состояния, при которой переносы и переподключения работают надёжно, и ошибки, из-за которых удачное демо оборачивается обращениями в поддержку.

Зачем это читать

Если вы строите или покупаете виртуальный класс, сессионные залы – та функция, которая отличает настоящий учебный инструмент от видеозвонка с логотипом школы: именно в малых группах учащиеся по-настоящему говорят. Она же чаще всего ломается на глазах у тридцати студентов: после переноса пропал звук, зал не закрывается, таймер сработал, а никто не вернулся, переподключившийся студент попал не в ту группу. Видео здесь ни при чём, это ошибки состояния. После релиза их чинить дорого: обычно приходится переделывать то, как хранится состав залов. Статья заранее даёт архитектуру и модель состояния, чтобы вы ставили задачу инженерам, видя общую картину, решали, строить или покупать, и обходили предсказуемые сбои до того, как они сорвут занятие.

Что такое сессионный зал на самом деле

Сессионный зал – это временная подсессия живого класса. Преподаватель делит класс, скажем, из тридцати учащихся на шесть групп по пять, каждая группа на десять минут получает собственное аудио- и видеопространство, а потом все возвращаются. Это похоже на воркшоп, где участников разводят по соседним аудиториям: то же мероприятие, те же люди, на время другие стены. Аудио и видео в зале работают на той же технике реального времени, что и основной класс; её мы разбирали в статье WebRTC для живого обучения.

Новое здесь – учёт. Система всегда должна знать, кто из учащихся в какой группе, кому можно переходить между группами, что делать, когда чей-то ноутбук отключился и подключился снова, и как вернуть всех обратно. Этот учёт – состав залов и правила вокруг него – и есть функция сессионных залов. Всё остальное – инфраструктура, которая у вас уже есть.

Систему сессионных залов удобно представлять как граф состава (кто в каком зале) и набор операций над ним: распределить, перенести, разослать сообщение, отсчитать время, собрать всех обратно. Всё это в реальном времени и согласованно отображается на экране каждого учащегося. Если граф устроен хорошо, с видео проблем не будет; если плохо, урок не спасёт никакое качество картинки.

Чем сессионные залы оправдывают себя

Начнём с педагогики: именно она оправдывает бюджет. Исследования онлайн-обучения раз за разом показывают, что работа в малых группах повышает вовлечённость: учащимся комфортнее высказаться в группе из четырёх, чем в классе из сорока, они чаще задают вопросы, а смену зала воспринимают как паузу, которая переключает внимание и снимает скуку (University of Guelph, Office of Teaching and Learning, 2021). Совместная работа в малых группах связана с более глубоким усвоением и лучшим запоминанием, чем пассивное слушание.

Те же исследования честно говорят и о провалах: в залах без структуры учащиеся часто не могут договориться, а зал без задачи быстро замолкает; в опросе студентов чаще всего жаловались на технические сбои и одногруппников, которые не участвовали (Read et al., 2022). Вывод для продуктовой команды: разделить звонок на части мало. Система должна приносить в зал задачу (вопрос, общий документ, доску) и давать преподавателю возможность наблюдать и помогать. Значит, залам нужен канал для контента и канал видимости для преподавателя, а не только изолированный звук.

Пять операций, которые обязана поддерживать система сессионных залов

Если отбросить маркетинг, любая система сессионных залов сводится к пяти операциям над графом состава. Когда все пять работают правильно, функции можно доверять.

Первое – распределить учащихся по залам. Моделей три, и хороший продукт поддерживает все: автоматическое распределение (система случайно и поровну раскладывает учащихся), ручное (преподаватель перетаскивает каждого в зал) и самостоятельный выбор (учащиеся сами выбирают зал из списка). В открытом BigBlueButton самовыбор включается одним параметром API – freeJoin (BigBlueButton API, 2026). Для взрослых самовыбор – удобный вариант по умолчанию: преподаватель перестаёт быть узким местом. Но нужен лимит мест в зале, чтобы группы получились сбалансированными.

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

Третье – разослать сообщение во все залы. Преподавателю нужно объявление для всех сразу («осталось две минуты, заканчивайте»). Обычно это короткое текстовое уведомление, которое ненадолго появляется поверх экрана у каждого участника, отдельно от чата конкретного зала. Некоторые продукты умеют и голосовое объявление, которое на несколько секунд прерывает работу в каждом зале.

Четвёртое – вести таймер. Время работы в залах ограничено. Система показывает обратный отсчёт, предупреждает, что время почти вышло, и может автоматически закрыть залы. Небольшой запас после команды «закрыть», например минута, позволяет учащимся договорить, прежде чем их вернут; сделайте его настраиваемым.

Пятое – вернуть всех в общий зал. Закрытие залов возвращает каждого учащегося в общую сессию в том состоянии, в котором он её покинул: то же видео, тот же состав, тот же преподаватель. Эта операция сложнее, чем кажется: граф состава снова сводится к одному залу, и любой учащийся, «потерявшийся» по ходу работы, всплывает здесь как ошибка. Хорошая система заодно приносит в общий зал результаты работы групп. BigBlueButton, например, умеет выгружать в родительскую встречу текущий слайд с пометками и общие заметки каждого зала (параметры breakoutRoomsCaptureSlides и breakoutRoomsCaptureNotes).

Нажмите, чтобы увеличить

Как это устроено: две архитектуры

Правильных способов построить сессионные залы два, и различаются они тем, где «живут» залы. Оба предполагают SFU (selective forwarding unit) – медиасервер, который пересылает видео каждого участника остальным, не смешивая потоки. Подробно он разобран в разделе Видеостриминг, а применительно к большим классам – в статье о масштабировании живого класса.

Архитектура A – логическое деление (один SFU, переключение подписок). Все остаются подключены к одному медиасерверу и одному каналу сигналинга; меняются только правила маршрутизации. Когда класс делится, сервер перестаёт пересылать каждому учащемуся потоки других групп и отдаёт только потоки его зала. Перенос учащегося – это запись в таблице подписок, а не новое соединение. Эксплуатировать такую схему проще: один сервер, одно соединение на учащегося, одно место для состояния. Так сессионные залы реализует большинство современных WebRTC-платформ. Слабое место – масштаб последствий: проблема с сервером затрагивает весь класс.

Архитектура B – отдельные залы (своя сессия на каждую группу). Каждая группа – отдельный зал, возможно, на отдельном экземпляре медиасервера. Разделить класс значит создать шесть залов и переключить соединение каждого учащегося в один из них. Так устроен, например, BigBlueButton: зал создаётся как отдельная встреча с флагом isBreakout и ссылкой на родительскую встречу parentMeetingID (BigBlueButton API, 2026). Изоляция получается сильной: сбой в одной группе не задевает остальные, а ради распределения нагрузки группы можно даже развести по разным серверам. Цена – больше движущихся частей: при переносе соединение устанавливается заново, а состав приходится отслеживать между залами.

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

Нажмите, чтобы увеличить

Модель состояния, на которой держится надёжность

Самое важное проектное решение: один авторитетный источник истины о составе залов – на сервере и никогда на клиентах. Почти любой баг сессионных залов, который вам встречался, сводится к тому, что два экрана по-разному «считают», кто в каком зале. Граф принадлежит серверу, а клиенты только отображают то, что им сообщили.

На практике граф – небольшая, часто меняющаяся структура данных: каждому учащемуся сопоставлен id зала, плюс метаданные по каждому залу (открыт или закрыт, когда кончается таймер, как распределяли). Граф меняется при каждом распределении и переносе, поэтому его держат в быстром общем хранилище. В продакшене динамическое состояние залов и участников часто хранят в in-memory-хранилище вроде Redis, чтобы каждый серверный процесс и слой сигналинга видели одно и то же. Канал сигналинга – то же управляющее соединение, по которому идут аутентификация и состав зала, – в реальном времени рассылает изменения графа всем клиентам.

Российская деталь: в графе лежат идентификаторы и имена учащихся, то есть персональные данные. С 01.07.2025 ч. 5 ст. 18 152-ФЗ запрещает операции с ПДн граждан РФ в базах данных за пределами России, поэтому хранилище состояния, как и медиасервер, разворачивайте в российском контуре: в своём ЦОДе или российском облаке.

Два события особенно нагружают модель, и оба нужно спроектировать сразу, а не латать потом.

Перенос. Когда преподаватель переводит учащегося, сервер обновляет граф и даёт клиенту команду подписаться на потоки нового зала и отписаться от старого. В архитектуре A медиасоединение не рвётся, меняются только подписки. Если сделать иначе – разорвать соединение и установить заново, – учащийся несколько секунд видит чёрный экран и слышит тишину, а в десятиминутном зале это заметная часть занятия.

Переподключение. У учащегося пропала сеть, клиент подключается снова. Угадывать, где он был, клиент не должен: он спрашивает сервер, тот читает граф и отвечает: «ты в зале 3, он открыт, осталось четыре минуты». Раз источник истины – сервер, переподключение сводится к повторному чтению графа, и учащийся попадает ровно туда, где был. Если бы состояние хранили клиенты, результат переподключения был бы делом случая.

Нажмите, чтобы увеличить

Контроль преподавателя во время работы

Пока группы работают, преподаватель должен учить, а не просто смотреть на сетку залов. Здесь важны три инструмента. Заход в зал позволяет заглянуть в любую группу, послушать или помочь; технически это временный перенос преподавателя в этот зал. Просьба о помощи даёт учащемуся поднять флажок, который преподаватель видит из любого зала, – аналог поднятой руки в малой группе. Рассылка отправляет сообщение во все залы сразу. Без этих инструментов не обойтись: те же исследования, что хвалят залы, предупреждают, что группы без присмотра замолкают, так что присутствие преподавателя – часть функции, а не дополнение к ней.

Нажмите, чтобы увеличить

Пара слов о стоимости, потому что команды опасаются, что залы умножат счёт. Обычно этого не происходит. Залы даже уменьшают число пересылаемых потоков: каждый учащийся подписан только на свою группу, а не на весь класс. Возьмём класс из 30 человек в режиме «все видят всех»: каждый получает 29 потоков, и сервер пересылает 30 × 29 = 870 потоков. Разделим класс на 6 залов по 5: каждый получает 4 потока, сервер пересылает 6 × 5 × 4 = 120 потоков, примерно седьмую часть прежней нагрузки. Отправители те же; сервер просто перестал пересылать потоки, которые никто не смотрит. Стоимость ретрансляции (TURN), о которой говорилось в статье WebRTC для живого обучения, зависит от числа отправителей, поэтому практически не меняется.

Сравнение для инженеров

Выбор, как строить, обычно сводится к таблице ниже. Большинство архитектурных споров решает колонка «Изоляция» – так же, как в других статьях этого раздела выбор инструмента чаще всего решает колонка стандартов.

Ошибка, из-за которой демо превращается в инцидент

Самый соблазнительный способ сэкономить – и самый опасный: сделать залы иллюзией на стороне клиента. В этом антипаттерне все остаются в одном настоящем зале, а каждый клиент просто прячет видео других групп и глушит их звук. На демо это выглядит отлично и делается быстро. Потом учащийся открывает в браузере инструменты разработчика или баг переключает флаг – и он видит и слышит группу, в которую его не пускали. Это утечка на оцениваемом или чувствительном занятии, а изображение и голос учащихся – их персональные данные. Хуже того, настоящего графа состава у сервера никогда не было, поэтому переносы, переподключения и запись по залам потом не добавить без переписывания. Изоляцию залов обеспечивает сервер: он просто не пересылает медиа других групп. Поток, который не дошёл до клиента, не раскроет никакой клиентский баг.

Вторая, менее заметная ошибка – терять состояние при переносе или переподключении, потому что его хранил клиент. Решение описано выше: граф принадлежит серверу, и каждый перенос и переподключение читают его. Закладывайте это с первого дня: перевести на единый источник истины систему, где состояние размазано по клиентам, – одна из самых дорогих переделок в видео реального времени.

Доступность и запись занятия

Три обязательства переходят вместе с учащимся в зал. Первое – субтитры. Если в основном классе есть живые субтитры (критерий WCAG 2.1 1.2.4 Captions (Live), уровень AA; на WCAG 2.1 построен и российский ГОСТ Р 52872-2019), они нужны и в зале, то есть субтитры должны работать в каждом зале, а не только в общем. Второе – сурдопереводчик. Для учащихся с ОВЗ ст. 79 273-ФЗ относит услуги сурдопереводчика к специальным условиям обучения; свяжите переводчика с учащимся в графе состава, чтобы при любом распределении и переносе они перемещались вместе. Третье – управление с клавиатуры (WCAG 2.1, критерий 2.1.1 Keyboard, уровень A): учащийся, который не может нажать «Попросить помощь» мышью, должен добраться до кнопки с клавиатуры.

Если вы записываете залы (см. запись живых занятий), записывайте каждый зал отдельно и с привязкой к графу состава, чтобы по записи было видно, кто на самом деле присутствовал. В BigBlueButton запись залов по умолчанию выключена (breakoutRoomsRecord), и это разумно: включайте её осознанно, предупреждайте участников и храните записи в России, как и остальные данные учащихся.

Где здесь Фора Софт

Сессионные залы – задача про состояние, которая только выглядит задачей про видео, и мы работаем как раз на стыке этих двух областей. Фора Софт с 2005 года делает видео реального времени, системы видеоконференций и ПО для виртуальных классов, поэтому одна команда отвечает и за медиасервер, и за сигналинг, и за состояние состава, которое должно быть согласовано между ними. Мы подключаемся, когда учебному продукту нужны надёжные залы: переносы без потери звука, переподключение в нужный зал, запись по залам и субтитры. И честно говорим, если готовый сервис ВКС или self-hosted BigBlueButton уже закрывает ваши задачи и заказная разработка не окупится. Во всех наших направлениях – e-learning, видеоконференциях, телемедицине и стриминге – в основе лежит одно и то же: согласованное состояние в реальном времени.

Главное

• Сессионные залы – задача про состояние, а не про видео; граф состава и есть функция.
• Держите один авторитетный граф состава на сервере, в российском контуре; клиенты его только отображают.
• Переводите учащихся из зала в зал переключением подписок, а не разрывом соединения.
• Залы уменьшают число пересылаемых потоков: каждый учащийся подписан только на свою группу.
• Никогда не имитируйте изоляцию на клиенте: надёжная граница – только медиа, которое сервер не переслал.
• Субтитры, сурдоперевод, управление с клавиатуры и запись по залам должны работать в каждом зале, а не только в общем.

Что читать дальше

• Виртуальный класс: что это и чем он отличается от встречи
• Масштабирование живого класса: SFU, simulcast и лекция на 200 мест
• Интерактивная доска и общий холст