Superautarke lokale Videokonferenz via OpenWRT + eduMEET + Raspberry Pi
Inhaltsverzeichnis
Einleitung
Die Ergebnisse des Lasttests der quelloffenen Videokonferenzplattform eduMEET ergaben, dass ein Server mit einem CPU Kern und einem Gigabyte RAM bereits über 20 Teilnehmer in einer Videokonferenz problemlos und qualitativ hochwertig mit Audio und Video versorgen kann. Desweiteren gibt es einen Artikel auf heise.de, welcher ein SoC-Board mit etlichen Antennen befähigt ein moderner Wi-Fi Router zu sein. Da moderne SoC-Boards die minimalen Anforderungen für eine eduMEET Instanz somit um mehrere Größenordnungen übertreffen, war die folgende Fragestellung naheliegend:
Ein solches Gerät kann für eine Vielzahl von Anwendungsmöglichkeiten dienen. Wann immer ein notwendiger Faktor bzw. Ressource, welcher zum Funktionieren des Dienstes notwendig ist, ausfällt oder beeinträchtigt ist, kann eine lokale bzw. vom Internet unabhängige Lösung Abhilfe schaffen. Als Beispiele hierzu wären zu nennen:
- Keine Verbindung zum regulären Internet möglich (Netzausfälle bis hin zu Katastrophenfall, schlechte Infrastrukturelle Anbindung, Sicherheitsrelevanz)
- Notwendigkeit zur räumlichen Trennung von Kommunikationspartnern (Medizinal Kontext, separates Routing in-house)
- Ad-hoc Bildschirmfreigabe ohne Ton und nötige Stromquelle
Anforderungen bzw. Scope
Um den ersten Teil der Forschungsfrage mit einem "Ja" beantworten zu können, müssen alle der folgenden Teilziele erreicht worden sein:
- Es gibt ein Gerät, welches diese Eigenschaften aufweist:
- es ist ein SoC-Board mit einem Wi-Fi Chip, welcher auch im Access Point Mode betrieben werden kann
- das SoC-Board ist kompatibel mit OpenWRT
- Der eduMEET Container ist auf dem Gerät funktionstüchtig
- Es herrscht Konnektivität zwischen allen Parteien (Server & Client)
- Client A erhält Audio und Video von Client B
Für den zweiten Teil der Frage müssen diverse Aspekte einer normalen Videokonferenz getestet werden, unter anderem Latenz, Bild- und Tonqualität aber auch Reichweite und ggf. auftretende Probleme.
Was hingegen nicht Gegenstand dieses Projekts war, ist die Frage nach der Skalierbarkeit bzw. Lastevaluation, Vergleich mehrerer Videokonferenzsysteme mit ähnlichem Aufbau und der Vergleich von unterschiedlichen Hardwaresetups. Das sind Fragen, welche im Future Work-Bereich verortet werden können.
Systemaufbau
Das Bild unten skizziert den (Hardware-)Aufbau des Setups: in rot-weiss der (headless) laufende Raspberry Pi 5, welcher über eine mobile 20.000 mAh Powerbank mit Strom versorgt wird, links ein Macbook als Client A und rechts ein Lenovo ThinkPad als Client B.
Der schematische Aufbau auf dem Raspberry Pi 5 selbst sieht wie folgt aus:
Auf dem Raspi läuft das OpenWRT als Betriebssystem (Snapshot Version [Build r30879-18077d22e9]), auf welchem wiederum der Docker-Daemon läuft um die Container zu administrieren. Vier Container sind für den Dienst notwendig: ein proxy Container, welcher die Anfrage aus dem Netz (und damit der Clients) korrekt weiterleitet; einen Client Container, der sich um die Darstellung des UIs und die clientseitige Konfiguration des Dienstes kümmert; ein Medianode Container, zuständig für die Audio und Videosignal "Verarbeitung" und ein Roomserver Container, welcher quasi das Backend des Dienstes organisiert. Die Version von eduMEET lautet 4.2-20260109-arm.
Implementation und Vorgehen
Ursprünglich war geplant ein ausrangiertes Intel NUC als Server zu verwenden, allerdings hätte es dafür sowohl ein spezielles Netzteil als auch eine USB-Antenne benötigt. Bei der Recherche wurde schnell klar, dass es fast keine USB-Antennen gibt, welche den notwendigen Access Point Modus unterstützen um eben als solcher für Clients fungieren zu können. Daher wurde als Plattform ein Raspberry Pi 5 auserkoren, der sowohl die Strom- als auch die Konnektivitätsproblematik löst.
Durch das Wechseln der Plattform (x86→ARM) musste aber extra Docker Builds für ARM erstellt werden, da einige Images Pakete enthielten, welche auf ARM-basierten Systemen nicht ordnungsgemäß liefen.
Aufgrund der eigentlichen Zielplattform (Router) wird per default bei der Installation die root-Partition nur etwas über 100 Megabyte groß erstellt. Da aber zeitgleich noch zusätzliche Pakete aus dem Repository installiert werden müssen, ist es von Nöten, die Partition zu vergrößern. Dabei gibt es leider einen Bug, welche das Offset der reservierten Blöcke falsch anlegt, wodurch das resizing nicht funktioniert (siehe Github Issue). Nach der Behandlung mit dem verlinkten Befehl kann die Größe der Partition korrekt angepasst werden. Allerdings ändert sich dadurch die UUID, weswegen der Bootvorgang fehl schlug → UUID gegen /dev/mmcblk0p2 austauschen und auch dieses Problem ist gelöst.
Nachdem einige Pakete nachinstalliert worden sind (dockerd, curl, docker-compose, git-http, git, jq, ack, bash), müssen für WebRTC und eduMEET lokale Zertifikate bzw. die fullchain erstellt werden, da die eingebaute certbot-Variante (über Letsencrypt) nicht anwendbar ist.
Per run-first.sh-Skript wird bei eduMEET die initiale Installation vorgenommen. Beim Builden der Container aus den Images ist darauf zu achten, dass in der .env Datei der TAG Parameter auf das korrespondierende ARM-Docker Repository gesetzt wird, da sonst standardmäßig die x86 Variante verwendet wird.
Die Konfiguration von eduMEET auf OpenWRT umfasst im wesentlichen das Anpassen von drei Dateien (Pfad in Abhänigkeit der gewählten Installation, hier /opt/edumeet/):
- /opt/edumeet/proxy/nginx.conf.template
- /opt/edumeet/.env
- /opt/edumeet/docker-compose.yml
In der nginx.conf muss der Pfad zu den self-signed Zertifikaten, in der .env Datei - wie bereits - erwähnt der TAG und in der docker-compose.yml der Pfad zu den Volumes der Zertifikate im Proxy Service angepasst werden. Ferner sollte der certbot-Service komplett rausgenommen werden, da er nicht benötigt wird.
Nachdem die Konfiguration des Dienstes abgeschlossen ist, muss OpenWRT per uci-Befehlen noch vom "DHCP Client-" in den "DHCP Host"-Modus versetzt werden, sodass mobile Endgeräte sich mit dem lokalen Wi-Fi verbinden können und auch eine IP-Adresse per DHCP erhalten.
Aus Einfachheitsgründen wurde darauf verzichtet, komplexe Firewallregeln zu implementieren, welche die Sicherheit des Systems erhöht hätten. Das war durch die Rahmenbedingungen schlicht nicht notwendig und wurde daher so konfiguriert, dass alle Packets aus alles Richtungen immer akzeptiert bzw. geforwarded wurden und niemals verworfen.
Ein Hinweis: der Docker Daemon und die LuCi Weboberfläche zum Konfigurieren von OpenWRT, welche die Client-Anfragen auf Port 80 bzw. 443 entgegen nehmen, können in der Standardkonfiguration nicht parallel laufen, weil nur einer der beiden Dienste den Port an sich binden kann. Entweder man ändert die Ports für den jeweiligen Dienst oder man wechselt zwischen ihnen hin und her.
Wenn man weiss was getan werden muss, dauert die Installation und Konfiguration des Systems ein bis maximal zwei Stunden.
Ergebnisse & Erfahrungen
Es war uns möglich, auf dem Raspberry Pi 5 sowohl OpenWRT korrekt zu konfigurieren als auch eine eduMEET Instanz zu installieren, sodass Clients über den Server verbunden konferieren können.
Tests ergaben, dass drei mobilen Clients (zwei Lenovo Laptops, ein Apple Macbook Pro) eine qualitativ hochwertige Videokonferenz ohne Einschränkungen abhalten konnten bzw. sie faktisch nicht von "normalen Instanzen" unterscheidbar war. Sowohl die Videoqualität als auch die Audioqualität in Hinblick auf Latenz und Auflösung war hervorragend.
Der Stromverbrauch des Raspberry Pis lag bei der Benutzung bei ca. 3 Watt, was mit einer 25.000 mAh Powerbank (in unserem Fall eine Anker 165W) eine Betriebszeit von ungefähr einem Tag oder 24 Stunden bedeutet.
Diskussion
Mit den Ergebnissen aus dem vorherigen Kapitel kann die eingangs gestellte Forschungsfrage mit einem klaren "Ja" beantwortet werden.
Die Limitationen dieses Setups liegen zunächst einmal in den verbauten Komponenten: Bei direktem Sichtkontakt ist die Videokonferenz bis zu einer Distanz von 65 Metern nicht bzw. nicht wahrnehmbar beeinträchtigt. Bis 90 Metern ist die Rückrichtung, also von Laptop zu RPi beeinträchtigt. Der Laptop hat es also nicht geschafft, die Sendeleistung aufzubringen, um den Server mit Audio und Video zu versorgen, was sich darin geäussert hat, dass der Laptop noch Daten von den restlichen Teilnehmern erhalten hat, jene aber nicht mehr vom Laptop. Ab 90 Metern sind sowohl Hin- als auch Rückrichtung abgebrochen und kein Senden und Empfangen von Daten war mehr möglich.
Diese Distanz verringert sich allerdings dramatisch schnell, sobald Hindernisse im Weg sind. Kurze Distanzen durch wenige Wände sind noch möglich aber bereits ab einer Distanz von 10-15 Metern durch massive Wände ist die Konnektivität so eingeschränkt, dass kein sinnvoller Datenaustausch mehr gewährleistet ist.
Für dieses Proof-of-Concept Projekt ist die Firewallkonfiguration sicherlich ausreichend, für einen Produktiveinsatz sollte aber Wert auf die korrekten Firewallregeln gesetzt werden.
Ausblick & Future Work
Ein interessanter Aspekt, den man zu einem anderen Zeitpunkt noch untersuchen könnte, wäre die Frage nach der Skalierbarkeit des Systems bezogen auf die Bandbreite. Wie viele Teilnehmer können einer Konferenz beitreten, bis es zu Einschränkungen bzw. Beeinträchtigungen des Dienstes kommt? Regelt eduMEET automatisch die Qualität und Datenrate über das SFU runter, wenn erkannt wird dass die Bandbreite nicht mehr groß genug ist? Aus dem erwähnten Lasttest wissen wir bereits das Limit bezogen auf CPU und RAM aber nicht in Bezug auf die Wi-Fi Konnektivität. Ein strukturierter Lasttest unter realistischen Bedingungen würde das klären.
Optimierungsmöglichkeiten kann man aus technischer Sicht leicht bei den Komponenten finden: eine externe Antenne würde die Sende- und Empfangsleistung erhöhen, um nicht die moderat dimensionierte verbaute Antenne des Raspberry Pi 5 benutzen zu müssen. Der Wechsel auf eine andere Plattform abseits des Raspberry Pi Ökosystems bietet wohl das größte Optimierungspotenzial, wenngleich man bedenken muss, dass die Anzahl der kompatiblen Komponenten recht klein ist (siehe Access-Point-Problematik). Eine Vorrichtung zum Ausrichten der Signale (ähnlich einer Richtfunkantenne) könnte die Reichweite auch erhöhen, wenn auch nur in die Server→Client-Richtung.
Fazit
Das Setup ist aus Sicht des VCC vielversprechend. Bei diversen "on-Site-Begehungen" - wie sie im VCC oft vorkommen - kann der Einsatzzweck noch erweitert werden, um beispielsweise mit wenig Aufwand und Equipment kurzerhand eine Videokonferenz an einem Ort abzuhalten, welcher nicht dafür vorgesehen ist oder um Equipment vor Ort zu testen, welches augenscheinlich den Geist aufgegeben hat.
Die Möglichkeit zu haben, mit sehr geringen Mitteln ein mobilen Audio und Video zu übertragen kann in Zukunft nur mehr Anwendungsfälle finden, die sich über die Zeit erst herausstellen werden.
Ferner lassen sich Szenarien kreieren, die für den Fall der Fälle eine schnelle Abhilfe bei Ausfall von Diensten geschaffen werden kann. Kostengünstig einen vorkonfigurierten Raspberry Pi auf Vorrat zu haben, den man in wenigen Minuten ans Strom- und Datennetz anschliessen kann um einigen wenigen 100 Teilnehmern eine Videokonferenzmöglichkeit zu schaffen, kann eine unvorhergesehene Lastspitze abfangen oder Teil einer Backupstrategie sein.
Um anderen Forschungsgruppen bei der Nachnutzung zu unterstützen, stellen wir die Konfigurationsdateien in den nachfolgenden Abschnitten bereit