What is SRT protocol? Secure Reliable Transport for live video
More live video workflow notes and product updates.
SRT moves live video across an imperfect network without pretending the network is perfect
SRT stands for Secure Reliable Transport. It is an open-source transport technology built on UDP for live video. The sender and receiver use acknowledgements and selective retransmission to recover packets that disappear in transit, as long as the replacement can arrive inside the configured latency window.
SRT is commonly used between an encoder and a production system, between sites, or from an event into the cloud. It is not a video codec, a player format or a complete streaming platform.
What SRT adds to a UDP media path
Plain UDP is fast and simple, but it does not replace a missing datagram. SRT adds a timing and recovery layer around the live flow. Sequence information lets the receiver detect a gap; feedback asks for a retransmission; the latency buffer gives the replacement a limited opportunity to arrive.
That trade is the heart of SRT. More latency can create more recovery time, but it cannot repair an under-provisioned link or unlimited congestion. Encryption protects the SRT session in transit when a passphrase is configured. Stream ID can carry connection metadata used by the receiving service, but its exact policy belongs to that service.
Caller, listener, and rendezvous modes answer one question: who opens the connection?
Initiates the connection to a known address and port. A camera can be Caller while sending, and a receiver can also be Caller while pulling.
Waits for an incoming SRT connection on an address and UDP port. Listener does not automatically mean “receiver”; the media direction comes from the application design.
Both sides initiate and attempt to meet. It can help in a deliberate peer-to-peer design, but firewall and NAT behavior still need testing.
Write the role beside every endpoint during setup. “Encoder sends, server receives” is not enough to diagnose two Callers or two Listeners.
Latency is a recovery budget, not a quality preset
The SRT socket options documentation describes receiver latency as the minimum time a packet is kept available for recovery, with the negotiated value influenced by both peers. For an operator, the useful inputs are measured round-trip time, the duration of loss bursts, and the amount of end-to-end delay the production can tolerate.
Begin from a measured path, not a copied number. Test under representative Wi-Fi, cellular or WAN changes; watch retransmissions and unrecovered loss; then raise or lower latency in controlled steps. The dedicated SRT latency guide turns that into a repeatable test.
Read these signals together
| Signal | What it can tell you | What it cannot prove alone |
|---|---|---|
| Bitrate | Media is arriving at a measurable rate. | That the codec is decodable or audio is present. |
| RTT | How long the acknowledgement path takes. | The full duration of a loss burst. |
| Retransmissions | The transport is being asked to recover data. | That every replacement arrived in time. |
| Unrecovered loss | Packets missed the usable recovery opportunity. | Exactly how visible the damage is after decode. |
Use the SRT statistics guide when you need to turn counters into an operator decision.
Where the protocol stops and the product begins
SRT gets a protected live transport session from one endpoint to another. A production system still needs access policy, routing, preview, recording, failover, output conversion and a browser-safe delivery format. That is why a protocol comparison cannot replace a real product trial.
Read the official SRT project and its socket options reference for the transport contract. Use Callaba SRT Server for the operational product and Callaba SRT Gateway for routing and conversion choices.
Connection role, latency and recovery belong in one SRT check
Caller initiates; Listener waits; Rendezvous peers meet. These labels do not fix the direction of the media.
Latency gives retransmitted packets time to return. Size it from measured RTT and representative loss bursts.
Read passphrase and Stream ID policy, bitrate, RTT and loss beside a decoded picture-and-audio check.
