Setting Up an NDI® Discovery Server

This section explains how to deploy and configure an NDI® Discovery Server on your network infrastructure. If you only need to configure Laika to use an existing discovery server, see Discovery Server Config instead.

What is an NDI® Discovery Server

An NDI® Discovery Server is a network service that facilitates source discovery across routed networks, VLANs, and subnets where multicast DNS (mDNS) isn’t available or practical.

Why you need one:

In large broadcast facilities with segmented networks, traditional mDNS discovery doesn’t cross subnet boundaries. A discovery server acts as a central registry where:

• NDI® senders register their availability
• NDI® receivers query for available sources
• Source information is bridged across network segments

The discovery server doesn’t transport video — it only handles source registration and discovery queries.

When to Deploy a Discovery Server

Deploy discovery servers when:

• Your facility uses multiple subnets or VLANs for network segmentation
• Routers between production and monitoring networks don’t forward multicast traffic
• Network spans multiple physical locations (different buildings, floors, or racks)
• IT policy prohibits multicast DNS on production networks
• You need centralized control over NDI® source visibility
• You’re operating in cloud or hybrid infrastructure where multicast isn’t available

You don’t need discovery servers when:

• All NDI® equipment is on a single flat network (same subnet)
• Network switches properly handle and forward multicast traffic
• Small installations with fewer than 10 devices on the same broadcast domain

Discovery Server Options

Official NDI® Tools Discovery Server:

Vizrt provides the official NDI® Tools package which includes Discovery Server software. This is the recommended solution for most facilities.

Download: Visit ndi.tv → NDI® Tools → Download for your platform (Windows, macOS, Linux)

Installation:

1. Install NDI® Tools on a server with visibility to all network segments where NDI® traffic exists
2. Enable the Discovery Server service during installation
3. Configure firewall rules to allow port 5959 (TCP/UDP)
4. Note the server’s IP address for receiver configuration

Third-Party Solutions:

Some facilities use custom discovery server implementations or integrate discovery into existing network infrastructure (Dante controllers, routing systems). These must implement the NDI® discovery protocol correctly to work with standard NDI® receivers like Laika.

Server Placement

Network Location:

Place discovery servers on network segments with routing visibility to:

• All subnets where NDI® senders exist
• All subnets where NDI® receivers exist
• Preferably in a core network location (not edge switches)

Redundancy:

For mission-critical facilities, deploy multiple discovery servers:

• Primary server on primary network segment
• Secondary server on backup network segment
• Configure receivers with both server addresses (comma-separated)

If one server fails, receivers fall back to the secondary automatically.

Performance Considerations:

Discovery servers use minimal resources:

• CPU: < 1% on modern systems
• RAM: < 100 MB
• Network: < 1 Mbps (discovery queries are lightweight)

A modest server can handle hundreds of NDI® sources and receivers.

Firewall Configuration

Required ports:

• TCP 5959: Primary discovery protocol port
• UDP 5959: Alternative discovery protocol port

Firewall rules required:

Allow inbound traffic to discovery server on port 5959 from:

• All NDI® sender subnets
• All NDI® receiver subnets

Allow outbound traffic from discovery server on port 5959 to:

• All NDI® sender subnets
• All NDI® receiver subnets

Testing connectivity:

From sender/receiver workstations:

telnet discovery-server-ip 5959

If connection succeeds, firewall rules are correct. If connection fails or times out, investigate firewall configuration.

Configuring NDI® Senders

For sources to register with discovery servers:

Most NDI® software and hardware supports discovery server configuration. Methods vary by manufacturer:

Via ndi-config.v1.json:

Create or edit the configuration file:

• Windows: C:\ProgramData\NDI\ndi-config.v1.json
• macOS/Linux: ~/.ndi/ndi-config.v1.json

Add discovery server addresses:

{
  "ndi": {
    "networks": {
      "discovery": "192.168.1.50:5959,192.168.1.51:5959"
    }
  }
}

Via application settings:

Some NDI® applications (vMix, OBS Studio with NDI® plugin, Wirecast, TriCaster) provide UI for setting discovery server addresses. Check the application’s network or NDI® configuration section.

Via command-line parameters:

Some software accepts discovery server addresses as command-line arguments. Consult vendor documentation.

Configuring NDI® Receivers

For Laika:

Menu → Sources → Discovery Server Config
Enter discovery server addresses.

See Discovery Server Config for detailed Laika configuration.

For other receivers:

Configuration varies by product:

• vMix: Settings → Network → NDI® Discovery Servers
• OBS Studio: NDI® plugin settings
• Hardware receivers: Web interface or front panel configuration

Consult vendor documentation for specific configuration steps.

Verifying Discovery Server Operation

From the discovery server:

Check server logs for registration messages. Most discovery servers log:

• Source registration events (when senders connect)
• Query events (when receivers request source lists)
• Connection failures

Log locations vary by implementation but are typically in:

• Windows: C:\ProgramData\NDI\logs\
• Linux/macOS: /var/log/ndi/ or system journal

From receivers:

Launch Laika, configure the discovery server address, and refresh sources. If sources appear within 5-10 seconds, the discovery server is working correctly.

From senders:

Check sender logs or status displays for “Registered with discovery server” messages. If registration fails, investigate network connectivity or firewall rules between sender and discovery server.

Discovery Server Maintenance

Monitoring:

Check discovery server health regularly:

• Verify service is running (systemd status, Windows Service Manager, etc.)
• Monitor CPU/RAM usage (should be minimal)
• Review logs for registration failures or query errors
• Confirm network connectivity from all sender/receiver subnets

Updates:

Keep discovery server software updated:

• NDI® Tools package releases include discovery server updates
• Check ndi.tv quarterly for new versions
• Test updates on secondary server before deploying to primary

Backup Configuration:

Document and back up:

• Discovery server IP addresses
• Firewall rule configurations
• ndi-config.v1.json files for senders and receivers
• Network topology diagrams showing discovery server placement

Troubleshooting Discovery Servers

Sources don’t register:

1. Verify senders are configured with correct discovery server IP
2. Check firewall rules on both sender and discovery server
3. Confirm network routing exists between sender subnet and discovery server
4. Review discovery server logs for connection attempts

Receivers see no sources:

1. Verify receiver is configured with correct discovery server IP
2. Check firewall rules on both receiver and discovery server
3. Confirm sources are actually registered (check discovery server logs)
4. Test discovery server connectivity from receiver (telnet port 5959)

Intermittent source disappearance:

1. Check discovery server uptime and stability
2. Review network for packet loss or link flapping
3. Verify discovery server isn’t overloaded (CPU/RAM/network)
4. Increase discovery retry intervals on senders if available

High latency during discovery:

1. Discovery should complete in 2-5 seconds — longer indicates issues
2. Check network latency between receiver and discovery server (ping times)
3. Verify discovery server isn’t saturated with queries
4. Consider deploying additional discovery servers in remote subnets

Best Practices

Centralized Management:

Maintain a master document listing:

• All discovery server IP addresses
• Which subnets/VLANs they serve
• Firewall rules required
• Contact information for network engineering support

Standardized Configuration:

Use consistent ndi-config.v1.json files across all senders and receivers in your facility. Store templates in version control or facility documentation for rapid deployment.

Redundancy Planning:

Always deploy at least two discovery servers for production facilities. Configure all senders and receivers with both addresses. Single points of failure are unacceptable in broadcast environments.

Change Management:

Before changing discovery server IPs or network topology:

1. Notify all operators minimum 48 hours in advance
2. Update configurations during maintenance windows only
3. Test thoroughly before returning to live operations
4. Keep old configuration documented for emergency rollback

Security Considerations:

Discovery servers don’t transport video, but they do expose source information:

• Filter discovery server access via firewall rules (allow only known sender/receiver subnets)
• Don’t expose discovery servers to Internet
• Use NDI® groups to segregate sensitive sources if required

Alternative: NDI® Bridge

For facilities that can’t deploy dedicated discovery servers, NDI® Bridge provides an alternative for cross-subnet connectivity. Bridge creates point-to-point connections between network segments and includes integrated discovery.

Check NDI® Bridge documentation for deployment in complex network environments.

---