AV (audio visual) systems now run over IP (Internet Protocol) networks. This page explains HDBaseT, Dante audio, video over IP and how I design the network beneath them. It then covers control systems, meeting and teaching rooms, security cameras, the handshake before a picture appears, and a fault finder.
Audio visual systems used to be a world of dedicated cables: a matrix switcher in a rack, and a cable to every input and output. Encoders now turn audio and video into packets, so the same switches that carry email can carry a lecture, a concert or a board meeting. Choose a view to compare the three ways of moving AV around a building.
Swipe sideways to see the whole diagram.
A matrix switcher has a fixed number of inputs and outputs. Every source and every display needs its own cable back to the rack, HDMI (High Definition Multimedia Interface) for short runs and HDBaseT for long ones. It is quick and predictable, but it stops growing when the frame is full.
A transmitter and receiver pair carries one source to one display over a single Cat cable, up to 100 m with HDBaseT. It suits one long run to a projector. Every new route needs another pair and another cable, and nothing can be shared.
An encoder turns each source into a stream of packets, and each decoder joins whichever stream it is told to. Any source can reach any display, one stream can feed many displays through multicast, and growth means more switch ports. The network now has to be designed for AV.
| Matrix switcher | Extenders | AV over IP | |
|---|---|---|---|
| Scale | Fixed by the frame size | One route per pair | Add switch ports and endpoints |
| One source to many displays | Yes, within the frame | Only with a splitter | Yes, with multicast |
| Cabling | Home run from every port | One cable per route | Structured cabling to the nearest switch |
| Latency | Almost none | Almost none | From under a millisecond to a frame or more, by codec |
| Who runs it | AV team | AV team | AV and network teams together |
| Where I use it | Small rooms with a few sources | One long run to a projector or screen | Buildings, campuses, venues and anywhere routes change |
Once audio and video ride on Ethernet, a misconfigured switch can silence a lecture hall. I design the AV network with the same care as a data centre network, and I bring the network team in from the first meeting.
Uncompressed or lightly compressed video gives no visible delay but needs 10 gigabit links. Heavier compression fits on 1 gigabit, or even on Wi-Fi and the internet, at the cost of some delay and detail. The use case decides, not the brochure.
Dante, AES67, NDI (Network Device Interface) and SDVoE (Software Defined Video over Ethernet) each let products from different makers work together. I prefer an open ecosystem over a single maker's closed system, unless one maker covers every need.
HDBaseT sends uncompressed video and audio up to 100 m over a single Cat cable, along with Ethernet, USB (Universal Serial Bus), control and power. It is point to point, not a network, so it sits between a matrix and full AV over IP. Watch each signal ride the same cable.
Swipe sideways to see the whole diagram.
One cable carries what HDBaseT calls 5Play: video with its audio (orange), Ethernet (cyan), USB (purple), control such as RS-232 and infrared (teal) and up to 100 W of power (pink). Ethernet and control run in both directions.
| Version | Year | What it brought |
|---|---|---|
| HDBaseT 1.0 | 2010 | Uncompressed HDMI video and audio, Fast Ethernet, control and PoH (Power over HDBaseT) on one Cat cable. 100 m at 1080p and 70 m at 4K. |
| HDBaseT 2.0 | 2013 | Networking between HDBaseT devices, USB 2.0 carried in the link, and fibre as an option beside copper. |
| HDBaseT 3.0 | 2019 | Up to 16 Gb/s downstream for uncompressed 4K at 60 frames with full colour (4:4:4), Gigabit Ethernet, faster USB and optional eARC (enhanced Audio Return Channel). It needs Cat6A or better. |
Dates and figures from the HDBaseT Alliance specifications, as summarised in public sources. The alliance was formed in 2010. Distances depend on the cable and the product, so I check each maker's data sheet.
A single long run, such as a lectern to a projector or a rack to a wall display, where a pair of boxes is simpler and cheaper than a network. It adds no compression and no visible delay.
I specify Cat6A, shielded where the run passes power or lighting, and terminate it with care: HDBaseT tolerates far fewer faults than Ethernet. With PoH the display end needs no local power socket.
An HDBaseT port looks like an Ethernet socket but speaks a different signal. I label both ends of every HDBaseT cable, so nobody patches one into a network switch.
HDBaseT needs well terminated Cat6A; termination and testing are on my copper cabling page.
Dante, made by Audinate, is the most common way to carry live audio over Ethernet. Devices share one clock using PTP (Precision Time Protocol), and audio moves in flows, unicast to one receiver or multicast to many. AES67 is the open standard that lets Dante talk to other systems. Watch the clock and both kinds of flow on one switch.
Swipe sideways to see the whole diagram.
Pink packets are PTP (Precision Time Protocol) sync from the leader clock to every follower. Orange is a unicast flow from the stagebox to the desk. Teal is one multicast flow from the desk that two receivers share. Grey is Dante Controller talking to the devices.
| Item | What Dante uses |
|---|---|
| Clock | PTP version 1 (IEEE 1588 version 1) by default, multicast to 224.0.1.129 to 224.0.1.132 on UDP (User Datagram Protocol) ports 319 and 320. PTP version 2 is used for AES67. |
| Audio, multicast | Addresses in 239.255.0.0/16 on UDP 4321. About 1.5 Mb/s for each channel. |
| Audio, unicast | Up to 4 channels in each flow, about 6 Mb/s for a typical flow. Each receiver needs its own copy. |
| QoS (quality of service) | DSCP (Differentiated Services Code Point) 56, CS7 (Class Selector 7), for time critical PTP events; 46, EF (Expedited Forwarding), for audio and PTP version 2; 8, CS1 (Class Selector 1), reserved; everything else best effort. Strict priority queues. |
| Latency | Set per receiver in Dante Controller. It decides how many samples each packet carries, from 4 to 64 per channel. |
| Redundancy | Devices with two ports can join a primary and a separate secondary network. With no DHCP (Dynamic Host Configuration Protocol), secondary ports take addresses from 172.31.0.0/16. |
| Switch settings | Gigabit ports, Energy Efficient Ethernet (EEE, 802.3az) turned off, IGMP (Internet Group Management Protocol) snooping with one querier per VLAN (virtual local area network), and QoS that trusts DSCP. |
From Audinate's guidance for network administrators and a microphone maker's switch guide. Bandwidth figures are approximate and vary with sample rate and latency setting.
A sketch for a Catalyst access switch in the AV VLAN. Catalyst 9000 switches trust DSCP by default. I check every line against the platform guide before I use it.
ip igmp snooping
ip igmp snooping querier
ip igmp snooping querier address 10.40.0.2
!
class-map match-any AV-PTP
match dscp cs7
class-map match-any AV-AUDIO
match dscp ef
policy-map AV-EGRESS
class AV-PTP
priority level 1
class AV-AUDIO
priority level 2
!
interface range GigabitEthernet1/0/1 - 24
description Dante devices
switchport access vlan 40
service-policy output AV-EGRESSWhat I run after the change, and again whenever audio clicks or drops.
show ip igmp snooping querier
show ip igmp snooping groups vlan 40
show policy-map interface GigabitEthernet1/0/10
show interfaces GigabitEthernet1/0/10 counters errorsSome switch ranges ship with AV profiles. NETGEAR's AV Line, for example, offers port profiles for Dante, AES67, NDI and other systems, and IGMP Plus, which sets up multicast between linked switches by itself. I still check what each profile changes, because the defaults suit a single AV island rather than a shared campus network.
| AES67 | SMPTE ST 2110-30 | |
|---|---|---|
| Published by | The Audio Engineering Society, 2013 | SMPTE (Society of Motion Picture and Television Engineers), as the audio part of ST 2110 |
| Clock | PTP default or media profile | The SMPTE ST 2059 media profile only |
| Transport | Unicast or multicast | Multicast only |
| Packet time | 1 ms required, for 1 to 8 channels at 48 kHz | Level A and B at 1 ms and 0.125 ms, Level C at 0.125 ms for up to 64 channels |
| Bit depth | 16 or 24 bit | 24 bit only |
| Dante in AES67 mode | Multicast, 1 ms, 48 kHz, 24 bit, up to 8 channels, announced with SAP (Session Announcement Protocol) | Works when the ST 2110-30 device accepts those settings and SAP |
Summarised from a comparison by the Alliance for IP Media Solutions (AIMS). Two devices that both claim AES67 or ST 2110-30 support may still need settings matched by hand.
Every Dante device follows one leader clock, chosen automatically or set by hand. I set a stable device with good holdover as the preferred leader, so the clock does not move when a laptop joins.
Dante uses unicast by default. When one source feeds many receivers, I make it a multicast flow, and then IGMP snooping and a querier stop that flow reaching every port.
Audinate's Dante Domain Manager adds user logins, roles, audit logs and domains that can span subnets. I use it where many teams share one AV network, such as a campus or a venue.
For the analogue end of the chain, from microphones and gain to loudspeakers, see my live sound page.
Video is far heavier than audio, so every video over IP system trades bandwidth against delay and detail. Uncompressed video needs 10 gigabit links. Light compression fits 4K onto 1 gigabit. Streaming codecs fit almost anywhere, with a little delay. Choose a technology to see what one stream needs.
Swipe sideways to see the whole diagram.
Eight channels of Dante audio as one multicast flow need about 12 Mb/s. A whole mixing desk worth of audio fits easily on a gigabit link, which is why audio moved to networks first.
NDI HX compresses video with H.264 or H.265, the codecs used for streaming. A 1080p stream at 60 frames needs about 10 Mb/s, so PTZ (pan, tilt, zoom) cameras and remote sources can run over modest links, with a little more delay.
Full bandwidth NDI uses a light codec called SpeedHQ. One 1080p stream at 60 frames needs about 150 Mb/s, so a gigabit link carries a handful of streams with headroom. The NDI certification target is under 100 ms from glass to glass.
1 gigabit AV over IP, such as Crestron DM NVX or Kramer KDS-7, compresses 4K at 60 frames to fit a 1 Gb/s port. Each stream can take most of that port, so I give every encoder and decoder its own port and plan the uplinks carefully.
SDVoE sends HD (high definition) and 4K at 30 frames uncompressed, with transport delay under 100 microseconds, and needs a 10 Gb/s port for each endpoint. It suits control rooms and live venues, where any delay shows.
Uncompressed 4K at 60 frames with full colour is about 12 Gb/s: 3840 by 2160 pixels, 24 bits each, 60 times a second. That is why every system above compresses, or uses links faster than 10 gigabits.
| Technology | Network | Compression | Delay | Where I use it |
|---|---|---|---|---|
| SDVoE | 10 Gb/s Ethernet | None for HD and 4K30, light for 4K60 | Under 100 microseconds of transport | Control rooms, venues, anywhere a mouse or a performer must feel instant |
| Crestron DM NVX | 1 Gb/s Ethernet | Visually lossless, 4K60 with full colour and HDR (high dynamic range) | Very low, as the maker states | Meeting rooms, lecture theatres and campuses on Crestron control |
| Kramer KDS-7 | 1 Gb/s Ethernet | 4K60 with 4:2:0 colour | Low; I check the maker's figure for each model | Meeting rooms and education spaces on Kramer systems |
| NDI | 1 Gb/s Ethernet | SpeedHQ, light | Under 100 ms target | Production, streaming and capture |
| NDI HX | Any IP network | H.264 or H.265 | 100 to 150 ms targets | PTZ cameras, remote sources, Wi-Fi |
| SMPTE ST 2110 | 10, 25 Gb/s and faster | None (ST 2110-20) or JPEG XS (ST 2110-22) | Very low | Broadcast facilities and outside broadcast |
Delays are the targets and claims each standard or maker publishes, not measurements. NDI targets are from the NDI certification guidelines.
Encoders and decoders from one family usually only talk to each other, unless they share a standard such as SDVoE or NDI. I pick one video family for a site and write it into the standards, so rooms built years apart still work together.
Ten 1 gigabit decoders on one access switch can each pull a different stream. The uplink must carry all of them, so I size uplinks from the busiest realistic case, not the average.
HDCP (High bandwidth Digital Content Protection) 2.x can cross a network, but HDCP 1.x cannot. Sources that play protected films or streaming services need an encoder and displays that support the right version.
AV over IP puts constant, heavy multicast onto switches that were built for bursty office traffic. Get multicast, QoS and power right and the AV system disappears into the background. Get multicast wrong and one video system can slow a whole building. Step through how IGMP snooping and the querier keep streams where they belong.
Swipe sideways to see the whole diagram.
With IGMP snooping off, a switch treats multicast like broadcast and sends every stream out of every port in the VLAN. The office PC and the printer each receive a video stream they never asked for. With a few 1 gigabit video streams, their ports fill up and the network slows for everyone.
Each decoder that wants a stream sends an IGMP membership report for that group address. With snooping on, the switch reads these reports and notes which ports want which groups.
Now the switch forwards each stream only to the ports that joined it. The office PC and the printer get nothing. This one setting is the difference between an AV network that works and one that takes down the building.
Snooping entries do not last forever. With standard timers, a membership ages out after about 260 seconds unless it is refreshed, and only a querier asks for refreshes. Without one, streams stop after a few minutes, or the switch floods them again, depending on the make.
One device per VLAN, usually the core or AV switch, acts as the IGMP querier. It sends a general query on a timer, the decoders answer with reports, and the snooping table stays current. I set the querier on purpose rather than leave it to chance.
When decoder 2 switches to another source, it sends a leave for the old group. With fast leave on, the switch stops that stream on the port at once, so changing channel does not briefly double the traffic.
Choose how many video or audio streams run in the AV VLAN, then turn IGMP snooping and the querier on or off. The tool shows what each kind of port receives, assuming every port is 1 gigabit and each decoder watches one stream.
Every port is nearly full. With snooping off, six NDI streams flood 900 Mb/s to every port in the VLAN, including printers and PCs that never asked for them. One more stream and the ports drop packets.
| Area | What I set, and why |
|---|---|
| Separation | A dedicated AV VLAN, or a physically separate network for large systems, so AV multicast and office traffic never compete. Dante redundancy needs a second network that shares no switches with the first. |
| Multicast | IGMP snooping on every switch, one querier per VLAN placed on purpose, fast leave for video, and unknown multicast not flooded. PIM (Protocol Independent Multicast) only if streams must cross subnets. |
| QoS | Trust DSCP from AV devices, with strict priority for clock and audio. Video classes below audio. Configured end to end, including uplinks. |
| Capacity | Non blocking switches, 1 gigabit for each endpoint (10 gigabit for SDVoE), and uplinks sized for the busiest realistic case. |
| Power | A PoE (Power over Ethernet) budget per switch for encoders, decoders, cameras, microphones and touch panels, with headroom for growth. |
| Stability | Energy Efficient Ethernet off on AV ports, edge ports set to come up at once, and storm control set so it never trips on legitimate multicast. |
| Management | AV devices on their own management addresses, default passwords changed, and access only from the AV and network teams. |
Many AV over IP failures come from two teams each assuming the other set something. I agree in writing who owns the AV VLAN, the querier, the QoS policy and the switch firmware.
A ping test proves nothing for multicast. Before handover I run every encoder at once, switch decoders between sources and watch the port counters on office ports stay quiet.
I keep a record of every multicast group, which encoder sends it and which VLAN it lives in, so a new system never reuses an address by accident.
The switching basics behind this are on the switching page, multicast routing is on the routing page, and queuing is on the QoS and traffic shaping page.
A room full of AV only works if one simple panel drives it. A control processor turns a button press or a booking into the right commands for every device, and reads back their status. Watch one press start a room.
Swipe sideways to see the whole diagram.
Cyan is a button press on the touch panel, and purple is a booking that starts the room on time. Orange packets are the commands the processor sends: display on, camera to its preset, microphones unmuted, lights to presentation. Teal packets are feedback, so the panel shows what really happened.
| Platform | Typical use | How it is programmed and managed |
|---|---|---|
| Crestron | Corporate rooms, lecture theatres, large venues | Control processors and touch panels programmed by certified programmers; Crestron XiO Cloud for remote management |
| Kramer Control | Meeting rooms and education spaces | A cloud based platform launched in 2016, configured through a web builder rather than code |
| Kramer QuickLaunch | One touch meeting start on a room PC or interactive display | Software with a branded dashboard of tiles for meetings, apps and content, plus room reset and a lockdown mode |
| Control4 | Homes and small offices | Dealer installed automation for AV, lighting, climate and security |
| Link | What it carries | What I watch for |
|---|---|---|
| RS-232 | Serial commands to displays, projectors and matrix switchers | Baud rate, a null modem cable or not, and a command set that differs between models |
| IR (infrared) | Remote control codes, sent by an emitter stuck over the sensor | One way only: the processor cannot know whether the display really turned on |
| IP control | Commands over TCP (Transmission Control Protocol) or HTTP (Hypertext Transfer Protocol) to displays, cameras, DSPs (digital signal processors) and switchers | Fixed addresses or DHCP reservations, and the device's own password |
| Relays and contacts | Screens, blinds and lighting circuits | Interlocks so a screen motor cannot drive both ways at once |
People want three things: start, share and end. I put those on the first screen and hide engineering controls behind a PIN (personal identification number).
Where a device can report its state, I use two way control, so the panel never shows a display as on when it is off.
A good meeting room starts in one touch, lets anyone share a screen without a cable, and sounds clear to the people who are not there. Most of the work is in the audio. Watch how a DSP stops the far end hearing its own voice.
Swipe sideways to see the whole diagram.
Cyan is the far end voice and video coming in. Red is the same voice returning from the loudspeakers into the microphones as an echo. Orange is the person in the room. AEC (acoustic echo cancellation) in the DSP subtracts the echo, so only orange goes back. Purple is a laptop sharing to the display wirelessly.
| Teams Rooms on Windows | Teams Rooms on Android | |
|---|---|---|
| Hardware | A small PC as the hub, a touch console, and certified cameras, microphones and speakers chosen for the room | An all in one video bar with the computer, camera, microphones and speakers inside |
| Best fit | Larger and more complex rooms | Small and medium rooms with a simpler set up |
| Cost and effort | Usually more to buy and more to support | Usually less to buy and less to support |
| Features | Usually gets new features first, such as two screen modes | Has caught up on many features, such as two screens and wireless sharing |
From a reseller comparison. Microsoft publishes a feature comparison that changes often, so I check it at design time.
A native room runs Teams or Zoom on its own system. BYOD (bring your own device) and BYOM (bring your own meeting) rooms let people plug their laptop into the room camera, microphones and display over USB. I decide per room type, then standardise.
Kramer VIA shares from an app, a web browser, AirPlay or Miracast, and supports Zoom, Teams and Google Meet. Barco ClickShare works the same way. Either removes the HDMI cable hunt at the start of a meeting.
Remote people forgive a soft picture but not bad audio. Ceiling arrays with beamforming keep tables clear. Every microphone feeds the DSP, and AEC uses the loudspeaker feed as its reference.
The display must suit the person at the back, not the person at the front. The DISCAS (Display Image Size for 2D Content in Audiovisual Systems) standard, ANSI/AVIXA V202.01, sizes the image from the farthest viewer and the smallest detail they must read. AVIXA is the Audiovisual and Integrated Experience Association, and ANSI the American National Standards Institute.
Enter the distance from the screen to the farthest seat and what people will look at. The tool applies the long standing rule of thumb: the farthest viewer sits no more than 8 image heights away for video, 6 for presentations and 4 for detailed work. For a real design I use the AVIXA DISCAS calculators.
An 85 inch display. For slides read from 6 m away, the image needs to be at least 1 m tall. The next common size up is 85 inches. Above about 100 inches I look at a projector, an LED (light emitting diode) wall or a second screen part way down the room.
Education rooms are used by different people every hour, and many are recorded or streamed. They need to be simple, identical and accessible, including for people who use hearing aids.
Rooms that record or stream every lecture need a camera that follows the presenter, a feed of the slides and clean audio, all sent to a capture platform such as Panopto. Kramer VIA can also stream to YouTube, Kaltura and Panopto over RTMP (Real Time Messaging Protocol).
Students in the room and online must hear each other. That means microphones that cover the room, not just the lectern, and a display or speaker where the online students appear.
A university may have hundreds of teaching rooms. I define a few standard room types, each with the same panel, the same equipment and the same network template, so support staff can fix any room.
| Item | What I plan for |
|---|---|
| The law | The Equality Act 2010 expects hearing loops where reasonably possible. British Standard BS 7594 is the UK design and installation guide, and the International Electrotechnical Commission (IEC) standard IEC 60118-4 sets the performance a loop must meet. |
| Design | Loop type by room shape, with phased arrays where steel in the building weakens the field or sound would spill into the next room. |
| Signal | A clean feed from the DSP, the same mix the room hears, not a room microphone. |
| Checks | A field strength meter test against IEC 60118-4 at handover, and signs that tell people the loop is there. |
Kramer's Education Spaces and Solutions Designer course covers these room types. The networks under them are on the Janet and education networks page.
CCTV (closed circuit television) is now mostly IP cameras, PoE switches and network video recorders: AV over IP with a legal duty attached. The network design is familiar. The difference is that footage is personal data and may be evidence, so retention and access matter as much as the picture. Choose a part to see what I decide there.
Swipe sideways to see the whole diagram.
Each IP camera compresses its picture, usually with H.265, and sends one or more streams: a high quality stream to record and a lighter one to view. Resolution, frame rate, codec and how much the scene moves set the bitrate, and the bitrate sets everything downstream.
A PoE switch powers the cameras over the same cable that carries the video. I keep cameras in their own VLAN, block them from the internet, and check the PoE budget, because outdoor cameras with heaters and infrared lights draw more power than indoor ones.
The NVR (network video recorder) writes every stream to disk, continuously or when it sees motion. Disks run in RAID (redundant array of independent disks) so one failed disk loses nothing. Storage is sized from bitrate, hours and days, as the calculator below shows.
Footage is personal data. I set a retention period the organisation can justify, let the recorder overwrite after it, and limit live and recorded viewing to named people. Exports are logged, so every copy that leaves the system can be traced.
Storage is the cameras multiplied by their bitrate, the hours they record and the days you keep. Bitrates here are indicative for H.265; the real figure depends on the scene, the frame rate and the camera's settings, so I measure a sample before buying disks.
About 20.7 TB of usable space. 16 cameras at about 4 Mb/s, recording all day for 30 days. Add the space RAID uses and 10 to 20% free space, so the recorder never runs full.
| Rule | What it means for a design |
|---|---|
| UK GDPR (General Data Protection Regulation) | CCTV that captures people processes personal data. The Information Commissioner's Office (ICO) guidance on video surveillance sets out what to do: a clear purpose, a data protection impact assessment, signs, short retention and secure access. |
| Surveillance Camera Code of Practice | Issued under the Protection of Freedoms Act 2012 and updated in 2021, with 12 guiding principles. Police and local authorities must have regard to it, and others are encouraged to follow it. |
| Government sites | In November 2022 the UK government told its departments to stop installing Chinese made surveillance cameras on sensitive sites. I check client policy before specifying any camera brand. |
Higher resolution and frame rate raise the bitrate, and the bitrate decides the switch uplinks, the recorder and the disks. I set frame rates to what the purpose needs: 12 to 15 frames a second is enough for many scenes (typical).
A main stream to record and a sub stream to view keep viewing stations and remote access light. Video walls ask for the sub stream unless an operator zooms in.
Cameras and recorders have a long history of default passwords and old firmware. I change every password, update firmware, block internet access and allow only the recorder and viewing stations to reach the cameras.
Most black screens in AV are not broken cables. They are a source and a display that never agreed on a format, or content protection that failed somewhere in the chain. Step through what happens between plugging in and seeing a picture.
Swipe sideways to see the whole diagram.
When a cable is connected, the display raises the hot plug detect line. The source now knows something is there and starts the conversation. A switcher or encoder in the middle does the same towards the source.
The source reads EDID (Extended Display Identification Data) over the DDC (Display Data Channel): the resolutions, frame rates and audio formats the display accepts. An encoder or switcher often presents a fixed EDID of its own, so the source does not change resolution every time a route changes.
If the content is protected, the source checks that the next device holds valid HDCP keys before it sends anything. With HDCP 2.x this includes a timing check, which stops protected video being sent to a device far away.
A switcher or encoder is an HDCP repeater. It authenticates every display after it, then reports the number of devices and the depth of the chain to the source. HDCP 2.x allows up to 32 devices and 4 levels of repeaters.
Only when every link is authenticated does the source send encrypted video. If one display fails, or the chain is too big, the source blanks protected content, which looks exactly like a cable fault.
| HDCP 1.x | HDCP 2.x | |
|---|---|---|
| Devices after the source | About 127 | 32 |
| Levels of repeaters | 7 | 4 |
| Across an IP network | No | Yes |
| Typical content | HD video | 4K streaming and discs, which often require HDCP 2.2 end to end |
Limits from AV makers' HDCP guidance. Each encoder and decoder also has its own limit, so I check the maker's figures for a large distribution.
I set a fixed EDID on each encoder input, usually 1080p60 or 4K60 to match the displays, so laptops do not flicker or change resolution when a route changes.
Office presentations rarely need HDCP. Media players and streaming boxes always do. I keep protected sources on routes whose every device supports the right HDCP version, and never send them to a capture card or a streaming encoder, which will refuse them.
Before handover I play protected content to the largest group of displays at once, because that is the route most likely to break the device count.
Every encoder, camera, touch panel and room PC is a networked computer, often with a web server, a default password and firmware nobody has updated. I treat the AV estate like any other part of the network.
| Risk | What I do about it |
|---|---|
| Default passwords | Every encoder, decoder, camera, DSP, panel and switch gets its own password before it reaches the network. Many AV devices ship with the same password on every unit. |
| Flat networks | AV devices sit in their own VLAN, with their management interfaces in a separate one. Only the AV team, the control processor and the monitoring system can reach them. |
| Old firmware | A firmware register for every AV device, reviewed alongside network patching. AV firmware is often years behind because nobody owns it. |
| Cloud management | Tools such as Crestron XiO Cloud, Kramer VIA Site Management and Kramer Control save site visits, but each one is a path into the building. I review where each connects, use single sign on where offered, and allow only the outbound connections it needs. |
| Room PCs | A Teams Rooms system on Windows is a Windows computer. It is patched, monitored and protected like one, as on my end user computing page. |
| Guest sharing | Wireless presentation devices that guests use sit on a network that cannot reach internal systems, with a code shown on the room display before anyone can share. |
| Audio networks | Dante Domain Manager adds logins, roles and audit logs, so a laptop with Dante Controller cannot reroute a venue's audio. |
The wider controls behind this, such as segmentation and access control, are on the security page.
AV over IP faults look alike from the room: no sound, no picture, a click, a flicker. Underneath they fall into a few groups, and most of them live in the network or the handshake. Choose a symptom to see where it usually sits and what I check first.
Swipe sideways to see the whole diagram.
Dante audio clicks or drops out. Usually the clock. Energy Efficient Ethernet is on, PTP is not prioritised, or a hop has errors. I check Clock Status in Dante Controller, turn EEE off, confirm the QoS policy puts PTP first, and check the port counters for errors.
The office network slows when the AV system starts. Multicast is flooding: IGMP snooping is off, or the AV traffic shares a VLAN with office devices. I check the snooping table, move AV into its own VLAN and confirm the querier.
Streams work, then stop after a few minutes. There is no querier, so memberships age out. I enable a querier on the core or AV switch for that VLAN, then rejoin the decoders and watch the table stay populated.
One display stays black while others work. Usually HDCP: the display or a converter does not support the version the content needs, or the chain is too long. I check HDCP status on the decoder, test a source without protection, and replace or bypass the weak link.
The laptop flickers or rearranges its screens when anyone changes a route. The encoder is passing through each display's EDID. I set a fixed EDID on the encoder input to match the displays, so the source sees one stable display.
Remote people hear their own voice a moment later. The echo canceller is not getting the right reference, or the loudspeakers are so loud that it cannot keep up. I check that AEC uses the far end feed as its reference, lower the loudspeaker level and move microphones away from loudspeakers.
A camera or decoder reboots at random. The switch has run out of PoE budget, or the device asks for more than its class. I check the budget and each port's draw, move devices to a switch with more power, and set priorities so critical devices are powered first.
| Question | Tool or command | What it tells me |
|---|---|---|
| Is the Dante clock healthy? | Dante Controller, Clock Status and Network Status tabs | Which device leads, which follow, and any sync or latency errors |
| Which ports joined which streams? | show ip igmp snooping groups vlan 40 | Every multicast group and the ports it is sent to |
| Is there a querier? | show ip igmp snooping querier | The querier's address, or nothing at all |
| Is QoS working? | show policy-map interface GigabitEthernet1/0/10 | Packets matched and dropped in each class |
| Is the cable or port bad? | show interfaces GigabitEthernet1/0/10 counters errors | CRC (cyclic redundancy check) and other errors on the link |
| Is the switch out of power? | show power inline | The PoE budget and what each port draws |
| Is the picture protected? | The encoder or decoder web page, or an HDMI analyser | HDCP version and status, and the EDID in use |
I change one thing at a time and repeat the same test after each change. My general method is on the troubleshooting page, and every acronym here is in the glossary.
AV over IP work usually arrives as a new building, a refresh of tired meeting rooms, a move to hybrid teaching or a venue that wants every room to talk to every other. I follow the same path each time. I agree what each room must do, survey what is there and design one standard per room type on one network. Then I prove it in pilot rooms and hand it over with monitoring in place.
Swipe sideways to see the whole diagram.
I start by agreeing what each kind of room or space must do: meet, teach, present, broadcast or watch. I record who decides in a RACI (responsible, accountable, consulted, informed) chart, and bring the AV, network, security and support teams together from the first meeting, because AV over IP crosses all four.
I turn each room type into requirements: what it must do, and how well. That means picture quality, audio clarity for remote people, delay limits, the time to start a meeting, accessibility such as hearing loops, and which sources carry protected content. Each target has an owner who signs it off.
Before designing anything I survey every room's size, acoustics, sightlines and power, the cable routes and distances, and the switches the AV would use, with their PoE budget and multicast settings. I list every existing AV device with its firmware, so I know what to keep, upgrade or retire.
The high level design sets a standard for each room type and the AV network beneath them: VLANs, multicast, QoS and power. The low level design covers signal flow drawings, addresses, switch configurations and panel layouts, with a test plan agreed in advance that includes the busiest realistic case.
I build one room of each type as a pilot, run every encoder at once, switch routes, play protected content to the largest group of displays and make test calls. Only then does the roll out continue in waves through change control, with as built drawings for every room.
Before handover every AV device is in monitoring, through cloud management or the network tools, with alerts for offline devices and clock errors. Support teams get room runbooks and swap out spares, and users get a one page guide in each room. Hypercare ends when the agreed criteria are met.
AV devices need firmware updates like any computer, and room needs change with how people work. I review usage and faults each quarter, patch firmware on a schedule, update the room standards each year, and plan refresh by room type so no room falls years behind the others.
What it must do.
How well it must do it, with a number wherever one can be agreed.
Numbers are typical starting points. Each organisation agrees its own with its users.
| Tool or source | What it tells me |
|---|---|
| A laser measure and a sound level meter | Room sizes, viewing distances and background noise |
show ip igmp snooping groups and show power inline | Multicast state and the PoE budget on each switch |
| Dante Controller | Existing Dante devices, clocks and flows |
| Crestron XiO Cloud or Kramer management tools | Device inventory, firmware and usage, where already in place |
| An HDMI analyser | How existing sources and displays handle EDID and HDCP |
| Help desk reports | Which rooms and faults generate the most calls |
Most AV over IP faults turn out to be multicast, the clock or the handshake, so I separate those three early.
| Layer | What I check |
|---|---|
| 1 · Physical | Cat cable quality and length, HDBaseT distance limits, and loose connectors at displays and floor boxes. |
| 2 · Data link | The AV VLAN, IGMP snooping, the querier, storm control and Energy Efficient Ethernet, using show ip igmp snooping groups. |
| 3 · Network | Addressing, DHCP reservations, and multicast routing with PIM if streams cross subnets. |
| 4 · Transport | Dante and NDI flows, latency settings and dropped packets, seen in Dante Controller and NDI tools. |
| 5 to 7 · Application | EDID, HDCP, control system logic, DSP settings and the meeting platform itself. |
My general method, with worked faults, is on the troubleshooting page.
AV over IP is shared between the AV and network teams. I agree who does what before the first room goes live.
The service desk takes the call, AV support owns rooms and devices, network operations owns switches, and each knows when to call the other.
Offline devices, Dante clock errors, PoE alarms and room usage, with alerts tuned during hypercare, the period of extra support after go live.
A runbook per room type, starting with the checks a service desk can do remotely, such as rebooting a decoder or resetting a room.
A stock of encoders, decoders, panels and cables, so a failed device is swapped in minutes and repaired later.
Every firmware update, switch change and new route goes through change control, tested first in a pilot room.
A regular review of faults, usage and user feedback, which feeds the room standards.
AV devices age faster than cabling and slower than laptops. I plan their upkeep from the start.
My AV over IP knowledge comes from Kramer's courses and other AV training, and from more than twenty years of designing the networks that AV now runs on. These are the credentials and the work behind this page.
AV over IP Installer and AV over IP Sales Associate: encoders, decoders and the network they depend on, and how systems are specified and installed.
Control System Designer, QuickLaunch Configuration 102, QuickLaunch Installer and VIA Sales Installer for control and meeting rooms, with Audio Specialist, Education Spaces and Solutions Designer and AV Fundamentals.
My CV lists Kramer Certified Expert, Crestron, Control4 and Honeywell BMS (building management systems) under delivery, buildings and AV. I also hold Hikvision's CCTV Expert certification.
LAN (local area network), WAN (wide area network) and cloud for multi site real estate and construction, with BACnet/IP building automation and IoT (Internet of Things) sensor networks.
Cisco 3750 PoE switches power the IP phones, with Cisco Unified Communications Manager carrying calls across an MPLS (Multiprotocol Label Switching) core. Voice QoS and PoE budgets work the same way for Dante and AV over IP. See the topology.
In my own time I stream and record with Blackmagic ATEM switchers, from the ATEM Mini series to a larger ATEM with SDI (serial digital interface), and PTZ and cinema cameras. More on the live streaming page.
Backed by CCNP (Cisco Certified Network Professional) Enterprise and the CCIE (Cisco Certified Internetwork Expert) Routing and Switching written exam for the multicast and QoS underneath, and CCVP (Cisco Certified Voice Professional) for voice. See all credentials
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.