SRT Redundancy: Building Fault-Tolerant SRT Workflows

SRT and Reliability

SRT was designed for unreliable networks. Its ARQ (Automatic Repeat reQuest) mechanism retransmits lost packets, its configurable latency buffer absorbs jitter, and its encryption protects against tampering. But SRT’s packet-level reliability does not protect against higher-level failures: encoder crashes, network path outages, ISP failures, or hardware faults.

For that, you need redundancy at the workflow level: multiple SRT streams traveling different paths, with automatic switching when one fails. This page covers SRT-specific redundancy patterns that work with Vajracast’s failover engine.

Dual-Path SRT

The most straightforward SRT redundancy pattern is sending the same stream over two independent network paths:

                    Path A (ISP 1)
Encoder -> SRT --------------------------> Vajracast (Input 1, Priority 1)
        -> SRT --------------------------> Vajracast (Input 2, Priority 2)
                    Path B (ISP 2)

Both SRT streams carry identical content. Vajracast receives both simultaneously and selects the highest-priority healthy input for output. If Path A fails, the system switches to Path B.

What Makes Paths Independent?

For true redundancy, the two paths must not share failure points:

• Different ISPs. Two connections from the same ISP share the same backbone and peering agreements. Use two different providers.
• Different physical routes. Two fiber connections entering the building through the same conduit are not independent. Ask your ISPs about physical diversity.
• Different intermediate hops. If both paths traverse the same data center or exchange point, a single failure there takes both down.

In practice, perfect path independence is difficult and expensive. The goal is to minimize shared infrastructure, not eliminate it entirely. Even imperfect diversity dramatically improves reliability.

Encoder Configuration

The encoder needs to produce two SRT output streams. Most professional encoders support multiple simultaneous outputs. If yours does not, use two encoders fed from the same video source (via an SDI splitter or HDMI splitter):

Single encoder, two outputs:

Camera -> Encoder -> SRT Output 1 (port 9000, ISP A)
                  -> SRT Output 2 (port 9001, ISP B)

Two encoders (maximum redundancy):

Camera -> SDI Splitter -> Encoder A -> SRT (ISP A) -> Vajracast Input 1
                        -> Encoder B -> SRT (ISP B) -> Vajracast Input 2

The two-encoder approach protects against encoder hardware failure, not just network failure. It is the recommended setup for mission-critical broadcasts.

Listener/Caller Failover

SRT has two connection modes: listener (waits for incoming connections) and caller (initiates the connection). The choice of mode affects your failover architecture.

Vajracast as Listener (Encoder Pushes)

The most common pattern. Vajracast listens on SRT ports, and the encoder calls in:

Encoder A -> SRT Caller -> Vajracast SRT Listener (port 9000)
Encoder B -> SRT Caller -> Vajracast SRT Listener (port 9001)

Advantages:

• Vajracast only needs a stable IP and open UDP ports.
• Encoders can be behind NAT (callers initiate outbound connections).
• Adding or removing encoders does not require Vajracast reconfiguration.

Failover behavior: If Encoder A crashes, its SRT connection drops. Vajracast detects the disconnection (within milliseconds for SRT) and switches to Encoder B on the next input in the priority chain.

Vajracast as Caller (Encoder Listens)

In some deployments, it is easier to have the gateway pull from the encoder:

Encoder A (SRT Listener on port 9000) <- SRT Caller <- Vajracast
Encoder B (SRT Listener on port 9001) <- SRT Caller <- Vajracast

Advantages:

• Vajracast can be behind a firewall without exposed UDP ports.
• Useful when the encoder has a public IP but Vajracast does not.

Failover behavior: If the connection to Encoder A fails, Vajracast’s caller automatically retries. If retries are exhausted or the connection timeout expires, the failover engine switches to Encoder B. SRT caller reconnection is automatic. If Encoder A comes back, Vajracast reconnects and (with auto-recovery enabled) switches back to it.

Mixed Mode

You can combine listener and caller modes in the same priority chain. For example:

This flexibility lets you adapt to the network topology of each source without compromising failover coverage.

SRT Stream ID for Multi-Tenant Ingest

When running a single SRT listener port for multiple streams, SRT’s Stream ID feature allows multiplexing:

srt://vajracast:9000?streamid=primary-feed
srt://vajracast:9000?streamid=backup-feed

Vajracast uses the Stream ID to route each incoming connection to the correct input of the correct route. This reduces the number of ports you need to open and simplifies firewall rules.

For redundancy, combine Stream IDs with the priority chain:

Priority 1: SRT Listener, port 9000, streamid=main
Priority 2: SRT Listener, port 9000, streamid=backup

Both encoders connect to the same port but identify themselves with different Stream IDs. Vajracast maps each to the correct priority slot.

SRTLA Bonding as Backup

SRTLA (SRT Link Aggregation) bonding aggregates multiple network connections into a single SRT stream. It is primarily used for mobile production where cellular connections are unreliable. But SRTLA also serves as an excellent backup path in fixed installations.

Pattern: SRT primary, SRTLA backup:

If the primary fiber connection fails, Vajracast fails over to the SRTLA bonded feed. The SRTLA connection aggregates multiple cellular modems, so it has its own layer of redundancy. If one modem loses signal, the others continue.

This pattern is particularly effective for remote broadcasts where the venue has a wired connection that is expected to work but cannot be fully trusted (shared hotel internet, temporary event networking, etc.).

SRTLA Configuration

Vajracast accepts SRTLA connections on a dedicated port. The SRTLA receiver disaggregates the bonded packets back into a standard SRT stream before passing it to the routing engine:

BELABOX (cellular) -> SRTLA -> Vajracast SRTLA Receiver -> SRT Input (Priority 2)

The SRTLA receiver runs alongside the SRT listener on the same Vajracast instance. No additional software is needed.

Monitoring Redundant SRT Paths

With multiple SRT paths active, monitoring becomes essential. You need to know the health of every path, not just the one currently active.

Vajracast provides per-input metrics for all inputs in a priority chain, including inactive ones:

• Connection state: is the backup connected and ready?
• Bitrate: is the backup receiving data at the expected rate?
• Packet loss: is the backup path degrading?
• RTT: is the network path to the backup stable?

Set up Grafana dashboards that show all paths side by side. Set up alerts for backup path degradation. You want to know if your safety net has a hole before you need it.

Pre-Flight Checks

Before every live event, verify all redundant paths:

1. Confirm all SRT connections are established (check Vajracast dashboard).
2. Verify bitrate on each path matches expectations.
3. Force a failover switch to each backup and verify clean output.
4. Switch back to primary and confirm stable operation.

This takes 2-3 minutes and can prevent hours of problems during the broadcast.

Next Steps

• Return to the Video Stream Failover Guide for the complete failover architecture
• Learn about Multi-Input Failover for general failover configuration
• Explore SRTLA Bonding for a deep dive into connection aggregation