WebRTC delivery (egress)

WebRTC-egress переворачивает традиционную peer-to-peer-модель WebRTC: вместо двух браузеров SFU (Selective Forwarding Unit) выступает источником, а каждый зритель – WebRTC-клиентом, принимающим от него. Браузер зрителя использует тот же `RTCPeerConnection`, что и для обычного звонка, но SDP offer/answer теперь однонаправленный (только сервер → клиент). WHEP (WebRTC-HTTP Egress Protocol) стандартизовал сигнализацию, чтобы любой совместимый плеер мог тянуть с любого совместимого SFU.

Главная фича – задержка. WebRTC-delivery даёт 200 мс – 1 с glass-to-glass – категорически меньше, чем 2–4 с у LL-HLS. Это делает его единственным жизнеспособным протоколом для спортивных ставок, аукционов на реальные деньги, интерактивных шоу, видеоуроков и любых «react together» сценариев, где разрыв в 2 секунды ломает UX. Twitch, Kick, betting-фиды DAZN и крупные аукционные платформы в 2026 году используют WebRTC-egress.

Цена – операционная сложность. WebRTC-egress требует SFU-инфраструктуры (mediasoup, LiveKit, Janus, Pion, Cloudflare Calls), бюджета TURN-трафика, ICE-обработки и плеерного стека, понимающего NACK, PLI, simulcast и SVC. Multi-CDN-distribution сложнее, потому что каждый SFU – stateful per-зритель. Большинство операторов, которым нужен WebRTC-egress, запускают его с небольшого числа региональных POP (5–20 глобально), а не по сотням POP, как у HLS.