SRT Protocol: Secure Reliable Transport for Live Video

What is SRT?

SRT (Secure Reliable Transport) is an open-source video transport protocol developed by Haivision and released to the open-source community in 2017 through the SRT Alliance. It was designed with a single purpose: move live video reliably over unpredictable networks. Unlike TCP-based protocols that stall when packets are lost, SRT uses UDP with a selective retransmission mechanism called ARQ (Automatic Repeat reQuest) that recovers only the missing packets, keeping latency low and streams clean.

SRT has rapidly become the standard for professional contribution feeds, remote production, and point-to-point video transport. It is supported by hundreds of products, from hardware encoders like Haivision Makito and Teradek to software platforms like OBS Studio, vMix, and Vajra Cast.

SRT Connection Modes

SRT defines three connection modes. Choosing the right mode determines how two endpoints establish their session.

Caller Mode

The caller initiates the connection to a remote listener. This is the most common mode for encoders sending video to a server.

srt://server.example.com:9000?mode=caller

Use caller mode when:

• Your encoder is behind NAT and cannot accept incoming connections
• You are pushing a stream to a centralized gateway or cloud server
• You want the source to control when the connection starts

In Vajra Cast, you configure a caller ingest when you need to pull a stream from a remote SRT source, or a caller output when you need to push a stream to a downstream SRT listener.

Listener Mode

The listener opens a UDP port and waits for incoming caller connections. This is the server-side mode.

srt://0.0.0.0:9000?mode=listener

Use listener mode when:

• You are running a centralized ingest server (like Vajra Cast) that accepts streams from remote encoders
• Your server has a public IP address or properly configured port forwarding
• You need to accept multiple incoming streams on different ports

Vajra Cast operates primarily in listener mode for ingest, opening a dedicated SRT port for each input. Each listener can be independently configured with its own latency, encryption, and stream ID settings.

Rendezvous Mode

Rendezvous mode allows two endpoints to connect without either side acting as a permanent server. Both sides attempt to connect to each other simultaneously, and the SRT handshake resolves which direction data flows.

srt://remote-peer:9000?mode=rendezvous

Rendezvous is useful when:

• Both endpoints are behind NAT and neither can accept incoming connections
• You need peer-to-peer connectivity without a relay server
• You are building a symmetric contribution workflow

In practice, rendezvous mode is less common in production environments because it requires precise timing coordination and both sides knowing each other’s IP addresses. Most professional workflows use the caller/listener model with a centralized gateway like Vajra Cast.

SRT Encryption

One of SRT’s most significant advantages over RTMP is built-in encryption. SRT uses AES (Advanced Encryption Standard) at the transport level, meaning every packet payload is encrypted before it leaves the sender.

How It Works

1. Both endpoints share a passphrase (10-79 characters)
2. During the handshake, the listener generates a random salt
3. Both sides derive the AES key from the passphrase and salt using PBKDF2
4. All video/audio payload data is encrypted with the derived key
5. SRT headers remain unencrypted (necessary for packet routing and retransmission)
6. Keys are periodically renegotiated for forward secrecy

Key Lengths

SRT supports three AES key lengths:

On any hardware with AES-NI (virtually all modern x86 processors), encryption has no measurable performance impact. Use AES-256 for everything unless you have a specific reason not to. For a complete walkthrough of encryption configuration, see our SRT Encryption Setup guide.

Passphrase Configuration

srt://server:9000?passphrase=MyS3cur3P@ssphr4se&pbkeylen=32

Both sides must use the exact same passphrase and key length. A mismatch causes a silent connection failure with no error message, which is a common source of confusion during initial setup.

Error Correction with ARQ

SRT’s error correction mechanism is what separates it from raw UDP streaming. When a receiver detects a missing packet (via sequence number gaps), it immediately sends a NAK (Negative Acknowledgment) to the sender requesting retransmission. The sender retransmits only the specific missing packets.

This process is governed by the latency parameter:

srt://server:9000?latency=500

The latency value (in milliseconds) defines the receive buffer. It is the time window SRT has to detect loss, request retransmission, and receive the recovered packet before the decoder needs it. The formula for choosing the right value:

Latency >= 4 x RTT + 2 x Jitter

Where RTT is the round-trip time between endpoints and Jitter is the variance in RTT. On a stable same-country connection with 30ms RTT, a latency of 200-500ms works well. For satellite or cellular links, you may need 1500-4000ms. See our detailed SRT Latency Tuning guide for recommended values across different network scenarios.

What Happens When Latency is Too Low

If the latency buffer is too small for the network conditions, SRT cannot recover packets in time. The result is unrecovered packet loss, which manifests as visual artifacts (macroblocking, glitches) or audio dropouts. Vajra Cast reports these as dropped packets in the real-time stream dashboard.

What Happens When Latency is Too High

Excess latency simply adds unnecessary delay to your stream. This matters in interactive scenarios (interviews, live Q&A) but is less critical for one-way broadcast. When in doubt, start high and reduce incrementally.

SRT Overhead Bandwidth

SRT reserves a percentage of bandwidth for retransmissions. The oheadbw parameter controls this:

srt://server:9000?oheadbw=25

The default is 25%, meaning if your stream is 10 Mbps, SRT will allow up to 12.5 Mbps total to accommodate retransmissions. On lossy networks (cellular, Wi-Fi), increase this to 50% or higher. On clean dedicated links, you can reduce it to 10-15%.

SRT Statistics and Monitoring

SRT exposes a rich set of real-time statistics through its API:

• RTT (Round Trip Time): current and smoothed values
• Packet loss rate: percentage of packets lost before recovery
• Retransmission rate: packets retransmitted per second
• Available bandwidth: estimated path capacity
• Buffer level: how much of the latency buffer is in use
• Encryption status: confirms AES is active

Vajra Cast surfaces all of these metrics per stream in the web dashboard and exposes them via the Prometheus /metrics endpoint for integration with Grafana or other monitoring tools. This observability is one of SRT’s strongest advantages over RTMP, which provides almost no transport-level diagnostics.

SRT in the Vajra Cast Architecture

Vajra Cast uses SRT as its primary transport protocol. The three-stage architecture (Ingest, Process, Redistribute) leverages SRT at both the input and output stages:

• Ingest: SRT listeners accept incoming streams from encoders, with per-input encryption and latency settings
• Redistribute: SRT caller outputs push streams to downstream servers, CDNs, or other Vajra Cast instances

Between stages, Vajra Cast uses zero-copy internal multicast, meaning adding additional SRT outputs costs zero CPU overhead. You can route one input to 50 SRT outputs with the same resource usage as one.

For workflows that involve legacy equipment, Vajra Cast bridges SRT with RTMP and HLS, allowing you to receive in one protocol and distribute in another without manual conversion.

Next Steps

• Return to the SRT Streaming Gateway Guide for the full architecture overview
• Learn about SRT Encryption Setup for detailed passphrase configuration
• Optimize your network with SRT Latency Tuning
• Read our blog post on SRT vs RTMP for a protocol comparison