Discovery Protocols for AV — mDNS, Bonjour, ARP, SSDP

Before an AV system can route audio, stream video, or send a control command, devices need to find each other on the network. Discovery protocols handle this automatically — without them, every IP address and port would need to be manually configured. Understanding how discovery works explains why devices appear (or don't appear) in Dante Controller, why NDI sources vanish on routed networks, and how to design networks that make discovery reliable.

ARP — Address Resolution Protocol

ARP (Address Resolution Protocol) is the most fundamental discovery mechanism on Ethernet networks. It translates IP addresses to MAC addresses, which switches need to actually deliver frames.

How it works:

1. Device A wants to send data to 10.10.1.50 but doesn't know its MAC address
2. Device A broadcasts an ARP Request: "Who has 10.10.1.50? Tell 10.10.1.10"
3. Device B (10.10.1.50) replies directly: "I'm 10.10.1.50, my MAC is aa:bb:cc:dd:ee:ff"
4. Device A caches this mapping in its ARP table and sends the frame

ARP operates at Layer 2 and is confined to a single subnet. It's the reason AV devices on different VLANs can't directly discover each other — ARP broadcasts don't cross VLAN boundaries. Inter-VLAN communication requires a Layer 3 router to forward packets, and devices on different subnets use the router's MAC address (their default gateway) to forward traffic.

ARP in AV troubleshooting: If a Dante or control system device is unreachable by IP ping but appears in the switch's MAC address table, the ARP table on the workstation is the first thing to check. A stale ARP entry for a device that has changed IP addresses will cause packets to go to the wrong destination.

mDNS — Multicast DNS

mDNS (Multicast DNS, RFC 6762) allows devices to resolve hostnames to IP addresses on a local network without a DNS server. Devices broadcast their own hostname and service information using DNS-format messages sent to the multicast address 224.0.0.251 (UDP port 5353).

mDNS is the discovery backbone for Dante, NDI, and many modern AV protocols:

• Dante uses mDNS to announce device names and capabilities. When Dante Controller opens, it sends mDNS queries to discover all Dante devices on the network. Each Dante device responds with its name, IP, and available channels.
• NDI uses mDNS to announce video sources. NewTek NDI Tools and compatible applications discover NDI sources automatically on the local network via mDNS.
• AirPlay (used in some AV presentation systems) uses mDNS for source discovery.

mDNS and VLANs: mDNS is link-local — it's limited to the local Layer 2 segment. mDNS packets do not cross VLAN boundaries or routers. This is why Dante Controller on VLAN 10 cannot discover Dante devices on VLAN 20, even if inter-VLAN routing is configured. The devices may be able to ping each other, but mDNS discovery fails because the multicast announcement never reaches the other VLAN.

Solutions for cross-VLAN mDNS:

• mDNS repeater / proxy — software or appliance that forwards mDNS between VLANs (Avahi on Linux, dedicated hardware proxies)
• Dante Domain Manager (DDM) — Audinate's enterprise management platform that replaces mDNS discovery with a centralized controller, enabling Dante across routed networks
• Flat single VLAN for AV — keeps all AV devices on one Layer 2 segment, avoiding the cross-VLAN problem entirely

Bonjour (Apple mDNS Implementation)

Bonjour is Apple's implementation of mDNS + DNS-SD (DNS Service Discovery). It's the same protocol as mDNS but with Apple-specific service types. Many AV devices and software applications use Bonjour/mDNS interchangeably — the underlying protocol is identical.

Bonjour announces services using _service._tcp.local or _service._udp.local naming conventions. For example:

• Dante devices advertise _netaudio-arc._udp.local
• AirPlay advertises _airplay._tcp.local
• NDI advertises _ndi._tcp.local

DNS-SD (RFC 6763) works alongside mDNS to provide service discovery — not just name resolution but the discovery of specific service types. A device can query "give me all devices offering Dante audio service" and receive a list of all discovered Dante endpoints.

SSDP — Simple Service Discovery Protocol

SSDP (Simple Service Discovery Protocol) is part of the UPnP (Universal Plug and Play) standard. Devices announce themselves by multicasting SSDP:alive messages to 239.255.255.250 (UDP port 1900), and clients discover devices by sending M-SEARCH requests to the same multicast address.

AV uses for SSDP:

• DLNA media servers and renderers (digital signage, media distribution)
• Some IP control systems use SSDP for device discovery
• Smart displays and projectors with UPnP support
• Network-attached media players

SSDP is less common in professional AV than mDNS, but it appears in consumer-facing and prosumer AV products. Like mDNS, SSDP is link-local and doesn't cross VLAN boundaries without a proxy.

DNS-SD — DNS Service Discovery

DNS-SD (RFC 6763) is a method of using standard DNS queries to discover services on a network. When combined with mDNS, it enables zero-configuration service discovery. When combined with a unicast DNS server, it enables cross-subnet discovery — making it useful for enterprise AV deployments.

Dante Domain Manager uses DNS-SD (via a standard DNS server rather than mDNS) to provide device discovery across routed networks. This is how DDM solves the cross-VLAN Dante discovery problem: instead of relying on mDNS broadcasts, all Dante devices register themselves with a central DDM server, which maintains a directory of all devices regardless of VLAN or subnet.

WS-Discovery (Web Services Dynamic Discovery)

WS-Discovery is used by ONVIF-compliant IP cameras and video devices to announce themselves on the network. It sends multicast messages to 239.255.255.250 (UDP port 3702) that include device capabilities and service endpoints.

When an ONVIF-compatible VMS (Video Management System) or AV control system scans for cameras, it sends a WS-Discovery probe. Cameras respond with their device description and service URLs, which the management system uses to configure streams.

Like mDNS and SSDP, WS-Discovery is link-local. NVRs and AV systems managing cameras across VLANs may need IP-based camera scanning (by IP range) rather than relying on WS-Discovery.

Discovery Protocol Summary

Common Pitfalls

• Dante devices invisible across VLANs — The most common Dante discovery issue. Dante Controller uses mDNS, which is link-local. If your workstation and Dante devices are on different VLANs, you need an mDNS proxy or Dante Domain Manager. Routing alone doesn't solve this.
• NDI sources disappearing on routed networks — Same root cause as Dante. NDI discovery uses mDNS. Sources on a different VLAN won't appear in NDI Monitor. Solutions: keep NDI sources and receivers on the same VLAN, use an mDNS proxy, or use NDI's direct IP connection feature as a workaround.
• mDNS proxy on wireless networks — Consumer wireless access points often include mDNS proxy/repeater functionality between the wireless and wired networks. Enterprise APs may not forward mDNS by default. Check AP configuration if AirPlay or other mDNS-based features don't work on Wi-Fi.
• ARP table conflicts from IP reuse — When a device is removed and a new device is assigned its IP, other devices on the network may have the old MAC address cached in their ARP tables. Until ARP entries expire (typically 20 minutes), traffic goes to the wrong destination. Force an ARP refresh or clear the table on affected devices.
• Enabling UPnP on AV VLANs unnecessarily — SSDP/UPnP can expose device information and sometimes configuration interfaces. On professional AV networks, disable UPnP if it's not required by any devices in the system.