The transition from dedicated circuit-switched audio contribution systems to packet-switched IP networks represents one of the most significant shifts in broadcast engineering. For decades, remote news gathering relied on ISDN, POTS lines, or dedicated satellite links, each with inherent limitations in bandwidth, cost, or global reach. In the modern landscape, the standard for high-quality, low-latency audio transport is AES67. Far from being just another protocol, AES67 serves as the foundational interoperability layer that allows disparate audio-over-IP (AoIP) ecosystems to coexist and communicate. For news organizations operating in the field, understanding and implementing AES67 is no longer optional; it is a prerequisite for agile, high-fidelity remote production. This article provides a comprehensive technical and operational guide to deploying AES67 in remote news gathering scenarios, from the control room to the field.

From Analog and TDM to IP: The Evolution of Contribution Circuits

Before the widespread adoption of IP, broadcasters relied on circuit-switched technologies like ISDN (Integrated Services Digital Network) and dedicated T1/E1 lines for high-quality remote audio. These systems provided guaranteed bandwidth and low latency, but they were expensive, inflexible, and limited in geographic reach. A reporter deploying to a remote village or a conflict zone often could not get an ISDN line installed in time for the news cycle. The IP paradigm, utilizing AES67, solves this by separating the audio payload from the physical transport layer. If the reporter has internet access via cellular bonding, satellite, or a local fiber connection, they can establish a high-fidelity audio link. This transition has dramatically expanded the potential for live remote reporting, enabling news teams to cover breaking events from virtually anywhere with a network connection.

The economic impact is equally profound. ISDN tariffs in many countries made per-minute costs prohibitive for long-form interviews or continuous coverage. AES67 over a broadband connection reduces marginal costs to near zero, allowing news organizations to keep more live feeds open and bring more voices to air. This shift has democratized live contribution, allowing smaller stations to compete with networks with larger budgets.

The Interoperability Bottleneck in AoIP

Before AES67 gained widespread traction, the broadcast audio market was fragmented. Major players like Audinate (Dante), Wheatstone (Livewire), and the RAVENNA alliance developed robust, feature-rich ecosystems. However, these systems were largely proprietary islands. A remote truck equipped with a Dante-based console could not natively receive a feed from a studio using a Livewire system without a costly and complex gateway device.

AES67 was designed to solve this exact problem. Ratified by the Audio Engineering Society, it is not a full networking standard like Dante or RAVENNA but a "mode" or interoperability standard. It defines a common set of specifications for sample rates (48 kHz), bit depth (16 or 24), packet times (1 ms), and synchronization (IEEE 1588-2008 Precision Time Protocol). Any device claiming AES67 compliance can exchange audio with any other AES67 device, regardless of the underlying native protocol. This effectively creates a universal transport layer for professional audio. For news engineers, this means that a remote codec from one manufacturer can feed a console from another without additional hardware, simplifying deployment and reducing capital expenditure.

Understanding the AES67 Technical Architecture

To fully exploit AES67, engineers must understand its specific technical constraints and capabilities. The standard operates in the IP layer, typically using UDP for transport due to its low overhead, relying on the network infrastructure for reliability rather than TCP retransmission. The AES67 standard itself is a concise document, but its implications for network design are extensive.

Media Clock and Synchronization (PTPv2)

The heart of AES67 is its synchronization layer, based on IEEE 1588-2008 (PTPv2). Unlike consumer audio sync, AES67 requires a profile that ensures sub-microsecond accuracy. The standard defines a specific PTP profile: the "AES67 Media Profile," which relies on a two-step clock synchronization process. In remote deployments, maintaining this level of sync across a WAN often requires a PTP-aware gateway or a local Grandmaster clock at the remote site that is locked to GPS or a stable NTP source. Without this precise sync, audio samples will drift, leading to clicks, pops, or complete loss of audio lock. For field use, portable GPS-disciplined clocks are available that can act as a local Grandmaster, ensuring that the remote devices remain in sync even when the WAN link is unreliable.

RTP Payload Types and Packetization

AES67 encapsulates audio using the Real-Time Transport Protocol (RTP). The standard typically mandates the use of the L16 or L24 payload types, representing 16-bit or 24-bit Linear PCM audio. The bit depth and sampling rate (typically 48 kHz) define the data rate. For a stereo 24-bit/48 kHz stream, this equates to 2 channels * 24 bits * 48000 samples = 2,304,000 bits per second, plus RTP and IP overhead. Packetization time is another critical factor. AES67 can operate at 1 ms, 0.125 ms, or other intervals, but the standard AES67 interoperability profile requires 1 ms. A 1 ms packet contains 48 samples per channel, offering a good balance between latency and overhead. Shorter packet times reduce latency but increase packet rate and overhead, while longer packet times reduce overhead but increase latency. For remote contribution over the public internet, a 1 ms packetization is common, but some implementations allow adjusting the buffer size to compensate for jitter.

Session Description Protocol (SDP)

For an AES67 receiver to play a stream, it needs to know the IP address, port, payload type, and clock information. This metadata is exchanged via SDP files. In a production environment, managing SDP files for dozens of remote streams can be complex, which is why central management systems and dynamic discovery protocols are often layered on top of the basic AES67 standard. Many AoIP platforms support mDNS or SAP (Session Announcement Protocol) to automate discovery, but for WAN connections, manual configuration or a central controller is typically used. Understanding SDP syntax is essential for troubleshooting; an incorrectly specified payload type or clock reference will prevent a stream from being decoded.

Quality of Service (QoS) Requirements

AES67 is sensitive to network congestion. It requires strict QoS controls to prioritize audio traffic. This typically involves marking packets with Differentiated Services Code Points (DSCP). For example, real-time audio is often marked with DSCP EF (Expedited Forwarding) or CS7, ensuring switches and routers prioritize this traffic over best-effort data, web browsing, or large file transfers. In a remote truck relying on a shared internet connection, proper QoS is non-negotiable for maintaining clean audio. It is recommended to reserve at least 10% of the link capacity for audio traffic and to shape or block non-essential traffic during live events. Network planners should also consider the impact of other real-time services like video (SMPTE ST 2110) and intercom when designing QoS policies.

AES67 vs. Dante vs. RAVENNA vs. Livewire

While AES67 provides the interoperability layer, it is essential to understand how proprietary protocols build upon it. Dante by Audinate is the most widespread AoIP technology globally. It uses a proprietary control and management plane but includes an "AES67 Mode" that allows Dante devices to output and receive AES67-compliant streams. RAVENNA is an open technology that directly implements AES67 and adds advanced features like more flexible stream management, support for higher sample rates, and robust multicast management. Livewire by Wheatstone is deeply integrated into their console ecosystem and similarly supports AES67 for cross-vendor interoperability. The key takeaway for news engineers is that AES67 is the "common language." When purchasing equipment, verifying AES67 compliance ensures it will talk to the rest of your IP audio infrastructure, regardless of the native protocol running underneath. However, note that not all implementations are created equal; some devices only support AES67 as a receiver or transmitter, and some may lack certain PTP profiles. Always test interoperability before committing to a deployment.

Strategic Advantages for Remote News Operations

The technical capabilities of AES67 translate directly into operational benefits for news teams, from the solo backpack journalist to the multi-crew satellite truck.

High-Fidelity Audio for Talent and Audience

Listeners can immediately perceive the difference between a constrained codec and uncompressed PCM audio. AES67's support for 24-bit, 48 kHz audio ensures that voice reports, natural sound, and complex audio scenes are reproduced with maximum clarity. For talent, this means a more natural and responsive communication with the studio, reducing fatigue during long live shots. In environments where background noise is present (e.g., protests, outdoor events), the headroom provided by 24-bit audio allows for cleaner mixing and less audible distortion when gain is applied.

Leveraging Existing IP Infrastructure

One of the primary cost benefits of AES67 is its ability to operate over standard IP networks. News organizations can utilize existing corporate WAN links, bonded 4G/5G cellular solutions, or low-cost satellite broadband instead of expensive, dedicated ISDN lines or high-bandwidth satellite transponders. This dramatically reduces the operating cost of remote contributions. For example, a multi-day political convention that previously required multiple ISDN lines costing thousands of dollars can now be covered using a single bonded cellular link and a portable AES67 codec, cutting costs by an order of magnitude.

Seamless Multi-Location Integration

Consider a major political event. A feed from a reporter on the convention floor (using a portable AES67 codec) needs to be mixed with a studio host, an analyst in a remote city, and a field producer's intercom. AES67 allows all these audio streams to coexist on a single network infrastructure and route to any destination within the production facility without a patch panel or complex analog routing. This flexibility is especially valuable in fast-moving news environments where last-minute changes to the audio routing are common.

Compliance with Modern Broadcast Standards

AES67 is a core component of the SMPTE ST 2110 suite, the standard for professional media over IP networks. Specifically, ST 2110-30 defines the carriage of PCM audio based on AES67, and ST 2110-31 defines AES3 transport. By adopting AES67 today, news organizations are building a technical foundation that aligns with the future of broadcast infrastructure, ensuring compatibility with next-generation routers, consoles, and processing gear. Many broadcast facility upgrades now mandate ST 2110 compliance, making AES67 a future-proof investment.

Overcoming the Challenges of Remote AoIP Deployment

Deploying AES67 in a controlled studio environment is relatively straightforward. The real test comes when connecting from a remote hotel room, a stadium press box, or a moving vehicle. Several challenges arise when bridging the local studio LAN with the public internet.

Jitter and Packet Loss

Jitter is the enemy of stable audio. While AES67's standard 1 ms packet time makes it sensitive to network variation, modern implementations offer receive buffers (typically configurable from 3 ms to 50 ms) that can smooth out jitter at the cost of added latency. For long-haul internet connections, Forward Error Correction (FEC) can be employed to reconstruct lost packets without retransmission, ensuring audio continuity even on lossy links. Some AES67 implementations support the SMPTE ST 2022-1 FEC standard, which inserts redundant parity packets. When using FEC, the receiver can recover from a small number of consecutive packet losses without interruption. However, FEC adds overhead, so it should be used judiciously based on the link quality.

Clock Synchronization Across WAN

PTP is designed for high-speed local networks with microsecond precision. Extending this across a WAN is difficult. A common solution for remote contribution is to use a "hybrid" approach. In the field, a local PTP Grandmaster clock provides synchronization for the remote devices. The remote stream is then sent using RTP, and the studio receiver locks to the incoming audio phase using a PLL (Phase-Locked Loop) or similar buffer-based mechanism, effectively treating the remote feed as an asynchronous source. Some codecs also support "adaptive clock recovery," where the receiver adjusts its playback clock based on the arrival timing of packets. This works well over stable connections but can introduce wander on highly variable links. For critical news events, deploying a GPS-locked Grandmaster at both ends ensures the tightest synchronization.

Bandwidth Management

Uncompressed 24-bit/48 kHz stereo audio requires approximately 6 Mbps of network bandwidth. While manageable, this can strain a limited cellular bond or shared satellite link. Some AES67 implementations support optional L16 compression or can be configured to use lower bit depths to conserve bandwidth during critical breaking news situations. Additionally, using mono instead of stereo can halve the bandwidth requirement. For editorial content like voice-only interviews, 16-bit mono at 48 kHz is often indistinguishable from higher bit depths and uses only 768 kbps. Network engineers should implement bandwidth shaping to guarantee audio traffic and drop non-essential data when the link is saturated.

Network Security for Remote Contribution

Opening an audio contribution link over the public internet exposes the operation to potential security risks. Standard AES67 RTP streams are not inherently encrypted. For sensitive news feeds, encryption is a necessity. This is typically achieved by tunneling the AES67 traffic over a Virtual Private Network (VPN) or by using a transport wrapper like Secure Reliable Transport (SRT), which provides built-in AES-256 encryption. Broadcasters should establish standard security policies for remote contributions, including firewalls, access control lists, and mandatory encryption for all streams traversing the public internet. It is also important to protect the management interfaces of AES67 devices with strong passwords and, where possible, isolate them on a separate VLAN.

Integrating Audio Workflows with Directus (Headless CMS)

In a modern digital newsroom, the audio stream is not the final deliverable; it is an asset that must be logged, clipped, transcribed, and distributed. This is where a headless CMS like Directus adds immense value. While Directus itself does not process raw RTP audio streams, it acts as the central system of record for all media assets.

Consider a workflow where audio from an AES67 contribution is ingested and recorded as broadcast-quality WAV files. These files can be immediately uploaded to Directus via its REST or GraphQL API. From there, journalists and producers can use Directus to:

  • Manage Metadata: Attach location, speaker, and subject tags to the audio file using Directus' flexible field types. This metadata can be ingested from third-party systems or manually entered.
  • Automate Transcriptions: Trigger automated speech-to-text processing on the uploaded files via webhooks or Directus flows. The resulting text can be stored as a separate asset or directly embedded.
  • Schedule Distribution: Make the audio available to sister stations or digital platforms via RSS feeds or APIs. Directus can publish audio files to CDNs for fast global delivery.
  • Control Routing: Use Directus as a backend to control an AoIP router's API, dynamically connecting AES67 streams to different recording channels based on a newsroom calendar. For example, a scheduled interview could automatically route the remote feed to a specific recorder and update the metadata in Directus.

This integration bridges the gap between the real-time, high-pressure environment of live audio contribution and the structured, data-driven world of digital asset management. By leveraging Directus to handle the metadata and workflow logic, broadcasters can build highly automated, scalable news production pipelines around their AES67 infrastructure. The headless architecture allows these workflows to be extended to mobile apps, web portals, and broadcast playout systems without re-engineering the core.

Best Practices for Field Deployments

Based on field experience from major broadcast events, several best practices have emerged for reliable AES67 remote contribution:

Network Segmentation and QoS

Always use VLANs (802.1Q) to separate audio traffic from data traffic. Configure QoS at the WAN edge to prioritize RTP traffic. Without strict QoS, a file transfer or software update can easily congest the link and cause audio dropouts. Implement traffic shaping to ensure audio never exceeds a predetermined percentage of the link capacity. Use DSCP marking to classify audio traffic as EF (Expedited Forwarding) and ensure that all routers in the path honor these markings.

Redundancy with ST 2022-7

SMPTE ST 2022-7 defines Seamless IP Protection, where two identical streams are sent over disparate network paths. If one path fails or experiences packet loss, the receiver seamlessly switches to the other. For critical live news coverage on election night or breaking news, implementing ST 2022-7 redundancy is the gold standard for maintaining audio continuity. This requires two independent network paths from the remote location to the studio. In practice, this might mean using two different cellular carriers or a combination of wired and wireless links. The remote codec must support dual-stream transmission, and the studio receiver must support hitless switching.

Utilize Reliable Transport Protocols for WAN

While AES67 handles the coding and synchronization, it is often paired with transport protocols optimized for unreliable networks when crossing the public internet. Protocols like Reliable Internet Stream Transport (RIST) or SRT can wrap AES67 audio streams, providing automatic retransmission, encryption, and robust jitter management. This combination allows for stable, high-quality contribution over standard business or residential internet connections. RIST is particularly popular in broadcast because it is an open standard with broad industry support, while SRT is widely used in content delivery. Both protocols can tunnel AES67 RTP streams with low overhead.

Pre-Event Network Verification

Before deploying a team to the field, pre-event testing is critical. Tools like the SMPTE ST 2110 Test Tool or dedicated AoIP analyzers can validate that the remote network path meets the strict latency and jitter requirements of AES67. A simple ping test is insufficient; engineers should measure one-way delay and packet delay variation (PDV). Many codec manufacturers provide diagnostic tools that report jitter, packet loss, and clock offset. Perform a test stream for at least 15 minutes to identify intermittent issues. If the link fails the test, consider using a bonded multi-link solution or switching to a lower bitrate profile.

The ecosystem surrounding AES67 continues to evolve, driven by the demands of cloud production and globalized news teams.

Cloud Native AoIP

Virtualized audio consoles and processing are becoming mainstream. Technologies like Virtual Soundcards and AES67 virtual drivers (e.g., RAVENNA for Linux) allow software running on a cloud instance to generate or consume AES67 streams. This enables a "studio in the cloud" where a producer in a different city can mix remote feeds just as if they were sitting in the broadcast center. Cloud providers are beginning to offer bare-metal instances with PTP-aware network interfaces, making it possible to run AES67 with sub-millisecond sync across data centers. This trend reduces the need for hardware in remotes and allows news organizations to scale production capacity on demand.

Integration with NDI and IPMX

While AES67 is the standard for audio, it is increasingly paired with video-over-IP standards like NDI and IPMX (a profile of SMPTE ST 2110 for Pro AV). Modern IP codecs and gateways often support both AES67 audio and a video standard, allowing for single-cable contribution of synchronized audio and video to the newsroom. This convergence simplifies remote news gathering by eliminating separate audio and video paths. For example, a portable field unit could output an AES67 audio stream and an NDI video stream over a single Ethernet connection, which a newsroom router then separates for processing.

Open Control Architecture (AES70)

Complementing AES67, the AES70 standard (OCA) defines a control protocol for professional media networks. This allows remote control of preamps, levels, and routing matrices over the same IP network. In a remote news context, a producer in the studio could use AES70 to remotely adjust the microphone gain on a field mixer, ensuring consistent audio levels without requiring the field engineer to touch the gear. OCA also supports monitoring and alarm reporting, giving engineers visibility into the health of remote devices.

Integration with ST 2110 and ST 2022-7

As broadcast facilities migrate to all-IP infrastructures using SMPTE ST 2110, AES67 becomes the native audio transport. Remote news feeds that adhere to AES67 can be directly plugged into these systems without format conversion. This reduces latency and improves reliability. Furthermore, combining AES67 with ST 2022-7 redundancy ensures that critical feeds remain on air even during network failures.

Conclusion

AES67 has fundamentally reshaped the economics and technical architecture of remote news gathering. By providing a universal, non-proprietary layer for high-quality audio transport, it frees broadcasters from the constraints of dedicated circuits and proprietary hardware. While deploying AoIP in the field introduces challenges related to network jitter, clock synchronization, and bandwidth, the maturity of AES67 tools and the availability of supporting protocols like RIST and SRT provide robust solutions.

For news organizations committed to delivering the highest audio quality while maximizing operational flexibility, investing in AES67 technology is a direct path to that goal. Looking ahead, the convergence of AES67 with cloud production, centralized metadata management via platforms like Directus, and open control standards will only deepen the standard's role as the backbone of global news audio contribution. By following the best practices outlined in this article, broadcast engineers can deploy AES67 with confidence, ensuring that every remote report sounds as clear as if it came from the studio next door.