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, quindi il traffico in uscita dal server cresce con il quadrato del numero di partecipanti. Un VPS da 1 GB o 2 GB con un uplink condiviso eseguirà correttamente il software. Non sarà però in grado di gestire la riunione plenaria che state immaginando.

Procedete quindi in questo ordine. Contate i partecipanti, calcolate i megabit e poi scegliete il server. L'installazione richiede venti minuti di copia e incolla. È l'uplink a determinare se gli altri riusciranno a sentirvi.

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

Partiamo dalla mesh. Ogni browser codifica il video della propria videocamera e invia direttamente una copia a ogni altro browser. Nessun media server interviene nel video. Una chiamata mesh tra due persone richiede un server di segnalazione e nient'altro. Per questo le chiamate uno a uno sono quasi gratuite da ospitare. La mesh smette di funzionare quando i partecipanti sono circa quattro o cinque, perché un laptop con una connessione 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 gli header 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.

La soluzione precedente è 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 è minima. Il costo in CPU è enorme. Oggi quasi nessuno usa un MCU per il video. Questa guida non lo usa.

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. Il valore cresce in modo lineare ed è innocuo. Il server invia N volte (N meno 1) volte 1.2 Mbps, perché ciascuna delle N persone deve ricevere gli altri N meno 1 flussi. È questo il secondo valore a porre fine ai 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. Leggete prima l'ultima riga. Cinquanta persone con la videocamera attiva richiedono 2,940 Mbps di traffico in uscita sostenuto da una singola macchina. Trenta persone richiedono 1,044 Mbps. Quattro persone richiedono 14.4 Mbps, un valore che qualsiasi VPS gestisce senza problemi. 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.

Le implementazioni reali restano al di sotto di questi valori. È utile sapere esattamente perché. Jitsi e LiveKit usano entrambi il simulcast: un mittente pubblica contemporaneamente diversi livelli di qualità e l'SFU inoltra un livello più basso a chi non è visualizzato sullo schermo. Jitsi dispone anche di un'impostazione last-N, che inoltra il video soltanto degli oratori più recenti. Entrambe le tecniche riducono molto il traffico. Nessuna modifica la forma della curva. Inoltre, entrambe smettono di essere utili nel momento in cui tutti attivano la videocamera e fissano sullo schermo gli altri partecipanti.

Cosa offre realmente l'uplink di un VPS?

Una pagina del piano indica «porta da 1 Gbps». Questa è la velocità della scheda di rete virtuale, non una garanzia sulla velocità del next hop. Il collegamento è condiviso con gli altri tenant sullo stesso host fisico. Per questo il throughput sostenuto durante le ore di maggiore carico è inferiore alla velocità della porta, e una videoconferenza rappresenta esattamente un carico sostenuto. La maggior parte dei piani prevede inoltre una quota mensile di trasferimento. Al superamento della quota, la velocità viene limitata oppure vengono addebitati costi aggiuntivi.

È questa quota a comparire in modo evidente in fattura. In un mese, venti ore della chiamata con trenta partecipanti trasferiscono in uscita dal server 9.4 TB, a 469.8 GB all'ora. Venti ore della chiamata con cinquanta partecipanti trasferiscono 26.5 TB. Verifica la quota di trasferimento prima della quantità di RAM. Se la pagina del piano non fornisce informazioni chiare, questa omissione è già una risposta. Interpretare correttamente un'offerta VPS economica è più importante per questo carico di lavoro che per quasi qualsiasi altro.

Jitsi Meet: la scelta predefinita e i 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 chiede un hostname e propone quindi una scelta per il certificato. Seleziona l'opzione Let's Encrypt e assegnagli un nome di dominio che punti già all'indirizzo pubblico di questo server. Il certificato viene emesso tramite una challenge HTTP, quindi la procedura fallisce se il nome punta altrove.

Apri quindi le porte. Sono quelle documentate nel manuale, con SSH per prima, in modo che ufw enable non ti 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

Le porte TCP 80 e 443 servono l'applicazione web e consentono il rinnovo del certificato. La porta UDP 10000 trasporta tutto l'audio e il video ed è quella che viene più spesso dimenticata. La porta UDP 3478 e la porta TCP 5349 appartengono al server coturn installato dal pacchetto Jitsi insieme al bridge. Forniscono 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 sulla porta UDP 10000. Se non visualizza nulla, il bridge non è stato avviato e /var/log/jitsi/jvb.log ne indica il motivo.

Per il dimensionamento, il manuale di Jitsi pubblica un punto di partenza specifico, mentre BigBlueButton ne indica 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 destinato a un uso intensivo. Una connettività di rete da 1,000 Mbps è spesso sufficiente. Il manuale precisa inoltre che configurazioni più piccole possono funzionare con 4 GB o 2 GB. Un dettaglio importante è il seguente: Prosody, il server XMPP che gestisce la segnalazione, può utilizzare un solo core. I core aggiuntivi aiutano il bridge, ma non apportano vantaggi alla segnalazione.

Perché tutti entrano nella chiamata, ma nessuno vede il video?

Questo è il problema tipico 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. Nei provider che assegnano alla macchina virtuale un indirizzo privato e vi associano un indirizzo pubblico, JVB rileva soltanto quello privato. Ogni client tenta quindi di inviare i flussi multimediali a un indirizzo come 10.0.0.5, ma i pacchetti non arrivano a destinazione.

Configura il bridge con entrambi gli indirizzi. Aggiungi 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"
        }
      ]
    }
  }
}

Riavvia con sudo systemctl restart jitsi-videobridge2. Ricava 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 configurazioni continuano a funzionare, ma per le nuove installazioni devi usare il blocco di mappatura riportato sopra.

L’altra causa possibile è un firewall non configurato. La maggior parte dei provider esegue un firewall di rete nel pannello di controllo, separato da ufw sul server, e la porta UDP 10000 deve essere aperta in entrambi. Per capire quale livello scarta i pacchetti, esegui sudo tcpdump -ni any udp port 10000 sul server mentre qualcuno accede dall’esterno. Se non arriva alcun pacchetto, il traffico non raggiunge la macchina e il blocco si trova a monte del sistema operativo. Se i pacchetti arrivano ma i riquadri restano neri, il bridge sta rispondendo con un indirizzo non raggiungibile dal client: il problema è quindi la mappatura. Se il componente che non sai configurare è ufw, le regole ufw realmente necessarie su un VPS spiega l’ordine delle regole che causa più spesso problemi.

BigBlueButton: pesante, vincolato 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 descritte 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 di produzione dichiarati dal progetto sono 16 GB di memoria con swap abilitato, 8 core CPU con elevate prestazioni single-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 del progetto inoltrano direttamente questo script a bash. Scaricalo e leggilo prima, perché modifica la configurazione di nginx, installa il proprio stack per i contenuti multimediali e l'audio, blocca le versioni dei pacchetti e assegna il nome host. Questo comportamento è previsto dal progetto, non è un difetto: BigBlueButton si aspetta di avere il controllo della macchina. Il flag -w configura il firewall, -s specifica il nome host, -e indica l'indirizzo che Let's Encrypt registra e -g aggiunge il front end Greenlight. Se lo stesso server gestisce anche la terminazione TLS per altri servizi, sposta BigBlueButton su un altro server oppure verifica di comprendere come funziona la configurazione del reverse proxy nginx prima che lo script la modifichi.

Confronta attentamente le due righe del grafico. 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. Considerale quindi come punti di partenza del rispettivo progetto, non come un confronto diretto. La differenza 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 sono quindi necessari un server XMPP, un runtime Java o un'applicazione Rails da mantenere in esecuzione. 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 disponibile su Ubuntu 24.04 contiene 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 cercare di usare il pacchetto della distribuzione.

Un gruppo è il termine usato da Galène per una stanza e corrisponde a un file JSON:

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

Apri https://your.server:8443/group/night-watch/ e accedi come vimes. Queste credenziali sono riportate direttamente nel README del progetto, quindi modificale prima che la porta sia raggiungibile da altri sistemi. Per una distribuzione reale, il progetto documenta un'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 contenuti multimediali. Fissa questo intervallo in modo da poter scrivere una sola regola firewall:

./galene -udp-range 40000-40100

L'opzione -turn è quella rilevante su un VPS. -turn ':1194' rimane in ascolto su tutti gli indirizzi IPv4 pubblici. -turn '203.0.113.1:1194' indica 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 di upgrade WebSocket. È importante sapere cosa viene gestito: i client continuano ad aprire flussi UDP diretti e connessioni TCP dirette verso la porta TURN. Il reverse proxy gestisce quindi soltanto la pagina e la segnalazione. I contenuti multimediali non lo attraversano.

La documentazione di Galène indica che sono sufficienti risorse server molto moderate, ma non pubblica un valore specifico. Non aspettarti quindi una cifra precisa. I calcoli della larghezza di banda riportati sopra restano validi. Il risparmio riguarda la memoria e i componenti necessari per tutto ciò che non fa parte dell'SFU.

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

Molti requisiti di "videoconferenza" riguardano in realtà una persona che presenta contenuti a un pubblico che scrive nella chat. Se questo è il tuo caso, un SFU è lo strumento sbagliato e l'economia 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 spettatore cresce in modo lineare anziché quadratico. Inoltre, poiché l'output è costituito da segmenti HTTP standard, puoi spostarlo dietro un object storage o una CDN e smettere di pagarlo 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 nella sezione precedente. L'installer scarica la release corrente e un binario di 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 associare un dominio al server.

Dal design HLS derivano due conseguenze. Gli spettatori sono in 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 utilizzati né UDP né TURN. Il servizio può quindi raggiungere reti in cui una chiamata WebRTC non riesce a stabilire la connessione.

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

Element Call su un server Matrix già in uso

Se gestisci già Matrix, la videochiamata è un componente aggiuntivo, non un secondo prodotto da amministrare. Non si tratta comunque di un solo pacchetto. Element Call richiede due componenti dietro il tuo 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) per la connessione. Questo servizio usa l’API di federazione Matrix, quindi deve 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, usato 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, a meno che davanti non sia presente un bilanciatore del carico

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, perché un intervallo aperto solo in parte causa errori per alcuni utenti e funziona per altri: è il tipo di malfunzionamento più difficile da diagnosticare. La configurazione lato 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. 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 può trovarsi su una rete aziendale o universitaria in cui il traffico UDP in uscita è completamente bloccato. Un altro può trovarsi dietro un NAT di livello carrier che assegna una porta sorgente diversa per ogni destinazione. Questa configurazione è chiamata NAT simmetrico e rende inutilizzabile l'indirizzo comunicato da STUN.

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

TURN su TCP tramite 443 o 5349 è il fallback che funziona quasi ovunque, perché una rete che blocca TLS su 443 ha già bloccato 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 include TURN sulla porta 1194. LiveKit integra un server TURN che si attiva 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

Su Debian e Ubuntu il servizio fornito dal pacchetto non si avvia finché non impostate TURNSERVER_ENABLED=1 in /etc/default/coturn. Un'istanza coturn installata ma mai abilitata appare dall'esterno esattamente come l'assenza completa di TURN. Per questo questa singola riga può far perdere intere serate.

Ora vediamo il costo che spesso non viene considerato. Un relay trasporta l'intero flusso multimediale di ogni partecipante inoltrato in entrambe le direzioni. Quando coturn condivide il server con l'SFU, gran parte di questo traffico attraversa il loopback e incide sulla CPU anziché sulla banda in uscita. Inoltre, il listener TLS cifra ogni pacchetto una seconda volta, oltre alla cifratura DTLS già applicata ai contenuti multimediali. Quando spostate TURN su un server dedicato, quel server richiede un piano di banda dimensionato con lo stesso criterio usato per l'SFU. TURN su TCP trasforma inoltre i contenuti multimediali in tempo reale in un flusso affidabile. Un pacchetto perso viene ritrasmesso invece di essere ignorato, quindi un partecipante inoltrato su un collegamento con perdite accumula ritardo anziché 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 esegue la transcodifica e quale costo comporta?

Un SFU inoltra i pacchetti e non decodifica mai il video. Per questo motivo, quattro core possono gestire una stanza che, sulla carta, sembra richiedere molte più risorse. Due funzionalità interrompono questo comportamento e spesso sorprendono chi le ha attivate 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 esegue continuamente il rendering dell’intera riunione, oltre a un encoder video attivo 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 video o audio. La registrazione richiede un secondo server, non una semplice casella di controllo.

La seconda è l’accesso telefonico. Collegare una linea telefonica a una conferenza significa convertire continuamente Opus a 48 kHz nel formato accettato dalla rete telefonica, in genere G.711 a 8 kHz, in entrambe le direzioni e per tutta la durata della chiamata. La transcodifica audio richiede molte meno risorse della transcodifica 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 esegue questo lavoro e, per lo stesso motivo di Jibri, deve essere eseguito su un server dedicato.

Quanto è grande il server necessario?

Per due persone, quasi nulla. Jitsi abilita per impostazione predefinita la modalità peer-to-peer quando ci sono esattamente due partecipanti. In questa modalità, la conferenza non invia i dati tramite il videobridge, ma usa direttamente la connessione tra i partecipanti. L'ingresso di una terza persona riattiva il bridge. Un VPS da 1 GB con Jitsi è quindi adatto per chiamate uno a uno, ma è inadeguato per quattro persone. Per questo motivo, «ha funzionato quando l'ho testato» è una segnalazione così comune.

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

Per trenta persone, il caso peggiore è 1,044 Mbps sostenuti, e venti ore di questo traffico corrispondono a 9.4 TB. A questa scala, bisogna valutare prima il costo della larghezza di banda e poi quello del server. Abilitare last-N, in modo che il bridge inoltri soltanto l'audio e il video degli ultimi oratori, impostare la videocamera disattivata come comportamento predefinito per i partecipanti e collocare l'SFU in un ambiente con un limite di trasferimento sufficiente a coprire questi calcoli.

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

Resta un ultimo aspetto del routing. 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'assetto più sostenibile con il budget di un piccolo VPS.

FAQ

Perché gli utenti possono entrare nella 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 popola ma tutti i riquadri restano neri, il percorso multimediale è interrotto mentre quello di segnalazione funziona. Controlla UDP 10000 in entrambi i firewall: quello del server e il firewall di rete separato disponibile nel pannello di controllo del provider. Verifica poi 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 sotto /etc/jitsi/videobridge/jvb.conf e riavvia jitsi-videobridge2. Eseguire sudo tcpdump -ni any udp port 10000 mentre qualcuno si connette indica quale dei due problemi è presente, perché l'assenza completa 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 ogni partecipante un livello di qualità completo, dal server escono circa 1,044 Mbps, pari a 469.8 GB all'ora. Questo è un calcolo basato su N volte (N meno 1) flussi da 1.2 Mbps ciascuno, non una misurazione del tuo ambiente. Simulcast e un'impostazione last-N riducono molto il consumo nell'uso normale, perché nella maggior parte dei momenti non tutti i partecipanti sono visualizzati sullo schermo. Dimensiona comunque il sistema considerando un valore vicino al caso peggiore, perché il caso peggiore è una riunione plenaria in cui tutti attivano contemporaneamente la videocamera.

Posso eseguire Jitsi Meet su un VPS con 1 GB?

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

Mi serve ancora 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 classe carrier che assegna una porta sorgente diversa per ogni destinazione, non può creare un percorso multimediale diretto, indipendentemente dalla natura pubblica dell'indirizzo del server. TURN su TCP alle porte 443 o 5349 fornisce un relay che il firewall del partecipante vede 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 molto più hardware di Jitsi Meet?

Perché svolge molte più funzioni del semplice inoltro video. Il requisito pubblicato per l'uso in produzione è di 16 GB di RAM e 8 core, contro 8 GB e 4 core indicati nel manuale di Jitsi. BigBlueButton esegue sullo stesso server uno stack completo per le conferenze audio, una lavagna condivisa e un livello per le presentazioni, una pipeline per la registrazione e la post-elaborazione, oltre a un front end web con account utente. Inoltre, impone requisiti specifici per la 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 di lavoro effettivo.