“WebRTC server” can mean several different things: a service that coordinates a call, network services that help endpoints connect, or a media server that routes or processes audio and video. You do not automatically need all of them, and WebRTC does not require every session to pass through a central media server.
For a simple two-person call, signaling and ICE connectivity checks may be enough when the endpoints can reach each other directly, with TURN available as a relay when they cannot. An SFU or MCU becomes relevant when your product needs server-mediated group media, broadcast distribution, mixing, or other server-side handling.
What people mean by a WebRTC server
WebRTC is a set of browser APIs and supporting protocols for real-time communication, not the name of one server product. The W3C WebRTC specification describes APIs that let a browser send and receive media and application data. It leaves applications to arrange how endpoints find one another and exchange the information needed to start a session.
That leaves room for several components which are often grouped under the phrase “WebRTC server”, even though they do different jobs:
| Component | Main job | Does it normally carry call media? |
|---|---|---|
| Signaling service | Exchanges setup messages, session descriptions and network candidates | Not necessarily |
| STUN service | Helps an endpoint discover an address that may be reachable from outside its local network | No, not as a media relay |
| TURN service | Relays traffic when a direct network path cannot be used | Yes, when selected as the path |
| SFU | Receives streams and forwards selected media tracks to subscribers | Yes |
| MCU | Receives and mixes audio or composites video into output media | Yes |
These roles can be deployed separately or combined in a product, depending on its design. A signaling service can help two browsers find each other without receiving their media. A TURN relay can carry media without deciding who belongs in a meeting or which participant’s video should appear. An SFU or MCU has a different job: it sits in the media path to route or process streams.
This distinction matters when you are choosing a library or service. A product advertised as a WebRTC server may provide only some of these functions. Before relying on it, check whether you still need to build signaling, supply TURN, manage rooms, or handle media routing yourself.
Do you need a server for WebRTC?
Not always in the sense people usually mean. WebRTC endpoints need a way to exchange setup information, and they need to find a usable network path. But when two peers can establish a direct route, their media can travel peer to peer without an SFU or MCU in the middle.
In a real application, “no server” is therefore usually shorthand for “no central media server”. Your application still needs to get the peers connected. It may use an application backend for signalling and a STUN or TURN service for connectivity. Which components are necessary depends on the product and the networks its users are on.
A direct call between two people is a sensible place to begin if you do not need central media features. Test it across the networks your users actually use, including mobile connections, office firewalls and restrictive public Wi-Fi. A direct route may work in one environment and fail in another. ICE tests available paths, and a TURN relay can carry media when the direct options do not work.
Peer-to-peer also has limits beyond reachability. If you add participants to a mesh call, each endpoint may need to send its media to several other endpoints and receive theirs. That puts more work on each participant’s connection and device as the group grows. There is no participant count that automatically determines the right architecture: the number of streams, device capability, network conditions and experience you want all matter.
An SFU is not a mandatory upgrade for every call. It is useful when the product needs a central point to receive and selectively distribute media. An MCU may fit where clients should receive a mixed or composited output. Those choices add media-server operation and capacity questions, so make them in response to a product need rather than because “WebRTC needs a server”.
Signaling and session setup
Before two endpoints can exchange media, they need to agree on the session and exchange connection details. WebRTC provides APIs for creating session descriptions and handling ICE candidates, but it does not prescribe one universal signaling protocol. Your application must provide a route for those messages between participants.
A typical flow looks like this: one endpoint creates an offer describing the media it can send or receive; the other endpoint responds with an answer; and both exchange ICE candidates as they are gathered. The application carries these messages between the endpoints. It may also use that same channel for practical call controls such as joining a room, ending a call or indicating that a participant has left.
The signaling channel is control traffic, not automatically the path for audio and video. A common design uses an application service to authenticate users and carry signaling messages, then allows ICE to find the media path separately. The service may know who is calling whom, but it does not have to receive the media.
The distinction gives you a useful debugging sequence. If a call does not start at all, check whether participants can join, whether offers and answers are exchanged, and whether candidate messages reach the other endpoint. If setup completes but no audio or video flows, examine ICE connectivity and selected paths. Treating both symptoms as “the WebRTC server is down” can send you towards the wrong component.
Signaling is also a security boundary. Users should not be able to join arbitrary rooms or subscribe to someone else’s setup messages simply because they know a room name. Authenticate and authorise session requests, and avoid exposing long-lived credentials in messages or client code. A functioning signaling channel is not, by itself, a complete security design.
STUN and TURN network paths
ICE, STUN and TURN are related but distinct. ICE gathers possible network addresses, tests candidate pairs and selects a usable route. STUN can help an endpoint learn an address assigned by its network edge. TURN provides a relayed address and carries traffic through a relay when a direct route is unavailable or blocked.
A STUN service does not make every device reachable. Network address translation and firewall policies can prevent the address discovered by one endpoint from accepting traffic from another. ICE checks candidate paths rather than assuming that one discovered address will work. If direct candidates fail, a TURN candidate may provide the route that completes the call.
TURN is a fallback path, not a conference media server. It does not provide room management, choose which video tracks participants receive, or mix a meeting into one picture. It forwards traffic through a relay. That makes otherwise difficult network paths more reachable, but relayed traffic uses bandwidth and may add path length and latency. The ICE specification, RFC 8445 notes that TURN may be unnecessary on some networks and can be expensive in some deployments.
Plan for TURN rather than assuming it will never be needed. The WebRTC transport requirements, RFC 8835 require browser support for TURN and include TCP and TLS-over-TCP modes for networks that block UDP. That does not mean every call will use a relay: ICE may find a direct route first. It does mean your application should have a considered fallback for networks where direct connectivity fails.
Measure relay use in your own deployment and investigate where failures happen. High relay usage can affect operating costs and the path media takes, while no relay option can leave users unable to connect from restrictive networks. If your audience includes people on corporate or managed networks, test the connection modes those networks permit instead of relying on a home broadband test.
When media can flow peer to peer
Peer-to-peer media is a good fit when two endpoints need a straightforward call and can establish a direct path. The media does not need to be sent through a central SFU or MCU simply because the application uses WebRTC. Signaling and connectivity assistance can exist alongside a direct media path.
The main advantage is that you avoid routing ordinary media through a conferencing server when ICE finds a direct route. That can keep the media architecture simpler. The trade-off is that you have less central control over media, and direct connectivity cannot be assumed across every user network. TURN remains useful as a relay fallback, with its bandwidth and path trade-offs.
For a small group, a peer mesh can be considered if each endpoint can handle the required sending and receiving. Each person may need to upload a stream to each of the other people, so participant uplink and device load rise as the call grows. Receiving several streams also asks more of client bandwidth and decoding capacity. A call that works on a developer’s laptop and fast office connection may behave differently on a lower-powered phone over mobile data.
If you are weighing a server-based approach against a continuous video broadcast, first clarify the delivery model. Interactive WebRTC calls are designed for real-time exchange; a loop of recorded video sent to YouTube is a different workflow. The guide to looping YouTube videos and Restream alternatives may help if your goal is a scheduled or always-on YouTube channel rather than interactive calls between participants.
Do not choose peer-to-peer solely because it sounds cheaper or simpler. A direct path may reduce reliance on media routing, but you still need to implement signaling, test connectivity, support TURN where needed and understand what happens when a route fails. The choice is about where the work and control should sit, not a guarantee that one design will always have lower cost or better quality.
When to use an SFU or MCU
Use a media server when the product needs media to pass through a central component for a reason. That reason might be distributing one participant’s media to several viewers, letting participants subscribe selectively, creating a consistent group-call experience, or processing audio and video on the server. An SFU and MCU address different versions of that need.
An SFU, or Selective Forwarding Unit, receives media streams and forwards selected tracks to subscribers. It generally does not mix the underlying video into one combined picture. A client can receive the speakers or video layers it needs, and the application can offer adaptable layouts or subscriptions. This can reduce the number of copies each publisher must send compared with a peer mesh, but the SFU and its network paths must carry the traffic it forwards. Subscribers may still receive several tracks.
An MCU, or Multipoint Conferencing Unit, processes media to create mixed audio or a composited video output. That can simplify what each endpoint receives, particularly when the product needs a fixed combined view. In exchange, the server does more media processing, and clients have less control over separate tracks and layouts than they would with individual streams from an SFU.
| Product need | Likely starting point | Main trade-off to test |
|---|---|---|
| Two-person call without server-side media features | Peer-to-peer, with signaling and ICE plus TURN fallback | Whether calls connect reliably across user networks |
| Small group where each device can send and receive all peers’ media | Peer mesh may be suitable for a constrained use case | Endpoint upload, download and decoding load as peers are added |
| Meeting with separate tracks or selective subscriptions | SFU | Forwarding capacity, bandwidth, subscriptions and scaling design |
| Fixed mixed audio or composed video for participants | MCU or media-processing service | Processing effort and reduced independent track control |
| Low-delay distribution to many viewers | SFU distribution or a hybrid design | Fan-out, network traffic, regional distribution and client load |
These patterns are starting points, not universal thresholds. A group size that works for one implementation, codec, device mix and network may fail in another. Test with representative clients, media quality and network conditions. For a broadcast-style service, calculate both the stream entering the system and the streams delivered to viewers; adding a media server does not remove the need to plan for distribution capacity.
A YouTube live channel is not automatically a WebRTC SFU use case. If your aim is to loop recorded worship content or another prepared programme to YouTube, the Windows 11 guide to continuously streaming recorded worship services describes that distinct workflow. If the actual product is a low-latency interactive room or audience contribution tool, then an SFU or hybrid architecture may be relevant to the real-time portion.
Choose an architecture for your application
Start with the product requirement, not the server label. Write down who sends media, who receives it, whether recipients need separate tracks, whether the server must record or process media, and how much delay is acceptable. Then map each requirement to a component: signaling for session coordination, STUN and TURN for connectivity, and an SFU or MCU for server-mediated media.
For two participants, begin with a direct-media design if the product does not need central routing. Include TURN in the connectivity plan, and test both direct and relayed paths. Monitor whether calls connect, which candidate type is selected, where failures cluster, and whether relayed calls remain usable for your media quality target.
For group calls, compare mesh and SFU approaches against the actual client and network envelope. A mesh can avoid a media server for a limited situation, but every endpoint may carry multiple streams. An SFU moves track distribution to a server-side component and gives you more control over subscriptions, while introducing capacity, deployment and operations work. Use representative tests rather than copying a participant limit from another product’s documentation.
For broadcast or server-side composition, define whether viewers need interactive, separately selectable tracks or a single mixed output. An SFU can forward tracks to interested subscribers; an MCU can generate a composed result. A hybrid may suit a product that needs both interactive contribution and broad distribution, but each additional stage needs its own capacity and failure analysis.
Security and operations belong in this decision. WebRTC’s transport protections do not replace application authorization, secure signaling, abuse controls, or careful handling of recordings and logs. The IETF’s WebRTC security architecture, RFC 8827 describes protocol security mechanisms, including DTLS-SRTP keying and ICE checks. Apply those mechanisms within a broader design that controls who can join and what they can access; adding a media server alone does not make an application secure.
Finally, decide who will operate the components. A self-managed deployment gives your team responsibility for monitoring, upgrades, regional capacity and incident response. A managed service can shift some of that work to a provider, but you still need to check its current features, regions, data handling, security controls, support and pricing against your requirements. If you are comparing continuous YouTube workflows rather than building a WebRTC application, the guide to OBS plugins for a continuous YouTube podcast stream covers a more relevant set of tools.
If your need is simply to keep a prepared video running as a YouTube live channel, building a WebRTC media architecture may solve the wrong problem. StreamNeo removes the need to leave your own computer running for that specific workflow: you upload the file and use your YouTube stream key to run the broadcast from the cloud, with monitoring and automatic restarts if it drops. It is YouTube-only and does not provide WebRTC conferencing.
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
Do I need a server for WebRTC?
You need a way for endpoints to exchange session setup information, and ICE needs candidate paths to test. A direct media path can work without an SFU or MCU, but a signaling service and STUN or TURN support may still be part of the application. The exact components depend on the product and user networks.
What is the difference between STUN and TURN?
STUN can help an endpoint discover an address that may be reachable beyond its local network. TURN relays traffic when a direct route cannot be used, so it can improve reachability but consumes relay bandwidth and may add path length. Neither service provides the room and track-routing functions of an SFU.
When should I use an SFU?
Consider an SFU when you need server-mediated distribution of separate tracks, selective subscriptions, group calls or low-delay broadcast delivery. It can move media fan-out away from participant devices, but you must plan for server-side traffic, capacity and operations. Test the chosen implementation with your expected codecs, client mix and network conditions.
Is an MCU the same as an SFU?
No. An SFU forwards selected media tracks, leaving clients more flexibility to choose what to display. An MCU mixes audio or composites video into a combined output, which can simplify the endpoint’s inputs but requires server-side processing and reduces independent track control.