NDI Discovery and Registration

Sending and receiving video streams across an IP network requires applications supporting video to be able to discover receiving applications that are looking for video. NDI resolves host names to IP addresses over the local area network (LAN) and does so automatically. When you start an application that sends NDI, the devices that can receive NDI become aware instantaneously. While this is a typical function on almost all networks, there are some cases where it is important to know how this works in order to properly configure networks utilizing managed data flows and QoS protocols.

NDI utilizes mDNS (multicast Domain Name System)[1] to create the zero configuration environment for discovery. This service sends an IP multicast message that asks the host to identify itself. The target machine then multicasts a message that includes its own IP address. This multicast is seen by all NDI receiving machines on the subnet, which then use the information in that message to update their own caches. These multicast queries are sent to a multicast address and as a result, no single device is required to have global knowledge. When a service or device sees a query for any service it recognizes, it provides a DNS response with the information from its cache


[1] Apple’s mDNS is published as a standards track proposal (RFC 6762)


The primary benefits of using mDNS is that it requires little or no administration to set up. Unless the network is specifically configured to not allow mDNS, NDI sources will be discovered. This format works when no infrastructure is present and can span infrastructure failures.

The mDNS Ethernet frame is a multicast UDP packet that broadcasts to[1]:

  • MAC address 01:00:5E:00:00:FB(for IPv4) 
  • IPv4 address
  • UDP port 5353

Because mDNS uses a link-local multicast address, its capacity is limited to a single physical or logical LAN. If the networking reach needs to be extended to multiple subnets or to an environment consisting of many different networking technologies, an mDNS gateway is implemented. An mDNS gateway provides a transport for mDNS packets across Layer 3 boundaries by filtering, caching, and redistributing services from one Layer 3 domain to another. This is a process that is managed in Layer 3 capable networking switches (refer to documentation provided from the switch manufacturer).




Figure 1. Sample Networking Scenario. For example, if the mDNS gateway functionality is enabled on the router in this figure, then service information can be sent from one subnet to another and vice-versa. For example, the NDI discovery information being advertised in the network with IP address (left) is redistributed to the network with IP address (right) and learned by the mDNS-enabled hosts and devices in that network.


On Windows devices in particular, choosing the network location type is critical for the successful discovery and registration of NDI. Typically, the first time a Windows machine is connected to a network, a dialog window appears that allows the user to choose the network location type: Home, Work, Public, or Domain. By default, Windows sets a new network location to Public. This location is designed to keep machines from being visible and responding to broadcast pings. This location type also affects mDNS responses and, in turn, keeps NDI video streams from being discovered and registered on the network. For successful discovery and registration of NDI, network locations should be set to Work or Home.

The Domain network location is used for domain networks, such as those at enterprise workplaces. This type of network location is controlled by the network administrator and cannot be selected or changed. In this type of configuration, mDNS discovery must be allowed at the domain level.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Article is closed for comments.