AES3 / AES/EBU
AES3 is the AES-governed professional two-channel digital audio interface, also widely called AES/EBU. Unlike Dante, AES67, Q-LAN, or ST 2110, native AES3 is not an IP protocol and has no TCP/UDP port footprint. It is a unidirectional, self-clocking, point-to-point serial digital audio link from one transmitter to one receiver, normally over a balanced 110-ohm digital audio cable path or a supported coaxial/fibre implementation. `ST 2110-31` is the separate managed-IP case for transparent RTP carriage of AES3 signals, including AES3 subframe information; it belongs in the ST 2110 network schedule, not in a native AES3 tie-line port list.
Audio TransportOpen Standardsub mspoint to point
Infrastructure Requirements
- A real AES3 physical path end-to-end: typically balanced `110-ohm` shielded twisted pair on `XLR`, or a `75-ohm` coaxial implementation/adaptation only where both ends explicitly support the coaxial form factor and signalling expectations
- one transmitter to one receiver on a unidirectional self-clocking link unless you add proper digital distribution/reclocking
- and a deliberate clock / sample-rate plan at every domain boundary. If AES3 is being carried transparently across an IP production network, that is the separate `SMPTE ST 2110-31` design case, with `RTP`, `SDP`, `PTP`, multicast, QoS, and receiver/subscriber management inherited from the ST 2110 plant.
Network Ports & Requirements
| Port(s) | Transport | Direction | Purpose | DSCP | Multicast | Config. |
|---|---|---|---|---|---|---|
| — | N/A | Both | Native AES3 does not use TCP, UDP, multicast groups, discovery services, or routable network services. | — | — | No |
| 110 | AES3 | Both | Carries two channels of linearly represented digital audio plus channel-status/user/validity/parity information on a self-clocking point-to-point physical link. | — | — | No |
| 75 | AES3-format | Both | Carries the AES3-format signal where the endpoint explicitly supports that physical implementation or a proper format/impedance conversion path is provided. | — | — | Yes |
Gotchas & IT Notes
- ⚠Do not open firewall ports for native AES3. It is a physical digital-audio tie line, not a routed network service.
- ⚠Do not patch AES3 through an Ethernet switch just because some implementations or adapters may use RJ-45/Cat cabling. The native transport is not Ethernet.
- ⚠XLR connector similarity is the field failure: label drawings and panels as `AES3`, `AES/EBU`, `DI`, or `DO`, not merely "audio".
- ⚠One AES3 link is one-way. If a system needs send and return audio, schedule two paths or another transport.
- ⚠Avoid passive Y-splitting. Use a digital distribution amplifier, reclocker, router, or appropriate gateway when one source must feed multiple destinations.
- ⚠If AES3 appears inside an AoIP, MADI, SDI, or ST 2110 gateway, separate the native AES3 transport from the management/control/network side of that gateway in the IT schedule.
- ⚠Use `ST 2110-31` only when transparent AES3 payload carriage over IP is the actual requirement. For ordinary PCM AoIP interoperability, `AES67` / `ST 2110-30` is normally the cleaner design boundary.
- ⚠Do not treat "AES3-compatible" as a firewall or network statement. It is a physical/protocol payload capability unless a specific gateway also exposes IP management, discovery, control, or ST 2110 media streams.
- ⚠Do not accept "supports AES3 sample rates" as sufficient. The selected endpoints must state the supported sample rates and must be tested for lock, mute/fallback behavior, channel-status interpretation, and `SRC` behavior where clock domains meet.
- ⚠Treat `AES-2id` as field guidance for use and troubleshooting, not the normative physical or transport definition. Use `AES3-1/2/3/4` and endpoint documentation for compliance language.
- ⚠For IT handoff, write "no native IP ports" and then list any separate device services from the actual gateway, DSP, router, or converter documentation. Do not infer those ports from AES3 itself.
- ⚠2026-06-02 refresh: native AES3 remains a no-IP physical audio interface. The source-backed port-schedule rule is still to list the AES3 tie line as physical infrastructure only, then schedule any separate gateway/router/DSP web UI, API, discovery, control, PTP, RTP, or management traffic from that device's documentation. `ST 2110-31` is not a reason to add ports to native AES3; it is a different RTP/IP design case for transparent AES3 carriage under the ST 2110 timing and session-description model.
- ⚠2026-06-07 refresh: rechecked AES, IEC, EBU, and SMPTE primary sources. The live IEC `60958:2026 SER` pack publication does not create an IP-service surface for AES3; it keeps the same serial digital-audio-interface family boundary. Treat native AES3 as physical infrastructure only, even when it appears on `XLR`, `BNC`, `RJ-45`, `D-sub`, optical adapters, or gateway cards. Those connector forms may change cable schedules and pinouts, but they do not make the native link routable through an Ethernet switch. If a gateway exposes `ST 2110-31`, Dante, AES67, MADI, SDI embedding, web UI, SNMP, API, or clock services, schedule those services from the gateway documentation as separate rows.
- ⚠2026-06-12 refresh: rechecked AES, IEC, EBU, and SMPTE primary sources. No port-data change: native AES3 still has no TCP, UDP, multicast, discovery, VLAN, or firewall-service footprint. The port schedule should keep AES3 as a physical signal row and separately schedule only the actual IP services of adjacent equipment. `ST 2110-31` remains the exception only because it is an RTP/IP encapsulation of AES3 under a managed `ST 2110` timing/session model, not because native AES3 has ports. Sources accessed 2026-06-12: <https://aes2.org/standards/>; <https://aes2.org/standards/standards-development/project-status/>; <https://www.aes.org/standards/blog/2024/9/reaffirmed-versions-of-aes3-1-2-3-4-have>; <https://www.aes.org/publications/standards/preview.cfm?ID=77>; <https://www.aes.org/publications/standards/search.cfm?docID=78>; <https://www.aes.org/publications/standards/preview.cfm?ID=79>; <https://www.aes.org/publications/standards/search.cfm?docID=80>; <https://tech.ebu.ch/publications/tech3250>; <https://webstore.iec.ch/en/publication/4048>; <https://pub.smpte.org/latest/st2110-31/st2110-31-2022.pdf>.
- ⚠2026-06-16 refresh: local-library-first review confirmed this Clearport port-data entry and the companion taxonomy entry remain the correct homes. Rechecked current official / primary AES, EBU, IEC, and SMPTE material. No native network-port change: `AES3` / `AES/EBU` remains a physical, unidirectional, two-channel serial digital-audio interface with no TCP, UDP, SCTP, DCCP, multicast-IP group, DNS, DHCP, NTP, PTP, routed discovery, VLAN, or firewall-service footprint. The IT answer is still "none for AES3 itself"; the AV answer is a signal schedule: physical medium/connector, direction, source/receiver sample rates, recovered-clock or `SRC` behavior, payload expectation, channel-status/validity handling, fan-out/reclocking method, and lock/mute/recovery acceptance. Do not copy `ST 2110-31` ports into a native AES3 line item. `ST 2110-31` is an RTP/IP transparent AES3 carriage design under the managed `ST 2110` timing/session model; schedule it under the ST 2110 network record when that is the actual system architecture. Sources accessed 2026-06-16: <https://aes2.org/standards/>; <https://aes2.org/standards/standards-development/project-status/>; <https://www.aes.org/standards/blog/2024/9/reaffirmed-versions-of-aes3-1-2-3-4-have>; <https://www.aes.org/publications/standards/preview.cfm?ID=77>; <https://www.aes.org/publications/standards/search.cfm?docID=78>; <https://www.aes.org/publications/standards/preview.cfm?ID=79>; <https://www.aes.org/publications/standards/search.cfm?docID=80>; <https://tech.ebu.ch/publications/tech3250>; <https://webstore.iec.ch/en/publication/4048>; <https://pub.smpte.org/latest/st2110-31/st2110-31-2022.pdf>.
Source: https://aes2.org/standards/