Эталонная архитектура живого обучения: полная картина

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Платформа живого обучения – это не видеозвонок с логотипом, а четыре связанные системы: плоскость управления, которая отвечает за комнаты и идентификацию; медиа-плоскость, которая передаёт видео; плоскость общего состояния, где живут сессионные залы и доска; и учебный мост, который связывает занятие с системой, фиксирующей, кто чему научился. Эта статья завершает блок о живом обучении: она собирает всё, что разбиралось раньше, – клиенты, сигналинг, селективную пересылку (SFU), состояние залов, общий холст, запись и связь с системой управления обучением (LMS) – в одну эталонную архитектуру, которую можно отдать инженеру. Главное решение, от которого зависит вся сборка: должно ли занятие отчитываться в учебную систему через LTI (стандарт, по которому LMS доверяет внешнему инструменту) и xAPI (стандарт записи учебных событий). Именно этот мост отличает виртуальный класс от видеозвонка. В статье – полная карта, уровни масштабирования от занятия с репетитором один на один до лекции на десять тысяч мест, российские требования к каждой плоскости, расчёт стоимости и задержки и чёткая граница «делать или покупать».

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

Если вы проектируете виртуальный класс – маркетплейс репетиторов, платформу курсов с потоками, корпоративную систему обучения с живыми занятиями, – вы берётесь за самое сложное в e-learning: видео реального времени, общее интерактивное состояние и учебные записи одновременно, и всё это с задержкой в миллисекунды. Большинство команд недооценивают задачу: демо выглядит как видеозвонок, а видеозвонки кажутся решённой проблемой. Статья даёт директору по обучению, основателю EdTech-компании или продакт-менеджеру полную архитектурную карту, чтобы точно ставить задачу инженерам, оценивать «виртуальный класс» вендора по реальному эталону и понимать, какие плоскости можно купить, а какие придётся строить (почти всегда это учебный мост).

Сначала – одна идея, на которой держится всё

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

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

Плоскость управления отвечает за идентификацию, комнаты, расписание, присутствие и права, то есть за логику «кому, в какую комнату и в какой роли можно». Медиа-плоскость передаёт звук и видео с задержкой в миллисекунды, почти всегда через селективную пересылку (о ней чуть ниже). Плоскость общего состояния в реальном времени синхронизирует у всех распределение по залам, штрихи на доске, чат и результаты опросов. А учебный мост связывает живую сессию с системой управления обучением и хранилищем учебных записей, чтобы занятие оставляло после себя записи, оценки и аналитику.

Если держать эти четыре плоскости раздельно, остальная статья (и ваша сборка) сложится сама. Если смешать – получится классический провал: красивый видеозвонок, который не может сообщить вашей LMS, что вообще что-то произошло.

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

Плоскость 1: управление

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

Уже на входе класс встречается с учебной системой: в реальном продукте ученик обычно не заводит отдельный аккаунт, а приходит из LMS уже аутентифицированным. Механизм называется LTI (Learning Tools Interoperability) – это стандарт организации 1EdTech, по которому учебная система доверяет внешнему инструменту. Подробно о нём – в разделе про учебный мост, а пока запомните одно: в хорошо построенном классе идентификация делегируется, а не дублируется. Если же продукт продаёт курсы напрямую частным лицам и ведёт собственные аккаунты, учтите российское правило: с 01.12.2023 сайты обязаны авторизовывать пользователей из России только по российскому номеру телефона, через ЕСИА («Госуслуги»), ЕБС или информационную систему российского юрлица (406-ФЗ). Вход только через зарубежную соцсеть под это правило не подходит, а корпоративный SSO по OIDC или SAML через систему самого заказчика, российского юрлица, подпадает под последний вариант.

В плоскости управления живёт и сигналинг – служебный обмен, который настраивает соединение реального времени до того, как пойдёт видео: стороны сообщают друг другу, как до них достучаться и какое медиа они могут отправлять, и только после этого открывается медиаканал. Полезная перемена последних лет: этот шаг, который раньше каждый писал сам, стандартизируется. Спецификации WHIP и WHEP заменяют самописный протокол поверх WebSocket обычным HTTP для публикации и воспроизведения, и большинство медиасерверов их уже поддерживают. WHIP стал стандартом IETF (RFC 9725, март 2025), WHEP на октябрь 2026 остаётся черновиком. Подробная механика сигналинга – в статье WebRTC для живого обучения; для архитектуры важно, что сигналинг – зона ответственности плоскости управления, отдельная от медиаканала, который он настраивает.

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

Плоскость 2: медиа

Об этой плоскости думают, когда говорят «видеокласс», и её чаще покупают, чем строят. Задача узкая и жёсткая: передавать звук и видео между участниками с такой малой задержкой, чтобы разговор шёл естественно. Ориентир – около 150–200 миллисекунд «от стекла до стекла»: в этих пределах живое общение ещё работает.

Для всего, что сложнее звонка один на один, медиа-плоскость строят вокруг SFU (Selective Forwarding Unit, сервер селективной пересылки). Он получает видео каждого участника один раз и выборочно пересылает его остальным, вместо того чтобы каждый отправлял копию всем. Почему именно так и какие есть альтернативы (mesh, где все соединены со всеми, и серверное сведение MCU) – в статье масштабирование живого класса: SFU, simulcast и лекция на 200 мест. Внутреннее устройство – как SFU пересылает потоки, что дают simulcast и SVC, как TURN-релеи обходят файрволы – относится к разделу «Видеостриминг»: топологии SFU, MCU и mesh и simulcast и SVC. Здесь важно другое: где SFU стоит в общей архитектуре и насколько большим он должен быть.

Размер медиа-плоскости задают два факта. Первый: один узел SFU на современном железе пересылает порядка 500–1 000 потоков, прежде чем понадобится второй; для одного воркера mediasoup обычно называют цифры из этого диапазона. Второй: когда одновременно публикующих становится больше нескольких тысяч, нужен каскад. В каждом регионе работает свой SFU, ученики подключаются к ближайшему узлу, а серверы передают друг другу только те потоки, которые должны попасть в другой регион. Jitsi реализовал эту идею под названием Octo. В LiveKit каскад между узлами есть в облачной версии, а при самостоятельном развёртывании комната пока должна помещаться на одном узле – это стоит учесть, выбирая сервер для российского облака. Рисунок с уровнями масштабирования ниже превращает эти числа в решение.

Граница «делать или покупать» здесь самая чёткая. Медиа-плоскость – решённая задача: с ней хорошо справляются open-source-серверы (mediasoup, LiveKit, Janus, Jitsi, а для готового класса – BigBlueButton), развёрнутые в российском облаке, и российские CPaaS и SDK (Voximplant, TrueConf SDK и другие). Собственную медиа-плоскость строят, только если контроль над медиаканалом и есть ваш продукт, а это редкость. В большинстве учебных продуктов готовый SFU покупают или разворачивают у себя, а инженерные силы тратят на плоскости, которые отличают продукт от конкурентов.

Плоскость 3: общее состояние

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

Главный технический выбор – как поддерживать согласованность распределённых копий этого состояния. Сегодня для доски и других совместных пространств по умолчанию берут CRDT (conflict-free replicated data types, бесконфликтные реплицируемые типы данных). Эти структуры устроены так, что когда двое одновременно рисуют или печатают, правки сливаются в одинаковый результат на каждом экране без центрального арбитра, который определял бы порядок. К 2026 году в этой нише лидируют две библиотеки, Yjs и Automerge; Yjs особенно часто выбирают там, где важна скорость, например для досок. CRDT выигрывают за счёт отзывчивости: штрих должен появиться под стилусом до любого обращения к серверу, потому что даже 80 миллисекунд между касанием и линией разрушают ощущение рисования. Поэтому локальная копия обновляется мгновенно, а согласование идёт потом.

Это состояние обычно передают по отдельному от видео каналу данных реального времени (WebRTC data channel или WebSocket). Разделение важно: доска должна работать плавно, даже когда видео страдает на слабом канале. Механика залов – деление комнаты на группы, перенос учеников между SFU-комнатами, сохранение доски и чата каждой группы и возврат в общий зал – отдельная задача, она разобрана в статье сессионные залы: дизайн, состояние и возврат в общий зал, а сам холст – в статье интерактивная доска и общий холст. Для архитектуры важно: состояние залов и доски живёт в этой плоскости, а не в медиа, и у него свой способ хранения и свой путь масштабирования.

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

Плоскость 4: Учебный мост – то, что делает это классом

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

Запуск: LTI 1.3. Ученик нажимает на занятие внутри своей LMS – например, Moodle, стандарта де-факто в российских вузах, где LTI 1.3 встроен, – и попадает в виртуальный класс уже авторизованным, с правильной ролью. Собственные ЭИОС вузов и российские корпоративные LMS поддерживают LTI по-разному, а публичных заявлений о поддержке немного, поэтому проверяйте конкретную систему до проектирования моста (подробнее – в статьях об интеграции с российскими LMS и ЭИОС вузов и с корпоративными LMS и HR-системами). Этот механизм задаёт стандарт LTI 1.3 (Learning Tools Interoperability) от 1EdTech, и описывать его нужно точно: LTI 1.3 – не вход по паролю. Он использует запуск через OpenID Connect (OIDC) и подписанный токен JSON Web Token (JWT), в котором передаются идентичность пользователя, его роль и контекст курса. LMS ручается за пользователя, а ваш инструмент доверяет подписанному сообщению. Единый вход (SSO) – следствие этого механизма, а не сам механизм.

Список участников и оценки: LTI Advantage. Поверх запуска LTI 1.3 работают три необязательных сервиса под общим названием LTI Advantage. Два из них для класса критичны. Names and Role Provisioning Services (NRPS) позволяет инструменту получить официальный список участников курса с ролью каждого, так что классу не нужно вести отдельный список зачисленных. Assignment and Grade Services (AGS) позволяет возвращать оценки и комментарии обратно в журнал LMS: оценка за живую активность, балл за участие или отметка о посещении появляются там, где их ждёт учебное заведение. Третий сервис, Deep Linking, позволяет преподавателю выбрать конкретную сессию и встроить её прямо из LMS. Все три описаны в LTI Advantage Implementation Guide от 1EdTech; называйте сервисы по именам, когда оцениваете объём работ.

Учебные события: xAPI и LRS. LTI отвечает на вопросы кто и какая оценка. На более тонкий вопрос – что происходило на занятии – отвечает Experience API (xAPI) от ADL. Он фиксирует учебные события простыми утверждениями («Мария вошла в живую сессию», «Мария говорила 4 минуты», «Мария выполнила задание в зале») в хранилище под названием Learning Record Store (LRS). Когда занятие записано и его смотрят позже, повтор отслеживается через xAPI Video Profile – тот же словарь видеособытий (played, paused, seeked, completed), что и для любого видео каталога; он разобран в статье трекинг видео через xAPI. Не путайте роли: SCORM и журнал LMS фиксируют заранее заданный набор результатов, а xAPI и LRS – подробное поведение. Серьёзный класс использует и то и другое: LTI/AGS для официальной оценки, xAPI/LRS для аналитики.

У российского учебного моста есть ещё два выхода, которых нет в стандартах 1EdTech и ADL. Если по итогам программы ДПО выдаётся удостоверение о повышении квалификации или диплом о переподготовке, организация вносит сведения о нём в ФИС ФРДО в течение 30 дней со дня выдачи (ПП № 850, с 01.09.2025). А если класс используют для обучения по охране труда, которое п. 66 Порядка обучения по охране труда (ПП № 2464) разрешает проводить с ДОТ (кроме практических занятий по первой помощи, применению СИЗ и на тренажёрах), сведения о проверке знаний вносятся в реестр обученных лиц Минтруда в течение 3 рабочих дней. Закладывайте эти выгрузки в мост сразу, а не после первой проверки.

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

Складываем плоскости: как проходит занятие

Проведём одну сессию через все четыре плоскости: архитектура – это и есть их согласованная работа. Ученик нажимает на ссылку занятия в LMS. Плоскость управления принимает запуск LTI 1.3, проверяет подписанный токен, читает роль и курс и сразу отправляет ученика в нужную комнату, без повторного входа. Сигналинг настраивает соединение. Медиа-плоскость пропускает звук и видео ученика через SFU и пересылает ему потоки остальных, выбирая слой simulcast под его сеть. Когда преподаватель делит класс на группы, плоскость общего состояния распределяет учеников по залам, выдаёт каждой группе свою доску (документ CRDT) и чат, а потом снова объединяет их. Всё это время учебный мост пишет утверждения xAPI в LRS – вошёл, говорил, рисовал, ответил на опрос – и в конце возвращает балл за участие или тест в журнал LMS через AGS. После занятия пайплайн записи превращает сессию в видео каталога с трекингом, как описано в статье запись живых занятий и постобработка.

Этот единственный проход и есть весь продукт. Любая функция, которую вы когда-нибудь добавите, попадёт в одну из четырёх плоскостей.

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

Российская специфика: требования ко всем четырём плоскостям

Архитектура выше международная, но в России на неё ложатся ещё три группы требований, и учесть их проще на схеме, чем потом.

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

Реестр ПО для образовательных организаций. По п. 21 Правил применения ЭО и ДОТ (ПП № 1678 в ред. ПП № 517) LMS, ВКС, прокторинг и другое ПО в составе дистанционных технологий должны создаваться и использоваться в соответствии с законодательством РФ и (или) входить в единый реестр российского ПО. Из-за «и (или)» строгость нормы зависит от толкования, но к государственным школам и вузам её на практике применяют жёстко.

Школы и колледжи – через ГИС и MAX. Для общеобразовательных программ и СПО организация, которая обрабатывает ПДн учеников, обязана использовать государственные информационные системы и «многофункциональный сервис обмена информацией», то есть мессенджер MAX (ч. 3.1 ст. 16 273-ФЗ, п. 4.1 и 9 ПП № 1678); Сферум перенесён в MAX. Вузы и организации ДПО вправе использовать ГИС «Современная цифровая образовательная среда» и MAX, но не обязаны (п. 10). Для школьного продукта это меняет учебный мост: он должен работать с государственным контуром, а не только с LMS.

Размер сборки: уровни масштабирования

В зависимости от размера «виртуальный класс» – очень разные сборки. Четыре уровня покрывают почти любой учебный продукт, и если заранее определить свой, вы не построите ни слишком много, ни слишком мало.

Уровень 1 – один на один (репетитор, консультации). Один репетитор и один ученик. Медиа может идти напрямую, peer-to-peer, без медиасервера; релей нужен только как запасной вариант для сложных сетей. Плоскость общего состояния всё равно важна – репетиторство держится на общей доске, – но медиа-плоскость здесь в простейшем виде. Это самый дешёвый в эксплуатации уровень.

Уровень 2 – малый интерактивный класс (до ~30–50 человек, семинар). Камеры могут быть включены у всех; залы и доска в центре внимания. Один узел SFU спокойно справляется с медиа. На этот уровень рассчитано большинство «виртуальных классов», и именно здесь плоскость общего состояния нагружена сильнее всего.

Уровень 3 – большой класс (до нескольких сотен, лекция). Теперь большинство участников только смотрят. Видео публикуют преподаватель и несколько активных учеников. Число публикующих ограничивают, а simulcast и SVC позволяют дёшево обслуживать большинство, которое только принимает. Одного SFU или небольшого кластера всё ещё хватает.

Уровень 4 – массовая сессия (от тысяч до десятков тысяч, лекция-событие или живой эфир MOOC). SFU каскадируют по регионам, а на самом большом масштабе тех, кто только смотрит, переводят на одностороннее вещание (low-latency HLS), оставляя WebRTC для интерактивного ядра. Экономика и выбор кодеков здесь опираются на статью масштабирование доставки: CDN, транскодинг и стоимость при больших объёмах и раздел «Кодирование видео».

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

Стоимость и задержка: пример расчёта

Разберём один уровень на цифрах. Возьмём уровень 2: 50-минутный семинар, 30 учеников, у всех включены камеры 720p, есть залы и общая доска, занятие записывается для каталога.

Бюджет задержки. Для естественного разговора задержка «от стекла до стекла» должна быть меньше примерно 200 миллисекунд. Грубая раскладка:

захват + кодирование     ≈  30 мс
сеть до SFU              ≈  40 мс (регионально)
пересылка SFU            ≈  10 мс
сеть до зрителя          ≈  40 мс
джиттер-буфер + декод    ≈  50 мс
-----------------------------------
итого                    ≈ 170 мс  → в пределах 200 мс для живого разговора

У доски свой бюджет: локальный штрих появляется мгновенно (воспринимаемая задержка 0 мс), а обновление CRDT согласуется в фоне, поэтому медленный видеоканал не тормозит перо.

Трафик и стоимость. Тридцать публикующих по ~1,2 Мбит/с, которых SFU пересылает остальным 29 участникам (30 × 29 = 870 потоков), – эта нагрузка и задаёт размер медиасервера, и она укладывается в один узел SFU. Но, как показала статья о записи, регулярные расходы определяет не живой час, а доставка повтора. Если позже 200 учеников посмотрят 50-минутную запись, примерно по 0,6 ГБ каждый:

200 зрителей × 0,6 ГБ = 120 ГБ трафика
120 ГБ × ~7,2 ₽/ГБ (ориентировочная цена трафика CDN) ≈ 860 ₽ на доставку этого повтора

Цена трафика здесь – ориентир для логики расчёта, а не тариф конкретного провайдера: сверяйтесь с прайсом выбранного российского облака или видеоплатформы.

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

Ошибки, из-за которых сборка не работает

«Это просто видеозвонок с доской». Корневая ошибка. У видеозвонка нет учебного моста: ни запуска через LTI, ни синхронизации списка участников, ни возврата оценок, ни событий xAPI. Продукт, построенный на этом допущении, выходит на рынок, хорошо смотрится на демо, а потом не может ответить на первый вопрос учебного заведения: кто присутствовал и кто сдал?

«LTI логинит пользователя». Технически – нет. LTI 1.3 – это запуск через OIDC с подписанным JWT, а единый вход – следствие. Команды, которые проектируют его как вход по паролю, строят интеграцию неправильно и не проходят проверку на соответствие стандарту.

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

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

«Одного SFU хватит навсегда». Хватит, пока в самой большой сессии не окажется несколько тысяч публикующих, – и тогда отсутствие плана каскада обернётся аварией. Честно определите свой уровень и проектируйте медиа под сессии, которые вы действительно будете проводить, а не под демо.

«Посмотрел повтор на 100% – значит, прошёл занятие». Посещение, участие и завершение – разные сигналы из разных источников: посещение – через AGS, события участия – через xAPI, а завершение – по осознанно заданному правилу. Их смешение – самая частая ошибка измерений в e-learning, и начинается она с архитектуры.

Делать или покупать: решение по каждой плоскости

Решение «делать или покупать» – не одно, а четыре, по одному на каждую плоскость. В таблице – реалистичные варианты и то, как каждый из них работает с учебными стандартами, без которых нет класса.

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

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

Фора Софт с 2005 года строит системы видео реального времени, видеосвязи, стриминга и e-learning, и платформа живого обучения находится ровно на пересечении этих направлений: медиа на WebRTC, общее состояние в реальном времени и учебный мост в LMS. Решение «делать или покупать», с которым мы помогаем командам, конкретное и принимается по каждой плоскости. Готовый SFU в российском облаке и встраиваемая доска быстро выводят на рынок продукт для семинаров, а собственная плоскость состояния и собственный учебный мост LTI/xAPI выделяют маркетплейс репетиторов или платформу курсов на рынке и готовят их к работе с учебными заведениями. Мы работаем в e-learning, видеосвязи, стриминге, OTT и телемедицине, поэтому нас обычно зовут, когда класс должен давать вещательное качество в медиа-плоскости и строгую измеримость в учебном мосту. Без преувеличений: для медиа-плоскости честный ответ часто «разверните готовый SFU», и мы так и скажем. Собственная разработка должна приходиться на ту часть, которая отличает ваш продукт.

Главное

• Живой класс – это четыре плоскости (управление, медиа, общее состояние, учебный мост), а не один видеоинструмент.
• Классом его делает учебный мост: запуск через LTI 1.3, список участников через NRPS, оценки через AGS, события xAPI.
• LTI 1.3 – это запуск через OIDC с подписанным JWT, а не вход по паролю; единый вход – следствие.
• Состояние залов и доски живёт в плоскости общего состояния на своём транспорте, а не в SFU.
• Размер медиа-плоскости задаёт уровень: P2P, один SFU или каскад SFU с вещанием.
• Все четыре плоскости – в российском контуре; для школ и вузов проверьте реестр ПО (п. 21 ПП 1678), для школ и СПО – работу через ГИС и MAX.
• Медиа-плоскость купите или разверните готовую; учебный мост постройте сами – за него продукту и доверяют.

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

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