NDI operations, discovery, and network boundaries
Use NDI where it is strong—and make every handoff observable
NDI is a family of IP video technologies for moving video, audio, metadata, and control between compatible production systems. It is especially useful inside a managed studio, venue, campus, or cloud network where sources need to be discovered and routed without adding a dedicated SDI cable for every path. Its convenience does not remove network design: source visibility, bandwidth, interfaces, timing, and recovery still need named owners.
Where Callaba fits
Callaba provides NDI device discovery, NDI adapters, and NDI network configuration alongside SRT and RTMP ingest, Multiview, recording, restreaming, and playback. Operators can set the Callaba machine name, Discovery Server addresses, and network IPs from the authenticated dashboard. The same UI includes configuration import and a full editor for advanced NDI settings, so normal operations do not require editing a hidden host file in a terminal.
That UI access is governed by Callaba dashboard authentication and application roles. It is not a substitute for switch policy, VLANs, firewalls, network ACLs, or media encryption. NDI groups and Discovery Server boundaries can control discoverability; they should not be described as user authentication.
The slow scan illustrates a configuration review inside the Callaba UI; it is not a live discovery status indicator. Reduced-motion preferences freeze it in place.
Choose the transport for the network you actually have
NDI is often the right tool for source exchange inside a controlled production network. A public WAN is a different failure domain. Rather than assuming local multicast discovery and LAN behavior will extend across arbitrary internet paths, terminate remote contribution with a transport designed for that segment—commonly SRT—then expose or consume NDI at the managed production boundary.
| Environment | Primary concern | Useful starting pattern | Proof required |
|---|---|---|---|
| Single studio LAN | Bandwidth, interface selection, source naming, and predictable discovery. | NDI sources and receivers on reviewed production interfaces. | All expected sources appear under load and remain correctly identified. |
| Routed campus or cloud VPC | Discovery across subnets where mDNS may be unavailable or undesirable. | Explicit Discovery Server addresses plus selected network IPs. | The expected inventory returns after restart without unintended interfaces. |
| Remote venue over the internet | Loss, jitter, firewall traversal, and recovery over an unpredictable path. | SRT or another appropriate WAN contribution handoff, then NDI inside the destination network. | Media survives a controlled impairment and appears as the correct downstream source. |
| Mixed production and office network | Capacity contention and unintended visibility. | Segmentation, policy, selected Callaba interfaces, and an explicit source list. | Production load does not collapse during representative non-video traffic. |
Configure Callaba without treating the JSON editor as the first step
- Write the intended network boundary. List the production interfaces, Discovery Server addresses, expected source names, and systems that must receive them. Record the current configuration before changing anything.
- Open NDI Tools → NDI configuration. Set a recognizable machine name, add only the approved discovery addresses, and select the network IPs that should carry NDI traffic.
- Review the generated configuration. The import and live editor are useful for advanced settings, but a pasted configuration can alter more than one field. Compare it with the baseline and keep unrelated values unchanged.
- Save in a maintenance window. Callaba applies this configuration by restarting its ingress service. Treat active ingest and NDI work as interruptible, then wait for the service to settle before judging source availability.
- Refresh Discovered devices. Compare what Callaba sees with the expected inventory. A source count alone is insufficient; verify machine and source identity so a stale or duplicate name is not accepted.
- Build one NDI Adapter. Select a known source or output pattern, give it a production-friendly name, and verify it in the receiving tool before adding more adapters.
Three NDI workflows worth rehearsing
1. Local production sources into a browser-visible operation
Use when cameras, graphics, and a software mixer already exchange NDI on a managed LAN, but operators also need a clear acceptance view, recording, or a route outside that room. Configure Callaba on the approved interface, verify source discovery, select the required input, and use Multiview to confirm picture and audio before starting the next output.
2. Remote SRT contribution converted for an NDI production
Use when a venue cannot share the studio’s local discovery domain. Receive a verified SRT feed in Callaba, monitor its transport and decoded media, then create the supported adapter or restream output that makes it available to the intended NDI environment. Test the NDI receiver independently; the SRT socket proves contribution, not downstream discovery.
3. Browser participant made available to a production switcher
Use when one participant from a Callaba video call should become a separately named NDI source. Verify the participant in the browser room, select that participant in the applicable Restream or adapter workflow, create the NDI output, and discover it on the switcher side. Repeat for another participant only after audio, naming, sync, and participant lifecycle behavior pass.
Accept the system with observable evidence
Discovery
Expected sources appear after the configuration restart. Names map to the runbook, duplicates are explained, and unapproved interfaces are absent from Callaba’s configuration.
Media
Picture moves, every required audio channel is audible, and the downstream tool receives the expected format. A source listed by Discovery Server may still have a media fault.
Capacity
Repeat the test with the actual source count, graphics, monitoring stations, and ordinary background traffic. Record peak rather than idle behavior and keep measurable headroom.
Recovery
Restart one source, interrupt one route, and restore the last known configuration. Measure how long the operator needs to identify and recover the correct signal.
Troubleshoot the ownership boundary, not “NDI” as one box
If a source is missing, compare the configured interface, discovery address, source registration, and expected name before changing encoding. If a source is visible but will not play, inspect network reachability and the sender/receiver media session. If several sources degrade only under load, measure switching and uplink capacity with the complete scene. If a remote feed is unstable before it reaches the NDI network, repair or replace the WAN transport rather than tuning local discovery.
Keep time aligned across the hosts used for operational evidence. When Callaba, the switch, and the receiving application use different clocks, a short dropout can appear to have three unrelated causes.
Product controls first, API only after the inventory is trustworthy
Start with the Callaba NDI product hub. Follow the NDI configuration guide, Discovered devices guide, and NDI adapters guide for operator actions. After one configuration survives restart and load testing, use the NDI configuration API and NDI adapters API for controlled repetition. Save and compare the complete object when automating; a partial-looking change may still restart active NDI processes.
Official NDI references
- NDI Discovery Server — centralized registration, unicast operation, groups, redundant servers, and configuration boundaries.
- Getting started with NDI Discovery — current Discovery and Access Manager workflow.
NDI tools and behavior evolve. Recheck the official documentation that matches the deployed NDI version, and keep the Callaba release plus the network baseline in the same acceptance record.
Start with one source whose name, network, and destination you can prove
Configure the Callaba NDI boundary in the UI, verify the source in Discovered devices, route it once, and observe it from a separate receiver. Scale only after that small chain survives restart and representative load.
