Zelf videoconferencing hosten op een VPS: de beste keuze

Zelfgehoste videoconferencing op een VPS is een bandbreedteprobleem

Zelfgehoste videoconferencing faalt op kleine servers om één reden, en dat is bijna nooit de installatie. Het serveronderdeel dat elk modern hulpmiddel gebruikt, is een SFU (selective forwarding unit). Deze neemt één videostream van elke deelnemer en stuurt een kopie daarvan door naar elke andere deelnemer, waardoor het verkeer dat de server verlaat kwadratisch toeneemt met het aantal deelnemers. Een 1 GB of 2 GB VPS op een gedeelde uplink zal de software prima draaien. Het zal echter niet de grote vergadering ondersteunen die u voor ogen heeft.

Voer het werk daarom in deze volgorde uit. Tel het aantal personen, bereken de benodigde megabits en kies daarna pas de server. De installatie is twintig minuten kopiëren en plakken. De uplink bepaalt of iemand u kan horen.

Waarom groeit de bandbreedte kwadratisch met het aantal deelnemers?

Begin bij mesh. Elke browser codeert zijn camerabeeld en stuurt een kopie rechtstreeks naar elke andere browser; er komt geen mediaserver aan te pas. Een mesh-gesprek tussen twee personen vereist enkel een signaleringsserver, wat de reden is dat één-op-één-gesprekken vrijwel gratis te hosten zijn. Mesh werkt niet meer bij vier of vijf personen, omdat een laptop op een thuisverbinding op dat moment vier of vijf afzonderlijke kopieën van zijn eigen videostream tegelijk moet uploaden.

Een SFU werkt anders. Elke browser uploadt één kopie naar de server. De server leest de RTP (real-time transport protocol) headers en stuurt die pakketten door naar de andere deelnemers zonder de video te decoderen. Dat is de hele truc, en daarom is een SFU licht voor de CPU maar zwaar voor het netwerk.

De oudere opzet is een MCU (multipoint control unit). Deze decodeert elke inkomende stream, voegt ze samen tot één beeld en codeert dat beeld opnieuw. De uitgaande bandbreedte is minimaal. De CPU-belasting is enorm. Bijna niets gebruikt tegenwoordig nog een MCU voor video, en in deze handleiding wordt er geen gebruik van gemaakt.

Nu de berekening voor een SFU. Stel dat iedereen video verstuurt met 1,2 Mbps en niemand de camera uitschakelt. De server ontvangt N keer 1,2 Mbps; dit is lineair en onschadelijk. De server verstuurt N keer (N min 1) keer 1,2 Mbps, omdat elk van de N personen de andere N min 1 streams moet ontvangen. Dat tweede getal is wat projecten de das omdoet.

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

Deze rijen zijn rekenkundig en geen meting van een specifieke server. De maandelijkse kolom gaat uit van twintig uur aan gesprekken per maand. Lees eerst de laatste rij. Vijftig mensen met de camera aan hebben 2,940 Mbps aan aanhoudend uitgaand verkeer nodig vanaf één machine. Dertig mensen hebben 1,044 Mbps nodig. Vier mensen hebben 14.4 Mbps nodig, wat elke VPS zonder problemen aankan. Tussen de rij voor vier personen en de rij voor dertig personen groeit het aantal deelnemers met een factor zeven en een half, terwijl het uitgaande verkeer met meer dan zeventig keer toeneemt.

Echte implementaties blijven onder deze cijfers, en het is nuttig om precies te weten hoe. Jitsi en LiveKit gebruiken beide simulcast: een zender publiceert meerdere kwaliteitslagen tegelijk, en de SFU stuurt een lage kwaliteitslaag door naar iedereen die niet in beeld is. Jitsi heeft ook een last-N-instelling die alleen video doorstuurt voor de meest recente sprekers. Beide besparen veel verkeer. Geen van beide verandert de vorm van de curve, en beide stoppen met helpen op het moment dat iedereen de camera aanzet en elkaar vastzet in het beeld.

Wat krijgt u daadwerkelijk met een VPS-uplink?

Op een productpagina staat vaak "1 Gbps poort". Dit is de snelheid van de virtuele netwerkkaart en geen garantie voor de volgende hop. De verbinding wordt gedeeld met andere huurders op dezelfde fysieke host. Daarom is de constante doorvoersnelheid tijdens een druk uur lager dan de poortsnelheid, en een conference call is precies zo'n constante belasting. De meeste abonnementen hebben ook een maandelijkse datalimiet, waarna uw verbinding wordt geknepen of extra kosten in rekening worden gebracht.

Die limiet is waar het vierkantje op een factuur verschijnt. Twintig uur aan een gesprek met dertig personen in één maand verplaatst 9.4 TB aan data vanaf de server, met 469.8 GB per uur. Twintig uur aan een gesprek met vijftig personen verplaatst 26.5 TB. Controleer de datalimiet voordat u naar de hoeveelheid RAM kijkt. Als de productpagina hier vaag over is, dan is die vaagheid uw antwoord. Een goedkope VPS-aanbieding correct lezen is voor deze workload belangrijker dan voor bijna elke andere.

Jitsi Meet: de standaardkeuze en de vereisten

Jitsi Meet is de oplossing waarmee de meeste gebruikers moeten beginnen. De installatie verloopt via de Debian-repository van het project zelf, waarbij nginx en een certificaat tijdens de installatie worden geconfigureerd. De videobridge (JVB) gebruikt een enkele UDP-poort, wat de firewallregels overzichtelijk houdt. Het vereist Debian 11 of nieuwer, of Ubuntu 22.04 of nieuwer.

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

Het installatieprogramma vraagt om een hostnaam en biedt vervolgens een keuze voor een certificaat. Kies de Let's Encrypt-optie en geef een domeinnaam op die al naar het publieke adres van deze server verwijst. Het certificaat wordt uitgegeven via een HTTP-challenge; een naam die ergens anders naar verwijst, zal bij die stap falen.

Open vervolgens de poorten. Dit zijn de poorten die in het handboek worden gedocumenteerd, met SSH als eerste zodat ufw enable u niet buitensluit:

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 en 443 bedienen de webapplicatie en maken certificaatvernieuwing mogelijk. UDP 10000 transporteert alle audio en video; dit is de poort die vaak wordt vergeten. UDP 3478 en TCP 5349 horen bij de coturn-server die het Jitsi-pakket naast de bridge installeert. Dit is het fallback-pad voor gebruikers wiens netwerk UDP blokkeert.

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

Het eerste commando moet rapporteren dat de service actief is. Het tweede commando moet tonen dat de bridge luistert op UDP 10000. Als er niets wordt getoond, is de bridge niet gestart en zal /var/log/jitsi/jvb.log aangeven waarom.

Wat betreft de schaling publiceert Jitsi in het handboek een eigen startpunt, terwijl BigBlueButton een veel grotere configuratie adviseert:

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

Het handboek van Jitsi suggereert 8 GB RAM en 4 toegewezen cores voor een serieuze server, waarbij 1,000 Mbps netwerksnelheid vaak voldoende is. Er wordt opgemerkt dat kleinere opstellingen op 4 GB of 2 GB draaien. Eén detail op die pagina is belangrijk om te onthouden: Prosody, de XMPP-server die de signalering afhandelt, kan slechts één core gebruiken. Extra cores helpen de bridge, maar doen niets voor de signalering.

Waarom neemt iedereen deel aan het gesprek, maar ziet niemand video?

Dit is het standaard Jitsi-probleem op een VPS. De deelnemerslijst vult zich, chat werkt, maar elk videovenster blijft zwart. De videobridge adverteert de adressen die deze op de eigen interfaces vindt. Bij een provider die de virtuele machine een privaat adres geeft en daar een publiek adres op mapt, vindt JVB alleen het private adres. Elke client probeert vervolgens media te sturen naar een adres zoals 10.0.0.5, waardoor de pakketten nergens aankomen.

Geef beide adressen door aan de bridge. Voeg een statische mapping toe aan /etc/jitsi/videobridge/jvb.conf:

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

Herstart met sudo systemctl restart jitsi-videobridge2. Gebruik het lokale adres uit ip -4 addr show en het publieke adres uit het configuratiescherm van uw provider. Oudere handleidingen stellen hetzelfde in via /etc/jitsi/videobridge/sip-communicator.properties met de keys org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS en org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS. Die werken nog steeds, maar nieuwe installaties dienen het bovenstaande mapping-blok te gebruiken.

De andere oorzaak is een firewall die u niet heeft geconfigureerd. De meeste providers hanteren een netwerkfirewall in het configuratiescherm die losstaat van ufw op de server zelf; UDP 10000 moet in beide openstaan. Om te achterhalen welke laag de pakketten blokkeert, voert u sudo tcpdump -ni any udp port 10000 uit op de server terwijl iemand van buitenaf deelneemt. Als er helemaal geen pakketten binnenkomen, bereikt niets de machine en ligt de blokkade stroomopwaarts van het besturingssysteem. Als er wel pakketten aankomen terwijl de vensters zwart blijven, antwoordt de bridge met een adres dat de client niet kan bereiken; in dat geval ligt het aan de mapping. Als u twijfelt over ufw zelf, behandelt de ufw-regels die een VPS daadwerkelijk nodig heeft de volgorde van regels waar gebruikers vaak over struikelen.

BigBlueButton: zwaar, eigenzinnig en het eist de volledige server

BigBlueButton is ontworpen voor onderwijsdoeleinden. Het beschikt over een whiteboard, subgroepen, polls en een presentatiegedeelte. De opnamefunctionaliteit is een kernonderdeel en geen extra toevoeging. Het is bovendien met grote afstand de zwaarste optie in dit overzicht en geen pakket dat u zomaar aan een bestaande server toevoegt.

Sinds augustus 2026 is het ondersteunde pad BigBlueButton 3.0 op Ubuntu 22.04, geselecteerd met de jammy-300-versievlag. De door het project gestelde productievereisten zijn 16 GB geheugen met swap ingeschakeld, 8 CPU-cores met hoge single-thread prestaties, 250 Mbps symmetrische bandbreedte en 500 GB schijfruimte als u opnames bewaart (50 GB als u deze uitschakelt). De gebruikte poorten zijn TCP 80 en 443, plus het UDP-bereik 16384 tot 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

De voorbeelden van het project zelf sluizen dat script direct door naar bash. Download het eerst en lees het door, omdat het uw nginx-configuratie herschrijft, zijn eigen media- en audiostack installeert, pakketversies vastzet en de hostname opeist. Dit is een bewuste ontwerpkeuze en geen gebrek: BigBlueButton verwacht de volledige controle over de machine te hebben. De -w-vlag configureert de firewall, -s is de hostname, -e is het adres dat Let's Encrypt registreert en -g voegt de Greenlight-frontend toe. Als dezelfde machine ook TLS-termination verzorgt voor andere services, verplaats BigBlueButton dan naar een andere server of zorg dat u begrijpt wat uw nginx reverse proxy-configuratie doet voordat het script deze wijzigt.

Vergelijk de twee rijen in die tabel zorgvuldig. BigBlueButton vraagt om twee keer zoveel geheugen en twee keer zoveel cores als de aanbeveling van Jitsi, terwijl het om een kwart van de bandbreedte vraagt. De twee cijfers worden niet op dezelfde manier gemeten en gaan uit van verschillende groepsgroottes; beschouw ze daarom als het startpunt van het betreffende project en niet als een directe vergelijking. Het verschil in CPU-gebruik is reëel en komt voort uit alles wat BigBlueButton doet naast het doorsturen van video.

Galène: de compacte optie

Galène is een compacte SFU geschreven in Go. Het compileert naar een enkel statisch binary-bestand, bevat een eigen webclient en beschikt over een ingebouwde TURN-server. Er is dus geen XMPP-server, Java-runtime of Rails-applicatie die u in de lucht moet houden. Als u een betrouwbare verbinding voor tien personen op een bescheiden server nodig heeft, probeer dit dan voordat u concludeert dat u zwaardere hardware nodig heeft.

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

Het golang-go-pakket op Ubuntu 24.04 is Go 1.22. Als go build meldt dat de module een nieuwere versie van Go vereist, installeer dan een actuele toolchain vanaf go.dev in plaats van te proberen het distributiepakket aan te passen.

Een 'group' is de term die Galène gebruikt voor een vergaderruimte; een group is een JSON-bestand:

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

Open https://your.server:8443/group/night-watch/ en log in als vimes. Deze inloggegevens zijn direct afkomstig uit de README van het project; wijzig deze dus voordat de poort vanaf andere locaties bereikbaar is. Voor een echte implementatie documenteert het project een systemd-unit:

[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

De gebruikte poorten zijn TCP 8443 voor de webinterface, TCP en UDP 1194 voor de ingebouwde TURN-server, en een reeks hoge UDP-poorten voor media. Pin deze reeks vast zodat u hiervoor één firewallregel kunt schrijven:

./galene -udp-range 40000-40100

De optie -turn is de belangrijkste op een VPS. -turn ':1194' luistert op alle publieke IPv4-adressen. -turn '203.0.113.1:1194' vertelt Galène welk adres clients daadwerkelijk zullen zien; dit is noodzakelijk wanneer het eigen adres van de machine privé is. -turn '' schakelt de ingebouwde server uit, zodat u via data/ice-servers.json naar een externe server kunt verwijzen. De standaardwaarde is auto, wat zich gedraagt als :1194 wanneer er geen ice-servers.json bestaat.

U kunt nginx voor de webinterface plaatsen door proxyURL in data/config.json in te stellen en de /ws-locatie te proxen met de WebSocket-upgradeheaders. Wees u bewust van wat dit dekt: clients openen nog steeds directe UDP-stromen en directe TCP-verbindingen naar de TURN-poort. De reverse proxy handelt dus alleen de pagina en de signalering af. Mediastromen passeren de proxy nooit.

De documentatie van Galène stelt dat het zeer bescheiden serverbronnen vereist, maar publiceert geen specifieke cijfers; verwacht deze dus ook niet. De eerder genoemde berekening voor bandbreedte blijft volledig van kracht. Wat u bespaart, is het geheugen en de complexiteit van alle onderdelen die geen deel uitmaken van de SFU.

Owncast: één-op-veel, waarbij bandbreedte lineair blijft

Veel vereisten voor "videoconferencing" komen in de praktijk neer op één persoon die presenteert aan een publiek dat via een chat reageert. Als dit uw situatie is, dan is een SFU de verkeerde tool en verandert de economische kant volledig. Owncast ontvangt een RTMP-stream van OBS of een vergelijkbare encoder en serveert HLS via standaard HTTPS. De bandbreedte per kijker is lineair in plaats van kwadratisch, en omdat de output uit gewone HTTP-segmenten bestaat, kunt u deze achter object storage of een CDN plaatsen en stoppen met betalen voor de origin-server.

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

De documentatie van het project adviseert om dit niet als root uit te voeren en om elk extern script te inspecteren voordat u het uitvoert; daarom is de download een afzonderlijke stap hierboven. Het installatieprogramma haalt de huidige release en een ffmpeg-binary op als u deze nog niet heeft. Voer ./owncast uit vanuit de installatiemap en open het admin-paneel op /admin op poort 8080. De standaard login is de gebruiker admin met de standaard stream key abc123 als wachtwoord. Wijzig dit voordat u een domein naar de server verwijst.

Het HLS-ontwerp heeft twee gevolgen. Kijkers lopen enkele seconden of minuten achter op de live-uitzending, omdat HLS volledige segmenten verstuurt; er is dus geen sprake van een tweerichtingsgesprek. Daarnaast is er geen UDP en geen TURN aanwezig in het pad, waardoor het netwerken bereikt waar een WebRTC-verbinding helemaal geen verbinding kan maken.

Owncast is bovendien de enige tool in dit overzicht die bewust transcodeert. Elke kwaliteitsinstelling die u inschakelt, is een extra ffmpeg-encode van de inkomende stream die gedurende de gehele uitzending draait. Bied op een kleine VPS slechts één of twee kwaliteitsniveaus aan. Vijf niveaus zullen de CPU volledig belasten terwijl het netwerk onbenut blijft.

Element Call op een Matrix-server die u al beheert

Als u al een Matrix-server beheert, is video een toevoeging in plaats van een tweede product dat u moet onderhouden. Het blijft echter meer dan één pakket. Element Call vereist twee zaken achter uw homeserver. Het eerste is een LiveKit SFU, die de media-doorsturing verzorgt. Het tweede is de MatrixRTC-autorisatieservice, element-hq/lk-jwt-service, die de client voorziet van de LiveKit WebSocket URL en een ondertekend JWT (JSON web token) om verbinding te maken. Die service gebruikt de Matrix-federatie-API, dus deze vereist een TLS-reverse proxy ervoor en een naam die via federatie bereikbaar is.

De gedocumenteerde poorten van LiveKit:

• TCP 7880 voor de API en de client WebSocket, achter een proxy die TLS-termination afhandelt
• TCP 7881 voor ICE over TCP, gebruikt wanneer een client geen verbinding kan maken via UDP
• UDP 50000 tot 60000 voor media, waarbij elke deelnemer in een ruimte twee poorten gebruikt
• UDP 3478 en TCP 5349 als u de ingebouwde TURN-server inschakelt; 5349 moet naar 443 worden verplaatst tenzij er een load balancer voor staat

Twee poorten per deelnemer klinkt alarmerend, maar dat is het niet. Een bereik van 10.000 poorten dekt duizenden deelnemers, en uw uplink raakt lang voor het bereik vol is. Stel het volledige bereik open, omdat een gedeeltelijk geopend bereik voor sommige gebruikers faalt en voor anderen werkt; dit is het lastigste type fout om te debuggen. De kant van de homeserver is een aparte taak, die wordt behandeld in het draaien van een Synapse-homeserver op een VPS.

Waarom kan één persoon nooit verbinding maken? TURN en netwerken die UDP blokkeren

Eerst wat terminologie, elk eenmalig gebruikt. ICE (interactive connectivity establishment) is het proces dat twee WebRTC-endpoints gebruiken om een werkend pad tussen elkaar te vinden. STUN (session traversal utilities for NAT) is een kleine service die een client vertelt hoe zijn eigen publieke adres er van buitenaf uitziet. TURN (traversal using relays around NAT) is een relay: wanneer er geen direct pad bestaat, sturen beide partijen hun media naar de TURN-server en deze stuurt het door.

U heeft TURN nodig voor de deelnemers wiens netwerken u niet kunt bereiken. Eén van hen bevindt zich op een bedrijfs- of campusnetwerk waar uitgaand UDP volledig wordt geblokkeerd. Een ander zit achter een carrier-grade NAT die voor elke bestemming een ander bronpoortnummer toewijst; dit heet symmetric NAT en maakt het adres dat STUN rapporteerde onbruikbaar.

Het symptoom is specifiek. De meeste mensen nemen deel en alles werkt. Eén persoon ziet de deelnemerslijst, ziet de chat, maar krijgt een zwart vlak en een laadicoon. Hun browser heeft kandidaten verzameld, geen van de paren werkte, en ICE eindigde in een mislukte status. In Chrome laat chrome://webrtc-internals, geopend tijdens de poging, de kandidaat-paren en die foutmelding zien. Vraag die persoon om het opnieuw te proberen via een telefoon op mobiele data. Als het daar wel werkt, is hun netwerk de oorzaak en is TURN de oplossing.

TURN over TCP op 443 of 5349 is de fallback die bijna overal werkt, omdat een netwerk dat TLS op 443 blokkeert, het web zelf heeft geblokkeerd. Het pakket van Jitsi installeert en configureert coturn voor u, wat precies de reden is waarom de gedocumenteerde firewallregels UDP 3478 en TCP 5349 bevatten. Galène heeft TURN ingebouwd op 1194. LiveKit heeft een ingebedde TURN-server die u in de configuratie inschakelt. Als u zelf coturn draait:

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

Op Debian en Ubuntu start de verpakte service niet totdat u TURNSERVER_ENABLED=1 instelt in /etc/default/coturn. Een coturn die wel is geïnstalleerd maar niet is ingeschakeld, ziet er van buitenaf hetzelfde uit als helemaal geen TURN hebben; dit is de reden waarom deze ene regel mensen hele avonden kost.

Nu de kosten waar niemand over schrijft. Een relay draagt de volledige media van elke gerelayeerde deelnemer in beide richtingen. Wanneer coturn een server deelt met de SFU, gaat het meeste van dat verkeer over loopback en kost het u CPU in plaats van uplink, en de TLS-listener versleutelt elk pakket een tweede keer bovenop de DTLS die de media al bevat. Wanneer u TURN naar een eigen machine verplaatst, heeft die machine een eigen bandbreedteplan nodig met dezelfde capaciteit als die van de SFU. En TURN over TCP verandert real-time media in een betrouwbare stream, waardoor een verloren pakket wordt opnieuw verzonden in plaats van overgeslagen, en een gerelayeerde deelnemer op een instabiele verbinding bouwt vertraging op in plaats van een korte hapering. Relay is een fallback die verbinding maakt, met een kwaliteit die het directe pad had overtroffen.

Wanneer voert de SFU transcodering uit en wat zijn de kosten daarvan?

Een SFU stuurt pakketten door en decodeert nooit video; daarom kunnen vier cores een ruimte bedienen die op papier onmogelijk lijkt. Twee functies doorbreken dit principe, en beide verrassen de gebruikers die ze via een selectievakje hebben ingeschakeld.

Opnemen is de eerste. Jitsi neemt op met Jibri, en de documentatie van Jibri beschrijft precies wat dit inhoudt: het start een Chrome-instantie die wordt gerenderd in een virtuele framebuffer, waarna de uitvoer wordt vastgelegd en gecodeerd met ffmpeg. Dit is een volledige browser die uw gehele vergadering rendert, plus een video-encoder, die continu draait gedurende de gehele duur van het gesprek. Dezelfde documentatie stelt dat er slechts één opname tegelijk wordt ondersteund op een enkele Jibri, en dat Jibri bedoeld is om op een aparte machine of virtuele machine te draaien waar geen andere applicaties gebruikmaken van de beeldscherm- of audioapparatuur. Opnemen is een tweede server, geen selectievakje.

Telefonisch inbellen is de tweede. Het koppelen van een telefoonlijn aan een conferentie betekent dat Opus op 48 kHz moet worden geconverteerd naar wat het telefoonnetwerk accepteert, meestal G.711 op 8 kHz, in beide richtingen en continu gedurende het hele gesprek. Audio-transcodering is aanzienlijk goedkoper dan video-transcodering, maar het proces draait per gespreksverbinding en pauzeert nooit, waardoor de kosten schalen met het aantal bellers. Als u een inbelnummer wilt, is een zelfgehoste VoIP-server de component die dit werk verricht, en deze hoort om dezelfde reden als Jibri op een eigen machine thuis.

Hoe groot moet de server daadwerkelijk zijn?

Voor twee personen is bijna niets nodig. Jitsi schakelt standaard over naar de peer-to-peer-modus wanneer er precies twee deelnemers zijn; in die modus stopt de conferentie met het verzenden van data via de videobridge en wordt de directe verbinding gebruikt. Zodra een derde persoon deelneemt, schakelt het systeem terug naar de bridge. Een 1 GB VPS met Jitsi is daarom een prima server voor één-op-één-gesprekken, maar ongeschikt voor vier personen. Dit verklaart waarom "het werkte tijdens mijn test" zo'n veelgehoorde opmerking is.

Voor maximaal tien personen met ingeschakelde camera's ligt 67.2 Mbps bij acht deelnemers binnen de bandbreedte die een standaard VPS-uplink kan verwerken. Twee virtuele CPU's en 4 GB RAM volstaan voor Jitsi of Galène bij dit aantal, zolang u geen opnames maakt. Monitor de datatransfer in plaats van de CPU-belasting.

Voor dertig personen is het worst-case scenario 1,044 Mbps continu, wat over twintig uur neerkomt op 9.4 TB. Bij deze schaal moet u eerst de kosten voor bandbreedte berekenen voordat u naar de server kijkt. Schakel last-N in zodat de bridge alleen de meest recente sprekers doorstuurt, stel standaard in dat camera's uitstaan voor deelnemers en plaats de SFU op een locatie met een datalimiet die deze berekening toelaat.

Daarboven is één VPS niet langer de juiste oplossing. Of het evenement is in feite een uitzending, waarbij Owncast in combinatie met een CDN een fractie van de kosten bedraagt, of u heeft meer dan één videobridge achter een enkele signaleringslaag nodig. Dat is een ander project dan waar u mee begon.

Nog één laatste advies over routing. De meeste teams hebben chat nodig voor veel meer uren per dag dan video, en chat is goedkoop te hosten en eenvoudig in de lucht te houden. Het opzetten van een zelfgehost alternatief voor Slack voor het dagelijkse verkeer, en het reserveren van een conferentieserver voor geplande gesprekken, is de opzet die het beste past binnen een beperkt VPS-budget.

FAQ

Waarom kunnen mensen deelnemen aan mijn Jitsi-vergadering, maar elkaar niet zien of horen?

Chat en de deelnemerslijst verlopen via het signaleringskanaal, wat TCP op 443 gebruikt, terwijl audio en video UDP 10000 naar de videobridge gebruiken. Als de lijst met deelnemers wordt gevuld maar elk venster zwart blijft, is het mediapad verbroken terwijl het signaleringspad correct functioneert. Controleer UDP 10000 in beide firewalls: die op de server zelf en de externe netwerkfirewall in het configuratiescherm van uw provider. Controleer vervolgens of de bridge zijn publieke adres kent: op een virtuele machine met een privaat adres en een gekoppeld publiek adres, voegt u een statische mapping toe onder ice4j.harvest.mapping in /etc/jitsi/videobridge/jvb.conf en start u jitsi-videobridge2 opnieuw. Het uitvoeren van sudo tcpdump -ni any udp port 10000 terwijl iemand deelneemt, laat zien waar het probleem ligt; als er helemaal geen pakketten binnenkomen, bevindt de blokkade zich stroomopwaarts van het besturingssysteem.

Hoeveel bandbreedte verbruikt een videogesprek met 30 personen?

In het slechtste geval, waarbij iedereen de camera aan heeft en de SFU een videostroom van volledige kwaliteit naar iedereen doorstuurt, verlaat ongeveer 1,044 Mbps de server, wat neerkomt op 469.8 GB per uur. Dit is een rekenkundige benadering gebaseerd op N keer (N min 1) streams van elk 1,2 Mbps, en geen meting van uw specifieke opstelling. Simulcast en een last-N instelling verminderen dit aanzienlijk bij normaal gebruik, omdat de meeste deelnemers op elk willekeurig moment niet in beeld zijn. Houd bij het dimensioneren echter rekening met het slechtste scenario, aangezien dat de situatie is waarin iedereen tegelijkertijd de camera inschakelt.

Kan ik Jitsi Meet draaien op een 1 GB VPS?

Het zal installeren en een gesprek tussen twee personen zal werken, mede omdat Jitsi voor precies twee deelnemers de peer-to-peer-modus gebruikt en de videobridge volledig overslaat. Het is echter geen bruikbare server voor groepsgesprekken. Prosody, de videobridge en de Java-runtime vereisen allemaal geheugen; de aanbeveling in het handboek is 8 GB voor een serieuze implementatie, en de bandbreedteberekening zal eerder een knelpunt vormen dan het geheugen. Als u enkel over een 1 GB-server beschikt, is Galène een betere keuze dan Jitsi.

Heb ik nog steeds een TURN-server nodig als mijn VPS een publiek IP-adres heeft?

Ja. Het probleem dat TURN oplost, bevindt zich aan de andere kant van het gesprek. Een deelnemer in een bedrijfsnetwerk dat uitgaand UDP blokkeert, of achter een carrier-grade NAT die per bestemming een ander bronpoortnummer toewijst, kan geen direct mediapad opbouwen, ongeacht hoe publiek het adres van uw server is. TURN via TCP op 443 of 5349 biedt hen een relay die voor hun firewall op regulier webverkeer lijkt. De pakketinstallatie van Jitsi configureert coturn hiervoor standaard, wat de reden is dat de gedocumenteerde firewallregels UDP 3478 en TCP 5349 openen.

Waarom heeft BigBlueButton zoveel meer hardware nodig dan Jitsi Meet?

Omdat het veel meer doet dan alleen video doorsturen. De gepubliceerde productievereisten zijn 16 GB RAM en 8 cores, tegenover 8 GB en 4 cores in het handboek van Jitsi. BigBlueButton draait een volledige audioconferencing-stack, een gedeeld whiteboard en presentatielaag, een pipeline voor opnames en nabewerking, en een web-frontend met gebruikersaccounts, allemaal op dezelfde machine. Het stelt ook specifieke eisen aan het platform: per augustus 2026 is de ondersteunde installatie versie 3.0 op Ubuntu 22.04. Beide cijferreeksen zijn afkomstig uit de documentatie van de projecten zelf en dienen als startpunt in plaats van als meting van uw werkelijke belasting.