WHEP: HTTP-сигнализация для egress WebRTC

Последняя проверка: 2026-05-21 по IETF Internet-Draft draft-ietf-wish-whep-03 WebRTC-HTTP Egress Protocol (WHEP) (S. Garcia Murillo, C. Chen, D. Jenkins – опубликован 18 августа 2025 года, истёк 19 февраля 2026 года; статус-цель «Proposed Standard»; статус в рабочей группе – «Revised I-D Needed»); архиву рабочей группы IETF WISH и календарю milestone; документации Cloudflare Stream по WebRTC и changelog по май 2026; changelog платформ Dolby, Millicast и OptiView; документации OvenMediaEngine по май 2026; и парному документу WHIP – IETF RFC 9725 от марта 2025 года.

TL;DR

WHEP, или WebRTC-HTTP Egress Protocol, – это зеркальное отражение WHIP для воспроизведения: один HTTP POST-запрос со стороны зрителя возвращает SDP answer и запускает поток WebRTC-медиа. Рабочая группа IETF WISH разрабатывает черновики WHEP с 2022 года, однако по состоянию на май 2026 года документ остаётся draft-ietf-wish-whep-03 – просроченным Internet Draft с последней правкой в августе 2025 года, а не RFC. Этот разрыв в статусе по сравнению с уже опубликованным WHIP RFC – ключевой факт 2026 года и причина, по которой каждое внедрение в продакшене сегодня технически ориентировано на движущуюся цель. WHEP – правильный выбор для доставки, когда задержка должна оставаться ниже секунды и вы контролируете обе стороны: и энкодер (через WHIP), и плеер; во всех остальных сценариях HLS, LL-HLS и LL-DASH по-прежнему являются более безопасными вариантами по умолчанию.

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

Двадцать лет индустрия стриминга использовала один стандарт для приёма контента (RTMP) и один – для воспроизведения (HLS), и эта асимметрия – отправка одним семейством протоколов, получение другим – просто воспринималась как данность. Публикация WHIP в виде RFC 9725 в 2025 году начала закрывать сторону contribution. WHEP, симметрично, призван закрыть сторону playback: он даёт браузеру, смарт-ТВ или мобильному приложению единый стандартизованный способ запросить WebRTC-поток у любого совместимого сервера. Обещание – такое же, как у WHIP, только на стороне приёмника: переносимость. Плеер, который вы пишете сегодня, должен работать с любым WHEP-сервером завтра.

Но WHEP – это ещё и история о том, насколько медленно на самом деле продвигаются стандарты. По состоянию на май 2026 года вы можете запустить WHEP в продакшене уже сегодня – Cloudflare Stream, Dolby Millicast, OvenMediaEngine, MediaMTX, Janus, LiveKit, Ant Media и ещё несколько вендоров его поддерживают, – однако черновик IETF так и не стал RFC, рабочая группа находится в статусе «Revised I-D Needed», а последняя версия документа датируется августом 2025 года. Эта статья – канонический справочник по текущему состоянию WHEP для инженеров, продактов и архитекторов, рассматривающих его для delivery-стека 2026 года: что именно говорит черновик, чем он отличается от WHIP, как на практике выглядят расширения выбора слоёв и событий, какие платформы его поддерживают, какой у него реальный пол задержки и что означает нерешённый стандартный риск для процедур закупки.

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

WHEP, WebRTC-HTTP Egress Protocol, – это тонкий HTTP-слой, позволяющий зрителю установить, поддерживать и завершить сессию воспроизведения WebRTC на медиа-сервере. Протокол выполняет одну задачу: он предоставляет зрителю стандартизированный способ принять одну WebRTC-медиа-сессию – единый поток аудио и видео, объединённый в bundle и передаваемый от сервера к зрителю, – и корректно завершить её. Всё остальное – транспорт данных, кодеки, шифрование, управление перегрузкой – соответствует стандартному WebRTC в рамках действующих спецификаций W3C и IETF. По структуре протокол напоминает WHIP, но работает в обратном направлении.

Два URL – это WHEP endpoint URL (куда зритель отправляет POST-запрос, чтобы начать сессию воспроизведения) и WHEP session URL (возвращается в заголовке Location ответа 201 и используется для всех последующих операций). Глаголы: POST (начать сессию), DELETE (закрыть сессию), PATCH (в двух ролях – либо обновить ICE, либо передать SDP-ответ зрителя на server counter-offer), OPTIONS (preflight CORS и проверка возможностей), GET (возвращает пустой 2XX-ответ, полезен только для проверки работоспособности). Это и есть весь протокол – всё остальное в драфте описывает точные требования к содержанию каждого запроса и ответа.

Механически: зритель формирует SDP offer для одного WebRTC PeerConnection (единый bundle-поток аудио и видео, направление recv-only, с использованием шифрования DTLS-SRTP), сериализует offer в текст и отправляет его в теле HTTP POST с заголовком Content-Type: application/sdp на WHEP-эндпоинт. У сервера есть два возможных варианта ответа: если он может принять offer без изменений, он возвращает 201 Created с SDP answer в теле и URL сессии в заголовке Location; если offer принять невозможно (например, зритель запросил кодек, который сервер не поддерживает), сервер возвращает 406 Not Acceptable с собственным SDP counter-offer в теле, и зритель должен ответить SDP answer, отправив его в теле PATCH-запроса к ресурсу сессии. Эта двухпутевая переговорная схема – главное механическое отличие WHEP от WHIP и основная причина, по которой большинство продакшн-реализаций WHEP вообще не используют путь с counter-offer – они жёстко задают кодек и полагаются на «счастливый путь» 201 Created.

После завершения обмена offer/answer происходит обмен ICE-кандидатами (серверные кандидаты приходят целиком в первом ответе, а зритель затем отправляет свои по мере поступления через trickle), завершается DTLS-рукопожатие, и SRTP-медиа начинает передаваться от сервера к зрителю. Зритель завершает сессию с помощью HTTP DELETE по URL сессии; если зритель внезапно исчезает, сервер обнаруживает разрыв соединения по стандартным таймерам проверки связности ICE в WebRTC и самостоятельно завершает сессию.

Транспорт на проводе – то, что использует WebRTC: UDP с ICE-кандидатами типов host, server-reflexive и relayed, DTLS для шифрования, SRTP для передачи медиа. Соответственно, WHEP наследует от WebRTC обход NAT (STUN/TURN, подробно в нашей статье) и механизм контроля перегрузки. Сигнализация осуществляется по HTTP/1.1 или HTTP/2; версия драфта не регламентируется.

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

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

WHEP появился в 2021 году как индивидуальный Internet-Draft (draft-murillo-whep-00), написанный тем же Серхио Гарсией Мурильо из Millicast, что и был соавтором WHIP. Мотивация была простой: если WHIP стандартизирует передачу (contribution) в WebRTC, то и путь воспроизведения (playback) должен использовать аналогичный подход – иначе вендоры стандартизируют простую сторону, а сложную оставят фрагментированной. Рабочая группа IETF WISH в 2022 году приняла эту работу как draft-ietf-wish-whep-00, поставив перед собой цель подать документ в IESG для публикации к декабрю 2024 года.

Этот этапный результат сместился вправо. Рабочая группа выпустила четыре версии – от -00 до -03, – причём последняя (draft-ietf-wish-whep-03) была опубликована 18 августа 2025 года и истекла без обновления 19 февраля 2026 года. Текущий статус в IETF datatracker – «Expired» на уровне IESG и «Revised I-D Needed – Issue raised by WG» на уровне рабочей группы, что на простом языке означает: в документе остались нерешённые вопросы, которые рабочая группа должна устранить перед повторной подачей. Целевой статус для RFC – «Proposed Standard». Авторы – S. Garcia Murillo (Millicast), C. Chen (ByteDance) и D. Jenkins (Everycast Labs Ltd), последний выступает в роли редактора.

Эта ситуация неудобна по двум причинам. Во-первых, сам черновик содержит стандартную для IETF формулировку: «It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.'» – по конвенции IETF такие документы не считаются стабильными ссылками. Во-вторых, каждый вендор, предлагающий WHEP сегодня, ориентируется на неустойчивую цель: часть из них до сих пор следует более раннему индивидуальному черновику (draft-murillo-whep-01), поскольку под него написаны их клиентские библиотеки плееров. Например, документация Cloudflare прямо указывает, что её реализация следует draft-murillo-whep-01, а не черновику рабочей группы.

Полезный контраст: WHIP – это 16 черновиков и три с половиной года работы рабочей группы; WHEP – три черновика и три года, без опубликованной эталонной реализации со стороны IETF (как dash.js закрепляет DASH для DASH-IF). Движение по standards-track медленное в любом протоколе, но конкретный блокер WHEP – не технические разногласия, а необходимость зафиксировать более сложную семантику в стабильном тексте: согласование кодеков, управление ресурсами со стороны зрителя, вопрос с расширением events-стрима. Протокол работает в продакшене потому что каждый разработчик принял локальные решения там, где спецификация оставила поле открытым.

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

Поверхность протокола минимальна. Дальше – краткий обзор проводной механики в том порядке, в котором её видит зритель.

POST – начать сессию (§4.2)

Зритель формирует SDP offer для одного WebRTC PeerConnection и отправляет его в теле HTTP POST-запроса на WHEP-эндпоинт. Запрос должен содержать Content-Type: application/sdp. В SDP offer действуют ограничения: направление recvonly (или sendrecv – для зрителя, передающего обратный аудиоканал, что является редким случаем); направления inactive и sendonly в offer’ах зрителя запрещены; сессия должна объединять все медиа в один транспорт (§4.5.1, политика max-bundle); допускается ровно один MediaStream (§4.5.2). В рамках этих ограничений всё, что разрешено в WebRTC, разрешено и в WHEP offer.

У сервера три возможных ответа. Самый распространённый – 201 Created (§4.2.1): сервер принимает offer без изменений, формирует SDP answer с направлением sendonly, собирает свои ICE-кандидаты ещё до отправки ответа и возвращает answer в теле с двумя заголовками: Location (указатель на URL сессии) и ETag (начальный entity-Tag, идентифицирующий ICE-сессию; обязателен, если поддерживается перезапуск ICE).

Второй ответ – 406 Not Acceptable (§4.2.2): сервер не принял offer зрителя, но готов к переговорам и возвращает в теле свой SDP counter-offer. В ответе тот же Location с указанием ресурса сессии и параметром valid-until в Content-Type, который сообщает, сколько времени counter-offer остаётся актуальным (по умолчанию – 30 секунд). Зритель должен ответить SDP answer’ом (направление recvonly), отправив его в теле PATCH-запроса на URL сессии с Content-Type: application/sdp; сервер подтверждает 204 No Content. Такой двухшаговый обмен counter-offer уникален для WHEP – в WHIP его нет, поскольку offer всегда определяет энкодер, а сервер его просто принимает.

Третий ответ – ошибка: 4XX при повреждённом SDP или отсутствии авторизации; 409 Conflict с заголовком Retry-After, когда у потока ещё нет активного паблишера (§4.2.8 – важный случай «зритель пришёл раньше броадкастера»); или 503 Service Unavailable, когда сервер не может выделить ресурсы (§4.6).

DELETE – закрыть сессию (§4.3)

Когда зритель завершает сеанс, он отправляет HTTP DELETE-запрос на URL сессии WHEP. Сервер завершает ICE и DTLS, освобождает медиа-ресурсы и возвращает 200 OK. DELETE – единственный надёжный способ корректно завершить сессию; если зритель не отправил DELETE, сервер полагается на таймеры проверки соединения ICE в WebRTC и механизм актуальности согласия (consent freshness, RFC 7675), которые обычно обнаруживают потерю связи в течение нескольких секунд и автоматически завершают состояние сессии.

PATCH – две разные задачи (§4.4 и §4.2.2)

PATCH в WHEP содержит два принципиально разных тела в зависимости от задачи. Первая задача, уже упомянутая выше, – передать SDP answer зрителя, когда сервер возвращает counter-offer: клиент отправляет Content-Type: application/sdp, сервер отвечает 204 No Content.

Вторая задача – и более распространённая – обновление ICE-состояния в ходе активной сессии (§4.4). Тело запроса – Content-Type: application/trickle-ice-sdpfrag (формат SDP-фрагмента для trickle ICE из RFC 8840), и запрос должен содержать заголовок If-Match. Существует два подварианта. PATCH с trickle-ICE (только новые кандидаты, без перезапуска) передаёт If-Match: "<текущий-etag>", сервер отвечает 204 No Content, при этом новый ETag не выдаётся. PATCH с перезапуском ICE передаёт буквальное значение If-Match: * (wildcard), сервер отвечает 200 OK, с телом application/trickle-ice-sdpfrag, содержащим новые ufrag/pwd и обновлённый набор серверных кандидатов, а также новым заголовком ETag, идентифицирующим новую ICE-сессию.

Коды ответа описывают интерпретацию сервера: 204 No Content (trickle прошёл), 200 OK с новым ETag (restart прошёл), 412 Precondition Failed (If-Match ETag не совпал – состояние сессии ушло вперёд), 428 Precondition Required (запрос не содержал If-Match вообще), 422 Unprocessable Content (сервер поддерживает один из вариантов trickle / restart, но не оба, §4.4.1). Механика ETag та же, что и в WHIP – она позволяет клиенту определить, актуальна ли его модель сессии.

OPTIONS и GET – preflight и health (§4.1, §4.3)

OPTIONS используется по двум причинам. Первая – CORS-предварительная проверка (preflight): перед отправкой POST-запроса на WHEP-эндпоинт браузер выполнит запрос OPTIONS, и этот эндпоинт должен корректно обработать preflight, вернув нужные заголовки Access-Control-Allow-Origin. Вторая – объявление возможностей: ответ 200 OK на OPTIONS должен содержать Accept-Post: application/sdp. GET-запрос к эндпоинту или URL сессии возвращает статус 2XX без тела – он полезен только для проверки доступности ресурса.

Выбор слоя, события и расширения – открытые края

Здесь драфт тоньше всего, и именно здесь больше всего расходятся реализации в продакшене.

Две функции, востребованные многими WHEP-плеерами, – выбор simulcast- или SVC-слоя для приёма и получение server-push-событий вроде «паблишер только что остановился» или «зрителей сейчас 8427» – в драфте не специфицированы. В документе предусмотрен extension-фреймворк (§4.9 и §6), согласно которому «расширения анонсируют себя через заголовок Link в ответе 201 Created с атрибутом rel, содержащим IANA-зарегистрированный URN с префиксом urn:ietf:params:whep:ext:», и приводится один пример гипотетического расширения для Server-Sent Events – однако он дан исключительно в иллюстративных целях, не является нормативным, и документ прямо указывает: «this document does not specify such an extension». Ранее отдельные драфты (draft-murillo-whep-*) включали JSON-API для выбора слоёв и поток событий SSE, но эти элементы были удалены до утверждения рабочей группой, оставив пространство для реализации вендорам.

На практике каждый вендор решил обе проблемы по-своему. Cloudflare предоставляет выбор слоёв через отдельный HTTP-эндпоинт на уровне сессии, принимающий JSON-тело с полями {mediaId, rid, spatialLayerId, temporalLayerId} – форма, которая встречалась в более ранних черновиках. Dolby Millicast использует SSE-канал, обнаружимый по заголовку Link, для событий типа viewercount, active, inactive, layers. OvenMediaEngine реализует выбор слоёв через параметры запроса в URL сессии WHEP. Ни одно из этих расширений не совместимо между вендорами на уровне передачи данных. Плеер, способный взаимодействовать с endpoint’ом выбора слоёв от Cloudflare, не сможет работать с Millicast.

Для закупок эта фрагментация важнее самого текста драфта. Провайдер достаточно совместим, чтобы зритель OvenMediaEngine мог воспроизвести поток Millicast; управляемый плейбэк – например, переключение на нижний simulcast-слой или прослушивание конца потока – несовместим. Расширения у вендоров обычно хорошо документированы, но это вендор-специфичные интерфейсы, под которые требуется отдельная интеграция на каждой платформе.

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

Драфт указывает (§4.8), что «все WHEP-эндпоинты, сессии и клиенты должны поддерживать HTTP-аутентификацию», а в (§4.8.1) говорится, что «аутентификация с использованием bearer-токена ... должна поддерживаться всеми WHEP-сущностями». Любой совместимый WHEP-сервер распознаёт заголовок Authorization: Bearer <token>, а любой совместимый клиент умеет его отправлять. Если клиент не настроен с токеном, спецификация дополнительно требует, чтобы этот заголовок не отправлялся ни в одном запросе – тем самым закрывается лазейка, через которую могло бы утечь значение по умолчанию или устаревшее значение.

В отличие от WHIP, где bearer-токен почти всегда привязан к стабильной идентичности паблишера (аккаунт броадкастера), у WHEP-токенов в продакшене более сложные жизненные циклы. Некоторые вендоры выпускают короткоживущие per-viewer JWT, ограниченные одной сессией и подписанные платформенным auth-сервисом; другие используют токены уровня потока, которые может предъявить любой авторизованный зритель; третьи поддерживают «открытые» потоки, не требующие токена вообще – в этом случае заголовок Authorization просто отсутствует. Для платного контента токен становится гейтом. Относитесь к нему как к любому API-ключу: короткий TTL, минимальные привилегии (по возможности – только на один поток), хранение в секрет-менеджере.

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

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

WHEP наследует бюджет задержки WebRTC. Реалистичная цифра для полного пайплайна WHIP → WHEP на чистой сети в 2026 году – от 200 до 800 миллисекунд «стекло к стеклу», в зависимости от географии и конфигурации.

Арифметика вслух. Возьмём типичный поток с частотой 30 кадров в секунду – один кадр приходит каждые 33 мс. Добавим задержку конвейера энкодера (30–100 мс для аппаратного H.264), пакетизацию DTLS- и SRTP, сетевой RTT на стороне приёмника (5–100 мс в пределах одного региона), маршрутизацию медиа внутри сервера (10–50 мс в SFU), сетевой RTT на стороне отправки (5–100 мс в пределах одного региона) и буфер джиттера на стороне WHEP (обычно 100–300 мс в WebRTC, настраиваемый). На проводном соединении в пределах одного региона суммарная задержка составляет около 300–500 мс; при трансатлантической передаче она удваивается.

Сравнение end-to-end с альтернативами:

Второе важное измерение: WHEP, как и любая доставка на основе WebRTC, требует относительно стабильного канала воспроизведения. Механизмы контроля перегрузки и буферизации джиттера в WebRTC терпят несколько процентов потерь, но 5%-ные потери в условиях враждебной мобильной сети или перегруженной домашней Wi-Fi приводят к заметному ухудшению качества. HLS-плеер при этом адаптируется, переключаясь на более низкий битрейт; WHEP-плеер же просто зависает. Интуиция индустрии 2026 года – использовать LL-HLS для «низкой задержки на массовых и шумных сетях»; использовать WHEP для «субсекундной задержки на чистых сетях при умеренном количестве зрителей» – хорошо описывает этот компромисс.

Конкретный пример – плейбэк Cloudflare Stream через WHEP

Проследим одну конкретную конфигурацию. Воспроизводим поток 1080p30 H.264 на 6 Mbps с WHEP endpoint Cloudflare Stream в браузере Chrome на проводном Ethernet, против потока, который сейчас в этот же Cloudflare-аккаунт пушит OBS-энкодер через WHIP.

Клиентский код прост. Браузер создаёт RTCPeerConnection, добавляет два RTCRtpTransceiver в режиме recvonly – один для видео, другой для аудио – вызывает createOffer() и затем передаёт fetch(WHEP_URL, { method: 'POST', headers: { 'Content-Type': 'application/sdp', 'Authorization': 'Bearer ' + token }, body: offer.sdp }). WHEP-эндпоинт Cloudflare валидирует offer, собирает полный набор ICE-кандидатов (host-кандидаты в каждом регионе Cloudflare PoP, а также TURN-ретрансляторы), формирует SDP answer с медиа-секциями sendonly и полным списком кандидатов, после чего возвращает 201 Created с Location: /webrtc/sessions/<viewer-session-id> и ETag: "view-abc123...".

Браузер принимает answer, вызывает pc.setRemoteDescription(answer), запускается ICE – проверка соединения успешно завершается на host-кандидате Cloudflare в том же регионе (RTT около 15 мс). DTLS-рукопожатие проходит за два раунда (~30 мс). Генерируются SRTP-ключи, и медиа начинает передаваться с сервера зрителю. Срабатывает событие RTCPeerConnection.ontrack на видео- и аудиотреке; приложение подключает их к <video> через videoElement.srcObject = stream – начинается воспроизведение. End-to-end задержка glass-to-glass, измеренная по миллисекундным часам на исходной камере и в вкладке WHEP браузера, составляет примерно 380 мс.

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

Сравним с тем же контентом через HLS. Тот же OBS-энкодер, тот же Cloudflare-аккаунт, но зритель запрашивает HLS-манифест вместо установки WHEP-сессии: задержка «стекло к стеклу» составляет около 12 секунд. При использовании LL-HLS на том же контенте задержка снижается до примерно 4 секунд. ~380 мс у WHEP – это на полтора порядка ниже, чем у HLS, и в десять раз меньше, чем у LL-HLS. Именно эта цифра имеет решающее значение при выборе сценария использования.

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

Какие платформы реально поддерживают WHEP в 2026 году

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

Раскол зеркалит карту поддержки WHIP: developer-платформы и B2B-видеопродукты внедряют WHEP параллельно с HLS и DASH, тогда как потребительские social-платформы придерживаются стратегии HLS-первым, а WHEP в их дорожной карте не фигурирует публично. Причина одинакова с обеих сторон – в потребительском сегменте social-медиа масштаб таков, что экономика WebRTC на уровне каждого зрителя становится неконкурентоспособной, и HLS через CDN по-прежнему дешевле на порядок при таких объёмах.

Типовые ошибки – что ломает WHEP в продакшене

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

Подводный камень 1: ICE-сбой из-за неконфигурированного TURN. WebRTC требует TURN-сервера, когда зритель находится за симметричным NAT, который не позволяет установить прямую peer-to-peer связь. В каждом продакшн-развёртывании WHEP должен быть настроен на использование TURN – собственного или хостингового (например, anycast TURN от Cloudflare, TURN от Twilio, кластер Coturn). Наиболее частая ошибка – зритель получает сообщение «ICE failed», потому что в SDP answer не было возвращено ни одного TURN-кандидата. Решение – либо настроить WHEP-сервер на анонсирование TURN-URL (стандарт позволяет это через заголовок Link с параметром rel="ice-server"), либо использовать TURN-сервер платформы.

Подводный камень 2: counter-offer не реализован в плеере. Путь 406 Not Acceptable с counter-offer встречается редко в продакшене, но возможен на некоторых self-hosted серверах, когда кодеки, предложенные зрителем, не совпадают с теми, что поддерживает сервер. Большинство плеерных библиотек завершают соединение с ошибкой 406, поскольку парсинг counter-offer SDP так и не был реализован. Решение – либо расширить набор предлагаемых кодеков (всегда включайте H.264 baseline и Opus – их поддерживает любой сервер), либо реализовать ответ с PATCH-SDP-answer.

Подводный камень 3: HTTPS не обязателен. §5 драфта говорит, что HTTPS должен использоваться. Некоторые self-hosted серверы поддерживают режим plaintext-HTTP для удобства локальной разработки – но никогда не используйте его в продакшене. Cleartext SDP передаёт bearer-токен по сети (он находится в заголовке Authorization POST-запроса), а утечка токена даёт злоумышленнику на пути права на воспроизведение. Используйте HTTPS с валидным сертификатом на каждом WHEP endpoint.

Подводный камень 4: bearer-токен в query string. Некоторые вендоры предлагают «удобную» форму, когда bearer-токен добавляется в URL как параметр запроса. Такой подход не предусмотрен в драфте спецификации и приводит к утечке токена через все HTTP-прокси, балансировщики, логи CDN и историю браузера. Используйте заголовок Authorization: Bearer <token>.

Подводный камень 5: относиться к WHEP как к HLS по масштабированию. Каждый WHEP-зритель – это полноценный WebRTC-пир на сервере. Сервер, обслуживающий 10 000 зрителей, поддерживает 10 000 SRTP-контекстов шифрования, 10 000 буферов джиттера, 10 000 ICE-сессий и 10 000 исходящих медиа-потоков. Экономика на единицу принципиально отличается от модели HLS/CDN-egress. Планируйте мощность на одного зрителя, а не на один поток; выбирайте провайдера, который сам реализует архитектуру fan-out на SFU (подробности в нашей статье по масштабированию WebRTC).

Подводный камень 6: считать драфт стабильным. WHEP сейчас – draft-ietf-wish-whep-03, истекающий в феврале 2026 года, с пометкой рабочей группы «Revised I-D Needed». Будущая ревизия может изменить семантику ETag, обработку counter-offer, логику выбора слоёв или любые IANA-регистрации. Продакшен-реализация не заметит этих изменений – вендоры уже внедрили свои версии, – но если вы разрабатываете собственную плеерную библиотеку, следите за рассылкой рабочей группы. Текст действительно активно развивается.

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

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

Выбирайте WHEP, если: (а) бюджет задержки составляет менее одной секунды от экрана до экрана; (б) сеть зрителя – проводная или стабильный Wi-Fi/5G-канал с ожидаемыми потерями менее 1 %; (в) аудитория ограничена (обычно не более 10 000 одновременных зрителей на поток, при которых экономика WebRTC fan-out остаётся эффективной); (г) целевая платформа уже поддерживает доставку через WHEP (любая из перечисленных выше); (д) плеер работает в браузере, мобильном приложении или среде смарт-ТВ с WebRTC-стеком.

Оптимальный путь для передачи – WHIP, чтобы минимизировать полную задержку.

Выбирайте LL-HLS, когда: задержка должна быть меньше пяти секунд, но аудитория больше 10 000 (или неограниченна), сеть смешана и неизвестна (LL-HLS деградирует переключением битрейта, не замиранием), либо требование покрытия устройств включает устаревшие смарт-ТВ и приставки без WebRTC-стека.

Выбирайте LL-DASH / CMAF chunked, если: ваш тулчейн уже поддерживает DASH «из коробки» (например, Bitmovin, Shaka Packager), а плеерная экосистема – dash.js или Shaka.

Выбирайте HLS, когда задержка не критична (VOD, архивы прямых трансляций, broadcast-хвосты) – доставка HLS через CDN обеспечивает самую низкую стоимость вывода трафика на одного зрителя с большим отрывом.

Выбирайте HESP, когда: тулчейн HESP-Alliance уже развернут и заявленные 400 мс задержки подтверждены на вашем пути.

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

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

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

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

• WHEP – это зеркальное воспроизведение WHIP: один HTTP POST возвращает SDP answer, после чего поток WebRTC-медиа передаётся с сервера зрителю.
• По состоянию на май 2026 года WHEP – это draft-ietf-wish-whep-03: истёкший IETF Internet-Draft, ещё не ставший RFC; рабочая группа находится в статусе «Revised I-D Needed».
• Провод использует четыре HTTP-метода (POST, DELETE, PATCH, OPTIONS) для двух URL, плюс уникальный путь для counter-offer (406 → PATCH), которого нет у WHIP.
• Выбор слоя и событий не вошёл в драфт; каждый вендор реализует собственные непереносимые расширения для обоих.
• Реальная задержка glass-to-glass: 200–500 мс при проводной передаче в одном регионе (WHIP-to-WHEP), 400–800 мс – при трансатлантической.
• Выбирайте WHEP, если задержка должна быть меньше секунды на чистой сети при ограниченной аудитории; выбирайте LL-HLS, если нужна задержка менее пяти секунд при масштабировании.
• Bearer-токен обязателен; HTTPS обязателен; токен никогда не передаётся в параметрах query строки URL.

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

• WHIP: ingest для WebRTC и стандарт RFC 9725 – зеркало для вкладов; в паре с WHEP обеспечивает end-to-end задержку менее секунды.
• WebRTC для доставки: от peer-to-peer к масштабной дистрибуции – обзор того, как WebRTC fan-out выходит за рамки одноадресной передачи.
• Как выбрать delivery-протокол в 2026: дерево решений – полный фреймворк по всем современным протоколам доставки.

CTA

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