WebRTC can connect two peers for an interactive session, carry a producer’s feed into streaming infrastructure, or deliver a live feed to a viewer. The right workflow depends on who is sending media, who is receiving it, and whether they need to interact.
The shared foundation is session negotiation and network connectivity. WebRTC does not choose your application’s signaling channel; peers or services must exchange session details and ICE candidates before media can flow. WHIP standardises one producer-to-service ingest workflow, while WHEP describes a viewer-egress workflow in an Internet-Draft, not a final RFC.
Three jobs WebRTC can perform
It helps to start with the job rather than the protocol name. A video call, a contribution feed from a remote camera, and playback of a live channel may all use WebRTC, but their directions and session management differ.
| Workflow | Who sends to whom | Typical purpose | Setup shape |
|---|---|---|---|
| Peer-to-peer | One peer to another | Two-way conversation or collaboration | Application exchanges SDP and ICE information |
| WHIP ingest | Producer or encoder to a service | Send a live contribution feed into streaming infrastructure | HTTP request carries an SDP offer to a WHIP endpoint |
| WHEP playback | Streaming service to a viewer | Let a viewer receive a WebRTC live stream | HTTP-based offer-and-answer flow described by an Internet-Draft |
The first is often interactive: both participants may send audio or video and respond to changing session conditions. Ingest is about getting media into a service. Playback is about establishing a media path from a service towards a viewer. Do not assume that a method for one direction automatically solves the other.
For a small business streaming a product demonstration, a peer-to-peer call might connect a presenter to a remote guest. If the production team wants to send a camera feed into a distribution service, that is an ingest job. A viewer opening a low-delay player is an egress job. The labels clarify which component initiates the session and which side needs to be reachable.
For a 24/7 YouTube channel, these WebRTC workflows are not interchangeable with simply uploading a finished loop video. If your main task is keeping a sequence of recorded programmes playing, a guide to automatically playing the next video on YouTube Live addresses a different operational problem. WebRTC is relevant when you are building a live media connection, not just choosing the next file in a schedule.
Signaling, offers, answers and ICE
WebRTC provides browser and application APIs for creating a peer connection, but it does not prescribe how two ends find each other or exchange the information needed to start. That application-level exchange is called signaling. It might use a web API, a messaging channel, or an RPC mechanism that your application already operates.
One side creates a session description protocol (SDP) offer describing the proposed media session. The other side returns an SDP answer describing what it can accept. Signaling carries those descriptions between the endpoints; it does not itself carry the audio or video. The WebRTC peer connections guide explains the API-level sequence, and MDN’s signaling guide describes the role of the application’s signaling channel.
ICE, short for Interactive Connectivity Establishment, helps the endpoints find a usable network path. Each side gathers ICE candidates, which represent possible ways to reach it. The application passes the candidates across its signaling channel so the ICE process can test candidate pairs. An SDP answer alone is not proof that a media connection is working: watch the peer connection state and verify that a candidate pair is selected and media is actually flowing.
The order matters when applying the information. Set the remote SDP description before adding remote ICE candidates with addIceCandidate(). If candidates arrive too early, your application needs to queue them until the remote description is in place. Trickle ICE lets candidates be sent as they are discovered rather than waiting for all gathering to finish; the WebRTC guide notes that this can reduce setup delay.
ICE may use STUN to learn about network reachability, and TURN to relay media when a direct path is unavailable. A direct connection is not guaranteed across every network. Corporate firewalls, mobile networks and home routers can produce different results, so configure appropriate ICE services and test from the kinds of networks your participants actually use. The W3C WebRTC Recommendation documents the browser API and its connection model.
The practical diagnostic distinction is between negotiation and connectivity. If no offer or answer is exchanged, inspect signaling. If negotiation completes but ICE remains stuck, inspect candidate exchange and STUN/TURN configuration. If the connection state looks healthy but there is no picture or sound, check the sender tracks, receiver tracks, permissions and media rendering separately.
Peer-to-peer interactive sessions
A peer-to-peer session is useful when participants need to talk or collaborate in real time. A tutor and a student, for example, may both send camera and microphone tracks, and each receives the other’s media. The application owns the user experience: joining, identity, permissions, signaling, error messages and the decision to reconnect.
The simplest design is not necessarily a direct network path. ICE attempts connectivity using the available candidates, and a TURN relay can be needed when the networks prevent direct communication. That relay can make a session possible, but it also means media travels through an intermediary. Plan for that operational dependency rather than treating TURN as an exceptional failure mode.
A call application should expose useful connection states to the user. “Connecting” should not disappear merely because an SDP answer has arrived. Track whether ICE is checking, connected, or failed, and make a sensible recovery path available. During a temporary network change, an ICE restart can help establish a new path, though the application still needs to manage its signaling exchange and explain any interruption.
This workflow suits interactive communication, not necessarily one-to-many broadcasting. A direct peer connection is designed around endpoints, and a viewer audience introduces a different fan-out problem. If every viewer is treated as a separate peer, the producer’s work and connection management grow with the audience. At that point, a media server or distribution service is commonly placed between producer and viewers; its role is covered below.
For creators who record lessons or coaching sessions and then publish material, the recording workflow is distinct from the live connection. The video recording software guide for coaches may help with creating the source material, but it does not replace the signaling and connectivity needed for a WebRTC session.
Send a producer feed with WHIP
WHIP, the WebRTC-HTTP Ingestion Protocol, addresses the producer-to-service job. An encoder or other media producer sends an SDP offer to a WHIP endpoint using an HTTP POST. The endpoint responds with an SDP answer; the client and endpoint then establish ICE and DTLS, after which media is carried using RTP and RTCP protected with SRTP.
The IETF published WHIP as RFC 9725, a Standards Track RFC in March 2025. That status matters: WHIP is a published ingest protocol, not merely a proposed pattern. A service can expose an endpoint for a producer to send into, with the service or CDN then handling its own distribution workflow.
WHIP is deliberately limited after initial negotiation. The RFC does not provide for SDP renegotiation or changing the media sections mid-session. Its HTTP PATCH mechanism can carry ICE-related updates, including trickle ICE or ICE restarts. The RFC recommends support for trickle ICE and ICE restart, and an endpoint may return STUN/TURN configuration as part of a successful response.
That constrained design is useful when the job is to start an ingest session and keep the protocol behaviour predictable. It also sets boundaries: do not plan on changing the media layout through a fresh SDP negotiation once the session is under way. Decide the tracks and media arrangement before publishing, and make sure the client and endpoint have compatible expectations.
WHIP does not dictate which camera, encoder or service you must use. The research supports the protocol workflow, not a particular hardware purchase or an encoder recommendation. If you are selecting a producer, check that it supports the endpoint and the media format you intend to send; then test startup, network changes and recovery before relying on it for a scheduled broadcast.
Deliver viewer playback and WHEP status
WHEP, the WebRTC-HTTP Egress Protocol, addresses the opposite direction: a viewer establishes a WebRTC session to receive media from a streaming service, CDN or WebRTC Transmission Network. The retrieved IETF document describes an HTTP-based exchange for that viewer session, with an SDP offer and answer and ICE-related PATCH updates. Like WHIP, the draft describes no SDP renegotiation after the initial exchange.
The status must be stated carefully. The source reviewed for this article is draft-ietf-wish-whep-04, an IETF Internet-Draft revision published on 22 June 2026 and marked to expire on 24 December 2026. It is not a finalized RFC. Draft status means the specification can change; check the current IETF document before making an implementation decision.
WHIP and WHEP are related in that each applies HTTP to a WebRTC session for a specific streaming job, but they are not the same workflow and do not have the same publication status. WHIP is producer ingest and is defined in RFC 9725. WHEP is viewer egress and, in the retrieved source, remains an Internet-Draft. Treating both as finalized standards would give a reader the wrong picture of what is settled.
For an operator, the useful question is whether the playback service and player agree on the draft’s current behaviour and supported media. Test on the viewer networks that matter, including mobile connections and restrictive networks. A viewer still depends on ICE connectivity, so a playback session can fail even when the producer is sending successfully. Keep separate checks for ingest health and viewer connection health.
This distinction is especially useful when troubleshooting. If a producer cannot establish its HTTP session, inspect the WHIP client and endpoint exchange. If the producer is publishing but a viewer cannot start playback, inspect the egress service, WHEP implementation, player negotiation and that viewer’s ICE path. “The stream is live” may only describe the ingest side, not whether every intended viewer can connect.
Where media servers and SFUs fit
A media server sits between producers and consumers when a direct peer-to-peer design does not match the distribution job. In an ingest workflow, the producer sends media to the service; the service can then make that media available to viewers through a suitable delivery path. WHIP defines one standardised way to get media into such a service. A viewer-egress protocol such as the WHEP draft describes a way to establish a WebRTC session from a service to a viewer.
An SFU, or selective forwarding unit, is one kind of media-server role: it forwards selected media streams to recipients rather than requiring every participant to send separate media directly to every other participant. That description is a conceptual role, not a guarantee about a particular product’s features or scaling. The research sources for this article do not substantiate performance comparisons, capacity figures or deployment recommendations for SFUs, so treat those as questions to verify with the implementation you are considering.
Keep responsibilities distinct in a design diagram. The producer captures and encodes media. Signaling or the HTTP protocol exchange establishes the session. ICE finds a viable path. A media service receives or forwards media. The player renders it for the viewer. When those jobs are mixed together under the phrase “WebRTC server”, it becomes harder to identify which part failed.
For a 24/7 channel made from pre-recorded material, a media-server workflow may be more machinery than you need. If the problem is choosing different files for different days, see the guide to scheduling different videos by day. If your priority is reducing the burden of keeping a computer on while a pre-recorded YouTube stream runs, StreamNeo removes that specific always-on computer task by letting you upload the video and leave your own machine off. That is a different workflow from building a WebRTC ingest or playback service.
Choose the workflow for your use case
Start by writing down the sender, receiver and interaction pattern. A remote interview needs two-way participant media and application signaling. A camera contribution sent to a streaming platform needs producer ingest. A browser player receiving a service’s live feed needs viewer playback. Naming those roles first avoids adopting a protocol because it appears in a feature list without checking whether it addresses your direction of media flow.
| If you need to… | Start with… | Check before you commit |
|---|---|---|
| Connect a small number of people interactively | Peer-to-peer WebRTC | Signaling ownership, ICE services, state handling and recovery |
| Send a contribution feed into a service | WHIP | Endpoint compatibility, supported tracks, ICE updates and client behaviour |
| Let viewers receive a service’s feed over WebRTC | WHEP implementation or draft-aware integration | Current specification status, service support, player compatibility and viewer connectivity |
| Keep a recorded YouTube loop running | A playback or automation workflow, not WebRTC by default | File sequence, scheduling, channel setup and what happens after interruption |
Then test the failure that matters most to your audience. For calls, test joining from different networks and what happens when a participant changes networks. For ingest, stop and restore connectivity and observe whether the producer can recover using the supported ICE mechanisms. For playback, test both a successful session and a viewer who cannot reach the service directly. Record the visible error and the system state instead of relying on “it worked once” as a readiness check.
Keep protocol maturity in the decision. The WebRTC APIs and recommendation provide the peer connection foundation; RFC 9725 specifies WHIP ingest; the retrieved WHEP document is a draft. If a vendor says it supports WHEP, ask which revision or behaviour it implements and how it handles changes in the draft. For any workflow, consult the current primary documentation and the service’s own compatibility notes rather than inferring support from the word WebRTC alone.
A protocol is only one part of operating a live channel. If you are using YouTube, confirm the current requirements for the channel and the specific broadcast separately. WebRTC connectivity does not itself ensure platform acceptance, audience reach, or uninterrupted playback. For long-running recorded loops, build the workflow around the content and operational burden you actually have, rather than adding interactive-session machinery that does not solve it.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How does WebRTC work for live streaming?
WebRTC establishes a secure media connection after the endpoints exchange session descriptions and ICE information through a signaling mechanism. The workflow can be peer-to-peer, producer ingest into a service, or viewer playback from a service. The direction and job determine which session setup is appropriate.
How do I send a WebRTC stream to a server?
For a service that supports WHIP, a compatible producer sends an SDP offer to its WHIP endpoint over HTTP and receives an answer. The session then uses ICE and DTLS to establish media transport. Check the endpoint’s requirements and test the producer’s recovery behaviour before using it for a live programme.
How does a viewer play a WebRTC live stream?
A viewer needs a player and service that can establish a WebRTC session, exchange the required session information and find a viable ICE path. WHEP describes an HTTP-based egress workflow, but the retrieved specification is an Internet-Draft, not a finalized RFC. Confirm which draft behaviour the service supports.
Are WHIP and WHEP interchangeable?
No. WHIP is for sending a producer’s feed into streaming infrastructure and is specified in RFC 9725. WHEP describes a viewer receiving media from a service and remains a draft in the source reviewed here. They address opposite directions, with distinct status.