WebRTC ports are not a single fixed list. In live video, the browser first has to reach the signaling service, then discover a usable network path, and finally move audio and video across whatever route survives NAT and firewall rules. This article breaks that stack into practical pieces so you can tell which ports matter, which ones are only fallbacks, and what to open for reliable streaming.
What matters most when browser-based video needs a stable path
- WebRTC depends on several layers, not one universal port, so signaling, STUN, TURN, and media each behave differently.
- 443/TCP is usually the safest signaling and fallback port, but it does not replace the need for media-friendly UDP where possible.
- 3478/UDP is the most common STUN and TURN listening port, while 5349/TCP and 443/TCP are common secure TURN fallbacks.
- Media often rides on negotiated ephemeral UDP ports, especially in peer-to-peer and SFU-based live video.
- For self-hosted live streaming, the exact UDP range is product-specific, so the vendor docs matter more than any generic checklist.
What WebRTC actually needs from the network
I separate the flow into control and media because they fail differently. Signaling is the setup layer: authentication, session description, codec negotiation, and the exchange of ICE candidates. Media is the real-time SRTP traffic that carries the stream once a path is chosen. If signaling works but audio never arrives, the problem is usually not the website port; it is the route selection or the firewall in front of media.
MDN’s explanation of ICE is the clearest shorthand: the browser tries to find a path that can get through NAT and firewalls, then falls back to relays when direct connectivity is not possible. That is why the same live video app can behave differently on home broadband, mobile data, and a locked-down office network. Once that split is clear, the port story becomes much easier to read.
The next step is the route-finding logic itself, because that is where most of the confusion around browser-based video starts.
How ICE, STUN, and TURN choose the route
Think of ICE as the path-finding layer. Each candidate is a possible route: host candidates use local addresses, server-reflexive candidates come from STUN, and relay candidates come from TURN. The browser checks them in order of viability and picks the first stable pair it can maintain. That is why the same meeting can be direct on one network and relayed on another, without the user seeing anything unusual.
STUN is the lightweight lookup step. The client asks a STUN server which public address and port the outside world can see. TURN is the fallback when a direct connection is blocked; it relays traffic through a server, which is more reliable but adds latency and bandwidth cost. In live video, that tradeoff is often worth it when your audience sits behind restrictive firewalls.
This also explains why network policy matters so much: if UDP is filtered too aggressively, the browser may still connect, but it will do so through a more expensive relay path.
The ports you will actually see in practice
These are the ports I expect to see most often in production. The exact numbers are not universal, but the roles are consistent.
| Part of the flow | Typical ports | What it does | What I would check |
|---|---|---|---|
| Signaling | 443/TCP, sometimes 80/TCP in testing | Exchanges session data, auth, and SDP offers or answers | HTTPS, WebSocket rules, proxies, certificates |
| STUN | 3478/UDP, sometimes 19302/UDP in Google-style deployments | Discovers the public address and NAT mapping | Outbound UDP, DNS, and reachability to the STUN host |
| TURN | 3478/UDP or TCP, 5349/TCP, sometimes 443/TCP or TLS | Relays media when direct peer paths fail | Credentials, TLS inspection, firewall allowlists |
| Media | Negotiated ephemeral UDP ports | Carries SRTP audio and video | Whether UDP is permitted and whether relay is being forced |
| SFU or streaming server | Product-specific UDP range | Receives and redistributes media for many participants | Vendor docs, server logs, port range sizing |
Google Meet is a useful real-world example of how app-specific this can be: its rollout notes added UDP 3478 while keeping 19302–19309 as a fallback path. The point is not to memorize one vendor’s list; it is to understand that the exact media ports belong to the service, not to WebRTC itself. That leads directly to the architecture you are shipping.
Once you know which ports belong to which layer, the next question is whether your live video setup is trying to be peer-to-peer, relay-based, or server-centered.
Which live video architecture you are actually shipping
For live video, port policy depends on whether you are building peer-to-peer calls, a TURN-backed fallback, or a one-to-many streaming stack. I usually map the architecture before I touch the firewall, because the right answer is different in each case.| Architecture | Port pattern | Best for | Tradeoff |
|---|---|---|---|
| Peer to peer | Dynamic UDP between browsers | Small meetings, low-latency collaboration | Least predictable behind firewalls |
| TURN relay | Outbound to relay ports such as 3478, 5349, or 443 | Restrictive networks and reliable fallback | More latency and relay bandwidth cost |
| SFU or live streaming server | Client to server UDP range or relay port | One-to-many sessions, moderation, recording | Requires a server-side port plan and capacity planning |
For a small internal call, peer-to-peer can be fine if the network is generous. For a public live stream or a studio workflow, I usually prefer an SFU or a relay-backed design because it scales more predictably and gives me a cleaner operational model. The port question then shifts from “Can the browser connect at all?” to “Which paths are allowed, and how much control do I have over them?”
That is the point where firewall policy becomes the practical problem, not the browser itself.
What to open in a firewall first
If I had to build a sensible baseline for a live video deployment, I would start narrow and expand only when the logs justify it. The goal is not to open everything; it is to let the application negotiate the best path without making the network too permissive.
- 443/TCP for signaling and secure fallback. This keeps auth and session setup working almost everywhere.
- 3478/UDP for STUN and basic TURN. This is the most common low-friction opening.
- 5349/TCP or 443/TCP for TURN over TLS when UDP is blocked or proxied.
- Vendor-defined UDP range for SFUs, ingest servers, or media relays. Do not guess this one.
- Outbound UDP wherever possible. Blocking it forces more relay use and usually raises latency.
In UK office networks, the pattern I see most often is not a missing browser permission; it is an over-tight egress policy or a TLS inspection box that interferes with relay fallback. If you can only change one thing, make sure the environment can reach a secure TURN endpoint on 443. That single change often turns a fragile deployment into one that works on home broadband, mobile data, and corporate Wi-Fi.
When the connection still fails, I move from policy to symptoms and inspect the ICE path directly.
How I troubleshoot blocked connections fast
The cleanest way to debug this is to match the symptom to the layer that is actually failing. A browser can look healthy while the media path is silently falling back or failing over and over again.
| Symptom | Likely cause | Next check |
|---|---|---|
| Signaling connects, media never starts | STUN or TURN is blocked, or credentials are wrong | Inspect the selected ICE candidate pair and relay logs |
| Works at home, fails on office Wi-Fi | UDP is filtered or a proxy is interfering | Test TURN over TLS on 443 and verify outbound rules |
| Audio works, video is unstable | Packet loss, bitrate too high, or relay congestion | Check RTP stats, lower encoding pressure, and review relay capacity |
| Latency suddenly jumps | The session is using a relayed path | Find out why direct candidates are being rejected |
The first metrics I look at are the selected candidate pair, relay ratio, and packet loss. If the app keeps choosing relay candidates, the browser is not the problem; the network policy is forcing the expensive path. That is a good place to stop guessing and start adjusting the allowed ports.
Once you have those signals, the safest deployment pattern becomes much easier to define.
The narrowest safe port set I would ship for live video
For a typical browser-based live video stack, I would keep the default footprint small and explicit. The baseline looks like this:
- 443/TCP for signaling and secure fallback.
- 3478/UDP for STUN and standard TURN discovery.
- 5349/TCP or a TURN-over-443 fallback for restrictive networks.
- A documented UDP media range only if you run an SFU or a media relay that needs one.
- Outbound UDP wherever your network policy can tolerate it.
If I were shipping this for a UK live-video platform today, I would start with that narrow set, measure how often relay paths are selected, and widen the rules only where the data proves I need to. That keeps the stack secure, predictable, and far easier to maintain when viewers move between home broadband, mobile connections, and office firewalls.
