Adăugarea de servere Jitsi Videobridge (JVB) este modalitatea normală de a crește capacitatea media pentru o implementare Jitsi Meet. Păstrați serviciile web, Prosody și Jicofo pe gazda Meet existentă, apoi adăugați mașini bridge independente care se înregistrează la aceeași cameră Prosody de descoperire a bridge-urilor. Jicofo poate apoi plasa noi conferințe pe un bridge disponibil. Pentru acest design de bază, participanții la o conferință utilizează un bridge selectat; nu aveți nevoie de Octo doar pentru că implementarea are mai multe servere JVB.
Acest ghid urmează configurarea scalabilă bazată pe pachete Debian/Ubuntu din Manualul Jitsi, verificată la 6 octombrie 2026. Dependențele exacte ale pachetelor și configurația generată pot varia în funcție de distribuție, versiunea pachetului Jitsi și dacă serverul a fost instalat cu Docker sau cu o altă metodă. Folosiți ghidul oficial de instalare corespunzător implementării existente.
Verificat: O singură instalare Jitsi Meet poate utiliza mai multe Videobridge-uri. Jicofo monitorizează bridge-urile și atribuie o nouă conferință unei bridge-uri. Exemplul simplificat din Manualul Jitsi plasează serviciile Meet pe un server și trei JVB-uri pe servere separate. Fiecare bridge trebuie să fie accesibil participanților la întâlnire pentru media și infrastructurii Meet pentru semnalizare.
Concepție greșită des întâlnită: „Am nevoie de un echilibrator de sarcină în fața JVB-urilor.” În designul multi-bridge documentat, Jicofo selectează o bridge; clienții trimit apoi media către acea bridge. Un echilibrator de sarcină HTTP generic în fața media UDP nu înlocuiește descoperirea bridge-urilor sau plasarea conferințelor. Acțiune: Adăugați fiecare JVB la pool-ul de bridge-uri Prosody/Jicofo și publicați adresa sa media accesibilă. Nu direcționați traficul media al fiecărei bridge-uri către un singur VIP UDP arbitrar.
Concepție greșită des întâlnită: „Mai multe punți fac ca o întâlnire să se întindă automat pe toate serverele.” În configurația de bază, Jicofo atribuie o conferință unei punți. Răspândirea participanților de la o conferință în regiuni sau punți este o topologie separată de retransmisie numită Octo (relee securizate în documentația JVB actuală). Acțiune: Începeți cu o pooling obișnuită de punți dacă obiectivul dvs. este reprezentat de mai multe întâlniri simultane; investigați Octo doar atunci când o conferință trebuie să utilizeze punți în mai multe locații sau aveți nevoie de acel comportament de retransmisie.
Alegeți un nume de gazdă sau o adresă publică și stabilă pentru fiecare JVB. Atribuiți fiecărei mașini virtuale o identitate unică a sistemului de operare și un pseudonim unic de instanță JVB atunci când configurația utilizează prezența XMPP MUC. Toate punțile ar trebui să poată accesa același serviciu Prosody și aceeași sală de fabricație a punților. Mențineți versiunile aliniate: Jicofo nu va amesteca punți cu versiuni diferite în aceeași conferință, iar documentația actuală a retransmiterilor repetă această constrângere pentru Octo.
| Cale | Folosește-l când | Ceea ce adaugă |
|---|---|---|
| Mai multe JVB-uri, o singură regiune | Aveți nevoie de mai multă capacitate pentru întâlniri simultane separate. | Instalarea, înregistrarea, accesul la rețea și validarea punții. |
| Relee Octo în diferite regiuni | O conferință are nevoie de participanți sau punți media din mai multe regiuni. | Setările de identitate și regiune a retransmiterii, conectivitatea Colibri WebSocket, strategia Jicofo și informațiile corecte despre regiunea clientului. |
Depinde de mediul dvs.: Nu există un număr universal de participanți per mașină virtuală. Documentația proprie a cerințelor Jitsi pune accentul pe capacitatea rețelei și volumul de lucru pe un singur număr fix de dimensionare. Codecul, rezoluția, simulcast-ul, ratele de pachete, conferințele concurente și lățimea de bandă a furnizorului afectează capacitatea. Acțiune: Stabiliți o bază pentru volumul de lucru real, apoi adăugați câte o punte pe rând și observați procesorul, debitul rețelei, pierderea de pachete și calitatea conferinței.
Înainte de a adăuga mașini, verificați dacă pagina Meet existentă se încarcă, dacă Prosody și Jicofo rulează și dacă un apel de test se finalizează prin bridge-ul curent. Înregistrați versiunile pachetului Jitsi. O semnalizare sau o configurare de certificat defectă pe serverul principal va face ca un bridge nou să pară configurat greșit, chiar și atunci când rețeaua sa este solidă.
La o instalare de pachete Debian/Ubuntu, inspectați serviciile systemctl status prosody jicofo jitsi-videobridge2și revizuiți jurnalele de servicii. Folosiți numele serviciilor prezente în instalarea dvs.; implementările containerizate expun comenzi și locații diferite ale jurnalelor.
Atribuiți fiecărei bridge propria adresă publică sau o mapare NAT unu-la-unu configurată corect. Ghidul de configurare scalabilă listează aceste căi tipice: clienții publici ajung la gazda web pe TCP 80/443; serverele JVB ajung la Prosody pe TCP 5222; iar clienții ajung la fiecare Videobridge pe UDP 10000 pentru media. TCP 80 este în general utilizat pentru configurarea certificatului sau a redirecționării, în timp ce un site Meet de producție ar trebui să utilizeze HTTPS.
Depinde de rețeaua dvs.: NAT, grupurile de securitate în cloud, IPv6, TURN și rețelele corporative restrictive pot necesita candidați sau căi suplimentare. Lista de porturi implicită nu este o dovadă că mediul funcționează prin firewall-ul dvs. specific. Acțiune: Verificați fluxul de pachete către fiecare adresă publică de bridge dintr-o rețea client externă și testați un apel real; o conexiune XMPP reușită nu verifică mediul UDP.
Folosește depozitul Jitsi și instrucțiunile pachetului care corespund distribuției gazdei Meet. Pe fiecare nod Debian/Ubuntu nou, instalează jitsi-videobridge2și răspunde la solicitările de configurare a pachetului cu numele gazdei Meet, conform instrucțiunilor din configurația scalabilă oficială. Manualul precizează că, pentru configurarea documentată bazată pe pachete, bridge-ul nu necesită modificări suplimentare în afară de configurația implicită după instalare.
Nu instalați un al doilea stack Jitsi Meet complet pe fiecare bridge, decât dacă doriți intenționat implementări Meet independente. Pentru un pool de bridge, păstrați rolurile web, Prosody și Jicofo pe gazda principală și adăugați servicii JVB pe celelalte mașini. Folosiți aceeași versiune JVB acceptată în pool; implementați upgrade-uri astfel încât să nu lăsați un pool cu versiuni mixte mai mult decât este necesar.
În configurarea bazată pe pachete, permiteți mai întâi configurației oficiale a pachetului să genereze setările așteptate. JVB-urile trebuie să se conecteze la Prosody și să anunțe prezența punții către același MUC al fabricii de bere pe care îl monitorizează Jicofo. Dacă utilizați calea de configurare curentă pentru clientul XMPP, documentația JVB arată părțile relevante de sub videobridge.statsși videobridge.apis.xmpp-client.configs; Jicofo trebuie să se alăture fabricii de bere corespunzătoare folosind jicofo.bridge.brewery-jid.
O configurație modernă tipică are această formă; înlocuiți toate valorile exemplu cu valori din instalarea dvs. și protejați secretul partajat:
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"
}
}
}
}
}Folosiți un porecla diferit muc_nicknamepentru fiecare punte (de exemplu, bridge-02și bridge-03). Proiectul JVB avertizează că poreclele trebuie să fie unice în toate instanțele. Numele exact al fișierului de configurare și necesitatea acestui bloc explicit depind de pachetul dvs. și de configurația existentă; evitați suprapunerea unei configurații moderne scrise de mână peste setările pachetului moștenit generate fără a verifica documentația versiunii instalate.
Reporniți sau porniți JVB pe fiecare gazdă nouă, apoi verificați dacă rămâne activ și se conectează la Prosody. Ghidul de configurare scalabilă recomandă verificarea jurnalelor Prosody și Jicofo pentru a confirma conexiunile bridge și dacă Jicofo descoperă bridge-urile. Dacă nu apare niciuna, verificați în această ordine: rezoluția DNS și accesibilitatea TCP 5222; acreditările și domeniul XMPP; ortografia exactă a MUC-ului brewery; poreclă duplicată; apoi compatibilitatea versiunilor JVB/Jicofo.
Începeți mai multe întâlniri de testare noi și confirmați că Jicofo le plasează în pool-ul disponibil în timp. Se așteaptă o întâlnire care ajunge pe un singur bridge; aceasta nu arată că echilibrarea a eșuat. Folosiți interfața de depanare Jicofo, dacă este activată și cu acces restricționat, pentru a inspecta bridge-urile disponibile și conferințele active. Documentația JVB oferă curl http://localhost:8888/debugca exemplu de depanare locală; interfețe de diagnosticare bind sau firewall, astfel încât acestea să rămână private.
Testați cu clienți din afara rețelei serverului. Confirmați că sunetul și video funcționează, apoi inspectați adresa bridge-ului selectat și fluxul UDP. Dacă un bridge apare în Jicofo, dar apelurile eșuează doar atunci când este selectat acel bridge, investigați adresa sa publică, maparea NAT, firewall-ul UDP și candidații anunțați. Mențineți un bridge în afara rotației în timpul întreținerii doar printr-o procedură de drenaj sau implementare acceptată pentru versiunea instalată; repornirea unui bridge activ poate întrerupe întâlnirile care îi sunt atribuite.
Octo este subiectul potrivit atunci când o singură conferință trebuie să utilizeze mai multe punți, adesea deoarece participanții sunt răspândiți în diferite regiuni. Nu este o condiție prealabilă pentru adăugarea de JVB-uri pentru capacitate obișnuită. Documentația actuală a retransmiterilor JVB necesită configurarea retransmiterilor pe fiecare punte participantă, Colibri WebSockets pentru conexiuni bridge-to-bridge și o strategie adecvată de selectare a punții Jicofo. Comportamentul în funcție de regiune depinde și de furnizarea de informații precise despre regiunea clientului către configurația Meet deservită.
O configurație de retransmisie include un parametru unic relay-idși o regiune pentru fiecare punte, în timp ce Jicofo activează Octo și selectează o strategie precum RegionBasedBridgeSelectionStrategy. Punctele finale Relay WebSocket trebuie, de asemenea, rutate corect prin orice proxy. Aceste setări se schimbă în funcție de versiuni și topologii, așadar urmați ghidul actual de retransmisie și validați căile exacte de proxy înainte de implementare.
Acțiune: Lăsați Octo dezactivat pentru un pool de bridge-uri simplu cu o singură regiune. Dacă aveți o cerință pentru mai multe regiuni, testați cu strategia de divizare documentată într-un mediu de testare, inspectați selectorul de bridge și starea conferinței Jicofo, apoi configurați regiunile clientului și selecția bazată pe regiuni. Nu setați etichete de regiune până când nu știți cum vor primi clienții metadatele regiunii corespunzătoare.
Dacă utilizatorii raportează probleme doar la un singur JVB, comparați calea de rețea și configurația acelui nod cu un peer funcțional înainte de a mări întregul cluster. Dacă toate punțile se degradează împreună, blocajul poate fi lățimea de bandă partajată, serviciile de semnalizare principale sau rețeaua participanților. Scalarea funcționează atunci când noile punți sunt accesibile independent, înregistrate corect și reduc măsurabil sarcina în timpul testelor realiste.
Comparați 10 instrumente de scanare ping pentru descoperirea rapidă a rețelelor LAN, scanarea multi-platformă și gestionarea adreselor IP. Aflați ce vă poate spune o scanare (sweep).
Comparați șase instrumente de gestionare a rețelei pentru monitorizarea performanței, inclusiv acoperirea SNMP, maparea, alertele, modelele de implementare și compromisurile de costuri.
Aflați ce înseamnă QoS în rețele, cum marcajele DSCP și cozile de trafic prioritizează aplicațiile vocale, video și de business și ce nu poate remedia QoS.
Compară software-ul de server SFTP fiabil pentru Windows și Linux, inclusiv OpenSSH, Bitvise, SolarWinds și SFTPGo. Găsește soluția potrivită pentru nevoile tale de securitate și transfer de fișiere.
Construiți o monitorizare practică a rețelei cu o acoperire clară a dispozitivelor, indicatori de performanță utili, alerte acționabile și o comparație între SolarWinds NPM, PRTG și OpManager.
Comparați șapte instrumente de gestionare a adreselor IP pentru descoperirea subrețelelor, coordonarea DNS și DHCP, inventarul rețelei și IPAM open-source.
Comparați instrumentele de scanare a rețelei pentru descoperirea rapidă a dispozitivelor, scanări IP pe mai multe platforme și IPAM pentru întreprinderi, cu îndrumări privind potrivirea fiecărei opțiuni la rețeaua dvs.
Folosește opțiunea --traceroute din Nmap pentru a mapa salturi la o gazdă autorizată, a înțelege ieșirea saltului și a RTT-ului și a depana răspunsurile lipsă fără a suprascana.
Comparați șase instrumente de monitorizare Windows Server în funcție de colectarea datelor Windows, vizibilitatea aplicațiilor, modelul de implementare și licențierea pentru a găsi instrumentul potrivit.
Comparați șase instrumente de monitorizare a rețelei Linux pentru descoperirea dispozitivelor SNMP, grafice de interfață, metrici gazdă, verificări de servicii și fluxuri de trafic.
