Dante Unicast Delay Requests：安全减少 PTP 多播流量
阅读约 7 分钟 · 更新于 2026年10月14日 · AV 网络工程师、系统技术员、前场（FOH）与监听工程师、广播操作员、场馆技术人员、系统集成商和制作经理
了解 Dante Unicast Delay Requests 的作用，确认 leader 兼容性，安全地为 follower 启用，并在代表性网络负载下验证时钟稳定性。
TL;DR — Dante 的 clock follower 通常使用 delay-request 消息来测量到 clock leader 的网络传输时间。在受支持的设备上，Unicast Delay Requests 会把这些消息直接发给 leader，而不是使用 multicast，这可以在大型网络中减少多播控制流量。请先确认当前和可能的 leader 都支持该功能，只在兼容的 follower 上启用，然后在验收前测试选主、同步、音频和故障恢复。
这个设置会改变什么
Dante 设备使用 Precision Time Protocol 时钟消息，让 follower 与被选中的 clock leader 对齐。delay request 帮助 follower 估算时钟消息穿过网络所需的时间。默认行为使用 multicast；可选设置会让 follower 通过 unicast 将其 delay request 直接发送给 leader。
| 设置 | 流量行为 | 运行结果 |
|---|---|---|
| 默认 delay request | follower 发送 multicast delay request | 兼容性简单，但随着 follower 数量增加，控制流量也会增长 |
| 启用 Unicast Delay Requests | 每个启用的 follower 直接向 leader 发送请求 | 当所有必需设备都支持时，可减少 multicast delay-request 流量 |
| 混合兼容网络 | 部分 follower 使用 unicast，其他保持 multicast | 在支持情况和 leader 行为都有文档记录时可以成立 |
| 不受支持的 leader 路径 | 启用的 follower 无法完成预期交换 | follower 可能无法同步 |
这个设置改变的是时钟控制传输方式。它不会把 Dante 音频流从 multicast 改成 unicast，不会替代 IGMP 配置，不会修复拥塞，也不会改变接收端音频 latency 设置。
判断网络是否需要它
如果网络规模较小、运行健康，并且在实测容量范围内，建议保持默认设置不变。当大量端点带来明显的 multicast 时钟控制流量，或者工程设计明确要求时，可以考虑 Unicast Delay Requests。
请从证据出发：盘点设备型号和固件，识别当前首选与已选中的 leader，测量 multicast 流量，并检查 clock 事件。不要因为“unicast”这个词听起来更高效，就盲目启用该选项。
Dante clock leader guide 解释了选主和外部时钟所有权。network health guide 解释了如何建立流量与时钟证据基线。
通过兼容性门槛后再启用
1. 盘点每一个可能的 leader 和 follower
记录设备型号、Dante 接口代际、固件、主/备角色、当前时钟状态，以及 Controller 是否显示 Unicast Delay Requests。不要只记录设置时可见的 leader，也要包括在故障后可能成为 leader 的设备。
2. 先证明 leader 支持
Audinate 的 Controller 指南说明，该功能只需要在 follower 上启用，但 clock leader 必须支持接收 unicast 请求。通过确认设备可用该选项，并查阅当前设备文档来验证支持性。如果某个可能的 leader 不支持该功能，要么让 follower 保持默认行为，要么设计并测试一种受支持的 leader 策略。
3. 对一组受控的 follower 进行修改
保存已知良好的配置和事件基线。在一小组、具有代表性的兼容 follower 上启用该设置。不要在同一测试窗口内同时修改 leader 优先级、QoS、布线、固件和 delay-request 模式。
4. 验证同步和音频
确认每个已修改的 follower 都锁定到预期 leader、保持稳定，并能通过可识别的音频。观察正常负载和峰值负载下的时钟状态、offset 历史、事件日志、数据包错误和 multicast 利用率。与基线对比结果，而不要只看一瞬间的绿色状态。
5. 测试选主与恢复
在已批准的边界条件下移除或禁用当前 leader。确认系统能够选出受支持的替代 leader，并且所有已启用的 follower 都能重新同步，而不会出现不可接受的静音或反复警告。恢复原始 leader，等待稳定后，在适用时对冗余 primary 和 secondary 路径重复测试。
排查故障模式
| 证据 | 可能问题 | 下一步受控检查 |
|---|---|---|
| 已更改的 follower 立即失去同步 | 当前 leader 可能不支持 unicast 请求 | 回退该 follower 组并验证 leader 能力 |
| 正常状态通过，但 leader failover 失败 | 某个可能的替代 leader 不兼容 | 单独测试每个可用 leader |
| 只有一台设备失败 | 固件、设备支持或本地路径不同 | 将其与同角色、已知良好的 follower 对比 |
| multicast 负载几乎没有变化 | delay request 不是流量中的主要部分 | 重新检查测量结果，必要时保持默认行为 |
| clock 警告持续存在 | 根因在时序或网络路径的其他位置 | 按照 clock 事件和 offset 证据继续排查 |
| secondary 网络表现不同 | 两条路径之间的支持、固件或拓扑不同 | 将两个网络分别作为独立故障域审计 |
不要通过提高音频 latency 来掩盖时钟不稳定。接收端 latency 只能保护媒体播放不受迟到音频包影响；它不能修复不兼容的 PTP 交换。
验收检查清单
- 已记录每一个当前和可能的 clock leader 的支持情况。
- 每个已修改的 follower 都有兼容的固件，并且界面中可见该设置。
- 已保存已知良好的配置和 clock 事件基线。
- 已修改的 follower 在代表性负载下保持锁定并稳定运行。
- 真实音频能送达每个关键目的地。
- 已测量修改前后的 multicast 利用率。
- leader 丢失、选主、恢复和冗余路径测试均通过。
- 具备回滚流程，且可恢复到之前的行为。
- 已记录负责人和已接受的设备清单。
如果测试产生警告或失锁，请先使用 Dante clock sync troubleshooting guide 再扩大变更范围。
记录时钟控制决策
记录为什么需要该选项、设备和固件盘点、已启用的 follower、符合条件的 leader、修改前后的利用率、clock 事件、offset 证据、failover 结果、负责人以及回滚点。未来的技术人员必须能够区分“有意的混合配置”和“未完成的部署”。
在 Techrider.live 中，请把这个决策放在数字音频网络说明和跳线表旁边。邀请系统工程师编辑同一份技术需求清单，保存已接受的修订，查看历史记录，并导出 PDF 供场馆或巡演交接使用。
FAQ
Dante 里的 Unicast Delay Requests 是什么？
它会让启用该功能的 clock follower 直接把 PTP delay-request 消息发送给 clock leader，而不是作为 multicast 发送。它影响的是时钟控制流量，而不是音频订阅的传输类型。
Dante 应该启用 Unicast Delay Requests 吗？
只有在实测规模或有文档记录的网络设计能证明该改动有必要，并且所有必需的 leader 和 follower 都兼容时，才应启用。健康的小型网络通常不需要额外配置。
哪些 Dante 设备需要启用 Unicast Delay Requests？
只有兼容的 follower 需要启用该选项。当前以及每一个可能的替代 clock leader 仍然必须支持接收这些请求。
Unicast Delay Requests 会不会导致 Dante 时钟不同步？
会。Audinate 提醒说，如果在 follower 上启用了该功能，而 clock leader 不支持它，可能会导致这些设备无法同步。
如何测试 Dante Unicast Delay Requests？
先建立网络基线，然后修改一小组 follower，在负载下验证时钟和音频，强制进行一次已批准的 leader 选举，测试恢复与冗余路径，最后把 multicast 利用率和事件证据与基线进行比较。