Свой видеослой или CPaaS: mediasoup, Janus, LiveKit или готовое решение

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

Кратко

Видеослой телемедицинского продукта либо берут готовым, либо строят сами. Готовое – это облачный видео-SDK российского вендора (Voximplant, SaluteJazz SDK), on-prem-сервер вендора (TrueConf) или ВКС-сервис, где встречи по ссылке создаются через API (VK Звонки, Яндекс Телемост). Своё – open-source медиасервер (mediasoup, Janus, LiveKit, Jitsi), развёрнутый в российском облаке. В медицине выбор начинается не с цены и функций, а с данных: любой сервер, через который идут звук и видео пациента, обрабатывает сведения о здоровье – специальную категорию персональных данных и врачебную тайну. Поэтому записи и базы должны быть в России (ст. 18 ч. 5 152-ФЗ), медиасервер за рубежом означал бы трансграничную передачу (ст. 12), вендор работает по поручению оператора (ст. 6), а собственный сервер размещается внутри вашего защищённого контура. Шифрование канала этих требований не снимает, а зарубежные видео-API выпадают из списка сразу. Готовое решение быстрее запускается и дешевле, пока объёмы не стали большими и постоянными. Своё выигрывает в стоимости на больших объёмах, контроле и владении данными, но серверы эксплуатируете и за меры защиты отвечаете вы. В статье – сравнение, которое начинается с данных, точка, где поминутная оплата становится дороже фиксированных затрат (с расчётом в рублях), ловушка open-source лицензий, опасная для закрытого продукта, и матрица решения под ваши планы развития.

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

Видеослой – самое дорогое и наименее обратимое техническое решение в разработке телемедицинского продукта. От него зависят ежемесячный счёт за инфраструктуру, выполнение требований 152-ФЗ, срок до первого звонка с пациентом и размер команды поддержки. Возьмёте готовый SDK – покажете рабочую консультацию за несколько дней, но окажетесь зависимы от цен, планов и судьбы продукта вендора (российский рынок прочувствовал это в 2022–2024 годах, когда зарубежные сервисы и облака уходили из страны). Развернёте open-source сервер – получите полный контроль, но фактически придётся содержать команду по инфраструктуре реального времени, а медиа пациентов окажется внутри вашего контура. Статья поможет основателю, продакт-менеджеру или ИТ-руководителю клиники принять решение осознанно в первую неделю, сразу учитывая требования к данным, стоимость и риск вендора, а не узнавать о последствиях из первого счёта за облако или первой проверки.

В чём на самом деле выбор

Видеокодек или SFU с нуля почти никто не пишет. Как объясняется в статье о топологиях, любой групповой клинический звонок идёт через Selective Forwarding Unit (SFU) – сервер, который принимает звук и видео каждого участника один раз и пересылает копии всем остальным. Поэтому настоящий вопрос уже: вы сами запускаете SFU на open-source софте или берёте его у вендора, который скрывает сервер за API?

Договоримся о терминах. CPaaS (Communications Platform as a Service) – платный сервис, который обслуживает медиасерверы, TURN-реле и клиентские SDK за вас: вы вызываете его API и не прикасаетесь к серверу. В России «готовое» бывает трёх видов, и разница между ними существенна: облачный SDK (Voximplant, SaluteJazz SDK) – медиа идёт через площадку вендора; on-prem-сервер вендора (TrueConf Server с VideoSDK) – медиа остаётся в вашем контуре, но код и планы развития чужие; ВКС по ссылке (API VK Звонков и Яндекс Телемоста) – API создаёт встречу, а пациент переходит во внешний клиент. Open-source медиасервер – mediasoup, Janus, LiveKit или Jitsi – бесплатный софт, который вы запускаете на арендованных в российском облаке машинах. «Купить» – значит взять готовое решение, «строить» – развернуть свой open-source сервер. Дальше сравниваются именно эти два пути.

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

Сначала – фильтр данных

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

Главное правило такое. Сведения о здоровье – специальная категория персональных данных (ст. 10 152-ФЗ), а сведения о факте обращения и состоянии здоровья – врачебная тайна (ст. 13 323-ФЗ) [1][3]. Живая видеоконсультация – это такие данные в движении: лицо и голос пациента и всё, что сказано на приёме. Обработкой 152-ФЗ называет любое действие с персональными данными, включая запись, хранение и передачу (ст. 3) [1]. Тот, кто обрабатывает их по заданию клиники-оператора, работает по поручению – договору, где перечислены данные и действия с ними, цели, обязанность соблюдать конфиденциальность и требования к защите по ст. 19 (ст. 6 ч. 3) [2]. Записывать, систематизировать и хранить ПДн россиян нужно в базах данных в России (ст. 18 ч. 5), а с 1 июля 2025 года вести эти операции в зарубежных базах прямо запрещено [1][4]. Передача же медиа через сервер за рубежом – трансграничная передача специальной категории (ст. 12).

Частая ошибка – аргумент: «Видеосервер всего лишь пересылает зашифрованные пакеты, значит, это нейтральная труба, и поручение ему не нужно». Строить на этом архитектуру рискованно. Во-первых, определение обработки в 152-ФЗ прямо включает передачу. Во-вторых, в стандартной схеме WebRTC шифрование идёт по участкам: SFU расшифровывает медиа на входе и заново шифрует для каждого получателя, а нередко ещё и записывает сессию. Курс придерживается консервативного прочтения: медиасервер вендора обрабатывает данные по поручению, а не служит простой трубой.

Отсюда два вывода, по одному на каждый путь:

• Если вы берёте готовое, вендор становится обработчиком по поручению. До того как в звонок войдёт первый реальный пациент, нужно письменно подтвердить три вещи: где физически обрабатываются медиа и хранятся записи (в России ли), готов ли вендор работать по поручению с нужным содержанием и – если ваша платформа сама обработчик клиники – допускает ли поручение клиники передоверие. Как выстроить эту цепочку договоров, разбирает статья о поручении обработки ПДн. Зарубежный видео-API отпадает сразу: медиа и записи уйдут за рубеж, а это противоречит требованию о локализации и означает трансграничную передачу специальной категории ПДн (ст. 12) [1]. К тому же заключить договор с таким сервисом и платить ему из России само по себе непросто. Поэтому вопрос «где медиа и записи и подпишет ли вендор поручение?» – первый фильтр при отборе, раньше цены и функций.
• Если вы строите, поручение вендору медиасервера не нужно, потому что третьей стороны нет, – но SFU теперь находится внутри вашей границы. Все меры вокруг него на вас: управление доступом, журналы аудита, защита каналов, шифрование при хранении – по ПП 1119 и приказу ФСТЭК № 21 для вашего уровня защищённости [5][6]. Браузерный WebRTC шифрует не по ГОСТ, поэтому решение о сертифицированных СКЗИ фиксируется в модели угроз. И всё равно нужен договор с облачным провайдером с условиями обработки ПДн: российские провайдеры – Yandex Cloud, Cloud.ru, Selectel, MWS – предлагают аттестованные сегменты для УЗ-1 [7], но аттестат покрывает инфраструктуру провайдера, а не ваше приложение.

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

Как привести весь видеостек в соответствие требованиям независимо от выбранного пути, разобрано в статье о паттерне архитектуры комплаенса, а детали шифрования, ГОСТ и СКЗИ – в статье о шифровании для телемедицины.

Купить: готовые видео-SDK и API в России

Купить – значит, вендор обслуживает SFU, TURN-реле, инфраструктуру записи и клиентские SDK, а вы работаете со всем этим через API. Рабочая консультация появляется за дни, а не месяцы, и никто не будит вас в 2 часа ночи из-за упавшего медиасервера. Взамен вы регулярно платите за объём, зависите от планов вендора, а медиа пациентов идёт через инфраструктуру, которую вы не контролируете.

Первый вопрос к каждому вендору: где обрабатываются медиа и хранятся записи, подпишет ли он поручение, на каком тарифе и за какую цену? Таблица ниже составлена по открытой документации на октябрь 2026 года. Колонка «Что подтвердить» – обязательное условие допуска: если вендор не подтверждает размещение в России и работу по поручению, он не подходит для клинического применения, каким бы хорошим ни был SDK.

Таблица 1. Готовые решения для видеослоя, доступные в России, октябрь 2026. Колонка «Что подтвердить» – первый фильтр в любом телемедицинском проекте. Мы сознательно не утверждаем, кто из вендоров подписывает поручение, где именно хранит записи и сколько стоит: тарифы сверяйте с прайсом и коммерческим предложением вендора и подтверждайте всё письменно до принятия решения.

Две истории стоит разобрать подробнее: они показывают два способа обжечься на покупке.

Уход зарубежных сервисов: риск вендора. С 20 марта 2024 года крупнейшие зарубежные облака прекратили обслуживать корпоративных клиентов из России [13], а до этого рынок покинули и другие западные сервисы. Командам, которые встроили весь продукт в чужой SDK или чужую инфраструктуру, пришлось срочно мигрировать. С российским вендором этот конкретный риск ниже, но общий урок остаётся: планы, цены и судьбу продукта контролирует вендор, и решение о закрытии или смене тарифа может ударить по продукту, который быстро не заменишь. Слой абстракции, позволяющий сменить видеовендора, заметно снижает этот риск.

ВКС по ссылке: видеозвонок – ещё не телемедконсультация. Отправить пациенту ссылку на встречу в VK Звонках или Телемосте технически просто: API создаст встречу, а VK Звонки ещё и автоматически включат запись. Но консультацию в смысле порядка телемедицины делает не видеоканал, а всё, что вокруг него: идентификация участников через ЕСИА (п. 7 приказа 193н), врач и организация в ФРМР и ФРМО (п. 9), раскрытие пациенту оператора информационной системы и места хранения материалов (п. 37), хранение записей как сопутствующих материалов 1 год (п. 49–51) [14]. Модель со ссылками оставляет всё это на вашей стороне и добавляет вопрос, где лежат записи и кто их оператор. «Мы на известной ВКС, значит, всё по закону» – именно такая расплывчатая позиция и проваливает проверку. Соответствие требованиям – свойство правильно настроенной системы с оформленными поручениями, а не бренда.

Строить: open-source медиасерверы

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

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

Таблица 2. Open-source SFU и их лицензии. Лицензия – юридический вопрос того же уровня, что и требования к данным: GPLv3 (Janus) может обязать раскрыть исходники производного продукта, если не купить коммерческую лицензию, а ISC (mediasoup) и Apache 2.0 (LiveKit, Jitsi) такого обязательства на закрытый продукт не накладывают. Сверьте актуальную лицензию и свой случай с юристом.

Коротко о каждом – с точки зрения клинического проекта, без протокольных подробностей; инженерное сравнение SFU есть в разделе «Видеостриминг»: полный разбор mediasoup/Janus/LiveKit/Jitsi/Pion.

mediasoup – SFU под лицензией ISC; это скорее низкоуровневый строительный блок, чем готовый сервер. Он даёт тонкий контроль и высокую производительность, а пермиссивная лицензия [15] не накладывает обязательств на закрытый продукт, но сигналинг, масштабирование и запись придётся собирать самим. Подходит команде с опытом в видео реального времени, которая хочет сама определять архитектуру.

Janus – зрелый шлюз от Meetecho, написанный на C и построенный на плагинах. Его слабое место – лицензия: Janus распространяется под GPLv3 [16], copyleft-лицензией, которая может требовать опубликовать исходники производных работ. Для закрытого телемедицинского продукта это реальный риск, поэтому Meetecho продаёт и коммерческую лицензию для команд, которым GPL не подходит [16]. Технически сервер сильный, но лицензию прочитайте до того, как на нём остановиться.

LiveKit – самый молодой из четырёх и даёт больше всего готового: SDK, масштабирование и запись включены, лицензия – пермиссивная Apache 2.0 [17]. С ним проще всего начать команде без глубокого опыта в WebRTC. У LiveKit есть и облачный управляемый вариант, но это зарубежный сервис, и для медданных российских пациентов он не подходит по той же причине – из-за локализации. В России LiveKit разворачивают только на своих серверах.

Jitsi – это Videobridge (SFU) и готовый веб-клиент Jitsi Meet; Videobridge распространяется под Apache 2.0 [18]. Хорош, когда нужна полноценная ВКС, которую можно доработать под клинический сценарий, а не набор кубиков; цена – меньшая гибкость в низкоуровневой архитектуре.

Какой бы сервер вы ни выбрали, схема одна: SFU внутри вашего защищённого контура в российском облаке, медиа в канале зашифровано стандартным для WebRTC DTLS-SRTP, записи зашифрованы при хранении вашими ключами, а вокруг – меры по ПП 1119 и приказу ФСТЭК № 21: контроль доступа, журналы событий, решение о СКЗИ в модели угроз [5][6].

Точка перелома: поминутная оплата против фиксированных затрат

Главное число в этом решении – объём, при котором покупка перестаёт быть дешевле собственного сервера. Затраты на двух путях устроены принципиально по-разному.

Готовый видео-API обычно берёт плату за объём – за минуту-участника или пакетами минут. Публичные прайсы российских вендоров мы здесь не приводим: часть цен сообщают только через отдел продаж, и они меняются. Поэтому для расчёта возьмём условную ставку ≈ 0,34 ₽ за минуту-участника – ориентир порядка величины, а не тариф конкретного провайдера; подставьте цену из своего коммерческого предложения. Нет звонков – нет платы, а дальше затраты растут линейно, без простаивающих серверов.

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

Посчитаем покупку для средней платформы: 50 000 консультаций в месяц по 20 минут, по два участника на звонок (пациент и врач):

минуты-участники = консультации × минуты × участники
                 = 50 000 × 20 × 2
                 = 2 000 000 минут-участников / месяц

стоимость CPaaS = минуты-участники × 0,34 ₽
                = 2 000 000 × 0,34 ₽
                = 680 000 ₽ / месяц

На таком объёме покупка выгодна: 680 тыс. ₽ в месяц, и команда по инфраструктуре не нужна. Теперь возьмём загруженную федеральную платформу на 500 000 консультаций в месяц – в десять раз больше:

минуты-участники = 500 000 × 20 × 2 = 20 000 000 / месяц
стоимость CPaaS  = 20 000 000 × 0,34 ₽ = 6 800 000 ₽ / месяц  ≈  82 млн ₽ / год

Больше 80 млн ₽ в год, и счёт растёт с каждым новым пациентом. Свой SFU при такой одновременной нагрузке обойдётся в несколько сотен тысяч рублей в месяц за облачные мощности плюс небольшая команда по инфраструктуре – скажем, 2,6–5,1 млн ₽ в месяц вместе с зарплатами (для ориентира: медиана зарплаты senior-разработчика по данным Хабр Карьеры – 304 тыс. ₽ на руки в месяц [19]). Если команда и серверы обходятся в эти 2,6–5,1 млн ₽, линии пересекаются на 7,6–15 млн минут-участников в месяц – это примерно 190–375 тыс. консультаций по 20 минут вдвоём. Ниже этой точки дешевле покупка, потому что вы не платите инженерам; выше – собственный сервер, потому что ваши затраты перестают расти вместе с использованием. При меньшем объёме и серверов нужно меньше, поэтому на практике перелом наступает чуть раньше. Точное значение зависит от зарплат, нагрузки и цены вендора, но картина везде одна.

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

Ошибка – сравнивать пути только по цене минуты. «0 ₽ за минуту» у своего SFU не учитывает зарплаты, а «копейки за минуту» у покупки – то, как быстро они складываются на больших объёмах. До выбора наложите свой прогноз объёма на обе модели затрат; в упрощённом виде это делает лист сравнения, который можно скачать ниже.

Четыре оси помимо стоимости

В большинстве случаев всё решают стоимость и требования к данным. Если же варианты близки, помогут ещё четыре оси сравнения.

Скорость запуска. Здесь безоговорочно выигрывает покупка. С готовым SDK рабочая консультация появляется за дни; собственный промышленный SFU с автомасштабированием в нескольких зонах доступности – инженерный проект на несколько месяцев. Для MVP, который торопится к пилоту, часто решает одна эта ось.

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

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

Риск вендора и его планов. Выигрывает свой сервер. Open-source код у вас никто не отнимет; уход зарубежных сервисов из России [13] – классический пример риска, который вы принимаете при покупке. Тонкий слой абстракции над видеовендором – сознательная страховка именно от этого, а on-prem-сервер вендора – компромисс: данные у вас, но код и обновления чужие.

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

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

Применим модель к двум типичным командам.

Стартап на ранней стадии с MVP: один пациент и один врач на звонок, несколько тысяч консультаций в месяц, команда из четырёх инженеров и пилот через девяносто дней. Вердикт – однозначно купить. При пяти тысячах консультаций счёт по условной ставке – около 68 тыс. ₽ в месяц, главное ограничение – срок запуска, а свободных рук на эксплуатацию медиасервера у команды нет. Возьмите вендора, который письменно подтвердит размещение медиа и записей в России и работу по поручению на доступном тарифе, – облачный SDK вроде Voximplant или SaluteJazz SDK, – и оберните SDK тонким слоем абстракции, чтобы потом его можно было сменить. Тратить здесь три месяца на свой SFU – хрестоматийная преждевременная оптимизация.

Крупная федеральная платформа: групповые занятия и поток консультаций – 500 000+ в месяц, клиники-заказчики строго требуют держать медиа пациентов в контролируемой инфраструктуре, своя команда по видео реального времени уже есть. Вердикт склоняется к строить или к гибриду. На таком объёме счёт за CPaaS превышает 80 млн ₽ в год и растёт с каждым пациентом, требования к данным говорят держать медиа у себя, а команда способна эксплуатировать серверы. Свой LiveKit или mediasoup в аттестованном сегменте российского облака ограничивает расходы и оставляет данные под контролем платформы: SFU находится внутри её границы медданных, а под ним – договор с облачным провайдером. Промежуточный вариант для заказчиков с закрытым контуром – on-prem-сервер вендора.

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

Типичная ошибка: выбирать видеослой только по цене минуты или списку функций, а про данные вспомнить позже. Чаще всего встречаются три ловушки. Первая – решить, что «зашифровано» значит «законно»: сервер за рубежом или вендор без поручения – нарушение при любом шифровании. Вторая – строить закрытый продукт на Janus под GPLv3, не прочитав лицензию и не купив коммерческую. Третья – выбрать поминутный тариф, не смоделировав нагрузку, и потом смотреть, как счёт на больших объёмах переваливает за 80 млн ₽ в год. Проверьте данные, лицензию и модель стоимости до того, как влюбитесь в SDK.

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

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

Чтобы решение можно было повторить, мы свели его на одну страницу: фильтр данных, проверка open-source лицензии, модель «поминутно или фиксированно» и четыре оси сравнения. Скачайте лист сравнения «свой видеослой или CPaaS» и пройдитесь по нему с учётом своих планов, прежде чем принимать решение.

Главное

• Выбор видеослоя – это выбор между готовым решением (облачный SDK, on-prem-сервер вендора, ВКС по ссылке) и собственным open-source SFU в российском облаке.
• Данные – первый фильтр: любой медиасервер обрабатывает сведения о здоровье, поэтому он стоит в России, а вендор работает по поручению; свой сервер размещается в вашем защищённом контуре.
• Шифрование канала не снимает требований к локализации и поручению; зарубежные видео-API для медданных отпадают сразу.
• Готовое быстрее запускается и дешевле, пока объёмы не стали большими и постоянными; своё выигрывает в стоимости на больших объёмах, контроле и владении данными.
• Поминутная оплата растёт линейно, а свой SFU – это фиксированные затраты плюс зарплаты: при условных ценах перелом наступает около 7,6–15 млн минут-участников в месяц. Посчитайте для своих цифр.
• Проверьте open-source лицензию: Janus – GPLv3 (copyleft); mediasoup (ISC), LiveKit и Jitsi (Apache 2.0) – пермиссивные.

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

• P2P, SFU или MCU: какую топологию выбрать для консультации, групповой сессии и вебинара
• Поручение обработки ПДн и договоры с подрядчиками: контракт, на котором держится весь стек
• Архитектура комплаенса: как встроить требования 152-ФЗ и 323-ФЗ в видеостек