SRT — Secure Reliable Transport

SRT (Secure Reliable Transport) is an open-source video transport protocol developed by Haivision and open-sourced in 2017 through the SRT Alliance (now maintained on GitHub as haivision/srt). It solves the core problem of reliable low-latency video contribution over public internet and cellular networks: RTMP (TCP-based) stalls on packet loss; unprotected UDP drops frames with no recovery. SRT uses UDP with an ARQ (Automatic Repeat reQuEST) retransmission layer that recovers lost packets within a configurable latency budget. The result is resilient, encrypted, low-latency video transport that works across NAT, firewalls, and lossy WAN links. SRT is now supported by virtually every professional encoder, decoder, and streaming platform and has replaced RTMP as the preferred contribution protocol for professional AV installations.

Core Architecture

UDP with ARQ Retransmission

SRT transmits data packets over UDP. The receiver acknowledges received packets (ACK) and requests retransmission of missing packets (NAK — Negative Acknowledgment). The transmitter maintains a retransmission buffer and resends lost packets on request. The critical constraint: retransmitted packets must arrive before the receiver's playout point — defined by the latency buffer.

Sender                              Receiver
  |------ Data packets -------->     |
  |<------- ACK (received) ------    |
  |<------- NAK (missing seq#) --    |
  |------ Retransmit lost pkt -->    |
  |                                  |  ← latency buffer (e.g. 500ms)
  |                                  |  ← playout point

If a packet is lost and the retransmission arrives within the latency buffer window, the receiver reassembles the stream seamlessly. If the retransmission arrives too late (after playout point), it is discarded and the packet is lost — resulting in a video artifact or freeze.

The fundamental SRT design rule: latency must be set to at least 3–4× the round-trip time (RTT) between sender and receiver. A 200 ms RTT path needs at minimum 600–800 ms of SRT latency for retransmission to function reliably.

Encryption

SRT has built-in AES encryption — no additional TLS layer is required. Encryption is negotiated at connection time using a passphrase (minimum 10 characters, maximum 79):

• AES-128: Lower CPU overhead; adequate for most contribution links
• AES-256: Higher security; use for sensitive or classified content
• Key exchange: Uses PBKDF2 key derivation from the passphrase — both endpoints must use the same passphrase
• Unencrypted fallback: If one side has no passphrase, the connection fails (by default). Configure enforcedEncryption=false to allow fallback to unencrypted — not recommended for public internet.

Encryption is transparent to the video codec — any video format (H.264, H.265, JPEG XS, uncompressed) travels inside encrypted SRT packets.

Flow Control and Bandwidth Management

SRT includes congestion control (based on UDT — UDP-based Data Transfer protocol). Key parameters:

• maxbw: Maximum bandwidth in bytes/second. Set to ~125% of expected stream bitrate to allow retransmission overhead without saturating the link.
• inputbw: Input stream bitrate estimate; used to calculate maxbw automatically.
• oheadbw: Overhead percentage for retransmissions (default 25%). Total bandwidth = stream bitrate × (1 + oheadbw/100).

Connection Modes

SRT has three connection modes that determine which side initiates the connection. Choosing correctly is essential for firewall traversal.

Caller Mode

The SRT endpoint initiates an outbound connection to a known IP:port. The destination must be in Listener mode and reachable (no blocking NAT/firewall on the destination side).

Encoder (Caller) ──── UDP:9000 ────> Decoder/Server (Listener)

Use case: Encoder behind a permissive firewall or cellular modem pushing to a cloud ingest server with a public IP and open port. The server's port must be open inbound.

Listener Mode

The SRT endpoint waits for incoming connections on a bound port. The remote side (Caller) initiates the connection. The Listener must have an accessible public IP or be reachable via port forwarding.

Encoder (Caller) ──── UDP:9000 ────> Media Server (Listener, public IP)

Use case: Cloud media server (Wowza, Haivision SRT Gateway, FFmpeg) listening for encoder pushes. The server opens port 9000 (or configured port) inbound; the encoder calls out.

Rendezvous Mode

Both endpoints simultaneously initiate connections to each other on the same port. This allows two endpoints both behind NAT to connect without either needing a public IP — a form of UDP hole-punching.

Encoder (Rendezvous) ←── UDP:9000 ──→ Decoder (Rendezvous)

Both sides must know each other's IP and use the same port. Both must send packets within milliseconds of each other for the NAT hole-punch to succeed.

Use case: Two venues connecting directly without a central server, both behind NAT firewalls. Requires coordination timing and may fail with symmetric NAT.

SRT Statistics and Monitoring

SRT exposes real-time statistics essential for diagnosing contribution link health:

Access statistics via: SRT library API (C/C++, Python bindings), FFmpeg -stats, Haivision hardware web UI, vMix/OBS plugin statistics pane.

SRT in Practice — Configuration Examples

FFmpeg SRT Caller (encoder pushing to server)

ffmpeg -i input.mp4 \
  -c:v libx264 -b:v 4M -preset veryfast \
  -c:a aac -b:a 128k \
  -f mpegts "srt://192.168.1.50:9000?mode=caller&latency=500000&passphrase=MySecret123"

Latency is specified in microseconds in FFmpeg SRT URLs (500000 µs = 500 ms).

FFmpeg SRT Listener (server receiving from encoder)

ffmpeg -i "srt://0.0.0.0:9000?mode=listener&latency=500000" \
  -c copy output.ts

OBS Studio

Settings → Stream → Service: Custom, Server: srt://[ip]:[port]?latency=500000, Stream Key: leave blank. OBS 27+ supports SRT natively.

Hardware encoders (Haivision Makito X, Teradek Cube, Magewell Ultra Encode)

Set output protocol to SRT, enter destination IP:port, set latency (milliseconds in hardware UIs), enter passphrase. Hardware encoders display real-time SRT statistics in their web UIs.

Platform Support

SRT vs. RIST

RIST (Reliable Internet Stream Transport) is a competing open standard from the Video Services Forum (VSF) that solves similar problems to SRT. Key differences:

For AV integration, SRT is the current default choice. RIST may be specified for broadcast infrastructure projects requiring multi-vendor interoperability guarantees.

Common Pitfalls

• Setting SRT latency lower than 3× the network RTT. SRT latency is a buffer that allows time for ARQ retransmission. If latency is 120 ms but the round-trip time between encoder and decoder is 80 ms, a lost packet has only 40 ms to be detected, requested, and retransmitted — not enough time on any real network. The result: frequent dropped packets and video artifacts despite SRT's retransmission mechanism. Fix: always measure RTT first (ping, or read from SRT statistics), then set latency to at minimum 3–4× RTT; for internet contribution, 500 ms is a safe default.

• Firewall blocking inbound UDP on the SRT port. SRT uses UDP (default port 9000), which many firewalls block inbound by default. Unlike TCP, there is no SYN/ACK for the firewall to track — the firewall must explicitly permit inbound UDP on the configured port. Fix: open inbound UDP on the SRT port (e.g., 9000) on the receiving side's firewall; or use Rendezvous mode if both sides are behind NAT; or use a cloud relay server with a public IP in Listener mode.

• Passphrase mismatch causing silent connection failure. SRT with mismatched passphrases does not produce a helpful error — the connection simply fails to establish or drops immediately. Fix: verify the passphrase is identical on both sender and receiver, including case sensitivity and any trailing spaces; test with encryption disabled (passphrase="") first to confirm network connectivity before adding encryption.

• Using SRT over a TCP VPN (e.g., OpenVPN TCP mode). SRT's ARQ retransmission is designed for UDP. Running SRT inside a TCP VPN tunnel causes double retransmission: SRT retransmits lost packets within the VPN, and the TCP VPN also retransmits them independently. This "TCP over TCP" behavior causes congestion collapse and poor performance under loss. Fix: use UDP-mode VPN (WireGuard, OpenVPN UDP mode) when tunneling SRT; or route SRT directly without a VPN, using SRT's own AES encryption for security.

• Ignoring maxbw setting, causing link saturation. By default, SRT sets maxbw=-1 (unlimited) or uses the input bitrate with 25% overhead. On a 10 Mbps uplink, a 8 Mbps stream with unlimited retransmission overhead can spike to 12–15 Mbps during high-loss periods, saturating the uplink and causing cascading packet loss. Fix: set maxbw to 90% of the available uplink bandwidth; size the stream bitrate to leave adequate headroom for retransmission.