What is an SRT Streaming Gateway?

An SRT streaming gateway is the central routing hub of a professional live streaming infrastructure. It sits between your video sources (cameras, encoders, remote feeds) and your destinations (CDNs, social platforms, recording servers), handling:

  • Protocol conversion: receive SRT, output WHEP, HLS, RIST, RTMP, RTSP, SRTLA, HTTP/TS, UDP, NDI, or ST 2110
  • Stream routing: send one input to multiple outputs
  • Failover protection: automatically switch to backup inputs on failure
  • Encryption: secure your streams with AES-256
  • Monitoring: real-time metrics for every stream

Think of it as a software video router: contribution comes in once, then the same live feed can be protected, processed, monitored, and delivered wherever it is needed.

Why SRT?

SRT (Secure Reliable Transport) was designed by Haivision specifically for live video transport over unpredictable networks. Unlike RTMP (which relies on TCP and falls apart on lossy connections), SRT uses UDP with selective retransmission (ARQ) to maintain stream quality even when the network isn’t perfect. For a detailed comparison of both protocols, see our SRT vs RTMP streaming guide.

Key advantages:

  • Packet loss resilience: handles up to 30% packet loss with sufficient latency buffer
  • Built-in encryption: AES-128 or AES-256, not bolted on as an afterthought
  • Configurable latency: from 20ms on LAN to several seconds for satellite links
  • Real-time metrics: RTT, jitter, loss rate, bandwidth, all available via API
  • Open source: no licensing fees, growing ecosystem

Core Architecture

A production SRT gateway typically has three stages:

1. Ingest

The gateway accepts incoming streams from various sources:

  • SRT listeners waiting for incoming connections
  • SRT callers connecting to remote sources
  • WHIP WebRTC sources for low-latency contribution
  • RIST Main Profile inputs with standard ARQ retransmission
  • Bonded SRTLA contribution from BELABOX, Moblin, and compatible senders
  • RTMP receivers for legacy encoder compatibility
  • RTSP, HLS, HTTP/TS, and UDP sources
  • All-in-one linear channel playout with graphics and timed SCTE-35 cues

Each ingest has independent connection parameters. SRT inputs additionally expose their own encryption and latency settings.

2. Processing

Once ingested, the gateway can process streams:

  • Transcoding: change resolution, bitrate, codec, or interlace handling with NVIDIA NVENC, Intel QSV, or VAAPI acceleration
  • Audio routing: preserve multiple audio PIDs, split 7.1 into stereo pairs, remap channels, and control gain
  • Failover logic: monitor one primary input and up to 7 backups and switch in under 50ms
  • Route chaining: prepare or transcode a feed once, then reuse it across downstream routes
  • Broadcast continuity: generate customizable color bars with 1 kHz tone, text, logo, and clock/timecode when a live source is unavailable
  • Metadata and recording: carry SCTE-35 signaling through the workflow and record a live route directly to file

3. Distribution

The gateway outputs processed streams to multiple destinations simultaneously:

  • SRT push to production servers, broadcast decoders with SDI/HDMI output, and master control room (MCR) systems
  • WHEP WebRTC output for low-latency browser playback
  • RIST Main Profile output to broadcast gateways and receivers
  • RTMP push to YouTube, Twitch, Facebook
  • RTSP, SRTLA, HTTP/TS, and UDP delivery
  • HLS adaptive output with viewer count, SCTE-35 manifest signaling, and a built-in player
  • NDI and ST 2110 output for on-premise production environments
  • Recording to local or network storage

This three-stage architecture means you can receive in one protocol, process, and distribute in another, all in a single, manageable system.

What Vajracast Adds to an SRT Gateway

Transport is only the first layer. Vajracast adds the control-room tools needed to keep a live service usable when sources, destinations, or production requirements change.

WebRTC Contribution with WHIP, Playback with WHEP

Vajracast accepts WHIP WebRTC input for low-latency contribution as well as SRT, RIST, RTMP, and other ingest protocols. Any routed feed can then be exposed as a WHEP WebRTC output for low-latency viewing. The integrated media player gives operators and authorized viewers a direct way to check the live feed in a compatible browser. For wider adaptive delivery, HLS outputs include a built-in player, live viewer count, and latency indicator.

Ingest MPEG-TS over UDP or SRT with up to four stereo audio tracks. Automatically generate adaptive HLS in four video resolutions using hardware-accelerated transcoding, preserving each audio track as a selectable language option. SCTE-35 cues from the incoming feed are converted into ad-break markers and inserted into the HLS playlists in real time.

Customizable Color Bars and Tone

Each route can use an integrated Bars & Tone source instead of relying on a separate test-signal generator. Operators can prepare a branded holding signal with customizable color bars, a 1 kHz reference tone, overlaid text, logo, and clock/timecode. It can be selected manually or placed at the end of a failover chain so an outage produces a controlled signal rather than black and silence.

Live Operations Without Route Restarts

Add a backup input, attach a new destination, or change an output while the route is on air. Other inputs and outputs continue running. Chained routes let one prepared feed supply several downstream workflows, while email alerts report source loss, failover, and recovery after a configurable grace period.

Browser Multiviewer and Embedded Previews

Monitor several live routes from a customizable browser-based video wall. Embedded previews, route status, and live metrics are available directly in the web interface, giving operators a practical multiviewer without requiring an external broadcast decoder or a separate monitoring application.

Recording and File-Based Playout

Record a live route directly to a media file for archive, compliance, review, or later reuse. The media file player can also use recorded or uploaded content as a route source for pre-recorded programs, holding content, backup programming, and channel continuity.

Build linear channels from media files and scheduled playlists. Play multitrack content with up to four stereo audio tracks. Schedule programming from Excel, add graphics, logos, and overlays in real time, and generate SCTE-35 cues for scheduled ad breaks.

Broadcast Processing and Visibility

Vajracast combines hardware transcoding, interlace handling, a multi-PID audio matrix, SCTE-35 carriage, and all-in-one channel playout with graphics. The web interface provides a live route diagram, per-node statistics, integrated media players, and VMAF/PSNR quality analysis; Prometheus metrics and pre-built Grafana dashboards cover infrastructure monitoring.

Setting Up Your First SRT Gateway

Hardware Requirements

SRT is lightweight. A modern gateway can handle dozens of HD streams on modest hardware:

WorkloadCPURAMNetwork
1-5 streams (passthrough)2 cores4 GB100 Mbps
5-20 streams (passthrough)4 cores8 GB1 Gbps
Hardware transcodingQSV or NVENC GPU16 GB1 Gbps
Enterprise (50+ streams)8+ cores32 GB10 Gbps

Network Configuration

SRT uses UDP. You’ll need:

  1. Public IP or port forwarding for listener mode
  2. Firewall rules allowing UDP on your chosen ports (convention: 9000+)
  3. Sufficient bandwidth: plan for 1.5x your aggregate bitrate to allow for SRT retransmissions

Software Setup with Vajracast

For a concrete reference of how a Vajracast SRT gateway slots into a redundant cross-border live production, see the example deployment — annotated diagrams covering both full-redundancy multi-region and single-ingest passthrough variants.

There are two ways to run a Vajracast SRT gateway:

Option 1 — Cloud (recommended for most teams)

Skip the infrastructure entirely. Vajracast runs on dedicated physical servers across New York, London, Frankfurt, Paris, Virginia, Los Angeles, Singapore, and Helsinki. Cloud Indie, Solo, and Pro plans share infrastructure; Dedicated runs on a bare-metal server provisioned for you. You get admin access to the web interface and your own subdomain (yourname.vajracast.com). We handle the OS, updates, network, monitoring, and incidents.

  1. Start a free trial — provisioned in minutes
  2. Log in to your Vajracast instance
  3. Create an ingest: choose SRT Listener/Caller, WHIP, RIST, RTMP, RTSP, SRTLA, HLS, HTTP/TS, UDP, or a media/playout source, then configure its protocol-specific settings
  4. Create an output: choose SRT, WHEP, HLS, RIST, RTMP, RTSP, SRTLA, HTTP/TS, UDP, recording, or an on-premise output
  5. Open the integrated player or route diagram to verify the signal, then add destinations or backup sources as needed

Setup time: under 5 minutes, no server to configure.

Option 2 — Self-Hosted (on request)

If you already operate Linux infrastructure and need to run Vajracast on your own hardware for sovereignty or compliance reasons, on-premise licensing is available on a contract basis. You remain responsible for the OS, network, bandwidth, monitoring, and updates. Contact us to discuss self-hosted licensing.

For a complete walkthrough including encoder configuration and OBS integration, see our SRT streaming setup guide and OBS SRT streaming guide.

SRT Encryption Deep Dive

Every SRT stream over the internet should be encrypted. SRT supports three key lengths:

  • AES-128: fast, sufficient for most use cases
  • AES-192: middle ground (rarely used)
  • AES-256: maximum security for sensitive content

Configuration is simple: both sides share a passphrase (10-79 characters). SRT derives the encryption key from this passphrase using PBKDF2.

Best practices:

  • Use AES-256 for any stream leaving your network
  • Use unique passphrases per stream
  • Rotate passphrases regularly
  • Never transmit passphrases over unencrypted channels

For implementation details including key rotation strategies and compliance considerations, see our SRT encryption and AES-256 deep dive.

Failover and Redundancy

A gateway without failover is a single point of failure. Professional deployments need:

Input Failover

Configure one primary input and up to 7 backups per route with automatic switching. For example:

  • Primary: SRT from main encoder
  • Backup 1: SRT from redundant encoder
  • Backup 2: RTMP from cloud encoder

The gateway monitors all inputs simultaneously and switches in under 50ms when the active SRT input fails. Best Score selects the healthiest available input; Round-robin moves down the configured priority list to the next available backup. Optional auto-failback switches back to the designated primary input once it has recovered and remained stable.

Output Redundancy

Send the same stream to multiple destinations:

  • Primary CDN ingest
  • Backup CDN ingest
  • Local recording (as ultimate backup)

For mobile production scenarios where reliable connectivity is a challenge, SRTLA bonding combines multiple network connections (cellular, Wi-Fi, Ethernet) into a single resilient SRT stream, providing both higher bandwidth and automatic path redundancy.

Geographic Redundancy

For mission-critical broadcasts, run gateways in multiple locations:

  • Primary gateway at venue
  • Secondary gateway in cloud
  • Both feeding the same CDN with origin failover

Monitoring and Observability

A gateway you can’t monitor is a gateway you can’t trust. Essential metrics:

  • Per-stream bitrate: is the source encoding at the expected rate?
  • Packet loss: is the network degrading?
  • RTT: is latency increasing?
  • Retransmission rate: how much bandwidth is spent on recovery?
  • Connection state: is every input and output connected?

Vajracast exposes all of these in real-time via the web dashboard and a REST API for integration with your monitoring stack.

The dashboard also provides a live topology diagram, preview players, and per-route email alerts for source loss, failover, and recovery. A configurable grace window prevents short network blips from generating unnecessary notifications. Prometheus metrics, pre-built Grafana dashboards, and VMAF/PSNR history support longer-term operational and quality analysis.

Next Steps

Ready to build your SRT streaming infrastructure? Start with these guides:

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

Frequently Asked Questions

What is an SRT streaming gateway?

An SRT streaming gateway is software that receives, processes, and redistributes live video streams using the SRT (Secure Reliable Transport) protocol. It acts as a central hub for video routing, protocol conversion, and stream protection.

Why use SRT instead of RTMP?

SRT provides built-in AES encryption, handles packet loss gracefully with ARQ error recovery, works over unreliable networks (cellular, satellite, public internet), and provides real-time transport metrics. RTMP lacks native encryption and struggles on lossy networks.

What is the minimum latency achievable with SRT?

SRT latency is configurable. On a LAN with <1ms RTT, you can achieve 20-60ms latency. Over the public internet, typical latencies range from 200ms to 2 seconds depending on network conditions and distance.

Can SRT work behind a firewall?

Yes, but SRT uses UDP, so you need to open specific UDP ports on your firewall. In caller mode, SRT initiates the connection outbound, which works with most NAT configurations.

What is SRTLA bonding?

SRTLA (SRT Link Aggregation) is an extension that bonds multiple network connections (e.g., cellular + Wi-Fi) into a single SRT stream. This provides higher bandwidth and redundancy for mobile production scenarios.

Can an SRT gateway deliver video to a web browser?

Yes. Vajracast accepts low-latency WebRTC contribution through WHIP and delivers live video through WHEP for low-latency playback or HLS for adaptive delivery. Built-in players let operators preview and share the output without a separate playback service.