Machine identity and discovery
Set the NDI machine name and reachable discovery-server addresses in dedicated fields.
NDI production control
Callaba NDI Server: discover, bridge, and monitor NDI
Callaba gives operators a visible NDI control layer for machine identity, discovery servers, network interfaces, configuration, adapters, Multiview, and downstream delivery. Use NDI inside the network boundary where it fits, and use a reviewed SRT path when media must cross an unpredictable WAN.
The dashboard keeps discovery and routing decisions visible; network design, bandwidth, firewall rules, and source compatibility still need to be validated in the real environment.
Product controls first
Operate the NDI layer without a terminal-first runbook
The normal path stays in the authenticated Callaba UI. Advanced automation is available after the network and product workflow have been proven.
Network interface addresses
Choose the explicit source IP addresses Callaba should bind instead of relying on an unknown host default.
Configuration import and live editor
Import reviewed JSON or text configuration, inspect it in the built-in editor, and save it from the dashboard.
Discovered sources and adapters
Inspect discovered devices, create the required adapter, start it, and verify its runtime state.
Access boundary
Dashboard authentication and API tokens control who changes Callaba settings. NDI groups do not replace network ACLs, segmentation, encryption, or firewall policy.
Technical specification
What the product supports, and what to verify
Supported behavior sits beside a practical acceptance check. The installed Callaba interface and the real source, destination, and infrastructure profile remain authoritative.
| Capability | Supported behavior | Acceptance check |
|---|---|---|
| Machine identity and discovery | Set the NDI machine name and reachable discovery-server addresses in dedicated fields. | Yes. Machine identity, discovery servers, interface addresses, configuration import, and the live editor are available in the dashboard. |
| Network interface addresses | Choose the explicit source IP addresses Callaba should bind instead of relying on an unknown host default. | The dashboard keeps discovery and routing decisions visible; network design, bandwidth, firewall rules, and source compatibility still need to be validated in the real environment. |
| Configuration import and live editor | Import reviewed JSON or text configuration, inspect it in the built-in editor, and save it from the dashboard. | Yes. Machine identity, discovery servers, interface addresses, configuration import, and the live editor are available in the dashboard. |
| Discovered sources and adapters | Inspect discovered devices, create the required adapter, start it, and verify its runtime state. | Start with one discovered source, verify it in Multiview, publish the required output, and only then add more adapters or API automation. |
| Access boundary | Dashboard authentication and API tokens control who changes Callaba settings. NDI groups do not replace network ACLs, segmentation, encryption, or firewall policy. | Callaba dashboard authentication and API tokens protect the product controls. Keep network ACLs and segmentation in place as a separate security layer. |
| One controlled boundary from source discovery to production output | The dashboard keeps discovery and routing decisions visible; network design, bandwidth, firewall rules, and source compatibility still need to be validated in the real environment. | No. Keep NDI discovery inside a designed network boundary. Use a WAN-suitable contribution path such as reviewed SRT when media must cross sites or public networks. |
Continue in the product
Set it up in Callaba. Then check the full path.
You have seen what the product does. These three guides take you into the exact controls, show what to connect next, and give you a practical check before the workflow goes live.
API is the second layer
Automate the exact NDI workflow you already validated
Use the released recipes to update configuration, inspect discovery, and publish an adapter. Keep operator approval and network policy outside the payload.
Cloud NDI and Callaba questions
Can Callaba configure NDI without editing host files in a terminal?
Yes. Machine identity, discovery servers, interface addresses, configuration import, and the live editor are available in the dashboard.
Does Callaba make local NDI discovery work automatically across the public internet?
No. Keep NDI discovery inside a designed network boundary. Use a WAN-suitable contribution path such as reviewed SRT when media must cross sites or public networks.
Can I control who changes the NDI configuration?
Callaba dashboard authentication and API tokens protect the product controls. Keep network ACLs and segmentation in place as a separate security layer.
Can the NDI workflow run in the cloud and self-hosted?
Yes. Choose cloud or Linux deployment based on network proximity, infrastructure ownership, storage, and operating requirements, then validate the same real sources.
Validate one real NDI path before expanding it
Start with one discovered source, verify it in Multiview, publish the required output, and only then add more adapters or API automation.
NDI feels effortless when every sender, receiver and operator shares a network built for media. Once discovery crosses subnets or several full-bandwidth feeds share a switch, automatic discovery is only the beginning of the design.
Media LANNDI sources and receivers
Known switches, addressing, discovery and bandwidth
Remote sideExplicit transport
SRT, RTMP or a deliberately engineered NDI path
See the network in Callaba before you route the source
NDI Discovered Devices shows the sources this Callaba host can see. NDI Adapters connect those sources to Callaba workflows. NDI Configuration stores the machine name, Discovery Server addresses, explicit source IPs and advanced settings.
After you can see and hear the intended source, place it in Multiview, send it to Recording, or attach a restream or conversion job. These jobs reuse the verified source; they do not turn discovery into proof that every output works.
Keep NDI where the network is observable
On a production LAN, NDI can carry picture, audio and metadata between cameras, switchers, graphics systems and software without a baseband cable for every route. That convenience still depends on reachability, predictable discovery, switches that can carry the traffic and receivers with enough sustained capacity.
Draw the actual path from sender to receiver. Mark every VLAN and routed boundary, estimate the number of simultaneous feeds and note whether the deployment uses full-bandwidth NDI, an HX variant or both. A long source list does not tell you how much traffic a receiver will request after it connects.
Choose how sources are discovered
mDNS on a local network
Automatic discovery works well when senders and receivers share a suitable LAN. It becomes harder to diagnose when sources appear across unintended segments or multicast behavior changes between switches.
Discovery Server for explicit registration
NDI documents the Discovery Server as a central source registry. Configured senders can avoid mDNS, which is useful across subnets and in cloud networks where multicast may be unavailable or undesirable.
A Discovery Server lists sources; it does not carry the media on their behalf. The sender and receiver still need a reachable path with enough capacity. Keep the registry address, groups and explicit source IPs beside the network diagram so another operator can explain why a source is visible.
Walk a remote feed in four steps
NDI is designed for production networks, not as a promise that an arbitrary public route will behave like a studio LAN. For a remote venue, decide where NDI ends and the contribution transport begins. That crossing might use SRT for recovery over an unpredictable path, RTMP for a compatible publisher, or a deliberately engineered NDI bridge.
01Name the source
Camera, programme, clean feed or return; include the machine and programme identity.
02Measure the LAN
Confirm discovery, the switch path, actual rate and the expected receiver count.
03Choose the crossing
Write down codec, transport, latency, authentication and who owns the remote endpoint.
04Watch the result
Check current picture, every required audio channel, sync and recovery after a disconnect.
Do not transcode by habit. Preserve the source when the receiving workflow can use it directly. Add a separate transcoding output only when the next system requires a different codec, resolution, frame rate or audio layout.
Discovery is not the final check
Open the feed on the surface the operator will use. Watch representative motion, listen to every required audio channel, check lip sync, colour, frame rate and source identity, then disconnect the sender long enough to exercise the expected recovery behavior.
Visible but wrong
A similarly named source can be selected successfully. Verify both machine name and programme identity.
Moving but silent
Video can pass while the intended audio pair or channel mapping does not. Listen instead of inferring audio from another meter.
Clean alone, broken together
One feed cannot certify a switch carrying the full show. Repeat with the expected concurrent source count.
Healthy until a route changes
A replacement switch port, VLAN rule or Discovery Server address can change visibility without touching the production application.
Move one cable and repeat the walk
Change one realistic condition: move a sender to its production switch port, restart the Discovery Server or interrupt the remote transport. Record which source disappeared, what the receiver reported and how long it took to restore picture and audio. A network diagram is useful when it predicts that behavior.
Primary references: NDI Discovery Server documentation and NDI-FIND discovery documentation.