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 184.108.40.206 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
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.
NDI Discovery works across subnets and also offers scope for lots of future developments. One important consideration with the NDI Discovery Server (apart from requiring NDI 4), is that once an NDI Sender is configured in NDI Access to talk to the Discovery Server it will *no longer use the mDNS discovery system* - that means an NDI Source connected to the Discovery Server will not be seen using mDNS by an NDI Receiver which is NOT also connected to the same Discovery Server. This is by design, since part of the Discovery Server's objective is to eliminate the mDNS flooding seen in extremely large NDI infrastructures.
There is currently no NDI Discovery Server to run on macOS (although Mac clients can still connect to one), but in addition to x86_64 versions for Windows and Linux, there are also versions of the Discovery Server available to run on ARM platforms like Raspberry PI, which might be a low cost and low energy always-on solution for modest NDI infrastructure.
Requires: TCP Port 5959
NDI Discovery combined with forcing NDI to use single TCP only communications can also allow you to control NDI traffic across NICs. By defining the discovery server at address 192.168.1.100, NDI Senders connecting to that discovery will advertise their sources on the 192.168.1.xxx range. When in single TCP mode, this means all receivers will connect to the source in this range and not use any other network ranges. This principle does NOT apply if you are enabling multiple different NDI protocols such as UDP Unicast, MultiTCP or rUDP.
NDI Discovery Method 4) NDI HX1 Discovery.
NDI HX1 is a means to an end - a bridge between native NDI Devices, and devices which were not originally designed as pure NDI, and which don't necessarily speak NDI natively. In some cases this can require other mechanisms to discover their existence. In most cases NDI Receivers will use a variation on the standard mDNS technique which sends out a different query, and where individual NDI HX devices may respond directly to the Receiver.
NB. Unlike NDI HX1, NDI HX2 uses the 3 standard NDI discovery techniques rather than this one.
Further Reading: review Newtek's own notes on NDI Access here: Introduction To NDI
Sienna's NDI core technologies support all flavours of NDI and all modes of discovery. Which method you use depends on your particular needs, and our network of Approved Sienna NDI Systems integrators can help you decide. Please let us know if you have any follow up questions, or you want to dig into the Sienna NDI Infrastructure product line and get on board with this unprecedented revolution in broadcast media infrastructure
** Subscribe to our Twitter feed for updates on new articles **