什么是 AES67？

AES67 的正式名称是“音频网络应用中的 AES 标准：高性能流式音频 over IP 互操作性”。AES 于 2013 年发布首版，并在产业实践积累了更多细节后发布 AES67-2018 修订版。它没有创建另一个封闭生态，而是规定不同厂商产品可以共同使用的音频传输与同步基础。

合规只是起点，并不是自动互通的承诺。设备还需要在采样率、打包时间、通道映射、媒体时钟和网络行为上保持一致。有些功能属于标准强制范围，有些则是厂商可选实现；采购文件应明确版本、配置和测试条件，而不是只写“支持 AES67”。

截至本次复核，AES67-2018 是许多产品和项目文件常引用的版本。由于标准可能继续发布修订、勘误或新版，正式冻结设计前仍应查阅 AES 官方标准目录，并以项目冻结时的有效版本为准。

标准规定的是选定的技术层，并不等同于完整的用户操作体验。

在 AES67 之前，Dante、RAVENNA、Livewire、Q-LAN 等平台都能在各自生态内完成低延迟、高可靠音频传输，但它们的传输封装、时钟假设、发现方式和控制模型并不相同。跨品牌直连往往需要桥接设备、格式转换或人工配置，项目一旦选定某个协议，整条信号链就容易随之锁定。

这种碎片化不仅是技术问题，也是采购和运维问题。用户可能无法把最合适的调音台、接口箱、功放或处理器组合在同一网络中，旧设备在新平台旁边也很难继续发挥作用。扩容、迁移和故障替换都需要先检查协议兼容性。

AES67 提供了一条受控的公共音频路径，让原生生态把选定流暴露给其他兼容系统。它不会消除厂商差异，也不会自动统一控制界面，但能让音频流跨越生态边界，从而降低系统级锁定风险。

AoIP 系统把采样音频封装成带有时间信息的 IP 数据包，通过网络发送，再由接收端重建连续音频。真正困难的不是搬运字节，而是在共享网络上保持采样相位、通道关系和播放连续性。网络平均带宽充足，并不代表实时音频一定稳定。

AES67 面向可管理的网络环境。交换机需要足够的缓冲、合理的组播控制和明确的服务质量策略。跨越路由或子网时，可以使用单播，也可以通过受控的组播路由扩展；每增加一个网络边界，就增加一层配置和监控要求。

PTP 提供设备之间的共同时间基准，采样率则定义媒体时钟。接收端既要恢复采样时刻，也要获得稳定的样本序列。丢包、抖动过大、PTP 不稳定或错误缓冲设置，都可能让系统出现断续、爆音或通道错位。

部署前应把网络设计视为音频系统的一部分，而不是附带基础设施。VLAN、QoS、PTP 域、组播查询器和交换机缓冲策略需要一起验证。对于关键节目通路，还应明确故障时的降级模式、告警路径和恢复时间。

• 采样把模拟音频转换为按固定时间间隔取得的数值。
• 打包过程加入序号、时间戳和载荷信息，便于接收端重建流。
• 接收缓冲可以吸收网络抖动，但会增加端到端延迟。
• 同步让不同设备共享同一个时间参考。

AES67 使用 IEEE 1588-2008，也就是常见的 PTPv2，来分发精确时间。PTP 报文通过时间戳和路径延迟测量，让设备建立共同时间轴。音频发送端和接收端因此可以按同一时刻放置样本，而不是仅依赖各自本地晶振。

RTP 由 RFC 3550 定义，负责承载音频载荷，并通过序号和时间戳帮助接收端识别丢包、乱序和播放时刻。RTCP 可提供接收统计，但具体监控方式取决于产品实现。RTP 本身不等于 AES67，AES67 对可用的媒体格式、时钟和参数组合另有约束。

SDP 用来描述会话。它可能包含媒体类型、IP 地址、端口、载荷格式、打包时间、通道映射等参数。有些系统直接交换 SDP，有些通过发现或管理服务传递。由于 AES67 没有规定唯一控制协议，SDP 如何产生、分发和更新，是集成设计中最容易产生差异的部分之一。

PTP、RTP 和 SDP 是 AES67 使用的标准基础，不是可选的市场标签。

AES67 使用线性 PCM，使接收端不必依赖某种专有编解码器即可互通。常见格式包括 16-bit 和 24-bit PCM，对应 L16、L24 等 RTP 载荷类型。双方必须对采样率、打包时间、载荷类型、通道数量和通道顺序达成一致。

QoS 的关键不是给音频无限制带宽，而是让 PTP 和 RTP 能在网络繁忙时获得稳定、低抖动的处理。DSCP 标记和队列策略可以区分实时媒体、普通办公流量和大文件传输。VLAN 能帮助隔离流量，但不能代替队列设计、拥塞管理和监控。

multicast 让一个发送端向多个接收端分发同一流，避免为每个接收者重复发送。但它也带来风险：IGMP snooping 配置错误、缺少查询器、地址规划混乱或组播泛洪，都可能影响整网。大型项目应在调试前规划地址段、查询器位置、组播组上限和 PTP 域。

上线后需要持续观察丢包、抖动、PTP 偏差、IGMP 状态和交换机队列。许多互通问题并不会表现为完全无声，而是偶发断续、左右声道错位、重启后无法恢复或在负载升高时出现异常。可观测性应与音频通路一起设计。

• 为媒体流量预留容量和队列预算。
• 使用文档化的组播地址规划。
• 核对所有交换机的 PTP 域与优先级设置。
• 部署后持续监控丢包、抖动、时钟偏移和 IGMP 状态。

AES67 没有规定唯一的自动设备发现方式。产品可能使用 SAP 公告、mDNS/Bonjour、原生控制器、手工 SDP，或上层编排系统。一台设备即使支持 AES67，也可能仍需要厂商软件完成连接参数配置，因此不能把“支持标准”理解为“所有操作都能自动完成”。

标准也没有规定统一的连接管理、命名、权限、固件更新、日志和监控接口。路由权限、设备身份、访问控制和告警策略通常由产品生态或上层管理系统负责。这是为什么大型 AES67 系统往往需要控制器或管理平台，而不是只依靠音频流协议。

冗余同样不属于 AES67 的统一定义。流复制、无缝切换、双路径和故障检测通常由原生平台或周围网络方案提供。AES67 可以解决流和同步的基础问题，但无法自动保证链路故障时节目不中断。

此外，AES67 不会把不同设备的所有高级功能变成通用功能。增益、预设、表头、静音、设备状态和固件管理仍然可能留在原生控制域中。项目设计必须明确哪些能力跨边界，哪些能力留在原系统。

Dante 是 Audinate 的专有音频网络技术。Dante AES67 interoperability 通常通过设备模式或配置实现，让选定的 Dante 流与外部 AES67 设备交换音频。原生的 Dante 设备发现、订阅、路由和管理仍属于 Dante 生态，因此跨边界连接可能仍需要 Dante Controller 等 Audinate 工具。

RAVENNA 是围绕标准 IP 协议构建的开放技术平台，与 AES67 和 SMPTE ST 2110-30 有明确对齐。RAVENNA 还可以提供超出 AES67 最低互通范围的高通道数、更多媒体格式、冗余模型和同步配置。可以把 AES67 看作 RAVENNA 部署中的一个公共层，而不是 RAVENNA 全部能力的同义词。

混合系统在现场非常常见。例如保留 Dante 的接口箱、功放和调音台，同时通过 AES67 连接广播核心、RAVENNA 制作系统或第三方处理器。此时应明确哪些端点是原生模式，哪些进入互通模式，SDP 在哪里交换，PTP 和组播策略由谁负责。

最容易出问题的往往不是音频能否发送，而是边界维护。固件升级、设备重启、时钟主备切换或网络故障后，双方是否仍能恢复连接，是否有统一告警，是否有明确的维护流程，都需要在项目中提前定义。

互通模式是系统设计选择，不会抹平原生功能差异。

先从信号与时钟清单开始。记录每个流的发送端、接收端、方向、采样率、打包时间、通道数、组播地址、源地址和备用路径，并决定使用单播还是组播，以及 SDP 如何生成、交换和保存。

PTP 规划应在增加端点前完成。明确哪些设备可担任主时钟，网络中有无边界时钟或透明时钟，主时钟消失后如何切换，是否具备稳定保持能力。测试时应使用与现场一致的交换机配置和负载，而不是在空网络上确认同步灯变绿。

系统联调不能只看单台设备演示。应验证通道映射、增益、样本对齐、链路故障后的恢复、组播加入和离开、管理可见性，以及不同固件版本混合运行的结果。还要覆盖主时钟重启、接收端掉线、上行拥塞等边界场景。

调试完成后应留下可追溯资料，包括交换机配置、PTP 日志、流记录、测试结果和维护责任人。AES67 降低了传输协议的不确定性，但不能替代专业网络工程和变更管理。

AES67 常用于广播机构、礼拜场所、会议中心、体育场馆、演出场馆、录音棚和多建筑园区。它特别适合多厂商设备需要共享音频、既有 AoIP 系统需要接入新制作核心，或项目希望使用标准协议降低长期维护风险的情况。

第一个误解是“只要是 AES67 设备，就能用同一种方式控制”。实际上，音频流可能正常，设备发现、路由、命名和监控却彼此分离。第二个误解是把 AES67 当作音质等级或编解码器。它定义的是互通框架，实际音质取决于源、采样格式、时钟和网络质量。

第三个误解是把 AES67 与 ST 2110-30 当成完全相同的标准。两者关系紧密，但 AES67 是 AES 的音频互通标准，ST 2110-30 是 SMPTE 更广泛专业媒体 IP 制作体系中的受约束音频组成部分。项目中涉及 ST2110、NMOS、PTP 配置和一致性等级时，必须区分两者的角色。

最后，AES67 也不是“自动解决所有兼容性”的按钮。产品支持范围、可选项、许可证、固件状态、网络设计和运维流程都会影响结果。将边界写清楚，并进行端到端验收，比依赖徽标或宣传语更可靠。