Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 62379-5-2:2014 – Common Control Interface for Networked Digital Audio and Video Products – Signalling Protocol
IEC 62379-5-2 defines the signalling protocol for the common control interface applicable to networked digital audio and video products operating over IP networks. This standard is part of the IEC 62379 series, which aims to provide a unified control framework for professional AV equipment across different manufacturers, enabling interoperability in broadcasting, live sound, installed sound, and video production environments. The signalling protocol specified in this part handles connection management, flow setup and teardown, routing, and resource allocation for real-time AV streams over packet-switched networks.
💡 Key Insight: IEC 62379-5-2 provides a control plane protocol that is transport-agnostic at the physical layer but aware of network QoS requirements. Unlike consumer AV streaming protocols, this standard addresses the deterministic latency, synchronisation, and reliability requirements of professional broadcast and production environments, where sub-millisecond timing accuracy and guaranteed delivery are essential.
1. Scope and Protocol Architecture
The standard specifies signalling messages for managing AV flows over IP networks. The protocol defines message formats, information elements, and state machines for connection management. The architecture separates the control plane (signalling) from the data plane (media transport), allowing the signalling protocol to operate independently of the actual media transport mechanism.
The protocol operates at the application layer and can run over TCP or UDP transport. Key message types defined in the standard include:
- FindRoute: Request for route discovery between source and destination units
- AddFlow: Establishment of a unidirectional or bidirectional media flow
- ClearDown: Tear-down of an established flow and release of network resources
- NetworkData: Exchange of network-specific configuration parameters
- EndToEndData: Exchange of end-to-end application parameters
- AsyncSetup: Setup of asynchronous (non-isochronous) data flows
2. Message Format and Structure
Each signalling message consists of a fixed header and a variable part containing information elements. The message structure is designed for efficient parsing and extensibility.
2.1 Message Header
| Field | Length (bits) | Description |
|---|---|---|
| Protocol version | 4 | Version identifier for the signalling protocol |
| Message type | 8 | Identifies the message function (FindRoute, AddFlow, etc.) |
| Message length | 16 | Total message length in bytes (header + variable part) |
| Transaction ID | 32 | Unique identifier for request-response matching |
| Source unit ID | Variable | UUID or IP-based identifier of the originating unit |
| Destination unit ID | Variable | UUID or IP-based identifier of the target unit |
| Flow identifier | 32 | Identifier for the media flow being managed |
2.2 Information Elements
The variable part of the message consists of a sequence of information elements (IEs), each with a type-length-value (TLV) structure. The standard defines over 20 information element types, including:
- Called/Calling address: Network addresses for the flow endpoints
- Flow descriptor: Media type, encoding, bit rate, and packetisation parameters
- Data format or protocol: Specific codec and container format identifiers
- Start/End time: Scheduled timing for flow activation and deactivation
- Call importance: Priority level for resource reservation and pre-emption
- Service name: Human-readable programme or service identifier
- Synchronous/Asynchronous service parameters: Timing and synchronisation requirements
- Link-specific resource allocations: Bandwidth and buffer reservations per network hop
- End-to-end delay: Maximum acceptable latency for the flow
⚠️ Engineering Note: The TLV-based information element structure provides protocol extensibility without breaking backward compatibility. Custom or manufacturer-specific information elements can be added using the reserved type range (0x80-0xFF), allowing vendors to extend the protocol for specialised applications while maintaining interoperability for standardised elements.
3. Address Format and Unit Identification
The standard defines a flexible addressing scheme that can accommodate different network technologies. Units are identified by a globally unique identifier (UUID) and located through network addresses that can be IPv4, IPv6, or other network-layer addresses. The protocol supports both unicast and multicast flow topologies.
Flow identifiers are 32-bit values that are unique within the context of the originating unit. The combination of source unit ID and flow identifier provides globally unique flow identification, which is essential for managing flows across multi-hop networks with multiple switches or routers.
4. Engineering Design Insights
- Byte order: All multi-byte fields in IEC 62379-5-2 are transmitted in network byte order (big-endian). This is consistent with Internet protocols but differs from some legacy AV protocols that use little-endian ordering. Engineers implementing protocol stacks must ensure correct byte order conversion on little-endian platforms (x86, ARM).
- Route metric computation: The FindRoute message includes route metric information elements that allow units to make informed routing decisions. The metric can be based on hop count, available bandwidth, cumulative latency, or a composite metric. The standard does not mandate a specific routing algorithm, allowing manufacturers to implement optimised path selection.
- Resource reservation: The AddFlow procedure includes optional resource reservation information elements for specifying bandwidth requirements, jitter buffers, and traffic class parameters. When used with QoS-enabled networks (DiffServ or IEEE 802.1Q), the signalling protocol can trigger automated network configuration for deterministic AV stream delivery.
✅ Best Practice: When implementing IEC 62379-5-2 in a broadcast environment, the AddFlow timeout parameter should be set according to the expected stream duration. For permanent installations (e.g., studio router connections), set the timeout to 0 (infinite). For event-based productions, set the timeout to the expected programme duration plus a 10% margin to prevent premature flow termination during extended segments.
🔥 Network Design Consideration: The signalling protocol itself can become a bottleneck in large-scale AV networks. For networks with more than 100 AV endpoints, dedicated signalling bandwidth should be provisioned. A rule of thumb is to allocate 1 Mbit/s of signalling bandwidth per 50 AV flows, accounting for the overhead of periodic route discovery and keep-alive messages.
5. Frequently Asked Questions
Q1: How does IEC 62379-5-2 relate to other AV networking standards like AES67 or Dante?
A: IEC 62379 provides the control plane (connection management and signalling), while AES67 and Dante operate at the media transport layer (RTP, PTP synchronisation). They are complementary — IEC 62379-5-2 can be used to manage the setup and teardown of AES67 media streams in a professional AV network.
A: IEC 62379 provides the control plane (connection management and signalling), while AES67 and Dante operate at the media transport layer (RTP, PTP synchronisation). They are complementary — IEC 62379-5-2 can be used to manage the setup and teardown of AES67 media streams in a professional AV network.
Q2: What network infrastructure is required for IEC 62379-5-2?
A: The standard operates over standard IP networks. For professional AV applications, a managed Gigabit Ethernet network with IGMP snooping for multicast management, PTP (IEEE 1588) for clock synchronisation, and DiffServ QoS is recommended. Unmanaged switches are not suitable for deterministic AV streaming.
A: The standard operates over standard IP networks. For professional AV applications, a managed Gigabit Ethernet network with IGMP snooping for multicast management, PTP (IEEE 1588) for clock synchronisation, and DiffServ QoS is recommended. Unmanaged switches are not suitable for deterministic AV streaming.
Q3: Can IEC 62379-5-2 control consumer AV devices?
A: The standard was designed for professional AV products. While there is no technical barrier to implementing the protocol in consumer devices, the complexity and feature set are oriented toward professional broadcast, installed sound, and production environments where centralised control and deterministic performance are required.
A: The standard was designed for professional AV products. While there is no technical barrier to implementing the protocol in consumer devices, the complexity and feature set are oriented toward professional broadcast, installed sound, and production environments where centralised control and deterministic performance are required.
Q4: How does the protocol handle network topology changes?
A: The FindRoute mechanism detects topology changes through periodic route discovery. When a route becomes unavailable (e.g., due to link failure), affected flows are automatically cleared down, and alternative routes can be established if redundant paths exist. The standard does not specify fast reroute mechanisms — these are handled by the underlying network infrastructure (e.g., STP, link aggregation).
A: The FindRoute mechanism detects topology changes through periodic route discovery. When a route becomes unavailable (e.g., due to link failure), affected flows are automatically cleared down, and alternative routes can be established if redundant paths exist. The standard does not specify fast reroute mechanisms — these are handled by the underlying network infrastructure (e.g., STP, link aggregation).
