La rete per l’AV over IP: cosa deve reggere davvero lo switch della sala

Il collaudo di una sala nuova va male quasi sempre allo stesso modo. L’immagine parte, l’audio pure, e nel giro di qualche minuto la rete dell’ufficio accanto rallenta fino a fermarsi. Oppure va tutto bene per settimane e poi, durante la plenaria, il labiale non torna più. In entrambi i casi la telefonata arriva all’integratore audio video, che risponde che i suoi apparati funzionano. E ha ragione: il problema è nella rete.

Quando la distribuzione di audio e video passa dai cavi dedicati alla rete dati, il progetto cambia mestiere. Le decisioni che contano non sono più su encoder e schermi, sono su switch, VLAN e priorità del traffico. Questa guida spiega quali sono, in italiano, e cosa succede quando mancano.

Cosa cambia quando l’impianto passa sulla rete

Nell’impianto tradizionale ogni sorgente arriva allo schermo attraverso un cavo suo, e al centro c’è una matrice con un numero fisso di ingressi e di uscite. Funziona bene ed è semplice da collaudare, ma ha due limiti: quando gli ingressi finiscono si cambia la matrice, e per aggiungere uno schermo si tira un cavo nuovo.

Sulla rete quei due limiti spariscono. Si aggiunge un punto rete invece di un cavo, non esiste un numero massimo di sorgenti, e qualsiasi sorgente può finire su qualsiasi schermo, anche in un altro edificio.

Il passaggio però non elimina il problema, lo sposta. Quello che prima era un cavo dedicato, che nessun altro poteva disturbare, adesso è traffico che condivide l’infrastruttura con backup, posta e videochiamate.

Va detto anche il contrario, perché conta: su una sala singola l’AV over IP raramente conviene. Una distribuzione su doppino come l’HDBaseT resta più semplice, più economica e più prevedibile, come nel caso della sala conferenze con aula corsi. L’IP conviene quando le sale sono molte, quando servono collegamenti fra edifici o quando l’impianto deve crescere nel tempo senza essere rifatto.

Il multicast, cioè il modo più comune di far fallire un collaudo

Un flusso video su rete non viene mandato a un destinatario solo: viene mandato a un gruppo, e chi vuole vederlo si iscrive. Si chiama multicast ed è il meccanismo giusto, perché permette a dieci schermi di ricevere la stessa immagine senza moltiplicare per dieci il traffico.

Il problema è cosa fa lo switch quando non sa chi si è iscritto. In quel caso manda il flusso a tutte le porte, perché non ha modo di sapere quali servono. Un singolo flusso video in 4K può così arrivare su ogni presa dell’edificio, comprese quelle dei PC che non hanno nulla a che fare con la sala.

È esattamente questo che succede quando la rete dell’ufficio si ferma il giorno del collaudo. Non è un guasto: è la rete che fa quello che le è stato chiesto di fare.

IGMP snooping e querier, tradotti

Servono due cose insieme, e la seconda è quella che si dimentica.

L’IGMP snooping è la funzione con cui lo switch ascolta chi si iscrive a quale gruppo e manda il flusso solo lì. Senza, si torna al caso di prima.

Il querier è chi, periodicamente, chiede a tutti “chi vuole ancora ricevere?”. Serve perché le iscrizioni scadono: se nessuno fa quella domanda, le tabelle si svuotano e lo switch ricomincia a inondare tutte le porte. La conseguenza pratica è che attivare lo snooping non basta: qualcuno nella rete deve fare il querier, e va deciso chi, non lasciato al caso.

Se poi le sale stanno su reti diverse e il flusso deve attraversarle, serve anche il routing del multicast, che è un altro capitolo e un’altra configurazione.

Il vincolo che decide la topologia prima di ogni altra scelta

Questo è il punto che sorprende chi progetta reti, e va guardato prima di comprare qualsiasi cosa. Riguarda audio e video in modo diverso, e la differenza decide la topologia dell’edificio.

L’audio è il vincolo rigido. Dante, che è di fatto lo standard dell’audio su rete, è progettato per operare dentro una sola sottorete: Audinate dichiara che i dispositivi non si scoprono né comunicano fra sottoreti diverse, e questo vale anche configurando normalmente il routing fra le due reti. Non è un problema che si risolve con una rotta. Una via d’uscita esiste, ed è la piattaforma di gestione dedicata dello stesso produttore, che abilita il funzionamento su reti instradate: è però una licenza e una scelta di progetto, non un’opzione da spuntare a impianto finito.

Il video è più permissivo, ma non libero. Anche i sistemi video su IP si appoggiano al multicast, e lo fanno persino nel caso più semplice di un solo trasmettitore e un solo ricevitore. Attraversare una sottorete è tecnicamente possibile, ma richiede che il multicast venga instradato: una configurazione in più e un punto di guasto in più. Per questo nella pratica anche il video finisce quasi sempre confinato nella propria VLAN, non per obbligo di protocollo ma per tenere il traffico dove deve stare.

La conseguenza pratica. Vince il vincolo più stretto, e il più stretto è quello dell’audio. L’architettura che un progettista di rete disegna d’istinto, cioè un core di livello 3 con una sottorete per piano o per ambito, rompe l’audio prima di ogni altra cosa. La VLAN dell’audio video non è quindi una scelta di igiene di rete: è imposta dal sistema audio, e va decisa all’inizio, perché cambiarla dopo significa rimettere mano all’indirizzamento dell’edificio.

Il sincronismo, e la trappola che sembra una buona idea

Audio e video su rete hanno bisogno di un riferimento di tempo comune, altrimenti i flussi derivano fra loro: il labiale non torna, e in un impianto con più diffusori l’audio arriva sfasato da punti diversi della sala. Quel riferimento lo distribuisce il protocollo PTP.

Esistono due versioni del protocollo, e non parlano fra loro. Dante usa la prima per impostazione predefinita, mentre AES67, lo standard che permette a sistemi audio di produttori diversi di scambiarsi flussi, richiede la seconda. È la prima causa di guasto negli impianti misti.

Il video arriva dopo l’audio, ed è lì che salta il labiale

C’è un secondo motivo per cui audio e video si disallineano, e non è il riferimento di tempo: è la latenza, cioè quanto ciascuno dei due impiega ad attraversare la catena.

L’audio su rete è velocissimo, e le piattaforme professionali dichiarano ritardi inferiori al millisecondo. Il video no, perché deve essere codificato e poi decodificato, e quanto ci mette dipende dalla codifica scelta: si va da meno di un fotogramma con le compressioni leggere fino a uno o più fotogrammi con le codifiche più efficienti, che a trenta fotogrammi al secondo significa decine di millisecondi.

Se audio e video viaggiano sullo stesso sistema, il disallineamento lo compensa il sistema per conto suo. Se invece l’audio sta su una piattaforma e il video su un’altra, che è la situazione normale quando la sala ha un processore audio dedicato e un impianto video separato, la compensazione la deve introdurre qualcuno: si ritarda l’audio quanto basta per aspettare il video.

Due conseguenze pratiche. La prima è che quel ritardo dipende dalla codifica video, quindi cambiare codifica significa ritarare l’audio. La seconda è che il valore giusto si misura in collaudo guardando lo schermo, non si deduce dalle schede tecniche.

Cosa fanno davvero Cisco e Huawei

Né l’uno né l’altro implementano la prima versione del protocollo: entrambi lavorano sulla seconda. Cisco però dichiara di far transitare i pacchetti della prima in modo trasparente, cioè di inoltrarli come traffico qualunque senza elaborarli.

Ed è tutto quello che serve, perché Dante non chiede allo switch di partecipare al sincronismo: chiede di non romperglielo. Se lo switch inoltra il multicast e rispetta la priorità, il resto se lo gestisce fra i propri dispositivi.

Da qui la trappola, che è controintuitiva. Configurare lo switch come orologio di riferimento sembra la cosa più corretta da fare, e invece può interrompere l’inoltro dei messaggi di sincronismo di Dante: a quel punto ogni dispositivo diventa orologio di se stesso e l’audio va peggio di prima. La rete sembra configurata meglio e l’impianto funziona peggio.

Sul lato documentazione c’è una differenza fra i due che vale la pena conoscere: la guida di configurazione del Cisco Catalyst 9300 nomina esplicitamente AES67 e Dante, documenta un profilo dedicato ai media e precisa che l’IGMP snooping è attivo per impostazione predefinita sulla VLAN, così i gruppi di sincronismo vengono inoltrati. Huawei documenta il supporto al sincronismo e alle reti a latenza deterministica sui propri switch campus, ma non nomina né AES67 né Dante.

La priorità: l’audio ha una gerarchia rigida

Se lo switch tratta tutto il traffico allo stesso modo, il sintomo non è un rallentamento. È un ticchettio periodico, o una sillaba che manca ogni tanto, e nessuno lo collega alla rete perché la rete “va”.

L’audio su rete ha una gerarchia precisa: prima passano i pacchetti che tengono sincronizzati gli apparati, poi l’audio, poi tutto il resto. Questi sono i valori che Audinate documenta e che vanno dati a chi configura lo switch.

Tipo di traffico	Priorità	Perché
Eventi di sincronismo critici	CS7 (56)	Se arrivano in ritardo, salta il riferimento di tempo di tutto l’impianto
Audio e sincronismo generale	EF (46)	Un pacchetto audio in ritardo è audio perso, non audio lento
Traffico riservato	CS1 (8)	Deve esistere ma non deve competere
Tutto il resto	Nessuna	Backup, posta e aggiornamenti stanno dietro

C’è però una trappola che quasi nessuno conosce: la versione software di Dante, quella che gira su un PC, non applica nessuna marcatura di priorità. Audinate lo dichiara e ne spiega il motivo, cioè che un computer trasmette a raffiche e una raffica ad alta priorità bloccherebbe il resto del traffico. La conseguenza pratica è che se in sala c’è un PC che fa da sorgente audio, quel flusso arriva alla rete senza priorità e la QoS non lo protegge. Spiega buona parte dei problemi intermittenti che nessuno riesce a riprodurre.

Il flusso video: quanta banda serve davvero

La decisione non è “quanta banda serve”, è quale codifica si sceglie, perché è quella a determinare la rete. È la prima scelta di progetto e va fatta prima di comprare gli switch: al contrario si acquistano apparati e poi si scopre che il collegamento fra i due edifici non regge il flusso.

Questi sono gli ordini di grandezza per un singolo flusso video. Sono valori di orientamento per capire in quale mondo ci si muove, non numeri da capitolato: quelli li dichiara il produttore per il modello scelto.

Come viaggia il video	Banda per flusso	Ritardo introdotto	Dove ha senso
Non compresso, 4K a 60 Hz a colore pieno	Oltre 10 Gigabit	Praticamente nullo	Raro su rete: richiede infrastruttura a 10 Gigabit dedicata
Compressione leggera, dichiarata visivamente senza perdite	Da 1 a 10 Gigabit	Inferiore a un fotogramma	Sale riunioni e control room su rete a 10 Gigabit
Codifiche a bassa latenza	Da 100 a 600 Megabit	Uno o due fotogrammi	Distribuzione su rete Gigabit: il caso più diffuso
Codifiche a forte compressione	Da 5 a 50 Megabit	Da alcuni fotogrammi in su	Cartellonistica digitale e streaming, non per l’interazione

Un riferimento utile per capire la scala: sul cavo, un segnale 4K a 60 Hz a 8 bit e colore pieno occupa circa 18 Gigabit, che è anche il limite dello standard HDMI più diffuso. Alzando la profondità di colore si supera quel limite, ed è il motivo per cui molti apparati riducono automaticamente la qualità del colore invece di mostrare uno schermo nero.

La riga che riguarda quasi tutti è la terza. È lì che si colloca la maggior parte degli impianti, ed è lì che nasce la domanda successiva: cosa si perde comprimendo.

Come si comprime il colore, e quando si vede

Il modo più comune di ridurre la banda non tocca la nitidezza dell’immagine: riduce l’informazione di colore, perché l’occhio umano è molto più sensibile al contrasto che alla tinta. La sigla che si trova nelle schede tecniche descrive quanto colore viene trasmesso.

Sigla	Cosa succede al colore	Banda rispetto al pieno
4:4:4	Ogni pixel ha il proprio colore: niente perdita	100%
4:2:2	Il colore è dimezzato in orizzontale, due pixel affiancati lo condividono	Circa due terzi
4:2:0	Il colore è dimezzato in orizzontale e in verticale	Circa la metà

Il colore che non viene trasmesso non sparisce: viene ricostruito per interpolazione dal decoder, che lo deduce dai pixel vicini. È una ricostruzione plausibile, non quella originale, e qui sta il punto pratico.

Su un video girato con una telecamera nessuno se ne accorge, perché nella realtà il colore cambia gradualmente e l’interpolazione indovina bene. Su un testo piccolo colorato, dove il colore cambia da un pixel all’altro, l’interpolazione sbaglia: i bordi si sfrangiano e le lettere sembrano sfocate. È il motivo per cui l’intestazione rossa di un foglio di calcolo si legge male su uno schermo nuovo che costa quanto un’auto usata.

La conseguenza per il progetto è una regola semplice: si sceglie in base a cosa si guarda. Boardroom con fogli di calcolo, disegni tecnici o dashboard vogliono il colore pieno. Sale dove si proiettano video e presentazioni con testo grande stanno benissimo con la compressione, e risparmiano metà della banda.

C’è infine un effetto che spiega molti reclami e che quasi nessuno considera: quando si condivide lo schermo in videoconferenza, la piattaforma comprime già il colore per conto suo, e lo fa con un codec pensato per i volti, non per le tabelle. Se l’impianto di sala comprime a sua volta, le due compressioni si sommano e il testo diventa illeggibile. In quel caso il problema non è il display, e non è nemmeno l’impianto: sono due processi che lavorano sullo stesso contenuto senza sapere l’uno dell’altro.

L’alimentazione: il conto che si sbaglia più spesso

L’errore è più banale e più frequente: il budget PoE si calcola sulla somma dei consumi reali, non sul numero di porte. Encoder, decoder, touchpanel, telecamere e access point si alimentano tutti dallo switch, e ogni dispositivo aggiunto dopo il collaudo consuma da quel budget. Il sintomo tipico è un apparato che non si accende più dopo aver aggiunto l’ultimo touchpanel, e non c’entra il touchpanel: c’entra che nessuno ha rifatto la somma.

Quando la rete non è omogenea

Una rete costruita e mantenuta con apparati di un solo produttore è la condizione migliore per un impianto audio video su IP, e non è affatto rara. Capita però che la rete non sia omogenea: si stratifica negli anni, oppure il segmento della sala viene aggiunto da chi installa l’impianto e non da chi gestisce la rete. Sulla maggior parte del traffico la differenza non si nota. Sul multicast sì, ed è il motivo per cui un impianto funziona in una sala e non in quella accanto, con la stessa configurazione.

Le differenze fra produttori si concentrano su tre comportamenti: cosa fa lo switch con un flusso di cui non conosce i destinatari, dato che alcuni lo inoltrano ovunque e altri lo scartano; quale apparato assume il ruolo di querier quando più switch potrebbero farlo, perché l’elezione automatica segue un criterio tecnico e non il buon senso; e quale versione del protocollo di iscrizione parla ciascuno, visto che versioni diverse possono non riconoscersi. A parte c’è il caso dello switch non gestito, che non sa cosa sia un’iscrizione multicast: inoltra tutto a tutti e da solo annulla il lavoro fatto sul resto della rete.

La regola pratica è questa. Dove possibile il segmento audio video si tiene di un solo produttore. Dove non è possibile si dichiara per iscritto chi fa il querier invece di lasciarlo all’elezione automatica, si allinea la versione del protocollo, si verifica modello per modello il comportamento sui flussi sconosciuti e si prova con tutte le sorgenti accese, non con un flusso di test.

Interoperabile sull’audio, proprietario sul video

Questa è una cosa che i materiali dei produttori non scrivono, e che cambia la valutazione di un investimento.

Sull’audio l’interoperabilità esiste davvero: AES67 permette a sistemi di marchi diversi di scambiarsi flussi. La linea NAV di Extron, per esempio, dichiara il supporto ad AES67 oltre alle funzioni di rete che servono al multicast e al controllo degli accessi.

Sul video no. Gli stessi apparati usano una codifica proprietaria, quindi il livello video resta legato al produttore scelto. Non è un difetto: è una scelta tecnica che serve a tenere bassa la latenza. Ma va saputa prima di firmare, perché significa che cambiare produttore sul video significa cambiare encoder e decoder di tutto l’impianto. Vale anche fra prodotti che dichiarano la stessa codifica: nella pratica trasmettitori e ricevitori si comprano dallo stesso produttore, perché l’interoperabilità dichiarata raramente sopravvive al collaudo.

C’è infine un terzo traffico che quasi nessuno mette a bilancio. Oltre alla distribuzione e alla conferenza, sulla stessa rete viaggia il controllo: touchpanel, sensori di presenza, comandi verso schermi e tende. È documentato, per esempio, che MaxHub abbia sviluppato driver per la piattaforma di controllo Extron, così che un unico pannello governi sala e sistema di conferenza. Attenzione però a non confondere i piani: quella è integrazione di controllo, non di trasporto. I comandi viaggiano su IP, il flusso audio video no. Sono tre traffici con requisiti diversi sulla stessa infrastruttura, e dimensionarne uno solo è il modo classico di sbagliare il progetto.

I sintomi, e cosa verificare per primo

Cosa si vede o si sente	Causa più probabile	Da verificare per primo
La rete dell’ufficio si ferma quando parte la sala	Multicast inondato su tutte le porte	IGMP snooping attivo e presenza di un querier
Il video funziona per qualche ora, poi si blocca	Iscrizioni multicast scadute senza querier	Chi fa il querier e con quale intervallo
Il labiale non torna, l’audio è sfasato	Sincronismo assente o interrotto	Se lo switch è configurato come orologio di riferimento
Ticchettio periodico o sillabe mancanti	Priorità del traffico non rispettata	Marcature sui flussi e code sullo switch
I dispositivi non si vedono fra loro	Apparati su sottoreti diverse	Che tutti gli apparati audio stiano nella stessa sottorete
Un apparato non si accende più	Budget di alimentazione esaurito	Somma dei consumi reali contro capacità dello switch
Funziona in una sala e non in quella accanto	Switch di produttori diversi con comportamenti differenti sul multicast	Chi fa il querier e quale versione del protocollo parla ogni apparato
Immagine a scatti solo su alcuni schermi	Collegamento sottodimensionato per la codifica scelta	Banda del collegamento verso quel punto

Perché conviene un interlocutore solo

Se chi progetta la rete e chi progetta la sala sono due fornitori diversi, il collaudo finisce quasi sempre in un rimpallo su di chi sia il problema, e il cliente resta in mezzo. È la ragione più concreta per cui su questi impianti conviene un interlocutore unico, come raccontiamo nella guida all’allestimento della sala riunioni e come si vede nell’auditorium a quattro sale con una sola regia.

Netframe è un system integrator IT dell’Emilia-Romagna con sede a Modena: progettiamo la rete aziendale e le sale riunioni, quindi l’impianto e l’infrastruttura che lo regge nascono insieme. Scrivici a info@netframe.it o chiamaci allo 059 7134794.

Domande frequenti

Conviene l’AV over IP o è meglio restare sui cavi dedicati?

Dipende dalla scala. Su una sala singola una distribuzione su doppino come l’HDBaseT è più semplice, più economica e più prevedibile: l’AV over IP aggiungerebbe complessità senza dare vantaggi. Conviene quando le sale sono molte, quando servono collegamenti fra edifici o quando l’impianto deve crescere nel tempo senza essere rifatto. Il punto di svolta non è il numero di schermi, è il numero di ambienti da collegare fra loro.

Serve una rete dedicata solo per l’audio e il video?

Non necessariamente una rete fisica separata, ma serve una VLAN dedicata con priorità configurata. La ragione è che un backup notturno o un aggiornamento di sistema non devono poter competere con un flusso audio in tempo reale. Su impianti grandi o critici la rete fisicamente separata resta la scelta più tranquilla, perché elimina il problema invece di gestirlo.

Perché l’audio va fuori sincrono con il video?

Perché manca un riferimento di tempo comune, oppure perché ce n’è più di uno. I dispositivi audio su rete si sincronizzano attraverso un protocollo dedicato, e se lo switch interrompe quei messaggi ogni apparato finisce per usare il proprio orologio. Il caso più insidioso è quando lo switch viene configurato come orologio di riferimento con la versione sbagliata del protocollo: sembra una configurazione più corretta e produce l’effetto opposto.

Il multicast può funzionare con switch di marche differenti?

Sì, ma è il punto in cui le reti miste danno più problemi, e quasi mai in modo evidente. Le differenze si concentrano su tre comportamenti: cosa fa lo switch con un flusso di cui non conosce i destinatari (alcuni lo inoltrano ovunque, altri lo scartano), quale apparato assume il ruolo di querier quando più switch potrebbero farlo, e quale versione del protocollo di iscrizione parla ciascuno. Il sintomo tipico non è un blocco netto ma un impianto che funziona in una sala e non in quella accanto, con la stessa configurazione. Se non si può usare un solo produttore sul segmento audio video, vanno dichiarati per iscritto il querier e la versione del protocollo, va verificato modello per modello il comportamento sui flussi sconosciuti, e va escluso qualsiasi switch non gestito, che inoltra tutto a tutti e annulla il lavoro fatto sul resto della rete.

Che caratteristiche deve avere lo switch per un impianto audio su rete?

Tre cose, nell’ordine. Deve governare il multicast, cioè avere l’IGMP snooping attivo e un querier definito nella rete. Deve rispettare le priorità del traffico, con code configurate e non solo dichiarate. E deve avere un budget di alimentazione calcolato sui consumi reali degli apparati collegati. La marca conta meno di queste tre condizioni, ma la documentazione del produttore va letta prima: non tutti dichiarano il comportamento su questi punti.

Quanta banda serve per il video su IP?

Dipende dalla codifica scelta, ed è per questo che la codifica è la prima decisione di progetto. Il video non compresso in 4K richiede infrastrutture a 10 Gigabit. Le codifiche a bassa latenza scendono su Gigabit, al prezzo di qualche millisecondo di ritardo e di una compressione che va valutata sui contenuti reali dell’azienda, non sulle immagini dimostrative. La domanda giusta da fare al fornitore non è quanta banda serve, ma quale codifica propone e perché.

Fonti

• Audinate, portale di supporto Dante: Connecting Dante Devices Across Different Subnets e How does Dante use DSCP / Diffserv priority values when configuring QoS?
• Cisco, Catalyst 9300 Software Configuration Guide, Cisco IOS XE 17.10, Configuring Precision Time Protocol (PTP): profilo media AES67, comportamento dell’IGMP snooping e supporto al sincronismo
• Huawei, CloudEngine S3700, S5700 e S6700 V600R024C00 Command Reference, 1588v2 (PTP) Configuration Commands: supporto a IEEE 1588v2 sui campus switch; la documentazione delle reti a latenza deterministica è sullo stesso portale di supporto
• Extron, NAV Pro AV over IP e scheda NAV E 511: supporto a IGMP v2 e v3 (RFC 2236 e RFC 3376), RTP (RFC 3550), 802.1X e AES67, codec PURE3
• Extron, Extron and MAXHUB, e MAXHUB, Extron, MAXHUB Deliver Scalable Control and Collaboration (11 giugno 2024): integrazione di controllo delle sale

Fonti verificate il 17 agosto 2026. Le funzionalità dichiarate dai produttori cambiano con le versioni firmware e software: verifica lo stato corrente prima di redigere un capitolato.

Netframe è un system integrator indipendente. Cisco e Huawei sono vendor su cui il team è certificato; Extron e MaxHub appartengono allo stack tecnologico utilizzato nei progetti e non costituiscono partnership commerciali.