P2P, SFU или MCU: какую топологию выбрать для консультации, групповой сессии и вебинара

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

Кратко

В любом видеозвонке с несколькими участниками нужно решить, как звук и видео каждого доходят до всех остальных. Вариантов всего три: peer-to-peer (каждое устройство отправляет поток напрямую каждому), SFU (сервер пересылает каждый поток без изменений) или MCU (сервер сводит все потоки в одну общую картинку). Peer-to-peer подходит только для консультации один на один. SFU – основной инструмент для групповых занятий, приёмов с участием родственников и консультаций «врач – врач» с несколькими специалистами. MCU оправдывает свою высокую стоимость, только когда нужна одна общая запись или приходится работать со слабым устройством – планшетом в регистратуре или видеотележкой в палате. Это не вопрос вкуса: выбор определяют число участников, устройство самого слабого пациента и то, ведёте ли вы запись. Ошибка обернётся севшими батареями телефонов, оборванными групповыми сессиями или счётом за серверы на сотни тысяч рублей в месяц. В статье каждая топология сопоставлена с типом клинической сессии, приведены расчёты трафика и учтена граница медданных: в телемедицине медиасервер обрабатывает данные пациента, а значит, стоит в России и работает по поручению клиники или в вашем защищённом контуре.

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

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

Главный вопрос любого группового звонка

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

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

Три варианта отличаются одним: где делаются копии. Либо каждый отправитель сам копирует свой поток и рассылает его всем (peer-to-peer), либо копии делает сервер (SFU), либо сервер собирает одну сведённую картинку для всех (MCU). Вот и вся классификация, остальное – следствия.

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

Детали на уровне пакетов – как SFU пересылает медиа, как работают слои simulcast и как WebRTC всё это согласует – разобраны в разделе «Видеостриминг»: SFU, MCU и mesh-топологии. Здесь мы говорим о клиническом решении: какая топология подходит для какого приёма и чего каждая стоит в деньгах и в удобстве для пациента.

Peer-to-peer: идеален для двоих, непригоден для троих

В peer-to-peer (при числе участников больше двух это называют полным mesh) каждое устройство отправляет свой поток напрямую каждому другому, без сервера посередине. Сигнальный сервер по-прежнему помогает браузерам найти друг друга в начале, но, как только пошло медиа, больше в нём не участвует. Как мы писали в статье WebRTC для телемедицины, даже «прямое» соединение часто идёт через TURN-реле, если файрвол блокирует прямой путь. Но реле просто пересылает байты, не заглядывая в них, так что топология остаётся peer-to-peer.

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

Потом подключается третий участник, и расчёт перестаёт сходиться. В mesh каждый должен отправлять отдельную копию своего видео каждому другому. Посчитаем исходящий трафик для обычного потока 720p около 1,5 Мбит/с:

2 человека: каждый шлёт 1 копию  → 1 × 1,5 = 1,5 Мбит/с   – комфортно
3 человека: каждый шлёт 2 копии → 2 × 1,5 = 3,0 Мбит/с   – тяжело для домашнего канала
4 человека: каждый шлёт 3 копии → 3 × 1,5 = 4,5 Мбит/с   – выше многих тарифов; телефоны снижают качество
5 человек:  каждый шлёт 4 копии → 4 × 1,5 = 6,0 Мбит/с   – не тянет большинство домашних сетей

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

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

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

SFU: рабочая лошадка клинического видео

SFU (Selective Forwarding Unit, сервер избирательной пересылки) стоит посередине звонка и пересылает потоки, не изменяя их. Каждый участник отправляет свой поток на сервер один раз, а сервер рассылает копии остальным. «Избирательность» в том, что сервер для каждого получателя решает, какие потоки и в каком качестве отправлять: пациент на слабом телефоне получает уменьшенные версии, а врач на оптоволокне – полное качество.

Для дефицитного исходящего канала это решает всё. Исходящий поток каждого остаётся постоянным – 1,5 Мбит/с, – сколько бы людей ни было в сессии. Телефон пациента кодирует видео с камеры один раз и отправляет один раз, хоть в звонке трое, хоть тринадцать. Всё копирование ложится на трафик сервера – статью расходов, которую можно спрогнозировать и оплатить, – а не на канал и батарею пациента, которые купить нельзя.

Поэтому SFU – вариант по умолчанию практически для любой клинической сессии с несколькими участниками:

• Групповые занятия. Группы психологической поддержки, школы для пациентов с хроническими заболеваниями, групповая реабилитация – сессия на восемь-двенадцать участников возможна только на SFU. Инструментам ведущего – раскладке модератора, подсветке активного говорящего, отключению микрофона или удалению участника – нужно, чтобы сервер видел каждый поток отдельно. SFU это сохраняет, а MCU – нет. Где проходит граница между психологической и медицинской помощью и что разрешено дистанционно в психотерапии и психиатрии – в статье о телемедицине ментального здоровья.
• Приёмы с родственниками и законным представителем. Взрослые дети, которые подключаются к приёму пожилого родителя из другого города, – это уже звонок на троих, за пределами возможностей mesh.
• Консультации «врач – врач» и консилиумы. Порядок телемедицины выделяет этот режим отдельно: его результат – медицинское заключение или протокол консилиума (193н, п. 2–3) [7]. Когда в звонке специалист федерального центра, лечащий врач и заведующий отделением, каждого нужно видеть отдельно и управлять каждым независимо.
• Приёмы с переводчиком. Переводчику нужны собственный аудиоканал и собственное окно видео; как устроены роли и права поверх SFU, разобрано в статье о многосторонних консультациях.

Кроме того, SFU передаёт видео каждого участника отдельной дорожкой, поэтому раскладку определяет экран каждого зрителя, а не «вшитая» в поток картинка. Врач может закрепить лицо пациента, переключиться на сетку для группы или скрыть собственное превью, и серверу для этого ничего не нужно делать. Эта гибкость полезна в клинике и принципиально отличает SFU от MCU.

Расходы есть, но умеренные и предсказуемые. По опубликованным инфраструктурным бенчмаркам, SFU на порядка 100 одновременных участников обходится примерно в 26–43 тыс. ₽ в месяц за серверный трафик, без тяжёлой обработки на сервере [1] (пересчёт по курсу; в российском облаке сверяйтесь с прайсом провайдера). Но звонок больше не peer-to-peer: SFU – сервер на пути медиа, а значит, он находится внутри границы медданных. Если им управляет вендор, сервер стоит в России, а вендор работает по поручению обработки ПДн (ст. 6 ч. 3 152-ФЗ) [5]. Если сервер ваш, он размещается в вашем защищённом контуре в российском облаке, с журналами аудита и контролем доступа.

MCU: мощно, дорого и нужно редко

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

Ради этого единственного выходного потока MCU и существует. Он решает две конкретные задачи, с которыми SFU не справляется:

• Слабое или устаревшее устройство. Устройство, способное декодировать лишь один видеопоток – старый планшет в регистратуре, видеотележка в палате, ТВ-приставка или интеграция с устаревшим оборудованием больничной видеоконференцсвязи, – не справится с четырьмя или восемью отдельными потоками от SFU. MCU заранее сводит всё в один поток, который устройство сможет воспроизвести. Если продукт должен работать на парке дешёвых или стационарных устройств, это аргумент за MCU.
• Одна общая запись. Когда нужен один аккуратный видеофайл всей сессии – сеткой, все в одном кадре, готовый для архива или разбора, – MCU создаёт его сам, потому что картинка уже сведена. SFU пишет каждую дорожку отдельно, и чтобы получить такой же общий файл, нужен отдельный шаг сведения. (Многие платформы записывают сессии отдельным серверным рекордером, а не полноценным MCU; архитектуру разбирает статья запись клинических сессий, а конфликт с шифрованием – статья сквозное шифрование в телемедицине.)

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

Платить за эту мощь приходится дорого. Декодирование, сведение и повторное кодирование видео в реальном времени сильно нагружают процессор, и MCU делает это непрерывно для каждой сессии. Поэтому по CPU он обходится намного дороже SFU, который ничего не декодирует и не перекодирует, а только пересылает [1][4]. По опубликованным бенчмаркам, развёртывание со сведённым потоком вещательного качества стоит примерно 170–430 тыс. ₽ в месяц против 26–43 тыс. ₽ у SFU при сопоставимой нагрузке. Одна компания сообщала об экономии порядка 17 млн ₽ в год после перехода от схемы «MCU везде» к гибриду, где MCU остался только там, где он действительно нужен [1] (суммы – пересчёт по курсу, порядок величин, а не котировки). Кроме того, лишний цикл «декодирование – сведение – кодирование» добавляет от десятков до пары сотен миллисекунд задержки и лишает участников гибкой раскладки: каждый зритель получает одну и ту же «вшитую» сетку.

Разбор на примерах: три реальные телемедицинские сессии

Применим модель к трём типичным сессиям телемедицинского продукта.

Плановая консультация по коррекции лечения – один пациент, один лечащий врач, десять минут, без записи, с телефона пациента; диагноз поставлен и лечение назначено на очном приёме, как требует порядок телемедицины (193н, п. 38–39) [7]. Peer-to-peer – хрестоматийный выбор: минимальная задержка, никаких затрат на сервер, медиа не проходит через вашу инфраструктуру. На практике многие платформы всё равно пускают такие звонки через свой SFU ради наблюдаемости, но с точки зрения топологии для двоих peer-to-peer вполне обоснован.

Групповое занятие – один ведущий и девять участников, пятьдесят минут, с режимом активного говорящего и возможностью выключить микрофон участнику. Mesh невозможен: при десяти людях каждый телефон должен отправлять девять копий, около 13,5 Мбит/с исходящего трафика, а такого не выдержит ни одна домашняя сеть. MCU справился бы, но свёл бы всех в одну сетку, и ведущий потерял бы контроль над отдельными участниками. Очевидный выбор – SFU.

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

Одному продукту нужны разные топологии для разных сессий. Зрелые телемедицинские платформы используют гибрид: SFU по умолчанию для многосторонних консультаций, peer-to-peer (или тот же SFU) для 1:1, а MCU или отдельный сводящий рекордер – только для сессий, которым действительно нужен один общий поток. Решение принимается для каждого типа сессии, а не для платформы целиком.

Три топологии в одной таблице

Табл. 1. Выбор топологии в одной таблице. Больше двух участников – mesh отпадает; стоимость MCU оправдывают только ограничения устройства или требование общей записи. Каждый сервер на пути медиа обрабатывает видео пациента – сведения о здоровье, специальную категорию ПДн, – поэтому стоит в России и работает либо по поручению клиники, либо в вашем защищённом контуре. Суммы – пересчёт опубликованных бенчмарков по курсу, порядок величин.

Отдельно о последней строке – её команды пропускают чаще всего. Видит ли сервер медиа в открытом виде или только пересылает зашифрованные пакеты, для здравоохранения правильно исходить из консервативного прочтения: любой сервер на пути медиа находится внутри границы медданных. 152-ФЗ называет обработкой любое действие с персональными данными, включая запись, хранение и передачу [6]. К тому же в стандартной схеме WebRTC шифрование идёт по участкам: SFU расшифровывает медиа на входе и заново шифрует для каждого получателя. С MCU всё ещё строже: он декодирует и заново кодирует видео, поэтому медиа неизбежно оказывается в памяти в открытом виде, и настоящее сквозное шифрование невозможно. Обоим серверам нужно поручение обработки, если ими управляет вендор, и размещение в России в любом случае: для записей и баз этого требует ст. 18 ч. 5 152-ФЗ, а сервер за рубежом означал бы трансграничную передачу специальной категории ПДн (ст. 12) [6]. Если продукту для психиатрии или психотерапии нужно сквозное шифрование, MCU отпадает сразу.

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

Как топология связана с выбором «своё или готовое»

SFU или MCU с нуля пишут редко. На практике выбирают между тем, чтобы развернуть open-source медиасервер самостоятельно, и готовым видео-SDK вендора; это решение разбирает статья свой видеослой или CPaaS. Топология – одно из исходных условий для него.

Open-source SFU – mediasoup, Janus, LiveKit, Jitsi – дают полный контроль и минимальную стоимость минуты на больших объёмах, но серверы в российском облаке вы держите сами и сами отвечаете за меры защиты вокруг них. Готовые решения обслуживают SFU (а если предлагают – то и сведение или запись) за вас, и топология в основном скрыта за их API. Но две вещи нужно проверить обязательно: где физически обрабатываются медиа и хранятся записи и подпишет ли вендор поручение обработки – ведь его сервер обрабатывает данные пациентов. Зарубежные видео-API для медданных российских пациентов отпадают сразу: медиа и записи уходят за рубеж, а это противоречит требованию о локализации и означает трансграничную передачу спецкатегории ПДн [6]. Доступные в России варианты различаются моделью, а не только ценой:

Табл. 2. Доступные в России варианты по открытой документации вендоров (октябрь 2026). Мы сознательно не утверждаем, кто из вендоров подписывает поручение и где именно хранит записи: получите письменное подтверждение до запуска. Сравнение стоимости на больших объёмах – в статье свой видеослой или CPaaS.

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

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

Фора Софт с 2005 года разрабатывает видео в реальном времени – конференции, стриминг, видеонаблюдение, e-learning и телемедицину, – и вопрос топологии мы решаем на каждом проекте, обычно в пользу гибрида. В телемедицине порядок такой: сначала требования регуляторов – каждый медиасервер, SFU или MCU, мы размещаем внутри границы медданных, в российском контуре, по поручению или в собственной инфраструктуре клиента. Затем подбираем топологию под тип сессии, чтобы консультация 1:1 оставалась дешёвой, а групповая сессия на десять человек – надёжной. Мы строили и на open-source SFU, и на готовых SDK; правильный выбор зависит от вашего масштаба, требований к записи и самого слабого устройства, которое нужно поддержать. Если хотите до начала разработки разложить свои сессии по топологиям и стоимости, поговорите с нашей телемедицинской командой.

Главное

• Топологий три: peer-to-peer, SFU (пересылает потоки), MCU (сводит в один поток).
• Peer-to-peer хорош только для 1:1: исходящий трафик растёт с каждым участником, и после двух-трёх участников звонок разваливается.
• SFU – стандарт для многостороннего клинического видео: постоянный исходящий поток, управление каждым участником, умеренная цена.
• MCU намного дороже и оправдан только для слабых или устаревших устройств либо ради одной общей записи.
• Выбирайте топологию для каждого типа сессии, а не для платформы целиком: зрелые продукты сочетают все три.
• Любой медиасервер находится внутри границы медданных: он стоит в России, и либо вендор работает по поручению, либо сервер ваш.

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

• WebRTC для телемедицины: почему это стандарт и его клинические подводные камни
• Свой или CPaaS: строить видеослой на mediasoup/Janus/LiveKit или взять готовое решение
• Многосторонние и многоролевые консультации: переводчики, специалисты, опекуны