Es gibt einen starken und weiter wachsenden Bedarf an digital souverän betreibbaren Lösungen für Videokonferenzen. Wir von Kopano stellen mit Kopano Meet ein Werkzeug hierfür zur Verfügung, andere erfolgreiche Player am Markt sind zum Beispiel Big Blue Button oder Jitsi. Uns alle eint jedoch ein Problem im Wettbewerb mit Zoom, Google Meet oder Microsoft Teams: Die dahinter liegende Infrastruktur.
Die Herausforderung
Videokonferenzen benötigen neben vergleichsweise kleinen Audiostreams auch Videostreams und Datenströme mit den freigegebenen Bildschirmen oder Präsentationen. Je nach der Anzahl aktiver Teilnehmern an einer einzelnen Konferenz wächst die Herausforderung an Bandbreite und Latenz. In einem früheren Blogpost reiße ich dieses Thema kurz an.
Hyperscaler wie Google oder Microsoft, oder auch mit hohen finanziellen Mitteln ausgestattete Anbieter wie Zoom betreiben eine Infrastruktur aus MCUs und/oder SFUs, die sich nah an den Anwendern befinden.
Hintergrund:
Eine SFU (Selective Forwarding Unit, unsere heißt Kopano Meet Boost) nimmt den teilnehmenden Clients vor allem Last beim Senden von Video- und Audiostreams ab. Diese müssen ja immer in dem Format verfügbar sein, dass jeder andere Teilnehmer benötigt. Und vor allem muss es einen solchen Stream für jeden anderen Teilnehmer geben.
Eine MCU (MultiCast Unit) sorgt zusätzlich dafür, das Teilnehmer nur einen bereits vorab gemixten Video- und Audiostream aus all dem erhalten, was alle andere Teilnehmer senden.
Abgesehen von den wirtschaftlichen Herausforderungen (beide Units sind sehr hohen Schwankungen im Bedarf von Rechenleistung ausgesetzt) und dem sich (zu) langsam lösenden Problem der Ende-zu-Ende-Verschlüsselung (siehe https://www.chromestatus.com/feature/6321945865879552, Datum: 20.11.2020) bilden genau diese Module das LockIn-Szenario: SFU und MCU sind jeweils nur für den Anbieter eines Dienstes nutzbar. Deswegen kann Zoom Dinge, die nur Zoom kann.
Die Infrastruktur
Eine Lösung wäre die Trennung von Infrastruktur und Anwendung, wie es bei der Bahn mit dem Schienennetz und den Anbietern der Zugverbindungen der Fall ist. Man könnte hier über ein Airbus-Modell nachdenken, bei dem Europa einen Infrastrukturanbieter schafft. Das widerspricht aber den Grundgedanken der digitalen Souveränität. Offene wohldefinierte Schnittstellen und ein mit dem Sovereign Cloud Stack vergleichbarer Ansatz für die Infrastruktur können jedoch eine flexible, hoch skalierbare und digital souveräne Lösung schaffen.
Die SFUs/MCUs bilden neben einem TURN Service die Basis der Infrastruktur. Da die Kommunikation aller modernen Videokonferenzlösungen über WebRTC stattfindet, sollten sich allumfassend nutzbare Schnittstellen definieren lassen. Eine Infrastrukturdefinition könnte die freie Wahl zwischen einer MCU und einer SFU beinhalten. Provider können dieses Paket dann als ihr Produkt mit ihrer Rechenpower und ihrem Pricing anbieten. Kunden können somit frei den Anbieter der Infrastruktur wählen und zwischen diesen wechseln.
Markt der Lösungsanbieter
Lösungsanbieter wie wir (oder Jitsi oder andere) verbinden sich dann jeweils zu diesen Infrastrukturen. Wer bereits eine Infrastruktur hat, wie z.B. Big Blue Button, kann die souveräne Infrastruktur neben seiner proprietären anbieten. Unterschiede auf Lösungsebene sind dann in Usecases (z.B. Konferenz, Klassenzimmer, …), Integrationen, Look & Feel oder Komfort zu finden. Da beim Anbieter der Infrastruktur notwendiger Weise auch alle Datenströme auflaufen, spielt natürlich auch das Vertrauen eine große Rolle. Mit dem Gedanken von definierten Schnittstellen ist dann aber ein Self-Hosting möglich, welches die Vertrauensfrage zum Beispiel für den Schulalltag oder kritische Unternehmenskommunikation lösen könnte.
