SRS (Simple Realtime Server) is an open-source media server that supports WebRTC for ultra-low-latency streaming by acting as a Selective Forwarding Unit. Developers use SRS WebRTC with WHIP and WHEP protocols for browser-to-browser communication and live streaming. For a fully managed alternative, VideoSDK provides WebRTC-based video calling SDKs that eliminate self-hosting complexity.
Imagine launching a live stream and watching the video arrive in your browser with barely a heartbeat of delay. That is the promise that drew developers to SRS WebRTC, and it is why this combination has become a go-to stack for real-time media delivery. You publish a stream from a browser, SRS receives it, and viewers scattered across the internet watch it with sub-second latency. No bulky plugins, no multi-second HLS buffers, just near-instant video.
SRS has earned its popularity because it is lightweight, open-source, and supports WebRTC natively alongside RTMP, SRT, and HLS. Developers who need fine-grained control over their media infrastructure gravitate toward SRS. But if you want a managed solution that handles signaling, scaling, and SDK integration for you, VideoSDK's video calling SDK offers a production-ready alternative. This guide walks through everything you need to understand about SRS WebRTC, from architecture and codecs to configuration and deployment.
What Is SRS?
SRS, or Simple Realtime Server, is an open-source, high-performance media server originally developed to handle RTMP streaming and HLS delivery. Over the years, it has evolved into a multi-protocol media server that supports WebRTC, SRT, HTTP-FLV, and even DASH. The project is maintained on GitHub and has gained a strong following among developers who need a self-hosted alternative to commercial streaming platforms.
SRS occupies a specific niche in the streaming ecosystem. It is not a full-featured video conferencing platform with built-in room management and participant roles. Instead, it is a focused, efficient media relay that excels at ingesting streams from publishers and distributing them to viewers with minimal latency. This makes it ideal for scenarios like live event streaming, surveillance camera feeds, game streaming, and one-to-many broadcast situations where you control the infrastructure.
The server is written in C++ and designed for high concurrency. It can handle thousands of concurrent viewers on modest hardware, which makes it attractive for developers who want to keep infrastructure costs low. Its WebRTC support, added in later versions, brought sub-second latency streaming to the SRS ecosystem, positioning it as a serious contender for real-time media delivery in 2026.
Understanding WebRTC Basics
WebRTC is a free, open-source project that provides browsers and mobile applications with real-time peer-to-peer communication via simple application programming interfaces. The W3C WebRTC specification defines the standards that make browser-to-browser communication possible without requiring users to install plugins or third-party software.
At the core of WebRTC is the peer connection, which establishes a direct media and data channel between two endpoints. Each peer connection involves several critical components. Media tracks represent the audio and video streams captured from device cameras and microphones. The Session Description Protocol, or SDP, is used to negotiate the capabilities of each endpoint, including which codecs to use and what media formats are supported. Interactive Connectivity Establishment, or ICE, handles the network-level connection process by gathering candidate addresses (host, server-reflexive, and relay) that allow peers to reach each other across different network topologies.
In a pure peer-to-peer WebRTC scenario, two browsers connect directly to each other. This works fine for one-to-one calls but breaks down quickly when you need one-to-many streaming. Connecting a single publisher to 100 viewers via mesh networking would overwhelm the publisher's bandwidth and CPU. This is where a Selective Forwarding Unit, or SFU, becomes essential.
SRS acts as an SFU for WebRTC. Instead of every viewer connecting directly to the publisher, each viewer connects to SRS. SRS receives a single copy of the media stream from the publisher and forwards it to all connected viewers. This dramatically reduces the publisher's upload bandwidth and makes scalable, low-latency streaming feasible. If you need a more comprehensive SFU solution with built-in room management, recording, and multi-platform SDKs, VideoSDK's Prebuilt UI Kit provides a zero-code alternative.
SRS WebRTC Architecture
The SRS WebRTC architecture follows a straightforward publish-subscribe model. A browser publisher captures audio and video from local devices, negotiates a WebRTC connection with SRS, and sends media streams to the server. SRS then acts as a relay, accepting subscription requests from browser players and forwarding the publisher's media to each viewer. The signaling layer uses HTTP-based protocols (WHIP for ingestion and WHEP for playback), while the media layer uses standard WebRTC RTP and RTCP packets over UDP.
The key architectural advantage of this design is its simplicity. SRS does not transcode media by default. It receives encoded RTP packets from the publisher and forwards them to viewers as-is. This keeps CPU usage low and latency minimal because the server never decodes or re-encodes video frames. The trade-off is that all viewers must support the same codec the publisher uses, which becomes important when selecting between H.264, VP9, and AV1.
Here is a visual representation of the SRS WebRTC architecture, showing the signaling and media paths:
Signaling Flow
The signaling flow in SRS WebRTC uses two HTTP-based protocols defined by the IETF: WHIP (WebRTC HTTP Ingestion Protocol) for publishing and WHEP (WebRTC HTTP Egress Protocol) for playback. These protocols replace the need for a custom WebSocket-based signaling server, which was historically one of the more complex parts of building WebRTC applications.
When a browser publisher wants to stream to SRS, it creates an SDP offer describing its media capabilities and sends it to the SRS WHIP endpoint via an HTTP POST request. SRS responds with an SDP answer, completing the negotiation. The browser then knows which codecs SRS supports, which ICE candidates to use, and how to establish the DTLS and SRTP security layers. The same process happens in reverse for viewers, who send their SDP offers to the WHEP endpoint and receive SDP answers from SRS.
This HTTP-based signaling approach is elegant because it integrates naturally with existing web infrastructure. You can put SRS behind a reverse proxy, use standard HTTP load balancers, and even serve WHIP and WHEP endpoints over HTTPS without any special WebSocket handling.
Media Relay
Once signaling completes and the WebRTC peer connections are established, SRS handles media relay. The publisher sends encoded RTP packets (carrying audio and video frames) to SRS over UDP. SRS does not decode these packets. Instead, it inspects the RTP headers to determine which stream and track each packet belongs to, then forwards the packets to every subscribed viewer.
RTCP (RTP Control Protocol) packets flow alongside RTP to provide feedback on packet loss, jitter, and bandwidth estimation. SRS processes this feedback to maintain healthy connections with each participant. If a viewer's network degrades, RTCP feedback helps SRS and the publisher's encoder adjust accordingly, though SRS itself does not perform transcoding or bitrate adaptation.
This pass-through relay model means SRS can handle a high number of concurrent viewers with relatively low CPU overhead. The server's primary resource constraints are network bandwidth and the number of open UDP connections, not video processing power. For developers who need server-side transcoding, adaptive bitrate streaming, or more sophisticated media processing, a managed solution like VideoSDK with built-in network-adaptive streaming may be a better fit.
Choosing the Right Codec in SRS
Codec selection is one of the most impactful decisions when configuring SRS WebRTC. The codec determines video quality, bandwidth consumption, and browser compatibility. SRS supports three primary video codecs for WebRTC: H.264, VP9, and AV1.
H.264 is the most widely supported codec across browsers and devices. Every modern browser can decode H.264, and hardware acceleration is nearly universal. If your priority is maximum compatibility and you are streaming to a diverse audience with unknown device capabilities, H.264 is the safest choice. The trade-off is that H.264 is less efficient than newer codecs, meaning you need more bandwidth to achieve the same visual quality.
VP9, developed by Google, offers significantly better compression efficiency than H.264. It is supported in Chrome, Firefox, and Edge, but not universally in Safari (though Safari support has improved in recent versions). VP9 is a strong choice when you know your audience primarily uses Chromium-based browsers and you want to reduce bandwidth costs without sacrificing quality.
AV1 is the newest codec of the three, offering the best compression efficiency. As of 2026, AV1 is supported in Chrome, Firefox, and Edge, with Safari adding support in more recent versions. AV1 decoding is hardware-accelerated on newer devices, but older hardware may struggle with software decoding. If you are building for a tech-savvy audience with modern hardware and want the lowest possible bandwidth at high quality, AV1 is worth the trade-off in compatibility.
A practical approach for production deployments is to default to H.264 for broad compatibility and offer VP9 or AV1 as options for viewers on capable browsers. SRS makes this flexible by allowing codec selection through the WHIP and WHEP URL parameters.
Configuring SRS for WebRTC
Configuring SRS for WebRTC involves three primary areas: the rtc_server block, the candidate IP setting, and codec parameters. Each plays a distinct role in making your WebRTC streams accessible and performant.
The rtc_server block is the top-level configuration section that enables WebRTC functionality in SRS. Within this block, you define whether the WebRTC server is enabled, which port it listens on for UDP media traffic, and various security and protocol settings. The default configuration enables WebRTC on the standard port, but production deployments often need customization based on network topology and firewall rules.
The candidate setting is arguably the most critical and most commonly misconfigured parameter in SRS WebRTC. It tells SRS which IP address to advertise in its ICE candidates when responding to browser SDP offers. If this is set incorrectly, browsers receive unreachable ICE candidates and the WebRTC connection fails silently.
Codec parameters can be specified at the stream level rather than in the configuration file. SRS allows you to request specific codecs by appending parameters to the WHIP and WHEP endpoint URLs. This gives you per-stream flexibility without restarting the server.
Here is a visual representation of the SRS WebRTC configuration hierarchy:
Candidate IP Setup
The candidate field in the SRS configuration tells the server which IP address to include in ICE candidate responses. When a browser sends an SDP offer to SRS, SRS responds with an SDP answer that includes ICE candidates. These candidates are the addresses the browser will try to connect to for media exchange over UDP.
If SRS is running on a server with a public IP address, you set the candidate to that public IP. If SRS is behind a NAT or running in Docker with port mapping, you must set the candidate to the externally reachable IP address, not the internal container IP. The most common mistake developers make is leaving the candidate unset or set to a local IP, which causes browsers on other networks to fail connection because they receive an unreachable address.
SRS does have an auto-detect feature that attempts to determine the server's public IP, but this is unreliable in containerized environments and behind load balancers. In production, always set the candidate explicitly to the IP address that browsers can reach over the internet.
Enabling AV1 and VP9
To use AV1 or VP9 instead of the default H.264 codec, you specify the codec parameter when constructing your WHIP and WHEP endpoint URLs. For AV1, you append a codec parameter with the value av1 to the WHIP URL used by the publisher and the WHEP URL used by viewers. For VP9, you use the value vp9 in the same way.
The publisher and all viewers must agree on the codec. If the publisher streams using AV1 but a viewer requests H.264 via their WHEP URL, the connection will fail because SRS does not transcode between codecs. This means you need to coordinate codec selection between publisher and viewers, either by hardcoding the same codec for all participants or by implementing a negotiation layer in your application logic.
A practical pattern is to default to H.264 for the publisher and allow viewers to request VP9 or AV1 if their browser supports it. However, since SRS passes through the publisher's codec without transcoding, all viewers must use the same codec the publisher selected. Plan your codec strategy before deployment.
Deploying SRS (Docker or Binary)
SRS offers two primary deployment methods: running the pre-built binary directly on a server or using the official Docker image. Both approaches are valid, and the choice depends on your infrastructure preferences and operational requirements.
The binary deployment involves downloading the compiled SRS binary for your platform and running it with a configuration file. This approach gives you direct control over the process and is straightforward for single-server deployments. You manage the process lifecycle, log rotation, and updates manually or through a process manager like systemd.
Docker deployment is the more popular choice for modern infrastructure. The official SRS Docker image is available on Docker Hub and can be run with a single command. You map the WebRTC UDP port range, the HTTP port for WHIP and WHEP signaling, and optionally the RTMP and SRT ports. You also mount your configuration file or pass configuration via environment variables.
For production deployments, several considerations go beyond the basic setup. HTTPS is essential for WebRTC in browsers because getUserMedia (the API that accesses camera and microphone) requires a secure context. You can terminate TLS at a reverse proxy like Nginx and forward HTTP to SRS internally. You also need to ensure your firewall allows UDP traffic on the port range SRS uses for WebRTC media, which is typically a range of ports rather than a single port.
TURN server fallback is another production consideration. If a viewer is behind a restrictive firewall or NAT that blocks UDP to SRS, a TURN server can relay media over TCP. SRS does not include a built-in TURN server, so you would need to deploy one separately (such as coturn) and configure it in your ICE servers list on the browser side. For developers who want TURN, signaling, and media relay handled as part of a single platform, VideoSDK's REST APIs provide a managed alternative.
Integrating WebRTC with Unity
Unity developers can leverage SRS WebRTC for game streaming, virtual reality experiences, and real-time 3D scene broadcasting. The integration uses the same WHIP endpoint that browser publishers use, but the media source is a Unity camera render texture or an audio source rather than a webcam feed.
The Unity WebRTC package provides the underlying peer connection functionality. You create a peer connection, generate an SDP offer, and send it to the SRS WHIP endpoint via HTTP. SRS responds with an SDP answer, and the WebRTC connection is established. Unity then encodes the video frames from your designated camera and sends them as RTP packets to SRS, which relays them to browser-based viewers.
This setup is particularly useful for cloud rendering scenarios where a Unity application runs on a server and streams its output to thin clients. Game studios use this pattern for cloud gaming prototypes, architectural visualization walkthroughs, and remote collaboration tools where the 3D rendering happens on a powerful server and the result is streamed to lightweight clients.
The main challenge with Unity integration is performance. Encoding video in real-time while maintaining acceptable frame rates for the Unity application requires careful resource management. You need to balance video resolution, frame rate, and encoding quality against the CPU and GPU resources your Unity scene already consumes. Starting with a lower resolution and adjusting upward based on available headroom is a practical approach.
Common Troubleshooting Scenarios
WebRTC connections can fail for reasons that are not immediately obvious. Understanding the most common failure modes helps you diagnose and fix issues quickly.
ICE gathering failures are the most frequent problem. When a browser cannot establish a UDP connection to SRS, the ICE process fails and the WebRTC connection never completes. The root cause is almost always the candidate IP configuration. If SRS advertises a private IP or an incorrect public IP, browsers on different networks cannot reach it. Check that the candidate field in your SRS configuration matches the externally reachable IP address. If you are running SRS in Docker, ensure the candidate is set to the host machine's public IP, not the container's internal IP.
Codec negotiation errors occur when the publisher and viewer request incompatible codecs. SRS does not transcode, so if the publisher sends AV1 and the viewer expects H.264, the connection fails during SDP negotiation. Verify that both publisher and viewer use the same codec parameter in their WHIP and WHEP URLs. Check the browser console for codec-related SDP errors.
Firewall and NAT issues can block UDP traffic entirely. If your server's firewall only allows TCP, WebRTC media cannot flow. Ensure that the UDP port range configured for SRS is open on both the server firewall and any cloud provider security groups. If UDP is not an option, you need a TURN server configured to relay media over TCP.
HTTPS mixed content errors prevent WebRTC from initializing. If your web page is served over HTTPS but the WHIP or WHEP endpoint URL uses HTTP, browsers block the request. Always serve WHIP and WHEP endpoints over HTTPS, either directly from SRS or through a reverse proxy that handles TLS termination.
Best Practices for Low-Latency Streaming
Achieving consistently low latency with SRS WebRTC requires attention to several factors beyond basic configuration. Network conditions, encoding settings, and monitoring all play roles in maintaining a high-quality streaming experience.
Choose the right resolution and frame rate for your use case. Streaming 1080p at 60 frames per second requires significantly more bandwidth and CPU than 720p at 30 frames per second. For live streaming scenarios where latency matters more than maximum resolution, 720p or even 480p at 30 frames per second often delivers a better viewer experience because the stream is more stable under variable network conditions.
Monitor your streams actively. SRS provides HTTP-based statistics endpoints that report current connections, bandwidth usage, and stream metadata. Integrate these metrics into your monitoring stack so you can detect issues before viewers complain. Key metrics to watch include concurrent viewer count, per-stream bandwidth, and ICE connection failure rates.
Budget your bandwidth conservatively. If your server has a 100 Mbps network connection and each viewer consumes 3 Mbps, you can serve roughly 30 viewers before hitting the network ceiling. Plan your capacity based on realistic per-viewer bandwidth estimates, and consider adding a CDN or additional SRS instances for horizontal scaling when your audience grows.
For developers who want network-adaptive streaming, automatic bitrate adjustment, and built-in monitoring without managing infrastructure, VideoSDK handles these concerns automatically as part of its SDK.
Definitions Glossary
SRS (Simple Realtime Server): An open-source, high-performance media server that supports WebRTC, RTMP, SRT, and HLS protocols for real-time video streaming and distribution.
SFU (Selective Forwarding Unit): A media routing architecture where the server receives a single encoded stream from a publisher and forwards it to multiple viewers without transcoding, reducing CPU overhead and enabling scalable low-latency streaming.
WHIP (WebRTC HTTP Ingestion Protocol): An IETF-defined protocol that allows browsers and applications to publish WebRTC streams to a media server using standard HTTP POST requests for SDP exchange.
WHEP (WebRTC HTTP Egress Protocol): An IETF-defined protocol that allows browsers and applications to subscribe to WebRTC streams from a media server using standard HTTP POST requests for SDP exchange.
ICE (Interactive Connectivity Establishment): A WebRTC framework that discovers and tests network paths (host, server-reflexive, and relay candidates) between peers to establish a usable media connection across different network topologies.
Key Takeaways
- SRS WebRTC provides sub-second latency streaming by acting as an SFU that relays RTP packets from publishers to viewers without transcoding, keeping server CPU usage low.
- The candidate IP setting is the most critical and most commonly misconfigured parameter in SRS WebRTC, and it must always be set to the externally reachable IP address in production deployments.
- Codec selection (H.264, VP9, or AV1) impacts bandwidth, quality, and browser compatibility, and all participants in a stream must use the same codec since SRS does not transcode.
- WHIP and WHEP protocols simplify WebRTC signaling by using standard HTTP POST requests for SDP exchange, eliminating the need for a custom WebSocket signaling server.
- For developers who need managed WebRTC infrastructure with network-adaptive streaming, TURN fallback, and multi-platform SDKs, VideoSDK offers a production-ready alternative to self-hosting SRS.
Conclusion
SRS WebRTC delivers a compelling combination of open-source flexibility and ultra-low-latency streaming for developers who want control over their media infrastructure. By acting as an efficient SFU with HTTP-based WHIP and WHEP signaling, SRS removes much of the complexity traditionally associated with WebRTC deployments. The key to success lies in correct candidate IP configuration, thoughtful codec selection, and proper production hardening with HTTPS and TURN fallback.
If you are building a real-time streaming application and want to evaluate SRS, start with a Docker deployment on a server with a public IP, configure the candidate correctly, and test with a simple browser publisher and viewer. The results will tell you quickly whether SRS meets your latency and quality requirements.
For teams that need a fully managed WebRTC solution with built-in room management, recording, transcription, and multi-platform SDKs across React, Flutter, iOS, Android, and more, VideoSDK provides an alternative that eliminates infrastructure management entirely. You can sign up for free at app.videosdk.live/login and start building in minutes.
What are you building with SRS WebRTC or VideoSDK? Drop a comment below, I would love to hear what kind of low-latency streaming use case you are working on.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ