2025-09-13T23:58:00+09:00

WebRTC, WHIP, and WHEP: making real-time streaming easier to connect

An introduction to WebRTC signaling and the roles of WHIP for ingest and WHEP for playback. The article outlines a GStreamer-to-OvenMediaEngine-to-browser streaming setup and links to the underlying specifications.

WebRTC, or Web Real-Time Communication, is an open set of technologies for exchanging audio, video, and data in real time between browsers and mobile apps without plugins. It is optimized for uses where immediacy matters, such as two-way calls and video conferencing. Under suitable conditions, latency below 150 milliseconds is realistic. In peer-to-peer (P2P) data transmission, once a connection is established, the parties exchange data directly rather than through an intermediary server. However, the coordination needed to initiate a connection, called signaling, is outside the WebRTC specification. Developers traditionally had to implement it themselves. This often became complicated and was one obstacle to wider adoption for live streaming. Signaling is the exchange of information that peers need before a WebRTC connection can start. Think of it as exchanging telephone numbers before making a call.

What is WebRTC?

Although the media can travel peer to peer, establishing the connection requires signaling through a server. Since WebRTC does not define signaling, implementations differ between apps and services. The signaling server manages session states, such as starting, ending, or changing a call, and exchanges routing information including IP addresses and ports.

It also handles ICE candidates: information used to find routes across NAT and firewalls.

The peers exchange SDP information describing media choices such as video and audio codecs, resolution, and bitrate.

This exchange takes place through a signaling server using a transport such as WebSocket or HTTP.

More specifically, peers exchange an offer, an answer, and connection candidates, or ICE candidates, to prepare the P2P connection.

Once signaling is complete and the connection is established, an intermediary signaling server is no longer needed for the subsequent data transfer.

WHIP and WHEP provide standardized procedures for this signaling process.

Before this standardization, each service had its own implementation, with poor interoperability between tools. Connecting a sender and player could be very complicated.

Custom implementations and debugging consumed substantial effort, while vendor lock-in and fragmented ecosystems were additional problems.

By defining HTTP-based signaling, WHIP and WHEP address these problems and substantially simplify building and operating low-latency WebRTC live-streaming systems.

Previously, a separate signaling service, such as a dedicated WebSocket server, was often necessary. WHIP/WHEP can reduce that requirement.

What is WHIP: WebRTC-HTTP Ingestion Protocol?

WHIP is a signaling protocol for sending, or ingesting, a WebRTC stream into a live-streaming system. Previously, sending video from a tool such as OBS Studio to a media server required signaling tailored to that server. WHIP standardizes the process. It uses an HTTP POST request for signaling, reducing implementation work and making connection setup closer in simplicity to RTMP. Lower development and operational barriers are a major advantage. Interoperability improves too. OBS Studio and other broadcasting tools support WHIP, making it easier to send WebRTC streams to different servers.

What is WHEP: WebRTC-HTTP Egress Protocol?

WHEP provides signaling for delivering, or egressing, a WebRTC stream from a media server to a viewer's client. WHIP handles the publishing side; WHEP handles the viewing-side connection. Like WHIP, it starts a session through an HTTP-based process, making WebRTC playback easier to integrate into a client app.

A simpler way to connect WebRTC systems

Combining WebRTC's real-time strengths with the standardized connection procedures of WHIP and WHEP allows simpler, more interoperable low-latency, high-quality live streaming. For example, WHIP and WHEP let the components cooperate through a common procedure, simplifying the construction of a low-latency streaming pipeline. Example flow: GStreamer → media server, such as OvenMediaEngine → web app Sender: GStreamer Role: capture and encode audio and video from a camera or file. Protocol: act as a WHIP client and send a WebRTC stream to OvenMediaEngine. Example: the whipsink element in gst-plugins-rs can build a WebRTC publishing pipeline. Media server: OvenMediaEngine Role: receive the WebRTC stream sent through WHIP and deliver it to a WHEP-capable web app. Its integrated signaling makes it easier to operate without deploying a separate signaling server. Receiver: web app Role: play the live stream in the viewer's browser. Protocol: act as a WHEP client and receive audio and video from OvenMediaEngine. For example, a JavaScript WHEP client library can initiate playback through straightforward HTTP requests. With common protocols such as WHIP and WHEP, tools and platforms including GStreamer, OvenMediaEngine, and web browsers can work together with fewer compatibility problems.