How SRT works: ARQ, latency buffer, encryption, and handshake

SRT builds reliability on top of UDP by adding feedback (ACK/NAK), packet numbering, retransmission rules, and timing controls. The result is a link that can survive jitter and packet loss while staying far more real-time than TCP under typical streaming conditions.

ARQ (Automatic Repeat reQuest) in plain language

In SRT, the receiver detects missing packet sequence numbers and requests only the missing ones (selective retransmission). That’s different from TCP’s “in-order delivery” behavior, which can cause head-of-line blocking and latency spikes when packets are lost.

Sender (UDP + SRT)                    Receiver
  P100  ---------------------------->  OK
  P101  ----X (lost) 
  P102  ---------------------------->  sees gap: missing P101
                  <------------------  NAK: resend P101
  P101  ---------------------------->  insert P101 into buffer, output in order

The catch: retransmission needs time. That time is provided by the latency buffer.

Latency buffer: the knob that trades delay for resilience

SRT typically uses a sender buffer and receiver buffer measured in milliseconds. The receiver holds packets briefly before releasing them, giving retransmissions a window to arrive. If your buffer is too small for your network’s worst-case jitter + RTT, you’ll see drops. If it’s too large, you add unnecessary delay.

• More latency → more time to recover losses → fewer artifacts.
• Less latency → faster glass-to-glass, but more vulnerable to loss/jitter.
• Rule of thumb: buffer should be comfortably larger than typical jitter and allow at least one retransmission round-trip.

Encryption: built-in security without a VPN

SRT supports AES encryption using a shared passphrase (often called “pbkeylen” for key length). This is ideal when you’re sending a private contribution feed from a school event, a church service, or a paid concert where you don’t want the raw ingest visible on the network.

# Example SRT URL parameters (common style)
srt://receiver.example.com:9000?mode=caller&latency=200&pbkeylen=16&passphrase=StrongPassHere

Important: encryption protects the SRT transport link, but your overall system still needs good operational security (rotate keys, restrict firewall rules, and separate ingest from public listener endpoints).

Handshake and control traffic

SRT performs a handshake to agree on parameters (latency, packet size, encryption options), then uses control packets for ACK/NAK and statistics. This telemetry is one reason SRT is practical for real-world ops—you can measure loss, RTT, and retransmission rates and tune accordingly.

High-level flow:
1) Caller -> Listener: handshake (capabilities, mode, optional crypto)
2) Listener -> Caller: handshake response (agreed params)
3) Data: UDP packets with sequence numbers
4) Receiver -> Sender: ACKs + NAKs (selective retransmit requests)
5) Optional keepalives / stats

Tuning SRT for real-world links: latency, bandwidth overhead, and packet loss

SRT is powerful, but it’s not magic. Your results depend on how you tune latency, how close your encode bitrate is to available bandwidth, and how you handle packet loss bursts. This section gives you practical knobs to turn and what each one costs.

Start with the network budget (bitrate + headroom)

If your uplink is 5 Mbps and you’re trying to push 4.8 Mbps video plus audio, SRT will struggle during congestion because retransmissions add overhead. Leave headroom.

• Safe rule: keep encoded bitrate at ~60–75% of consistent uplink capacity.
• Bursty networks (LTE/5G, shared Wi‑Fi): consider 50–60% for stability.
• Remember: retransmissions + control traffic increase bandwidth use under loss.

Set latency based on RTT and jitter, not vibes

Your SRT latency should cover: jitter + at least one retransmission cycle. If your RTT is 80 ms and jitter peaks at 60 ms, a 200–300 ms latency is often workable. If RTT is 200 ms (international) with jitter spikes, you may need 500–1200 ms or more.

# Example: modest buffer for domestic public internet
srt://ingest.example.com:9000?mode=caller&latency=250

# Example: more buffer for cellular or long-haul
srt://ingest.example.com:9000?mode=caller&latency=800

Understand packet loss types: random vs burst

Random loss (1–2%) is usually recoverable with moderate latency. Burst loss (a 500 ms Wi‑Fi dropout) is harder: no retransmission can recover packets that never had time to be resent within your latency window.

• Random loss: increase latency slightly; keep bitrate conservative.
• Burst loss: stabilize Wi‑Fi, use wired, or increase latency significantly.
• Repeated bursts: consider a backup path (bonded cellular, second ISP, or automatic failover feed).

Encryption and CPU: don’t ignore device limits

AES encryption is excellent for protecting contribution feeds, but older laptops, mini PCs, or mobile devices can become CPU-bound if you’re encoding and encrypting simultaneously. If your encoder shows dropped frames under load, reduce resolution/framerate, use hardware encoding, or test a lower key size where appropriate (while still meeting your security requirements).

Monitoring signals that tell you what to fix

Most SRT tools expose stats like RTT, packet loss, retransmitted packets, and buffer occupancy. Use those metrics during rehearsal, not during the live show.

• RTT increasing: congestion; reduce bitrate or change network.
• Retransmits spiking: rising loss; increase latency or fix link quality.
• Buffer constantly near empty: latency too low for network conditions.

Broadcast workflows: remote guests, church services, studio-to-cloud, failover

Below are common, battle-tested SRT deployment patterns for radio DJs, music streamers, podcasters, churches, schools, and live event teams. Use these as blueprints and adapt them to your gear.

1) Remote DJ or podcast host → studio/cloud ingest (simple Caller → Listener)

A remote DJ laptop or hardware encoder sends SRT to a cloud VM (Listener). The cloud ingest decodes or forwards the program to your radio streaming encoder, then you publish to Shoutcast/Icecast for listeners.

Remote DJ (Caller, SRT)  --internet-->  Cloud Ingest (Listener)
                                              |
                                              v
                                         Encoder / Transcoder
                                              |
                                              v
                                      Shoutcast/Icecast Delivery
                                   (SSL, unlimited listeners, 99.9%)

This pattern is ideal when you want reliability for the contributor but maximum compatibility for listeners. If the DJ’s connection gets rough, increase SRT latency and/or reduce contribution bitrate without changing your listener endpoints.

2) Church service contribution with secure encryption

For churches, schools, and ticketed events, SRT encryption protects the raw program feed as it travels from sanctuary to cloud. You can then distribute publicly from the cloud while keeping the ingest private.

# Typical encrypted SRT caller URL (example)
srt://ingest.yourdomain.com:9000?mode=caller&latency=600&pbkeylen=16&passphrase=UseARealPassphrase

Combine that with SSL listener delivery and predictable flat pricing. Shoutcast Net’s plans keep your ongoing costs stable, unlike platforms with per-viewer or per-hour fees.

3) Studio-to-cloud primary + backup (failover workflow)

Run two independent paths: a primary wired ISP and a backup (secondary ISP or bonded cellular). Each sends an SRT feed to the cloud. On the cloud side, switch between them (manual or automated) based on health metrics.

Studio Encoder A (Primary ISP) --SRT--> Cloud Receiver A
Studio Encoder B (Backup LTE)  --SRT--> Cloud Receiver B
                                     \ 
                                      \-- Switch/Failover --> Publish

This is especially valuable for schools and churches where a single consumer router reboot can ruin a live broadcast. With failover, the show continues.

4) Remote guests + live production + platform restream

A producer collects remote guests via SRT (for robustness) or WebRTC (for interactivity), mixes the show, then pushes outputs to platforms. Many creators need to Restream to Facebook, Twitch, YouTube while also maintaining an audio-only station feed for radio listeners.

Guest 1 --SRT--> Producer/Mixer --RTMP/SRT--> Platforms
Guest 2 --SRT-->        |
                         +--> Audio program --> Shoutcast/Icecast

A key advantage of designing around translation is that you can bridge any stream protocols to any stream protocols (RTMP, RTSP, WebRTC, SRT, etc). That means you can accept what guests can send, and publish what audiences can watch/listen to.

5) Always-on radio channel: live when you’re live, AutoDJ when you’re not

For radio DJs and podcasters, the best listener experience is a station that never goes offline. Use SRT (or your preferred contribution method) for live shows, then fall back to AutoDJ playlists for 24/7 programming.

Shoutcast Net makes this simple with AutoDJ plus hosting that supports unlimited listeners, SSL streaming, and 99.9% uptime—without the surprise invoices common with Wowza’s expensive per-hour/per-viewer billing model.

Recommended rollout checklist (so you don’t troubleshoot live)

• Lock the ingest design: choose Caller/Listener ports, document them, and test from the worst network you expect (cellular/hotel).
• Set bitrate with headroom: verify uplink stability at the venue; don’t max it out.
• Rehearse with stats visible: watch RTT, retransmits, and buffer behavior for at least 20 minutes.
• Plan failover: second connection path or backup content (AutoDJ) to keep the station on air.
• Keep billing predictable: choose flat-rate hosting where audience growth doesn’t explode costs.