WHIP и WHEP: замена RTMP в вашем стеке стриминга (2026)

Почему Фора Софт пишет этот плейбук

Фора Софт с 2005 года выпустила более 625 проектов, и около 200 из них связаны с живым или интерактивным видео. В их числе — StreamLayer (интерактивный спортивный стриминг, который используют NBC, CBS, Red Bull, Chelsea FC и Sony Music), EyeBuild (видеонаблюдение на солнечных батареях с ИИ и приёмом по 4G/5G), WorldCastLive, Mangomolo и Tradecaster.

За последние двенадцать месяцев мы перевели четыре продакшен-стека с RTMP на WHIP/WHEP. Среди них — спортивный вещатель, у которого сквозная задержка упала с 6,2 с до 380 мс, и платформа для онлайн-мероприятий, где хрупкая цепочка RTMP→HLS→LL-HLS заменена единым уровнем mediasoup. Цифры, решения и компромиссы в этой статье взяты из тех проектов, а не из вендорских буклетов.

Если ваш энкодер по-прежнему отправляет RTMP, а зрители всё ещё мирятся с задержкой 5–30 с, это руководство расскажет, что теперь возможно, сколько это стоит и как мигрировать, не выжигая существующую инфраструктуру.

Почему RTMP уходит в 2026 году

RTMP — Real-Time Messaging Protocol — разработан Macromedia для Flash Player в 2002 году. Adobe перестала его поддерживать в 2012-м. Сам Flash был окончательно похоронен в декабре 2020-го. Тем не менее RTMP уцелел как фактический стандарт приёма потока, потому что на нём говорили OBS Studio, FFmpeg, GStreamer и все аппаратные энкодеры в мире. Замены не было.

С 2024 года изменились три вещи:

1. Планка интерактивности сдвинулась. Спортивный стриминг, лайв-коммерция, онлайн-аукционы, фан-вовлечение и наложение чата на базе ИИ — всем нужна задержка туда-обратно меньше секунды. Связки RTMP→HLS дают 5–30 секунд. Даже LL-HLS, «низколатентный» вариант HLS, держит 3–7 секунд. Данные StreamLayer показывают: интерактивные зрители смотрят на 33 % дольше. Но интерактив невозможен, если ваш пол по задержке — 6 секунд.

2. RFC 9725 закрепил альтернативу. WHIP — WebRTC-HTTP Ingestion Protocol — вышел в марте 2025 года как Standards Track RFC. Это уже не черновик. Вендоры могут реализовать его, зная, что спецификация заморожена, а OBS Studio добавил нативную поддержку в версии 30. Сторона энкодера решена.

3. CDN-ы это приняли. Cloudflare Stream, AWS IVS Real-Time, Dolby OptiView, Red5 Cloud, Ant Media Server, Mux, Wowza, Millicast и open-source-инструменты Eyevinn — все теперь предоставляют WHIP-эндпоинты. Пять лет назад это был исследовательский протокол. Сегодня — пункт чек-листа у каждого вендора.

RTMP не умрёт за одну ночь — он работает, и нижестоящая HLS-цепочка по-прежнему чувствительна к тому, как пришли байты. Но путь вперёд для любого интерактивного сценария — WHIP на приёме, WHEP на воспроизведении и привычный HLS/DASH как запасной вариант для дешёвой длинной части аудитории.

Что такое WHIP — RFC 9725 простыми словами

Сессия WHIP — это один HTTP-обмен и затем медиа поверх WebRTC peer connection. Никакого WebSocket, никакого MQTT, никакого проприетарного SDK для сигнализации. Энкодер отправляет обычный HTTP POST с SDP-оффером в теле и Bearer-токеном в заголовке Authorization. Сервер отвечает HTTP 201 Created, SDP-ответом и URL сессии. После этого RTP-пакеты идут по транспорту WebRTC (DTLS-SRTP).

В сыром виде рукопожатие выглядит так:

POST /whip/live/streamkey HTTP/1.1
Host: ingest.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Content-Type: application/sdp

v=0
o=- 4611734147533472881 2 IN IP4 127.0.0.1
s=-
... (SDP offer)

---

HTTP/1.1 201 Created
Location: /whip/live/streamkey/abc123
Content-Type: application/sdp

v=0
o=- ... (SDP answer)

---

DELETE /whip/live/streamkey/abc123 HTTP/1.1   # to terminate
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Три вещи делают это важным.

1. Это просто HTTP. Перед WHIP можно поставить любой обратный прокси, балансировщик нагрузки, WAF, CDN или edge-функцию. Аутентификация — та, что уже есть в вашем стеке: OAuth bearer-токены, mTLS, подписанные URL. RTMP требует отдельного publish-сервера; WHIP укладывается в остальную HTTP-инфраструктуру.

2. Транспорт — WebRTC. Сразу после рукопожатия вы получаете обход NAT через ICE/STUN/TURN, сквозное шифрование SRTP, контроль перегрузки через Google Congestion Control или NADA, повторную передачу пакетов через NACK и FEC — все современные транспортные возможности, которые RTMP приходилось привинчивать через проприетарные SRT- или WebRTC-туннели.

3. Это не зависит от энкодера. OBS 30 поставляется с нативной поддержкой WHIP. У FFmpeg в ветке 7.x есть мультиплексор whip. Работают webrtcsink + whipclientsink в GStreamer. Аппаратные энкодеры от AJA, Magewell, BlackMagic и TeradECK получили прошивки с WHIP. Чтобы публиковать поток на медиасервер, вендорский SDK больше не нужен.

Что такое WHEP — зеркальный близнец для отдачи

WHEP — WebRTC-HTTP Egress Protocol — это парный протокол для воспроизведения. Зритель отправляет POST со своим SDP-оффером на WHEP-эндпоинт, получает SDP-ответ и медиапоток поверх WebRTC. С точки зрения плеера это та же простота, которую WHIP даёт энкодеру.

Если WHIP уже стал RFC, то WHEP пока остаётся IETF Internet-Draft. Но спецификация стабильна, и Cloudflare Stream, OvenMediaEngine, AWS IVS, Dolby OptiView и большинство управляемых вендоров реализуют его совместимо. Мы сегодня используем WHEP в продакшене и для инженерных целей считаем его готовым — даже если официальная ленточка ратификации ещё не повязана.

WHEP даёт сквозное воспроизведение с задержкой меньше секунды (на тонко настроенном деплое — меньше 1 с) для неограниченного числа зрителей, если развернуть SFU-меш для веерного распространения. Классическое возражение — «WebRTC не масштабируется выше нескольких сотен зрителей» — больше не верно: топологии origin-shield SFU и WHEP-источники уровня CDN снимают этот предел (Cloudflare заявляет об отсутствии лимита на одновременных зрителей в своём WebRTC-предложении Stream).

Бенчмарк по задержке — RTMP vs LL-HLS vs WHIP

Сквозная задержка — единственный значимый показатель. Мы измеряем её, накладывая на исходный кадр высокоточный таймстамп, фиксируя отрисованный кадр у зрителя и измеряя дельту. Цифры ниже — из наших продакшен-деплоев 2025–2026 годов: выборка за 14 дней по нескольким регионам и трём профилям энкодера. Они согласуются с публичными бенчмарками Cloudflare и Streaming Media Magazine.

Диапазон 200–500 мс покрывает всё — от последнего кадра в буфере энкодера до отрисовки на экране зрителя. Около 80–120 мс уходит на кодирование и пейсинг WebRTC, 30–60 мс — на сеть, 30–100 мс — на пересылку через SFU, остальное — на декодирование и отображение. Если настроить GOP (1 с в режиме live), предпочесть аппаратный H.264 baseline и поднять SFU географически близко к зрителю, нижняя граница держится надёжно.

Для сравнения: нативный WebRTC peer-to-peer (без SFU и без обёртки WHIP) даёт примерно те же 0,2–0,5 с. То есть WHIP/WHEP не добавляют измеримой задержки поверх вручную собранного WebRTC-стека, но снимают всю сложность слоя сигнализации.

Эталонная архитектура — как выглядит продакшен

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

Пять уровней подробно

1. Энкодер. OBS Studio 30+ для авторов на десктопе, FFmpeg 7+ для безголовых пайплайнов, аппаратные энкодеры от AJA, Magewell, BlackMagic, TeradECK или Haivision для студий. Энкодер отправляет WHIP на один настроенный URL с Bearer-токеном. Никаких кошмаров с TCP keep-alive и никаких рукопожатий эпохи Flash.

2. WHIP-шлюз. Тонкий HTTP-сервис: проверяет Bearer-токен, применяет лимиты, при необходимости правит SDP (например, чтобы зафиксировать параметры VP8/H.264) и пересылает SDP-оффер в SFU. Обычно мы запускаем его как stateless Go- или Node-сервис за nginx; накладные расходы по задержке — единицы миллисекунд.

3. SFU-меш. Selective Forwarding Unit — именно здесь живёт сама трансляция: он пересылает RTP-пакеты от издателя ко всем подписчикам без перекодирования. mediasoup, LiveKit, Janus, Jitsi, Ant Media, кастомные сборки на Pion — всё рабочее. Для интерактивного спортивного стриминга или любой трансляции с более чем 1k одновременных зрителей мы разворачиваем SFU мешем: один origin-SFU на трансляцию, edge-SFU в регионе пользователя, RTP передаётся между ними.

4. Развилка пакетирования. Большинство продакшен-деплоев не выбирают «всё через WHEP» или «всё через HLS». Они держат опциональный транскодер на FFmpeg, который забирает RTP с SFU и отдаёт LL-HLS ABR-лестницу с задержкой 3–5 с для дешёвого длинного хвоста зрителей, тогда как интерактивные зрители идут через WHEP. DVR и VOD снимаются с той же ветки.

5. Зритель. Браузеры (Chrome, Edge, Safari, Firefox) воспроизводят WHEP нативно через любой из открытых клиентов (инструменты WHIP/WHEP от Eyevinn, JS SDK от LiveKit, референсный плеер Cloudflare). iOS и Android используют системный WebRTC-стек. Smart TV — гибрид: HLS для классических STB и WebView-WebRTC для свежих панелей Android TV / WebOS.

Матрица вендоров — кто поддерживает WHIP/WHEP сегодня

К маю 2026 года все крупные медиавендоры и CDN поддерживают WHIP на приёме. Покрытие WHEP чуть тоньше: ряд вендоров до сих пор поставляет проприетарные WebRTC-SDK для воспроизведения параллельно с открытым WHEP-эндпоинтом. Тем не менее совместимости достаточно, чтобы смешивать решения разных вендоров.

Замечание про AWS IVS Real-Time: WHIP официально поддерживается на приёме, но для воспроизведения Amazon по-прежнему опирается на проприетарный IVS Player SDK. WHEP-эндпоинт доступен, но считается второстепенным. Если на стороне клиента у вас IVS Player JavaScript SDK или iOS/Android SDK, низкая задержка достигается без прямого обращения к WHEP.

Self-hosted: mediasoup, Janus, Eyevinn, LiveKit

Self-hosted имеет смысл, когда вы перешагиваете отметку 10–15 тыс. WebRTC-минут в месяц или когда у вас есть требования по соответствию (HIPAA, локализация данных GDPR), которые управляемые CDN не закрывают без дорогих корпоративных тарифов. Ниже — шорт-лист, который мы рекомендуем в 2026.

mediasoup. SFU на C++ с Node.js-управляющим слоем. Проверен временем; используется в продакшене Discord, Mozilla Hubs и несколькими клиентами Фора Софт. Поддержка WHIP/WHEP идёт через официальный компаньон mediasoup-broadcaster или сторонние шлюзы. Малый эксплуатационный след; жёсткая производительность.

LiveKit (open source). Self-hosted LiveKit даёт тот же SFU, что и LiveKit Cloud, без ежемесячного счёта. Нативные эндпоинты Ingress (WHIP) и Egress (WHEP). Те же SDK, что и в облачной версии. Эксплуатация тяжелее, чем у mediasoup — нужно держать управляющий слой на Redis, серверы комнат и TURN-релеи — но из коробки идут интеграции с ИИ-агентами, что важно, если вы планируете позже добавить голосовой ИИ.

Janus Gateway. Ветеран. На C, плагинная архитектура, плагин WHIP зрелый. Janus хорош, когда нужно экзотическое поведение (мультитенантные правила маршрутизации, кастомная перезапись RTP, шлюз SIP), но в эксплуатации он тяжелее, чем mediasoup.

Open-source-инструменты Eyevinn. Референсный WHIP-сервер, WHIP-клиент, WHEP-сервер и WHEP-плеер — всё под Apache. Мы используем их для PoC и для надстройки кастомной маршрутизации над существующим SFU. Самостоятельно для продакшен-масштаба не предназначено, но незаменимо для тестирования и для команд, которые хотят разобраться со спецификацией руками.

Pion. Чисто Go-реализация WebRTC-стека от команды ION-SFU. Хороший выбор, когда ваша эксплуатационная команда предпочитает Go-бинари, а не возню с Node/C++ управляющим слоем, и когда нужен субмиллисекундный контроль над переписыванием RTP.

Модель затрат — managed vs self-hosted на масштабе

Вот расчёт по реальному деплою 2025 года: спортивный вещатель с пиком одновременных зрителей около 12 000, среднее время просмотра 38 минут, 14 часов прямых эфиров в неделю. Итого отданных зрительских минут в месяц: примерно 1 050 000.

Managed-сценарий (Cloudflare Stream): при цене 0,075 ₽ за отданную минуту 1,05 млн минут × 0,075 ₽ ≈ 78 тыс. ₽ / мес за отдачу. Плюс 2 ТБ хранения (исходим из DVR на 30 дней) — примерно 15 тыс. ₽ / мес. Итого: около 93 тыс. ₽ / мес, никакой инфраструктуры. До 1 млн минут в месяц это самый дешёвый вариант.

Self-hosted-сценарий (mediasoup на Hetzner AX): три региональных SFU (US East, EU Central, APAC), каждый на сервере AX102 (около 17 тыс. ₽ / мес за узел), две TURN-релейные ноды (по 6 тыс. 700 ₽ / мес каждая), один транскодер для ABR-фолбэка (17 тыс. ₽ / мес), одна управляющая нода (6 тыс. 700 ₽ / мес). Исходящий трафик у Hetzner включён до 20 ТБ / мес на узел. Аппаратные расходы — около 93 тыс. ₽ / мес. Плюс 0,3 ставки senior-инженера на эксплуатацию: ~262 тыс. ₽ / мес по типичной полной стоимости. Итого: примерно 352 тыс. ₽ / мес на этом масштабе.

Точка пересечения. При таком профиле одновременных зрителей managed выигрывает, пока вы не перешагиваете примерно 4 млн отданных минут в месяц — это около 50 тыс. одновременных зрителей на одном полуторачасовом мероприятии. Выше этой точки поминутная тарификация управляемых CDN начинает доминировать, а self-hosted-инфраструктура с уже амортизированной инженерной работой выигрывает в 2–4 раза.

Есть и третий вариант — гибрид. Держите self-hosted SFU для предсказуемой части аудитории (ежедневный новостной поток, регулярный класс) и переключайтесь на управляемый WHIP/WHEP-сервис вроде Cloudflare Stream при непредсказуемых пиках (флэш-распродажа, вирусный момент, плей-офф). В 2025 году мы реализовали этот шаблон для двух клиентов: он ограничивает максимальную стоимость, не заставляя переразвёртывать SFU.

Мини-кейс — с RTMP на WHIP за 12 недель

Региональный спортивный вещатель пришёл к нам в октябре 2024 года с типичной проблемой. Их связка RTMP→HLS давала зрителям лаг 6,2 с, что разрушало целостность продукта по лайв-беттингу: зрители ставили на эпизоды, которые домашняя аудитория уже видела. Перевод платформы был исключён — контракт с действующим стриминг-SaaS оставался ещё 18 месяцев.

План на 12 недель. Недели 1–2 мы разместили на существующем RTMP-пути таймстамп-наложения и снимали сквозную задержку p50 и p95 в четырёх регионах. Медиана была 6,2 с, p95 — 9,4 с. Недели 3–5 мы развернули параллельный WHIP-шлюз перед self-hosted mediasoup на Hetzner AX102, не трогая легаси-RTMP. Недели 6–8 вещатель через систему feature-флагов перенаправил 5 % трафика на новый путь; мы следили за стабильностью и тонко настраивали GOP, jitter buffer и распределение TURN-релеев. Недели 9–11 раскатывали до 25 %, затем до 60 %, затем до 100 %. Неделя 12 — репетиция отката и обучение дежурных.

Результат. Медианная сквозная задержка упала с 6,2 с до 380 мс. p95 упал с 9,4 с до 720 мс. Hold-rate ставок (доля ставок, размещённых внутри игрового окна) вырос на 19 %. Отток зрителей в первые 30 секунд после подключения — метрика, которая отражает восприятие «поток вообще живой?» — снизился с 11 % до 3 %. Хотите такой же замер? Позвоните или напишите — мы набросаем эквивалентный план под ваш стек.

5-недельный план миграции

Когда исходный стек проще — один приём, одна поверхность зрителя, без беттинг- или коммерс-наложений — миграция сжимается примерно до пяти недель. Канонический недельный план ниже.

Фреймворк решения — выбираем WHIP за пять вопросов

В1. Ломается ли какая-то пользовательская функция при задержке выше 2 с? Лайв-беттинг, онлайн-аукционы, телемедицина с двусторонним приёмом, Q&A в классе, чат, синхронный с эпизодом, фан-реакции на спортивном оверлее — всё ломается. Если у вас есть хотя бы одно из этого — WHIP не опция, а необходимость.

В2. Что на стороне энкодера? Если контрибьюторы работают на OBS, FFmpeg или аппаратных энкодерах от AJA/Magewell/BlackMagic, WHIP уже работает без установки SDK. Если у них легаси-приложение с проприетарной RTMP-прошивкой, планируйте обновление энкодера в параллель.

В3. Что на стороне зрителя? Браузеры и мобильные WebView обрабатывают WHEP нативно. STB на smart-TV и более старые приложения Connected-TV могут потребовать ветку HLS. Если ваша аудитория — на 70 %+ smart-TV, HLS-путь у вас сохранится в любом случае; WHIP всё равно даёт выигрыш, сжимая пайплайн трансляции выше пакетировщика.

В4. Какой объём? Ниже 100 тыс. отданных минут/мес выигрывает managed (Cloudflare/AWS IVS/Mux) по совокупной стоимости. 100 тыс.–4 млн минут/мес — managed по-прежнему выигрывает за счёт неучтённых инженерных расходов. Выше 4 млн начинает доминировать self-hosted.

В5. Какие требования по соответствию? HIPAA, локализация данных по GDPR, FedRAMP или жёсткие договорные обязательства по on-prem меняют картину. Самый простой путь — self-hosted в вашем VPC на mediasoup или LiveKit OSS. Несколько управляемых вендоров предлагают enterprise-тарифы с BAA и резидентностью в ЕС, но шаг по цене существенный — закладывайте 3× стандартного тарифа.

Подводные камни

1. Недостаточно TURN. Симметричный NAT у мобильных операторов означает, что заметная часть зрителей не сможет установить peer-to-peer ICE-кандидата. Они уйдут на TURN-релей. Если ваш TURN-кластер — одна нода в одном регионе, у вас единая точка отказа и огромный счёт за трафик. Держите TURN минимум в трёх регионах и закладывайте трафик в 30–40 % от общей отдачи.

2. Сюрпризы при согласовании кодеков. WHIP позволяет энкодеру и серверу договориться о любом общем кодеке. OBS по умолчанию выбирает H.264 baseline — нормально. FFmpeg может выбрать H.265 или VP9, если SDP не зафиксирован. Клиентская сторона иногда не поддерживает выбранный кодек — особенно сборки Safari постарше. Всегда фиксируйте SDP-оффер в шлюзе.

3. Забытые потребители ниже по потоку. RTMP часто кормит не только плеер: подписчики — downstream-аналитика, вставка рекламы (маркеры SCTE-35), архивация DVR, субтитры, ретрансляция в соцсети. Перед выводом из эксплуатации проведите аудит каждого потребителя RTMP-источника — иначе вы узнаете, что аналитический дашборд опустел, только после переключения.

4. Неверная настройка контроля перегрузки. WebRTC по умолчанию использует Google Congestion Control (GCC). На чистой оптике это работает; на перегруженном мобильном канале GCC может слишком агрессивно опустить битрейт — и вы получите 240p, хотя 720p удержался бы. Настройте нижний порог битрейта кодирования и окно сглаживания BWE под профиль вашей аудитории.

5. Привязка к SDK под другим именем. Некоторые «WHIP-совместимые» вендоры выставляют WHIP-эндпоинт, но требуют свой проприетарный SDK на стороне плеера, чтобы включился режим низкой задержки. Это не открытый стандарт, а управляемый сервис с дверцей в форме WHIP. Перед подписанием многолетнего контракта проверьте WHEP-путь и доступные открытые варианты воспроизведения.

Какие KPI измерять

KPI качества. Сквозная задержка p50 (цель: < 500 мс) и p95 (цель: < 1,0 с). Time-to-first-frame при подключении зрителя (цель: < 800 мс). Freeze rate — доля секунд, когда воспроизведение замирало (цель: < 0,3 %). PSNR или VMAF против исходного кадра, выборка раз в 30 секунд.

Бизнес-KPI. Среднее время просмотра — ждите рост на 10–30 % на интерактивных сценариях, когда задержка падает ниже 1 с. Отток в первые 30 секунд после подключения (цель: < 4 %; здоровый WHEP-путь обычно даёт 2–3 %). Для беттинга и коммерции — конверсия внутри игрового окна: самый прямой индикатор того, что задержка больше не ломает покупку.

KPI надёжности. Доступность WHIP-шлюза (цель: 99,95 %). Запас по CPU и трафику SFU в час пик (цель: < 70 % от пика). Утилизация TURN-релея (цель: < 60 % от пика, чтобы был запас на скачки симметричного NAT). Среднее время восстановления при переподключении энкодера (цель: < 3 с — время от потери соединения у энкодера до возврата зрителя в поток).

Когда НЕ мигрировать

Линейный OTT с повторами и VOD-библиотеками. Если основной сценарий — «посмотреть 45-минутный эпизод когда удобно», зрителю всё равно, начался поток 10 секунд назад или сейчас. HLS плюс обычный CDN остаются дешевле, проще и кешируемее, чем WHEP. WHIP всё ещё может помочь со стороны контрибьюции — забирать контент из студии в ваш VOD-пайплайн — не меняя клиентскую часть.

Гипер-чувствительная к расходам реклама-ориентированная трансляция. Если ваш ARPU около нуля (бесплатно, на рекламе, новости) и аудитория — миллионы, поминутная стоимость WebRTC-доставки превышает HLS-через-CDN примерно в 2–5 раз. Преимущества интерактива не оправдывают счёт. Гибрид — WHEP для премиум-подписчиков, LL-HLS для бесплатного тарифа — часто правильный ответ.

Аудитория только на smart-TV. Старые smart-TV не поддерживают воспроизведение WebRTC. Если у вас 70 %+ Roku, Fire TV прежних версий, LG WebOS до 2022 или Samsung Tizen до 2023 — держите LL-HLS-путь. WHIP на стороне приёма всё равно даёт выигрыш (лучше задержка контрибьюции до пакетировщика), но клиентский эффект исчезает.

Контрибьюция одного источника на экстремальном битрейте. Если идёт 4K HDR-контрибьюция с удалённой ПТС по спутнику, SRT плюс пакетировщик ниже по потоку остаются безопаснее. Контроль перегрузки в WebRTC не проектировался под многомегабитные пути с фиксированным битрейтом; ARQ-восстановление в SRT для такого профиля предсказуемее.

FAQ

WHIP — это официальный стандарт IETF?

Да. RFC 9725 опубликован как IETF Standards Track в марте 2025 года. Протокол заморожен и стабилен для продакшена. WHEP пока остаётся Internet-Draft — ожидается, что он пройдёт тот же путь к статусу RFC, — но уже широко совместим между реализациями.

YouTube или Twitch поддерживают WHIP?

По состоянию на май 2026 года — нет. Оба по-прежнему принимают поток через RTMP для обычных авторов. Twitch экспериментировал с WHIP для низколатентных мероприятий, но это не дефолт. Если ваше распространение зависит от YouTube или Twitch, заложите параллельный RTMP-путь: можно держать WHIP внутренним стандартом и конвертировать в RTMP на границе отдачи.

Работает ли WHIP/WHEP за корпоративным фаерволом?

Большинство корпоративных сетей пропускают WHIP — сигнализация это обычный HTTPS. Медиатранспорту нужен UDP для WebRTC, и некоторые жёсткие сети его блокируют; в этом случае стек WebRTC откатывается на TCP-релей через TURN на порту 443. Мы не встречали корпоративного окружения, где такая комбинация не работает, но TURN на 443 обязателен для гарантированного доступа.

Можно ли сохранить существующий HLS DVR при работе с WHIP?

Да — это рекомендуемый шаблон. Снимайте RTP с SFU в пакетировщик на FFmpeg, который выдаёт LL-HLS ABR-лестницу для DVR, архивации VOD и дешёвой длинной части аудитории. Живые интерактивные зрители остаются на WHEP; все остальные — на HLS. Мы реализовывали такую развилку в продакшене для StreamLayer и одного регионального вещателя.

WHIP совместим с HIPAA?

Сам протокол — это HTTP и WebRTC; и то и другое дружелюбно к шифрованию. HIPAA-соответствие достигается архитектурой целиком: шифрованное медиа (DTLS-SRTP, нативно в WebRTC), подписанное BAA с тем управляемым вендором, которого вы используете, журналирование метаданных сессий и BAA-покрываемое хранилище для записей. Self-hosted WHIP/WHEP внутри вашего VPC — самый простой путь к HIPAA-соответствию.

Чем WHIP отличается от SRT?

SRT — протокол контрибьюции: его задача переместить видеосигнал из удалённой точки в пакетировщик через шумную сеть. С этим он справляется отлично. WHIP — протокол приёма: он перемещает видеосигнал в медиасервер с задержкой меньше секунды, готовый к веерному распространению по WebRTC. Они дополняют друг друга: многие продакшен-стеки используют SRT для контрибьюции до регионального хаба, а затем WHIP для публикации в SFU и распространения.

Будет ли WHIP работать с моим аппаратным энкодером?

Если энкодер выпущен или получил прошивку в 2024 году или позже — почти наверняка да. AJA HELO Plus, Magewell Ultra Encode, BlackMagic Web Presenter HD/4K и TeradECK Vidiu — все получили прошивку с WHIP. Для устройств постарше рядом с энкодером запускается небольшой WHIP-шлюз: он принимает RTMP локально и переотправляет вверх по потоку через WHIP. Мы делали это для двух клиентов с зафиксированным капексом по железу.

Сколько обычно стоит миграция на WHIP?

Для стека с одним приёмом и одной зрительской поверхностью на управляемой инфраструктуре (Cloudflare Stream или AWS IVS Real-Time) инженерные затраты — примерно 5–7 недель одного senior-инженера с опытом WebRTC, плюс архитектурный и эксплуатационный ревью. Для self-hosted-деплоя на mediasoup или LiveKit OSS закладывайте 8–12 недель плюс SRE на настройку мониторинга и TURN. Аппаратные расходы рассмотрены в разделе 9. Полная стоимость зависит от объёма работ, но чистая миграция обычно укладывается в 1,8–6 млн ₽.

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

Готовы попрощаться с RTMP?

RTMP за двадцать лет вывел индустрию живого вещания с пола в 30 секунд на пол в 5 секунд. WHIP и WHEP опускают этот пол ниже 500 мс за 5-недельный проект — без проприетарного SDK на стороне энкодера, без своего слоя сигнализации и без привязки к вендору, если вы её сами не выберете. RFC 9725 сделал миграцию безопасной для инвестиций; OBS Studio и крупные CDN сделали её дешёвой для старта.

Если у вашего продукта есть момент, который ломается на 2 с задержки — ставка, торг, покупка, вопрос, эпизод — апгрейд теперь строго обязателен. Остаётся один вопрос: managed или self-hosted, — и он решается пятью вопросами и таблицей по зрительским минутам.