Transport mechanics map
SRT carries live media across an imperfect IP path and gives the endpoints a limited window in which to recover loss. Its mode, recovery budget and encryption policy need to be explicit; otherwise product settings quickly turn into folklore.
The protocol moves payload. Encoding, platform design and proof of usable decoded media sit elsewhere in the path.
Place SRT in the media path
The map begins with the media stages: encoder or application, SRT sender, network, SRT receiver, demuxer/decoder and output. Beside each endpoint, note both the payload it carries and the product that owns it. SRT may bridge a venue and cloud system, connect production sites or form one controlled leg of a larger contribution path.
SRT is an open-source transport protocol for live video and audio; it uses UDP and ARQ-based retransmission, with optional AES encryption. Open the official SRT project for the primary documentation. An application UI maps onto that protocol; it does not replace it.
Understand UDP, ARQ and recovery
UDP provides datagram transport without TCP-style ordered delivery. SRT adds acknowledgements and ARQ-based retransmission, allowing the receiver to request a missing packet again. Yet recovery still has a clock: a replacement arriving after its useful delivery point cannot repair a moment that has already been presented.
Recovery also needs network headroom. On a continuously saturated path, retransmissions compete with the original media. SRT cannot create bandwidth or make an unsupported codec decodable. Transport state and decoded output therefore belong in the same observation, while rate-control changes remain outside a protocol definition.
- Original packet crosses the UDP path.
- Receiver identifies missing sequence information.
- ARQ requests a retransmission.
- Replacement must arrive inside the useful window.
- Receiver still has to demux and decode the payload.
Assign Caller, Listener or Rendezvous
In the official srt-live-transmit mode contract, Caller initiates a connection to a Listener, Listener waits for a Caller, and Rendezvous is a one-to-one mode in which both peers attempt to initiate the connection. Each endpoint needs a recorded role, separate from the direction in which media flows.
A camera may call while sending, but an application can just as easily call while receiving from a waiting server. That makes “Sender equals Caller” unsafe shorthand. Rendezvous still needs deliberate configuration on both peers, along with firewall and NAT testing. One explicit diagram should contain the addresses, ports and roles.
Initiates toward the named peer.
Waits for a Caller on the configured socket.
Both one-to-one peers attempt initiation.
Recorded separately from connection role.
Treat latency as a recovery budget
SRT receiver latency is a time budget used by recovery; the effective setting and peer negotiation must be checked on the actual path rather than treated as a universal quality preset. A larger budget can leave more time for a requested packet to return, at the cost of additional transport delay.
The value should come from measured RTT, observed loss and the production delay limit. Check current socket options for exact semantics and units, then Tune the recovery window in a controlled path experiment. Both peers need testing; this page intentionally does not prescribe one number.
Enable encryption with an explicit policy
Optional AES encryption protects the SRT payload in transit when configured. The policy should say whether encryption is required, how keys or passphrases are provisioned, which modes and lengths the deployed versions support, and what happens during rotation or failure. A passphrase must never appear in a public URL example or log.
Encryption does not authorize a stream, manage viewers or apply DRM to final playback; those controls belong to their own products and policies. In a safe environment, check a valid secret, an invalid one and a rotated one, recording the rejection without exposing the value.
Separate transport health from decoded media
Connection state, bitrate, RTT, loss and retransmission counters describe parts of an SRT session. None proves that the expected video, audio or timestamps reached a decoder. Read SRT telemetry for the exact field classes, then set those intervals beside the picture and audio observations.
Transport may look active while the session carries the wrong program, an unsupported codec, silent audio or corrupt timestamps. Conversely, a counter can move even when recovery prevents visible damage. The two observations stay synchronized by timestamp and session identity; neither should be forced to stand in for the other.
Prove the path end to end
Product configuration comes after the protocol map is clear. Configure a Callaba SRT endpoint, start one known test signal and capture the role, address, port, latency and encryption state on both peers. Transport statistics and the receiver result must cover the same interval.
An intentional disconnect and recovery extends the proof beyond the first successful connection. The record should show which peer restarts, how the Listener or Caller state changes, whether security is renegotiated and when decoded media becomes usable again. That application behavior remains distinct from the protocol’s role definitions.
Verify decoded output where Multiview is the approved observation surface. The finished diagram covers one real path, including endpoint roles, ports, latency on each peer, encryption state, transport counters and decoded picture/audio acceptance. Run the same check after a controlled reconnect.
