Audio over IP technology has fundamentally transformed how professionals transmit and receive high‑quality audio signals across network infrastructures. Among the key standards driving this transition, AES67 provides a common interoperability layer that allows diverse audio devices and systems to communicate reliably. At the heart of this standard lies metadata—data embedded within audio streams that goes far beyond the raw waveform. Metadata in AES67 enables precise synchronization, stream identification, and real‑time monitoring, making it an indispensable component of any professional AoIP deployment. This article explores the role, types, and implementation of metadata in AES67 streams, offering practical insights for system designers and engineers.

What is Metadata in AES67?

Metadata in AES67 refers to structured information carried alongside the audio payload that describes or controls the audio stream itself. Unlike the digital audio samples that represent sound, metadata provides context—such as stream identifiers, timestamps, source details, and synchronization data—that helps receiving devices accurately interpret, synchronize, and route the audio.

AES67 mandates the use of the Real‑time Transport Protocol (RTP) for transporting audio streams. The RTP header contains critical metadata fields, including a sequence number, timestamp, and SSRC (synchronization source) identifier. However, comprehensive metadata often extends beyond the RTP header into payload descriptions, session descriptions (via SDP), and network control protocols like NMOS (Networked Media Open Specifications). Properly structured metadata ensures that a microphone feed from one manufacturer’s stagebox can be automatically discovered and decoded by a mixing console from another vendor, all over a standard IP network.

Key Distinctions: Payload vs. Metadata

It is important to distinguish between the audio payload—the actual PCM samples—and the metadata that accompanies them. The payload carries the sonic information; metadata carries the instructions for how to handle that information. Without metadata, an AES67 stream would be a meaningless jumble of bits; with it, the stream becomes a self‑describing, routable audio source.

The Importance of Metadata in Audio Streaming

Metadata underpins several critical functions in AES67‑based systems. Its proper use ensures that audio streams can be discovered, synchronized, and managed across large, heterogeneous networks.

Accurate Synchronization

One of the most significant contributions of metadata is enabling sample‑accurate synchronization. AES67 relies on the Precision Time Protocol (PTP) as defined in IEEE 1588‑2008. PTP timestamps embedded in the metadata provide a common time reference across all devices on the network. Receivers use these timestamps to align audio samples from different sources, eliminating delays or phase misalignments that would otherwise cause audible artifacts. For live broadcast or installed sound systems, even a few samples of offset can be unacceptable—metadata makes precise alignment possible.

Stream Identification and Discovery

In a large AoIP network with hundreds of active streams, identifying the correct source is paramount. Metadata carries unique identifiers such as the SSRC in RTP, as well as human‑readable labels when combined with session description protocols (SDP). Modern AES67 deployments often integrate with NMOS (e.g., IS‑04 Discovery & Registration), which uses metadata—including stream ID, source name, and channel labels—to enable automatic device discovery and connection management. This metadata transforms a list of opaque UDP flows into a manageable inventory of microphones, mix outputs, and intercom feeds.

Monitoring and Diagnostics

Metadata also supports network health and audio quality monitoring. By inspecting sequence numbers, timestamps, and redundant stream information (e.g., from SMPTE ST 2022‑7 seamless redundancy), engineers can detect packet loss, jitter, or clock drift. Devices can report stream health using extended metadata fields, enabling proactive maintenance. For example, a console might log a message indicating that a specific AES67 stream is experiencing excessive jitter—allowing technicians to isolate a faulty switch before a broadcast or live event is affected.

Types of Metadata Used in AES67

Metadata in AES67 can be classified into several categories, each serving a distinct purpose. Understanding these categories helps system integrators configure devices correctly and troubleshoot issues.

RTP Header Metadata

Every AES67 stream is carried within RTP packets. The RTP header includes:

  • Sequence Number: A 16‑bit number incremented with each packet, used for packet‑loss detection and reordering.
  • Timestamp: Derived from the PTP clock, this value allows the receiver to calculate the correct playback time for each sample.
  • SSRC: A unique identifier for the synchronization source, ensuring that packets from different streams can be distinguished even if they arrive on the same UDP port.
  • Contributing Sources (CSRC): Optional identifiers for mixers that combine multiple input streams.

Session Description Protocol (SDP) Metadata

Before an AES67 stream can be exchanged, sender and receiver must agree on parameters such as codec, sample rate, number of channels, and network addresses. This information is conveyed via SDP, a text‑based metadata format. Common SDP fields include:

  • Media description (m= line): Defines the transport protocol and port (e.g., m=audio 5004 RTP/AVP 96).
  • Attribute (a=) lines: Specify media‑specific parameters, such as a=rtpmap:96 L24/48000/2 for linear 24‑bit PCM at 48 kHz, two channels.
  • Clock synchronization attributes: Indicate PTP domain and clock identity (a=clock-domain in some extensions).
  • Stream labels: Often embedded in custom attributes or via NMOS registration.

Payload‑Embedded Metadata

Some advanced AES67 implementations embed metadata directly in the RTP payload, using formats like SMPTE ST 2110‑30 (audio) or proprietary methods. This can include per‑channel gain, pan, or routing instructions. While AES67 itself does not mandate such payload metadata, it is increasingly used in broadcast and production environments to carry “Audio Metadata” as defined in AES X211. This information might indicate that a channel is a “commentator mic” or “crowd ambient,” allowing downstream processors to apply appropriate settings automatically.

Network Control Metadata (NMOS)

NMOS (Networked Media Open Specifications) adds a layer of control metadata that is not embedded in the stream itself but is exchanged via REST APIs. The IS‑04 specification defines a registry where senders and receivers post their metadata, including unique IDs, labels, and stream transport parameters. IS‑05 enables connection management, allowing a controller to route streams by sending commands that update both sender and receiver metadata. This infrastructure‑level metadata is critical for scaling AES67 beyond point‑to‑point static configurations.

Implementing Metadata in AES67 Systems

Putting metadata to work in a real‑world AES67 network requires careful attention to protocol compliance, timing, and interoperability.

RTP and PTP Integration

All AES67 devices must support RTP and PTP. The RTP timestamp must be derived from the same PTP grandmaster clock that synchronizes the network. This binding ensures that timestamps across different senders are consistent. Implementation details include:

  • Generating PTP‑aligned RTP timestamps (e.g., using a 48 kHz tick counter).
  • Setting the RTP timestamp offset to reflect the sample phase relative to the PTP epoch.
  • Ensuring that sequence numbers wrap correctly and are not interrupted during clock domain changes.

Session Description Handling

AES67 devices must be able to generate and parse SDP descriptions. The SDP is typically exchanged via a signaling protocol such as SAP (Session Announcement Protocol) or through NMOS IS‑05. Common pitfalls include:

  • Encoding audio formats with the correct rtpmap value (e.g., L24 for linear PCM, 96 for custom dynamic range).
  • Specifying the exact number of audio channels and the channel ordering.
  • Including the ptime attribute to indicate packet time (usually 1 ms or 125 µs for low‑latency applications).

Redundancy and Redundant Metadata

Many AES67 installations use SMPTE ST 2022‑7 for seamless stream redundancy—sending two identical streams over different paths. Metadata must be consistent between the primary and secondary streams; otherwise, the receiver cannot automatically switch without errors. Duplicate sequence numbers and identical timestamps allow the receiver to discard duplicates and reconstruct audio even if one path fails. Implementing this requires careful coordination of metadata generation at the sender.

Configuration and Calibration

Setting up metadata parameters correctly often involves both hardware and software configuration. Engineers should:

  • Assign unique SSRCs to each sender to avoid collisions.
  • Ensure all devices use the same PTP profile (e.g., AES67 profile specifies IEEE 1588‑2008 with a domain number of 0 or 1).
  • Verify that SDP files are broadcasted or registered correctly so that receivers can discover streams.
  • Use network analyzers (e.g., Wireshark with custom dissectors) to inspect RTP headers and SDP exchanges during commissioning.

Best Practices for Metadata Management

To maximize the reliability and flexibility of an AES67 network, system designers should follow established best practices for metadata.

Consistent Naming and Labeling

Human‑readable metadata—such as stream names and channel labels—should follow a consistent convention across the entire system. For example, a naming scheme like Stage Left Microphone 1 is far more useful than an obscure code. When combined with NMOS registration, these labels become searchable and routable without requiring manual patch lists.

Metadata Integrity Verification

Periodically verify that the metadata being broadcast matches the actual stream parameters. Tools such as the AES67 Analyzer or open‑source packet capture scripts can validate RTP timestamps, sequence numbers, and SDP consistency. Any discrepancy should be investigated immediately, as mismatched metadata can cause receivers to drop streams or produce audible glitches.

Documentation and Interoperability Testing

Since AES67 metadata sits at the intersection of multiple standards (RTP, PTP, SDP, NMOS, ST 2022‑7), documentation is critical. Maintain a spreadsheet of each device’s metadata capabilities: supported sample rates, PTP profiles, SDP attributes, and NMOS version. Conduct interoperability tests before a system goes live, especially when integrating products from different vendors. Resources like the AES Standards website provide guidance on metadata implementations.

Future‑Proofing with NMOS

While AES67 streams can work without NMOS, adopting NMOS metadata management brings significant long‑term benefits. The IS‑04 registry and IS‑05 connection management allow dynamic rerouting and fleet‑wide metadata updates—similar to the concepts discussed in fleet‑level content management in other domains. Investing in NMOS‑compatible infrastructure simplifies scaling from a few streams to hundreds or thousands.

Conclusion

Metadata is the silent partner that makes AES67 audio streams reliable, discoverable, and synchronizable. From the RTP timestamp and SSRC to SDP descriptions and NMOS registrations, every metadata element contributes to the plug‑and‑play experience expected in modern IP‑based production and distribution. As AES67 adoption continues to grow—especially with its integration into SMPTE ST 2110 for broadcast—understanding and properly implementing metadata becomes a core skill for audio engineers and network architects. By investing in well‑crafted metadata strategies, organizations can achieve the lowest latency, highest fidelity, and most flexible audio networks available today.

For further reading, consult the AES67‑2018 standard, the NMOS specifications, and the IEEE 1588 Precision Time Protocol documentation.