Ports and Troubleshooting

Updated Oct 21, 2026

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 processor, memory, and transcoding sizing, see System Requirements.) 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 nothing routed here. On a vMix/OBS destination slot, the gateway is actively sending a plain black picture rather than nothing at all — see No-signal fallback below.
• 🔵 Blue — connected and routed, but the gateway is currently substituting the "technical difficulties" slate because nothing real has arrived from the routed source in the last few seconds. Also covered in No-signal fallback below.
• 🟢 Green — connected, routed, and genuinely receiving/relaying real video right now.

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:

• A vMix/OBS destination slot tile shows its routed source's thumbnail only while it's actually relaying real content (green). When it's showing black or the slate instead (see No-signal fallback above), the tile shows that same black/slate image directly rather than a stale frame from the source — so what you see on the tile always matches what's actually being sent, not just what's configured. A vMix slot or single-feed destination still doesn't independently confirm its own reception is correct even when green — it's showing you the same frame its source tile shows, not a capture of vMix's own screen. If you need to confirm a destination is actually receiving correctly, 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 fallback

Once a destination slot or a source's return feed is connected, the gateway always sends it real, continuously-encoded video — never silence. Which of three things it sends depends on what's actually happening upstream, and updates live as conditions change:

• Nothing routed at all → a plain black picture, sent immediately (no waiting period). This applies the moment the slot is connected, whether or not you've ever patched anything into it.
• Routed, but nothing real has arrived in the last 5 seconds → the "technical difficulties" slate image, switching back to the real picture the instant real content resumes — no action needed from you either way.
• Routed and genuinely receiving/relaying real content → the real picture.

This is the same behavior for both a source's return feed and a vMix/OBS destination slot — a genuine connection on either side of the gateway should never look like a hard failure to whatever's watching it, whether that's a field decoder on a return feed or vMix waiting on an input slot.

Why this matters: a field decoder (or vMix input) that receives nothing at all often just reports a plain "connection timed out" or sits on its own generic "no signal" screen, which looks exactly like a network problem even when the real cause is something mundane like "nothing's patched into this slot yet" or "the source hasn't started streaming yet." The black/slate fallback turns that into a clear, visible signal instead — black specifically means "the connection itself is fine, nothing's been routed here," and slate specifically means "something's routed, but it's not currently sending anything real" — two different situations that used to look identical (or, for a destination slot before this existed, looked like total silence) from the receiving end.

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. The black fallback isn't customizable — it's always a plain black frame, with nothing to upload or reset.

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."

A source's return feed won't connect (even though its own ingest is fine):

The shared return-feed listener (port 5000, every source multiplexed through it) tells sources apart by a stream ID the connecting device must present — not by port or IP. If your field device's own return/"program feed" input doesn't have a stream ID field, or has it blank, this will fail to connect at all, silently, no matter how many times it retries.

1. The stream ID format is always return_site_<N>, where <N> is that source's own index (shown as the number on its card — e.g. source 6 needs exactly return_site_6). This is unrelated to whatever stream ID (if any) that same device uses for its own ingest connection — the two are configured independently, often in different sections of the field device's own settings ("Program Feed" vs "Contributor Camera," or similar wording).
2. If you've just set this and it's still not connecting, check whether your field device's app/control panel actually needs a full reload (not just a reconnect toggle) to pick up a newly-saved setting — some web-based encoder control panels only push new config to the running encoder on a fresh page load.
3. Check Diagnostics for that source's return row's Last Error — a rejected stream ID shows up there.

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."
• A field encoder repeatedly reconnecting (a high, climbing Reconnects count in Diagnostics, or a connection that only briefly holds before dropping) on a genuinely rough network path — cellular, long-distance Wi-Fi, a saturated home connection — often means its own SRT latency setting is too low for that path's real jitter, not a problem on the gateway side. Raising the field device's own latency setting (its default is often quite low, e.g. 200ms) to something more generous for a poor connection can turn a connection that never holds into one that holds reliably. SRT negotiates the larger of both ends' latency settings, so this only ever needs to be raised on whichever end actually has the rough path — normally the field device, not the gateway.
• If a vMix/OBS destination's SRT connection stays up and looks perfectly healthy in Diagnostics (clean stats, no loss/retransmits) but genuinely stops producing any new video after playing briefly — as opposed to freezing on the last frame, or showing black/slate — check whether that output has hardware encoding enabled, especially if another output on the same vMix/OBS instance also has SRT (or another hardware-encoded output) running at the same time; a limited or contended hardware encoder session can silently stop producing frames while the connection itself stays open. Try disabling hardware encoding on that specific output as a test.
• 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.