SRT when neither end has a static IP

SRT assumes that one of the two ends can be connected to. In real venues, neither can: the church hall is behind the building's router, the studio is on a business line with a dynamic address, and the phone is behind carrier-grade NAT where port forwarding does not exist even in principle.

This page explains the three modes, then the three honest ways out.

The three connection modes

Caller dials out to an address. Works from behind any NAT, because outbound UDP is what NAT was built for.

Listener waits to be dialled. Needs a reachable address and the right UDP port open — a static IP or reliable dynamic DNS, plus a port forward.

Rendezvous has both sides dial each other at the same moment on the same port, so each one's outbound packet opens the path for the other's inbound packet.

Why rendezvous is not the universal answer

Rendezvous works when both routers do cone NAT: the port they allocate for your outbound packet stays the same regardless of who the packet goes to, so the far end can aim at it.

It fails when either side does symmetric NAT — a new port per destination, which is what most carrier-grade NAT does, and what many business firewalls do deliberately. The far end aims at a port that is no longer yours, and the handshake never completes. It also fails when both ends are behind the same kind of restrictive firewall, or when the clocks of the two dial attempts drift too far apart.

The practical summary: rendezvous is worth trying between two ordinary home connections, and is close to hopeless when a mobile network or a corporate firewall is on either side.

Option 1: make one side reachable

Cheapest if you already have the means. You need, on one side:

• a static IP, or dynamic DNS that updates fast enough
• a UDP port forwarded to the receiving machine
• a firewall rule that survives your IT department

Then that side is the listener and the other dials in. If your provider gives you CGNAT, ask for a real IP — many ISPs offer one for a small fee, and that is often the whole problem solved.

Option 2: run your own relay on a VPS

Rent a small VPS with a public address, install SRT tooling, and have both ends call it:

srt-live-transmit "srt://:4000?mode=listener" "srt://:6000?mode=listener"

Real, and completely legitimate. What you are taking on: UDP port management, restarts when a stream dies, buffer tuning, monitoring, someone awake during the event, and the discovery that the cheap VPS is in the wrong country for your latency. For a permanent installation it pays off. For six shows a year it is a hobby.

Option 3: use a hosted relay

Both ends stay callers — nothing forwarded, nothing installed, no static IP anywhere:

encoder ──► relay input ──► relay output ──► receiver
 (caller)   public address, fixed ports      (caller)

That is what this service is. You get an input address for the sender and one or more output addresses for receivers, in Germany or the USA, managed from a Telegram bot: three free 30-minute sessions a day, $5 for a full production day. The same relay can feed several receivers at once — programme, backup, and a producer watching on a laptop — each pulling independently.

Which one should you pick

Before you commit to any of them

Prove that SRT leaves the building at all. From the venue's network, pull our free test signal:

ffplay "srt://de.inoutsrt.com:6999?streamid=read:beacon&latency=200"

If the bars appear, outbound UDP works and any caller-based design will work. If they do not, no relay and no VPS will help until the network is fixed — and it is much better to learn that a week before the event than an hour before.