> ## Documentation Index
> Fetch the complete documentation index at: https://docs.streampixel.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Network requirements
> Ports, protocols, and STUN/TURN IP ranges that need to be reachable for Streampixel to deliver low-latency streams.
If a viewer's stream is laggy, blurry, or won't connect at all, the network is the most common culprit. This page lists exactly what needs to be reachable for Streampixel to work well — share it with your IT team or network admin when you need firewall changes.
## Required ports
Open the following ports outbound from the viewer's network:
| Port | Protocol | Purpose | TLS | Required |
| ------------- | -------- | ----------------------------------------- | --- | -------- |
| **3478** | **UDP** | TURN — primary media path | No | **Yes** |
| 3478 | TCP | TURN fallback | No | Yes |
| 443 | TCP | TURN over TLS | Yes | Yes |
| 5349 | TCP | TURN over TLS | Yes | Yes |
| 10000 – 60000 | UDP | Direct peer connection to rendering nodes | No | Optional |
**UDP 3478 is the most important port.** If it's blocked, WebRTC media falls back to TCP, which adds head-of-line blocking and significantly degrades stream quality — expect blurriness, frame drops, and higher latency. Always open UDP 3478 first.
### About the optional UDP 10000–60000 range
This range is **not required** for streaming to work — it's an optimization. When these ports are open, the viewer can establish a **direct peer-to-peer connection to the rendering node** instead of routing media through a TURN relay server. The result is lower latency, since media takes one fewer hop.
If the range is blocked, the connection still completes — it just goes through the TURN relay (UDP 3478). For latency-sensitive use cases (interactive games, simulations, VR), opening this range is worth the effort. For most other workloads, the relay path is fine.
## Why UDP matters
WebRTC is designed around UDP. Video frames are time-sensitive — a packet that arrives late is worse than a packet that's dropped, because TCP will retransmit the late packet and stall every frame behind it. UDP just keeps moving.
When UDP is blocked, the SDK falls back to TURN-over-TCP (port 3478 TCP, then 443/5349 over TLS). Connections still complete, but you'll see:
* Increased latency — typically +50 to +200 ms
* Pixelation and motion blur during congestion
* Dropped frames instead of graceful bitrate adaptation
* Choppy audio under load
If your audience includes corporate, hospital, or hotel networks, ask their IT team to allow UDP 3478 outbound.
## STUN / TURN IP ranges
Streampixel uses Twilio's global STUN/TURN infrastructure. To allow these IPs through restrictive firewalls, or to apply Quality of Service routing, allow the ranges below.
**Whitelist all Twilio regions, not just the one closest to you.** Twilio routes connections to the nearest healthy edge dynamically — if the closest region is unavailable or congested, your traffic may be served from another region. Limiting the allow-list to a single region causes connections to fail when failover happens.
| CIDR block | IP lower bound | IP upper bound | Addresses |
| ---------------- | -------------- | -------------- | --------- |
| 3.25.42.128/25 | 3.25.42.128 | 3.25.42.255 | 128 |
| 13.210.2.128/27 | 13.210.2.128 | 13.210.2.159 | 32 |
| 54.252.254.64/26 | 54.252.254.64 | 54.252.254.127 | 64 |
| CIDR block | IP lower bound | IP upper bound | Addresses |
| ----------------- | -------------- | -------------- | --------- |
| 18.230.125.0/25 | 18.230.125.0 | 18.230.125.127 | 128 |
| 18.231.105.32/27 | 18.231.105.32 | 18.231.105.63 | 32 |
| 177.71.206.192/26 | 177.71.206.192 | 177.71.206.255 | 64 |
| CIDR block | IP lower bound | IP upper bound | Addresses |
| ---------------- | -------------- | -------------- | --------- |
| 18.156.18.128/25 | 18.156.18.128 | 18.156.18.255 | 128 |
| 18.195.48.224/27 | 18.195.48.224 | 18.195.48.255 | 32 |
| 52.59.186.0/27 | 52.59.186.0 | 52.59.186.31 | 32 |
| CIDR block | IP lower bound | IP upper bound | Addresses |
| --------------- | -------------- | -------------- | --------- |
| 3.7.35.128/25 | 3.7.35.128 | 3.7.35.255 | 128 |
| 52.66.193.96/27 | 52.66.193.96 | 52.66.193.127 | 32 |
| 52.66.194.0/26 | 52.66.194.0 | 52.66.194.63 | 64 |
| CIDR block | IP lower bound | IP upper bound | Addresses |
| ----------------- | -------------- | -------------- | --------- |
| 3.249.63.128/25 | 3.249.63.128 | 3.249.63.255 | 128 |
| 54.171.127.192/26 | 54.171.127.192 | 54.171.127.255 | 64 |
| 52.215.127.0/24 | 52.215.127.0 | 52.215.127.255 | 256 |
| 52.215.253.0/26 | 52.215.253.0 | 52.215.253.63 | 64 |
| CIDR block | IP lower bound | IP upper bound | Addresses |
| ----------------- | -------------- | -------------- | --------- |
| 13.115.244.0/27 | 13.115.244.0 | 13.115.244.31 | 32 |
| 18.180.220.128/25 | 18.180.220.128 | 18.180.220.255 | 128 |
| 54.65.63.192/26 | 54.65.63.192 | 54.65.63.255 | 64 |
| CIDR block | IP lower bound | IP upper bound | Addresses |
| ----------------- | -------------- | -------------- | --------- |
| 13.229.255.0/27 | 13.229.255.0 | 13.229.255.31 | 32 |
| 18.141.157.128/25 | 18.141.157.128 | 18.141.157.255 | 128 |
| 54.169.127.128/26 | 54.169.127.128 | 54.169.127.191 | 64 |
| CIDR block | IP lower bound | IP upper bound | Addresses |
| ---------------- | -------------- | -------------- | --------- |
| 3.235.111.128/25 | 3.235.111.128 | 3.235.111.255 | 128 |
| 34.203.250.0/23 | 34.203.250.0 | 34.203.251.255 | 512 |
| 34.203.254.0/24 | 34.203.254.0 | 34.203.254.255 | 256 |
| 54.172.60.0/23 | 54.172.60.0 | 54.172.61.255 | 512 |
| CIDR block | IP lower bound | IP upper bound | Addresses |
| ----------------- | -------------- | -------------- | --------- |
| 34.216.110.128/27 | 34.216.110.128 | 34.216.110.159 | 32 |
| 44.234.69.0/25 | 44.234.69.0 | 44.234.69.127 | 128 |
| 54.244.51.0/24 | 54.244.51.0 | 54.244.51.255 | 256 |
These ranges are managed by Twilio and may change. If you maintain a strict allow-list, re-check the official Twilio documentation periodically.
## Quick checklist for IT teams
If a stream isn't working from a corporate or restricted network, ask the network admin to confirm:
* [ ] **UDP port 3478 outbound is allowed** (most important)
* [ ] TCP ports 443, 3478, and 5349 outbound are allowed
* [ ] The Twilio IP ranges for **all regions** are not blocked (Twilio fails over between regions, so a single-region allow-list is not enough)
* [ ] WebRTC is not disabled at the browser policy level (some enterprise browsers disable it)
* [ ] The dashboard domain (`dashboard.streampixel.io`) and your project's stream URL are reachable
* [ ] *(Optional, for lower latency)* UDP ports 10000–60000 outbound are allowed — enables direct peer connection to the rendering node instead of relaying through TURN
If all of the above are open and streams are still degraded, contact [support](mailto:support@streampixel.io) with a stream-stats sample (see [Diagnosing stream quality](/resources/web-sdk/guides/troubleshooting#stream-is-blurry-or-pixelated)).
## Next
Diagnose blurry streams, connection failures, and audio issues.
Hit your latency, FPS, and bitrate targets.