Alle kanten op
Videoconferentiesystemen maken gebruik van een server om de verbinding tussen de deelnemers te bemiddelen. Ze verschillen in hoe de eigenlijke beeld- en geluidsgegevens verstuurd worden. Bij sommige, zoals Nextcloud Talk, communiceren de clients rechtstreeks met elkaar, dus iedereen stuurt zijn data naar iedereen en ontvangt van iedereen. Daarom zijn de eisen voor de server en zijn netwerkverbinding zeer laag. Voor Nextcloud Talk is bijvoorbeeld een Raspberry Pi of PHP op een kleine gehoste webserver al voldoende.
De privacy bij videoconferenties kan ook makkelijk worden beschermd. De peerto-peer methode stelt twee clients in staat om afspraken te maken over end-to-endencryptie. Bovendien is het vrij moeilijk om alle data af te luisteren, omdat de datastromen verschillende routes nemen.
Maar omdat UDP voor de transmissie wordt gebruikt, zijn er twee afzonderlijke datastromen per paar deelnemers, één voor elke transmissierichting. Dat heeft twee grote nadelen. De upstream-bandbreedte van elke deelnemer moet voldoende zijn om de data parallel naar alle andere deelnemers te sturen. Als je dus een xDSL-verbinding hebt met een lage upstream-snelheid, kun je alleen deelnemen aan sessies met weinig deelnemers. Bovendien staat de Network Address Translation (NAT) van routers vaak de boel in de weg. Het werkt alleen voor uitgaande UDP-stromen betrouwbaar. Om binnenkomende gegevens er doorheen te sluizen, moeten clients wat trucs uithalen en de UDP-poorten raden.
Of dat werkt, is afhankelijk van de NAT-technologie die in een router geïmplementeerd is. Thuisrouters kun je vaak om de tuin leiden, maar sommige bedrijfs- en vooral mobiele netwerken gebruiken ‘symmetrische NAT’ en zijn daarom een onneembare vesting voor binnenkomende streams: als je daar achter zit, kun je niets horen of zien van je partners. Dan helpt een extra TURN-server een Nextcloud Talk-installatie op weg.
CENTRALISME
De NAT- en traffic-problemen van peer-topeer-conferenties hebben geen invloed op de systemen die geluid en beeld via een centrale server routeren. Elke client hoeft dan maar één keer beeld en geluid naar de server te sturen. En zelfs als iedereen de gegevens van de andere deelnemers volledig ontvangt, past het principe van weinig versturen en veel ontvangen perfect bij een xDSL-verbinding. De server kan de kwaliteit van de verzonden video per client aanpassen aan de kwaliteit van de verbinding. Op die manier creëren systemen zoals Zoom een aanvaardbare kwaliteit, zelfs over echt slechte lijnen.
De prijs: je privacy. Want als een server de videogegevens moet optimaliseren, kunnen die niet versleuteld blijven. In plaats van end-to-end-beveiliging kan alleen de overdracht tussen client en server versleuteld worden. In principe kan iedereen die toegang heeft tot de videoserver de videoconferenties ook bekijken.
Een server onder eigen controle helpt daartegen; we hebben in [1] beschreven hoe je dat zou kunnen doen. Maar de eisen aan de server en vooral aan de internetverbinding zijn hoog. De datastromen van alle deelnemers moeten immers ontvangen worden en ook weer worden verstuurd. Daarom is een thuisserver of een hostingpakket met beperkt dataverkeer vaak niet voldoende voor regelmatige conferenties met meerdere deelnemers.
Bovendien draaien delen van de software soms buiten de webserver, en dan heb je aan een eenvoudig hostingpakket niet genoeg. Dan moet je een rootserver of een containercloud hebben. En video-optimalisatie vergt ook wel wat rekenkracht – die een Raspberry Pi niet kan bieden.