WHIP

До WHIP у каждого WebRTC-ингест-сервиса была своя сигнализация – свои схемы WebSocket, особенности REST, вендорские SDK. Плагин OBS для одного сервиса не работал с другим без правки кода. WHIP стандартизирует максимально простую сигнализацию: энкодер отправляет POST-запрос с SDP offer на известный URL, сервер отвечает SDP answer и URL сессии, а медиа передаётся через установленный WebRTC PeerConnection. PATCH и DELETE по URL сессии управляют ICE-кандидатами и завершением соединения.

RFC 9725 был опубликован в марте 2025 года после нескольких лет пребывания в статусе черновика (`draft-ietf-wish-whip`). К 2026 году WHIP поддерживают OBS (встроенная поддержка с версии 30.x, 2023), Cloudflare Stream, Mux, Dolby.io, AWS MediaLive, Twitch и большинство managed live-платформ. Для WebRTC-ингеста он сыграл ту же роль, что и RTMP для Flash-ингеста: создал единую точку подключения, к которой может обращаться любой вендор энкодера. Убийственная комбинация – OBS транслирует H.264/Opus через WHIP на managed-сервис, который конвертирует поток в LL-HLS для дистрибуции.

WHIP обеспечивает задержку в доли секунды – в отличие от RTMP, где она составляет 2–5 секунд, – без необходимости возиться с портами (вся сигнализация идёт по HTTPS/443, а медиапоток – через стандартный WebRTC UDP). Минус в том, что WHIP требует энкодеры и серверы приёма, поддерживающие WebRTC, и их эксплуатация сложнее, чем у RTMP. Тренд к 2026 году: WHIP – для новых воркфлоу с низкой задержкой, RTMP – для уже работающих систем, где требования к задержке не критичны.