srtla_rec is an SRT transport proxy with link aggregation. SRTLA is designed to transport SRT traffic over multiple network links for capacity aggregation and redundancy. Traffic is balanced dynamically depending on network conditions. The primary application is bonding mobile modems for live streaming.
Note: This is a fork of the original SRTLA implementation by BELABOX. The original server component (srtla_rec) was marked as unsupported by BELABOX.
- Support for link aggregation across multiple network connections
- Automatic management of connection groups and individual connections
- Robust error handling and timeouts for inactive connections
- Logging of connection details for easy diagnostics
- Improved load balancing through ACK throttling
- Connection recovery mechanism for temporary network issues
- C++11 compatible compiler
- CMake for the build process
- spdlog library
- argparse library
SRTLA assumes that:
- Data is streamed from an SRT sender in caller mode to an SRT receiver in listener mode
- To benefit from link aggregation, the sender should have 2 or more network links to the SRT listener (typically internet-connected modems)
- The sender needs to have source routing configured, as SRTLA uses
bind()to map UDP sockets to specific connections
# Clone the repository
git clone https://github.com/OpenIRL/srtla.git
cd srtla
# Build with CMake
mkdir build
cd build
cmake ..
makesrtla_rec runs as a proxy between SRTla clients and an SRT server:
./srtla_rec [OPTIONS]--srtla_port PORT: Port to bind the SRTLA socket to (default: 5000)--srt_hostname HOST: Hostname of the downstream SRT server (default: 127.0.0.1)--srt_port PORT: Port of the downstream SRT server (default: 4001)--verbose: Enable verbose logging (default: disabled)--debug: Enable debug logging (default: disabled)
./srtla_rec --srtla_port 5000 --srt_hostname 192.168.1.10 --srt_port 4001 --verbose- srtla_rec creates a UDP socket for incoming SRTLA connections.
- Clients register with srtla_rec and create connection groups.
- Multiple connections can be added to a group.
- Data is received across all connections and forwarded to the SRT server.
- ACK packets are sent across all connections for timely delivery.
- Inactive connections and groups are automatically cleaned up.
SRTLA implements a protocol for packet transmission over multiple network connections, aggregating the data and making it available to the SRT protocol. The implementation is based on the following core mechanisms:
-
Connection Group Management: The software organizes connections into groups, with each group corresponding to an SRT stream. This enables support for multiple simultaneous SRTLA senders with a single receiver.
-
Packet Tracking: The code tracks received packets with sequence numbers and periodically sends SRTLA-ACK packets back to confirm receipt.
-
Two-phase Registration Process:
- Sender (conn 0):
SRTLA_REG1(contains sender-generated random ID) - Receiver:
SRTLA_REG2(contains full ID with receiver-generated values) - Sender (conn 0):
SRTLA_REG2(with full ID) - Receiver:
SRTLA_REG3 - Additional connections follow a similar pattern
- Sender (conn 0):
-
Error Handling: The receiver can send error responses:
SRTLA_REG_ERR: Operation temporarily failedSRTLA_REG_NGP: Invalid ID, group must be re-registered
-
Connection Cleanup: Inactive connections and groups are automatically cleaned up after a configurable timeout (default: 10 seconds).
-
Load Balancing through ACK Throttling: The server controls ACK frequency to influence the client's connection selection without requiring client-side modifications.
-
Connection Recovery Mechanism: Connections that show signs of recovery after temporary outages are given a chance to stabilize again.
The implementation uses epoll for event-based network I/O, allowing efficient handling of multiple simultaneous connections.
This version of SRTLA includes improvements to address two key issues in the original implementation:
In the original implementation, connections with temporary problems were completely disabled. In this enhanced version:
- Connections showing signs of recovery enter a "recovery mode"
- These connections receive more frequent keepalive packets for a set period (5 seconds)
- After successful recovery, they are fully reactivated for data transmission
- Recovery attempts are abandoned after a certain time if unsuccessful
This functionality allows connections to "heal" after brief disruptions (e.g., due to network issues) rather than remaining completely disabled.
In the original implementation, load was unevenly distributed across available connections. The new implementation:
- Introduces a monitoring and evaluation system for connection quality
- Checks connection quality every 5 seconds based on:
- Bandwidth (bytes/s)
- Round-Trip Time (ms)
- Packet loss rate
- Assigns error points to each connection based on these metrics
- Calculates a quality weight for each connection (10% to 100%)
- Controls ACK packet frequency based on connection quality
- Good connections receive ACKs more frequently
- Poor connections receive ACKs less frequently
- Indirectly influences the window size in the client and thus connection selection
The result is better data distribution, with more stable connections carrying more load than problematic ones, without requiring client modifications.
The central innovation of this solution is ACK throttling for load distribution. It's based on the following principles:
- The SRT/SRTLA client (srtla_send) selects connections based on a score derived from the window size and in-flight packets.
- The window size in the client is adjusted when ACKs are received.
- By selectively throttling ACK frequency, we can indirectly control how quickly the window grows in the client.
- This causes the client to prefer better connections without requiring changes to the client code.
Connection quality is assessed by measuring and analyzing:
- Bandwidth: Low bandwidth leads to more error points
- Packet Loss: Higher loss rates lead to more error points
The weight levels are:
- 100% (WEIGHT_FULL): Optimal connection
- 70% (WEIGHT_DEGRADED): Slightly impaired connection
- 40% (WEIGHT_POOR): Severely impaired connection
- 10% (WEIGHT_CRITICAL): Critically impaired connection
The recovery functionality works as follows:
- A connection that receives data again after being marked inactive is placed in recovery mode
- In this mode, keepalive packets are sent more frequently (every 1 second)
- If the connection remains stable for a short period (5 seconds), it is considered recovered
- If recovery does not occur within the time window, the recovery attempt is aborted
The following parameters can be adjusted to optimize behavior:
KEEPALIVE_PERIOD: Interval for keepalive packets during recovery (1 second)RECOVERY_CHANCE_PERIOD: Period during which a connection can attempt to recover (5 seconds)CONN_QUALITY_EVAL_PERIOD: Interval for evaluating connection quality (5 seconds)ACK_THROTTLE_INTERVAL: Base interval for ACK throttling (100ms)- Various weight levels (
WEIGHT_FULL,WEIGHT_DEGRADED,WEIGHT_POOR,WEIGHT_CRITICAL)
- The RTT calculation is simplified and could be improved in future versions
- The error point thresholds are static and could be dynamically adjusted to better adapt to different network situations
- The throttling might be less effective with very short ACK intervals
The sender should implement congestion control using adaptive bitrate based on the SRT SRTO_SNDDATA size or measured RTT.
srtla_rec creates information files about active connections under /tmp/srtla-group-[PORT]. These files contain the client IP addresses connected to a specific socket.
This project is licensed under the GNU Affero General Public License v3.0:
- Copyright (C) 2020-2021 BELABOX project
- Copyright (C) 2024 IRLToolkit Inc.
- Copyright (C) 2024 OpenIRL
- Copyright (C) 2025 IRLServer.com
You can use, modify, and distribute this code according to the terms of the AGPL-3.0.