AV-over-IP & Network Design

Introduction

A design is a set of decisions somebody else can build from. That is the whole of it, and it is why this book exists separately from the one before it. AV Networking Intermediate teaches you to configure the switch in front of you. This book is about the decisions made weeks earlier — how many switches, of what speed, in what shape, carrying how many streams, with which addresses, and what happens when one of them dies.

Those decisions used to belong to somebody else. An AV designer chose a matrix, counted its inputs and outputs, and drew cables to it. The matrix did the hard part. On a network there is no matrix: the switch fabric is the matrix, and its capacity, its shape and its failure behaviour are all now yours to specify. A great deal of matrix design skill transfers directly. What does not transfer is the arithmetic, and that is most of this book.

It covers choosing a standard and understanding what that commits you to, sizing links from real figures, topology, the addressing and multicast plan, what happens when AV has to cross a subnet, redundancy that protects against failures which actually occur, and the package you hand over at the end.

How to Use This Book

Read it in order the first time. It runs the way a design job runs: understand the technology, take the brief, size it, shape it, address it, protect it, build it, prove it, and hand it over.

Keep a notebook

Keep one page per design you work on, with four things: the stream count and per-stream bandwidth you used, the busiest link and what crossed it, the topology you chose and why, and the thing you got wrong. The last column is the one that makes you good at this. Designs fail in a small number of repeated ways and your own list of them is worth more than any checklist here.

A note on the words

"Design" means two different things in this trade and the gap causes arguments. To an AV integrator it often means the drawing package — the deliverable. To a network engineer it means the architecture — the decisions. This book uses it in the second sense throughout, and calls the deliverable the design package. Likewise "AV-over-IP" is used here for any system that carries production audio or video as packets, which includes Dante and ST 2110 even though neither is usually marketed with that phrase.

A note on safety

Design decisions made at a desk become physical work for somebody else, and that is where this subject's hazards live. A switch specified into a ceiling void means ladder work, often alone and often over seating, so a design that puts active equipment where it cannot be safely reached has created a hazard rather than solved a problem. A fully loaded chassis switch is a two-person lift into a rack, and specifying one into a rack position above shoulder height commits somebody to doing that. Rack power is mains power, and a design that fills a rack without allowing for its load and its heat is a fire risk, not an inconvenience — the electrical and HVAC part of the design is a safety matter.

One hazard belongs to networked audio specifically and is worth naming at design stage because that is where it can be prevented. A clock failure or a routing mistake can put full-scale digital noise into a PA with no warning and no fade, and anybody wearing in-ears when it happens is at real risk of hearing damage. Designs that allow a single clock source, or that let one mistake reach every output at once, are designs that make that outcome more likely. Nothing here qualifies you to do electrical work or to sign off a structural fixing.

What AV-over-IP Actually Is

Three boxes: an encoder, a network, a decoder. Everything in this book is about the middle box, and the reason the middle box is hard is that it is the first part of an AV system that is shared with strangers.

Audio and video become data on a network — and that changes everything about how systems are built.

Encoder, network, decoder

A source — a camera, a playback machine, a console output — reaches an encoder, which turns the signal into a stream of packets. The network carries the packets. A decoder at the far end turns them back into a signal for a screen or a speaker. That is the shape of every AV-over-IP system without exception, and when you are lost in a system diagram, finding the encoders and decoders will orient you.

Two things about the edges matter at design time. The encoder decides the bandwidth and most of the latency, so the choice of encoder is a network decision disguised as an AV one. And the decoder is where the system's behaviour under stress becomes visible: a decoder starved of packets freezes, tears or goes black depending on what it was built to do, and knowing which it does tells you what a congestion event will look like on the day.

Some systems hide the encoder and decoder inside other things. A networked audio card in a console is an encoder; a screen with a receiver module built in contains a decoder. The shape has not changed, only the packaging.

What changed for the person who used to specify a matrix

If you used to specify a matrix, you already have most of this skill. You counted sources and destinations, checked the matrix had enough of each, worked out the cable lengths, and specified a device whose internal capacity was somebody else's problem. The parts that transfer are the counting and the discipline of working from a signal list.

The part that does not transfer is that a matrix of 32 by 32 either has the capacity or does not, and the datasheet says so. A network's capacity depends on where the traffic goes. Thirty-two sources and thirty-two destinations on one switch is trivial; the same counts split across three buildings is a different and much harder problem, because now the question is how much has to cross each link between them. That question has no answer on a datasheet. You work it out.

The other change is that the matrix was yours and the network very often is not. A matrix in your rack does what you configured. A network shared with a hospital, a bank or a university does what its owners permit, and the design has to be something they will agree to. That is a political skill as much as a technical one and it has a chapter of its own.

How to do it

1. Find the encoders and list them; that is your source count and your bandwidth.
2. Find the decoders and list them; that is your destination count.
3. Read one encoder's datasheet for its bit rate and its latency figure.
4. Draw the links between groups of devices, not the devices themselves.
5. Mark which link carries the most, because that is the design's real constraint.
6. Ask who owns each switch, and write the answer next to it.

What goes wrong

Practice it

On any AV-over-IP system you can get a drawing of.

The Standards and What They Cost

Choosing the standard is the first design decision and it fixes nearly every later one. Get it right and the rest of the design is arithmetic. Get it wrong and no amount of switch budget will save it.

The trade each one makes

Bandwidth, latency and quality are not three separate requirements. They are one budget shared three ways, and every AV-over-IP system picks a point in it: how much it compresses against how much latency and quality that costs. There is no system that is light on bandwidth, instant and pristine, and a brief that asks for all three is asking for something that does not exist. Every design decision from here will spend latency to save bandwidth, or the reverse.

Uncompressed systems send the pixels. Latency is a line or two of video, quality is perfect, and the bandwidth is enormous — gigabits per feed. Lightly compressed systems use a codec designed for low latency and visually lossless results, landing in the hundreds of megabits with a frame or less of delay. Heavily compressed systems use the codecs built for distribution, fit in single-digit megabits, and cost tens or hundreds of milliseconds, which is fine for a screen somebody is watching and useless for anything a presenter sees themselves on.

Audio sits outside this argument because audio is small. A channel is about a megabit, so nobody compresses production audio for bandwidth reasons. Audio's constraints are latency and clock, not capacity, and that is why networked audio and networked video are designed against different limits even when they share a switch.

What is actually in use

Dante for audio, by a wide margin, with AES67 as the interoperability layer that lets Dante exchange audio with other manufacturers' systems. AVB and Q-LAN appear in installed systems and have their own switch requirements. CobraNet and EtherSound are legacy and you will meet them in buildings that were fitted out fifteen years ago.

For video the landscape is messier. SMPTE ST 2110 is the broadcast standard and separates video, audio and data into their own streams. SDVoE is a hardware-based approach aimed at matrix replacement with very low latency. NDI dominates production and streaming workflows where convenience matters more than the last millisecond. And there is a long list of manufacturer-specific systems aimed at the same job as SDVoE, each with its own bit rate and its own switch requirements.

The designer's position on all of this should be unsentimental. You do not need to know how each codec works. You need, for whatever is specified, four numbers: bit rate per stream, latency, whether it uses multicast, and what it requires of the switch. If the manufacturer cannot give you those four, that is itself a finding worth reporting.

SMPTE ST 2110, and what asking for it commits you to

ST 2110 deserves its own section because the phrase gets used in briefs by people who have priced neither the network nor the engineering. It is the right answer for broadcast facilities and it is a serious commitment.

Uncompressed video means gigabits per feed, so ST 2110 is a 25-gigabit or faster design in practice, with switches to match. It requires precise PTP, usually with dedicated grandmasters and boundary clocks, because the standard's whole model depends on everything agreeing on time. It separates each feed into several streams, which multiplies the multicast group count and makes the address plan a real piece of work rather than an afterthought. And it generally wants a network designed for it rather than one adapted to it.

So when ST 2110 appears in a brief, the honest response is a question: is this a broadcast facility, and is there a budget for a broadcast network? If yes, it is correct and this book's chapters on addressing, clock and redundancy all apply with the dial turned up. If the answer is that somebody liked the sound of it, a lightly compressed system will do the job on infrastructure that costs a fraction as much, and saying so early is worth a great deal to everybody.

How to do it

1. Write down the real latency requirement, separating what is needed from what was asked for.
2. Write down the quality requirement in terms of what the content is, not a resolution number.
3. Ask whether anything is going to broadcast or to a facility that already runs ST 2110.
4. Get bit rate, latency, multicast behaviour and switch requirements for each candidate.
5. Multiply the bit rate by the stream count and see which candidates the budget can carry.
6. Choose, write down why, and put the rejected options in the design package with their reasons.

What goes wrong

Practice it

For a system you have worked on or a brief you have seen.

Bandwidth Planning at Scale

Three numbers decide whether a design works: per-stream bandwidth, how many streams cross the busiest link, and what that link can carry. Two of them come from documentation and one you work out. Nothing in this chapter is difficult; it is just routinely not done.

Different AV-over-IP standards make different trade-offs, and all of them need bandwidth.

Per stream, from the datasheet

Start with one stream. For audio it is arithmetic you can do in your head: sample rate times bit depth, so 48 kHz at 24 bits is 1.152 megabits per channel of payload, and allowing about 1.5 megabits per channel covers the packet overhead at normal latency settings. Sixty-four channels is therefore about 96 megabits, and a gigabit link carries that ten times over.

For video, do not calculate — look it up. Uncompressed you can compute, because it is pixels times frames times bits: 1080p60 at 4:2:2 and 10 bits is 1920 x 1080 x 60 x 20, about 2.49 gigabits, and 2160p60 at the same sampling is about 9.95 gigabits. But compressed rates depend entirely on the product and sometimes on the content, and the only acceptable source is the manufacturer's documentation. A design built on a remembered number is a design that fails at load, and the failure arrives on the day the room is full.

Where a product's rate varies with content, design on the worst case the manufacturer will confirm, and write down that you did. That sentence in the design package has saved more projects than any clever topology.

What crosses the busiest link

Bandwidth faults do not happen at devices, they happen at links. So the design question is never "can the network carry this" but "what has to cross this particular cable at the worst moment".

Draw the design as groups of devices with links between them. For each link, list the distinct streams that must cross it in each direction, multiply out, and total. Then compare against the link's rated speed — and design to about 70 per cent of it, because queuing delay becomes visible on real-time traffic well before a link is nominally full, and because the system will be extended.

Multicast changes this arithmetic in one way that is easy to get wrong in both directions. A multicast stream crosses a link ONCE however many receivers are on the far side, so the total is the sum of DISTINCT streams crossing, not the sum of what receivers consume. But the first receiver on the far side is what makes a stream cross at all, so adding one receiver in a new room can add a whole stream to a link that previously never carried it. Both halves of that sentence catch designers out.

Oversubscription, honestly

Oversubscription is the ratio between what could theoretically arrive at a link and what the link can carry. A switch with 48 gigabit ports and a single 10-gigabit uplink is oversubscribed roughly five to one, and that is not automatically wrong — it is wrong only if the traffic actually tries to use it.

For AV the useful distinction is between traffic that is bursty and traffic that is constant. Office traffic is bursty: 48 ports rarely all want the uplink at once, which is why oversubscription is normal in IT design. AV traffic is constant. A camera feed uses its bandwidth every second of every hour, so an AV link either has the capacity or it does not, and statistical arguments about peaks do not apply.

That single difference is why AV networks look over-specified to an IT department and why the conversation goes badly if you cannot explain it. Design AV links for the sum of what will constantly be on them. Then show the arithmetic.

How to do it

1. List every stream with its documented bit rate and direction.
2. Group the devices by where they physically are.
3. Draw the links between the groups, including any that cross a building.
4. For each link, list the distinct streams that must cross it and total them.
5. Compare each total against 70 per cent of the candidate link speed.
6. Where a link fails, choose between a faster link, a second link, or moving a device.
7. Record every total in the design package, because you will be asked to justify the switch cost.

What goes wrong

Practice it

On paper, for a real system or a plausible brief.

Designing from the Brief

Every bad AV network was designed from a product list. Every good one was designed from a brief that somebody interrogated first, and the interrogation is the skilled part.

The needs analysis

A needs analysis is a structured conversation that turns what people want into things you can count. It happens before any product is named, and the output is a document the client agrees to.

Six questions get you most of the way. What content, from where, to where? How many sources and how many destinations, now and in three years? What is the real latency requirement — does anybody see themselves on a screen, and is anything going to air? What quality, judged by what the content actually is rather than by a resolution number somebody read? What has to keep working if something fails, and what can be allowed to stop? And who owns the network it will run on?

That last question changes the design more than any other, which is why it is asked at the start rather than discovered at the end.

Write the answers down and get them agreed. Not because of blame, but because a design is a set of decisions and decisions need premises. When the brief changes — and it will — you want to be able to show which number moved and what it cost.

When the brief is wrong

Briefs are routinely wrong in predictable ways, and recognising them early is most of the value a designer adds.

The commonest is a resolution asked for everywhere when it matters in two places. Somebody has written 4K across a forty-screen estate because 4K is the word for good, and thirty-eight of those screens are wayfinding displays at the end of a corridor. Asking which screens somebody will stand close to and look at carefully usually reduces the design by an order of magnitude in cost.

The second is a latency requirement with no stated reason. Low latency is expensive, and it is genuinely essential wherever a human sees themselves — a presenter on a confidence monitor, a performer on a side screen, anything going to a broadcast chain. Everywhere else a frame or two is invisible. Ask what the number is for.

The third is redundancy requested as a blanket. "It must never fail" is not a requirement, it is a feeling. The useful version names what must keep working and for how long, and that version can be designed and costed.

Saying this well is a craft. You are not telling the client they are wrong; you are asking what the requirement is for, and letting the answer do the work. Bring the cost of both options and let them choose. A designer who presents two priced options with the trade explained is trusted. One who says "you do not need that" is argued with.

Readiness

You cannot design without facts, and half of all design delay is waiting for facts nobody thought to gather. Find out early whether they exist.

The list is short: a drawing of the building with the riser and containment routes, what cabling is already in place and whether anybody has tested it, where there is rack space and power and cooling, who owns the network and what their policies permit, whether there is an existing addressing scheme you must fit into, and whether anybody holds a clock. If three of those are unknown, the design has a research phase whether or not anybody budgeted for one, and saying so early is the professional act.

How to do it

1. Ask what content goes from where to where, and write it as a list of signals.
2. Count sources and destinations, now and at a horizon the client will name.
3. Establish the real latency requirement and what each number is for.
4. Establish quality by asking what the content is and who looks closely at it.
5. Ask what must keep working through a failure, and for how long.
6. Ask who owns the network and what their policies permit.
7. Check the readiness list and report anything missing as a finding.
8. Write it up, send it, and get it agreed before designing.

What goes wrong

Practice it

Take a brief you have seen, however informal.

Topology — The Shape of the Design

Topology is the shape: how many switches, where, and how they join. It decides cost, resilience and how far the design can grow, and unlike almost everything else it is very expensive to change later.

The three shapes you will use

Flat. One switch, everything on it. For a system that fits on one switch this is not a compromise, it is the correct answer: no trunks to size, no inter-switch bandwidth, nothing to misconfigure, and the lowest latency available. A great many AV systems should be flat and are not, because a second switch felt more professional. If it fits, keep it flat.

Collapsed core. One central switch, with edge switches hanging off it in a star. Each edge switch serves a room or a rack; the core carries everything that moves between them. This is the standard shape for a building and it is what most AV designs should be. Its weakness is obvious and stated plainly: the core is a single point of failure and its uplinks are where all your arithmetic lands.

Spine and leaf. Several spine switches, every leaf connected to every spine. Any leaf reaches any other leaf in exactly two hops, the capacity between leaves is the sum of several links rather than one, and losing a spine costs capacity rather than connectivity. This is what broadcast facilities and large uncompressed systems use, and it is a serious piece of infrastructure. It is overkill for a lecture theatre and it is the only honest answer for a hundred uncompressed feeds.

Choosing between them

Work from the link arithmetic, not from taste. If the whole system fits on one switch with ports to spare, it is flat. If devices are in separate places and the total crossing between them fits comfortably on one or two links, it is a collapsed core. If the traffic between groups exceeds what a sensible number of links can carry, or if losing one switch is unacceptable, it is spine and leaf.

Two refinements worth knowing. A collapsed core with two cores, each edge switch dual-homed, gets most of spine-and-leaf's resilience for much less money and is a very common and sensible AV answer. And separating audio and video onto physically separate switches — rather than separate VLANs on shared switches — is sometimes the right call when the two have radically different requirements, because it means a video design decision can never affect the audio.

Keep the shape simple. Every additional hop adds latency and a place for clock to degrade, and every additional link is something to document, test and maintain. Elegance here means fewer parts, not more.

The physical plant

The cable plant outlives three generations of the equipment on it, so specify it generously. Fiber between rooms rather than copper wherever the run is long or the building might change, more strands than today needs, and single-mode where there is any chance of a longer run later. Copper to devices, of a category that supports the speed you will want in five years rather than the one you need now.

Then the unglamorous part that stops designs dead. Rack space, in units, at a height a person can reach. Power, including the current draw of every switch and whether the rack's circuits can take it. Cooling, because a rack of switches is a heat source and a hot switch throttles or fails. And containment — the physical route a cable takes — which is often the real constraint in an existing building and is very frequently discovered after the design is signed off.

Specify equipment where it can be reached safely. A switch in a ceiling void above fixed seating is a maintenance problem for the life of the building and a safety problem for whoever has to get to it.

How to do it

1. Total the traffic between each group of devices from the previous chapter's work.
2. Test the flat option first and keep it if the system genuinely fits.
3. If not, lay out a collapsed core and size its uplinks against the totals.
4. Ask what losing the core would cost; if it is unacceptable, dual-home the edges or go to spine and leaf.
5. Count hops between any two devices and check the latency budget still holds.
6. Specify the cable plant for a decade, not for the signal list.
7. Confirm rack space, power, cooling and containment exist before issuing anything.

What goes wrong

Practice it

For a system across three rooms with 16 sources and 48 destinations.

The Addressing and Multicast Plan

Two plans, written before anything is configured. The unicast plan decides where devices live. The multicast plan decides which addresses the streams use — and that second one is the plan nobody makes, which is why systems collide.

The unicast addressing plan

One subnet per VLAN, written in CIDR, sized with room to double. Then a block per class of device, in order, with gaps: infrastructure at the bottom, then encoders, then decoders, then control, with a DHCP range at the top for laptops and anything temporary. Static addresses for everything that matters, because a device whose address never changes is a device you can find at three in the morning.

Use the private ranges — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — and if the system will ever touch an existing corporate network, ask what they already use before choosing, because an overlap is discovered late and fixed expensively.

Size up. A /24 holds 254 usable addresses and feels enormous while you are commissioning forty devices. It feels tight the second time the client adds a wall of screens, and changing a mask afterwards means re-addressing everything in a window nobody wants to give you.

Decide the naming too. Devices discovered by name — which is most AV gear, over mDNS — need a naming convention agreed at design stage, or you end up with a browser list of forty devices called by their default model name and no way to tell which room each is in.

The multicast address plan

Multicast addresses are not yours to invent freely. The range 224.0.0.0 to 239.255.255.255 is divided into blocks with defined purposes, set out by IANA in RFC 5771, and two facts from it matter at design time.

The first: 239.0.0.0/8 is the administratively scoped block, and it is the one your system should use. It is the multicast equivalent of the private address ranges — reserved for use inside an organisation, not routed to the internet, and yours to allocate. If an AV system is putting its streams anywhere else, that is worth questioning.

The second: 224.0.0.0/24 is the local network control block and is used by the protocols themselves — this is where the routing and management protocols live. An AV system must not allocate from it, and a switch's behaviour towards it is special, which is why a stream misconfigured into that range produces symptoms that look like nothing else.

And the second fact narrows further than "use 239". RFC 2365 subdivides the administratively scoped block into named scopes, and the one an AV system belongs in is the IPv4 Organization Local Scope, 239.192.0.0/14 — which the RFC describes as the space from which an organisation should allocate sub-ranges for private use. That is exactly our case. Above it, 239.255.0.0/16 is the IPv4 Local Scope, the minimal enclosing scope and not further divisible.

The practical consequence is worth stating plainly, because it is the kind of thing a designer gets wrong by picking a number that looks free. The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are unassigned, and the RFC says they should be LEFT unassigned until 239.192.0.0/14 is no longer sufficient. So allocating a block at, say, 239.100.x.x is not merely unconventional — it is taking space the standard is holding in reserve. Allocate inside 239.192.0.0/14 and you are both correct and unlikely to collide with anybody.

So the plan: allocate a contiguous block inside 239.192.0.0/14, give each class of stream its own range inside that block, and keep every address in the system numerically close together so that the low bits differ. That last point is the practical reason to keep the block narrow — a multicast IP address maps onto a MAC address carrying only the low 23 bits of the group, so addresses that differ only in a high bit are indistinguishable to a switch's layer-2 machinery, and a receiver asking for one gets both.

Where the AV system offers to allocate addresses itself, let it. Most do, and most do it correctly. Your job is then to record what it chose, so the next system installed in the building does not choose the same.

The IANA multicast address blocks, and which one is yours

The complete IPv4 multicast map from Section 3 of RFC 5771, the IANA guidelines for multicast address assignment. One row is the answer to "what addresses should our AV system use"; the rest are there so a reader who meets an address outside it knows what they have found.

The RFC says plainly that addresses in the administratively scoped block are for local use within an organisation, which is exactly the AV case, and it is why essentially every AV-over-IP product defaults somewhere inside 239.0.0.0/8; a design still allocates from its 239.192.0.0/14 part, as this book does. Two blocks are worth recognising for different reasons. 224.0.0.0/24 is where the protocols themselves live, and a stream misconfigured into it behaves unlike anything else you will see. And 232.0.0.0/8, source-specific multicast, is the one worth asking for by name on a larger design: AV has exactly one known sender per group, which is the case SSM was built for, and it removes the rendezvous point that the next chapter is largely about.

How to do it

1. Ask what address ranges the organisation already uses, before choosing any.
2. Assign one subnet per VLAN in CIDR, sized to at least double the device count.
3. Block out each class of device in order, with gaps, and a DHCP range at the top.
4. Agree a device naming convention that says which room a device is in.
5. Allocate one contiguous multicast block inside 239.192.0.0/14.
6. Give each class of stream a range inside it, keeping every address numerically close.
7. Where the AV system allocates its own addresses, record what it chose.
8. Ask the network team whether source-specific multicast is available to you.

What goes wrong

Practice it

On paper.

Routed Multicast

Here is the fact that forces half the decisions in a multi-subnet design: multicast does not cross a router by itself. Nobody is at fault, nothing is broken, and no switch setting fixes it. It has to be designed for.

Why it does not cross

Multicast works inside a segment because switches can learn, from the IGMP conversation, which of their ports asked for a group. A router joins two segments and forwards traffic between them on the basis of destination addresses it has routes to. A multicast group is not a destination anywhere — it is a label for "whoever is interested" — so a router has nothing to look up and, by default, does nothing.

The practical consequence is the one every AV designer meets. Put encoders in one VLAN and decoders in another and they will ping each other happily, discover nothing, and carry no streams. The network is working exactly as specified.

This gives you three honest options and you should know all three, because the right answer varies and the first one is more often right than people expect.

Keep AV in one VLAN. If every encoder and decoder can live on one segment, do that, and the problem does not exist. Most AV systems can. A design that spreads AV across subnets for tidiness has bought itself routed multicast for no benefit.

Route the multicast properly. Some systems genuinely do span subnets: separate buildings, an existing network you have to fit into, or a scale that makes one segment unwise. Those need a multicast routing protocol, and in practice that means PIM.

Keep unicast where the counts are small. Some systems can send unicast to a handful of receivers, and unicast routes like any other traffic. This stops scaling at about four receivers, but for a few feeds to a few places it is the simplest thing that works.

PIM, in the amount a designer needs

PIM is Protocol Independent Multicast, and the variant in use is sparse mode, specified in RFC 7761. You will not configure it — that is a network team's work and a routing specialism — but you must be able to ask for it correctly, because a vague request gets a vague answer and then a failed commissioning.

The core idea is the rendezvous point. Since receivers do not know where senders are, the network nominates a router as a meeting place. Receivers' joins travel towards it, senders register with it, and traffic initially flows via it. Once traffic is flowing, routers downstream can work out where the sender actually is and switch to the direct path — the shortest-path tree — abandoning the detour. That transition is normal, it is designed in, and it is why a stream can take a slightly different route a second after it starts.

Two things follow for a design. The rendezvous point is infrastructure that must exist, be reachable and ideally be redundant, and "who is the RP" is a question with an answer somebody has to give you. And there is a brief, specified delay at the start of a stream while the trees are built, which matters if your design assumes a destination can change source instantly — a video wall switching layouts, for instance.

The better answer, where it is available, is source-specific multicast. In SSM a receiver asks for a group AND a named sender, so there is nothing to rendezvous about: no RP, no registration, no switchover. AV is the ideal case for it because every AV group has exactly one known sender, and it is worth asking the network team for by name. It needs IGMPv3 at the receivers and the 232.0.0.0/8 range, both of which an AV design can specify, so SSM streams take their addresses from 232/8 rather than from the 239.192.0.0/14 block of the last chapter's plan.

What RFC 7761 specifies, and which of it is your business

The protocol's own structure, taken from the contents of RFC 7761 — PIM-SM, Internet Standard 83, which obsoletes RFC 4601. The right-hand column is the judgement an AV designer needs: what to understand, what to ask for, and what to leave to the network team. There is no shame in the last column; it is a hundred pages of state machines.

Read the middle of that list again, because it is the practical output of this chapter. The questions an AV designer has to get answered are narrow and specific: is multicast routed between these subnets at all; who is the rendezvous point and is it redundant; and is source-specific multicast available. Three questions. Asked at design stage they take a ten-minute conversation. Discovered at commissioning they take a week, because the answer involves a change to somebody else's production routing.

How to do it

1. First, ask whether the AV can all live in one VLAN; if it can, stop here.
2. If it cannot, write down exactly which subnets streams must cross and in which direction.
3. Count the receivers; if there are very few, ask whether unicast will serve.
4. Ask the network team whether multicast is routed between those subnets today.
5. Ask who the rendezvous point is and whether it is redundant.
6. Ask whether source-specific multicast is available, and say why you want it.
7. Record every answer in the design package, with the name of who gave it.
8. Allow for the brief tree-building delay wherever your design switches sources quickly.

What goes wrong

Practice it

For a design spanning two buildings.

Segmentation and Priority by Design

How to configure a VLAN is the previous book. How many VLANs there should be, on how many switches, carrying what, and who has to agree to it — that is a design decision, and it is made on paper before anybody logs into anything.

An AV network is designed deliberately — segmented, prioritised, and built for reliability.

How many VLANs, and why

The default AV shape is four: audio, video, control, management. It is a good default and you should be able to justify departing from it in either direction.

Fewer is right when the system is small and the traffic classes are not really distinct. Collapsing audio and control on a system with eight audio devices and three control panels costs nothing and removes a subnet to document, address and route. Video is the one almost never worth collapsing, because video bursts and video is what swamps its neighbours.

More is right when something must be isolated for a reason you can name. A separate VLAN for a guest or contractor system so it cannot see yours. A separate one for a subsystem with a different clock. A separate one because an IT security policy requires it, which is a perfectly good reason even when the technical case is thin.

The discipline is to write the reason next to each one. A VLAN with no stated purpose is a VLAN somebody will put something random into, and the segmentation that was meant to protect the AV will have quietly stopped doing it. And every additional VLAN that AV traffic must cross is a multicast routing problem, which is the previous chapter.

QoS as a design document

A priority scheme is an agreement, not a setting. Its defining property is that it has to be identical on every switch along every path, which means it has to be written down and agreed before anybody configures anything — and on a shared network, agreed with people who have their own priority scheme already.

What the design has to state: which traffic classes exist, what marking each carries, what relative priority each gets, and which ports the markings are trusted on. For AV the order is not negotiable — clock above media, media above control, control above everything else — because one frame of video late is a glitch and one packet of clock late is a system-wide fault.

On a network you own, write the scheme and implement it. On a shared network, the conversation is different and it goes better if you arrive with a proposal rather than a request. An IT department probably already has a QoS policy with classes for voice and video; your job is to show how AV maps onto it, where it does not fit, and what you are asking them to add. Bring the specific markings. "We need QoS" gets nowhere; "we need these DSCP values trusted on these ports and placed in your existing priority queues this way" can be assessed and approved.

And state plainly in the design what QoS is for, because it is routinely misunderstood by the people signing it off: it does not create capacity. It decides what suffers when there is not enough. The capacity argument was the bandwidth chapter and it is not solved here.

How to do it

1. List the traffic classes the system actually has, not the ones a template suggests.
2. Assign each a VLAN, and write one sentence saying what it is for.
3. Check whether any AV stream must cross between them, and if so go back a chapter.
4. Write the priority order, with clock first, and the marking each class carries.
5. State which ports markings are trusted on.
6. If the network is shared, map your scheme onto the owner's existing one before proposing it.
7. Put both tables in the design package; they are what somebody configures from.

What goes wrong

Practice it

For a design you have or can imagine.

Clock Across a Designed Network

Clock is where multi-switch audio designs actually fail. Not bandwidth — bandwidth is almost never the problem for audio. Clock. And unlike bandwidth it cannot be fixed later by buying a bigger switch.

What the design has to decide

Networked audio needs every device to agree on when a sample happens, to within microseconds, and that agreement travels as packets using PTP — the Precision Time Protocol, IEEE 1588. One device is grandmaster and the rest follow it. The election is automatic, which is exactly the problem: if you do not decide, the system decides, and it will decide again every time something is powered down.

So the design states four things. Which device is grandmaster, and why — always powered, centrally placed in the network, ideally purpose built. Which device is the nominated fallback. Which PTP version and, where it matters, which domain. And where the clock boundaries are, if the network is large enough to need them.

The last one is the part that distinguishes a design from a configuration. Every switch a clock packet crosses adds a little uncertainty, and a packet that takes a varying route is worse than one that takes a long but constant route. On a large network the answer is switches that participate in PTP rather than merely passing it — boundary clocks, which recover the clock and regenerate it downstream, so the uncertainty does not accumulate across the whole estate. Whether your design needs them is a function of topology and scale, and it is a question to settle before buying switches, because not all switches can do it.

Which brings up the one design rule that makes everything else easier: keep the clock path short, simple and consistent. This is a real argument for the flat and collapsed-core topologies over anything clever, and it is why AV networks look architecturally dull compared with the IT networks around them. The dullness is the point.

Where two systems meet

Interoperability problems between networked audio systems are clock problems far more often than they are protocol problems, and a design that joins two systems should say which one holds the clock before it says anything else.

Dante has historically used PTP version 1 and supports version 2 for AES67 interoperability; AES67 uses version 2. A design that joins a Dante system to another manufacturer's AES67 system has to state the version, the domain, and which side is master. Left unstated, each system elects its own grandmaster, both work perfectly alone, and the join is unstable in a way that looks like a protocol incompatibility and is not.

Separate clock domains are sometimes the right answer. If two subsystems genuinely do not need to be sample-accurate with each other — a background music system and a production audio system, say — letting each hold its own clock and converting at the single point where they meet is simpler and more robust than forcing one clock across both. State that decision explicitly, because the default assumption of anybody who reads the drawing later will be that one clock rules everything.

How to do it

1. Nominate the grandmaster, and write down why that device.
2. Nominate the fallback, and set its priority so it is second rather than discovered.
3. State the PTP version, and the domain if more than one exists.
4. Count the switch hops on the longest clock path.
5. Decide whether boundary clocks are needed, and check candidate switches support them.
6. Where two audio systems meet, state which holds the clock and at what version.
7. Where two subsystems do not need sample accuracy, state that they have separate domains.
8. Specify clock as the top priority class in the QoS table.

What goes wrong

Practice it

For a networked audio design across three rooms.

Redundancy and What It Protects

Most redundancy is bought without anybody saying which failure it covers. The useful question is never "is it redundant" but "what exactly happens when this specific thing dies, and is that acceptable".

AV on the network must not fail — so it's designed and deployed for reliability.

Match the mechanism to the failure

Redundancy mechanisms are specific. Each protects against some failures and none against others, and buying the wrong one is both expensive and falsely reassuring.

Read the last two rows together, because they are the cheapest useful redundancy there is and they are routinely left out of designs that contain far more expensive measures. A spare switch with no configuration export is a brick. A configuration export with no spare switch is a document. Together they turn a dead switch from a rebuild into a swap, and they cost almost nothing.

Link aggregation, and what it does not do

Link aggregation combines several physical links into one logical link, and it is routinely sold as both redundancy and bandwidth. It is genuinely one of those and partly the other, and the distinction matters for AV specifically.

As redundancy it works: lose one member of the bundle and the rest carry on, with a brief interruption. That is real and worth having.

As bandwidth it is more limited than it sounds, because traffic is assigned to a member link by a hash of its addresses. Two links do not give one stream twice the bandwidth — each stream picks a link and stays on it. So aggregating two gigabit links does not carry a 1.5 gigabit stream. It carries two separate streams, possibly both on the same member if the hash says so.

For AV that distinction is sharp, because AV traffic is a small number of large constant streams rather than many small bursty ones, which is exactly the case where hashing distributes badly. If a design needs more capacity than one link provides, the honest answer is usually a faster link rather than more links. Use aggregation for resilience and count on it for capacity only where the stream count is high enough for the hash to spread.

Seamless protection switching

One redundancy scheme is built for real-time media rather than data, and it is worth knowing because it is the only one that protects against packet loss rather than against equipment failure.

The idea is to send two identical copies of a stream by two separate network paths, and have the receiver take whichever packet arrives first and discard the duplicate. A packet lost on one path is recovered from the other with no interruption at all — no reconvergence, no gap, nothing audible or visible. SMPTE ST 2022-7 specifies this for media streams and it is standard practice in broadcast.

The cost is honest and should be stated in any design that proposes it: double the bandwidth, two genuinely separate paths all the way through, and endpoints that support it. It protects the stream, not the source or the destination, so a design that uses it and has one encoder has protected the least likely part of the chain.

For most AV, this is more than the job needs. For anything going to air, or a system where a single visible glitch is a serious event, it is the mechanism that actually delivers what "it must never fail" was reaching for.

Designing for the failures that happen

Designs defend against dramatic failures and get taken down by ordinary ones. So rank the failure modes by how often each actually occurs, rather than by how serious it sounds. The honest ranking: somebody unplugs something; a patch lead goes marginal; a configuration change is made without a record; a device's firmware is updated and its behaviour changes; power is lost to one rack; a switch dies. Only the last two are what redundancy hardware is for, and they are the two rarest failure modes on the list.

The first four are addressed by labelling, testing and keeping records. A design that specifies dual cores and does not specify a labelling scheme or a configuration backup has spent its money in the wrong place.

So set the level deliberately. Ask what must keep working, for how long, and what it costs if it does not — then match the mechanism to that. Write the answer in the design, including the failures you have decided to accept, because an accepted risk that is written down is a decision and an accepted risk that is not is a surprise.

How to do it

1. List the things that can fail, in order of how often they actually do.
2. For each, write what happens to the AV and whether that is acceptable.
3. Where it is not, choose the mechanism that protects against that specific failure.
4. Specify a labelling scheme and a configuration backup before anything expensive.
5. Specify a spare switch and the configuration export that makes it useful.
6. Check that no single configuration change can reach both halves of anything redundant.
7. Write down the failures you are accepting, and have the client agree them.

What goes wrong

Practice it

For a design you know.

Commissioning and Working with IT

A design becomes a system through other people. On a network you own that is a matter of order and discipline. On somebody else's network it is a negotiation, and it is where more AV projects are won and lost than in any technical decision in this book.

Working with the IT department at design stage

Start from their position, because it is reasonable. An IT department is measured on stability and security. They have been handed equipment they did not choose, by people who did not tell them what it needed, and asked to make it work on a network carrying things that matter more than a video wall. They will say no to anything vague, and they are right to.

So arrive prepared and arrive early. The design-stage meeting, not the install week. Bring the device list with counts, the per-stream bandwidth with its source, the per-link totals, the addressing plan, the multicast plan, the priority scheme mapped onto theirs, and a written statement of what you are asking them to change.

Ask in their language and with numbers. Not "we need multicast" but "we need IGMP snooping on VLAN 40 with a querier, for 16 sources totalling 3.2 gigabits of multicast, and we need to know whether it is routed to VLAN 41". Not "we need QoS" but "we need these DSCP values trusted on these ports, mapped into your existing priority queues this way". A request in that form can be assessed. A request that cannot be assessed gets refused by default.

And bring the alternative. If the answer is no, a separate AV network is usually the fallback, and offering it unprompted shows you understand their position rather than resenting it. Sometimes it is simply the better answer, and in a hospital or a bank with rules you will not argue away, it is the only answer. The design that works inside the constraints is the design.

Get the answers in writing, with names and dates, and put them in the design package. Not defensively — because people move on and a verbal agreement about multicast routing has no half-life at all.

Commissioning to the design

Commissioning has an order and the order exists so that faults are found one category at a time. Prove the physical plant, then the switch configuration, then the addressing, then one AV device, then two, then the rest. Each stage produces written evidence.

The arithmetic of this is simple. Connect forty devices to an unproved network and a fault has forty-one suspects. Prove the network first and it has one.

Prove cable with a tester and keep the results, not with a link light. Prove the switch configuration by reading it back and comparing it against the design, not against what you remember typing. Prove the addressing with two laptops per VLAN before any AV device is connected. Then connect AV one device at a time, each one completely, recording its address and its switch port as you go.

Where the installed system differs from the design — and it will — record the difference rather than silently absorbing it. A design package that does not match the installed system is worse than none, because the next person will trust it.

Testing under real load

An empty network proves very little about a full one. Everything in this book that can bite — link saturation, queuing, clock degradation, multicast table size — bites under load and is invisible without it.

So test with every source running simultaneously, every destination subscribed, and ideally something hostile happening as well: a large file copy, a firmware update, somebody plugging a laptop into a spare port. Run it for longer than feels necessary, because clock problems and slow leaks only show over time. And do it before go-live, when there is still time to act on what you find.

Record what normal looks like while it is normal. Utilisation on every significant link, error counters, clock status, and the multicast group count. That baseline is the single most useful thing you can hand over, because without it nobody can tell an abnormal reading from an ordinary one, and most of operational troubleshooting is exactly that judgement.

Which is the point of the operational handover, and it is a separate act from handing over documents. Somebody runs this system after you leave, and what they need is not the design but the three or four readings that tell them whether today is normal: the utilisation of the busiest link, the error counters on the AV ports, and the clock status. Show them where to find each one, show them the baseline figure beside it, and tell them which direction is bad. A monitoring system that nobody has been taught to read is a monitoring system nobody looks at.

How to do it

1. Meet the network owner at design stage with every number and a written list of asks.
2. Get their answers in writing, with names and dates, into the design package.
3. Test and record every cable before anything is configured.
4. Configure to the design, then read the configuration back and compare it.
5. Prove each VLAN with two laptops before any AV device is connected.
6. Connect AV devices one at a time, recording address and port for each.
7. Run every source and destination at once, for longer than feels necessary.
8. Add hostile traffic and watch what happens.
9. Record the baseline — utilisation, errors, clock, group count.
10. Write down every difference between the design and what was built.

What goes wrong

Practice it

Use a real or imagined design.

The Design Package

The deliverable is a set of documents, and most people in this trade have never seen a good one. It is not a formality — it is the thing that decides whether the system can be built, understood, extended or repaired by anybody who was not in the room.

What is actually in it

Eight documents, a page or two each. None of them is difficult and together they are the difference between a design and a conversation.

Add two things from commissioning and the package is complete: the as-built differences, and the baseline. And export every switch configuration to a file and store it with the documents, because a configuration export turns a dead switch from a rebuild into a swap.

Service levels, and what you are promising

A designer's numbers have a way of becoming somebody's contractual obligation, often without the designer noticing. "The system supports up to sixteen simultaneous streams" is an engineering statement in a design and a promise in a contract, and the difference between them is whether anybody wrote down the conditions.

So state the conditions with every figure. Sixteen streams at the stated bit rate, on the specified switches, with nothing else on the AV VLAN. Latency figures measured how and between what. Availability claims qualified by what is redundant and what is not. A number without its conditions will be quoted without them.

If the project has a service-level agreement, read it against your design and say so if they disagree. An SLA promising a two-hour fix is a statement about spares on shelves and people on call, and if the design has neither, somebody has promised something the design cannot deliver. That is worth one awkward conversation at design stage instead of a dispute later.

Handing it over

Hand it over in person if you possibly can. Walk somebody through the topology drawing, show them the addressing plan and where a new device goes, and tell them the one thing most likely to go wrong. Every system has one, and you know what it is.

Make sure the package reaches the people who will actually need it: the client, whoever maintains the system, and the network owner — and keep a copy yourself, because you will be the one they call.

Finally, say what you did not do. The design that records its own boundaries — what is out of scope, what was accepted, what was deferred — is the design that survives contact with the next project.

How to do it

1. Collect the agreed needs analysis and the signal list.
2. Put in the per-link bandwidth calculation with the per-stream figures you used.
3. Draw the topology with every link labelled with its speed and its total.
4. Add the addressing plan in CIDR and the multicast plan.
5. Add the VLAN table with purposes and the priority table with markings.
6. Add the accepted-risk list, agreed with the client.
7. Add the as-built differences and the baseline from commissioning.
8. Export every switch configuration and store it alongside.
9. State the conditions attached to every number you have quoted.
10. Hand it over in person, to the client, the maintainer and the network owner.

What goes wrong

Practice it

For a system you have worked on.

Putting AV Network Design Together

A design is a chain of decisions, each one constraining the next. Read back along it and every number should trace to a figure somebody can check, or to a requirement somebody agreed to.

Design deliberately, deploy reliably, and you make AV-over-IP deliver on its promise.

The whole design in concert

The chain runs like this. The brief gives you counts, a latency requirement and a quality requirement. Those choose the standard. The standard gives you a bit rate per stream. The bit rate and the counts give you the per-link totals. The totals and the geography give you the topology. The topology gives you the switch specification, the cable plant, and the rack, power and cooling requirements. The device counts give you the addressing plan, and the stream counts give you the multicast plan. The subnet boundaries tell you whether you need routed multicast. The topology and scale tell you whether you need boundary clocks. The failure analysis gives you the redundancy. And all of it lands in a package somebody builds from.

That is the whole method, and its value is that it is auditable. Every link in it is a decision with a reason, which means that when something changes — and the brief always changes — you can follow the chain and see exactly what moves. Add eight more screens and you know which link total changes, whether the topology survives, whether the address blocks have room, and what it costs. A design built this way answers questions. A design assembled from a product list cannot.

It also means the honest answer to most design questions is another question, further back up the chain. "What switch should we use" has no answer until the per-link totals exist, and the totals have no answer until the standard is chosen, and the standard has no answer until somebody says what the latency is for. Working backwards to the question that actually needs answering is most of the skill.

Growing as an AV network designer

This is the route into the best-paid work in the trade, and it is a narrower door than it looks: the shortage is not of people who know what a VLAN is but of people who will produce an auditable design and defend it in a meeting. Three things grow you as a designer, in order of how much they pay back.

Do the arithmetic on every system you touch, even when nobody asks and the system is already installed. Ten minutes, per-stream figures from documentation, totals per link. Do that on twenty systems and you will have an instinct for what fits that no reading can give you — and you will find two or three systems running much closer to a limit than anybody realised.

Get fluent on the configuration side even though it is not this job. A designer who cannot configure a switch is designing with their hands tied, because the feasibility of a design is partly a question about what switches can actually be made to do. A second-hand managed switch costs less than a microphone.

Then learn to run the design-stage meeting. It is the highest-value skill in this book and the least technical. Arriving at a network owner with every number, a mapped priority scheme, a written list of asks and a costed alternative is rare enough that it is remembered, and it is the thing that turns a competent designer into the one who gets asked back.

Read the standard text alongside this one. Networked AV Systems, published with InfoComm International — now AVIXA — goes considerably further than a book of this length can, particularly on subnetting arithmetic, streaming system design and the commercial side. Its chapter 5 is this book's subject treated at book length.

Glossary

Practical sign-off

AV network design is learned by designing and deploying. The learner plans bandwidth, segments AV on a VLAN, applies QoS, manages multicast, builds in redundancy, and tests an AV-over-IP network. A mentor signs off when the learner can design and deploy a reliable AV network.

• Planned bandwidth for an AV-over-IP system
• Segmented AV on its own VLAN and applied QoS
• Configured managed multicast and built in redundancy
• Deployed and tested an AV-over-IP network, collaborating with IT

How to do it

1. Follow the chain from the brief to the package and check every link has a reason.
2. Pick three numbers at random and try to trace each to a document or a figure.
3. Check the busiest link total against the specified link speed one more time.
4. Check the addressing and multicast plans have room for the stated growth.
5. Check that what happens when each switch dies is written down.
6. Check the accepted risks are agreed and not merely assumed.
7. Ask what question you would be unable to answer in a review meeting, and answer it.

What goes wrong

Practice it

Take any design, yours or somebody else's.

Where to Go Next

This book sits between two others and borrows from both. AV Networking Intermediate is behind it and is where the configuration lives — if any chapter here made you want to actually type something, that is the one to go back to. IP Video Engineering is ahead of it and takes the video side properly: compression, how the codecs work, what their artefacts look like, and broadcast practice.

The first ninety days

Do the bandwidth arithmetic on every system you touch, whether or not anybody asks. Ten minutes each, figures from documentation, totals per link. Twenty systems in and you will have judgement that cannot be read into existence — and you will find two or three systems running far closer to a limit than their owners know.

Then write a design package for a system that has none. It is the fastest way to learn what a good one contains, it is immediately useful to whoever maintains that system, and it is the single best thing to be able to show somebody who is deciding whether to let you design their network.

Where this leads

AV systems designer, AV network architect, broadcast engineering, and the consultancy work where somebody is paid to produce exactly the package the last chapter describes. It is the best-paid end of this trade and the shortage of people who can do it properly is not closing.

What the gear actually looks like

Every device named in this book, in one place. Recognition is the whole point of Chapter 4 — use this page to attach a picture to each name before you meet it on a dock at six in the morning.

Audio

Dynamic microphone

Condenser microphone

Wireless handheld

Radio rack

Mixing console

Stage box / snake

Power amplifier

Main loudspeaker

Subwoofer

Stage monitor wedge

In-ear monitors

DI box

Video

Camera

Video switcher

Scaler / processor

Projector

LED wall panel

Confidence monitor

Lighting & control

Conventional fixture

Moving-head fixture

Lighting console

Dimmer

Show controller

Media server

Networking & infrastructure

Network switch

Patch bay

Equipment rack

Power distribution

Cable tester

A properly coiled cable

Connectors, close up

XLR

TRS / TS ¼-inch

SDI on BNC

HDMI

Cat5e / Cat6 (RJ45)

Fiber optic

DMX (5-pin XLR)

AC power — not signal