Videoconferenze self-hosted su VPS: banda e scelta

Le videoconferenze self-hosted su un VPS sono un problema di larghezza di banda

Le videoconferenze self-hosted falliscono sui server di piccole dimensioni per un solo motivo, che quasi mai riguarda l'installazione. Il componente server utilizzato da tutti gli strumenti moderni è un SFU (selective forwarding unit). Riceve un flusso video da ogni partecipante e ne inoltra una copia a tutti gli altri partecipanti. Di conseguenza, il traffico in uscita dal server cresce con il quadrato del numero di partecipanti. Un VPS da 1 GB o 2 GB su un uplink condiviso esegue il software senza problemi. Non è però in grado di gestire la riunione plenaria che stai pianificando.

Procedi quindi in questo ordine. Conta i partecipanti, calcola i megabit e scegli il server. L'installazione richiede venti minuti di operazioni di copia e incolla. È l'uplink a determinare se gli altri partecipanti riusciranno a sentirti.

Perché la larghezza di banda cresce con il quadrato dei partecipanti?

Partiamo dalla mesh. Ogni browser codifica il video della propria videocamera e invia una copia direttamente a ogni altro browser; nessun media server elabora il video. Una chiamata mesh tra due persone richiede un signalling server e nient’altro. Per questo le chiamate uno a uno sono quasi gratuite da ospitare. La mesh smette di funzionare con circa quattro o cinque persone, perché un laptop collegato a una rete domestica deve caricare contemporaneamente quattro o cinque copie separate del proprio video.

Un SFU funziona in modo diverso. Ogni browser carica una copia sul server. Il server legge le intestazioni RTP (real-time transport protocol) e inoltra i pacchetti agli altri partecipanti senza decodificare il video. Questo è tutto il meccanismo. Per questo un SFU richiede poca CPU e molta rete.

L’architettura più datata è un MCU (multipoint control unit). Decodifica ogni flusso in ingresso, li compone in un’unica immagine e ricodifica quell’immagine. La larghezza di banda in uscita è ridotta. Il costo in termini di CPU è enorme. Oggi quasi nessuno usa un MCU per il video, e questa guida non lo utilizza.

Passiamo ora ai calcoli per un SFU. Supponiamo che ogni persona invii video a 1.2 Mbps e che nessuno disattivi la videocamera. Il server riceve N volte 1.2 Mbps: una crescita lineare e trascurabile. Il server invia N volte (N meno 1) volte 1.2 Mbps, perché ognuna delle N persone deve ricevere gli altri N meno 1 flussi. È questa seconda cifra a far fallire i progetti.

[
  {
    "label": "4 people",
    "sfu_egress_mbps": 14.4,
    "egress_gb_per_hour": 6.5,
    "monthly_volume_tb": 0.13
  },
  {
    "label": "8 people",
    "sfu_egress_mbps": 67.2,
    "egress_gb_per_hour": 30.2,
    "monthly_volume_tb": 0.6
  },
  {
    "label": "15 people",
    "sfu_egress_mbps": 252,
    "egress_gb_per_hour": 113.4,
    "monthly_volume_tb": 2.3
  },
  {
    "label": "30 people",
    "sfu_egress_mbps": "1,044",
    "egress_gb_per_hour": 469.8,
    "monthly_volume_tb": 9.4
  },
  {
    "label": "50 people",
    "sfu_egress_mbps": "2,940",
    "egress_gb_per_hour": "1,323",
    "monthly_volume_tb": 26.5
  }
]

Queste righe contengono calcoli, non misurazioni di un server specifico. La colonna mensile presuppone venti ore di chiamate al mese. Leggi prima l’ultima riga. Cinquanta persone con la videocamera attiva richiedono 2,940 Mbps di traffico in uscita continuo da una singola macchina. Trenta persone richiedono 1,044 Mbps. Quattro persone richiedono 14.4 Mbps, un valore che qualsiasi VPS gestisce senza difficoltà. Tra la riga con quattro persone e quella con trenta persone, il numero di partecipanti cresce di sette volte e mezza, mentre il traffico in uscita cresce di oltre settanta volte.

Nelle implementazioni reali questi valori sono inferiori, ed è importante capire esattamente perché. Jitsi e LiveKit usano entrambi il simulcast: il mittente pubblica contemporaneamente più livelli di qualità e l’SFU inoltra un livello a bassa qualità a chi non è visualizzato sullo schermo. Jitsi dispone inoltre di un’impostazione last-N, che inoltra il video soltanto degli interlocutori che hanno parlato più recentemente. Entrambi i meccanismi riducono molto il traffico. Nessuno dei due modifica l’andamento della curva e smettono entrambi di essere utili quando tutti attivano la videocamera e fissano il video degli altri partecipanti.

Che cosa offre realmente l'uplink di un VPS?

Una pagina del piano indica una «porta da 1 Gbps». Si tratta della velocità della scheda di rete virtuale, non di una garanzia sulla capacità del collegamento successivo. Il collegamento è condiviso con gli altri tenant dello stesso host fisico. Per questo, durante le ore di maggiore utilizzo, il throughput sostenuto è inferiore alla velocità della porta. Una conferenza è esattamente un carico sostenuto. La maggior parte dei piani prevede inoltre un limite mensile di trasferimento. Superato tale limite, la velocità viene ridotta oppure vengono addebitati costi aggiuntivi.

È questo limite che compare come voce inattesa in fattura. In un mese, venti ore della chiamata con trenta partecipanti trasferiscono 9.4 TB in uscita dal server, a 469.8 GB all'ora. Venti ore della chiamata con cinquanta partecipanti trasferiscono 26.5 TB. Verificate il limite di trasferimento prima della quantità di RAM. Se la pagina del piano non lo specifica chiaramente, questa ambiguità è già una risposta. Leggere correttamente un'offerta VPS è più importante per questo carico di lavoro che per quasi ogni altro.

Jitsi Meet: la scelta predefinita e i relativi requisiti

Jitsi Meet è la soluzione con cui la maggior parte degli utenti dovrebbe iniziare. Si installa dal repository Debian del progetto, configura nginx e un certificato durante l'installazione e il videobridge (JVB) usa una sola porta UDP, mantenendo brevi le regole del firewall. Richiede Debian 11 o versioni successive oppure Ubuntu 22.04 o versioni successive.

sudo apt update
sudo apt install -y apt-transport-https curl gnupg
sudo add-apt-repository universe
sudo apt update
sudo curl -sL https://prosody.im/files/prosody-debian-packages.key -o /usr/share/keyrings/prosody-debian-packages.key
echo "deb [signed-by=/usr/share/keyrings/prosody-debian-packages.key] http://packages.prosody.im/debian $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/prosody-debian-packages.list
sudo apt install -y lua5.2
curl -sL https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'
echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
sudo apt update
sudo apt install -y jitsi-meet

Il programma di installazione richiede un hostname e propone quindi una scelta per il certificato. Selezionare l'opzione Let's Encrypt e specificare un nome di dominio che risolva già all'indirizzo pubblico di questo server. Il certificato viene rilasciato tramite una verifica HTTP, quindi un nome che punti altrove causa un errore in questa fase.

Aprire quindi le porte. Sono quelle documentate nel manuale, con SSH per prima, in modo che ufw enable non impedisca di accedere al server:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable

TCP 80 e 443 servono l'applicazione web e consentono il rinnovo del certificato. UDP 10000 trasporta tutto l'audio e il video ed è la porta che viene più spesso dimenticata. UDP 3478 e TCP 5349 appartengono al server coturn installato dal pacchetto Jitsi insieme al bridge. Costituiscono il percorso alternativo per gli utenti la cui rete blocca UDP.

sudo systemctl status jitsi-videobridge2
sudo ss -ulnp | grep 10000

Il primo comando dovrebbe indicare il servizio come attivo. Il secondo dovrebbe mostrare il bridge in ascolto su UDP 10000. Se non visualizza nulla, il bridge non è stato avviato e /var/log/jitsi/jvb.log indica il motivo.

Per il dimensionamento, il manuale di Jitsi pubblica un proprio punto di partenza, mentre BigBlueButton ne pubblica uno molto più elevato:

[
  {
    "label": "Jitsi Meet",
    "ram_gb": 8,
    "cpu_cores": 4,
    "uplink_mbps": "1,000"
  },
  {
    "label": "BigBlueButton 3.0",
    "ram_gb": 16,
    "cpu_cores": 8,
    "uplink_mbps": 250
  }
]

Il manuale di Jitsi suggerisce 8 GB di RAM e 4 core dedicati per un server adatto a un utilizzo intenso. In molti casi sono sufficienti 1,000 Mbps di connettività di rete. Indica inoltre che le installazioni più piccole funzionano con 4 GB o 2 GB. Un dettaglio di quella pagina è importante: Prosody, il server XMPP che gestisce la segnalazione, può utilizzare un solo core. I core aggiuntivi aiutano il bridge, ma non apportano benefici alla segnalazione.

Perché tutti partecipano alla chiamata, ma nessuno vede il video?

Questo è il problema standard di Jitsi su un VPS. L’elenco dei partecipanti si popola, la chat funziona, ma tutti i riquadri video restano neri. Il videobridge pubblicizza gli indirizzi che rileva sulle proprie interfacce. Se il provider assegna alla macchina virtuale un indirizzo privato e vi associa un indirizzo pubblico, JVB rileva soltanto quello privato. Di conseguenza, ogni client prova a inviare i dati multimediali a un indirizzo come 10.0.0.5, ma i pacchetti non arrivano a destinazione.

Indicate al bridge entrambi gli indirizzi. Aggiungete una mappatura statica a /etc/jitsi/videobridge/jvb.conf:

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "10.0.0.5"
          public-address = "203.0.113.10"
        }
      ]
    }
  }
}

Riavviate con sudo systemctl restart jitsi-videobridge2. Recuperate l’indirizzo locale da ip -4 addr show e quello pubblico dal pannello di controllo del provider. Le guide meno recenti configurano la stessa impostazione in /etc/jitsi/videobridge/sip-communicator.properties usando le chiavi org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS e org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS. Queste chiavi continuano a funzionare, ma per le nuove installazioni è consigliato usare il blocco di mappatura precedente.

L’altra causa possibile è un firewall non configurato. Molti provider gestiscono un firewall di rete dal pannello di controllo, separato da ufw sul server, e la porta UDP 10000 deve essere aperta su entrambi. Per capire quale livello blocca i pacchetti, eseguite sudo tcpdump -ni any udp port 10000 sul server mentre un utente partecipa dall’esterno. Se non arriva alcun pacchetto, la macchina non è raggiunta: il blocco si trova a monte del sistema operativo. Se i pacchetti arrivano ma i riquadri restano neri, il bridge risponde con un indirizzo non raggiungibile dal client: il problema è quindi la mappatura. Se il dubbio riguarda ufw, le regole ufw effettivamente necessarie su un VPS descrivono l’ordine delle regole che causa più spesso problemi.

BigBlueButton: pesante, vincolante e progettato per usare l’intero server

BigBlueButton è progettato per la didattica. Include una lavagna, stanze separate, sondaggi e un’area per le presentazioni. La pipeline di registrazione è una funzionalità principale, non un componente aggiuntivo. È inoltre di gran lunga l’opzione più pesante tra quelle disponibili e non è un pacchetto da aggiungere a un server esistente.

Ad agosto 2026, il percorso supportato è BigBlueButton 3.0 su Ubuntu 22.04, selezionato con il flag di versione jammy-300. I requisiti dichiarati dal progetto per l’uso in produzione sono 16 GB di memoria con swap abilitato, 8 core CPU con prestazioni elevate su un singolo thread, 250 Mbps di banda simmetrica e 500 GB di spazio su disco se si conservano le registrazioni (50 GB se vengono disabilitate). Le porte sono TCP 80 e 443, oltre all’intervallo UDP da 16384 a 32768.

wget -q https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh
less bbb-install.sh
bash bbb-install.sh -w -v jammy-300 -s bbb.example.com -e info@example.com -g

Gli esempi forniti dal progetto inviano direttamente quello script a bash. Scaricalo e leggilo prima di eseguirlo, perché riscrive la configurazione di nginx, installa il proprio stack multimediale e audio, blocca le versioni dei pacchetti e prende il controllo del nome host. Questo comportamento è previsto dal progetto, non è un difetto: BigBlueButton si aspetta di gestire direttamente la macchina. Il flag -w configura il firewall, -s è il nome host, -e è l’indirizzo che Let’s Encrypt registra e -g aggiunge il frontend Greenlight. Se la stessa macchina gestisce anche la terminazione TLS per altri servizi, sposta BigBlueButton su un’altra macchina oppure assicurati di capire come funziona la configurazione del reverse proxy nginx prima che lo script la modifichi.

Confronta attentamente le due righe della tabella. BigBlueButton richiede il doppio della memoria e il doppio dei core indicati per Jitsi, ma richiede un quarto della banda. Le due cifre non sono misurate nello stesso modo e presuppongono dimensioni diverse delle stanze. Considera quindi ciascun valore come il punto di partenza del relativo progetto, non come un confronto diretto. La differenza nel consumo di CPU è reale e dipende da tutte le attività che BigBlueButton svolge oltre all’inoltro del video.

Galène: l'opzione leggera

Galène è un SFU compatto scritto in Go. Viene compilato in un singolo binario statico, include il proprio client web e integra un server TURN. Non servono quindi un server XMPP, un runtime Java o un'applicazione Rails da mantenere attiva. Se ti serve una chiamata affidabile per dieci persone su una macchina con risorse limitate, prova questa soluzione prima di concludere che serva hardware più potente.

sudo apt update && sudo apt install -y git golang-go
git clone https://github.com/jech/galene
cd galene
CGO_ENABLED=0 go build -ldflags='-s -w'
mkdir groups

Il pacchetto golang-go su Ubuntu 24.04 è Go 1.22. Se go build segnala che il modulo richiede una versione più recente di Go, installa una toolchain aggiornata da go.dev invece di forzare il pacchetto della distribuzione.

Un gruppo è il termine usato da Galène per indicare una stanza e consiste in un file JSON:

echo '{"users": {"vimes": {"password":"sybil", "permissions":"op"}}}' > groups/night-watch.json
./galene &

Apri https://your.server:8443/group/night-watch/ ed esegui l'accesso come vimes. Queste credenziali sono riportate direttamente nel README del progetto, quindi modificale prima che la porta sia raggiungibile da altre reti. Per una distribuzione reale, il progetto documenta una unità systemd:

[Unit]
Description=Galene
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/galene
User=galene
Group=galene
ExecStart=/home/galene/galene
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Le porte sono TCP 8443 per l'interfaccia web, TCP e UDP 1194 per il server TURN integrato e un intervallo di porte UDP alte per i media. Fissa questo intervallo, così puoi scrivere una sola regola del firewall:

./galene -udp-range 40000-40100

L'opzione -turn è quella rilevante su un VPS. -turn ':1194' resta in ascolto su tutti gli indirizzi IPv4 pubblici. -turn '203.0.113.1:1194' comunica a Galène l'indirizzo che i client vedranno effettivamente. È necessario quando l'indirizzo della macchina è privato. -turn '' disabilita il server integrato, così puoi indicare un server esterno tramite data/ice-servers.json. Il valore predefinito è auto, che si comporta come :1194 quando non esiste alcun ice-servers.json.

Puoi mettere nginx davanti all'interfaccia web impostando proxyURL in data/config.json e facendo il proxy della location /ws con gli header per l'upgrade WebSocket. Considera i limiti di questa configurazione: i client aprono comunque flussi UDP diretti e connessioni TCP dirette verso la porta TURN. Il reverse proxy gestisce quindi soltanto la pagina e la segnalazione. I media non lo attraversano.

La documentazione di Galène indica che sono sufficienti risorse server molto contenute e non pubblica alcun valore specifico. Non aspettarti quindi una cifra precisa. Il calcolo della larghezza di banda riportato sopra resta pienamente valido. Il risparmio riguarda la memoria e i componenti aggiuntivi di tutto ciò che non fa parte dell'SFU.

Owncast: da uno a molti, con larghezza di banda lineare

Molti requisiti di «videoconferenza» riguardano in realtà una persona che presenta contenuti a un pubblico che scrive in chat. In questo caso, un SFU è lo strumento sbagliato e il modello dei costi cambia completamente. Owncast riceve uno stream RTMP da OBS o da un encoder simile e distribuisce HLS tramite il normale HTTPS. La larghezza di banda per ogni spettatore cresce in modo lineare anziché quadratico. Poiché l'output è costituito da segmenti HTTP standard, puoi spostarlo dietro un object storage o una CDN e smettere di sostenere questo costo sull'origine.

curl -sL https://owncast.online/install.sh -o install-owncast.sh
less install-owncast.sh
bash install-owncast.sh

La documentazione del progetto indica di non eseguire il servizio come root e di esaminare qualsiasi script remoto prima di eseguirlo. Per questo il download è un passaggio separato riportato sopra. L'installer scarica la release corrente e un binario ffmpeg se non ne hai già uno. Esegui ./owncast dalla directory di installazione e apri il pannello di amministrazione all'indirizzo /admin sulla porta 8080. L'accesso predefinito usa l'utente admin e la chiave di stream predefinita abc123 come password. Modificala prima di puntare un dominio al server.

Dal design HLS derivano due conseguenze. Gli spettatori ricevono il contenuto con un ritardo di alcuni secondi o minuti rispetto alla diretta, perché HLS distribuisce segmenti completi. Non è quindi possibile una conversazione interattiva. Inoltre, nel percorso non vengono usati né UDP né TURN. Il servizio può quindi raggiungere reti alle quali una chiamata WebRTC non riesce affatto a connettersi.

Owncast è anche l'unico strumento qui descritto che esegue intenzionalmente la transcodifica. Ogni qualità di output abilitata richiede un'ulteriore codifica ffmpeg dello stream in ingresso, attiva per tutta la durata della trasmissione. Su un VPS di piccole dimensioni, offri una o due qualità. Cinque qualità saturerebbero la CPU mentre la rete rimarrebbe inattiva.

Element Call su un server Matrix già in esecuzione

Se gestisci già Matrix, le videochiamate sono un’aggiunta, non un secondo prodotto da amministrare. Tuttavia, sono necessari più di un pacchetto. Element Call richiede due componenti dietro il homeserver. Il primo è un SFU LiveKit, che inoltra i flussi multimediali. Il secondo è il servizio di autorizzazione MatrixRTC, element-hq/lk-jwt-service, che fornisce al client l’URL WebSocket di LiveKit e un JWT firmato (JSON Web Token) con cui connettersi. Questo servizio usa l’API di federazione Matrix. Deve quindi essere preceduto da un reverse proxy TLS e avere un nome raggiungibile dalla federazione.

Le porte documentate di LiveKit:

• TCP 7880 per l’API e il WebSocket del client, dietro un proxy che termina TLS
• TCP 7881 per ICE su TCP, utilizzato quando un client non riesce a uscire tramite UDP
• UDP 50000-60000 per i flussi multimediali; ogni partecipante a una stanza usa due porte
• UDP 3478 e TCP 5349 se abiliti il server TURN integrato; la porta 5349 deve essere spostata su 443 se non c’è un load balancer davanti

Due porte per partecipante possono sembrare preoccupanti, ma non lo sono. Un intervallo di 10,000 porte copre migliaia di partecipanti e la capacità di uplink si esaurisce molto prima dell’intervallo. Apri comunque l’intero intervallo. Un intervallo aperto solo in parte causa infatti problemi per alcuni utenti e funziona per altri: è il tipo di errore più difficile da diagnosticare. La configurazione del homeserver è un’attività separata, descritta in gestire un homeserver Synapse su un VPS.

Perché una persona non riesce mai a connettersi? TURN e le reti che bloccano UDP

Prima definiamo alcuni termini, usati una sola volta ciascuno. ICE (interactive connectivity establishment) è il processo che due endpoint WebRTC usano per trovare un percorso funzionante tra loro. STUN (session traversal utilities for NAT) è un piccolo servizio che comunica al client quale indirizzo pubblico risulta visibile dall'esterno. TURN (traversal using relays around NAT) è un relay: quando non esiste un percorso diretto, entrambi i lati inviano i propri flussi multimediali al server TURN, che li inoltra.

TURN è necessario per i partecipanti che si trovano su reti non visibili. Uno di loro potrebbe trovarsi su una rete aziendale o universitaria in cui il traffico UDP in uscita è completamente bloccato. Un altro potrebbe trovarsi dietro un NAT di livello carrier che assegna una porta sorgente diversa per ogni destinazione. Questo comportamento si chiama NAT simmetrico e rende inutilizzabile l'indirizzo comunicato da STUN.

Il sintomo è specifico. La maggior parte delle persone entra e tutto funziona. Una persona vede l'elenco dei partecipanti e la chat, ma visualizza un riquadro nero e un indicatore di caricamento. Il browser ha raccolto i candidati, ma nessuna coppia ha funzionato e ICE è terminato con uno stato di errore. In Chrome, chrome://webrtc-internals aperto durante il tentativo mostra le coppie di candidati e l'errore. Chiedete alla persona di riprovare da un telefono con la rete dati mobile. Se in questo modo funziona, la causa è la rete utilizzata e TURN risolve il problema.

TURN su TCP sulla porta 443 o 5349 è il fallback che funziona quasi ovunque, perché una rete che blocca TLS sulla porta 443 blocca anche il web. Il pacchetto di Jitsi installa e configura coturn automaticamente. Per questo le regole firewall documentate includono UDP 3478 e TCP 5349. Galène integra TURN sulla porta 1194. LiveKit include un server TURN integrato che si abilita nella configurazione. Se eseguite coturn autonomamente:

sudo apt install -y coturn
sudo systemctl enable --now coturn

listening-port=3478
tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_STRING
realm=turn.example.com
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
min-port=49152
max-port=65535
no-multicast-peers

Queste impostazioni vanno inserite in /etc/turnserver.conf. Su Debian e Ubuntu, il pacchetto avvia coturn subito dopo l'installazione usando la versione predefinita di quel file. Di conseguenza, enable --now trova il servizio già in esecuzione e non modifica nulla. Le impostazioni diventano effettive quando eseguite sudo systemctl restart coturn. Ogni modifica successiva al file richiede lo stesso riavvio. Le guide meno recenti indicano anche di impostare TURNSERVER_ENABLED=1 in /etc/default/coturn. Solo il vecchio script init legge questa opzione. L'unità systemd usata dai pacchetti attuali non la legge. Quella riga quindi non modifica nulla e un'istanza di coturn che non è mai stata riavviata continua a usare il file predefinito.

Ora consideriamo il costo che spesso non viene indicato. Un relay trasporta in entrambe le direzioni tutti i flussi multimediali di ogni partecipante inoltrato. Quando coturn condivide il server con l'SFU, gran parte di questo traffico attraversa il loopback e consuma CPU invece di banda in uplink. Inoltre, il listener TLS cifra ogni pacchetto una seconda volta, oltre alla cifratura DTLS già usata dal flusso multimediale. Quando spostate TURN su un server dedicato, quel server richiede un piano di banda dimensionato come quello dell'SFU. TURN su TCP trasforma inoltre i flussi multimediali in tempo reale in un flusso affidabile. Un pacchetto perso viene ritrasmesso invece di essere ignorato. Di conseguenza, un partecipante inoltrato su un collegamento con perdite accumula ritardo invece di subire una breve interruzione. Il relay è un fallback che consente la connessione, ma con una qualità che il percorso diretto avrebbe garantito.

Quando l’SFU transcodifica e quanto costa?

Un SFU inoltra i pacchetti e non decodifica mai il video. Per questo motivo, quattro core possono gestire una stanza che sulla carta sembra impossibile da servire. Due funzionalità interrompono questa proprietà. Entrambe sorprendono chi le abilita tramite una casella di controllo.

La prima è la registrazione. Jitsi registra con Jibri e la documentazione di Jibri descrive esattamente il suo funzionamento: avvia un’istanza di Chrome renderizzata in un framebuffer virtuale, quindi acquisisce e codifica l’output con ffmpeg. Si tratta di un browser completo che renderizza l’intera riunione, oltre a un encoder video, in esecuzione continua per tutta la durata della chiamata. La stessa documentazione specifica che un singolo Jibri supporta una sola registrazione alla volta e che Jibri deve essere eseguito su una macchina o una macchina virtuale separata, senza altre applicazioni che utilizzino i dispositivi audio o video. La registrazione richiede un secondo server, non una semplice casella di controllo.

La seconda è l’accesso tramite telefono. Collegare una linea telefonica a una conferenza significa convertire Opus a 48 kHz nel formato accettato dalla rete telefonica, generalmente G.711 a 8 kHz, in entrambe le direzioni e continuamente per tutta la chiamata. La transcodifica audio è molto meno costosa di quella video, ma viene eseguita per ogni tratta della chiamata e non si interrompe mai. Il costo aumenta quindi con il numero di chiamanti. Se vuoi un numero per l’accesso telefonico, un server VoIP self-hosted è il componente che svolge questo lavoro e, per lo stesso motivo di Jibri, deve essere eseguito su un server dedicato.

Quali sono le dimensioni effettivamente necessarie?

Per due persone, quasi nulla. Jitsi abilita per impostazione predefinita la modalità peer-to-peer quando i partecipanti sono esattamente due. In questa modalità, la conferenza smette di inviare i dati tramite il videobridge e usa invece la connessione diretta. Quando entra una terza persona, il traffico torna a passare dal bridge. Un VPS da 1 GB con Jitsi è quindi adatto per chiamate individuali, ma poco indicato per quattro persone. Per questo la frase «ha funzionato durante il test» è così comune.

Per un massimo di circa dieci persone con le videocamere attive, 67.2 Mbps con otto partecipanti rientrano nella capacità sostenibile dell'uplink di un normale VPS. Due CPU virtuali e 4 GB sono sufficienti per eseguire Jitsi o Galène a queste dimensioni, purché non si registrino le sessioni. Monitorare il contatore del traffico trasferito, non il grafico della CPU.

Per trenta persone, nel caso peggiore il traffico sostenuto è pari a 1,044 Mbps e venti ore di utilizzo corrispondono a 9.4 TB. A questa scala, il costo della banda va calcolato prima di quello del VPS. Abilitare last-N in modo che il bridge inoltri soltanto l'audio e il video degli oratori più recenti, impostare le videocamere disattivate come comportamento predefinito per i partecipanti e collocare l'SFU in un ambiente con un limite di trasferimento sufficiente a sostenere questi volumi.

Oltre questa scala, un singolo VPS non è la soluzione adatta. L'evento potrebbe essere in realtà una trasmissione, nel qual caso Owncast insieme a una CDN costa una frazione di questa soluzione. In alternativa, servono più videobridge dietro un unico livello di signaling. Si tratta però di un progetto diverso da quello iniziale.

Resta un ultimo aspetto di instradamento. La maggior parte dei team ha bisogno della chat per molte più ore al giorno rispetto al video. La chat è economica da ospitare e semplice da mantenere operativa. Configurare un'alternativa self-hosted a Slack per il traffico quotidiano e mantenere un server per le conferenze soltanto per le chiamate pianificate è l'organizzazione che resta sostenibile anche con il budget ridotto di un piccolo VPS.

FAQ

Perché gli utenti possono partecipare alla mia riunione Jitsi ma non vedersi né sentirsi?

La chat e l'elenco dei partecipanti passano attraverso il canale di segnalazione, che usa TCP sulla porta 443, mentre audio e video usano UDP sulla porta 10000 verso il videobridge. Se l'elenco dei partecipanti si completa ma tutti i riquadri restano neri, il percorso multimediale non funziona mentre quello di segnalazione è operativo. Controlla UDP 10000 in entrambi i firewall: quello del server e il firewall di rete separato nel pannello di controllo del provider. Verifica quindi che il bridge conosca il proprio indirizzo pubblico: su una macchina virtuale con un indirizzo privato e uno pubblico associato, aggiungi una mappatura statica in ice4j.harvest.mapping dentro /etc/jitsi/videobridge/jvb.conf e riavvia jitsi-videobridge2. Esegui sudo tcpdump -ni any udp port 10000 mentre qualcuno si connette: il risultato indica quale dei due problemi è presente, perché l'assenza totale di pacchetti significa che il blocco si trova a monte del sistema operativo.

Quanta larghezza di banda usa una videochiamata con 30 persone?

Nel caso peggiore, in cui tutti abbiano la videocamera attiva e l'SFU inoltri a tutti un livello alla qualità massima, dal server escono circa 1,044 Mbps, pari a 469.8 GB all'ora. Si tratta del calcolo basato su N volte (N meno 1) flussi da 1.2 Mbps ciascuno, non di una misurazione del tuo ambiente. In condizioni normali, simulcast e un'impostazione last-N riducono molto il consumo, perché nella maggior parte dei casi non tutti i partecipanti sono visualizzati contemporaneamente. Dimensiona comunque l'infrastruttura considerando un valore vicino al caso peggiore, perché il caso peggiore si verifica quando tutti attivano la videocamera durante una riunione plenaria.

Posso eseguire Jitsi Meet su un VPS da 1 GB?

L'installazione riesce e una chiamata tra due persone funziona, in parte perché Jitsi usa la modalità peer-to-peer con esattamente due partecipanti e non utilizza affatto il videobridge. Non è però un server adatto alle chiamate di gruppo. Prosody, il videobridge e il runtime Java richiedono tutti memoria; il suggerimento del manuale è 8 GB per una distribuzione seria e il consumo di larghezza di banda diventerà un limite prima della memoria. Se disponi soltanto di un server da 1 GB, a questa dimensione Galène è più adatto di Jitsi.

Ho ancora bisogno di un server TURN se il mio VPS ha un indirizzo IP pubblico?

Sì. Il problema risolto da TURN si trova dall'altra parte della chiamata. Un partecipante su una rete aziendale che blocca il traffico UDP in uscita, oppure dietro un NAT di livello carrier che assegna una porta sorgente diversa per ogni destinazione, non può stabilire un percorso multimediale diretto, indipendentemente dalla visibilità pubblica dell'indirizzo del server. TURN su TCP tramite 443 o 5349 fornisce un relay che per il firewall appare come normale traffico web. L'installazione del pacchetto Jitsi configura coturn in questo modo per impostazione predefinita; per questo le regole firewall documentate aprono UDP 3478 e TCP 5349.

Perché BigBlueButton richiede hardware molto più potente di Jitsi Meet?

Perché svolge molte più operazioni del semplice inoltro video. Il requisito di produzione pubblicato è 16 GB di RAM e 8 core, rispetto a 8 GB e 4 core indicati nel manuale di Jitsi. BigBlueButton esegue sulla stessa macchina uno stack completo per le conferenze audio, un livello per lavagna condivisa e presentazioni, una pipeline per registrazione e post-processing e un front end web con account utente. Inoltre impone vincoli precisi sulla piattaforma: ad agosto 2026 l'installazione supportata è la versione 3.0 su Ubuntu 22.04. Entrambi i valori provengono dalla documentazione dei rispettivi progetti e costituiscono punti di partenza, non misurazioni del carico effettivo.