NDI Ports & Discovery: mDNS, Subnets & Media Tests | Callaba
More live video workflow notes and product updates.
An NDI source can be discoverable while its video ports are blocked, and a healthy sender can remain invisible when discovery never reaches the receiver. Troubleshooting works faster when you separate three stages: find the source, establish the media session, then prove frames and audio arrive on the intended interface. “Open all NDI ports” is not a diagnosis.
Discovery and media use different network conversations
Callaba can prove visibility, not the whole media path
Callaba's documented NDI configuration selects the instance machine name, explicit network interfaces and Discovery Server addresses. The NDI discovered-devices API can synchronize the inventory and report whether a saved device is currently discovered. After visibility is confirmed, an NDI adapter can publish a managed output.
A saved device entry is not proof that its sender is reachable now. Callaba explicitly directs operators to check current state. Its documentation does not describe a port scanner, packet capture, firewall-rule generator or per-connection NDI transport trace, so network evidence still belongs in the incident workflow.
| Callaba check | What a pass means | Next check |
|---|---|---|
| Configured interface | The intended local IP is selected | Route and firewall bind to that interface |
| Discovery Server reachable | The registry endpoint accepts the connection | Sender and receiver use compatible discovery configuration |
getStat reports discovered | The source is currently visible | Open the media session and verify frames |
mDNS is local discovery by default
The official NDI mDNS guide states that NDI uses multicast DNS for zero-configuration discovery by default. mDNS uses UDP port 5353 and the IPv4 link-local multicast address 224.0.0.251. Because it is link-local, it normally discovers sources within one physical or logical LAN rather than crossing routed subnets.
Check the operating-system network profile as well as the switch. Host firewall policy can suppress mDNS responses even when multicast is present on the wire. On a multi-homed machine, confirm queries and responses appear on the media interface, not only the management network.
A Discovery Server connects controlled areas
The official NDI Discovery Server documentation describes a centralized registry that can replace sender mDNS and work across subnets or environments where multicast is undesirable. Clients configured to the same service can discover registered sources through unicast connectivity.
The default Discovery Server port is TCP 5959, and current NDI versions allow a different port to be configured. Treat the server address and port as one versioned setting across senders and receivers. For resilient designs, test each configured server independently and verify that clients recover without retaining a stale source list.
Use a port table by function
The current official NDI network-port reference separates discovery, host queries and media connections. The ranges depend on NDI version, transport mode, sender or receiver role and concurrent connections, so copy the exact rules for the deployed SDK rather than freezing a permanent universal range.
| Port or range | Transport | Documented purpose |
|---|---|---|
| 5353 | UDP | mDNS discovery on the local link |
| 5959 | TCP | Default NDI Discovery Server service |
| 5960 | TCP | Query a machine for its sources when added by IP |
| 5961 and up | TCP | Base TCP connections for NDI streams |
| 5960 and up | UDP | Reliable UDP in NDI 5 and later, with connection sharing |
| 6960 and up | TCP or UDP | Multi-TCP or UDP receiving connections |
| 7960 and up | TCP or UDP | Multi-TCP, unicast UDP or multicast UDP sending connections |
This table is not a reason to create an unrestricted any-to-any firewall rule. Identify which hosts send, receive, query or run discovery; calculate connection counts; constrain direction and network zones; and confirm the current NDI documentation when the SDK changes.
Manual addressing solves only discovery
NDI can query a source machine by address when mDNS cannot reach it. That can reveal sources across a routed network, but it does not guarantee that the later media ports are permitted or that the path has enough capacity. The same distinction applies to a Discovery Server: a source name in the registry proves registration, not video delivery.
After the source appears, test connection establishment, chosen network interface, transport, packet rate, receive bitrate, dropped frames, audio cadence and rendered output. If names appear quickly but video fails, stop changing mDNS and inspect the media path.
Subnets and multiple interfaces need one owner
Document which subnet owns discovery, which carries media, and whether senders are allowed to use more than one NIC. Avoid duplicate machine names. Keep addressing stable for Discovery Servers, and make route preference deterministic on hosts with management and production interfaces.
When cloud or routed environments do not support link-local multicast, use the centralized or manual discovery method supported by the participating products. Validate end-to-end MTU, bandwidth and security separately; successful unicast discovery does not change those media requirements.
The source is listed, but the receiver gets no frames
An NDI source remains listed after a firewall change. Operators keep resynchronizing discovery because the tile is black. First use the current-state check to distinguish a live discovery result from a saved entry. Then compare the selected Callaba interface, Discovery Server connection, sender and receiver port logs, firewall denies, receive bitrate and decoded frames. Discovery on TCP 5959 is healthy, but the receiver's media connection range is blocked. Add a least-privilege rule for the documented mode and hosts, reconnect, and verify session establishment, sustained bitrate, advancing frames and clean audio. The source list alone is not the acceptance test.
Move through the failure in the same order as the connection
- Freeze identity. Record unique machine and source names, IPs, subnets and NDI versions.
- Confirm discovery mode. Choose local mDNS, Discovery Server or manual source addressing deliberately.
- Trace visibility. Observe queries, registration and a current discovered state.
- Trace the session. Record endpoints, transport and ports actually selected.
- Measure media. Check bitrate, packet loss, frame cadence, audio and rendered output.
- Retest change. Repeat after firewall, SDK, NIC, VLAN or Discovery Server updates.
NDI network ports and discovery FAQ
Which port does NDI discovery use?
Local mDNS uses UDP 5353. The NDI Discovery Server uses TCP 5959 by default, although its listening port can be changed.
Why can I see an NDI source but not its video?
Discovery and media are separate. The source may register correctly while the chosen media transport or port range is blocked.
Does mDNS work across subnets?
mDNS uses link-local multicast and normally stays within one LAN. Use an approved Discovery Server or manual addressing strategy for routed areas.
What can Callaba verify?
Callaba documents explicit NDI interfaces and Discovery Servers plus synchronized device visibility and current discovered state. Packet and firewall diagnosis remains a separate network check.