Sienna NDI Insider Know-How Series

with Mark Gilbert, CTO Gallery SIENNA

Part 2 - All about NDI Discovery

NDI Source Discovery

One of the best things about NDI (and a major differentiator from other IP Video protocols) is its auto-discovery system. All your NDI Devices find all the others automatically, without resorting to entering IP addresses and ports for every source and destination.

How does this work ?  Let's find out.

There are actually four different methods which can play a role here, for different types of workflow, so properly understanding them can help you make the right decision when designing your NDI Infrastructure.

NDI Discovery Method 1) DNS-SD

(Multicast DNS Service Discovery) / Bonjour / ZeroConf.

These are three different names for essentially the same thing.  This is the default mechanism used by NDI since version 1.0.

NDI Senders 'advertise' themselves on the network by emitting a multicast message which provides information about their IP address and port along with some other information. A DNS-SD Daemon on the other local computer systems caches this information, and the NDI Receiver software asks the local DNS-SD daemon for the list of known "_ndi._tcp." class services, which returns the known NDI Sources.  Similarly, an NDI sender can later announce that it's leaving the network and the DNS-SD Daemons will update their records.

In this way NDI Receivers can discover the existence and location of NDI Senders to present you with that user-friendly list of sources.

mDNS communications are typically via messages sent to multicast address 224.0.0.251 using UDP port 5353

DNS-SD works great, but has some caveats.  Specifically, multicast doesn't typically work well across subnets (zones of a network which are on different address ranges), so devices on different subnets often won't find each other, same goes for different instances on cloud based infrastructure.

Also, for very large and complex NDI systems with a huge number of mDNS messages sloshing around, sometimes you can run into other network traffic challenges.

Requires: UDP Port 5353

NDI Discovery Method 2) NDI Access

 (active polling).

This is the variation on discovery most people will have come across - it requires you to add a list of IP Addresses where you might find NDI Senders, into an application or file on the NDI Receiver machines. This is typically done using the NDI Access Manager application.  What this does is to allow NDI Receivers to issue an active query message over TCP to each potential NDI Sender device and ask for a list of NDI Sources which are on offer. This happens on TCP port 5960 and the Sender device (if it's present and awake) will reply with a list of any NDI Sources running on that IP address.

Note that where multiple different NDI Senders are on the same IP address (for example a computer running several different bits of software) - this will incidentally depend on mDNS *locally* within the machine which is used to gather the 'local' NDI list sent in reply to the original query. NDI Access works great, but it does involve entering every address into every machine which can be fiddly to maintain at scale.

Requires: TCP Port 5960

NDI Discovery Method 3) NDI Discovery Server

(or Directory Service).

This is the logical solution for larger scale NDI Infrastructure where mDNS may not be practical and NDI Access would be too much work.  Unlike 1) and 2) where there is no central store of NDI information, this method is based on running a dedicated application called "NewTek NDI Discovery Service" on Windows or "ndi-directory-service" on Linux. This software is designed to run 24/7 on a permanent server - it doesn't use much in the way of resources so doesn't need to be a powerful computer - but it must *always* be on, *always* reachable by your NDI Devices.

Running the server is only half of the setup - you also need to 'opt-in' all your NDI Devices to use the NDI Discovery server, by entering the Discovery server address into the NDI Access Manager application on each device. Note that NDI Discovery only works with NDI4 and newer, so this isn't an option for older NDI Based systems.

The NDI Discovery Server works by every NDI Source and every NDI receiver making a persistent socket connection to the server using TCP port 5959, and either announcing itself (sender), or constantly being informed of any changes in source availability (receiver). If an NDI Source is switched off, the connection to the Discovery Server will break, and the server informs all the connected receivers that the source is no longer available. Same deal when a new NDI source wakes up and connects to the Discovery Server.