L'aggiunta di server Jitsi Videobridge (JVB) è il metodo standard per aumentare la capacità multimediale di una singola implementazione di Jitsi Meet. Mantenendo i servizi web, Prosody e Jicofo sull'host Meet esistente, si aggiungono macchine bridge indipendenti che si registrano alla stessa sala di rilevamento bridge di Prosody. Jicofo può quindi assegnare nuove conferenze a un bridge disponibile. In questa configurazione di base, i partecipanti a una conferenza utilizzano un bridge selezionato; non è necessario Octo solo perché l'implementazione prevede più server JVB.
Questa guida segue la configurazione scalabile basata su pacchetti per Debian/Ubuntu descritta nel Manuale di Jitsi, verificata il 6 ottobre 2026. Le dipendenze esatte dei pacchetti e la configurazione generata possono variare a seconda della distribuzione, della versione del pacchetto Jitsi e del metodo di installazione utilizzato (Docker o altro). Utilizzare la guida di installazione ufficiale corrispondente alla propria implementazione.
Verificato: una singola installazione di Jitsi Meet può utilizzare più Videobridge. Jicofo monitora i bridge e assegna una nuova conferenza a un bridge. L'esempio semplificato del manuale di Jitsi prevede che i servizi Meet siano installati su un server e che i tre JVB siano su server separati. Ogni bridge deve essere raggiungibile dai partecipanti alla riunione per i contenuti multimediali e dall'infrastruttura Meet per la segnalazione.
Errore comune: "Ho bisogno di un bilanciatore di carico davanti ai JVB." Nella configurazione multi-bridge documentata, Jicofo seleziona un bridge; i client inviano quindi i contenuti multimediali a quel bridge. Un bilanciatore di carico HTTP generico davanti ai contenuti multimediali UDP non sostituisce il rilevamento del bridge o l'assegnazione della conferenza. Soluzione: aggiungere ogni JVB al pool di bridge Prosody/Jicofo e pubblicare il suo indirizzo multimediale raggiungibile. Non indirizzare il traffico multimediale di ogni bridge verso un VIP UDP arbitrario.
Errore comune: "Un maggior numero di bridge fa sì che una riunione si estenda automaticamente a tutti i server". Nella configurazione di base, Jicofo assegna una conferenza a un bridge. La distribuzione dei partecipanti di una conferenza tra regioni o bridge è gestita da una topologia di relay separata chiamata Octo (relay sicuri nella documentazione JVB corrente). Soluzione: se l'obiettivo è un maggior numero di riunioni simultanee, si può iniziare con il pooling di bridge standard; valutare Octo solo quando una conferenza deve necessariamente utilizzare bridge in più sedi o quando è necessario quel comportamento di relay.
Scegliere un nome host o indirizzo pubblico e stabile per ogni JVB. Assegnare a ogni VM un'identità univoca del sistema operativo e un nickname univoco per l'istanza JVB quando la configurazione utilizza la presenza MUC XMPP. Tutti i bridge devono essere in grado di raggiungere lo stesso servizio Prosody e la stessa sala di brewery del bridge. Mantenere le versioni allineate: Jicofo non mescolerà bridge con versioni diverse nella stessa conferenza e la documentazione di relay attuale ribadisce questo vincolo per Octo.
| Sentiero | Usalo quando | Cosa aggiunge |
|---|---|---|
| Molteplici JVB, una regione | È necessaria una maggiore capacità per gestire riunioni separate e simultanee. | Installazione del bridge, registrazione, accesso alla rete e convalida. |
| Octo Relays tra le regioni | Una conferenza necessita di partecipanti o di collegamenti mediatici provenienti da più di una regione. | Impostazioni di identità e regione del relay, connettività WebSocket di Colibri, strategia Jicofo e informazioni corrette sulla regione del client. |
Dipende dal tuo ambiente: non esiste un numero universale di partecipanti per VM. La documentazione sui requisiti di Jitsi stessa enfatizza la capacità di rete e il carico di lavoro piuttosto che un singolo valore fisso per la dimensione. Codec, risoluzione, simulcast, velocità dei pacchetti, conferenze simultanee e larghezza di banda del provider influiscono tutti sulla capacità. Azione: stabilisci una base di riferimento sul tuo carico di lavoro effettivo, quindi aggiungi un bridge alla volta e osserva CPU, throughput di rete, perdita di pacchetti e qualità della conferenza.
Prima di aggiungere macchine, verificare che la pagina Meet esistente si carichi correttamente, che Prosody e Jicofo siano in esecuzione e che una chiamata di prova venga completata tramite il bridge corrente. Annotare le versioni del pacchetto Jitsi. Un problema di segnalazione o di configurazione del certificato sul server principale farà apparire un nuovo bridge come non configurato correttamente, anche se la sua rete è funzionante.
Su un'installazione di pacchetti Debian/Ubuntu, ispeziona i servizi systemctl status prosody jicofo jitsi-videobridge2e analizza i relativi log. Utilizza i nomi dei servizi presenti nella tua installazione; le implementazioni in container espongono comandi e posizioni dei log diversi.
Assegnate a ciascun bridge un indirizzo pubblico univoco o una mappatura NAT uno a uno correttamente configurata. La guida alla configurazione scalabile elenca i seguenti percorsi tipici: i client pubblici raggiungono l'host web su TCP 80/443; i server JVB raggiungono Prosody su TCP 5222; e i client raggiungono ciascun Videobridge su UDP 10000 per i contenuti multimediali. La porta TCP 80 viene generalmente utilizzata per la configurazione di certificati o reindirizzamenti, mentre un sito Meet di produzione dovrebbe utilizzare HTTPS.
Dipende dalla rete: NAT, gruppi di sicurezza cloud, IPv6, TURN e reti aziendali restrittive potrebbero richiedere percorsi o candidati aggiuntivi. L'elenco di porte predefinito non garantisce il funzionamento dei contenuti multimediali attraverso il firewall specifico. Azione: verificare il flusso di pacchetti verso ciascun indirizzo bridge pubblico da una rete client esterna ed eseguire una chiamata effettiva; una connessione XMPP riuscita da sola non è sufficiente a verificare il funzionamento dei contenuti multimediali UDP.
Utilizzare il repository Jitsi e le istruzioni per l'installazione dei pacchetti che corrispondono alla distribuzione dell'host Meet. Su ogni nuovo nodo Debian/Ubuntu, installare jitsi-videobridge2il pacchetto e rispondere alle richieste di configurazione con il nome host di Meet, come indicato nella configurazione scalabile ufficiale. Il manuale afferma che, per la configurazione basata su pacchetti documentata, il bridge non necessita di ulteriori modifiche rispetto alla configurazione predefinita dopo l'installazione.
Non installare un secondo stack Jitsi Meet completo su ogni bridge, a meno che non si desideri intenzionalmente avere implementazioni Meet indipendenti. Per un pool di bridge, mantieni i ruoli web, Prosody e Jicofo sull'host principale e aggiungi i servizi JVB alle altre macchine. Utilizza la stessa versione di JVB supportata su tutto il pool; esegui gli aggiornamenti in modo graduale per evitare di lasciare un pool con versioni miste più a lungo del necessario.
Nella configurazione basata su pacchetti, lasciare innanzitutto che la configurazione ufficiale del pacchetto generi le impostazioni previste. I JVB devono connettersi a Prosody e annunciare la presenza del bridge allo stesso MUC del birrificio monitorato da Jicofo. Se si utilizza il percorso di configurazione client XMPP corrente, la documentazione JVB mostra le parti rilevanti in videobridge.statse videobridge.apis.xmpp-client.configs; Jicofo deve unirsi al birrificio corrispondente utilizzando jicofo.bridge.brewery-jid.
Una tipica configurazione moderna ha questa forma; sostituite tutti i valori di esempio con i valori della vostra installazione e proteggete il segreto condiviso:
videobridge {
stats {
enabled = true
transports = [{ type = "muc" }]
}
apis {
xmpp-client {
configs {
xmpp-server-1 {
hostname = "meet.example.com"
domain = "auth.meet.example.com"
username = "jvb"
password = "REPLACE_WITH_SECRET"
muc_jids = "JvbBrewery@internal.auth.meet.example.com"
muc_nickname = "bridge-01"
}
}
}
}
}Utilizzare un diverso muc_nicknamesu ogni bridge (ad esempio, bridge-02e bridge-03). Il progetto JVB avverte che i nickname devono essere univoci tra le istanze. Il nome esatto del file di configurazione e la necessità di questo blocco esplicito dipendono dal pacchetto e dalla configurazione esistente; evitare di sovrapporre una configurazione moderna scritta manualmente alle impostazioni generate dal pacchetto legacy senza consultare la documentazione della versione installata.
Riavvia o avvia JVB su ogni nuovo host, quindi verifica che rimanga attivo e si connetta a Prosody. La guida alla configurazione scalabile consiglia di controllare i log di Prosody e Jicofo per confermare le connessioni bridge e che Jicofo rilevi i bridge. Se uno non viene rilevato, controlla in quest'ordine: risoluzione DNS e raggiungibilità TCP 5222; credenziali XMPP e dominio; ortografia esatta del MUC del birrificio; nickname duplicato; infine compatibilità della versione di JVB/Jicofo.
Avvia diverse nuove riunioni di prova e verifica che Jicofo le distribuisca nel pool disponibile nel tempo. È previsto che una riunione finisca su un bridge; ciò non indica un errore di bilanciamento. Utilizza l'interfaccia di debug di Jicofo, se abilitata e con accesso limitato, per esaminare i bridge disponibili e le conferenze attive. La documentazione di JVB fornisce curl http://localhost:8888/debugun esempio di debug locale; configura o disattiva le interfacce di diagnostica del firewall in modo che rimangano private.
Eseguire dei test con client esterni alla rete del server. Verificare che audio e video funzionino correttamente, quindi esaminare l'indirizzo del bridge selezionato e il flusso UDP. Se un bridge appare in Jicofo ma le chiamate falliscono solo quando viene selezionato tale bridge, esaminare il suo indirizzo pubblico, il mapping NAT, il firewall UDP e i candidati pubblicizzati. Durante la manutenzione, escludere un bridge dalla rotazione solo tramite una procedura di svuotamento o distribuzione supportata per la versione installata; il riavvio di un bridge attivo può interrompere le riunioni ad esso assegnate.
Octo è l'argomento giusto quando una singola conferenza deve utilizzare più bridge, spesso perché i partecipanti sono distribuiti in diverse regioni. Non è un prerequisito per aggiungere JVB per la capacità ordinaria. La documentazione attuale sui relay JVB richiede la configurazione del relay su ciascun bridge partecipante, Colibri WebSockets per le connessioni bridge-to-bridge e un'adeguata strategia di selezione del bridge Jicofo. Il comportamento in base alla regione dipende anche dalla fornitura di informazioni accurate sulla regione del client alla configurazione Meet servita.
Una configurazione di relay include un indirizzo univoco relay-ide una regione per ogni bridge, mentre Jicofo abilita Octo e seleziona una strategia come RegionBasedBridgeSelectionStrategy. Gli endpoint WebSocket di relay devono anche essere instradati correttamente attraverso qualsiasi proxy. Queste impostazioni cambiano a seconda delle release e delle topologie, quindi segui la guida di relay corrente e convalida i percorsi proxy esatti prima del rollout.
Azione: Lascia Octo disabilitato per un semplice pool di bridge a regione singola. Se hai esigenze multi-regione, esegui dei test con la strategia di suddivisione documentata in un ambiente di staging, esamina il selettore di bridge e lo stato della conferenza di Jicofo, quindi configura le regioni client e la selezione basata sulla regione. Non impostare le etichette di regione finché non sai come i client riceveranno i metadati di regione corrispondenti.
Se gli utenti segnalano problemi solo su un JVB, confrontare il percorso di rete e la configurazione di quel nodo con quelli di un peer funzionante prima di estendere l'intero cluster. Se tutti i bridge presentano un degrado simultaneo, il collo di bottiglia potrebbe essere la larghezza di banda condivisa, i servizi di segnalazione principali o la rete dei partecipanti. L'espansione funziona quando i nuovi bridge sono raggiungibili in modo indipendente, correttamente registrati e riducono in modo misurabile il carico durante test realistici.
Confronta sei server e collettori syslog gratuiti per Windows e Linux, inclusi strumenti con interfaccia grafica, opzioni open source, funzionalità di ricerca, avvisi e trasporto sicuro.
Scopri cosa fa Microsoft IIS, come funzionano la sua pipeline di richieste e i pool di applicazioni e quando Apache, NGINX o Caddy potrebbero essere più adatti alle tue esigenze di server web.
Diagnostica i picchi di utilizzo della CPU del browser Jitsi Meet e riduci il carico del client controllando i riquadri video, gli effetti della fotocamera, la grafica del browser e le impostazioni dell'host.
Monitora lo stato di salute, il carico della conferenza e il traffico di Jitsi Videobridge con il suo endpoint Prometheus integrato, quindi esplora e visualizza i dati in Grafana.
Configura un dominio personalizzato per Jitsi Meet Docker con DNS, URL pubblico, HTTPS, Let's Encrypt, porte del firewall, impostazioni NAT e verifica end-to-end.
Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.
Scopri come diagnosticare e risolvere l'avviso di configurazione di PHP OPcache di Nextcloud controllando l'SAPI PHP attivo, i limiti di dimensionamento, i commenti e le impostazioni di riconvalida.
Risolvere i problemi di migrazione del database Kopano dopo un aggiornamento di MySQL o MariaDB verificando i backup, le versioni del server, le modalità SQL, il set di caratteri, lo stato dello schema e i log.
Collega Nextcloud a LDAP o Active Directory con trasporto sicuro, filtri per utenti e gruppi, attributi di accesso e un'implementazione collaudata.
Risolvi i problemi di notifiche di Element Android sui telefoni senza Google configurando UnifiedPush, le autorizzazioni Android, le impostazioni della batteria ed eseguendo test di verifica affidabili.
