Dante 与 AES67

AES67 是公开标准，目标是定义多个厂商都能实现的共同互通面，而不要求用户采用某一家公司的控制器、发现模式或产品体系。Dante 是由 Audinate 拥有和开发的商业技术生态，提供从设备发现、路由、时钟、管理、虚拟声卡到认证硬件的完整体验。

两种模式各有优势。标准组织可以建立持久公共层，但无法统一每个实现的用户体验；商业生态可以提供紧密集成的工具和更可预测的产品行为，但控制权属于技术所有者。

因此，Dante AES67 interoperability 应看作两种模式之间的会合点。Dante 设备可以按配置暴露选定 AES67 兼容流，其他系统也可能接收或发送这些流。但 Dante 生态中的其余流程仍然是 Dante 专有流程。

AES67 由 AES 标准工作体系维护。Dante 及相关名称、标识和技术规范由 Audinate 控制。产品支持 Dante AES67 不等于 Dante 被开源，也不意味着一个 AES67 实现自动成为 Dante 产品。

技术写作必须准确使用商标。Dante 只用于描述 Audinate 的技术，具体设备或模式应使用厂商官方名称。不要暗示 AES67 拥有 Dante，也不要把 Dante 当作 AoIP 的通用同义词。

Dante is a trademark of Audinate Pty Ltd. This page is an independent technical comparison.

商标说明是编辑背景，不替代对供应商最新条款的审阅。

原生 Dante 设备通常通过 Dante 控制生态被发现，并根据产品与部署使用 Dante Controller、Dante Director 等工具管理。用户可以在统一界面看到设备名、通道标签、订阅、时钟状态和诊断信息。

AES67 没有规定唯一发现或路由协议。当 Dante 进入 AES67 互通模式时，外部系统可能通过 SDP 或兼容发现机制看到音频流，但这不代表所有 Dante 功能都能在外部控制器中管理。

集成商应分别记录两层内容：跨 AES67 边界的音频流，以及仍由 Dante 原生工具完成的管理动作。混合系统图应显示 Dante 控制器、外部 AES67 设备或控制器，以及 SDP、组播地址、PTP 配置和通道映射的交换点。

Dante 使用自身时钟模型，并为原生流提供可配置延迟。AES67 模式可能需要不同的 packet time 或延迟，因为互通配置必须匹配外部设备。设计时应让边界两侧保持一致采样率、打包时间和时钟关系。

延迟不是一个单独数字。它包含打包、接收缓冲、设备处理、网络传输，以及原生模式和互通模式之间的转换。最可靠的比较是真实拓扑中的端到端测量，而不是数据表上的最低设置。

Dante 在自身生态内提供冗余选项，AES67 本身没有定义统一无缝保护机制。混合部署可能在 Dante 域内保留原生冗余，在 AES67 边界采用不同保护模型。这个边界的故障行为必须测试并记录。

PTP 对齐同样关键。Dante 与 AES67 设备可能需要共享时钟参考，或通过受控方式桥接时间域。PTP 规划不当，即使路由和带宽看似正常，音频也可能偶发断续。

原生 Dante 管理不只包括音频订阅，还包含设备命名、通道标签、时钟监控、固件流程、事件日志和 Audinate 软件或服务。AES67 互通模式不会自动把这些管理能力开放给第三方系统。

混合项目应明确各层责任：谁分配 Dante 设备名，谁管理 AES67 组播地址，谁监控 PTP，谁处理流消失告警，谁更新边界两侧固件。责任不清会显著延长故障恢复时间。

支持边界也应写明。厂商可能分别支持 Dante 设备、AES67 模式、网络配置和第三方控制器，却不承担整套系统责任。建立集成矩阵可以减少调试和运维中的责任争议。

Dante 产品参与 Audinate 的产品与认证体系，具体能力可能因设备类别、硬件、固件和许可证不同而变化。AES67 支持必须按型号和固件版本确认，不能只根据 Dante 品牌推断。

有效审查应回答五个问题：设备支持所需 AES67 方向吗？支持目标采样率和 packet time 吗？能提供所需通道数吗？时钟和冗余行为符合系统设计吗？厂商是否记录互通模式限制？

认证说明的是特定测试配置，而不是所有组合都会同样表现。项目资料应保存固件版本、配置导出、测试脚本和测量结果。

典型 Dante AES67 部署会为选定发送或接收流配置 AES67 兼容传输和时钟关系。这样可以让 Dante 网络连接非 Dante 处理器、广播设备、录音系统或其他支持相同互通配置的 AoIP 平台。

边界通常比原生工作流更窄。AES67 接收端不一定知道 Dante 设备名称、通道标签或订阅模型，可能只看到由 SDP 描述的 IP 流。反过来，Dante 控制器也可能无法管理外部接收端的全部属性。

某些功能在离开原生 Dante 模式后会变化。通道数可能降低，延迟选项受限，采样率受约束，冗余行为也可能不同。这些限制由具体实现决定，应查阅当前产品文档并实测。

最大的限制不一定是带宽，而是运维可见性。Dante 操作员可能看到原生网络正常，却不知道 AES67 交叉连接已经失败；AES67 控制器也可能只看到流，不知道 Dante 源端已进入原生降级状态。跨域监控因此非常重要。

组播设计是另一个风险。Dante、AES67 和周围网络可能采用不同地址分配、IGMP 行为和流密度习惯。计划应保留地址范围、限制组成员、确认每个 VLAN 的查询器行为。

最后，Dante AES67 连接不是所有格式和控制功能的万能转换器。它不会把非音频信号变成音频，不会替代采样率转换器，也不保证第三方设备能控制 Dante 产品。这些功能需要单独产品或管理集成。

当所有关键端点都属于 Dante 生态，项目又重视统一控制器、支持模型和原生功能时，纯 Dante 通常最简单。为了不需要的跨边界流引入 AES67，可能增加时钟、组播和测试负担。

当设施需要把 Dante 连接 RAVENNA、ST 2110-30 制作核心、第三方处理器或标准录音监控平台时，混合部署更合适。它也可用于迁移，让站点在不替换现有 Dante 网络的情况下引入新子系统。

核心问题不是抽象地比较纯 Dante 和混合，而是哪些流需要跨边界，以及每条流需要什么保证。少量低风险监听流可以接受简单桥接，直播节目通路则可能需要冗余网络、确定性时钟、监控和经过演练的故障流程。

清单首先记录流需求：方向、采样率、packet time、通道数、单播或组播，以及预期恢复行为。然后确认 Dante 型号、固件、许可证、互通模式、PTP 配置、冗余支持和监控可见性，并测试实际设备组合。

一个常见误解是“支持 AES67 后 Dante 设备就变得通用”。实际上，原生 Dante 仍是产品体验中心。另一个误解是 AES67 模式在所有型号上免费且完全一致。许可证、硬件、固件和产品类别都会影响可用性。

第三个误解是只把互通当作工程细节。它同时影响采购、运行、支持和培训。好的混合设计会给每个生态明确角色，并建立范围清晰、可测量、可维护的边界。

• 确认具体 Dante 型号和固件版本。
• 核对 AES67 方向、通道数和包格式。
• 记录 PTP 与时钟边界。
• 决定组播、冗余和监控方式。
• 在系统移交前测试故障恢复。