What Is SRTLA? — SRTLA vs. RTMP Explained
Why SRTLA is the best transport for IRL streaming — compared with RTMP.
What Is SRTLA?
SRTLA stands for Secure Reliable Transport Link Aggregation. It's a protocol that bundles multiple internet connections (LTE modems, Wi-Fi, Ethernet) into a single logical uplink and sends packets across all paths in parallel. On the server side, the packets are put back into the correct order.
Developed by BELABOX for IRL streaming — that is, mobile streaming, where individual networks often falter.
Why SRTLA instead of RTMP?
RTMP (Real-Time Messaging Protocol) emerged from the Flash era in 2005. It runs over TCP and was never built for the mobile internet.
TCP vs. UDP
- TCP (RTMP) guarantees ordering and retries packets automatically. The problem: head-of-line blocking. If a single packet is lost on a mobile network, everything after it waits — your stream freezes.
- UDP (SRT/SRTLA) just keeps sending. Packets can briefly arrive out of order, but the stream stays alive. SRT compensates with a jitter buffer on the server side.
Packet loss
Mobile networks typically have 1-5% packet loss. TCP/RTMP retries every lost packet -> latency explodes, often to 10+ seconds, until the stream collapses.
SRT allows a configurable retry window (typically 2000ms latency) — lost packets are only retried if they can still arrive within that time. The rest: gone, but it doesn't matter.
Link aggregation
SRTLA's killer feature: using multiple modems in parallel.
- Belabox: 2x LTE + 1x Wi-Fi = 3 links at once
- Total bandwidth = sum of the links
- If one link dies completely (e.g. you walk into a dead zone), the others take over immediately
With RTMP you'd have to pin your entire stream to a single link — link dies = stream dies.
Comparison table
| Feature | RTMP | SRT | SRTLA |
|---|---|---|---|
| Transport | TCP | UDP | UDP (multiple) |
| Typical latency | 3-6s | 1-3s | 1-3s |
| Behavior on packet loss | Freeze | Jitter-tolerant | Jitter-tolerant |
| Multi-link | No | No | Yes (bonding) |
| Encryption | No (RTMPS only) | AES-128/256 | AES-128/256 |
| Firewall-friendly | Very (80/443/1935) | Medium (9999 UDP) | Medium (5000 UDP) |
| Suited for IRL | Poor | Good | Ideal |
When should you use RTMP?
- Home setup with fiber — your network is stable, SRT brings zero benefit
- Firewall/ISP blocks UDP — RTMP runs everywhere
- Encoder only supports RTMP — many older hardware encoders (e.g. TriCaster) have no SRT
When should you use SRT?
- Mobile/LTE as your uplink
- Low latency matters (interactive chat, Q&A)
- Fluctuating network (travel, event, sports broadcast)
When SRTLA?
- Mobile IRL with multiple modems
- Professional event broadcast with dual-ISP redundancy
- Anywhere a single link doesn't have enough bandwidth
FizzyPeak supports all three
FizzyPeak has a native SRTLA receiver (not via an external relay — we built it ourselves). That means:
- No extra latency from an intermediate relay
- Direct feedback to your encoder (link stats, RTT)
- Ingest endpoint:
srt://ingest.fizzypeak.stream:9999for SRT,srtla://ingest.fizzypeak.stream:5000for SRTLA
For RTMP: rtmp://ingest.fizzypeak.stream/live.
In practice: latency settings
The SRT/SRTLA latency is the jitter buffer on the server side. Too low -> the stream breaks. Too high -> viewers wait longer.
- 1000ms — home fiber, stable Wi-Fi
- 2000ms — standard city LTE (recommended)
- 4000ms — travel, US roaming, unstable 5G
- 8000ms — satellite, really bad network
Latency is set in the URL: ?latency=2000. It only affects the ingest leg — your viewers see no difference, because YouTube/Twitch have their own buffers.
Key point: If you're streaming IRL -> SRT or SRTLA. RTMP only as an absolute fallback.
Noch Fragen? Öffne das Dashboard oder schreib im Discord #support.