Zelfgehoste videoconferentie op VPS: bandbreedte berekenen

Zelfgehoste videoconferenties op een VPS vormen een bandbreedteprobleem

Zelfgehoste videoconferenties falen 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 alle andere deelnemers, waardoor het verkeer dat de server verlaat kwadratisch toeneemt met het aantal deelnemers. Een VPS van 1 GB of 2 GB op een gedeelde uplink zal de software prima draaien. Deze 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 tegelijkertijd vier of vijf afzonderlijke kopieën van zijn eigen videostream 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 deze 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 niets in deze handleiding doet dat.

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, wat lineair en onschadelijk is. 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 waar projecten op vastlopen.

[
  {
    "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, geen meting van een specifieke server. De maandelijkse kolom gaat uit van twintig uur aan gesprekken per maand. Lees de laatste rij eerst. 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 zevenenhalf keer, terwijl het uitgaande verkeer meer dan zeventig keer zo groot wordt.

Echte implementaties blijven onder deze cijfers, en het is nuttig om precies te weten hoe. Zowel Jitsi als LiveKit gebruiken simulcast: een zender publiceert tegelijkertijd verschillende kwaliteitslagen, en de SFU stuurt een lage laag 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 zodra iedereen de camera aanzet en elkaar vastzet op het scherm.

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 piekuren 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 de kosten op een factuur zichtbaar worden. Twintig uur aan een gesprek met dertig personen in één maand verbruikt 9.4 TB aan dataverkeer vanaf de server, bij 469.8 GB per uur. Twintig uur aan een gesprek met vijftig personen verbruikt 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 toepassing.

Jitsi Meet: de standaardkeuze en de vereisten

Jitsi Meet is de oplossing waar de meeste gebruikers mee moeten beginnen. De software wordt geïnstalleerd vanuit de eigen Debian-repository van het project, configureert tijdens de installatie nginx en een certificaat, en de videobridge (JVB) gebruikt slechts één UDP-poort, wat de firewallregels beperkt 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 aan. 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 deze 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 van wie het 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 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 dimensionering publiceert het handboek van Jitsi een eigen startpunt en BigBlueButton een aanzienlijk grotere configuratie:

[
  {
    "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 volstaat. Er wordt opgemerkt dat kleinere opstellingen draaien op 4 GB of 2 GB. Eén detail op die pagina is het onthouden waard: 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 de call, maar ziet niemand video?

Dit is het standaard Jitsi-probleem op een VPS. De deelnemerslijst vult zich, de chat werkt, maar elk videovenster blijft zwart. De videobridge adverteert de adressen die hij op zijn eigen interfaces vindt. Bij een provider die de virtuele machine een privéadres geeft en daar een publiek adres op mapt, is het enige adres dat JVB vindt het privéadres. Hierdoor probeert elke client media te sturen naar een adres zoals 10.0.0.5 en komen de pakketten nergens aan.

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 gebruiken 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 tegenhoudt, 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 er niets de machine en ligt de blokkade vóór 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 is de mapping de oorzaak. Als u twijfelt over ufw zelf, behandelt de ufw-regels die een VPS daadwerkelijk nodig heeft de volgorde van regels waar veel gebruikers over struikelen.

BigBlueButton: zwaar, eigenzinnig en het eist de volledige server op

BigBlueButton is ontworpen voor onderwijsdoeleinden. Het beschikt over een whiteboard, subgroepruimtes, polls en een presentatiegebied. De opnamefunctionaliteit is een kernonderdeel en geen extra toevoeging. Het is veruit 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 sturen het script rechtstreeks naar bash. Download het script 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 front-end toe. Als dezelfde server ook TLS-termination uitvoert voor andere services, verplaats BigBlueButton dan naar een andere machine 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 elk specifiek project in plaats van als een directe vergelijking. Het CPU-verschil is reëel en komt voort uit alle taken die BigBlueButton uitvoert naast het doorsturen van video.

Galène: de compacte optie

Galène is een compacte SFU geschreven in Go. Het bouwt naar een enkel statisch binair bestand, bevat een eigen webclient en is voorzien van een TURN-server. Er is dus geen XMPP-server, Java-runtime of Rails-applicatie die u in de lucht hoeft te houden. Als uw vereiste een betrouwbare vergadering met tien personen op een bescheiden server is, 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 klaagt dat de module een nieuwere versie van Go vereist, installeer dan een actuele toolchain vanaf go.dev in plaats van te proberen de distributiepakketten aan te passen.

Een group is de term die Galène gebruikt voor een ruimte, en 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 een externe locatie bereikbaar is. Voor een daadwerkelijke 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 het adres dat 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, die 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, dus de reverse proxy handelt alleen de pagina en de signalering af. Mediastromen passeren deze nooit.

De documentatie van Galène stelt dat het zeer bescheiden serverbronnen vereist en publiceert geen specifiek cijfer; verwacht er dus geen. De bandbreedteberekening van hierboven blijft volledig van kracht. Wat u bespaart, is het geheugen en de bewegende onderdelen van alles wat niet de SFU zelf is.

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

Veel "videoconferentie"-behoeften zijn in feite één persoon die presenteert aan een publiek dat in de chat typt. Als dit uw situatie is, dan is een SFU het verkeerde hulpmiddel en veranderen de economische aspecten 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 stopt u met betalen voor het verkeer vanaf de origin.

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 hierboven een afzonderlijke stap. 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 via 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.

Er zijn twee gevolgen van het HLS-ontwerp. Kijkers lopen enkele seconden of minuten achter op de live-uitzending, omdat HLS volledige segmenten verstuurt; er is dus geen sprake van een heen-en-weer conversatie. 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 draait gedurende de gehele uitzending. Bied op een kleine VPS slechts één of twee kwaliteiten aan. Vijf kwaliteiten zullen de CPU verzadigen 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 componenten achter uw homeserver. De eerste is een LiveKit SFU, die de media doorstuurt. De 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) voor de verbinding. Deze service gebruikt de Matrix-federatie-API, dus deze vereist een TLS-reverse proxy aan de voorzijde en een naam die via federatie bereikbaar is.

De gedocumenteerde poorten voor LiveKit zijn:

• TCP 7880 voor de API en de client-WebSocket, achter een proxy die TLS termineert
• 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; poort 5349 moet worden verplaatst naar 443, tenzij er een load balancer voor staat

Twee poorten per deelnemer klinkt alarmerend, maar dat is het niet. Een bereik van 10.000 poorten is voldoende voor duizenden deelnemers, en uw uplink raakt verzadigd lang voordat het bereik op is. Stel het volledige bereik open, omdat een gedeeltelijk open bereik voor sommige gebruikers wel werkt en voor anderen niet; 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 is 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 toont chrome://webrtc-internals tijdens de poging de kandidaat-paren en die fout. 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 afgesloten. 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 ingebouwde 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

Deze instellingen plaatst u in /etc/turnserver.conf. Op Debian en Ubuntu start het pakket coturn direct na installatie met de standaardversie van dat bestand, dus enable --now hierboven vindt het al draaiend en wijzigt niets. Uw instellingen worden van kracht wanneer u sudo systemctl restart coturn uitvoert, en elke latere wijziging aan het bestand vereist dezelfde herstart. Oudere handleidingen adviseren ook om TURNSERVER_ENABLED=1 in /etc/default/coturn in te stellen. Alleen het oude init-script leest die schakelaar. De systemd-unit die huidige pakketten gebruiken doet dat niet, dus die regel verandert niets, en een coturn die u niet heeft herstart, bedient nog steeds het standaardbestand.

Dan de kosten waar niemand over schrijft. Een relay draagt de volledige media van elke gerelayeerde deelnemer in beide richtingen. Wanneer coturn op dezelfde server staat als de SFU, verloopt het meeste verkeer via loopback en kost dit 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 de SFU. Bovendien verandert TURN over TCP real-time media in een betrouwbare stream, waardoor een verloren pakket wordt herverzonden in plaats van overgeslagen. Een gerelayeerde deelnemer op een verbinding met pakketverlies bouwt daardoor vertraging op in plaats van een korte hapering. Relay is een fallback die verbinding mogelijk maakt, met een kwaliteit die het directe pad had kunnen overtreffen.

Wanneer transcodeert de SFU 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 het doet: het start een Chrome-instantie die wordt gerenderd in een virtuele framebuffer en legt de uitvoer vast en codeert deze 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 zonder dat andere applicaties gebruikmaken van de beeldscherm- of audioapparaten. Opnemen is een tweede server, geen selectievakje.

Telefonisch inbellen is de tweede. Het koppelen van een telefoonlijn aan een conferentie betekent het converteren van Opus op 48 kHz 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 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 dat 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 gegevens via de videobridge en wordt de directe verbinding gebruikt. Zodra een derde persoon deelneemt, schakelt het systeem terug naar de bridge. Een VPS met 1 GB RAM is daarom een prima server voor één-op-één-gesprekken, maar ongeschikt voor vier personen. Dit verklaart waarom de opmerking "het werkte tijdens mijn test" zo vaak voorkomt.

Voor maximaal tien personen met ingeschakelde camera's ligt 67.2 Mbps bij acht deelnemers binnen de bandbreedte die een standaard VPS-uplink kan ondersteunen. Twee virtuele CPU's en 4 GB RAM zijn voldoende om Jitsi of Galène op die schaal te draaien, mits u geen opnames maakt. Houd de teller voor dataverkeer in de gaten in plaats van de CPU-grafiek.

Voor dertig personen is het worst-case scenario 1,044 Mbps aan continu verkeer; twintig uur hiervan resulteert in 9.4 TB. Bij deze schaal moet u eerst de kosten voor bandbreedte berekenen voordat u naar de server zelf kijkt. Schakel last-N in zodat de bridge alleen de meest recente sprekers doorstuurt, stel in dat camera's standaard 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 gedurende veel meer uren per dag nodig dan video. Chat is goedkoop om 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 opstelling 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: de firewall 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 op. Het uitvoeren van sudo tcpdump -ni any udp port 10000 terwijl iemand deelneemt, laat zien welk van de twee het probleem is; 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 laag 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 afgeleide van N keer (N min 1) streams van elk 1,2 Mbps, 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 dit de situatie is tijdens een algemene vergadering waarbij 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 handleiding zelf adviseert 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 de handleiding van Jitsi. BigBlueButton draait een volledige audioconferencing-stack, een gedeeld whiteboard en presentatielaag, een pipeline voor opname en nabewerking, en een web-front-end 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 uitgangspunt in plaats van als meting van uw specifieke werklast.