Videoconferenze: quanta banda serve davvero e cosa conta di più

Quando una videoconferenza va male la colpa viene quasi sempre data alla "linea lenta". Nella maggior parte dei casi la banda è abbondante e il problema è altrove: jitter, packet loss, upload saturo o un firewall che tratta il traffico real-time come un download qualsiasi. Ecco i numeri reali e cosa controllare.

Quanta banda serve per partecipante

Valori indicativi per flusso, in entrambe le direzioni:

• Solo audio: 50-100 kbps. Trascurabile.
• Video 360p: circa 500 kbps.
• Video 720p: 1-1,5 Mbps.
• Video 1080p: 2-3 Mbps.
• Condivisione schermo statica: 150-300 kbps; con contenuto in movimento o video sale a 2 Mbps e oltre.

Il calcolo che serve davvero è quello aggregato. Un ufficio con 10 persone in call contemporaneamente a 720p consuma circa 15 Mbps in upload e altrettanti in download nel caso peggiore. Su una FTTH con 300/100 Mbps non è un problema; su una FTTC con 20 Mbps di upload lo diventa appena si aggiungono backup in cloud o sincronizzazioni di file.

La direzione critica è quasi sempre l'upload. Ogni partecipante invia il proprio flusso verso il server della piattaforma, e le linee asimmetriche hanno lì il collo di bottiglia.

I parametri che contano più della banda

• Latenza (RTT): sotto i 100 ms la conversazione è naturale. Tra 100 e 200 ms si iniziano a percepire sovrapposizioni. Oltre i 300 ms diventa faticosa.
• Jitter: la variazione della latenza tra pacchetti consecutivi. Va tenuto sotto i 30 ms. È il responsabile principale dell'audio "robotico": il jitter buffer del client deve scartare o ritardare pacchetti arrivati fuori tempo.
• Packet loss: sotto l'1% è gestibile con la correzione d'errore. Sopra il 3% l'audio si spezza e il video si blocca a scatti. Una perdita anche minima ma costante è peggiore di un burst isolato.

Un collegamento da 1 Gbps con 5% di packet loss dà una call peggiore di uno da 20 Mbps pulito. È il motivo per cui aumentare il profilo di connettività spesso non risolve nulla.

Bufferbloat: il colpevole più frequente

Il sintomo classico è la call che degrada solo quando qualcuno in casa o in ufficio scarica qualcosa. Il router accoda i pacchetti in buffer sovradimensionati e la latenza schizza da 20 ms a 500 ms sotto carico, anche se lo speed test continua a mostrare il pieno throughput.

La soluzione non è più banda ma una disciplina di code moderna: CAKE o fq_codel, impostati a circa il 90-95% della velocità reale della linea. Su un router che lo supporta si passa da centinaia di millisecondi di latenza sotto carico a poche decine, e il problema sparisce.

Priorità del traffico

Le piattaforme di videoconferenza marcano i pacchetti con DSCP: tipicamente EF (46) per l'audio, AF41 (34) per il video, AF21 (18) per la condivisione schermo. Perché serva a qualcosa devi:

• Rispettare la marcatura sul router invece di azzerarla, come fanno molti apparati in configurazione di fabbrica.
• Mappare quelle classi su code prioritarie in uscita verso la WAN.
• Non fidarti della marcatura oltre il tuo perimetro: sulla rete pubblica il rispetto del DSCP non è garantito, quindi il QoS ti protegge dalla congestione locale, non da quella di transito.

Se il router non gestisce DSCP, una regola più grezza ma efficace è classificare per porta UDP: le piattaforme usano prevalentemente UDP nell'intervallo 3478-3481 e in range alti dinamici.

Errori di configurazione ricorrenti

• UDP bloccato in uscita: il client fa fallback su TCP 443. Funziona, ma la ritrasmissione TCP sotto perdita introduce ritardi enormi. Verifica che l'UDP verso i server della piattaforma sia consentito.
• SIP ALG o deep inspection attivi: interferiscono con i flussi real-time. Vanno disattivati.
• Doppio NAT: complica il NAT traversal e allunga il tempo di negoziazione ICE. Se hai un modem del provider in cascata al tuo router, metti il primo in bridge.
• Wi-Fi invece del cavo: sulla postazione fissa il cavo elimina in un colpo solo jitter da interferenza, roaming e canali congestionati. È l'intervento con il miglior rapporto tra sforzo e risultato.
• VPN sempre attiva: instradare la call dentro un tunnel verso la sede aggiunge un hop e spesso satura l'uplink dell'ufficio. Le piattaforme cloud vanno escluse dal tunnel con split tunneling.
• Access point sovraffollato: oltre 20-25 client attivi per radio la contesa del mezzo aumenta il jitter. Serve un AP in più, non un router più potente.

Come diagnosticare in due minuti

Durante una call problematica, lancia un ping continuo verso un IP stabile e osserva la deviazione dei tempi: valori che oscillano tra 20 e 400 ms indicano bufferbloat o saturazione. Poi controlla le statistiche interne della piattaforma, che riportano in tempo reale jitter, perdita e banda usata per flusso: se il client segnala perdita in ricezione il problema è a monte, se la segnala in trasmissione è sul tuo uplink o sulla tua rete locale.