Dante 和 AES67 有什么区别？如何规划可互通的音频网络

TL;DR — Dante 是完整的商业音频网络平台；AES67 是让兼容设备交换音频 over IP 流的互操作标准。支持的 Dante 设备可以与非 Dante 的 AES67 终端交换 AES67 RTP 组播音频，但启用该模式只是开始。终端仍然需要兼容的音频格式、组播地址、PTPv2 时钟同步、网络策略和经过测试的订阅。只要设计没有明确要求 AES67 边界，就尽量在 Dante-to-Dante 路由中保留原生 Dante。

Dante 和 AES67 解决的是不同规模的问题

Dante 和 AES67 经常被拿来比较，好像它们是两个可以互换的产品。其实不是。

Dante 提供设备发现、路由、时钟、监测、配置以及在受支持生态中的媒体传输。AES67 定义了一种让专业音频 over IP 系统交换无压缩音频流的通用方式。它并没有把这些音频流周边的所有控制、发现、安全或管理功能标准化。

因此，实际问题不是“哪个更强”，而是“系统需要在哪里设置一个基于标准的音频边界，以及这个边界上的每一个设置由谁负责”。

在 Dante 系统内部尽量使用原生 Dante

当两端都是 Dante 设备时，即使启用了 AES67 模式，它们通常还是会使用原生 Dante 传输。启用 AES67 并不会把所有路由都转换成 AES67，也不会改善普通的 Dante-to-Dante 订阅。

如果原生路径已经满足制作需求，就优先使用它。这样可以保留熟悉的 Dante 命名、路由、监测和恢复流程。只有当某个兼容的非 Dante 终端需要通过一个有意设计的接口发送或接收音频时，才添加 AES67，例如跨越广播、固定安装 AV、调音台、DSP 或录音边界。

这个区分可以避免一个常见错误：仅仅因为每台设备都提供了互操作选项，就去修改一个原本稳定的原生网络。

确认每个终端都支持所需模式

AES67 支持是设备能力，不是每个网络端口都自动附带的保证。在推进演出之前，请盘点：

• 具体产品和接口；
• 已安装的固件和 Dante 软件版本；
• 支持的 RTP 或 AES67 模式；
• 支持的采样率、声道数和封包格式；
• 组播地址限制；
• PTPv2 时钟选项和域行为；
• 切换模式是否需要重启；
• 非 Dante 终端如何声明或接收该流。

在当前版本的 Dante Controller 中，兼容设备会显示 RTP 或 AES67 配置控制。旧产品可能对地址、流或时钟有更窄的限制。请以已部署固件的文档为准，不要默认某一台设备成功就代表整套设备都适用。

将 AES67 路由视为一个明确的组播流

AES67 互操作使用 RTP 组播流。发送端会创建一个包含音频格式、目标组播地址、UDP 端口和时序行为的流。接收端必须支持这些值，并加入同一个流。

在创建订阅之前先定义这个流：

某些 Dante 实现只能在特定组播范围内接收 AES67 流。如果接收端配置的 RTP 前缀与发送流不匹配，订阅也可能显示已接受，但音频仍然不会通过。请记录实际部署要求，不要照搬通用地址示例。

关于更大范围的 fanout 决策，请参见 Dante 单播与组播。

把 PTPv2 时钟同步当作单独的工作流来做

AES67 依赖 PTPv2 时序。原生 Dante 网络有自己的时钟选举行为，因此互操作设计必须明确规定相关设备如何到达兼容的 PTPv2 参考时钟。

请验证：

1. 哪个设备或时钟有资格担任 AES67 时序域的主时钟；
2. 每个参与终端使用的 PTP 版本和域编号；
3. Dante 设备是否使用自动或手动的 AES67 时钟配置；
4. 是否有任何设备在原生侧和 AES67 侧之间桥接所需的时序行为；
5. PTP event message 和 general message 的 DSCP 以及交换机处理方式；
6. 失去主时钟、上联链路或某个终端时会发生什么。

不要假设可见设备就一定共享可用时钟。发现、控制和媒体时序是不同的检查项。 Dante 时钟主机指南 解释了原生 Dante 的选举方式；AES67 边界仍然需要单独的 PTPv2 验证。

让组播保持在有意设计的网络范围内

AES67 流并不是把所有端口都泛洪的理由。先规划 VLAN 和交换机路径，再为该设计配置组播控制。

受管网络可以使用 IGMP snooping，让流只发送到有接收需求的端口，同时由放在正确位置的 querier 维持成员关系。具体策略属于网络所有者。请确认 PTPv2、所需发现机制以及 RTP 组播都能到达目标终端，同时不会泄漏到无关的制作网络中。

还要检查双向链路容量。组播可以减少发送端 fanout，但每一条承载流量的链路仍然会消耗带宽。 Dante 网络交换机要求指南 涵盖链路速度、QoS、EEE、计数器和验收测试。

从静音到恢复，完整测试互操作性

1. 先保存已知的原生基线

导出当前 Dante 配置，并记录时钟、路由、采样率、名称、地址和交换机状态。在启用新的 RTP 模式之前，先保护正在工作的输出。

2. 一次只配置一个边界

仅在受支持的终端上启用所需模式。应用约定好的格式、组播前缀、延迟和 PTPv2 设置。如需重启，等重启完成后再判断结果。

3. 创建一个可识别的测试流

先从少量声道和一个明显可识别的测试源开始。记录它的声道顺序、组播地址、端口和发送端。避免一次创建多个匿名流。

4. 订阅并检查每一层

确认接收端加入了目标流，锁定到正确时钟，没有报错，并在预期输出端产生正确音频。仅凭路由指示并不能证明媒体已经被正确识别且可听。

5. 施加真实负载

让计划中的原生 Dante 路由、AES67 流和代表性的共享流量同时运行。观察时钟状态、延迟、丢包错误、链路利用率、队列和实际目的地。

6. 测试故障与回滚

一次只移除并恢复源、接收端、时钟主机和相关网络链路。测量静音和恢复行为。最后，确认文档化的基线能够恢复，而且不需要临时编造设置。

记录互操作边界

技术需求清单应包含：

• 使用 AES67 的业务原因；
• 原生 Dante 和 AES67 终端，按设备、端口和声道列出；
• 固件和兼容性负责人；
• 音频格式和声道顺序；
• RTP 组播地址、端口和允许范围；
• PTPv2 主时钟、域、优先级和回退方案；
• VLAN、交换机、IGMP 负责人、QoS 和链路容量；
• 接收端延迟和验收证据；
• 重启、故障、备用件和回滚流程；
• 被授权修改两侧配置的技术人员。

不要把密码或敏感网络凭据放进公开的技术需求清单。请通过场地方批准的安全渠道单独共享这些信息。

数字音频网络技术需求清单指南 演示了如何把这个边界与整场演出的交接资料一起整理。

Dante 和 AES67 检查清单

• 某个具名的非 Dante 互操作边界确实需要 AES67。
• 每个终端和固件版本都支持所选模式。
• 采样率、编码、声道顺序、组播地址和端口一致。
• PTPv2 源、域、优先级和回退都已验证。
• 组播范围、querier、QoS、EEE 和链路容量已获批准。
• 路由通过了正确音频、满负载、故障和恢复测试。
• 原生 Dante 路由仍然有文档并且可恢复。
• 负责人和回滚流程已写入技术需求清单。

常见错误

把 AES67 当成完整控制系统。 它标准化的是可互操作的媒体路径，而不是所有发现、路由、安全或监测行为。

在每台 Dante 设备上都启用 AES67。 只在经过批准的非 Dante 边界需要时才启用和配置它。

只检查路由，不检查时钟。 接收端可能发现一个流，但如果没有兼容的 PTPv2 时序，仍然无法输出稳定音频。

盲目复制组播值。 地址范围、前缀、端口和设备支持必须与实际终端和网络规划一致。

在空闲交换机上只测一条流。 验收必须包含原生路由、预期的 AES67 负载、共享流量、故障和恢复。

FAQ

Dante 和 AES67 有什么区别？

Dante 是完整的网络媒体平台，包含路由、发现、时钟、监测和设备配置。AES67 是一项标准，用于让兼容的 audio-over-IP 系统交换 RTP 音频流。

Dante 兼容 AES67 吗？

受支持的 Dante 设备可以与兼容的非 Dante AES67 设备互相发送和接收 AES67 音频。兼容性取决于设备、固件、音频格式、组播设置和 PTPv2 配置。

AES67 是否使用组播？

AES67 互操作通常使用 RTP 组播流。发送端、接收端、交换机、VLAN、组播地址、端口和 IGMP 策略都必须符合同一个方案。

AES67 是否需要 PTPv2？

是。AES67 使用 PTPv2 进行媒体时钟同步。参与终端必须共享兼容的 PTPv2 配置和时序路径。

如何测试 Dante 和 AES67 的互操作性？

先验证能力和格式，配置 PTPv2，创建一个已知的 RTP 组播流，确认目标端输出正确音频，然后测试满载、时钟和链路丢失、终端恢复以及回滚。

让标准边界保持可恢复

把已批准的终端映射、RTP 流、时钟方案、网络范围、测试证据和回滚计划，和其他演出文档一起存档。在 Techrider.live 中，把这些内容与同一份技术需求清单、舞台布局图和输入列表放在一起，邀请负责工程师编辑，然后在共享当前版本之前先保存并检查历史记录。