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; release notes OBS Studio 30+ и исходниками obs-webrtc; документации и changelog Cloudflare Stream WHIP/WHEP до мая 2026; документации AWS Elemental MediaLive и AWS IVS Real-Time по WHIP publishing; референсной документации 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, – это standards-track ответ на вопрос «как запушить живой WebRTC-поток на сервер, не написав кастомный код сигнализации». IETF опубликовал его как RFC 9725 в марте 2025 года (Standards Track, статус «Proposed Standard») после трёх с половиной лет работы рабочей группы WISH; в 2026 году протокол стал стандартным sub-секундным contribution-путём для каждого современного developer-platform live-сервиса. На проводе всё предельно просто: энкодер отправляет один HTTP POST с SDP offer в теле, сервер возвращает 201 Created с SDP answer и заголовком Location, указывающим на ресурс сессии; один HTTP DELETE завершает сессию. В 2026 WHIP – правильный выбор для contribution, когда бюджет задержки меньше секунды на относительно чистом канале, а целевая экосистема энкодеров (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-ingest было индивидуальным проектом. Каждая платформа изобретала свой протокол сигнализации – у Janus был один, у mediasoup другой, у LiveKit третий, у Millicast четвёртый, у Twilio пятый – и энкодер, работавший с одним вендором, без вендор-специфичного SDK не работал ни с каким другим. WebRTC как медиа-уровень был открытым стандартом, а WebRTC как путь contribution – vendor-lock. Именно эта одна проблема двадцать лет держала вещательную индустрию на RTMP.

WHIP закрывает проблему минимально возможной поверхностью: один HTTP POST заменяет десяток кастомных протоколов сигнализации. Энкодер, говорящий на WHIP, пушит на любой сервер, говорящий на WHIP, точка. Тот же OBS, который сегодня пушит в Cloudflare Stream, завтра пушит в AWS IVS, в пятницу в Dolby Millicast, в субботу в self-hosted Ant Media – без правки чего-либо, кроме URL и Bearer-токена. Эта переносимость и есть причина значимости протокола. Эта статья – канонический справочник по WHIP для инженеров, продактов и архитекторов, выбирающих contribution-стек в 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 на session URL; сервер возвращает 200 OK, разбирает состояние ICE/DTLS и освобождает медиа-ресурсы. Если энкодер просто исчез, сервер замечает потерю через собственные keepalive и ICE-connectivity-check таймеры 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 contribution-путь был кастомной интеграцией. WebRTC как стандарт, опубликованный W3C и IETF между 2011 и 2018 годами, определил медиа-уровень (PeerConnection, RTCDataChannel, грамматика SDP, DTLS-SRTP, ICE/STUN/TURN), но сознательно оставил сигнализацию вне своего scope. Логика W3C была такая: требования к сигнализации сильно зависят от приложения – у видеоконференции одни, у одностороннего broadcast другие, – пусть вендоры выбирают правильный инструмент под каждый случай. На практике эта свобода вылилась во фрагментацию. Каждый WebRTC-серверный вендор изобретал свою сигнализацию: Janus использовал WebSocket + JSON-протокол, mediasoup – request/response JSON по WebSocket, Twilio – проприетарный signalling SDK, Vidyo, Tokbox – каждый своё. Энкодеру, чтобы зайти в WebRTC-пайплайн, нужен был вендор-специфичный SDK под каждый целевой сервер.

В конце 2020 года Серхио Гарсия Мурильо из Millicast и Александр Гуайяр из CoSMo Software подали в IETF первый Internet-Draft по WHIP (draft-ietf-wish-whip-00), предложив единый HTTP-сигнализационный слой для конкретного случая односторонней contribution. Замысел был сознательно минимален: не пытаться стандартизировать сигнализацию вообще, а стандартизировать один самый распространённый случай – энкодер пушит один медиа-поток на сервер, – а более сложные случаи оставить вендор-специфичными. IETF в 2021 году учредил рабочую группу 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 пошёл противоположным путём. Гарсия Мурильо и Гуайяр держали scope сознательно узким, поверхность – крошечной, и провели документ через процесс 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; иначе сервер «MUST reject the HTTP POST request with an appropriate 4xx error response» (§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 SHALL содержать полный список серверных кандидатов, – поэтому клиент получает полный набор кандидатов в теле answer и не должен ждать дополнительной серверной сигнализации. Сервер возвращает answer ответом 201 Created с Content-Type: application/sdp и телом answer. Два заголовка ответа несут оставшуюся идентичность сессии: Location указывает на WHIP session URL (URL, который позже используется для PATCH и DELETE), и, если сервер поддерживает ICE restart, заголовок ETag – «unique strong entity-tag identifying the ICE session» (§4.3.1).

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

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

Когда энкодер закончил, он отправляет HTTP DELETE на WHIP session URL (тот URL, который сервер вернул в заголовке Location исходного POST). Сервер разбирает ICE и DTLS, освобождает медиа-ресурсы и возвращает 200 OK. DELETE – единственный «чистый» способ закрыть сессию; если энкодер исчез без DELETE, сервер опирается на собственные keepalive и ICE-connectivity-check таймеры 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, либо литеральная * для безусловного restart.

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

• 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 – ключевой кусок state machinery протокола: именно он даёт клиенту понять, актуальна ли его картина мира ICE-сессии, и именно он позволяет серверу безопасно отклонять запросы restart, которые гонятся друг с другом.

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

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

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

ICE-машинерия WebRTC отвечает за выбор лучшего сетевого пути между двумя endpoint-ами. Классический ICE (RFC 8445) предполагает, что обе стороны обмениваются полными списками кандидатов в SDP offer/answer и только потом начинают connectivity checks. 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 делает только клиент. Причина прагматическая: у сервера обычно стабильные публичные адреса и сбор кандидатов тривиален; клиент может сидеть за NAT-ом, собирая server-reflexive и relayed кандидаты несколько сетевых round-trip-ов, и выигрывает от trickle сильнее.

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

Тонкий, но важный момент: §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 media-сервера (Janus, mediasoup, LiveKit) – как повезёт с версией; проверяйте release notes.

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

RFC 9725 §4.7 предписывает всем WHIP-endpoint-ам, сессиям и клиентам поддерживать 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», если клиент не был сконфигурирован с ним, – это закрывает мелкую дыру, в которой неаутентифицированный клиент мог бы случайно слить дефолтное значение заголовка.

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

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

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

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

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

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

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

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

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

Грабли 1: ICE failure, потому что TURN не настроен. WebRTC нужен TURN-сервер, когда обе стороны сидят за симметричными NAT-ами, не пускающими прямой p2p. Каждое продакшен-внедрение WHIP должно поставлять TURN-сервер (или использовать платформенный hosted 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-endpoint.

Грабли 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), offer отвергается. На середину 2026 года широко совместимые кодеки – H.264 (универсально), VP8 (большинство серверов), Opus (универсально для аудио); поддержка H.265, VP9 и AV1 растёт, но неравномерна. Проверяйте список принимаемых кодеков платформы до настройки энкодера; несовпадение проваливается быстро, но с невнятным сообщением об ошибке.

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

Грабли 6: цена трафика TURN. Каждый relay-медиа-пакет (то есть пакеты, идущие через TURN-сервер, потому что прямой путь не получился) стоит TURN egress. Для 6 Mbps-потока, полностью ушедшего на relay (worst-case симметричный NAT), 6 Mbps TURN egress – это реальный счёт. Крупные облачные платформы берут $0,05–$0,40 за GB TURN egress в 2026 году, что соответствует CDN egress по порядку. Закладывайте TURN-трафик в модель затрат; не считайте, что соединение всегда уйдёт по direct.

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

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

Раскол тот же, что в истории с SRT, в том же направлении и по той же причине: consumer-социалки медленно добавляют ingest-протоколы, потому что их RTMPS-пайплайны работают и стоимость миграции высока; developer-платформы и современные B2B-видеосервисы выкатывают WHIP параллельно с RTMPS и SRT на одном endpoint. Везде, где исторически вы поставили бы SRT для sub-секундного contribution, сегодня можно поставить WHIP – и в отличие от SRT, WHIP идёт с опубликованным RFC и более широкой «browser-native client» историей (любой современный браузер – это 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, keyframe interval 2 секунды (B-frames disabled, потому что дефолтный профиль WebRTC их не согласует). Settings → Audio: Opus, 48 kHz, 128 kbps. Это вся настройка энкодера.

OBS сначала шлёт HTTP OPTIONS на endpoint (оптимизация 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, с feedback-расширениями SRT и SRTCP), одна на аудио (Opus, send-only), – связанные одним ICE-транспортом через BUNDLE. WHIP-endpoint Cloudflare валидирует offer, собирает полный набор своих ICE-кандидатов (host-кандидаты в каждом регионе PoP плюс TURN-relay), генерирует SDP answer с recvonly-секциями и полным списком кандидатов и возвращает 201 Created с Location: /webrtc/sessions/<session-id> и ETag: "abc123...".

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

В ходе сессии 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-плеер в браузере: glass-to-glass около 12 секунд. Форма протокола та же – push contribution от энкодера в облако – и наблюдаемое содержание то же. Разница в задержке – полтора порядка. Эта разница и есть единственная причина выбирать 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, когда: путь contribution лоссовый (спутник, агрессивная сотовая, transcontinental на пике конгестии), либо энкодер – классическая broadcast-«железка», не говорящая на WebRTC. Селективная ретрансляция и более длинный latency-бюджет SRT восстанавливают потери там, где WebRTC деградирует.

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

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

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

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

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

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

• WHIP стандартизирует WebRTC contribution как один HTTP POST с SDP offer в теле и ответ 201 Created с answer.
• RFC 9725 опубликован как Standards Track / Proposed Standard в марте 2025; протокол – дефолтный sub-секундный contribution-путь.
• Полная поверхность протокола – четыре HTTP-глагола (POST, DELETE, PATCH, OPTIONS) против двух URL (endpoint, session).
• ETag + If-Match – state machinery, безопасно гейтящая ICE restart; trickle ICE использует PATCH с application/trickle-ice-sdpfrag.
• Bearer-токен обязателен в каждом совместимом WHIP-внедрении; никогда не кладите токен в query-параметр URL.
• Реальная glass-to-glass задержка: 200–500 ms same-region wired, 400–800 ms transatlantic, 3–6 s с LL-HLS downstream.
• WHIP для чистых низколатентных путей, SRT для лоссовых, RTMPS для consumer-социалок, RIST для SMPTE-комплаенса.

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

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

CTA

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