WebRTC для телемедицины: почему это стандарт и его клинические подводные камни

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

Кратко

WebRTC стал стандартом телемедицины по двум причинам. Он запускает шифрованный видеозвонок прямо в браузере пациента – без скачивания и плагинов, с задержкой меньше секунды. И это бесплатный открытый стандарт (рекомендация W3C, протокольная часть – в RFC 8825–8829 IETF), который уже реализован во всех крупных браузерах и видео-SDK. Шифрование встроено и обязательно (DTLS-SRTP), но само по себе ещё не означает соответствия 152-ФЗ: вокруг звонка по-прежнему нужны остальные меры защиты по ПП 1119 и приказу ФСТЭК № 21, серверы в России, поручение обработки с каждым подрядчиком и вход пациента через ЕСИА. Подводные камни в клинике операционные, а не теоретические. 5–20% сессий соединяются только через реле-сервер TURN, который нужно заложить в бюджет и держать внутри границы медданных. Закрытые больничные сети блокируют основной путь протокола. Для записи нужна архитектура, которой в WebRTC из коробки нет. А peer-to-peer перестаёт работать, как только подключается третий участник. Ниже каждый камень разобран с расчётами – чтобы оценить разработку телемедицинской платформы до первого спринта, а не после сорванного пилота.

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

Если вы основатель, продакт-менеджер или ИТ-руководитель клиники и оцениваете телемедицинский проект, фраза «возьмём WebRTC» прозвучит на первой же технической встрече – и это правильный выбор. Но за ней стоит всё, что окружает стандарт: реле-серверы, поведение реальных клинических сетей, отсутствие встроенной записи и момент, когда peer-to-peer незаметно становится неверной архитектурой. Месяцы в телемедицинских проектах уходят именно на эти четыре пункта, а не на сам видеозвонок. Эта статья открывает архитектурный блок курса: прочитайте её первой, а потом переходите к отдельным темам. В конце вы будете знать, какие вопросы задать вендору или команде, чтобы понять, строили ли они клиническое видео раньше.

Что такое WebRTC простыми словами

Видеозвонку нужны три вещи: захватить камеру и микрофон, доставить звук и картинку собеседнику с минимальной задержкой и сделать всё это безопасно. Примерно до 2012 года для этого приходилось что-то устанавливать – десктопное приложение или браузерный плагин вроде Flash. Эпоха плагинов окончательно закончилась, когда Adobe отключила Flash в конце 2020 года [11].

На смену пришла технология Web Real-Time Communication, или WebRTC: набор встроенных в браузер возможностей, с которыми веб-страница может захватывать звук и видео и передавать их на другое устройство в реальном времени. Представьте телефонную линию прямо во вкладке браузера: открытая страница и есть приложение для звонка, устанавливать ничего не нужно.

Дальше важны две детали. Первая: WebRTC – открытый стандарт, а не продукт. Браузерная часть – рекомендация W3C: главный орган стандартизации веба опубликовал её в январе 2021 года и продолжает поддерживать, актуальная редакция датирована мартом 2025-го [1]. Сетевую часть описывает IETF – организация, которая стандартизирует интернет-протоколы, – в RFC 8825 и сопутствующих документах [2]. Лицензию на WebRTC никто не выдаёт и отозвать её никто не может. Для продукта, который проживёт лет десять и всё это время будет проходить проверки, это ровно то, что нужно.

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

Устройство самого протокола – обмен описаниями сессий, сбор кандидатов, что SFU делает с каждым пакетом – разобрано в разделе «Видеостриминг»: начните со статьи WebRTC без зауми. Здесь речь о клиническом применении.

Почему WebRTC победил в клиническом видео

У WebRTC четыре свойства, и каждое отвечает на конкретное клиническое требование.

1. Пациент ничего не устанавливает

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

WebRTC убирает эти шаги. Пациент нажимает ссылку из SMS или письма, открывается браузер, пациент входит через Госуслуги, браузер задаёт один вопрос – «разрешить доступ к камере и микрофону?» – и визит начинается. Деталь, которую часто упускают: браузеры дают доступ к камере и микрофону только страницам, открытым по HTTPS (правило «безопасного контекста»), так что шифрованное соединение браузер потребует раньше, чем о нём спросит ваш специалист по безопасности [1]. На WebRTC работают и open-source медиасерверы, и готовые видео-SDK: другого API реального времени в браузере просто нет.

Поддержка стандарта практически повсеместна: Chrome и Firefox – с 2013 года, Safari – с 11-й версии в 2017-м, современный Edge – с 2020-го; браузеры на движке Chromium получают её вместе с движком [1][2]. Для пациентской аудитории это значит, что поддерживать нужно браузер, который у пациента уже есть.

2. Задержка меньше секунды: консультация – это разговор

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

Международный союз электросвязи зафиксировал это ещё десятилетия назад в рекомендации ITU-T G.114: задержка в одну сторону до ~150 миллисекунд воспринимается естественно, а больше 400 миллисекунд для живой речи неприемлема [10]. Распишем бюджет. В 150 миллисекунд должны уложиться захват кадра, сжатие, путь по сети, декодирование и вывод на экран:

захват + кодирование ≈ 20–40 мс
путь по сети         ≈ 30–80 мс (внутри страны или региона)
джиттер-буфер + декод + рендер ≈ 30–60 мс
итого                ≈ 80–180 мс в одну сторону

WebRTC спроектирован именно под такой бюджет: задержка «от камеры до экрана» обычно укладывается в 500 миллисекунд, на нормальных сетях – в 200. Протоколы стриминга «один-ко-многим» играют в другой лиге: классический HLS отстаёт от реального времени на 6–30 секунд, его вариант с низкой задержкой – на 2–5 секунд [2]. Врач не может вести осмотр с задержкой в 6 секунд: он даже не может спросить «здесь больно?» и сразу увидеть реакцию. Поэтому ни один серьёзный телемедицинский продукт не передаёт консультации через стриминговый протокол – выбора здесь на самом деле нет.

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

Какое качество нужно разным специальностям и когда дерматологии или телеинсульту «достаточного» уже мало, разбирает статья о качестве и задержке клинического видео.

3. Шифрование обязательно, но это ещё не соответствие требованиям

У WebRTC нет нешифрованного режима. Стандарт требует передавать медиа по SRTP – защищённому варианту транспортного протокола реального времени, – а ключи согласовывать через DTLS, рукопожатие в стиле TLS прямо между конечными точками (RFC 8827; базовые механизмы – RFC 3711 и RFC 5763/5764) [3]. Проще говоря, звук и видео зашифрованы на каждом участке сети, а реализация без шифрования не была бы WebRTC и не работала бы ни с одним браузером.

Это серьёзное преимущество. Видео, на котором пациент рассказывает о симптомах, – сведения о здоровье, то есть специальная категория персональных данных (ст. 10 152-ФЗ), и одновременно врачебная тайна (ст. 13 323-ФЗ). Защищать их нужно с момента, когда поток уходит в сеть. Среди мер, которых требуют ст. 19 152-ФЗ, ПП 1119 и приказ ФСТЭК № 21, есть защита каналов передачи данных, и WebRTC обеспечивает её по умолчанию [4][6][7].

Здесь команды часто переоценивают стандарт. Защита канала – лишь одна группа мер приказа № 21; идентификация и аутентификация, управление доступом, регистрация событий безопасности и контроль целостности целиком реализуются в приложении, которое вы строите вокруг WebRTC [7]. Есть и российская особенность: браузерный WebRTC шифрует не по ГОСТ, и если модель угроз требует нейтрализовать угрозы в канале криптографией, понадобятся сертифицированные ФСБ средства криптозащиты (СКЗИ); это решение фиксируется в модели угроз. Наконец, договор за вас не подпишет ни один протокол. Каждый подрядчик, чьи серверы обрабатывают данные пациентов по заданию клиники, работает по поручению оператора на обработку ПДн (ст. 6 ч. 3 152-ФЗ) – договору с перечнем данных и действий, целями, обязанностью соблюдать конфиденциальность и требованиями к защите. А базы данных с ПДн россиян должны находиться в России (ст. 18 ч. 5) [4][5], как бы надёжно ни были зашифрованы данные при передаче.

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

Порядок оказания телемедицинской помощи (приказ Минздрава 193н) добавляет конкретики: участников консультации идентифицируют через ЕСИА (п. 7), а на сайте или в приложении пациенту сообщают, кто оператор информационной системы и где хранятся материалы (п. 37) [9]. То есть размещение видеослоя становится публичной информацией. За чем ещё следить: 24 июля 2026 года опубликован проект приказа ФСТЭК на замену № 21. В нём есть меры для контейнеров и API, требования к обработчикам и оценка защищённости – до начала обработки, затем раз в три года и после каждого инцидента; на 24.09.2026 проект не подписан [8]. Архитектура на WebRTC закрывает защиту передачи уже по своему устройству, остальное придётся доказывать.

4. Вокруг стандарта – целая экосистема

Стандарты побеждают за счёт сетевого эффекта. WebRTC – единственный API реального времени в браузере, поэтому на нём построены все видео-SDK, его поддерживает каждый SFU (тип медиасервера, на котором работает большинство телемедицинских платформ), а WebRTC-инженер легко переходит с одного стека на другой. Практическое следствие для заказчика: выбор WebRTC не привязывает к вендору. Платформу на готовом видео-SDK можно позже перевести на open-source медиасервер – mediasoup, Janus, LiveKit, Jitsi, – не меняя того, что работает в браузере пациента. Этот сценарий разобран в статье свой видеослой или CPaaS, и он реален именно потому, что в основе лежит общий стандарт. А вендоры уходят: с 20 марта 2024 года крупнейшие зарубежные облака прекратили обслуживать корпоративных клиентов из России [13], и командам, встроившим продукт в чужую инфраструктуру, пришлось срочно переезжать. Открытый стандарт страхует от таких поворотов.

Как консультация подключается на самом деле

Сначала посмотрим на механизм целиком. Когда пациент и врач нажимают «Войти», браузеры обмениваются предложениями соединения через ваш сигналинг-сервер – HTTPS/WebSocket-сервис, который вы держите сами; именно здесь проходит авторизация. Каждый браузер собирает варианты сетевых путей с помощью STUN-сервера, который просто сообщает устройству, как его адрес выглядит снаружи. Процедура ICE (RFC 8445) перебирает пары путей, пока один не заработает, а если не заработал ни один, переключается на TURN-реле. Рукопожатие DTLS устанавливает ключи, и начинает идти шифрованное медиа [2][3]. На хорошей сети вся последовательность занимает 1–3 секунды, поэтому техническая проверка перед звонком проходит в виртуальной приёмной, а не в момент подключения врача.

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

Теперь о четырёх местах, где в клинике начинаются проблемы.

Камень 1. TURN: реле, которое забывают посчитать

Большинство домашних и клинических сетей работает за NAT – функцией роутера, которая позволяет многим устройствам делить один публичный адрес. Два устройства за NAT часто не могут связаться напрямую – как два человека, которые пытаются переписываться, указывая только номер квартиры без адреса дома. STUN решает простые случаи, сообщая устройству его внешний адрес. Для сложных случаев – строгих и симметричных NAT, сетей, которые режут прямой путь, – нужен TURN: реле-сервер с публичным адресом, который пересылает медиа между сторонами. Это своего рода «почта до востребования», через которую идёт звонок, когда прямого маршрута нет (актуальная спецификация – RFC 8656) [2].

Для бюджета важны три факта о TURN.

Первый: без TURN нельзя запускаться. По отраслевым замерам, 5–20% сессий не соединяются напрямую, доля зависит от географии, оператора и строгости сети [12]. Для этих пациентов сервис без TURN просто не работает, причём это именно те сети, которые важны медицине: больницы, клиники, гостевой корпоративный Wi-Fi, мобильные сети с операторским NAT (CGNAT).

Второй: трафик через реле – это гигабайты, за которые платят. Если участник подключён через реле, TURN пересылает каждый пакет звонка в обе стороны. Посчитаем. Типичный поток консультации в 720p – около 1,5 Мбит/с в каждую сторону. За 20 минут в одном направлении передаётся:

1,5 Мбит/с × 60 с × 20 мин = 1 800 мегабит ≈ 225 МБ
обе стороны через реле ≈ 450 МБ на релейную консультацию

Теперь масштаб. Пусть платформа проводит 10 000 консультаций в месяц и 15% из них идёт через реле:

10 000 × 15% = 1 500 релейных консультаций
1 500 × 0,45 ГБ ≈ 675 ГБ релейного трафика в месяц

Для расчёта возьмём ориентир порядка 34 ₽ за гигабайт трафика через управляемый TURN-сервис. Это не тариф конкретного провайдера: сверяйтесь с прайсом своего облака или видеовендора. Получаем 675 × 34 ₽ ≈ 23 тыс. ₽ в месяц – немного. Но в закрытых корпоративных сетях через реле нередко идёт 60–70% звонков, и при 70% те же консультации дают уже 3 150 ГБ и ≈ 110 тыс. ₽ в месяц – только за реле, ещё без медиасервера и записи. Цены у провайдеров различаются в разы, а собственный coturn на виртуальной машине в российском облаке при больших объёмах часто обходится дешевле – но эксплуатировать его придётся вам. Смысл расчёта не в конкретных рублях: «доля реле × минуты × битрейт» – это строка бюджета, которую можно и нужно спрогнозировать при построении модели стоимости, а не обнаружить в первом счёте.

Третий: TURN находится внутри границы медданных. TURN пересылает пакеты, уже зашифрованные DTLS-SRTP, и ключей не хранит, поэтому некоторые считают его просто «трубой». Курс рекомендует более осторожный подход, подробно описанный в статье о паттерне архитектуры комплаенса: любой сервер на пути медиа считается частью контура медданных. Значит, TURN стоит в России и либо принадлежит провайдеру, работающему по поручению, либо развёрнут в вашем защищённом контуре. Типичная ошибка: скопировать в продакшен бесплатные публичные учётные данные TURN/STUN из учебного примера. Тогда консультации пациентов пойдут через сервер неизвестной третьей стороны – возможно, за рубежом, без договора, без поручения и без каких-либо гарантий доступности. Пока прямой путь работает, проблему не видно, и всплывает она через несколько месяцев – как раз у пациентов с самыми плохими сетями.

Камень 2. Больничные сети настроены вас не пропускать

В офисе демо работает. Потом пилот запускают в больнице – и 40% звонков со стороны врача не соединяются или идут через реле с заметной задержкой. Ничего не сломалось: больничная сеть делает ровно то, для чего её настроили.

Клинические сети – одна из самых сложных сред для WebRTC. На внедрениях картина обычно такая: UDP – быстрый транспорт без установки соединения, на котором WebRTC предпочитает передавать медиа, – закрыт целиком, кроме явно разрешённых сервисов; исходящий трафик идёт через прокси или глубокую инспекцию пакетов (DPI); гарантированно открыты только TCP-порты 80 и 443 (веб) [12]. У домашних сетей свои сложности: Wi-Fi гостиниц и общежитий, мобильный CGNAT, роутеры провайдеров с жёсткими настройками.

Инженерное решение – последовательная лестница фолбэков (резервных путей), и платформа должна реализовать её целиком: сначала прямой UDP, затем TURN по UDP, потом TURN по TCP и наконец TURN по TLS на порту 443. В последнем случае медиа упаковано так, что выглядит как обычный защищённый веб-трафик и проходит почти везде (режимы TCP и TLS описаны в RFC 8656) [2]. Каждая ступень вниз добавляет задержку и чувствительность к джиттеру, поэтому это запасные варианты, а не основной путь. Не менее важна организационная часть: со стационарами договаривайтесь с ИТ-службой больницы до запуска – пусть внесут адреса ваших TURN и медиасерверов в список разрешённых, откроют для них UDP и настроят приоритет (QoS) для трафика консультаций. Сетевой тест в виртуальной приёмной, пока пациент ещё успевает переключиться с клинического Wi-Fi на мобильный интернет, превращает фатальные сбои в исправимые. Полный набор приёмов – в статье о надёжности соединения, а механика протокола – в подробном разборе ICE, STUN и TURN из раздела о стриминге.

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

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

Камень 3. Запись: в WebRTC нет кнопки REC

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

Вариантов три, и у каждого свои последствия для защиты данных. Первый – записывать на клиенте, в браузере (API MediaRecorder), и потом выгружать. Это ненадёжно на слабых устройствах и сетях, типичных для телемедицины, а до обработки запись лежит незашифрованной на устройстве пациента или врача. Второй – записывать на сервере: звонок идёт через медиасервер (SFU), который сохраняет потоки в хранилище. Так делают в продакшене, и тогда и сервер, и хранилище оказываются строго внутри границы медданных: в России, с шифрованием при хранении, контролем доступа и журналами событий. Третий – взять функцию записи у готового видео-SDK. Это та же серверная архитектура, только с логотипом вендора, а вопросы локализации и поручения переходят в договор с ним.

Обратите внимание, что незаметно изменилось при серверной записи: звонок больше не peer-to-peer, даже если это консультация 1:1. Отсюда следствия. Площадка медиасервера влияет на задержку и на то, где физически лежат данные. А настоящее сквозное шифрование (когда даже ваши серверы не могут расшифровать медиа) прямо противоречит серверной записи – этот конфликт разбирает статья о сквозном шифровании. У записи есть и юридическая сторона. Порядок 193н не обязывает записывать консультации, но если запись сделана, аудио- и видеозаписи хранятся как сопутствующие материалы консультации 1 год (п. 49–51) [9]; пациента нужно предупредить и получить его согласие, а доступ к записям разграничить. Подробнее – в статье о согласии, записи и хранении, а полная архитектура записи описана в отдельной статье этого блока. Решать, писать ли консультации, нужно в первую неделю: от этого зависят топология, список вендоров и заметная часть требований к защите данных.

Камень 4. P2P работает только для двоих: третий участник меняет архитектуру

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

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

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

Домашние тарифы в хороший день дают 5–10 Мбит/с на отдачу, а каждое лишнее кодирование нагружает процессор и сажает батарею самого слабого устройства в звонке – в телемедицине это обычно устройство пациента. Стандартное решение – SFU (selective forwarding unit, сервер избирательной пересылки): каждый участник отправляет на сервер один поток, а сервер раздаёт копии остальным. Исходящий канал не растёт при любом числе участников, а затраты переходят в серверный трафик, который можно просто купить. Какая топология подходит для какого типа клинической сессии – в статье про P2P, SFU и MCU, а роли, права и каналы переводчика – в статье о многосторонних консультациях.

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

Есть и вторая, менее очевидная причина, по которой в продакшене даже звонки 1:1 пускают через SFU: наблюдаемость и управление. Чистый P2P-звонок почти ничего не даёт команде эксплуатации – ни серверных метрик качества, ни точки записи, ни контроля над маршрутом. SFU даёт телеметрию качества, по которой можно действовать (из неё же пополняются журналы аудита), точку записи там, где есть согласие, и одну архитектуру для 1:1 и групп вместо двух расходящихся веток кода. Платить за это приходится серверным трафиком и парой десятков миллисекунд задержки. Большинство команд, запускавших клиническое видео в масштабе, на это соглашаются, и эталонная архитектура в конце блока исходит из того же.

WebRTC против альтернатив

Основателю не нужно сравнивать WebRTC с другим стеком реального времени для браузера: другого просто нет. Сравнивать имеет смысл со смежными технологиями, которые регулярно всплывают при оценке проекта.

Таблица 2. Смежные технологии и где каждая уместна. Для самой консультации обоснованный вариант один.

Последняя строка таблицы важна: альтернативы не конкурируют с WebRTC, а дополняют его. Зрелая платформа часто проводит консультации по WebRTC, образовательные трансляции – по HLS, а для пациента, у которого видео не идёт даже через TURN поверх TLS, держит аудиорежим в том же приложении (тот же WebRTC, только звук, а идентификация через ЕСИА уже пройдена) и телефонную линию поддержки, чтобы перенести приём. Обычный телефонный звонок консультацию не заменяет: порядок требует идентифицировать участников через ЕСИА (п. 7 193н) [9]. К тому же синхронное видео – лишь один из трёх форматов телемедицины. Спрос растёт в услугах, которые целиком состоят из разговора. По опросу страховщиков, который провёл брокер Remind, в 2025 году телемедициной в ДМС пользовались 25% застрахованных против 12% в 2022-м; типичные форматы в полисах – профилактика, психологи, второе мнение, расшифровка анализов [14].

Что это значит для вашего проекта

Четыре камня вместе дают картину объёма работ. Сам стандарт WebRTC бесплатен и решает самую сложную задачу – шифрованное медиа в реальном времени в любом браузере. Всё остальное – ваш проект: сигналинг с полноценной авторизацией и входом через ЕСИА; STUN/TURN в России, свои или у провайдера по поручению; SFU, как только появляется запись или третий участник; лестница фолбэков для проблемных сетей; слой журналов, согласий и мер защиты, которого требуют 152-ФЗ и порядок 193н. Ничего экзотического, но всё это должно попасть в оценку. По нашему опыту оценки проектов, видимый видеозвонок – примерно пятая часть инженерных трудозатрат на телемедицинскую платформу, а большая часть остальной работы в видеослое приходится как раз на четыре описанных камня. Следующее решение – собирать на готовом видео-SDK или строить на open-source медиасерверах (свой или CPaaS), а модель стоимости переводит его в цифры.

Чтобы превратить всё это в конкретные действия, мы собрали одностраничный чек-лист: пятнадцать проверок по бюджету TURN, проблемным сетям, записи, топологии и границе медданных. Скачайте чек-лист перед стартом WebRTC-телемедицины и пройдитесь по нему со своей архитектурой до первого спринта.

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

Фора Софт с 2005 года разрабатывает продукты с видео в реальном времени – видеоконференции, стриминг, видеонаблюдение, e-learning и телемедицину, – и WebRTC стал нашим рабочим инструментом с момента его появления в браузерах. В телемедицине мы начинаем с требований: проектируем сценарий консультации под 152-ФЗ и 323-ФЗ (TURN и медиасерверы в российском контуре, поручения подрядчикам, журналы аудита, вход через ЕСИА, запись с учётом согласий), а затем добиваемся, чтобы он выдерживал реальные сети – больничные файрволы, мобильный интернет в регионах, устройства пожилых пациентов. Этот порядок – сначала требования регуляторов, затем надёжность, затем функции – лежит в основе всего раздела, потому что так мы работаем на проектах. Если вы оцениваете телемедицинскую платформу и хотите узнать цену подводных камней заранее, поговорите с нашей телемедицинской командой.

Главное

• WebRTC победил в клиническом видео благодаря четырём свойствам: работает без установки, даёт задержку меньше секунды, шифрует медиа в обязательном порядке и опирается на открытую экосистему.
• Шифрование канала встроено, а остальные меры по 152-ФЗ, ПП 1119 и приказу ФСТЭК № 21, локализацию, поручения и ЕСИА придётся обеспечить самим. Браузерный WebRTC шифрует не по ГОСТ, поэтому решение о СКЗИ фиксируйте в модели угроз.
• Закладывайте TURN в бюджет с первого дня: через реле идёт 5–20% сессий, за больничными файрволами – больше. Реле должны стоять в России.
• Стройте лестницу фолбэков вплоть до TURN поверх TLS на порту 443 и тестируйте на проблемных сетях ещё до пилота.
• Решите вопрос записи в первую неделю: она требует серверной архитектуры и тянет за собой дополнительные требования к защите данных.
• P2P работает только для двоих; из-за переводчиков, родственников и консультаций «врач – врач» стандартом становится SFU.

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

• P2P, SFU или MCU: какую топологию выбрать для консультации, групповой сессии и вебинара
• Свой или CPaaS: строить видеослой на mediasoup/Janus/LiveKit или взять готовое решение
• Архитектура комплаенса: как встроить требования 152-ФЗ и 323-ФЗ в видеостек