SRTLA Bonding with BELABOX: Mobile Streaming Made Reliable
The Mobile Streaming Problem
Streaming from a fixed location with fiber internet is straightforward. You have consistent bandwidth, low jitter, and predictable latency. Streaming from a moving vehicle, a crowded stadium, a protest march, or a remote mountainside is an entirely different challenge.
A single cellular connection is unreliable by nature. Bandwidth fluctuates as you move between cell towers. Congestion during events can cut throughput to a fraction of normal. Dead zones appear without warning. If your entire stream depends on one SIM card, a single dropped connection means your broadcast goes dark.
This is the problem SRTLA bonding solves.
What is SRTLA?
SRTLA stands for SRT Live Association (sometimes called SRT Link Aggregation). It is an extension to the SRT protocol that bonds multiple network connections into a single, aggregated stream. The core idea is simple:
- Your encoder sends the same SRT stream across multiple network paths simultaneously
- A server-side component (the SRTLA receiver) collects packets from all paths
- Duplicate packets are discarded, missing packets are filled in from whichever path delivered them
- The reconstructed stream is forwarded as a standard SRT stream
The result: your effective bandwidth is the sum of all connections, and your reliability is dramatically higher because a packet only needs to arrive on one path to be delivered.
How Bonding Differs from Failover
These are often confused, but they solve different problems:
| Bonding (SRTLA) | Failover | |
|---|---|---|
| Active connections | All paths active simultaneously | One primary, others standby |
| Bandwidth | Aggregated across all paths | Limited to active path |
| Switching | Transparent (no switch event) | Detectable gap during switch |
| Use case | Mobile, unreliable networks | Fixed infrastructure redundancy |
| Complexity | Higher (multi-path management) | Lower (primary/backup logic) |
Bonding gives you both more bandwidth and more resilience. Failover gives you a safety net for catastrophic failure. In a professional mobile streaming setup, you use both: SRTLA bonding for the contribution path, and gateway-level failover as the last line of defense.
What is BELABOX?
BELABOX is a purpose-built mobile streaming encoder designed for IRL (In Real Life) streaming, live news gathering, and field production. It is available as both a dedicated hardware unit and as software that runs on single-board computers like the Jetson Nano.
Key features relevant to SRTLA:
- Multiple modem support: connect 2-4+ USB cellular modems simultaneously
- SRTLA bonding built-in: splits the SRT stream across all available connections
- Wi-Fi and Ethernet: additional bonding paths beyond cellular
- Battery-powered options: for truly mobile use
- Low latency: hardware encoding with direct SRT/SRTLA output
- Remote management: cloud dashboard for monitoring and configuration
BELABOX is one of the most popular encoders in the IRL streaming community precisely because of its SRTLA implementation. It turns unreliable cellular connections into a production-grade contribution path.
Architecture: BELABOX to Vajra Cast
Here is the complete signal chain for a bonded mobile stream:
┌─ Modem 1 (4G) ──┐
Camera → BELABOX ──├─ Modem 2 (5G) ──├──► SRTLA Server ──► Vajra Cast ──► Outputs
├─ Wi-Fi ─────────┤
└─ Ethernet ──────┘
(SRTLA) (SRT) (SRT/RTMP)
- BELABOX encodes the video and splits it across all available network connections using SRTLA
- SRTLA Server receives packets from all paths, reconstructs the single SRT stream, and forwards it
- Vajra Cast receives the reconstructed SRT stream, applies routing rules, and distributes to all outputs
The SRTLA server can run on the same machine as Vajra Cast or on a separate server. For the simplest setup, run them together.
Setting Up the SRTLA Server
The SRTLA server is the bonding endpoint that reassembles packets from multiple network paths. You need this running on a server with a public IP address.
Option 1: srtla_rec (Reference Implementation)
The official SRTLA receiver (srtla_rec) is open-source:
# Clone and build
git clone https://github.com/BELABOX/srtla.git
cd srtla
make
# Run the SRTLA receiver
./srtla_rec 5000 127.0.0.1 9000
Parameters:
5000: the SRTLA listening port (what BELABOX connects to)127.0.0.1: the SRT destination (your Vajra Cast instance)9000: the SRT destination port
This tells srtla_rec to listen for SRTLA connections on UDP port 5000, reassemble them, and forward the reconstructed SRT stream to localhost port 9000.
Option 2: Docker Deployment
For production, run SRTLA in a container:
docker run -d \
--name srtla \
--network host \
-e SRTLA_PORT=5000 \
-e SRT_HOST=127.0.0.1 \
-e SRT_PORT=9000 \
belabox/srtla-receiver:latest
Using --network host is important because SRTLA needs to see the real source IPs of incoming packets to properly track each bonded connection.
Firewall Configuration
Open the SRTLA port for UDP inbound:
# iptables
iptables -A INPUT -p udp --dport 5000 -j ACCEPT
# ufw
ufw allow 5000/udp
# firewalld
firewall-cmd --add-port=5000/udp --permanent
firewall-cmd --reload
Note: you only need to expose the SRTLA port (5000) to the internet. The SRT port (9000) can stay internal if srtla_rec and Vajra Cast run on the same machine.
Configuring Vajra Cast
With the SRTLA server forwarding to port 9000, set up Vajra Cast to receive the reconstructed SRT stream:
- Create an SRT Listener ingest on port 9000
- Set latency to 1500-3000ms (SRTLA streams need generous buffers due to multi-path jitter)
- Enable encryption if your BELABOX is configured with a passphrase
- Create outputs as needed:
- SRT push to a production server
- RTMP push to YouTube/Twitch
- Local recording for archival
The SRT latency setting deserves special attention for SRTLA. Because packets arrive via different network paths with different latencies, the jitter is inherently higher than a single-path SRT connection. Start with 2000ms and reduce only after observing the actual RTT and jitter in Vajra Cast’s monitoring dashboard.
For detailed latency tuning guidance, see our SRT Latency Tuning guide.
Configuring BELABOX
Network Connections
Connect your cellular modems and configure each one:
- Insert SIM cards into USB modems (recommended: at least 2 different carriers)
- Connect modems to BELABOX USB ports
- Connect Wi-Fi if available (adds another bonding path)
- Connect Ethernet if available (e.g., venue press room)
Using different carriers is crucial. If all your SIMs are on the same carrier, a single tower outage or congestion event affects all connections simultaneously. Carrier diversity is the key to reliable bonding.
SRTLA Output Configuration
In the BELABOX interface:
Protocol: SRTLA
Host: your-server.com
Port: 5000
Latency: 2000 (ms)
Passphrase: YourSecurePassphrase (optional but recommended)
Key Length: 32 (AES-256)
Encoder Settings
Optimize the encoder for mobile streaming:
Codec: H.264 (wider compatibility) or HEVC (lower bitrate)
Resolution: 1920x1080 (or 1280x720 for bandwidth-limited scenarios)
Bitrate: 4000-6000 Kbps (H.264) or 2500-4000 Kbps (HEVC)
Keyframe Interval: 2 seconds
Profile: High
Rate Control: CBR
CBR (Constant Bitrate) is strongly recommended for SRTLA. Variable bitrate causes unpredictable bandwidth demands across bonded connections, making the splitting algorithm less efficient.
Bonding Strategy
BELABOX supports different bonding modes:
- Aggregate: split packets across all connections weighted by available bandwidth. Maximum total throughput.
- Broadcast: send every packet on every connection. Maximum redundancy, but bandwidth-expensive.
- Failover: use the best connection, switch on failure. Minimum bandwidth use, but no aggregation.
For most mobile scenarios, Aggregate is the right choice. Use Broadcast only when bandwidth is abundant and reliability is absolutely critical (e.g., live news with contractual uptime requirements).
Real-World Scenarios
IRL Streaming
IRL (In Real Life) streaming means walking through cities, attending events, and being constantly on the move. The network changes every few minutes.
Typical setup:
- BELABOX in a backpack
- 2-3 USB modems (different carriers)
- Action camera or mirrorless with HDMI capture
- Battery pack for 4-6 hour runtime
Configuration tips:
- Set bitrate to 4000 Kbps (H.264). Aggressive enough for good quality, conservative enough for cellular
- Use 720p if you have fewer than 3 modems
- Set SRT latency to 3000ms. IRL networks are unpredictable; buffer generously
- Enable HEVC if your BELABOX hardware supports it (40% bitrate savings at equivalent quality)
Expected performance:
- 2 modems (4G): 4-8 Mbps aggregated, 95%+ uptime
- 3 modems (4G+5G): 10-20 Mbps aggregated, 98%+ uptime
- 4 modems (mixed carriers): 15-30 Mbps aggregated, 99%+ uptime
Live News Gathering (ENG)
News crews need to go live from anywhere, often in breaking-news situations where there is no time to set up satellite uplinks.
Typical setup:
- Professional camera with SDI output
- BELABOX with SDI input card
- 4 modems (two different carriers, two SIMs each)
- On-site Wi-Fi as a bonus path when available
Configuration tips:
- Bitrate: 6000-8000 Kbps (broadcast quality requires higher bitrate)
- Resolution: 1080p mandatory for broadcast
- Latency: 2000ms (balance between delay and reliability)
- Use AES-256 encryption. News feeds are high-value targets for interception
Workflow with Vajra Cast:
Field camera → BELABOX → SRTLA → Vajra Cast (newsroom) → SDI output to control room
→ SRT to remote producers
→ Recording for archive
The newsroom Vajra Cast instance acts as the central routing hub, converting the incoming SRTLA/SRT stream to whatever formats the production infrastructure needs.
Sports and Live Events
Stadium events present a unique challenge: tens of thousands of people competing for the same cell towers. This is where carrier diversity and aggressive bonding pay off.
Typical setup:
- Multiple camera positions, each with a BELABOX
- 4 modems per BELABOX (4 different carriers if possible)
- Pre-event site survey to identify best carrier coverage
- Dedicated SRTLA servers per camera feed
Configuration tips:
- Run a site survey before the event: test each carrier’s bandwidth at the venue during a comparable crowd size
- Pre-bond Wi-Fi from the venue’s press network if available
- Set latency to 2500-3500ms. Stadium congestion causes jitter spikes
- Configure Vajra Cast failover between camera feeds in case an entire BELABOX loses connectivity
Multi-camera architecture:
Camera 1 → BELABOX 1 → SRTLA → Vajra Cast → [Switcher Input 1]
Camera 2 → BELABOX 2 → SRTLA → Vajra Cast → [Switcher Input 2]
Camera 3 → BELABOX 3 → SRTLA → Vajra Cast → [Switcher Input 3]
Each BELABOX feeds into its own SRT ingest on Vajra Cast. The gateway provides monitoring across all feeds and can output to a video switcher via SRT or SDI (with a decoder).
Monitoring Bonded Streams
Once your SRTLA stream is flowing through Vajra Cast, monitor these metrics:
Per-Connection Metrics (BELABOX Side)
- Per-modem throughput: which connections are carrying the most traffic?
- Per-modem packet loss: is one carrier worse than others?
- Connection count: are all bonded connections active?
Aggregated Stream Metrics (Vajra Cast Side)
- Total bitrate: does it match your encoder settings?
- RTT: is the round-trip stable? SRTLA streams typically show higher RTT than single-path SRT.
- Jitter: multi-path delivery inherently increases jitter. Watch for sustained spikes.
- Retransmission rate: some retransmission is normal with SRTLA. Sustained rates above 10% suggest insufficient total bandwidth.
- Dropped packets: zero is the target. Any drops mean your SRT latency buffer is too small.
Vajra Cast exposes all SRT statistics in the real-time dashboard and via the Prometheus /metrics endpoint for integration with Grafana or other monitoring tools.
Troubleshooting Common Issues
BELABOX connects but stream is choppy
Cause: Insufficient aggregate bandwidth. Your total cellular throughput is less than your encoding bitrate plus SRT overhead.
Fix: Lower your encoding bitrate, add another modem, or switch to HEVC to reduce bandwidth requirements by 40%.
High retransmission rate on Vajra Cast
Cause: Large RTT differences between bonded connections. When one path has 30ms RTT and another has 200ms, the jitter is extreme.
Fix: Increase SRT latency on the Vajra Cast ingest. For mixed-latency paths, use latency >= 4x the slowest path’s RTT.
One modem disconnects repeatedly
Cause: Poor signal, carrier throttling, or SIM data cap reached.
Fix: Check signal strength in BELABOX dashboard. Replace the SIM or move to a different position. SRTLA handles modem reconnection automatically. The stream continues on remaining paths.
SRTLA server not receiving packets
Cause: Firewall blocking UDP, or wrong port.
Fix: Verify UDP is open on the SRTLA port. Test with nc -u -l 5000 on the server and echo test | nc -u server 5000 from a client.
Stream delay is too high
Cause: SRT latency set too conservatively.
Fix: Reduce latency incrementally. Monitor dropped packets. If you see zero drops at 3000ms, try 2500ms, then 2000ms. Stop when drops appear and back off by 25%.
Best Practices Summary
- Use at least 2 cellular carriers. Carrier diversity is more valuable than more SIMs on the same carrier.
- Start with generous latency (3000ms) and tune down after observing real-world metrics.
- Use CBR encoding. SRTLA splits packets more efficiently with predictable bitrate.
- Enable AES-256 encryption. Cellular networks are shared infrastructure; encrypt everything.
- Monitor all paths. A dead modem you do not know about reduces your redundancy.
- Run a site survey for planned events. Test carrier coverage before show day.
- Keep encoding bitrate below 70% of aggregate bandwidth. Leave headroom for SRT retransmissions.
- Use HEVC when possible. 40% bitrate reduction means fewer packets to bond and recover.
SRTLA bonding with BELABOX and Vajra Cast transforms mobile streaming from a fragile, best-effort exercise into a reliable, production-grade workflow. The combination of multi-path bonding on the encoder side and intelligent routing and failover on the gateway side gives you resilience that no single connection can match.
For more on configuring SRT parameters, see our SRT Streaming Gateway guide. For encryption setup details, read SRT Encryption Setup.