Skip to main content

​
WHEP in-browser guest player

WHEP (WebRTC-HTTP Egress Protocol) is an open IETF draft that plays a live media stream over WebRTC — the browser POSTs an SDP offer to an HTTPS endpoint and the gateway answers in kind. For a broadcast, that means glass-to-glass latency of roughly one second, versus the multi-second playlist latency of HLS. Because the negotiation is plain WHEP, no Orbit vendor SDK is involved on either side: any stock browser (or an external WHEP client such as OBS or VLC) can reach the same endpoint. The dashboard route /voice/video/player/… is a dedicated page that plays one WHEP URL on its own — the kind of link you can hand to a guest viewer with no dashboard role, or embed in your own front-end without wiring up the video SDK. Use the guest player when a viewer needs to watch a live broadcast. Use the Orbit video SDK when the person must join a room as a participant — with their own camera and microphone publishes, room controls, and access-token claims. Watching does not need the SDK. The route takes one path segment: the WHEP playback URL, percent-encoded. Construct deep-links with encodeURIComponent:
A URL that does not decode to an http(s) address renders the page’s empty sheet — a paste-a-URL hint instead of a blank screen or a thrown error — so an accidentally malformed link still tells the visitor what the shape should be. Because the WHEP draft carries the capability in the URL itself, no bearer header or additional authentication is needed on this path. Treat a WHEP URL as you would a share link: anyone holding it can watch the live broadcast. Open a broadcast’s live viewer page (for example from Voice → Broadcasts, or the room’s live sessions view). Under the player you find:
  1. An HLS / WHEP toggle — WHEP plays in-browser with the same stock-WebRTC negotiation; HLS remains the default for maximum compatibility.
  2. The WHEP URL row, which copies the raw endpoint and carries a Play in browser action. That action opens the guest player route above in a new tab — the link it opens is exactly the /voice/video/player/<encoded-url> construction you would hand-build.
Copy the URL from that row to construct share links, or open the player directly and share the resulting address.

​
The playback walk

  1. Join — open the link; the page immediately negotiates the WHEP connection and shows a connecting state.
  2. Live — when the first video track arrives, playback starts on the <video> element. Standard browser controls cover mute/unmute and volume for the audio leg.
  3. Leave — closing the tab or navigating away closes the peer connection against the SFU; nothing on the guest page lingers.
The page watches-one-way: it is a viewer surface, so it does not publish video or audio, and it does not report a “watching now” heartbeat the way the authenticated broadcast viewers page does — the route is keyed by a raw WHEP URL, not a room.

​
Troubleshooting

  • Connection stalls in connecting — the ICE handshake timed out before a track arrived. Check the recipient’s network egress: WHEP needs UDP (or a TURN path) to reach the media server, so corporate proxies that force all traffic through TCP-only paths block it. Have the viewer retry from an unconstrained network.
  • Connection failed with a retry button — the WHEP endpoint answered non-200 or returned an unparsable SDP answer. The broadcast may have ended, or the URL is stale. WHEP endpoints are minted per live broadcast; re-copy the row from the live viewer page.
  • Negotiated but waiting-for-track — the handshake succeeded but no media is flowing yet (the broadcast publisher has not started, or is muted at the source). This is an explicit state, not a frozen frame; playback starts as soon as a track arrives.
  • Unsupported browser — WHEP depends on RTCPeerConnection with send/ receive SDP negotiation. Every current Chrome, Edge, Firefox, and Safari build supports it; very old or heavily locked-down browser builds that disable WebRTC cannot play and will hit the retry state.

​
Adjacent guides