Dante PTP v1 vs PTP v2: Keep Clock Domains Compatible

TL;DR — PTPv1 and PTPv2 are different timing protocols, not interchangeable labels. A Dante system may use different PTP behavior at a native Dante boundary and an AES67 interoperability boundary, depending on device and firmware support. Inventory every endpoint, identify each clock domain and approved bridge, verify the actual leader and follower states, then test audio through loss and recovery. Never assume that seeing a stream proves clock compatibility.

Start with the clock domain, not the stream

Precision Time Protocol distributes a shared time reference across a network. The protocol version is part of that timing boundary. Devices participating in different PTP versions do not automatically become one clock domain simply because they share a switch or can discover the same media stream.

Use the Dante clock leader guide for election fundamentals. This guide owns the version boundary and its acceptance test.

Understand PTPv1 and PTPv2 as separate protocols

PTPv1 and PTPv2 use different message formats and election behavior. Treat them as distinct timing systems unless the exact product documentation states that a device supports a deliberate boundary or interoperability mode.

Native Dante clocking and AES67 interoperability can have different requirements. Do not convert that general statement into a fixed rule for every product. Confirm the supported PTP mode, domain behavior, sample rate, and AES67 implementation for each device and firmware release.

Inventory the endpoints before configuration

1. Record every transmitter, receiver, switch path, firmware version, and enabled interoperability mode.
2. Mark the audio sample rate and supported PTP behavior for each endpoint.
3. Draw each clock domain separately, including its expected leader and followers.
4. Identify any device intended to participate in or bridge more than one timing context.
5. Verify that the proposed role is explicitly supported by current manufacturer documentation.
6. Save the healthy baseline: leader, follower states, offsets, subscriptions, events, and audible output.

Do not enable a second protocol mode on every device as an exploratory fix. Change only the documented boundary device and keep a rollback path.

Build one deliberate timing boundary

Name the leader in each domain

Write down the expected leader, alternate behavior, and preference settings for every domain. A bridge cannot compensate for two unstable elections.

Align the media format

Confirm the sender and receiver support the same sample rate, encoding, channel count, and interoperability mode. A clock-compatible receiver can still reject an unsupported payload.

Control the network scope

Map the VLANs, switch ports, multicast forwarding, and any routed boundary. Keep Dante primary and secondary networks separated according to the supported design. A PTP experiment must not join redundant paths or extend timing traffic unintentionally.

Verify the boundary in layers

Start with timing. Confirm the expected leader and stable followers on each side, then inspect offsets and events long enough to catch repeated elections or unlocks. Next confirm the media flow, channel mapping, and physical destination. Finally, send identifiable audio one channel at a time.

The AES67 flow setup guide covers the media workflow after timing support is established.

Test loss, recovery, and restart

1. Pass representative audio and capture the stable state on both sides.
2. Interrupt the approved boundary at one known point.
3. Record leader changes, follower unlocks, mute or artifact behavior, and event timestamps.
4. Restore the boundary and wait for stable clock recovery before judging audio.
5. Verify every subscription and critical physical output again.
6. Restart in the approved sequence and confirm the intended state persists.
7. Exercise the rollback so the crew can return to the native Dante baseline.

Do not describe recovery as seamless unless the exact deployed system demonstrated it under realistic load.

PTP boundary acceptance checklist

• Every device, firmware version, and supported PTP mode is recorded.
• Each clock domain has one expected leader and documented alternate behavior.
• Any bridge or interoperability role is supported by the manufacturer.
• Sample rate, encoding, channel count, and receiver mapping agree.
• VLAN and multicast scope carry timing only where intended.
• Followers remain stable and offsets are acceptable under production load.
• Identifiable audio reaches every critical physical destination.
• Loss, recovery, restart persistence, and rollback are proven.
• The owner and accepted evidence are attached to the handoff.

Document the timing handoff

Record devices, firmware, protocol modes, domains, leaders, preferences, network paths, media format, offsets, event evidence, audible results, failure behavior, restart sequence, owner, and rollback. Make the diagram distinguish timing domains from media flows.

Keep the accepted clock map beside the digital patch and input list in Techrider.live. Invite collaborators to edit the same rider, save the tested revision, inspect history, and export a current PDF for the venue, broadcast, or touring team.

FAQ

Does Dante use PTPv1 or PTPv2?

Dante timing behavior depends on the product, firmware, and operating mode. Native Dante and an AES67 interoperability boundary may use different PTP contexts, so confirm the actual device documentation and status rather than relying on a universal label.

Can PTPv1 and PTPv2 devices synchronize directly?

Do not assume so. They are different protocols. A supported device or architecture must deliberately handle the boundary; otherwise treat them as separate clock domains.

Why is an AES67 stream visible but not synchronized?

Discovery and media timing are separate. The receiver may see session information while using an incompatible PTP mode, lacking clock lock, or rejecting the selected media format.

Can one device bridge PTP clock domains?

Only when that exact device, firmware, and configuration explicitly support the role. Verify its behavior, leader state, format limitations, and failure recovery in the deployed system.

How do I test a Dante PTP boundary?

Confirm leaders and stable followers on both sides, pass identifiable audio, inspect offsets and events under load, interrupt one approved boundary, then prove recovery, restart persistence, and rollback.