WHIP: ingest для WebRTC и стандарт RFC 9725

Последняя проверка: 2026-05-21 по IETF RFC 9725 WebRTC-HTTP Ingestion Protocol (WHIP) – Standards Track / Proposed Standard, опубликованному в марте 2025 года авторами Серхио Гарсия Мурильо (Millicast) и Александром Гуайяром (CoSMo Software); архиву рабочей группы IETF WISH; релизным заметкам OBS Studio 30+ и исходному коду obs-webrtc; документации и changelog Cloudflare Stream WHIP/ WHEP до мая 2026; документации AWS Elemental MediaLive и AWS IVS Real-Time по публикации через WHIP; референсной документации Dolby Millicast WHIP; гайду Ant Media Server 2.10+ по WHIP; модулю libwhip в FFmpeg 7; опции WHIP в Larix Broadcaster; и реестру WHIP URN в IANA.

TL;DR

WHIP, WebRTC-HTTP Ingestion Protocol, – это стандартный ответ на вопрос «как передать живой WebRTC-поток на сервер, не разрабатывая собственный код сигнализации». IETF опубликовал его как RFC 9725 в марте 2025 года (Standards Track, статус «Proposed Standard») после трёх с половиной лет работы рабочей группы WISH; в 2026 году протокол стал стандартным sub-секундным путём передачи контента для каждой современной платформы разработки live-сервисов. По сути, всё предельно просто: энкодер отправляет один HTTP POST с SDP offer в теле, сервер возвращает 201 Created с SDP answer и заголовком Location, указывающим на ресурс сессии; один HTTP DELETE завершает сессию. В 2026 году WHIP – правильный выбор для передачи контента, когда бюджет задержки меньше секунды на относительно чистом канале, а целевая экосистема энкодеров (OBS 30+, FFmpeg 7, Larix, Cloudflare Stream, AWS IVS Real-Time, Dolby Millicast, Ant Media, MediaLive, Wowza, THEO, Vimeo, Mux Live, аппаратные энкодеры Magewell / AJA / Teradek / Haivision) уже поддерживает WHIP.

Зачем эта статья

До WHIP каждое внедрение WebRTC-ингеста было индивидуальным проектом. Каждая платформа разрабатывала свой протокол сигнализации – у Janus он был один, у mediasoup – другой, у LiveKit – третий, у Millicast – четвёртый, у Twilio – пятый – и энкодер, совместимый с одним вендором, без использования вендор-специфичного SDK не работал ни с кем другим. WebRTC как медиауровень оставался открытым стандартом, но WebRTC как способ передачи контента превращал систему в vendor lock-in. Именно эта одна проблема двадцать лет удерживала вещательную индустрию на RTMP.

WHIP решает задачу с минимальной поверхностью: один HTTP POST заменяет десяток кастомных протоколов сигнализации. Энкодер, поддерживающий WHIP, может транслировать на любой сервер, поддерживающий WHIP – и всё. Тот же OBS, который сегодня транслирует в Cloudflare Stream, завтра – в AWS IVS, в пятницу – в Dolby Millicast, в субботу – на самописный Ant Media – без каких-либо изменений, кроме URL и Bearer-токена. Именно эта переносимость и делает протокол значимым. Эта статья – канонический справочник по WHIP для инженеров, продактов и архитекторов, выбирающих стек для передачи контента в 2026 году: что именно описано в RFC 9725 (с указанием номеров секций), как работают четыре HTTP-метода, зачем нужен trickle ICE и ICE restart, почему задержка именно такая, где WHIP выигрывает и проигрывает по сравнению с SRT и RTMPS, а также какие платформы и энкодеры поддерживают его сегодня.

Что такое WHIP – на одной странице

WHIP, WebRTC-HTTP Ingestion Protocol, – это тонкий HTTP-слой, обёртывающий обмен SDP offer/answer для WebRTC. Протокол выполняет одну задачу: обеспечивает энкодеру стандартизированный способ опубликовать одну WebRTC-медиа-сессию на сервер и корректно завершить её. Всё остальное – медиа-транспорт, кодеки, шифрование, контроль перегрузки – остаётся на стороне обычного WebRTC, определённого существующими спецификациями W3C и IETF. Гениальность WHIP заключается в минимальной поверхности взаимодействия. Полный операционный протокол – всего четыре HTTP-метода и два URL-адреса.

Два URL – это WHIP endpoint URL (куда энкодер отправляет POST-запрос для начала сессии) и WHIP session URL (возвращается в заголовке Location ответа 201 и используется для всех последующих операций). Четыре глагола – POST (запуск сессии), DELETE (завершение), PATCH (обновление состояния ICE во время сессии) и OPTIONS (preflight CORS и обнаружение возможностей). Всё остальное в RFC 9725 – это точные определения содержимого каждого запроса и ответа.

Механически: энкодер генерирует SDP offer для одного WebRTC PeerConnection (один bundle-объединённый медиа-поток аудио + видео, направление send-only, шифрование DTLS-SRTP оговорено), сериализует offer в текст и отправляет его в теле HTTP POST с заголовком Content-Type: application/sdp на WHIP endpoint URL. Сервер валидирует offer, собирает свои собственные ICE-кандидаты, генерирует SDP answer с полным набором серверных кандидатов и возвращает answer как application/sdp в ответе 201 Created. Ответ несёт два важных заголовка: Location – указатель на свежесозданный ресурс WHIP-сессии, и ETag – идентификатор текущего состояния ICE-сессии (используется потом для безопасной обработки запросов на ICE restart). На этом у клиента всё есть для завершения ICE-хэндшейка; после ICE и DTLS медиа начинает течь через SRTP.

Чтобы корректно завершить сессию, энкодер отправляет HTTP DELETE-запрос на URL сессии; сервер возвращает 200 OK, разбирает состояние ICE/DTLS и освобождает медиа-ресурсы. Если энкодер просто пропадает, сервер обнаруживает потерю по собственным таймерам keepalive и проверкам связности ICE в WebRTC и закрывает сессию самостоятельно.

Транспорт на проводе – то, что использует WebRTC: UDP с ICE-кандидатами типов host, server-reflexive и relayed, DTLS для шифрования, SRTP для медиа. Соответственно, WHIP наследует от WebRTC и обход NAT (STUN/TURN, подробно в нашей статье), и контроль перегрузки (transport-wide congestion control, сокращённо TWCC, а также receiver-side bandwidth estimator). HTTP – версии 1.1 или 2; RFC 9725 не предписывает конкретную версию, и обе активно используются в продакшене.

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

Краткая история WHIP

До 2020 года каждый путь интеграции WebRTC был кастомным решением. WebRTC как стандарт, опубликованный W3C и IETF в период с 2011 по 2018 год, определил уровень медиа (PeerConnection, RTCDataChannel, грамматику SDP, DTLS-шифрование, SRTP, ICE/STUN/TURN), но намеренно оставил сигнализацию за рамками спецификации. Логика W3C была такова: требования к сигнализации сильно зависят от конкретного приложения – у видеоконференций одни, у одностороннего вещания – другие, – поэтому вендорам следует выбирать подходящий инструмент под каждый случай. На практике эта свобода привела к фрагментации: каждый поставщик WebRTC-серверов разрабатывал собственную систему сигнализации. Janus использовал WebSocket + JSON-протокол, mediasoup – JSON-запросы и ответы через WebSocket, Twilio – проприетарный SDK для сигнализации, а Vidyo и Tokbox – свои собственные решения. Чтобы энкодер мог подключиться к WebRTC-пайплайну, ему требовался вендор-специфичный SDK для каждого целевого сервера.

В конце 2020 года Серхио Гарсия Мурильо из Millicast и Александр Гуайяр из CoSMo Software представили в IETF первый Internet-Draft по WHIP (draft-ietf-wish-whip-00), предложив единый HTTP-слой сигнализации для частного случая односторонней передачи контента. Идея была сознательно минималистской: не пытаться стандартизировать сигнализацию в целом, а зафиксировать наиболее распространённый сценарий – когда энкодер отправляет один медиа-поток на сервер, – оставив более сложные случаи на усмотрение вендоров. В 2021 году IETF создала рабочую группу WISH для продвижения стандартизации. Через шестнадцать драфтов и три с половиной года консенсусный документ прошёл ревью IESG и был опубликован как RFC 9725 в марте 2025 года.

RFC 9725 имеет статус «Standards Track» – высшую категорию в процессе IETF – и на данный момент опубликован как «Proposed Standard». Документ формально обновляет два более ранних RFC: RFC 8840 (trickle ICE) и RFC 8842 (согласование настроек DTLS-SRTP), уточняя их поведение в рамках WHIP-сессии. Авторитетный URL документа – https://www.rfc-editor.org/rfc/rfc9725; ниже мы приводим номера секций именно из опубликованного RFC, а не из устаревших черновиков.

Полезный исторический контраст: попытка стандартизации SRT так и не вышла за рамки Internet-Draft. Драфты истекли в 2022 году, и сегодня SRT управляется сообществом, основанным на устаревшем драфте и эталонной реализации. WHIP пошёл противоположным путём. Гарсия Мурильо и Гуайяр сознательно ограничили область применения и минимизировали интерфейс, после чего успешно провели документ через процесс IETF и добились его формальной публикации в виде RFC. Результат – стабильная спецификация, на основе которой вендоры могут строить свои решения; нормативный номер документа («RFC 9725»), который можно использовать в комплаенс-документации и регламентах. Эта разница имеет значение при закупках в broadcast-индустрии.

Четыре HTTP-глагола – что делает каждый

Поверхность протокола – четыре HTTP-метода на двух URL. Далее – краткое описание каждого метода в порядке их использования энкодером.

POST – начать сессию (RFC 9725, раздел 4.2)

Энкодер формирует SDP offer для одного WebRTC PeerConnection и отправляет его в теле HTTP POST-запроса на WHIP endpoint URL. Запрос должен содержать Content-Type: application/sdp; в противном случае сервер обязан отклонить HTTP POST-запрос с соответствующим ответом 4xx (§4.2). В SDP offer действуют ограничения: направление должно быть sendonly или sendrecv; направления recvonly и inactive в клиентских offer-ах явно запрещены; сессия обязана объединять все медиа в один транспорт с использованием BUNDLE (§4.4.1); допускается ровно один MediaStream (§4.4.2). В рамках этих требований всё, что допустимо в WebRTC, считается допустимым и в WHIP-offer.

Сервер проверяет offer и формирует SDP answer. Направление answer всегда – recvonly. Сервер собирает все свои ICE-кандидаты до отправки ответа: согласно §4.3.2 RFC 9725, answer должен содержать полный список кандидатов со стороны сервера. Поэтому клиент получает полный набор кандидатов в теле answer и не нуждается в дополнительной сигнализации от сервера. Сервер возвращает answer в ответе 201 Created с Content-Type: application/sdp и телом answer. Два заголовка ответа передают оставшуюся идентификацию сессии: Location указывает на WHIP session URL (URL, который позже используется для PATCH и DELETE), а если сервер поддерживает перезапуск ICE, заголовок ETag содержит «уникальный сильный entity-tag, идентифицирующий ICE-сессию» (§4.3.1).

Коды статуса, отличные от 201, указывают на режимы отказа, к которым клиент должен быть готов: 4xx – при некорректно сформированном offer или отсутствии bearer-токена, 5xx – если сервер не может выделить медиа-ресурсы, а также различные 3xx-редиректы (§4.5), которые клиент обязан выполнять. Полный перечень приведён в §4.2 и §4.7 RFC.

DELETE – завершить сессию (RFC 9725, раздел 4.2)

Когда энкодер завершает работу, он отправляет HTTP DELETE на URL сессии WHIP – тот самый, что сервер вернул в заголовке Location первоначального POST-запроса. Сервер обрабатывает ICE и DTLS, освобождает медиа-ресурсы и возвращает 200 OK. DELETE – единственный «чистый» способ завершить сессию: если энкодер отключается без отправки DELETE, сервер полагается на собственные таймеры keepalive и проверки связности ICE в WebRTC, которые обычно обнаруживают потерю соединения в течение нескольких секунд и удаляют серверное состояние.

PATCH – обновление ICE-состояния во время сессии (RFC 9725 §4.3.1)

PATCH – это глагол, с помощью которого обновляется ICE-состояние в ходе активной сессии. Причины для отправки PATCH ровно две: добавить новые ICE-кандидаты, собранные клиентом после исходного POST (trickle ICE, §4.3.2), или перезапустить ICE из-за изменения сетевого пути под сессией (ICE restart, §4.3.3). В обоих случаях тело запроса – Content-Type: application/trickle-ice-sdpfrag – представляет собой формат trickle-ICE SDP-фрагмента из RFC 8840, а сам запрос должен содержать заголовок If-Match, значение которого – либо последний полученный от сервера ETag, либо литерал * для безусловного перезапуска.

Коды ответа кодируют интерпретацию сервера:

• 204 No Content – PATCH с trickle ICE (только новые кандидаты) принят; тело ответа отсутствует, новый ETag не возвращается.
• 200 OK – с новым SDP-фрагментом answer и новым ETag: ICE restart прошёл успешно; клиент обязан принять новый набор кандидатов.
• 405 Method Not Allowed – сервер не поддерживает PATCH на этом ресурсе сессии (ни trickle ICE, ни ICE restart).
• 422 Unprocessable Content – сервер поддерживает одну из двух операций, но не обе (§4.3.3); запрос PATCH обработать невозможно.
• 412 Precondition Failed – ETag в If-Match не совпадает с текущим состоянием сессии (ICE-сессия изменилась с момента последнего просмотра клиентом).
• 428 Precondition Required – в запросе отсутствует заголовок If-Match.

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

OPTIONS – обнаружение возможностей и CORS preflight (RFC 9725 §4.1)

Заголовок OPTIONS используется в двух целях. Первая – CORS-предварительная проверка: браузер, который собирается отправить POST-запрос на WHIP-эндпоинт, сначала отправляет OPTIONS, и RFC 9725 требует, чтобы WHIP-эндпоинт обрабатывал эту предварительную проверку с соответствующими Access-Control-Allow-Origin. Вторая – обнаружение возможностей: ответ 200 OK на OPTIONS-запрос должен содержать Accept-Post: application/sdp, чтобы сообщить, что эндпоинт принимает POST-запросы с SDP. Недавние релизы OBS Studio используют ответ на OPTIONS для получения серверных ICE-кандидатов ещё до отправки POST – это позволяет сократить один раунд обмена сообщениями при установлении соединения. Данный паттерн был добавлен в OBS 30.2 в середине 2025 года и теперь стал общепринятой оптимизацией.

Trickle ICE и ICE restart – зачем оба

ICE-механизм WebRTC отвечает за выбор оптимального сетевого пути между двумя конечными точками. Классический ICE (RFC 8445) предполагает, что обе стороны обмениваются полными списками кандидатов в SDP offer/answer, а затем запускают проверку соединения. Trickle ICE (RFC 8840) отменяет это требование – кандидаты можно передавать постепенно, по мере их обнаружения. Это ускоряет процесс, поскольку клиенту не нужно ждать завершения полного сбора кандидатов перед отправкой offer.

WHIP поддерживает trickle ICE через глагол PATCH. Поведение сервера асимметрично: серверные кандидаты всегда передаются полностью в исходном ответе 201 (§4.3.2: «the WHIP endpoint SHALL gather all the ICE candidates ... before responding»), а trickle ICE используется только клиентом. Причина прагматическая: у сервера обычно стабильные публичные адреса, и сбор кандидатов тривиален; клиент может находиться за NAT, собирая server-reflexive и relayed кандидаты за несколько сетевых round-trip-ов, и выигрывает от trickle ICE больше.

ICE restart – более сложный случай. Во время сессии нижняя сеть может измениться: мобильный энкодер переключается между сотовой и Wi-Fi, ноутбук в роуминге меняет IP-адрес, истекает NAT-биндинг – и существующая ICE-сессия становится недействительной. ICE restart требует от обеих сторон собрать новый набор кандидатов и повторно пройти проверки соединения, не прерывая медиа-канал. В WHIP клиент инициирует перезапуск, отправляя PATCH с If-Match: * (безусловная форма, §4.3.3) и телом, содержащим новый ice-ufrag, ice-pwd и обновлённый набор кандидатов. Сервер отвечает новым фрагментом SDP, новым ETag, и перезапуск продолжается.

Тонкий, но важный момент: §4.3.3 указывает, что и trickle ICE, и ICE restart RECOMMENDED, но не REQUIRED, и протокол предоставляет чистый способ отказаться от одной операции серверу, поддерживающему другую (ответ 422). В 2026 году все основные серверы, которые мы тестировали, поддерживают обе функции – Cloudflare Stream добавил поддержку ICE restart и trickle ICE в начале 2025 года, AWS IVS Real-Time имел обе функции с момента GA, Dolby Millicast – с 2024 года, Ant Media – с версии v2.10. У self-hosted медиа-серверов (Janus, mediasoup, LiveKit) поддержка зависит от версии; проверяйте release notes.

Аутентификация – Bearer-токены и почему их нужно использовать всегда

RFC 9725 §4.7 требует, чтобы все WHIP-эндпоинты, сессии и клиенты поддерживали HTTP-аутентификацию согласно §11 RFC 9110. В секции 4.7.1 далее чётко указано, что должна поддерживаться аутентификация по bearer-токенам: «bearer token authentication ... MUST be supported by all WHIP entities». Это означает, что каждый совместимый WHIP-сервер понимает заголовок Authorization: Bearer <token>, а каждый совместимый клиент умеет его отправлять.

На практике в каждом продакшен-внедрении WHIP используется Bearer-токен. Энкодер настраивается с WHIP endpoint URL и токеном (часто они передаются вместе в виде URL + ?token=... для удобства, но каноническая форма – заголовок). Сервер проверяет токен при каждом запросе – POST, PATCH, DELETE – и отклоняет неаутентифицированные запросы с кодами 401 или 403. RFC 9725 чётко указывает: токен «MUST NOT be sent in any request», если клиент не был сконфигурирован с ним – это закрывает небольшую уязвимость, при которой неаутентифицированный клиент мог бы случайно передать значение заголовка по умолчанию.

Жизненный цикл токена выходит за рамки RFC – спецификация намеренно не описывает, как токен выдаётся, обновляется или отзывается. На практике используются знакомые паттерны, характерные для любых HTTP API: короткоживущие JWT, подписанные сервисом аутентификации платформы (Cloudflare Stream, Dolby Millicast, AWS IVS); долгоживущие API-ключи (по умолчанию у большинства self-hosted серверов); подписанные URL для сессии (некоторые CDN добавляют слой подписи перед своим WHIP-эндпоинтом). Относитесь к токену как к обычному API-секрету: регулярно обновляйте, ограничивайте правами строго по необходимости и храните в менеджере секретов.

Криптографическая защита на проводе – двухуровневая: HTTPS защищает сигнальные данные (SDP offer, SDP answer, bearer-токен, обмен кандидатами), а DTLS-SRTP – медиа. DTLS-хэндшейк WebRTC PeerConnection генерирует мастер-ключи SRTP, которые шифруют каждый медиа-пакет end-to-end. Оба уровня обязательны в продакшене; в разделе §5 (Security Considerations) RFC указано: «HTTPS SHALL be used». Режим передачи в открытом виде отсутствует.

Каков реальный пол задержки

WebRTC проектировался с жёстким ограничением по end-to-end задержке – конференц-сценарий ориентирован на sub-300-ms glass-to-glass, – и WHIP наследует этот подход. Реалистичная цифра для contribution-пути по чистому сетевому каналу в 2026 году – от 200 до 800 миллисекунд glass-to-glass, в зависимости от конфигурации пути.

Арифметика вслух. Типичный энкодер выдаёт кадры со скоростью 30 кадров в секунду, то есть один кадр каждые 33 мс. К этому добавляется задержка конвейера самого энкодера (обычно 30–100 мс для аппаратного H.264, 50–150 мс для софтверного H.264, ещё больше – для HEVC или AV1), пакетизация DTLS- и SRTP, сетевой round-trip от энкодера до сервера (5–100 мс при маршруте в пределах одного региона, 100–200 мс – трансатлантический), буфер джиттера на стороне сервера (обычно 100–300 мс в WebRTC, настраивается) и downstream-пакетизация плюс буфер плеера, если поток транслируется зрителям. Самый чистый путь contribution-only – от энкодера до сервера, после чего сервер сразу передаёт медиа по протоколу доставки с задержкой менее секунды – даёт задержку 200–600 мс; путь, при котором на приёмной стороне происходит конвертация в HLS, добавляет задержку HLS (обычно 4–10 секунд).

Сравнение с SRT – прямое. SRT обычно настраивается на задержку 200–500 мс для проводного канала в пределах одной страны, а дополнительная арифметика, связанная с закрытием GOP и HLS-упаковкой, увеличивает общую задержку «от экрана до экрана» при использовании SRT→HLS до 8–12 секунд. Типичная задержка «от экрана до экрана» при использовании WHIP на аналогичном пути, завершающемся доставкой через WebRTC (WHEP на приёмной стороне), составляет около 400–800 мс. Разница – примерно в десять раз – и именно она делает выбор в пользу WHIP вместо SRT однозначным.

Другая важная ось: WHIP требует относительно чистого contribution-пути. Механизмы контроля перегрузки и буфер джиттера в WebRTC способны компенсировать несколько процентов потерь, но 5%-я потеря на спутниковом канале или при слабой сотовой связи – это ситуация, в которой WebRTC деградирует быстрее, чем SRT. Бюджет в 4× RTT у SRT даёт протоколу запас для агрессивных ретрансляций; у WebRTC хватает ресурсов только на одну-две ретрансляции, но не на многораундовый recovery. Для спутникового contribution-пути WHIP – неправильный выбор; правильным будет SRT.

Частые ошибки – что ломает WHIP в продакшене

Короткий список самых частых отказов при создании нового WHIP-канала. Большинство из них – не ошибки в протоколе, а проблемы с конфигурацией.

Грабли 1: ICE failure, потому что TURN не настроен. WebRTC требует TURN-сервер, когда обе стороны находятся за симметричными NAT, которые блокируют прямое p2p-соединение. Каждое продакшн-внедрение WHIP должно включать TURN-сервер (или использовать хостинговый – например, anycast TURN от Cloudflare, TURN от Twilio или кластер Coturn). Наиболее частая причина сбоя – энкодер возвращает «ICE failed», поскольку в SDP answer отсутствуют TURN-кандидаты. Решение – настроить WHIP-сервер на выдачу TURN-URL или использовать сторонний хостинговый TURN. Подробнее о механизмах NAT/STUN/TURN – в нашей статье.

Грабли 2: HTTPS не принуждён. RFC 9725 §5 гласит: «HTTPS SHALL be used». Некоторые self-hosted серверы поддерживают режим plaintext-HTTP для удобства локальной разработки – но никогда не используйте его в продакшене. Незашифрованный SDP передаёт bearer-токен по сети (он находится в заголовке Authorization POST-запроса), и утечка токена даёт злоумышленнику на пути к серверу права на ingest. Используйте HTTPS с валидным сертификатом на каждом WHIP-эндпоинте.

Грабли 3: Bearer-токен в URL query string. Некоторые вендоры предлагают «удобную» форму, при которой bearer-токен добавляется к URL как query-параметр. Такая форма не описана в RFC 9725, и её использование приводит к тому, что токен попадает во все HTTP-промежуточные звенья, логирующие URL (балансировщики, прокси, логи на edge CDN, история браузера). Используйте заголовок Authorization: Bearer <token>. Если документация вендора требует query-параметра – настаивайте на своём: каноническая форма – заголовок.

Грабли 4: несовпадение кодека с сервером. WHIP передаёт те кодеки, которые согласуются в SDP offer/answer. Если энкодер предлагает H.265 (HEVC), а сервер поддерживает только H.264 (AVC), предложение отклоняется. На середину 2026 года наиболее совместимыми кодеками остаются H.264 (универсальный), VP8 (поддерживается большинством серверов), Opus (универсальный для аудио); поддержка H.265, VP9 и AV1 растёт, но пока неравномерна. Перед настройкой энкодера обязательно проверяйте список поддерживаемых кодеков на платформе – несоответствие приводит к быстрому сбою, но с неясным сообщением об ошибке.

Грабли 5: trickle ICE не поддерживается сервером. Старые реализации WHIP-серверов (некоторые до сих пор используются с 2022–2023 годов) не поддерживают метод PATCH и отвечают кодом 405 Method Not Allowed на любой trickle ICE. Современные энкодеры, такие как OBS Studio 30+, по умолчанию используют trickle ICE, и ответ 405 от сервера приводит к разрыву соединения. Решение – обновить сервер или отключить trickle ICE на стороне клиента; в OBS для этого есть переключатель «Enable trickle ICE» в настройках WebRTC-сервиса. На практике в 2026 году все коммерческие платформы, которые мы тестировали, поддерживают trickle ICE; проблема возникает только с устаревшими self-hosted серверами.

Грабли 6: цена трафика TURN. Каждый relay-медиа-пакет (то есть пакеты, идущие через TURN-сервер, потому что прямой путь не удался) облагается платой за TURN-выходной трафик. Для 6 Мбит/с потока, полностью передаваемого через релей (наихудший случай – симметричный NAT), 6 Мбит/с TURN-выходного трафика становятся реальной статьёй расходов. Крупные облачные платформы в 2026 году берут $0,05–$0,40 за ГБ TURN-выходного трафика – по порядку величины сопоставимо со стоимостью CDN-выходного трафика. Учитывайте TURN-трафик при расчёте затрат: не полагайтесь на то, что соединение всегда будет прямым.

Кто реально поддерживает WHIP в 2026

Таблица ниже обобщает поддержку WHIP-ингеста по платформам, с которыми мы сталкивались в клиентских проектах в 2026 году. Данные актуальны на май 2026 года; перед окончательными архитектурными решениями рекомендуется сверяться с документацией вендора.

Тот же раскол, что и в истории с SRT: consumer-социалки медленно внедряют ingest-протоколы, потому что их RTMPS-пайплайны работают стабильно, а стоимость миграции высока. В то же время developer-платформы и современные B2B-видеосервисы запускают WHIP параллельно с RTMPS и SRT на одном эндпоинте. Везде, где раньше исторически использовали SRT для передачи с задержкой менее секунды, сегодня можно использовать WHIP – и в отличие от SRT, WHIP имеет опубликованный RFC и более широкую историю «нативного клиентского» использования в браузерах (любой современный браузер – это WHIP-клиент из коробки через RTCPeerConnection).

Рабочий пример – OBS транслирует в Cloudflare Stream по WHIP

Пройдёмся по одной конкретной конфигурации. Пушим 1080p30 H.264 на 6 Mbps из OBS Studio 30.2 на Mac mini с проводным Ethernet-аплинком на WHIP-endpoint Cloudflare Stream, обратно отдаём через WHEP в браузер-вкладку в той же сети для замера end-to-end задержки.

В OBS настройка прямая. Settings → Stream → Service: «WHIP». Server: https://customer-<id>.cloudflarestream.com/<key>/webrtc/publish. Bearer token: production-токен из Cloudflare dashboard. Settings → Output: x264, CBR, 6 Mbps, интервал ключевых кадров – 2 секунды (B-кадры отключены, потому что профиль WebRTC по умолчанию их не поддерживает). Settings → Audio: Opus, 48 кГц, 128 кбит/с. Это вся настройка энкодера.

OBS сначала отправляет HTTP OPTIONS на эндпоинт (оптимизация для OBS 30.2+), получает в ответ список TURN-URL сервера и собирает host- и server-reflexive-кандидаты через этот TURN. Затем отправляется HTTP POST с Content-Type: application/sdp, Authorization: Bearer <token> и SDP offer в теле. Offer содержит две медиа-секции: одна – для видео (H.264 baseline, режим send-only, с расширениями обратной связи SRT и SRTCP), вторая – для аудио (Opus, режим send-only), обе связаны единым ICE-каналом через механизм BUNDLE. WHIP-эндпоинт Cloudflare проверяет offer, формирует полный набор своих ICE-кандидатов (host-кандидаты в каждом регионе PoP, а также TURN-ретрансляторы), генерирует SDP answer с recvonly-секциями и полным перечнем кандидатов, после чего возвращает ответ с 201 Created, Location: /webrtc/sessions/<session-id> и ETag: "abc123...".

OBS получает ответ, устанавливает его в PeerConnection, запускается ICE. Проверка соединения находит кандидата-хост от Cloudflare в том же регионе (RTT около 15 мс). DTLS-хэндшейк завершается за два round-trip (~30 мс). Генерируются SRTP-ключи, и начинается передача медиа. Конечная задержка end-to-end от источника до зрителя, измеренная по миллисекундным часам на стороне источника и во вкладке WHEP-зрителя: примерно 380 мс.

В ходе сессии OBS собирает ещё один server-reflexive-кандидат (определение публичного IP завершается уже после начального POST) и отправляет PATCH с Content-Type: application/trickle-ice-sdpfrag, If-Match: "abc123..." и кандидатом в теле. Cloudflare отвечает 204 No Content (успешный trickle, нового ETag нет). Сессия длится 90 минут без перерывов; в конце OBS отправляет DELETE /webrtc/sessions/<session-id> с bearer-токеном; Cloudflare отвечает 200 OK и завершает сессию.

Сравним тот же путь через RTMPS: RTMPS в Cloudflare Stream, затем HLS-пакер от Cloudflare и, наконец, HLS-плеер в браузере – задержка «от стекла до стекла» составляет около 12 секунд. Формат протокола остаётся тем же – push-отправка от энкодера в облако – и наблюдаемое содержимое не меняется. Разница в задержке – почти в полтора порядка. Именно эта разница и является единственной причиной выбирать WHIP.

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

Когда выбирать WHIP – фреймворк решения

WHIP – правильный выбор для contribution в конкретных условиях. Ниже представлен фреймворк, по которому мы проводим клиентов при проектировании архитектуры contribution на 2026 год.

Выбирайте WHIP, когда: (а) бюджет задержки меньше одной секунды glass-to-glass хотя бы на участке contribution+delivery; (б) путь между энкодером и сервером – проводной или стабильный 5G/Wi-Fi-канал с ожидаемой потерей пакетов менее 1%; (в) целевая платформа поддерживает WHIP (Cloudflare Stream, AWS IVS Real-Time, Dolby Millicast, Mux Live, MediaLive, Ant Media, LiveKit, Wowza, THEO или любой self-hosted сервер из списка выше); (г) экосистема энкодера поддерживает WHIP (OBS 30+, FFmpeg 7, Larix Broadcaster, Wirecast или любой аппаратный энкодер, реализовавший WHIP в 2026 году – Magewell Pro Convert с WHIP, AJA HELO Plus с прошивкой 2025, Teradek с прошивкой 2025, Haivision Pro 460 с прошивкой 2024+).

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

Выбирайте RTMPS, когда: цель – consumer-соцсети (YouTube, Twitch, Facebook, Kick, TikTok), для которых RTMPS – единственный поддерживаемый способ приёма потока. Технически это решение хуже, но операционно – без альтернатив для этих задач.

Выбирайте RIST, когда: требование соответствия SMPTE явно предписывает использование спецификации SMPTE TR-06, либо существующий вещательный пайплайн уже работает на RIST.

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

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

Мы внедряли WHIP-основанные contribution-стеки в нескольких вертикалях с момента стабилизации протокола: телемедицинские решения, где клиническая камера передаёт поток на центральный WebRTC-сервер для консультаций с задержкой менее секунды; e-learning-платформы для записи живых занятий, где преподаватели отправляют поток на WHIP-эндпоинт, который далее транслируется через WHEP и LL-HLS; live-торговля и аукционы, где ведущий транслирует через WHIP, а зрители получают контент по пути доставки с задержкой менее секунды; AR/VR-мероприятия в реальном времени, где WHIP-путь укладывается в бюджет, необходимый для комфортного восприятия человеком. Паттерн остаётся стабильным: когда contribution-путь прост и латентность является ключевым фактором, WHIP – правильный выбор, а минимальная спецификация RFC делает интеграцию с несколькими бэкендами недорогой.

Ключевые выводы

• WHIP стандартизирует передачу WebRTC-данных как один HTTP POST с SDP-offer в теле и возвращает ответ 201 Created с SDP-answer.
• RFC 9725 опубликован в марте 2025 года как Proposed Standard в рамках Standards Track; протокол стал стандартным путём для субсекундной передачи медиа.
• Полная функциональность протокола включает четыре HTTP-метода (POST, DELETE, PATCH, OPTIONS) и два URL-адреса (endpoint, session).
• ETag и If-Match обеспечивают механизм управления состоянием, безопасно контролируя перезапуск ICE; при использовании trickle ICE применяется PATCH с application/trickle-ice-sdpfrag.
• Bearer-токен обязателен в каждом совместимом с WHIP решении; никогда не передавайте токен в параметрах строки запроса URL.
• Реальная задержка «от экрана до экрана»: 200–500 мс при проводном соединении в одном регионе, 400–800 мс при трансатлантической передаче, 3–6 с при использовании LL-HLS для потребителей.
• WHIP предназначен для чистых низколатентных каналов, SRT – для сетей с потерями, RTMPS – для потребительских социальных платформ, RIST – для соответствия стандартам SMPTE.

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

• SRT: профессиональный стандарт для контрибуции по публичному интернету – альтернатива для lossy-путей; задержка выше, но восстановление от потерь эффективнее.
• WHEP – egress WebRTC по HTTP – парный протокол доставки; в паре с WHIP обеспечивает end-to-end задержку менее секунды.
• Как выбрать ингест-протокол в 2026: дерево решений – полное дерево решений по всем пяти современным протоколам контрибуции.

CTA

Поговорить с инженером по стримингу · Посмотреть кейсы · Скачать чек-лист интеграции WHIP (PDF)