It is always the same shape of fault. Not the whole wall — one feed. A camera stream that was on the wall at handover is a black rectangle at 3:10am, and the operator on shift has three numbers to ring: the integrator who built the room, the IT team who own the switches, and the vendor whose encoder is blinking green like nothing happened. All three can demonstrate, politely and correctly, that it isn’t theirs. By the time anyone with privileged access to that switch is awake, the feed has come back on its own, and the ticket closes as intermittent.
Nothing was broken. Something was unowned.
That distinction is the whole argument here, and it needs saying plainly because the industry has spent a decade debating the wrong question. Network or matrix is settled — the network won, and it won convincingly. What replaced it is a harder question nobody puts on a tender: AV over IP is not a product category, it is a network service, and the document that says who runs that service week to week almost never gets written. Boxes get a serial number, a warranty and a line in the asset register. The switch configuration those boxes depend on gets a handshake.
In a boardroom that produces an awkward Tuesday. In an operations centre running twelve-hour shifts it produces the 3am call above, which is why the discipline belongs in control room AV design from the first sketch, next to sight-lines and console heights, rather than in a change request six months after go-live.
What AV over IP actually moved into your rack
AVIXA’s read on 2026 is that AV over IP is now mainstream, and that technical conversations in AV increasingly resemble IT conversations — cybersecurity, interoperability, cloud management, enterprise infrastructure. That is true, and most integrators would say it describes their last three jobs. What gets less attention is the mechanical consequence.
A matrix switcher kept its complexity inside a frame. The crosspoint logic, the bandwidth allocation, the timing — all of it was the manufacturer’s problem, soldered down, and it either worked or you sent the frame back. Moving to Extron NAV or Crestron DM NVX does not delete that complexity. It relocates it into a configuration file on a switch, where it becomes editable by anyone with the credentials and invisible to everyone without them.
Here is the specific inventory of what moved, because vagueness is how this gets waved through:
Multicast behaviour. AV over IP distributes video as multicast. Every switch in the signal path needs IGMP snooping enabled, and where there is no layer-3 device doing the work, one switch has to be configured as the querier — otherwise group memberships age out and streams stop, usually minutes after everything looked fine at commissioning. Switches also have a finite number of multicast groups they can track, which is a sizing decision made long before anyone counts the encoders.
Switch capability, not switch brand. Network-audio vendors publish requirements that read like a hardware specification because they are one: managed switches, non-blocking capacity, QoS prioritisation of AV traffic, and Energy Efficient Ethernet disabled — a power-saving feature that is excellent on a desk and ruinous on a time-sensitive stream.
Time. AES67 synchronises devices using IEEE 1588 Precision Time Protocol, version 2. Boundary or transparent clock support in the switch is a recommendation that behaves like a requirement once the system grows past one closet. A clock domain with no documented grandmaster is a system with a scheduled failure in it.
None of this is exotic engineering. It is ordinary network work, well documented by every manufacturer selling into the space — Datapath ships a network manager as part of Datapath Aetria, which tells you how seriously the people who build control-room platforms take the layer underneath. The difficulty was never technical. The difficulty is that a switch sitting in an AV rack, carrying AV traffic, configured by an AV integrator, remains a piece of network infrastructure in an organisation where the network team did not ask for it and the AV team is not resourced to run it.
AVIXA’s analysis of the European market this year put it more bluntly than most vendors would: multi-vendor is the default, ownership is the gap. That gap is where projects quietly fail — not at handover, where everything works, but eighteen months later, when a firmware update lands or a switch is replaced like-for-like by someone who had no reason to know the old one was carrying a PTP domain.
The Handover Ledger
So here is the artefact we think every networked AV project should hand over alongside the as-builts. Call it the Handover Ledger. It is six rows long, and the rule that makes it work is deliberately strict:
Every row gets a name, a method and a date. A row with a job title instead of a name is unowned. A row with “as required” instead of a date is unowned.
“The IT team” is not a name. “Annually” is not a date. The point of the ledger is not thoroughness — any competent integrator could produce a longer list. The point is that each line has to survive contact with a person who could be rung at 3am, and most of these lines currently cannot.
| Layer | What it actually is | Who assumes it’s theirs | What an unowned row looks like |
|---|---|---|---|
| Switch configuration | VLANs, IGMP snooping and querier, QoS policy, EEE disabled, port profiles | AV says IT, IT says AV | A switch replaced like-for-like at midnight; video gone by morning |
| Multicast address plan | Which group ranges belong to AV, documented and reserved | Nobody — it was decided in a commissioning week | A new subsystem lands on an address already in use; two streams fight |
| Time / PTP domain | Grandmaster, boundary clocks, domain number, failover order | Assumed to be automatic because it was automatic on day one | Audio drifts, then drops; nobody connects it to the clock |
| Firmware baseline | Versions across encoders, decoders, switch OS, wall processor, codecs — and the tested combination | Each vendor, for its own box only | One device updated for a security patch; an interoperability bug nobody can reproduce |
| Identity, certificates and licences | 802.1x credentials, certificate expiry, subscription and portal renewals | Procurement, until something expires | A certificate lapses on a long weekend and half the estate stops authenticating |
| Source catalogue and presets | The layouts per shift and per incident, and who may change them | The operators who were there at commissioning | Three years on, everyone drives the wall from one preset because the rest no longer match reality |
Two things about the right-hand column are worth sitting with. First, none of those failures look like a network fault to the person experiencing them — they look like the AV being unreliable, which is how good systems acquire bad reputations. Second, every one of them is cheap to prevent and expensive to diagnose, which is the exact profile of a problem that gets deferred until it is urgent.
We also think the ledger belongs in the design documentation, not the handover pack. A row you discover you cannot fill during design is a conversation about scope. The same row discovered at handover is an argument.
When the matrix switcher is still the better answer
The honest counter-case deserves more than a sentence, because the lazy version of this argument — network good, matrix obsolete — has done real damage.
If a room has four fixed sources, one display surface, no KVM requirement and no plausible growth path, an AV-over-IP design is very likely the worse system. Not because the technology is inferior, but because it adds a managed network, a multicast plan, a clock domain and a firmware matrix to an organisation that has no one to run any of it. A matrix switcher in that room is a sealed appliance with one owner and one failure mode. That is a genuine advantage, and the industry’s enthusiasm for networked everything has quietly pushed a lot of small systems past the point where the management overhead is repaid.
The size limit arrives faster than people expect, though. Add a second room that needs the same sources. Add KVM, so operators can drive machines in the rack room from a console. Add a wall whose layout changes by shift. Add any growth at all, and the matrix stops being a sealed appliance and becomes a frame you outgrow, replace wholesale and argue about. That is the point at which the network’s overhead becomes its advantage: you add endpoints instead of replacing the system.
The useful question is therefore not which architecture. It is what scale of ownership this organisation can actually sustain — and then choosing the architecture that fits it. An operations centre with a 24/7 roster and a resourced IT function can own a networked system properly. A single meeting room in a 40-person office generally cannot, and should not be sold one.
It is also worth being fair to the vendors here. The ownership gap is not a manufacturer failing. Extron, Crestron, Q-SYS, Datapath and the network-audio vendors all publish detailed network guidance, and it is mostly good. The gap sits in procurement: the network layer appears in no bill of materials, so it gets no line in the budget, so it gets no owner.
What a custom AV design and fit-out owes the network
The industry has already started to price this in, even if tenders haven’t. AVIXA’s 2026 channel survey found services edged past hardware in revenue contribution — 38% against 36% for 2025 — with corporate cited as the largest predicted managed-services opportunity. Read that as the market discovering that the sustaining layer is where the value sits, and that selling someone a wall without selling them the means to keep it running is an incomplete transaction.
For a custom AV design and fit-out, that translates into deliverables you can ask for by name:
- A network topology drawing that shows the AV VLANs, the switch models, and which ports carry which traffic — not a block labelled “network”.
- A reserved multicast address plan, written down, with room in it.
- The PTP topology: grandmaster, backups, domain, and what happens when the grandmaster is rebooted.
- A firmware baseline naming the tested combination of versions, with the date it was tested and who tests the next one.
- The Handover Ledger above, filled in, with real names against each row.
On a Q-SYS Core Nano estate that documentation is what makes remote management genuinely useful rather than a dashboard nobody logs into. On a control-room wall it is what turns a 3am fault from an escalation into a ten-minute fix. Where an organisation has no internal capacity to hold those rows, the answer is to contract them deliberately — that is precisely what Focus Care support exists to carry, and why our AV support scope is written in terms of named responsibilities rather than a response-time number that sounds reassuring and commits to nothing.
We have built both sides of this. At Intertek’s MineralSpace facility, audio runs over Dante networking with an Extron processor arranging media players, PCs and live CCTV across an LED wall in whatever configuration a session needs — a system whose flexibility is entirely a function of the network beneath it being specified properly. At Linkforce, five rooms run from one centralised Q-SYS platform rather than five independent rooms, which is cheaper to own precisely because there is one place where the configuration lives, and one set of rows to keep filled.
The question to put in the tender
Most control-room specifications we are asked to respond to are rigorous about the things that can be tabulated. Wall dimensions, panel duty rating, redundancy on the signal path, console ergonomics, sight-line angles in degrees. All of it necessary. None of it sufficient, because a 24/7 room does not fail at the panel — the panels are the most reliable thing in the building. It fails at the layer that six different organisations each assume somebody else is watching.
So add one line, and make it a requirement rather than a courtesy. Not describe your network design — every respondent will answer that, and answer it well. Ask instead:
Name the person who will hold each row of the configuration twelve months after handover, and tell us how we will know when they stop.
A good respondent will have an answer, and it will cost money, and the cost will be visible rather than buried. A respondent without an answer has told you something more useful than any specification sheet could: that the network your operations centre runs on is going to belong to whoever happens to be awake. If you are planning an operations centre, a command room or a security suite in Perth, bring that question to the design table early — it is the one we would rather argue about on a drawing than on a Saturday night. That is the conversation we start every control room AV project with, and it is the one that decides whether the room is still trusted in year five.