The Network Transport Foundation of AES67

AES67 does not reinvent networking. It operates as a profile that selects specific, proven technologies from the standard Internet protocol suite. The protocol stack is designed to prioritize low latency and real-time delivery over reliability mechanisms that introduce delay. This fundamental design choice dictates the entire packet structure.

Why RTP/UDP/IP?

AES67 mandates the use of the Real-time Transport Protocol (RTP) over User Datagram Protocol (UDP) over Internet Protocol (IP). This combination is deliberately chosen over TCP. While TCP provides guaranteed delivery through retransmission, these retransmissions introduce variable latency and jitter that are unacceptable for live audio. RTP provides the necessary sequencing and timing information for real-time streams, while UDP provides a fast, connectionless transport layer. AES67 specifically utilizes IP multicast, allowing a single audio source to be distributed to multiple receivers without duplicating data on the wire, making it highly efficient for point-to-multipoint distribution.

Anatomy of an AES67 Packet

An AES67 packet consists of a sequence of headers wrapping a payload of audio samples. Understanding the function of each header field is critical for troubleshooting packet loss, latency issues, and synchronization errors. The total packet size is constrained by the Ethernet Maximum Transmission Unit (MTU), typically 1500 bytes, which limits the number of audio channels or samples per packet.

Ethernet Frame (Layer 2)

The journey begins at the physical layer. The Ethernet header includes the source and destination MAC addresses. In a multicast stream, the destination MAC address is a multicast address derived from the IP multicast group, typically in the range of 01:00:5E: for IPv4. Switches use this address to forward traffic efficiently. The header also contains an optional 802.1Q VLAN tag, which is highly recommended for segregating audio traffic from other network data and for carrying Priority Code Point (PCP) bits for Quality of Service (QoS). The EtherType field (0x0800 for IPv4 or 0x86DD for IPv6) identifies the network layer protocol.

IP Header (Layer 3)

The IP header manages logical addressing and routing. AES67 typically uses IPv4 multicast addresses in the 239.0.0.0 to 239.255.255.255 range (administratively scoped). The Differentiated Services Code Point (DSCP) field is perhaps the most critical byte in the IP header for audio quality. AES67 recommends a specific DSCP value (typically EF - Expedited Forwarding, or AF41) to ensure that audio packets receive priority treatment across switches and routers. Without proper DSCP marking, audio packets can be dropped during network congestion.

UDP Header (Layer 4)

The UDP header is minimal but essential. It provides source and destination port numbers. The destination port is used by the receiver to demultiplex the incoming stream to the correct application. The 16-bit checksum provides basic error detection for the UDP datagram and its payload. Because UDP is connectionless, there is no handshake, allowing for immediate data flow.

The RTP Header

The RTP header is the heart of the AES67 packet, providing the mechanisms for ordering, timing, and payload identification. The fixed header is 12 bytes long.

  • Version (V), Padding (P), Extension (X): Standard flags. AES67 typically does not use the header extension.
  • CSRC Count (CC): Identifies the number of contributing sources. Usually zero in a standard AES67 stream.
  • Marker (M): Used to signal boundaries, such as the start of a talk spurt or a video frame boundary in ST 2110-30.
  • Payload Type (PT): Identifies the audio encoding format. For AES67, common values include L16 (Linear PCM 16-bit) or L24 (Linear PCM 24-bit), often using dynamic payload type numbers (e.g., 96 or 97) negotiated via SDP.
  • Sequence Number: Increments by one for each RTP packet sent. This is the primary tool for detecting packet loss, misordering, and for managing the jitter buffer on the receiving end. A wrap-around of the sequence number is handled by the jitter buffer logic.
  • Timestamp: Reflects the sampling instant of the first sample in the packet. This timestamp is derived directly from the PTP clock. A 48kHz stream will increment this timestamp by 48 ticks per millisecond or 48 ticks per sample period. The receiver uses this to reconstruct the original audio timing and clock domain.
  • Synchronization Source (SSRC): A unique 32-bit identifier for the source of the stream. This is used to distinguish multiple streams from the same source.

Audio Payload

The payload contains the raw or encoded audio samples. AES67 mandates support for Linear PCM at 48 kHz sample rate with 16, 20, or 24-bit depth. The payload can also carry AM824 (Audio over USB) format. The number of samples per packet is determined by the packet time (ptime). Common values include 1ms (48 samples), 125 microseconds (6 samples), or 4ms (192 samples). A 1ms packet time offers lower latency but increases network overhead (more packets per second). The payload size must be carefully calculated to fit within the network MTU to avoid fragmentation, which is strictly forbidden in AoIP networks due to the latency and complexity it introduces.

Precision Timing with PTPv2 (IEEE 1588)

Synchronization is the single most challenging aspect of AoIP. AES67 mandates the use of the IEEE 1588-2008 Precision Time Protocol (PTPv2) to distribute a common clock to all devices on the network. This ensures that the transmitter's sample clock and the receiver's sample clock are perfectly synchronized, preventing buffer underruns or overruns that cause audible clicks and pops.

The Best Master Clock Algorithm

Every PTP-capable device on the network runs the Best Master Clock Algorithm (BMCA). The BMCA analyzes clock quality attributes—such as clock class, clock accuracy, and priority—to elect a single Grandmaster (GM) Clock. All other devices synchronize to the GM. In a properly designed system, the GM is often a dedicated, highly stable device (e.g., a GPS-locked master clock generator). The BMCA also provides automatic failover; if the GM fails, a new GM is elected from the remaining devices.

PTP Message Exchange

PTPv2 defines a specific message sequence to correct clock drift. The GM periodically sends a Sync message. It immediately follows this with a Follow_Up message containing the precise time the Sync was sent. The slave device sends a Delay_Req message and records the time it is sent. The GM responds with a Delay_Resp message, containing the precise time the original Delay_Req was received. By computing the round-trip time, the slave can calculate its offset from the GM and adjust its local clock. This process repeats constantly, maintaining sub-microsecond accuracy across the network.

Session Discovery with SAP and SDP

How does a receiver find an available AES67 stream? The standard uses the Session Announcement Protocol (SAP) for discovery. AES67 transmitters periodically multicast a SAP announcement to a well-known SAP address. This announcement contains a Session Description Protocol (SDP) payload.

The SDP file is the recipe for the stream. It contains all the metadata a receiver needs to connect, synchronize, and decode the audio.

  • Media Description: m=audio defines the media type, port, and transport (RTP/AVP).
  • Connection Data: c=IN IP4 239.x.x.x/32 specifies the multicast group IP address.
  • Attributes:
    • ptime: Packet time in milliseconds (e.g., 1.0).
    • rtpmap: Maps the payload type to an encoding (e.g., 96 L24/48000/2 means 2 channels of 24-bit PCM at 48kHz).
    • Media Clock: mediaclk:direct=0 or a specific PTP timestamp reference.
    • Playout Delay: ts-refclk:ptp=IEEE1588-2008 links the stream clock to the PTP grandmaster.
    • Channel Order: While SMPTE ST 2110-30 specifies channel ordering for AES67, many streams rely on a mutually agreed channel map.

Data Flow Mechanics

The flow of audio data from source to sink is a continuous, tightly orchestrated process. Understanding the transmitter and receiver operations is key to diagnosing network or audio artifacts.

Transmitter Operations

The audio interface digitizes analog audio samples at a constant rate (e.g., 48kHz). The transmitter's driver reads these samples from the hardware and places them into a buffer. At every packet interval (e.g., every 1ms), the driver encapsulates a block of samples into an RTP packet. The sequence number is incremented, and the timestamp is set to the PTP-aligned sample count. The packet is then wrapped in UDP and IP headers, marked with the correct DSCP value, and sent to the configured multicast MAC address. Transmitters must maintain a stable, PTP-locked sample clock to ensure consistent packet timing.

Receiver Operations and Jitter Management

The receiving device listens for SAP announcements. The user selects a stream, and the receiver subscribes to the multicast group using IGMP (Internet Group Management Protocol). Once subscribed, packets begin arriving. However, network switches introduce variable delays (jitter). The receiver's first task is to place incoming packets into a jitter buffer. This buffer smooths out the network delay variations.

  • Jitter Buffer Sizing: The buffer must be large enough to absorb the worst-case network jitter without underflowing, but small enough to limit latency. Typical jitter buffers in AES67 devices range from 1ms to 20ms.
  • Sequence Number Check: The receiver monitors sequence numbers for gaps, indicating lost packets. It can also use this to reorder out-of-order packets.
  • Clock Recovery (PLL): The receiver uses the RTP timestamps derived from the PTP clock to drive a Phase-Locked Loop (PLL). This PLL reconstructs the transmitter's sample clock, ensuring that its internal DAC (Digital-to-Analog Converter) runs in perfect synchronization with the source.

Handling Latency and Loss

Latency in an AES67 network is the sum of several factors: sampling delay, packetization delay (ptime), network transit delay (uplinks, queuing), jitter buffer delay, and processing delay. A 1ms ptime with a 5ms total end-to-end latency is achievable in a well-tuned network. While AES67 does not mandate specific Forward Error Correction (FEC), it does support RTP Redundancy (RFC 2198). More commonly, high-availability systems use a redundant network topology (dual redundant networks) where the transmitter sends two identical streams (Stream A and Stream B) over separate network paths, aligning with SMPTE ST 2022-7 seamless protection switching.

Network Infrastructure Requirements

AES67 places strong demands on network hardware. Standard office-grade switches are often unsuitable for high-channel-count AoIP. Professional managed switches are required.

  • IGMP Snooping: Switches must listen to IGMP messages to forward multicast traffic only to ports that have explicitly requested it. Without IGMP Snooping, multicast traffic floods to all ports, wasting bandwidth.
  • PTP-Aware Switching: For sub-microsecond accuracy across large networks, switches should support PTP Boundary Clock (BC) or Transparent Clock (TC) functionality. This corrects for the latency the switch itself introduces into the PTP timing messages.
  • Quality of Service (QoS): Strict QoS queuing (e.g., Strict Priority) must be configured on all switch ports. PTP event messages should receive the highest priority (CS7), followed by audio traffic (EF or AF41), and then best-effort data.
  • Bandwidth Planning: Engineers must calculate total stream bandwidth. A single 24-bit, 48kHz, 8-channel stream consumes roughly 9.2 Mbps. A network handling 64 such streams requires nearly 600 Mbps of dedicated audio bandwidth. Proper planning prevents over-subscription of uplinks.

Interoperability in Practice

The primary goal of AES67 is to make different manufacturers' gear work together. This is typically enabled in devices through an "AES67 Mode." For example, Dante devices can be configured to output or accept AES67 streams, albeit often with a restriction on channel count or packet time compared to native Dante flows. Livewire+ and Q-LAN devices can similarly interface via AES67.

Common interoperability issues often arise from mismatched configurations. A transmitter sending 1ms packets may not be compatible with a receiver that only supports 4ms packets. Clock domain alignment is another frequent challenge; all devices must be locked to the same PTP grandmaster. Network engineers must pay close attention to the SDP parameters advertised by each device and ensure the network infrastructure (PTP profiles, DSCP values, and VLAN configuration) is consistent across the entire system. For further reading on PTP profiles, refer to the IETF specification on PTPv2 and the IEEE 1588-2008 standard. Practical configuration guides are available from Audinate's AES67 resources.

Conclusion

AES67 represents a foundational standard for the modern, interoperable audio-over-IP ecosystem. By breaking down the packet structure—from the Ethernet frame and RTP header to the PTP timestamp and audio payload—we can see how every layer contributes to the robust, low-latency transmission of professional audio. The mechanics of data flow, driven by precise timing and careful buffer management, ensure that audio is delivered reliably across complex network topologies. For audio professionals, moving beyond a black-box understanding of these technologies is essential. Mastering the principles of packet structure, synchronization, and network configuration is the key to deploying and maintaining high-performance, scalable AoIP systems that stand the test of time.