L'ajout de serveurs Jitsi Videobridge (JVB) est la méthode habituelle pour augmenter la capacité multimédia d'un déploiement Jitsi Meet. Conservez les services web, Prosody et Jicofo sur le serveur Meet existant, puis ajoutez des machines de pont indépendantes qui s'enregistrent auprès de la même salle de découverte de pont Prosody. Jicofo peut alors placer les nouvelles conférences sur un pont disponible. Dans cette configuration de base, les participants à une conférence utilisent un pont sélectionné ; l'utilisation d'Octo n'est pas nécessaire du seul fait que le déploiement comporte plusieurs serveurs JVB.
Ce guide suit la configuration évolutive basée sur les paquets Debian/Ubuntu décrite dans le manuel Jitsi (version du 6 octobre 2026). Les dépendances exactes et la configuration générée peuvent varier selon la distribution, la version de Jitsi et la méthode d'installation du serveur (Docker ou autre). Veuillez consulter le guide d'installation officiel correspondant à votre déploiement.
Vérifié : Une seule installation de Jitsi Meet peut utiliser plusieurs ponts vidéo. Jicofo supervise ces ponts et leur attribue une nouvelle conférence. L’exemple simplifié du manuel Jitsi place les services Meet sur un serveur et trois ponts vidéo (JVB) sur des serveurs distincts. Chaque pont doit être accessible aux participants pour la diffusion multimédia et à l’infrastructure Meet pour la signalisation.
Idée reçue : « Il me faut un équilibreur de charge devant les JVB. » Dans l’architecture multi-ponts documentée, Jicofo sélectionne un pont ; les clients y envoient ensuite leurs flux multimédias. Un équilibreur de charge HTTP générique devant les flux UDP ne remplace ni la découverte des ponts ni le placement des conférences. Action : Ajoutez chaque JVB au pool de ponts Prosody/Jicofo et publiez son adresse IP accessible pour les flux multimédias. Ne redirigez pas le trafic multimédia de chaque pont vers une adresse IP virtuelle UDP unique.
Idée reçue : « Plus il y a de ponts, plus une réunion s’étend automatiquement sur tous les serveurs. » Dans sa configuration de base, Jicofo attribue une conférence à un pont. La répartition des participants d’une même conférence entre différentes régions ou ponts repose sur une topologie de relais distincte appelée Octo (relais sécurisés dans la documentation JVB actuelle). Recommandation : Commencez par un pool de ponts classique si votre objectif est d’organiser davantage de réunions simultanées ; n’envisagez Octo que si une conférence doit utiliser des ponts situés à plusieurs endroits ou si vous avez besoin de ce comportement de relais.
Choisissez un nom d'hôte ou une adresse publique et stable pour chaque JVB. Attribuez à chaque machine virtuelle une identité de système d'exploitation unique et un surnom d'instance JVB unique lorsque la configuration utilise la présence XMPP MUC. Tous les ponts doivent pouvoir accéder au même service Prosody et à la même salle de brassage. Assurez-vous que les versions soient compatibles : Jicofo n'autorise pas l'utilisation de ponts de versions différentes au sein d'une même conférence, et la documentation actuelle du relais reprend cette contrainte pour Octo.
| Chemin | Utilisez-le lorsque | Ce que cela ajoute |
|---|---|---|
| Plusieurs JVB, une région | Vous avez besoin de plus de capacité pour des réunions simultanées distinctes. | Installation, enregistrement, accès au réseau et validation du pont. |
| Octo relais à travers les régions | Une conférence nécessite des participants ou des relais médiatiques dans plus d'une région. | Paramètres d'identité et de région du relais, connectivité WebSocket Colibri, stratégie Jicofo et informations de région client correctes. |
Cela dépend de votre environnement : il n’existe pas de nombre universel de participants par machine virtuelle. La documentation de Jitsi relative aux exigences met l’accent sur la capacité du réseau et la charge de travail plutôt que sur une valeur fixe. Le codec, la résolution, la diffusion simultanée, le débit de paquets, les conférences simultanées et la bande passante du fournisseur ont tous une incidence sur la capacité. Action : établissez une base de référence pour votre charge de travail réelle, puis ajoutez un pont à la fois et observez l’utilisation du processeur, le débit du réseau, la perte de paquets et la qualité des conférences.
Avant d'ajouter des machines, vérifiez que la page Meet existante se charge correctement, que Prosody et Jicofo sont en cours d'exécution et qu'un appel test aboutit via le pont actuel. Notez les versions des paquets Jitsi. Un problème de signalisation ou de configuration de certificat sur le serveur principal peut faire apparaître un nouveau pont comme mal configuré, même si son réseau fonctionne correctement.
Sur une installation de paquets Debian/Ubuntu, inspectez les services systemctl status prosody jicofo jitsi-videobridge2et consultez leurs journaux. Utilisez les noms de service présents sur votre installation ; les déploiements conteneurisés utilisent des commandes et des emplacements de journaux différents.
Attribuez à chaque pont sa propre adresse publique ou une configuration NAT un-à-un correcte. Le guide d'installation évolutive décrit les chemins typiques suivants : les clients publics accèdent au serveur web via TCP 80/443 ; les serveurs JVB accèdent à Prosody via TCP 5222 ; et les clients accèdent à chaque pont vidéo via UDP 10000 pour la diffusion multimédia. Le port TCP 80 est généralement utilisé pour la configuration des certificats ou des redirections, tandis qu'un site Meet en production doit utiliser HTTPS.
Cela dépend de votre réseau : NAT, groupes de sécurité cloud, IPv6, TURN et réseaux d'entreprise restrictifs peuvent nécessiter des ports ou des chemins supplémentaires. La liste des ports par défaut ne garantit pas le bon fonctionnement des flux multimédias à travers votre pare-feu. Action : vérifiez le flux de paquets vers chaque adresse de pont publique depuis un réseau client externe et effectuez un test d'appel ; une connexion XMPP réussie ne suffit pas à garantir le bon fonctionnement des flux multimédias UDP.
Utilisez le dépôt Jitsi et suivez les instructions d'installation des paquets correspondant à la distribution de l'hôte Meet. Sur chaque nouveau nœud Debian/Ubuntu, installez jitsi-videobridge2le paquet et répondez aux invites de configuration en indiquant le nom d'hôte Meet, conformément aux instructions de la configuration évolutive officielle. Le manuel précise que, pour sa configuration documentée basée sur les paquets, le pont ne nécessite aucune modification supplémentaire après l'installation.
N'installez pas une seconde instance complète de Jitsi Meet sur chaque pont, sauf si vous souhaitez des déploiements Meet indépendants. Pour un pool de ponts, conservez les rôles web, Prosody et Jicofo sur l'hôte principal et ajoutez les services JVB aux autres machines. Utilisez la même version de JVB prise en charge pour l'ensemble du pool ; effectuez les mises à niveau progressivement afin de ne pas maintenir un pool avec des versions différentes plus longtemps que nécessaire.
Dans une configuration basée sur un package, commencez par laisser la configuration officielle du package générer les paramètres attendus. Les JVB doivent se connecter à Prosody et annoncer leur présence sur le même serveur MUC de la même brasserie que celui surveillé par Jicofo. Si vous utilisez le chemin de configuration actuel du client XMPP, la documentation JVB indique les éléments pertinents sous [référence manquante] videobridge.statset videobridge.apis.xmpp-client.configs[référence manquante]. Jicofo doit rejoindre la brasserie correspondante à l'aide de [ méthode manquante jicofo.bridge.brewery-jid].
Voici une configuration moderne typique ; remplacez toutes les valeurs d’exemple par celles de votre installation et protégez le secret partagé :
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"
}
}
}
}
}Utilisez un nom différent muc_nicknamepour chaque pont (par exemple, `bridge` bridge-02et ` bridge-03bridge`). Le projet JVB recommande que les noms soient uniques pour chaque instance. Le nom exact du fichier de configuration et la nécessité de ce bloc explicite dépendent de votre paquet et de votre configuration existante ; évitez de superposer une configuration moderne personnalisée aux paramètres générés par un paquet hérité sans consulter la documentation de la version installée.
Redémarrez ou lancez JVB sur chaque nouvel hôte, puis vérifiez qu'il reste actif et connecté à Prosody. Le guide d'installation évolutif recommande de consulter les journaux de Prosody et de Jicofo pour confirmer les connexions de pont et la détection des ponts par Jicofo. Si un pont n'apparaît pas, vérifiez dans cet ordre : la résolution DNS et l'accessibilité du port TCP 5222 ; les identifiants XMPP et le domaine ; l'orthographe exacte du nom de domaine MUC de la brasserie ; l'absence de doublons sur le pseudonyme ; puis la compatibilité des versions de JVB et de Jicofo.
Lancez plusieurs nouvelles réunions de test et vérifiez que Jicofo les répartit correctement sur le pool de connexions disponible. Il est normal qu'une réunion soit attribuée à un seul pont ; cela n'indique pas un échec d'équilibrage. Utilisez l'interface de débogage de Jicofo, si elle est activée et que son accès est restreint, pour examiner les ponts disponibles et les conférences actives. La documentation JVB fournit curl http://localhost:8888/debugun exemple de débogage local ; bloquez les interfaces de diagnostic (pare-feu, etc.) pour garantir leur confidentialité.
Testez avec des clients hors du réseau du serveur. Vérifiez que l'audio et la vidéo fonctionnent, puis examinez l'adresse du pont sélectionné et le flux UDP. Si un pont apparaît dans Jicofo mais que les appels échouent uniquement lorsque ce pont est sélectionné, vérifiez son adresse publique, sa configuration NAT, son pare-feu UDP et les candidats annoncés. Mettez un pont hors service pendant la maintenance uniquement via une procédure de vidage ou de déploiement prise en charge pour votre version installée ; le redémarrage d'un pont actif peut interrompre les réunions qui lui sont assignées.
Octo est la solution idéale lorsqu'une conférence unique doit utiliser plusieurs ponts, souvent parce que les participants sont répartis sur plusieurs régions. Son utilisation n'est pas indispensable pour ajouter des JVB afin d'assurer une capacité standard. La documentation actuelle sur les relais JVB exige une configuration de relais sur chaque pont participant, l'utilisation de WebSockets Colibri pour les connexions entre ponts et une stratégie de sélection de pont Jicofo appropriée. La prise en compte des régions dépend également de la fourniture d'informations précises sur la région du client à la configuration Meet.
La configuration d'un relais inclut un identifiant unique relay-idet une région pour chaque pont. Jicofo active Octo et sélectionne une stratégie RegionBasedBridgeSelectionStrategy. Les points de terminaison WebSocket du relais doivent également être correctement acheminés via un proxy. Ces paramètres varient selon les versions et les topologies ; il est donc important de suivre le guide de relais actuel et de valider les chemins de proxy exacts avant le déploiement.
Action : Laissez Octo désactivé pour un pool de ponts monorégional simple. Si votre environnement comporte plusieurs régions, effectuez un test avec la stratégie de répartition documentée dans un environnement de test, examinez le sélecteur de ponts et l’état de la conférence de Jicofo, puis configurez les régions clientes et la sélection par région. Ne définissez pas les étiquettes de région tant que vous ne savez pas comment les clients recevront les métadonnées de région correspondantes.
Si des utilisateurs signalent des problèmes sur un seul JVB, comparez le chemin réseau et la configuration de ce nœud avec un homologue fonctionnel avant d'étendre le cluster. Si tous les ponts se dégradent simultanément, le goulot d'étranglement peut provenir de la bande passante partagée, des services de signalisation principaux ou du réseau des participants. La mise à l'échelle fonctionne correctement lorsque les nouveaux ponts sont accessibles indépendamment, correctement enregistrés et réduisent sensiblement la charge lors de tests réalistes.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
