Telebridge between two vMix instances via satellite internet: solution with SRTMiniServer

When organizing joint events, the task of connecting two remote locations with broadcast-quality two-way video often arises. Each side needs to see and hear the other — a classic telebridge. Both locations are running vMix, the internet connection is Starlink, and there are no static ("white") IP addresses.

In this article, we'll examine why a direct SRT connection doesn't work under these conditions and how to solve the problem using SRTMiniServer and its CrossLine function.

The SRT protocol operates on the Listener–Caller model. The Listener opens a port and waits for an incoming connection, while the Caller initiates a connection to that port. For the Caller to reach the Listener, the Listener needs a public IP address and an open (forwarded) port.

Starlink uses CGNAT — all subscribers are behind the operator's NAT. This means:

● you cannot forward ports on the router,

● you cannot accept incoming SRT connections,

● both sides can only act as Callers.

Two Callers cannot connect without a Listener. An intermediate node with a public IP is needed to receive both streams and route traffic between them.

What about Rendezvous mode? SRT has a third connection mode — Rendezvous — where both sides simultaneously attempt to establish a direct connection with each other, without a designated Listener. However, in practice, it is poorly suited for production tasks. First, for configuration, each side must know the other's public IP and port in advance — but behind CGNAT (Starlink, mobile internet), the actual public address is inaccessible to the subscriber. Second, Rendezvous does not work with all NAT combinations: if both sides are behind Symmetric NAT, the connection will not establish. This gives Rendezvous a probabilistic nature — it may work in some network conditions but fail in others. For serious events where connection failure is unacceptable, such unreliability is not acceptable.

SRTMiniServer is installed on a cloud server (VPS) with a public IP and acts as a central SRT stream router.

The key function enabling the telebridge is CrossLine. It allows redirecting an incoming SRT stream from one SRTMiniServer line to another line as a return stream. Thus, each side receives video from the other side through the same server to which it is connected.

No Decode Mode. In this scenario, SRTMiniServer does not decode video — it works exclusively as an SRT stream router. Therefore, the No Decode mode should be enabled in settings, which disables decoding and NDI output. This significantly reduces server requirements: instead of a powerful machine, you can use a minimal VPS with 2 CPU cores.

Each vMix simultaneously sends its own signal (SRT Output, Caller) and receives the return stream (SRT Input, Caller). Both connections go to SRTMiniServer, which provides cross-routing through CrossLine.

Since a telebridge is typically a one-time or periodic event, deploying a permanent server is impractical.

The optimal choice is Amazon EC2. Thanks to No Decode mode (see above), the simplest instance is sufficient — for example, t3.small (2 vCPU, 2 GB RAM). The cost of such an instance is about $0.03/hour, meaning a full day of the event costs less than one dollar.

● Create and configure the instance in advance — install SRTMiniServer, open the necessary ports in the Security Group.

● After configuration and testing, Stop the instance. In the stopped state, only disk storage is charged (pennies).

● Before the event, Start the instance. The public IP will change, but this is not a problem — vMix on both locations is configured in Caller mode; you simply need to update the address.

● After the event, stop it again.

This approach allows you to keep a fully configured server "on pause" and activate it within minutes when needed.

Tip: If you need a consistent IP each time you start, attach an Elastic IP to the instance (small additional charge for unused addresses).

● Install SRTMiniServer on the VPS.

● Select "No decode" in right-bottom corner (more info >>>)

● Allocate two lines (Line 1 and Line 2) — one for each location.

● Activate CrossLine for both lines: Line 1 → Line 1 and Line 2 → Line 2. This enables pulling the stream from each line.

● Sending: Settings → Outputs / NDI / SRT → enable SRT Output in Caller mode, specify the IP and port of Line 1 on SRTMiniServer.

● Receiving: Add Input → Stream / SRT → Caller mode, specify the IP and port of Line 1 on SRTMiniServer (the CrossLine return stream will come automatically).

More info about Playback setup see here >>>

● Similarly, but connect to Line 2 of SRTMiniServer.

● Ensure both sides can see each other.

● Check SRT statistics in SRTMiniServer: RTT, packet loss

Starlink provides sufficient bandwidth for video transmission (typically 50–200 Mbps download), but satellite internet has characteristics that are important to consider:

Latency. Typical RTT through Starlink is 40–60 ms under stable conditions, but spikes up to 100–200 ms can occur during satellite handovers. It is recommended to set SRT Latency to at least 200 ms (or 300–500 ms with unstable connections) so the buffer compensates for jitter.

Brief disconnections. During satellite handovers, connection losses of 1–3 seconds may occur. SRT is designed for such conditions: the ARQ (Automatic Repeat Request) mechanism automatically requests retransmission of lost packets. Sufficient latency buffer minimizes the impact of such moments on the picture.

Bitrate. Starlink upload is typically 10–30 Mbps. Recommended transmission bitrate is 5–10 Mbps (h.264) or 3–6 Mbps (HEVC), which leaves headroom for ARQ retransmissions.

The combination of vMix + SRTMiniServer in the cloud solves the telebridge problem between two locations without static IP addresses. The CrossLine function provides cross-routing of streams, and SRT handles the specifics of the Starlink satellite channel — jitter, packet loss, and brief disconnections.

For one-time events, a cloud server (Amazon EC2) can be prepared in advance and activated just before the event, without incurring ongoing costs.

Important note: This scheme scales easily to any number of participants, meaning you can conduct video link-ups between three, five, or ten cities in the same way.