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 and holds stable for the configured failback stability window (default 3s), the failback engine switches back to it.

Mixed Mode

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

PriorityModeDescription
1ListenerPrimary encoder pushes to Vajracast
2CallerVajracast pulls from backup encoder
3ListenerRTMP backup (different protocol)

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.

Pairing SRTLA with Failover (They Are Not the Same Thing)

SRTLA (SRT Link Aggregation) bonds multiple network connections into a single SRT stream. It exists to keep one stream alive when individual network links degrade — typically several cellular modems, sometimes cellular plus wired. When a bonded link drops, the others compensate. The stream itself never fails over anywhere: it is still one stream, still one input, still one slot in a priority chain.

That distinction matters because SRTLA and failover address different failure modes and should not be thought of as alternatives:

  • SRTLA = link redundancy inside one source. Handles modem drops, single-ISP congestion, signal holes in a moving vehicle.
  • Failover = source redundancy between independent sources. Handles encoder crashes, site power loss, a bonded cellular link dying entirely, etc.

You combine them when you want both. In fixed installations where the primary path is a fiber SRT input and the backup path must traverse an unreliable medium (cellular, hotel Wi-Fi), using an SRTLA-bonded cellular link as the backup source gives you link redundancy on the backup path and source redundancy between paths:

PrioritySourceNotes
1Fiber SRT from venuePrimary — reliable wired path
2Cellular encoder bonded over SRTLABackup — SRTLA handles modem-level failure, failover handles link-level failure

From Vajracast’s routing engine, both entries are just SRT inputs. The SRTLA receiver deaggregates bonded packets into a standard SRT stream before the routing engine sees it, so the failover mechanism behaves identically on both slots.

Configuration

Vajracast accepts SRTLA connections on a dedicated port. The SRTLA receiver disaggregates the bonded packets back into a standard SRT stream:

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. For full SRTLA setup and BELABOX integration, see the SRTLA Bonding guide.

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

Distribute live broadcast from the cloud

Managed cloud platform with dedicated servers, N+1 failover, hardware transcoding, and global delivery. Free for 30 days.

Start free trial See pricing

30 days free · No credit card · Direct access to the dev team