The Dante Port Map Is Now a Design Document

On 4 November Audinate updated the support article that lists every port, multicast group and server the Dante platform uses. It reads like an appendix for somebody debugging a silent channel, but it is better understood as a contract: the vocabulary that an AV designer and an IT security team have to agree on before a single audio flow crosses a switch. The list is specific enough to be useful. Native Dante audio is multicast to 239.255.0.0/16 on UDP 4321; AES67 audio, the interoperability path to other vendors, is multicast to 239.69.0.0/16 on UDP 5004. PTP clocking sits on 224.0.1.129 to 224.0.1.132, UDP 319 and 320. Discovery uses mDNS on 224.0.0.251, UDP 5353, and control and monitoring uses 224.0.0.230 to 233 on UDP 8700 to 8708. Unicast audio occupies UDP 14336 to 15359, and AES67 discovery uses SAP on 239.255.255.255, UDP 9875.

The first consequence is that a Dante network has two multicast ranges, not one. A design built only around 239.255.0.0/16 will carry native Dante perfectly and fail the moment an AES67 device from another manufacturer is added, because its RTP audio lands in a different group and its announcements arrive by SAP. That has to be planned before the first switch is configured: an IGMP querier in every VLAN that carries audio, an explicit note that multicast does not cross routers without a rendezvous point, and a documented decision about whether AES67 and native Dante share a VLAN. Sites that run one flat audio VLAN because it works in a two-room test discover the cost at two hundred flows.

The second consequence is that PTP is not optional traffic. Ports 319 and 320 carry the clock, and a firewall rule that treats them as ordinary UDP will either block audio entirely or, worse, let audio through while devices never lock, which presents as intermittent clicks that no amount of cable swapping fixes. Where Dante Domain Manager is in use, PTP also runs unicast, so the access list has to name the domain manager as a permitted peer rather than opening a group. The third consequence is where security baselines break audio. A rule that denies UDP above 1024 will kill both the unicast audio range and the FPGA-level flow keepalives on UDP 61440 to 61951. And a detail that surprises most IT teams: Dante AV video endpoints authenticate HDCP on TCP 16100 to 16131, a video-specific range that no generic AV firewall template contains.

There is a security reading too. A published, complete port list is also a complete enumeration of the surface, so the same document should drive the hardening plan: Dante on a dedicated VLAN, 802.1X on edge ports, no Dante on the guest network, and management interfaces that are not reachable from the audio subnet. Amtune's Dante and AES67 audio interfaces and Dante OEM modules are shipped with fixed, documented port behaviour precisely so that the network team can write a rule once and reuse it across projects, and the AES67 modular range lets a design add third-party interoperability without redesigning the multicast plan.