Understanding AES67 and Its Role in Modern Broadcast

The broadcast industry is undergoing a fundamental shift toward IP-based infrastructure, driven by the need for greater flexibility, scalability, and cost efficiency. As remote production and cloud-based audio workflows move from experimental to mainstream, a common challenge emerges: how to ensure seamless interoperability between the diverse range of audio-over-IP (AoIP) equipment, codecs, and software platforms in use today. The answer, for many broadcasters, is AES67.

AES67 is an audio-over-IP interoperability standard developed by the Audio Engineering Society. Published as AES67-2018, it provides a common transport layer that allows devices from different manufacturers—each with their own proprietary AoIP ecosystems (like Dante, Ravenna, or Q-LAN)—to exchange high-quality audio streams over standard IP networks. By defining required parameters for media clocking, synchronization, stream format, and transport, AES67 removes the barriers that once forced broadcasters into single-vendor solutions. For remote production and cloud workflows, this interoperability is not just convenient; it is essential.

The standard has gained widespread adoption because it addresses a pain point familiar to any engineer who has tried to connect a Dante-equipped mixing console to a RAVENNA-based codec. Before AES67, such a connection required expensive bridging hardware or proprietary gateways. Now, with proper configuration, devices from Audinate, Lawo, Merging Technologies, and others can pass audio directly. This has accelerated the adoption of IP-based workflows in environments where heterogeneous equipment is the norm rather than the exception.

Core Technical Components of AES67

To successfully implement AES67, engineers must understand its key technical pillars. The standard specifies the use of RTP (Real-time Transport Protocol) for audio payload delivery, typically carrying up to 8 channels of 24-bit, 48 kHz audio per stream. Synchronization relies on the IEEE 1588 Precision Time Protocol (PTP), using a profile derived from SMPTE ST 2059. This ensures low-jitter clocking and sample-accurate alignment across multiple devices—critical when handling live, time-sensitive audio in remote or distributed environments.

AES67 also mandates specific Quality of Service (QoS) parameters to prioritize audio traffic on congested networks. These include the use of DiffServ Code Points (DSCP) to mark packets, with recommended values for audio (typically EF or AF41) and control traffic. The standard defines acceptable latency limits as low as 1 millisecond for local area networks, making it suitable for live production where delay must be imperceptible.

The RTP payload format for AES67 uses the L24 audio coding scheme, which embeds linear PCM samples in 24-bit containers. Each RTP packet carries a fixed number of samples per channel, with the packet time typically set to 1 millisecond for low-latency applications. The standard also specifies how to handle redundant streams and packet loss concealment, though these mechanisms are optional and implementation-dependent.

Comparison with Other AoIP Standards

While AES67 is an interoperability layer, it is often confused with full-featured ecosystems like Dante or Ravenna. Dante (Audinate) is a complete networking platform with its own management software, automatic discovery, and routing capabilities; its recent AES67 mode allows devices to operate as AES67 endpoints. Ravenna, developed by Lawo and ALC NetX, is another IP audio solution that natively supports AES67 and RAVENNA-Generated PTP. ST 2110-30 (Audio, uncompressed PCM) extends these concepts for broadcast video workflows, using AES67 as its audio transport. Understanding these relationships helps broadcasters choose the right combination of technologies for their specific workflow.

A key distinction is that AES67 does not provide device discovery, connection management, or routing control. It is purely a transport and synchronization standard. For full workflow automation, broadcasters typically pair AES67 with NMOS (Networked Media Open Specifications) IS-04 and IS-05, which provide registry-based discovery and connection management. This separation of concerns allows engineers to mix and match components from different vendors while maintaining interoperability at the transport layer.

Implementing AES67 in Remote Production

Remote production—whether for sports, news, or live events—demands reliable, low-latency audio transport across distances that may span hundreds or thousands of kilometers. AES67 provides a standardized way to carry microphone feeds, intercom signals, and program audio over dedicated IP circuits or private WANs, often in conjunction with video sent via ST 2110 or compressed codecs (e.g., JPEG XS). The key is to maintain synchronization and low delay even when the network introduces real-world impairments.

Step-by-Step Implementation for Remote Sites

The following steps offer a practical guide for integrating AES67 into a remote production environment:

  • Assess equipment compatibility: Inventory all audio gear at both ends—mixing consoles, stageboxes, microphone preamps, codecs, intercom panels. Confirm AES67 support via native implementation or firmware upgrade. Devices without AES67 may require converters or gateway boxes (e.g., Dante to AES67 bridge). Some older devices may support AES67 only in a limited fashion, such as fixed stream parameters or restricted PTP profiles. Testing each device against the AES67 conformance matrix published by the AES is a prudent first step.
  • Design the IP network: Use managed switches with VLAN segmentation, IGMP snooping for multicast control, and adequate bandwidth. For a typical stereo stream (48 kHz, 24-bit), bandwidth is approximately 2.9 Mbps per channel; plan for headroom. For remote links, a dedicated MPLS circuit or bonded cellular with QoS guarantees is recommended over public internet due to jitter and packet loss. The network design must also account for the burst nature of RTP traffic: even though the average bitrate is predictable, packet sizes and inter-packet timing can vary based on PTP alignment and network congestion.
  • Configure Precision Time Protocol (PTP): Designate a grandmaster clock (e.g., using a GPS-disciplined oscillator or an AES67- / ST 2059-compliant master). Ensure all devices on the network are set to the same PTP domain (default 0 for AES67). Use boundary clocks or transparent clocks to limit PTP load on large networks. In remote production scenarios where the grandmaster is at a central location, the WAN path must be engineered to carry PTP messages with low delay variation; otherwise, slaves may lose lock or accumulate timing errors.
  • Set QoS and stream parameters: Mark all AES67 audio traffic with DSCP EF (46) or AF41 (34) at the switch and router levels. Configure multicast addresses (239.192.x.x style) and session descriptions (SDP) for each stream. Many devices generate SDP files automatically; these can be exchanged between remote locations via file transfer or API. The SDP contains all the parameters needed to decode the stream: IP address, port, payload type, sample rate, bit depth, channel count, and PTP timing information.
  • Interoperability testing: Before going live, conduct end-to-end tests using reference signals (e.g., 1 kHz tone, silence, program material). Measure latency between encode and decode points using a software tool or hardware comparator. Probe for packet loss, duplications, or timing slips. Check that PTP lock is maintained across reboots and network changes. It is also wise to test failover scenarios, such as a grandmaster clock failure or a network link outage, to ensure that audio streams continue without audible glitches.

Challenges in Remote AES67 Deployments

Remote production often introduces network conditions that differ from a controlled studio plant. WAN latency can exceed 50 ms, making sub-5 ms AES67 streams impossible without buffering. Packet loss on internet links causes dropouts unless forward error correction (FEC) or redundant streams are used. Some broadcasters opt for ST 2022-7 seamless redundancy across two diverse paths to protect against failure. Additionally, clock synchronization over WAN may require precise timing such as utilizing the White Rabbit extension to PTP, though this is still emerging in the broadcast space.

Another common challenge is the asymmetric nature of many WAN connections. While download bandwidth may be generous, upload capacity is often limited, and this can create bottlenecks when multiple audio streams need to be sent from a remote site to a central production hub. Engineers must carefully calculate the aggregate uplink bandwidth required and ensure that the connection can sustain it without packet loss. Bonded cellular or satellite links can provide additional capacity but introduce their own latency and jitter characteristics.

Integrating AES67 with Cloud-Based Audio Workflows

The advent of cloud production—where mixing, monitoring, and processing happen on virtual machines in data centers—adds another layer of complexity. AES67 streams, originally designed for real-time multicast on LANs, must be adapted for unicast transport across the public internet while maintaining low latency and clock accuracy. Cloud-based audio workflows demand software-based AES67 endpoints that can run on commodity servers, receive streams from on-premises decoders, and send processed audio back to the physical world.

Cloud Gateways and Virtualized Endpoints

Several vendors now offer software AES67 endpoints (e.g., Lawo's RAVENNA Virtual Sound Card, Merging's Anubis NTP, or hardware appliances like the Dante Domain Manager bridge). These devices convert AES67 streams into formats consumable by cloud processing applications (e.g., DAWs, automated mixing engines, or virtual routers). The workflow typically involves:

  • On-premises codec: Receives analog or digital audio and encodes to AES67/RTP over local LAN.
  • Edge gateway: Translates multicast to unicast, adds FEC, buffers to compensate for variable WAN latency, and applies encryption (e.g., AES-256 over SRTP). The edge gateway is often a dedicated hardware appliance or a hardened software instance running on a well-provisioned edge server.
  • Cloud receiver: A virtual machine running a low-latency audio driver that decodes the AES67 stream and presents audio to the cloud production engine (e.g., through ASIO or ALSA). The cloud receiver must be located in a data center with low-latency peering to the edge gateway; AWS Direct Connect or Azure ExpressRoute can provide dedicated, predictable connectivity.
  • Return path: Similar process in reverse, with the cloud output stream sent back to multiple remote locations. The return path often carries mixes, cues, and intercom signals, and must be synchronized with the forward path to avoid drift.

One emerging approach is to run the entire AES67 endpoint as a containerized microservice within the cloud, using technologies like Docker or Kubernetes. This allows broadcasters to scale endpoint instances dynamically based on production demand, spinning up additional receivers for large events and scaling down during quieter periods. Containerized endpoints also simplify software updates and version management across a fleet of cloud-based production resources.

Best Practices for Cloud Integration

  • Use dedicated compute resources: Cloud virtual machines must have deterministic network performance; choose instance types with network acceleration (e.g., AWS Elastic Network Adapter) and avoid shared tenancy for latency-critical work. Reserve CPU cores for real-time PTP and audio processing. Hyperthreading should be disabled on hosts running real-time audio workloads to prevent timing jitter from sibling threads.
  • Secure audio transport: By default, AES67 does not include encryption. In cloud workflows, always tunnel AES67 through a VPN or use SRTP (Secure RTP) to prevent eavesdropping and tampering. End-to-end authentication should be implemented using certificates or pre-shared keys. For high-security applications such as live news or sports betting, the encryption key management should follow a zero-trust model where each stream uses a unique, ephemeral key.
  • Monitor and adapt: Continuous monitoring of RTP jitter, sequence numbers, and PTP offset is crucial. Deploy network diagnostic agents at both ends; automatically increase buffer depth when jitter exceeds thresholds. Use cloud services like AWS CloudWatch or Azure Monitor to track audio stream health. Set up alerts for out-of-threshold conditions such as packet loss above 0.1% or PTP offset exceeding 1 microsecond.
  • Standardize on unicast: While AES67 natively supports multicast, cloud data centers typically lack multicast routing. Force all AES67 streams to unicast (single destination IP). This also simplifies firewall rules (UDP ports 5004, 5005 for RTP and RTCP). Some cloud providers offer multicast forwarding as a managed service, but this is usually limited to specific regions and incurs additional cost.
  • Plan for clock redundancy: In a cloud deployment, the PTP grandmaster can be a virtualized instance that uses a software clock disciplined by NTP or GNSS via a time-as-a-service API. However, virtualized clocks can drift under heavy CPU load. Deploy redundant grandmasters in different availability zones and use the Best Master Clock Algorithm (BMCA) to automatically fail over if the primary master becomes unreachable.

Addressing Synchronization Across the WAN

One of the most significant hurdles for cloud AES67 is maintaining PTP synchronization when the grandmaster clock is not reachable over unreliable WAN links. Common solutions include deploying a local grandmaster at each site that is disciplined by GNSS (e.g., GPS, Galileo), or using a software PTP slave that converges to a cloud-based master via the IEEE 1588 protocol with appropriate PTP profiles. Some production houses adopt a "loose sync" approach where AES67 streams are aligned to the same sample rate but not phase-locked, relying on sample-rate conversion at the cloud endpoint—though this can degrade quality if done repeatedly.

For broadcasters who require sample-accurate synchronization across continents, the White Rabbit extension to PTP offers sub-nanosecond accuracy over WAN. While White Rabbit is more common in scientific and financial applications, its use in broadcast is growing, especially for large-scale distributed productions where multiple remote sites contribute to a single live mix. The cost and complexity of White Rabbit hardware are still significant, but as the technology matures, it may become the default for high-end remote production.

Future-Proofing with AES67 and ST 2110

AES67 is not a static standard. It forms the audio foundation for the SMPTE ST 2110 suite, which brings video, audio, and ancillary data over IP. As broadcasters progress toward all-IP production, ST 2110-30 (audio) inherits AES67 exactly, meaning any investment in AES67 infrastructure today is fully compatible with future ST 2110 systems. Additionally, the AES67-2018 revision added support for higher sample rates (96 kHz) and improved redundancy handling. For those shifting to cloud, upcoming profiles such as NMOS (Networked Media Open Specifications) IS-04 and IS-05 promise to automate discovery and connection management of AES67 streams across on-premises and cloud environments.

The evolution of AES67 also intersects with emerging IP-based audio standards like AES72 (open control architecture for AoIP networks) and the AES's work on audio transport for immersive and object-based audio. As broadcasters adopt formats like Dolby Atmos and MPEG-H, the transport layer must handle multiple audio objects and metadata streams. AES67's flexible RTP payload format can accommodate these requirements, but engineers should verify that their chosen endpoints support the necessary payload types and channel counts.

Practical Industry Examples

Major broadcasters like the BBC and NBC Sports have deployed AES67 for remote commentary positions, enabling freelance talent to connect from home studios using Ravenna or Dante interfaces. Audio production for live e-sports events increasingly uses AES67 to link game audio consoles with cloud-based mixing software. In radio, AES67 is used in virtualized playout systems where audio is generated in data centers and delivered to transmitter sites via AoIP. These examples demonstrate the standard's versatility in real-world, high-pressure production contexts.

Another notable adoption is in live music streaming, where festivals and concert halls use AES67 to distribute multichannel audio to remote mixing engineers, allowing them to create broadcast mixes from anywhere in the world. The synchronization accuracy of PTP ensures that all instruments and vocal microphones remain in phase, even when the engineer is monitoring through cloud-based processing. This workflow has become particularly valuable for events with global audiences, where the production team may be distributed across multiple time zones.

Conclusion

AES67 has emerged as the indispensable bridge between disparate AoIP ecosystems, unlocking new possibilities for remote and cloud-based audio production. By mastering its technical requirements—PTP synchronization, QoS marking, SDP management, and network design—broadcasters can build flexible, interoperable audio workflows that scale from a single control room to a global cloud infrastructure. As the industry continues to move toward fully software-defined, IP-based production, AES67 provides a stable, future-proof foundation that will remain a cornerstone of professional audio transport for years to come.

For further reading, consult the AES67 standard document available from the Audio Engineering Society, the SMPTE ST 2110-30 specification for video-related audio, and vendor application notes such as Audinate's guide to configuring AES67 on Dante devices or Lawo's RAVENNA white papers. These resources offer deeper technical details for engineers planning their next AES67 deployment.