Visioconférence sur VPS : calculer la bande passante

La visioconférence auto-hébergée sur un VPS est un problème de bande passante

La visioconférence auto-hébergée échoue sur les petits serveurs pour une seule raison, qui n’est presque jamais l’installation. Le composant serveur utilisé par tous les outils modernes est un SFU (selective forwarding unit). Il reçoit un flux vidéo de chaque participant et en transmet une copie à tous les autres participants. Le trafic sortant du serveur augmente donc avec le carré du nombre de participants. Un VPS de 1 GB ou 2 GB sur une liaison partagée exécutera correctement le logiciel. En revanche, il ne pourra pas prendre en charge la réunion générale que vous envisagez.

Procédez donc dans cet ordre. Comptez les participants, calculez le débit en mégabits, puis choisissez le serveur. L’installation prend vingt minutes de copier-coller. C’est la liaison montante qui détermine si les autres peuvent vous entendre.

Pourquoi la bande passante augmente-t-elle avec le carré du nombre de participants ?

Commencez par le mesh. Chaque navigateur encode sa caméra et envoie directement une copie à chacun des autres navigateurs. Aucun media server ne traite la vidéo. Un appel mesh à deux personnes nécessite un serveur de signalisation, et rien d’autre. C’est pourquoi les appels individuels coûtent presque rien à héberger. Le mesh cesse de fonctionner vers quatre ou cinq personnes, car un ordinateur portable connecté à une connexion domestique doit envoyer simultanément quatre ou cinq copies distinctes de sa propre vidéo.

Un SFU fonctionne autrement. Chaque navigateur envoie une copie au serveur. Le serveur lit les en-têtes RTP (real-time transport protocol) et transfère les paquets aux autres participants sans décoder la vidéo. C’est tout le principe. C’est pourquoi un SFU consomme peu de CPU, mais beaucoup de réseau.

L’ancienne architecture est un MCU (multipoint control unit). Il décode chaque flux entrant, les compose en une seule image, puis réencode cette image. La bande passante sortante est faible. Le coût CPU est énorme. Presque aucun système n’utilise encore un MCU pour la vidéo, et ce guide non plus.

Voici maintenant le calcul pour un SFU. Supposons que chaque personne envoie de la vidéo à 1.2 Mbps et que personne n’éteigne sa caméra. Le serveur reçoit N fois 1.2 Mbps. Cette valeur est linéaire et sans difficulté. Le serveur envoie N fois (N moins 1) fois 1.2 Mbps, car chacune des N personnes doit recevoir les N moins 1 flux des autres participants. C’est cette seconde valeur qui met fin aux projets.

[
  {
    "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
  }
]

Ces lignes correspondent à des calculs, et non aux mesures d’un serveur particulier. La colonne mensuelle suppose vingt heures d’appels par mois. Commencez par lire la dernière ligne. Cinquante personnes avec la caméra activée nécessitent 2,940 Mbps de trafic sortant soutenu depuis une seule machine. Trente personnes nécessitent 1,044 Mbps. Quatre personnes nécessitent 14.4 Mbps, ce que n’importe quel VPS gère sans difficulté. Entre la ligne de quatre personnes et celle de trente personnes, le nombre de participants est multiplié par sept et demi, tandis que le trafic sortant est multiplié par plus de soixante-dix.

Les déploiements réels restent en dessous de ces valeurs. Il est utile de savoir précisément pourquoi. Jitsi et LiveKit utilisent tous deux le simulcast : un émetteur publie simultanément plusieurs couches de qualité, et le SFU transmet une couche basse aux personnes qui ne sont pas à l’écran. Jitsi dispose également d’un paramètre last-N qui ne transmet la vidéo que pour les intervenants les plus récents. Ces deux mécanismes réduisent fortement le trafic. Aucun ne modifie la forme de la courbe. Tous deux cessent d’être utiles dès que tout le monde active sa caméra et épingle la vidéo des autres participants.

Que vous apporte réellement la liaison montante d’un VPS ?

Une page tarifaire indique « port 1 Gbps ». Il s’agit de la vitesse de la carte réseau virtuelle, et non d’une garantie concernant le prochain saut réseau. La liaison est partagée avec les autres locataires du même hôte physique. Le débit soutenu pendant une période chargée est donc inférieur à la vitesse du port, et une visioconférence représente précisément une charge soutenue. La plupart des offres incluent également un quota mensuel de transfert. Au-delà de ce quota, le débit est limité ou des frais sont facturés.

C’est ce quota qui peut faire apparaître un montant inattendu sur la facture. Vingt heures de l’appel à trente personnes au cours d’un mois transfèrent 9.4 TB depuis le serveur, à raison de 469.8 GB par heure. Vingt heures de l’appel à cinquante personnes transfèrent 26.5 TB. Vérifiez le quota de transfert avant la quantité de RAM. Si la page de l’offre reste vague à ce sujet, cette imprécision constitue déjà une réponse. Bien lire une offre de VPS bon marché est plus important pour cette charge de travail que pour presque toute autre.

Jitsi Meet : le choix par défaut et ses prérequis

Jitsi Meet est la solution avec laquelle la plupart des utilisateurs devraient commencer. Le logiciel s’installe depuis le dépôt Debian du projet, configure nginx et un certificat pendant l’installation, et le videobridge (JVB) utilise un seul port UDP, ce qui limite le nombre de règles du pare-feu. Il nécessite Debian 11 ou une version ultérieure, ou Ubuntu 22.04 ou une version ultérieure.

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

L’installateur demande un nom d’hôte, puis propose de choisir un certificat. Sélectionnez l’option Let's Encrypt et indiquez un nom de domaine qui résout déjà vers l’adresse publique de ce serveur. Le certificat est délivré au moyen d’un challenge HTTP. Si le nom pointe ailleurs, cette étape échoue.

Ouvrez ensuite les ports. Ce sont ceux documentés dans le manuel, avec SSH en premier pour éviter que ufw enable ne vous bloque l’accès :

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 et 443 servent l’application web et permettent le renouvellement du certificat. UDP 10000 transporte tout l’audio et la vidéo. C’est le port souvent oublié. UDP 3478 et TCP 5349 sont utilisés par le serveur coturn que le paquet Jitsi installe avec le bridge. Ils fournissent une solution de repli pour les utilisateurs dont le réseau bloque UDP.

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

La première commande doit indiquer que le service est actif. La seconde doit afficher que le bridge écoute sur UDP 10000. Si elle n’affiche rien, le bridge n’a pas démarré et /var/log/jitsi/jvb.log indiquera pourquoi.

Pour le dimensionnement, le manuel de Jitsi publie sa propre configuration de départ, tandis que BigBlueButton en publie une beaucoup plus importante :

[
  {
    "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
  }
]

Le manuel de Jitsi recommande 8 Go de RAM et 4 cœurs dédiés pour un serveur sérieux. Une connexion réseau de 1,000 Mbps suffit souvent. Il précise aussi que des installations plus petites fonctionnent avec 4 Go ou 2 Go. Un détail de cette page mérite d’être retenu : Prosody, le serveur XMPP qui gère la signalisation, ne peut utiliser qu’un seul cœur. Les cœurs supplémentaires servent au bridge, mais n’apportent rien à la signalisation.

Pourquoi tout le monde rejoint-il la réunion, mais personne ne voit la vidéo ?

C’est le problème classique de Jitsi sur un VPS. La liste des participants se remplit, le chat fonctionne et toutes les vignettes vidéo restent noires. Le videobridge annonce les adresses qu’il trouve sur ses propres interfaces. Chez un fournisseur qui attribue une adresse privée à la machine virtuelle et lui associe une adresse publique, JVB ne trouve que l’adresse privée. Chaque client essaie donc d’envoyer les flux multimédias vers une adresse comme 10.0.0.5, et les paquets n’aboutissent pas.

Indiquez les deux adresses au bridge. Ajoutez une correspondance statique dans /etc/jitsi/videobridge/jvb.conf :

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

Redémarrez avec sudo systemctl restart jitsi-videobridge2. Récupérez l’adresse locale avec ip -4 addr show et l’adresse publique dans le panneau de contrôle de votre fournisseur. Les anciennes procédures définissent le même paramètre dans /etc/jitsi/videobridge/sip-communicator.properties avec les clés org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS et org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS. Ces paramètres fonctionnent toujours, mais les nouvelles installations doivent utiliser le bloc de correspondance ci-dessus.

L’autre cause possible est un pare-feu que vous n’avez pas configuré. La plupart des fournisseurs proposent dans leur panneau de contrôle un pare-feu réseau distinct de ufw sur la machine. Le port UDP 10000 doit être ouvert dans les deux pare-feu. Pour déterminer quelle couche bloque les paquets, exécutez sudo tcpdump -ni any udp port 10000 sur le serveur pendant qu’une personne rejoint la réunion depuis l’extérieur. Si aucun paquet n’arrive, la machine n’est pas atteinte : le blocage se situe en amont du système d’exploitation. Si des paquets arrivent alors que les vignettes restent noires, le bridge répond avec une adresse inaccessible au client : le problème vient de la correspondance. Si vous avez un doute sur ufw, les règles ufw réellement nécessaires sur un VPS explique l’ordre des règles qui pose souvent problème.

BigBlueButton : lourd, très directif, et conçu pour utiliser tout le serveur

BigBlueButton est conçu pour l’enseignement. Il intègre un tableau blanc, des salles de répartition, des sondages et un espace de présentation. Son pipeline d’enregistrement est une fonction native, et non un module complémentaire. C’est aussi de loin l’option la plus lourde ici. Ce n’est pas un paquet que vous ajoutez à un serveur existant.

En août 2026, le chemin pris en charge est BigBlueButton 3.0 sur Ubuntu 22.04, sélectionné avec l’indicateur de version jammy-300. Les exigences de production indiquées par le projet sont 16 Go de mémoire avec le swap activé, 8 cœurs CPU avec de bonnes performances mono-thread, 250 Mbit/s de bande passante symétrique et 500 Go d’espace disque si vous conservez les enregistrements (50 Go si vous les désactivez). Les ports utilisés sont TCP 80 et 443, ainsi que la plage UDP 16384 à 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

Les exemples du projet redirigent directement ce script vers bash. Téléchargez-le et lisez-le d’abord, car il réécrit votre configuration nginx, installe sa propre pile média et audio, verrouille les versions des paquets et s’approprie le nom d’hôte. C’est le fonctionnement prévu, et non un défaut : BigBlueButton s’attend à gérer toute la machine. L’indicateur -w configure le pare-feu, -s définit le nom d’hôte, -e indique l’adresse à laquelle Let’s Encrypt enregistre le certificat, et -g ajoute l’interface frontale Greenlight. Si cette même machine termine aussi les connexions TLS d’autres services, déplacez BigBlueButton sur une autre machine ou assurez-vous de comprendre ce que fait la configuration de votre reverse proxy nginx avant que le script ne la modifie.

Comparez attentivement les deux lignes de ce tableau. BigBlueButton demande deux fois plus de mémoire et deux fois plus de cœurs que les recommandations de Jitsi, tout en demandant un quart de la bande passante. Les deux chiffres ne sont pas mesurés de la même manière et supposent des tailles de salles différentes. Considérez donc chacun comme le point de départ de son propre projet, et non comme une comparaison directe. L’écart au niveau du CPU est réel. Il vient de toutes les opérations effectuées par BigBlueButton en plus de la transmission de la vidéo.

Galène : l’option légère

Galène est un SFU compact écrit en Go. Il se compile en un binaire statique unique, fournit son propre client web et inclut un serveur TURN. Il n’y a donc pas de serveur XMPP, de runtime Java ou d’application Rails à maintenir en fonctionnement. Si vous avez besoin d’un appel fiable à dix personnes sur une machine modeste, essayez cette solution avant de conclure qu’il vous faut davantage de matériel.

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

Le paquet golang-go sur Ubuntu 24.04 fournit Go 1.22. Si go build indique que le module nécessite une version plus récente de Go, installez une toolchain actuelle depuis go.dev au lieu de vous battre avec le paquet de la distribution.

Un groupe est le terme utilisé par Galène pour désigner une salle. Il s’agit d’un fichier JSON :

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

Ouvrez https://your.server:8443/group/night-watch/ et connectez-vous avec vimes. Ces identifiants proviennent directement du README du projet. Modifiez-les avant que le port soit accessible depuis un autre réseau. Pour un déploiement réel, le projet documente une 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

Les ports sont TCP 8443 pour l’interface web, TCP et UDP 1194 pour le serveur TURN intégré, ainsi qu’une plage de ports UDP élevés pour les médias. Fixez cette plage afin de pouvoir écrire une seule règle de pare-feu :

./galene -udp-range 40000-40100

L’option -turn est celle qui compte sur un VPS. -turn ':1194' écoute sur toutes les adresses IPv4 publiques. -turn '203.0.113.1:1194' indique à Galène l’adresse que les clients verront réellement. C’est nécessaire lorsque l’adresse de la machine est privée. -turn '' désactive le serveur intégré afin que vous puissiez utiliser un serveur externe avec data/ice-servers.json. La valeur par défaut est auto, qui se comporte comme :1194 lorsqu’aucun ice-servers.json n’existe.

Vous pouvez placer nginx devant l’interface web en définissant proxyURL dans data/config.json, puis en proxyfiant l’emplacement /ws avec les en-têtes de mise à niveau WebSocket. Sachez ce que cela couvre : les clients ouvrent toujours des flux UDP directs et des connexions TCP directes vers le port TURN. Le reverse proxy ne gère donc que la page et la signalisation. Les médias ne le traversent jamais.

La documentation de Galène indique que le logiciel nécessite des ressources serveur très modérées, sans publier de chiffre précis. N’en attendez donc pas un. Les calculs de bande passante présentés plus haut restent entièrement valables. Vous économisez la mémoire et les composants de tout ce qui n’est pas le SFU.

Owncast : diffusion d’une source vers plusieurs spectateurs, avec une consommation de bande passante linéaire

De nombreux besoins de « visioconférence » correspondent en réalité à une personne qui présente un contenu à un public échangeant dans un chat. Si c’est votre cas, un SFU est le mauvais outil et le modèle économique est complètement différent. Owncast reçoit un flux RTMP depuis OBS ou un encodeur similaire, puis diffuse du HLS sur HTTPS standard. La bande passante par spectateur évolue de manière linéaire, et comme la sortie se compose de segments HTTP classiques, vous pouvez la placer derrière un stockage objet ou un CDN et ne plus la faire transiter par le serveur d’origine.

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

La documentation du projet indique de ne pas exécuter ce service en tant que root et d’examiner tout script distant avant de l’exécuter. C’est pourquoi le téléchargement constitue une étape distincte ci-dessus. L’installateur récupère la version actuelle ainsi qu’un binaire ffmpeg si vous n’en avez pas déjà un. Exécutez ./owncast depuis le répertoire d’installation, puis ouvrez le panneau d’administration à /admin sur le port 8080. L’identifiant par défaut est l’utilisateur admin, et la clé de stream par défaut abc123 sert de mot de passe. Modifiez-la avant de faire pointer un domaine vers le serveur.

La conception HLS entraîne deux conséquences. Les spectateurs ont quelques secondes ou quelques minutes de retard sur le direct, car HLS diffuse des segments entiers. Il n’y a donc pas de conversation interactive. Par ailleurs, UDP et TURN n’interviennent jamais dans le chemin réseau. Le flux peut ainsi atteindre des réseaux auxquels un appel WebRTC ne peut pas se connecter.

Owncast est également le seul outil présenté ici qui transcode volontairement le flux. Chaque qualité de sortie activée correspond à un encodage ffmpeg supplémentaire du flux entrant, exécuté pendant toute la durée de la diffusion. Sur un petit VPS, proposez une ou deux qualités. Cinq qualités satureront le CPU alors que le réseau restera inutilisé.

Element Call sur un serveur Matrix que vous exploitez déjà

Si vous exploitez déjà Matrix, la vidéo s’ajoute à l’existant au lieu de nécessiter un deuxième produit à administrer. Il ne s’agit toutefois pas d’un seul package. Element Call a besoin de deux services derrière votre homeserver. Le premier est un SFU LiveKit, qui assure le relais des flux multimédias. Le second est le service d’autorisation MatrixRTC, element-hq/lk-jwt-service, qui fournit au client l’URL WebSocket LiveKit et un JWT signé (JSON web token) pour s’y connecter. Ce service utilise l’API de fédération Matrix. Il doit donc être placé derrière un reverse proxy TLS et disposer d’un nom que la fédération peut atteindre.

Ports documentés de LiveKit :

• TCP 7880 pour l’API et le WebSocket client, derrière un proxy qui termine TLS
• TCP 7881 pour ICE sur TCP, utilisé lorsqu’un client ne peut pas sortir par UDP
• UDP 50000 à 60000 pour les flux multimédias, chaque participant d’une salle utilisant deux ports
• UDP 3478 et TCP 5349 si vous activez le serveur TURN intégré ; le port 5349 doit être déplacé vers 443, sauf si un load balancer est placé devant

Deux ports par participant peuvent sembler inquiétants, mais ce n’est pas un problème. Une plage de 10,000 ports couvre des milliers de participants, et votre liaison montante arrive à saturation bien avant la plage. Ouvrez tout de même la plage complète : une plage partiellement ouverte échoue pour certains utilisateurs et fonctionne pour d’autres, ce qui est le type de panne le plus difficile à diagnostiquer. La partie concernant le homeserver constitue une tâche distincte, décrite dans exploiter un homeserver Synapse sur un VPS.

Pourquoi une seule personne ne peut-elle jamais se connecter ? TURN et les réseaux qui bloquent l’UDP

Commençons par quelques termes, utilisés une seule fois chacun. ICE (interactive connectivity establishment) est le processus utilisé par deux endpoints WebRTC pour trouver un chemin fonctionnel entre eux. STUN (session traversal utilities for NAT) est un petit service qui indique à un client à quoi ressemble sa propre adresse publique depuis l’extérieur. TURN (traversal using relays around NAT) est un relais : lorsqu’aucun chemin direct n’existe, les deux côtés envoient leurs médias au serveur TURN, qui les transmet.

Vous avez besoin de TURN pour les participants dont vous ne pouvez pas contrôler les réseaux. L’un d’eux peut se trouver sur un réseau d’entreprise ou de campus où l’UDP sortant est entièrement bloqué. Un autre peut être derrière un NAT de niveau opérateur qui attribue un port source différent pour chaque destination. On parle alors de NAT symétrique, ce qui rend inutilisable l’adresse indiquée par STUN.

Le symptôme est caractéristique. La plupart des personnes rejoignent la session et tout fonctionne. Une personne voit la liste des participants et le chat, mais affiche une tuile noire avec un indicateur de chargement. Son navigateur a recueilli des candidates, mais aucune paire n’a fonctionné et ICE s’est terminé dans un état d’échec. Dans Chrome, chrome://webrtc-internals ouverte pendant la tentative affiche les paires de candidates et cet échec. Demandez à cette personne de réessayer depuis un téléphone utilisant les données mobiles. Si cela fonctionne, son réseau est à l’origine du problème et TURN est la solution.

TURN sur TCP via 443 ou 5349 est le mécanisme de repli qui fonctionne presque partout, car un réseau qui bloque TLS sur 443 bloque aussi le Web. Le paquet Jitsi installe et configure coturn automatiquement. C’est pourquoi ses règles de pare-feu documentées incluent l’UDP 3478 et le TCP 5349. Galène intègre TURN sur 1194. LiveKit intègre un serveur TURN qu’il suffit d’activer dans la configuration. Si vous exécutez vous-même coturn :

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

Ces paramètres se placent dans /etc/turnserver.conf. Sur Debian et Ubuntu, le paquet démarre coturn dès son installation avec la version standard de ce fichier. Ainsi, enable --now ci-dessus le trouve déjà en cours d’exécution et ne modifie rien. Vos paramètres prennent effet lorsque vous exécutez sudo systemctl restart coturn. Toute modification ultérieure du fichier nécessite le même redémarrage. Les anciennes documentations indiquent également de définir TURNSERVER_ENABLED=1 dans /etc/default/coturn. Seul l’ancien script init lit ce paramètre. L’unité systemd utilisée par les paquets actuels ne le lit pas. Cette ligne ne change donc rien, et un coturn qui n’a jamais été redémarré continue d’utiliser le fichier standard.

Voici maintenant le coût rarement indiqué. Un relais transporte l’intégralité des médias de chaque participant relayé dans les deux directions. Lorsque coturn partage une machine avec le SFU, la majeure partie de ce trafic passe par la loopback et consomme du CPU plutôt que de la bande passante montante. De plus, le listener TLS chiffre chaque paquet une seconde fois, en plus du DTLS déjà utilisé par les médias. Lorsque vous déplacez TURN sur une machine dédiée, cette machine a besoin d’une offre de bande passante dimensionnée comme celle du SFU. TURN sur TCP transforme aussi les médias temps réel en flux fiable. Un paquet perdu est donc retransmis au lieu d’être ignoré. Un participant relayé sur une liaison instable accumule alors du retard au lieu de subir une brève dégradation. Le relais permet de se connecter, mais avec une qualité que le chemin direct aurait dépassée.

Quand le SFU transcode-t-il, et quel en est le coût ?

Un SFU transmet les paquets et ne décode jamais la vidéo. C’est pourquoi quatre cœurs peuvent servir une salle qui semble impossible à gérer sur le papier. Deux fonctionnalités remettent ce principe en cause. Elles surprennent souvent les personnes qui les ont activées en cochant une case.

L’enregistrement est la première. Jitsi enregistre avec Jibri, et la documentation de Jibri décrit précisément son fonctionnement : il lance une instance de Chrome rendue dans un framebuffer virtuel, puis capture et encode la sortie avec ffmpeg. Il s’agit d’un navigateur complet qui restitue l’intégralité de votre réunion, avec un encodeur vidéo, pendant toute la durée de l’appel. La même documentation précise qu’un seul enregistrement à la fois est pris en charge sur un même Jibri et que Jibri doit fonctionner sur une machine ou une machine virtuelle distincte, sans aucune autre application utilisant les périphériques d’affichage ou audio. L’enregistrement nécessite un deuxième serveur, pas une simple case à cocher.

L’accès par téléphone est la seconde. Relier une ligne téléphonique à une conférence consiste à convertir en continu l’Opus à 48 kHz dans les deux sens vers le format accepté par le réseau téléphonique, généralement le G.711 à 8 kHz, pendant toute la durée de l’appel. Le transcodage audio coûte bien moins cher que le transcodage vidéo, mais il s’exécute pour chaque branche d’appel et ne s’interrompt jamais. Le coût augmente donc avec le nombre d’appelants. Si vous voulez un numéro d’accès par téléphone, un serveur VoIP auto-hébergé est le composant qui effectue ce travail. Il doit fonctionner sur sa propre machine, pour la même raison que Jibri.

De quelle taille de serveur avez-vous réellement besoin ?

Pour deux personnes, presque aucune puissance. Jitsi active le mode pair à pair par défaut lorsqu’il y a exactement deux participants. Dans ce mode, la conférence n’envoie plus les données via le videobridge et utilise directement la connexion entre les participants. L’arrivée d’une troisième personne réactive le bridge. Ainsi, un VPS de 1 GB exécutant Jitsi convient très bien aux appels individuels, mais beaucoup moins à quatre personnes. C’est pourquoi « cela fonctionnait quand je l’ai testé » revient si souvent dans les rapports.

Jusqu’à environ dix personnes avec les caméras activées, 67.2 Mbps avec huit participants reste dans les capacités montantes d’un VPS ordinaire. Deux CPU virtuels et 4 GB suffisent pour exécuter Jitsi ou Galène dans cette configuration, à condition de ne pas enregistrer les appels. Surveillez le compteur de transfert plutôt que le graphique du CPU.

Pour trente personnes, le pire cas atteint 1,044 Mbps en continu, et vingt heures correspondent à 9.4 TB. À cette échelle, évaluez le coût de la bande passante avant celui du serveur. Activez last-N afin que le bridge ne relaie que les intervenants récents, désactivez les caméras par défaut pour les participants et placez le SFU chez un fournisseur dont le quota de transfert couvre ce volume.

Au-delà, un seul VPS n’est plus adapté. Soit l’événement est en réalité une diffusion, auquel cas Owncast avec un CDN coûte une fraction de cette configuration, soit vous avez besoin de plusieurs videobridges derrière une même couche de signalisation. Il s’agit alors d’un projet différent de celui que vous aviez commencé.

Un dernier point concerne le routage. La plupart des équipes ont besoin du chat pendant beaucoup plus d’heures dans la journée que de la vidéo. Le chat est peu coûteux à héberger et facile à maintenir. Mettre en place une alternative auto-hébergée à Slack pour les échanges quotidiens et réserver un serveur de conférence aux appels planifiés est l’organisation qui reste viable avec le budget limité d’un petit VPS.

FAQ

Pourquoi les participants peuvent-ils rejoindre ma réunion Jitsi sans se voir ni s’entendre ?

Le chat et la liste des participants passent par le canal de signalisation, qui utilise TCP sur 443, tandis que l’audio et la vidéo utilisent UDP 10000 vers le videobridge. Si la liste des participants se remplit mais que toutes les vignettes restent noires, le chemin média est interrompu alors que le chemin de signalisation fonctionne. Vérifiez UDP 10000 dans les deux firewalls : celui de la machine et le firewall réseau distinct du panneau de contrôle de votre fournisseur. Vérifiez ensuite que le bridge connaît son adresse publique : sur une machine virtuelle avec une adresse privée et une adresse publique mappée, ajoutez un mapping statique sous ice4j.harvest.mapping dans /etc/jitsi/videobridge/jvb.conf, puis redémarrez jitsi-videobridge2. Exécuter sudo tcpdump -ni any udp port 10000 pendant qu’une personne rejoint la réunion indique lequel des deux chemins est en cause, car l’absence totale de paquets signifie que le blocage se situe en amont du système d’exploitation.

Quelle bande passante utilise un appel vidéo à 30 participants ?

Dans le pire des cas, lorsque tout le monde active sa caméra et que le SFU transmet une couche en qualité maximale à chaque participant, environ 1,044 Mbps sortent du serveur, soit 469.8 GB par heure. Il s’agit d’un calcul basé sur N fois (N moins 1) flux à 1.2 Mbps chacun, et non d’une mesure de votre installation. Le simulcast et un réglage last-N réduisent fortement cette valeur en usage normal, car la plupart des participants ne sont pas affichés à un instant donné. Prévoyez malgré tout une capacité proche du pire des cas, car ce cas correspond à une réunion générale où tout le monde active sa caméra en même temps.

Puis-je exécuter Jitsi Meet sur un VPS de 1 GB ?

L’installation fonctionnera, et un appel à deux participants fonctionnera également, notamment parce que Jitsi utilise le mode peer to peer avec exactement deux participants et n’utilise alors pas du tout le videobridge. Ce n’est pas un serveur adapté aux appels de groupe. Prosody, le videobridge et le runtime Java ont tous besoin de mémoire. Le guide recommande lui-même 8 GB pour un déploiement sérieux, et le calcul de la bande passante deviendra un problème avant la mémoire. Si vous disposez seulement d’une machine de 1 GB, Galène convient mieux à cette taille que Jitsi.

Ai-je encore besoin d’un serveur TURN si mon VPS possède une adresse IP publique ?

Oui. Le problème résolu par TURN se situe à l’autre extrémité de l’appel. Un participant sur un réseau d’entreprise qui bloque l’UDP sortant, ou derrière un NAT de niveau opérateur qui attribue un port source différent pour chaque destination, ne peut pas établir de chemin média direct, même si l’adresse de votre serveur est publique. TURN sur TCP avec 443 ou 5349 leur fournit un relais qui ressemble à du trafic web normal pour leur firewall. L’installation du paquet Jitsi configure coturn dans ce but par défaut. C’est pourquoi les règles de firewall documentées ouvrent UDP 3478 et TCP 5349.

Pourquoi BigBlueButton nécessite-t-il beaucoup plus de ressources matérielles que Jitsi Meet ?

Parce qu’il fait bien plus que transmettre de la vidéo. Ses exigences de production publiées sont de 16 GB de RAM et 8 cœurs, contre 8 GB et 4 cœurs dans le guide de Jitsi. BigBlueButton exécute une pile complète de conférence audio, un tableau blanc partagé et une couche de présentation, un pipeline d’enregistrement et de post-traitement, ainsi qu’une interface web avec des comptes utilisateur, le tout sur la même machine. La plateforme est également imposée : en août 2026, l’installation prise en charge est la version 3.0 sur Ubuntu 22.04. Ces deux ensembles de chiffres proviennent de la documentation de chaque projet. Ils servent de points de départ et ne constituent pas des mesures de votre charge de travail.