Dante vs AES67: Plan an Interoperable Audio Network

TL;DR — Dante is a complete commercial audio-networking platform; AES67 is an interoperability standard for compatible audio-over-IP streams. Supported Dante devices can exchange AES67 RTP multicast audio with non-Dante AES67 endpoints, but enabling the mode is only the start. The endpoints still need compatible audio formats, multicast addressing, PTPv2 clocking, network policy, and tested subscriptions. Keep native Dante for Dante-to-Dante routes unless the design specifically requires an AES67 boundary.

Dante and AES67 solve different-sized problems

Dante and AES67 are often compared as if they were two interchangeable products. They are not.

Dante provides device discovery, routing, clocking, monitoring, configuration, and media transport across a supported ecosystem. AES67 defines a common way for professional audio-over-IP systems to exchange uncompressed audio streams. It does not standardize every control, discovery, security, or management feature around those streams.

The practical question is therefore not “Which one wins?” It is “Where does the system need a standards-based audio boundary, and who owns every setting on that boundary?”

Use native Dante inside a Dante system

When both endpoints are Dante devices, they normally communicate using native Dante transport even if AES67 mode is enabled. Enabling AES67 does not convert every route into AES67 and does not improve an ordinary Dante-to-Dante subscription.

Use the native path when it already satisfies the production requirement. It preserves the expected Dante naming, routing, monitoring, and recovery workflow. Add AES67 when a compatible non-Dante endpoint must send or receive audio across a deliberately designed interface, such as a broadcast, installed AV, console, DSP, or recording boundary.

This distinction prevents a common mistake: changing a stable native network merely because every device offers an interoperability option.

Confirm that every endpoint supports the required mode

AES67 support is a device capability, not a guarantee attached to every network port. Before advancing the show, inventory:

• exact product and interface;
• installed firmware and Dante software version;
• supported RTP or AES67 mode;
• supported sample rates, channel count, and packet format;
• multicast address restrictions;
• PTPv2 clock options and domain behavior;
• whether changing mode requires a reboot;
• how the non-Dante endpoint advertises or accepts the stream.

In current Dante Controller versions, compatible devices expose RTP or AES67 configuration controls. Older products may have narrower address, flow, or clocking limits. Use the documentation for the deployed firmware rather than assuming that one successful device represents the entire fleet.

Treat the AES67 route as a defined multicast flow

AES67 interoperability uses RTP multicast flows. A transmitter creates a stream with an audio format, destination multicast address, UDP port, and timing behavior. The receiver must support those values and join the same stream.

Define the flow before creating subscriptions:

Some Dante implementations only receive AES67 flows within particular multicast ranges. A subscription may also look accepted while audio does not pass if the receiver's configured RTP prefix does not match the transmitted flow. Record the actual deployed requirements instead of copying a generic address example.

For the broader fanout decision, see Dante unicast versus multicast.

Build PTPv2 clocking as its own workstream

AES67 depends on PTPv2 timing. Native Dante networks have their own clock-election behavior, so an interoperable design must explicitly establish how the relevant devices reach a compatible PTPv2 reference.

Verify:

1. which device or clock is eligible to lead the AES67 timing domain;
2. the PTP version and domain number used by every participating endpoint;
3. whether the Dante devices use automatic or manual AES67 clock configuration;
4. whether any device bridges required timing behavior between native and AES67 sides;
5. DSCP and switch treatment for PTP event and general messages;
6. the effect of losing the leader, an uplink, or one endpoint.

Do not assume that visible devices share a usable clock. Discovery, control, and media timing are separate checks. The Dante clock leader guide explains native Dante election; the AES67 boundary still needs its own PTPv2 verification.

Keep multicast inside an intentional network scope

An AES67 stream is not a reason to flood every port. Map the VLAN and switch path, then configure multicast controls for that design.

A managed network may use IGMP snooping to send the stream only to ports with interested receivers, with one correctly placed querier maintaining membership. The exact policy belongs to the network owner. Confirm that PTPv2, discovery where required, and RTP multicast all reach the intended endpoints without leaking into unrelated production networks.

Also check link capacity in both directions. Multicast saves transmitter fanout, but every flow still consumes bandwidth on each link that carries it. The Dante network switch requirements guide covers link speed, QoS, EEE, counters, and acceptance testing.

Test interoperability from silence to recovery

1. Save the known native baseline

Export the current Dante configuration and record clock, routes, sample rates, names, addresses, and switch state. Protect working outputs before enabling a new RTP mode.

2. Configure one boundary at a time

Enable the required mode only on supported endpoints. Apply the agreed format, multicast prefix, latency, and PTPv2 settings. Allow any required reboot to finish before judging the result.

3. Create one identifiable test flow

Start with a small channel set and an unmistakable test source. Record its channel order, multicast address, port, and transmitter. Avoid creating several anonymous flows at once.

4. Subscribe and inspect every layer

Confirm the receiver joins the intended flow, locks to the correct clock, reports no errors, and produces the correct audio on the expected output. A routing indication alone is not proof of audible, correctly identified media.

5. Apply realistic load

Run the planned native Dante routes, AES67 streams, and representative shared traffic together. Watch clock status, latency, packet errors, link utilization, queues, and actual destinations.

6. Exercise failure and rollback

Remove and restore the source, receiver, clock leader, and relevant network link one at a time. Measure mute and recovery behavior. Finally, prove that the documented baseline can be restored without inventing settings.

Document the interoperability boundary

The Rider should include:

• the operational reason for using AES67;
• native Dante and AES67 endpoints by device, port, and channel;
• firmware and compatibility owner;
• audio format and channel order;
• RTP multicast address, port, and permitted range;
• PTPv2 leader, domain, priorities, and fallback;
• VLAN, switches, IGMP owner, QoS, and link capacity;
• receiver latency and acceptance evidence;
• reboot, failure, spare, and rollback procedures;
• the technician authorized to change each side.

Do not place passwords or sensitive network credentials in a public rider. Share those through the venue's approved secure channel.

The digital audio network tech rider guide shows how to place this boundary beside the rest of the show handoff.

Dante and AES67 checklist

• AES67 is required by a named non-Dante interoperability boundary.
• Every endpoint and firmware version supports the selected mode.
• Sample rate, encoding, channel order, multicast address, and port match.
• The PTPv2 source, domain, priority, and fallback are verified.
• Multicast scope, querier, QoS, EEE, and link capacity are approved.
• The route passes correct-audio, full-load, failure, and recovery tests.
• Native Dante routes remain documented and recoverable.
• The owner and rollback procedure are in the Rider.

Common mistakes

Treating AES67 as a complete control system. It standardizes an interoperable media path, not every discovery, routing, security, or monitoring behavior.

Enabling AES67 on every Dante device. Only enable and configure it where an approved non-Dante boundary requires it.

Checking the route but not the clock. A receiver can discover a stream yet fail to produce stable audio without compatible PTPv2 timing.

Copying multicast values blindly. Address ranges, prefixes, ports, and device support must match the actual endpoints and network plan.

Testing one stream on an idle switch. Acceptance must include the native routes, intended AES67 load, shared traffic, failures, and recovery.

FAQ

What is the difference between Dante and AES67?

Dante is a complete networked media platform with routing, discovery, clocking, monitoring, and device configuration. AES67 is a standard that lets compatible audio-over-IP systems exchange RTP audio streams.

Is Dante compatible with AES67?

Supported Dante devices can send and receive AES67 audio to and from compatible non-Dante AES67 devices. Compatibility depends on the device, firmware, audio format, multicast settings, and PTPv2 configuration.

Does AES67 use multicast?

AES67 interoperability commonly uses RTP multicast streams. The transmitter, receiver, switches, VLAN, multicast address, port, and IGMP policy must all fit the same plan.

Does AES67 require PTPv2?

Yes. AES67 uses PTPv2 for media clock synchronization. Participating endpoints must share a compatible PTPv2 configuration and timing path.

How do you test Dante and AES67 interoperability?

Verify capabilities and formats, configure PTPv2, create one known RTP multicast flow, confirm correct audio at the destination, then test full load, loss of clock and links, endpoint return, and rollback.

Keep the standards boundary recoverable

Store the approved endpoint map, RTP flow, clock plan, network scope, test evidence, and rollback beside the rest of the show documentation. In Techrider.live, keep it with the same Rider as the stage plot and input list, invite the responsible engineer to edit it, then save and inspect history before sharing the current version.