Skip to content

SRT delivery

SRT carries the signal where multicast does not reach: to another city, to a partner, across the internet. There are two ways to hand it over, and they differ in who establishes the connection:

  • Push — the station dials the destination itself and pushes the stream. That is how a signal is handed to a site that expects an incoming connection.
  • Serving (play) — the station raises a listener and waits for the partner to pull the stream. Convenient when the counterparty has its own schedule and its own equipment: you give the address and the key, the rest is theirs.

Sending to a destination

The Egress tab, + Add push, the SRT protocol:

Field What it sets
Name the destination's identity
Host, Port the receiving side's SRT listener
Passphrase the AES encryption key; on a mismatch the receiving side refuses at the handshake
Stream ID the identifier by which the receiver knows what it was sent
Handshake timeout (ms), Peer timeout (ms) the connection and inactivity timeouts

An address pasted whole as srt://203.0.113.10:9000 is split into the fields, and the SRT URL assembled back is shown next to them — that is what you copy and give to the receiving side.

A dead push comes back up by itself, once every five seconds, like any other delivery destination.

Serving from the stream's port

The SRT playback block: turn on Allow SRT pull (play), set the Port and, ideally, a Passphrase.

The partner pulls the stream by connecting to srt://<station-address>:<port> with their key. The port belongs to the stream entirely — one port per stream; a port conflict between streams is rejected on save rather than discovered on air.

Serving from a dedicated port may have its own outgoing MPEG-TS section: the partner receives the signal under the program number they need, without touching the other destinations.

What matters

  • Egress does not colour the stream. The stream status reflects the input. A dead push destination does not turn the stream red — delivery is checked by the destination's counters.
  • The latency on the output is the receiver's budget. How much time the receiving side has for loss recovery is set by them; the "three to four RTTs" rule is the same on both sides — see SRT ingest.
  • Retransmits are normal while there are few of them. A destination's retransmit counter grows when the path loses packets: the transport is doing its job. What is alarming is not the fact but the trend and its company — reconnects alongside.

What next