Connecting AV to IT: start with traffic flows, not with the solution

Not everything needs to talk to everything

When AV and IT are separated, the same question eventually appears: how do we connect the AV network to the IT network?

The conversation often jumps straight to solutions: a static route, NAT router, firewall rule, trunk, control VLAN or out-of-band network. But that is actually step two.

The first question should be:

What exactly needs to communicate?

Not all AV traffic has the same function. Audio, video, control, management and services each have different requirements. By separating those traffic flows first, you avoid opening the entire AV network unnecessarily.

Four types of traffic

A practical AV design distinguishes four main categories.

1. AV media

This is the actual audio and video data. Think of Dante audio, AES67, NDI video, SDVoE, Q-SYS audio/video or ST 2110.

These streams are sensitive to bandwidth, latency, jitter, multicast behavior and timing. In many installations, this traffic is best kept inside the AV zone.

2. AV control

This is operation and control. Think of touch panels, room control, API calls, camera control, matrix control, presets, mute commands and status information.

Control traffic is usually lighter than media, but it is important for the user experience.

3. AV management

This is administration and configuration. Think of switch management, web interfaces, SSH, SNMP, NETGEAR Engage, Q-SYS Designer, Dante Controller, firmware management and monitoring.

Management traffic should not be available to everyone. Only administrators or specific management systems should have access.

4. Services

Many AV devices need supporting services, such as DNS, NTP, logging, license checks, updates or monitoring.

These services usually do not require broad network access. They require specific access to known servers.

Why this distinction matters

Without this distinction, a connection quickly becomes too broad. For example, a route is added between IT and AV “so management works”, and later it turns out that the entire IT client network can reach all AV devices.

That is rarely necessary.

Dante is a good example of why the distinction matters. Audinate documents different types of Dante traffic, including PTP, mDNS, multicast audio, AES67 audio, unicast audio/video, control and monitoring. Not every type of traffic has the same function or the same desired scope.

Q-SYS also makes it clear that the network carries multiple functions: audio and video distribution, discovery, synchronization, control and management. These are different flows that should be designed deliberately.

Example: meeting room

Take a meeting room with cameras, microphones, a DSP, speakers, touch panel, Teams Room system and a NETGEAR AV switch.

What really needs to be connected?

Teams Room -> internet/cloud: yes
Touch panel -> control processor: yes
AV admin laptop -> AV devices: yes, limited
DSP -> NTP server: yes
AV switch -> monitoring: yes
Guest Wi-Fi -> AV devices: no
General office clients -> camera web interface: no
Dante audio -> IT network: usually no

This example shows that “connecting AV to IT” is not an all-or-nothing question. It is about targeted access rules.

Discovery is a separate topic

Many AV tools use discovery to automatically find devices. This often works well inside one subnet, but not automatically across VLAN or firewall boundaries.

The reflex is sometimes to stretch VLANs or open firewall rules broadly. That is not always the best approach.

For NDI, for example, a Discovery Server is available. NDI describes that Discovery Servers can support multiple subnets and organize sources into different areas for workflow and security needs.

For Dante, Dante Domain Manager can help in larger environments. Audinate describes that Dante Domain Manager can create independent Dante Domains and that one Dante Domain can span multiple subnets.

Solutions like these are often better than simply stretching Layer 2 everywhere.

Practical inventory

Every project should start with a traffic matrix.

For example:

Source: AV admin laptop
Destination: NETGEAR Engage / AV switches
Protocol: HTTPS / management
Direction: IT -> AV management
Allow: yes, admin subnet only

Source: AV devices
Destination: NTP server
Protocol: UDP 123
Direction: AV -> IT services
Allow: yes

Source: Guest Wi-Fi
Destination: AV VLANs
Protocol: any
Direction: Guest -> AV
Allow: no

This makes the conversation with IT concrete. You are not asking to “open the AV network”. You are asking for specific traffic flows.

Conclusion

A good connection between AV and IT does not start with routing, NAT or VLANs. It starts with understanding the traffic flows.

Media, control, management and services each have their own requirements. By making that distinction early, you design a network that is safer, more stable and easier to manage.

In the next blog, we discuss the most common connection methods: out-of-band management, control VLANs and firewalling.