Ports and Troubleshooting

Firewall / port reference

What N means, and whether it's stable: each source and each destination gets a slot number the first time you add it (1st added = 1, 2nd = 2, and so on), and that number — and therefore its port — never changes for as long as that entry exists. Deleting an entry frees its number for reuse; the next new source/destination you add takes the lowest free number, which could be one a deleted entry used to have. So: your existing sources/destinations never have their ports move out from under them, but a brand-new one can land on a port a previous, now-deleted one used to occupy — worth knowing if you keep your own notes on which physical encoder uses which port.

Key thing to remember: sources always call in to the gateway (so the gateway's public-facing firewall needs those inbound rules); everything on the destination side, the gateway always calls out — nothing on your local vMix/OBS network needs an inbound rule from the internet, only from the gateway itself.

Which IP those inbound ports actually listen on is picked in the Setup tab's "Gateway interface" column — one network interface, chosen from a list of what's actually detected on the machine (never a freehand IP entry, so a typo can't wedge ingest onto an address that doesn't exist):

One NIC or two? For N sources and D destinations (each destination has 3 slots), every routed stream's bytes pass through the gateway once per hop: ingest = N, slot push = D×3, program-out pull = D×1, and — only if you're using return feeds back to the field — up to N more. A single NIC carries all of it. If you have two network interfaces available, splitting onto both instead (one dedicated to internet-facing source/return traffic, one dedicated to your local vMix/OBS network, picked independently as each destination's own interface) isolates internet jitter/loss from local production traffic and roughly halves what either interface has to carry. Using 6 Mbps as a reference 1080p60 SRT contribution bitrate:

A single 1 Gbps NIC stays comfortably headroomed up to roughly 60 sources and 3 destinations with return feeds active — well past most real deployments. Past that scale, or at a much higher per-source bitrate, splitting across two 1 Gbps interfaces raises the practical ceiling substantially before faster hardware is actually necessary.

Status dots

Every dot reflects a live connection right now, never a cached or saved state. On the Operate tab, this same red/yellow/green signal is shown as a colored border around each tile (a "tally light") instead of a small dot — same three states, same meaning, just more visible at a glance across a busy matrix. The Diagnostics tab shows the same red/yellow/green as a colored dot in its Status column, grouped by source/destination name instead of laid out spatially — see Diagnostics and Signal Flow for what else that view adds beyond just status.

• 🔴 Red — no connection. For a source, its encoder isn't calling in. For a destination, the gateway can't reach it. Either way, it's retrying automatically in the background — you never need to restart anything manually.
• 🟡 Yellow — connected, but not routed anywhere yet. Applies to sources and to vMix/OBS destination slots alike.
• 🟢 Green — connected and routed.

A destination on UDP MPEG-TS doesn't have real connection state (UDP has no handshake) — its dot reflects whether a packet has arrived in the last 2 seconds, not a true connected/disconnected signal. Not configurable.

A source or destination on RTMP/RIST is bridged through an external tool (ffmpeg) rather than handled directly — its dot reflects whether that bridge process is currently running, which is slightly coarser than SRT/UDP's precise per-packet tracking: it can't always distinguish "waiting for a connection" from "actively receiving."

Traffic counters and connection health

Next to the status dot on each source, destination slot, and program-out, you'll see a small traffic stat — bytes transferred, a live bitrate, uptime since the current connection started, and (from the Diagnostics tab) reconnect count and, for native SRT connections, real RTT/packet loss/retransmit numbers. This is the thing that actually proves media is flowing, since a green dot only means a connection is open, not that valid data is coming through it. If a dot is green but the traffic stat stays at 0 B, something upstream is connected but not actually sending — check the encoder's own output status, not the gateway.

Traffic counters exist for every native SRT/UDP relay (source ingest, vMix/OBS destination slots, program-out, the return feed); RTT/packet loss/retransmits specifically only exist for native SRT (not plain UDP-TS) — see Diagnostics and Signal Flow for the full column reference. None of the above exists for single-feed (Epiphan/RTMP/RIST) destinations, which don't have per-packet visibility into the ffmpeg bridge.

Live thumbnails (Operate tab)

Every source and station-program-out tile on Operate shows an actual preview frame from its incoming video, refreshed roughly every 5 seconds — not just a status color. This is the fastest way to confirm "is this actually the right camera/feed," not just "is something connected." A tile that's been green for a while but still shows "no preview" usually means the connection itself is fine but the source isn't sending decodable video yet (e.g. an encoder that connected before it started actually encoding).

Two things worth knowing:

• Destination tiles show their routed source's thumbnail, not their own capture. A vMix slot or single-feed destination doesn't independently confirm its own output is correct — it's showing you the same frame its source tile shows. If you need to confirm a destination is actually receiving correctly (not just that the right source is routed to it), check the receiving software/hardware directly.
• Single-feed (RTMP/RIST) destinations have no live preview of their own egress at all, same limitation as their missing traffic counters above — there's no per-frame visibility into the ffmpeg bridge feeding them.

No-signal slate

If a feed has nothing real to send for 5 seconds, the gateway automatically shows a "technical difficulties" slate instead of sending silence — and switches back to the real picture the instant it resumes, with no action needed from you.

• A source's return feed always gets this once it's connected — even if you haven't set up a return route for that site at all yet. Its confidence monitor should never just be dark.
• A station-to-station forward route only falls back once it's actually routed but idle (e.g. patched to a station that's currently offline). A slot you simply haven't patched anything into stays blank, same as always — that's still your own explicit choice.

Why this matters: a field decoder that receives nothing at all often just reports a plain "connection timed out," which looks exactly like a network problem even when the real cause is something mundane like "the station this return is fed from hasn't started streaming yet." The slate turns that into a clear, visible signal instead — if a field operator sees "technical difficulties" on their return monitor, that alone tells you the problem is on the gateway/production side, not the network.

You can replace the slate image from the Setup tab — the "No-signal slate image" panel sits directly under the gateway interface picker, and shows a live preview of whatever's currently set so you're never uploading blind. Any common image format works, and it's automatically scaled to fit the screen without stretching, whatever its original shape. "Reset to default" restores the built-in one at any time.

Each source's return feed also gets its own live thumbnail now, shown right next to its return-routing control on the Operate tab — so you can see at a glance, right from the dashboard, whether a site is currently getting real content or the slate, without needing to check the field decoder itself.

This is a different thumbnail from a destination's own "Program Out" tile, and they behave differently on purpose:

• A destination's Program Out tile shows exactly what that station is actually sending to the gateway, straight from the real capture — it never shows the slate. If the station is down, that tile just shows nothing, same as always.
• A source's return thumbnail shows what's actually going back out to that field site — real content, or the slate when idle.

So if a station goes down: its own Program Out tile goes blank (no change there), while any site whose return is fed from that station switches to showing the slate on its return thumbnail. Once the station's Program Out tile shows real content again, the return thumbnail should follow shortly after.

SRT latency/passphrase overrides

Click SRT settings on a source's card, or Edit ports on a vMix/OBS destination's card, to override the gateway's default SRT latency (120ms) or require a passphrase — only meaningful for SRT-protocol sources/destinations. If a passphrase is set and the other side doesn't present it, the connection is refused outright (not just flagged) — if a source or destination that used to connect suddenly can't, check whether someone set a passphrase here first, before digging into networking.

("SRT settings" and "Edit ports" are different labels for the same kind of thing — both open that card's endpoint configuration overrides, just named for what's most relevant on a source's card vs. a destination's.)

The return feed does not inherit a source's passphrase. A source's SRT settings only protect that source's ingest — the shared return-feed listener (port 5000, every source multiplexed through it) has no per-source latency/passphrase of its own.

Troubleshooting checklist

Source won't connect: 1. Confirm you're using the exact IP/port shown on the source's card — these are generated per-source, not fixed. 2. Confirm your encoder is in caller mode (dialing out), not listener — the gateway is always the listener for sources. 3. For RTMP, double check the stream key/path matches exactly what's shown on the source's own card — a mismatched path is silently rejected. 4. For RIST, confirm your encoder is in caller mode, not listener — the gateway is always the listener for sources, same as every other protocol. 5. Check the source's card for SRT settings — if a passphrase is set there, your encoder needs the exact same one or the connection is refused (not just flagged). 6. Check Diagnostics for that source's Last Error — a bind/listener failure or a rejected connection shows the exact reason there, not just "offline."

Destination won't connect: 1. Confirm the destination software (vMix/OBS Media Source) is configured as a listener, not a caller — the gateway always calls out to destinations. 2. Confirm there's no firewall between the gateway and your local network blocking the relevant port. 3. If you have two destinations on the same physical box, check they aren't both trying to use the shared program-out port (14000) — there's currently no dashboard control to override this per destination. Two options: run the second one on a different host/VM, or (power users) set program_out_port_override for one of the destinations directly in app_config.json and restart the gateway — it isn't exposed in the dashboard yet, but the backend already supports it. 4. Check the destination's SRT settings (via Edit ports) for a passphrase mismatch, same as sources above. 5. Check Diagnostics for that destination slot's Last Error — same as sources, a dial failure shows the actual reason (e.g. connection refused, timeout) there.

Video connects but looks wrong / stutters: - Check the traffic stat next to the status dot first — if the bitrate looks far lower (or higher) than expected, that's a real signal about what's actually flowing, not just that a connection exists. - For a native SRT connection, check Diagnostics for packet loss/retransmits on that specific row — real loss/retransmit numbers are a stronger signal of a degraded network path than "it looks choppy." - Otherwise this usually isn't a gateway routing problem — it's either a network issue on the actual video path (jitter, packet loss) or an encoder/decoder setting mismatch (bitrate, resolution, keyframe interval). The gateway itself doesn't touch, re-encode, or transcode the video for SRT/UDP-TS paths — RTMP/RIST bridges do remux the container but don't re-encode either, so a quality problem is almost always upstream or downstream of the gateway, not in it.

Something changed and now nothing works: - Check the Events tab first — it's a timestamped log of every route change, preset application, and connect/disconnect this session, so you can see exactly what changed and when without guessing.

• Check Diagnostics' Reconnects column for anything unexpectedly high — frequent reconnects on one endpoint, even if it currently reads green, is worth investigating before it becomes a visible problem.
• Rerouting a vMix/OBS or UDP-TS destination is instant and seamless.
• Rerouting an RTMP or RIST destination causes a brief (a second or two) real interruption on that output only — expected behavior, not a bug, since that reroute has to restart an external process.