Configure SRT Caller, Listener, and Rendezvous Output

Configure SRT mode, URI, passphrase, firewall/NAT, and resilience testing.

Written By 4ALL.LIVE

Last updated 12 days ago

Create a resilient contribution link over unreliable networks using the peer's agreed SRT topology.

Best for: Network and broadcast engineers.

Before you start

Requires an SRT-compatible peer and routable UDP connectivity.

Sign in with access to the correct organization, team, and event.
Record event, language, workstation, app build, OS, drivers, destination, and operator.
Commission with test pattern and a non-public receiver before program video.
Obtain peer host/IP, UDP port, and mode.
Exchange passphrase securely when required.
Identify firewall/NAT and receiver owners.

Choose Caller when Encoder initiates to a listening receiver; this is normally simplest through NAT.
Choose Listener when the remote caller initiates and inbound UDP can reach Encoder.
Use Rendezvous only when both peers/network explicitly support it.
Enter a complete srt://host:port URI and approved passphrase.
Coordinate latency and URI options between peers.
Run test pattern and watch connecting, connected, reconnecting, or failed.
During rehearsal, introduce controlled loss/jitter and inspect recovery and delay.
Document addresses, forwarding, mode, encryption, and ownership.

What success looks like: The peer connects in the agreed mode and sustains video, audio, and captions through expected impairment.

No connect: check caller/listener pairing, address, UDP port, NAT, and firewall.
Handshake rejected: compare passphrase/options securely.
Rendezvous unreliable: use caller/listener topology.
Loss artifacts: raise SRT latency or reduce bitrate after measurement.

Important: SRT encryption depends on passphrase handling. Never place passphrases in tickets, screenshots, or public runbooks.