SRT streaming server: latency, modes, encryption and the UDP port

What the latency setting buys

SRT latency is not glass-to-glass delay. In the SRT documentation it is only the network leg: the time a packet waits in the receiver buffer before it is handed to the application. The mechanism is TimeStamp Based Packet Delivery (TSBPD): the receiver replays packets with the same spacing the sender gave them, and the buffer gives a lost packet time to be reported and sent again.

SRTO_LATENCY sets both the receive latency and the peer latency. The default is 120 ms in live mode, and the value actually used on a connection is negotiated in the handshake as the larger of what the two sides ask for. The documentation recommends 3 to 4 times the round-trip time, and warns that RTT varies a lot on Wi-Fi, line-of-sight radio and 4G/5G links.

Too-late packet drop (SRTO_TLPKTDROP) is on by default in live mode: a packet whose play time has passed is skipped rather than waited for. The latency is therefore also the ceiling on recovery. Set it too low for the path and you see glitches; set it high and every viewer is that much further behind.

Caller, listener and rendezvous

Who opens the connection is independent of which way the video flows. A caller sends the connection request; a listener waits on a bound UDP port; in rendezvous both sides dial each other at once, one to one, which helps when both ends sit behind firewalls.

• Listener on the receiving server is the usual layout: the server has a fixed address, so only its UDP port has to be open, and encoders on unknown addresses call in.
• Listener on the sender suits a venue feed that several receivers pull from different places.
• Rendezvous cannot carry a Stream ID in any useful way, since each side would overwrite the other's.
• Stream ID (SRTO_STREAMID, up to 512 characters) lets one listener port accept many streams; the project's access-control guidelines define the #!:: key-value format, for example r= for the resource and m=publish for the mode.

Passphrase and key length

Setting SRTO_PASSPHRASE turns encryption on. The passphrase must be 10 to 80 characters; both ends set the same one, and it is run through PBKDF2 to derive the key-encrypting key. By default the payload is encrypted with AES in counter mode (AES-CTR); newer releases can optionally use AES-GCM.

For one-way contribution the documentation says the sender sets the key length and the receiver leaves it at 0. SRTO_ENFORCEDENCRYPTION defaults to true, so a mismatched or missing passphrase is rejected at connect time instead of producing a stream nobody can decrypt.

Ports, bandwidth and the firewall

SRT has no fixed well-known port. A listener binds the UDP port you choose, and that port must be reachable: open it in the firewall and, behind NAT, forward it as UDP to the listener's local address. A caller needs no inbound rule.

Retransmissions travel on the same link as the stream, so leave headroom above the encoder bitrate. With SRTO_MAXBW at 0 the ceiling follows the input rate plus SRTO_OHEADBW, which defaults to 25%; the documentation warns that too little overhead makes the stream choke as loss rises. The default -1 means no limit beyond the 1 Gbps live-mode cap.

SRT against RTMP for contribution

RTMP runs over TCP. The SRT Internet-Draft notes that TCP-based protocols such as RTMP give acceptable reliability only on low-RTT connections and cannot use a link's full bandwidth under TCP congestion control. SRT runs over UDP and recovers loss with Automatic Repeat reQuest inside a bounded latency window, so delay stays constant instead of growing behind a stalled connection.

The draft also notes RTMP's payload limits: two audio channels and a restricted codec set without HEVC, VP9 or AV1. SRT is payload agnostic. RTMP still wins on reach, since nearly every encoder speaks it, and on a short, clean path from a studio to a nearby ingest the difference is small.

Running your own SRT server on Linux

1. Install the build dependencies and build the library and sample apps from the Haivision repository, as the Linux build guide shows.
2. Measure RTT from the encoder's site; the msRTT statistic reports it once a test connection is up.
3. Start a listener with a passphrase and a latency sized from that RTT, and open its UDP port.
4. Point the encoder at the server as a caller with the same passphrase and its chosen key length.
5. Watch pktRcvLoss, pktRetrans and pktRcvDrop: drops mean the latency is too short for the path.

sudo apt-get install tclsh pkg-config cmake libssl-dev build-essential
git clone https://github.com/Haivision/srt.git && cd srt
./configure
make

# receiver: listen on UDP 9000, encrypted, 400 ms buffer, hand MPEG-TS to local UDP 1234
./srt-live-transmit "srt://:9000?passphrase=use-a-long-random-secret&latency=400" udp://127.0.0.1:1234 -v

# sender: read UDP 1234 (listens on all interfaces; keep that port closed to the outside), call the receiver, AES-256
./srt-live-transmit udp://:1234 "srt://receiver.example.net:9000?passphrase=use-a-long-random-secret&pbkeylen=32&latency=400" -v

The project describes srt-live-transmit as a sample for instruction and testing, not for production. In production the listener is normally an SRT-capable media server. For that role, a dedicated streaming server is single tenant, with root, an unmetered port, and the streaming software you choose.

SRT ingest without running the server

If the goal is a live channel rather than an SRT server to administer, our live video streaming service takes SRT on the Starter, Pro and Platinum plans; the free plan takes RTMP and WebRTC. Every channel is issued a separate SRT port and passphrase, so channels never share a listener, and the dashboard prints the settings with a copy button beside each line.

The encoder lands in the closest ingest city of five, and the stream rides our own network to the channel's server in New York or Bucharest. Output is HLS and DASH to viewers through the video CDN. The Live tab shows whether the encoder is connected, from which address and at what rate, and can drop a stuck encoder or restart the channel. For a one-off conference or concert, event streaming is set up on the same CDN.

When a hosted channel is the wrong fit

• You need SRT out as well as in, or SRT relays between your own sites: run your own listener on a dedicated machine.
• You need rendezvous mode or Stream ID routing under your control: those are server-side settings.
• Your encoder only speaks RTMP: SRT buys nothing, and RTMP works on every plan.