Mesh
Problematisch ist die DSL-Geschwindigkeit, manche Teilnehmer verfügen nur auf ein 16/1 MBps Vertragsmöglichkeit, dies reduziert die Verwendbarkeit des Mesh-Betrieb drastisch.
Ein WebRTC Konferenz und Webminar System
Das Kompilieren stelle sich nicht als eine einfache Sache, es werden viele Komponente, wie beispielsweise Mediasoup (ein Media-Server) eingebunden. Unter Fedora 35 gelang das Erzeugen des ausführbaren Programms, auf ein Ubuntu-System, wie von der Readme Datei, nah gelegt gibt es nicht wirklich, einige Abhängigkeiten sorgten dafür, dass notwendige Komponente aus der Repositories nicht installiert werden konnten.
Als Server diente eine VPS (Ionos) mit Debian. Damit konnte für das erste Wirow nicht ausgeführt werden, einiges ist auf Debian-basierten Systeme restlos veraltet, dies führte zu Fehlern (libc.so Inkompatibilität).
Mit patchelf konnten die entsprechende Libraries überarbeitet werden und aud das Debian System installiert werden (eigene Verzeichnis). Neuerzeugen Binaries mussten auch, nach der Erzeugung (per Script) gepatch werden. Das Kopieren und Ausführen auf den Server gelang dann.
Ein weitere Server aus Frankreich, es wird im universitäre Bereich verwendet.
Da eine Internationalisierung nicht vorhanden ist und einige kleinere Ungereimtheiten vorhanden sind scheidet Galène aus.
Je nach Einsatzzweck können die Anforderungen sehr unterschiedlich sein.
| Merkmal | Wirow | Jitsi | Kommentar |
|---|---|---|---|
| Raumreservierung | Ja | Nein | |
| Moderation | Nein | ? | Bei Jitsi-Meet wäre der erste Anwender automatisch Moderator! |
| Mediageräte aus | Nein | Ja | Nicht nur der Moderator kann alle Kameras und oder Mikrofone abschalten |
| Hand heben | Nein | Ja | Wenn die Signallaufzeit groß sind, muss das Wort explizit erteilt werden |
| Chat | Ja | Ja | |
| Bildschirm teilen | Ja | Ja | Unterschiedliche Philosophien |
| Darstellung umschalten | Ja | Ja | Unterschiedliche Vorgehensweise |
| Hintergrund Änderung | Nein | Ja | Unter Jitsimeet scheint es zu Probleme zu kommen |
Der Videoraum sollte nur von Menschen, die die URL kennen erreichbar sein, am besten ohne Login. Ein Gebrauch des Angebotes sollte, für Fremden untersagt sein (Ressourcenverbrauch).
Damit solch ein Video Treffen gelingt, die Teilnehmer sich gegenseitig stören ist eine Moderation angebracht. Da die Laufzeiten recht groß werden könnnen, ist ein geregelten Ablauf des Treffens möglicherweise erschwert. Jemanden spricht, legt eine kurze Pause ein, ein andere nutzt die Gelegenheit umd das Wort zu nehmen und schon herrscht Chaos. Eine Moderation ist notwendig!
Als normale Anwender können die Kamera und oder Microphone der anderen Teilnehmer angeschaltet werden, die Moderartionsrechte bestehen offenbar nur im Setzen einen Passwort oder ähnliches.
Dieser Punkt gehört eigentlich zu den wichtigsten Moderationshilfen, wenn die Teilnehmer ungeschult sind.
Im Laufe einen Video-Treffen können weitere Informationen angeboten werden, vertiefende Literatur, Link auf ein Webseite, bei dem man weitere Informationen usw. beziehen kann. Eine nur Oral vermittelte Information ist sehr schnell vergessen, kann aber den Chat entnommen werden.
Wenn dass Handheben nicht vorhanden ist, könnte es als Ersatz verwendet werden.
Auch wenn jeder, sowohl mit Jitsi-meet wie mit Wirow ihr Bildschirm teilen können, ist die Funktion, bei Wirow flexibler.
Was möchte man sehen:
Jitsi-meet bittet, als erste Bildschirmdarstellung eine Ansicht in dem alle Teilnehmer in eine smalle Leiste am rechten Rand angezeigt wird. Der Anwender muss aktiv die Kacheldarstellung einstellen (falls er diese findet) oder ein der Teilnehmer anklicken um derjenige auf das gesamten Bildschirm (Browserfenster) zu bringen. Sollten nur 2 Teilnehmer sich unterhalten, ist der Gespächpartners auf das gesante Fenster abgebildet.
Wirow folgt ein anderen Ansatz, eine Kacheleinstellung ist das Default. Einzelne Teilnehmer können auf den vollen Platz durch klicken des entsprechenden Feld des übertragene Bild (Andeuten Symbol rechts, unten im jeweilige Kachel).
Beide Vorgehensweise dürfte als gleichwertig betrachtet werden, auch wenn jitsi-meet mehr (verwirrenden?) Einstellung bittet.
Die Bedienelemente (Mikrofon ein- / ausschalten, …) befinden sich bei Jitsi-meet mittig am unteren Rand des Fensters, werden jedoch ausgeblendet so, dass unerfahrene Anwender immer wieder damit Probleme haben.
Bei Wirow sind diesen Elementen in eine schmale vertikale Leiste am linken Fensterand angeordnet und werden immer angezeigt.
Einiges spricht für Wirow, auch wenn Verbesserungen von Nöte sind. Manches ist unter Jitsi-Meet besser durchdacht, Wirow hat dafür bei andere Punkten das bessere Konzept.
Einige Beigaben, die interessant sein könnten, ist dass eine digitale Tafel vorhanden ist (Whiteboard) und dass Dateien durch angemeldeten Gäste hoch- und heruntergeladen werden können.
Das Screensharing kann, gleichzeitig von jeden Teilnehmer vorgenommen werden. Bei Jitsi-meet wurde es nicht probiert. Jitsi-meet erlaubt es Hintergrund Bilder einzustellen, es ist sehr schön, scheint aber viele Resourcen zu verbrauchen und einiges zu hindern.
Jitsi-Meet verwendet sowohl das MESH wie das SFU Betrieb, die Umschaltung des Betriebes hängt vom Anzahl der Teilnehmer ab.
Wirow verwendet immer die SFU.
Problematisch ist die DSL-Geschwindigkeit, manche Teilnehmer verfügen nur auf ein 16/1 MBps Vertragsmöglichkeit, dies reduziert die Verwendbarkeit des Mesh-Betrieb drastisch.
Die Vorteile des SFU-Betriebs wiegen den Nachteile ab.
Die meisten Anschlüsse dürften mit IPv6 ausgestattet werden. Damit ist in solche Fällen eine direkte Verbindung zwischen SFU und Client möglich und ein Relay (TURN) erübrigt sich. Dies sollte sich positiv auf der Latenzzeit auswirken.
Die untersuchten Jitsi-Meet server erlaubten leider keine IPv6, im Test-Umfeld war es nicht unbedingt ein Nachteil, ein TURN Server war nicht konfiguriert, dennoch konnten auch Verbindungen zwischen ein IPv6 only und ein IPv4 only client aufgebaut werden. NAT wurde im Heim Router vorgenommen, damit kam es nicht zu zusätzliche Latenz. Falls ein CG-NAT Anschluss vorhanden ist oder die Video-Konferenz über ein Mobil-Funknetz stattfindet, ist eher mit Probleme zu rechnen. Unter Einsatz von IPv6 ist jeweils nur die Firewall zu überwinden, dies stellt kein Problem dar.
Stun wurde konzipiert um bidirektionalle Kommunikationen zwischen 2 Rechner, in dem da Firewall “durchgelöschert” und das NAT überwunden wird, zu ermöglichen. Dies gelingt nicht immer.
Die Lösung ist den Einsatz einem TURN Server. Falls der Aufbau der Verbindung mittels das STUN Protokoll nicht gelingt, meldet sich der Client an ein Relais und bezieht seine Daten, aktiv vom Relais.
Beim Einsatz von IPv6 Verbindungen, sollte ein STUN-Server ausreichend sein, dies setzt allerdings vorraus, dass das IPv6 Protokoll eine volle Unterstützung seitens des WebRTC Server vorhanden ist und dass alle Systeme eine IPv6 Verbindung aufgebaut haben. Der TURN Server muss zwischen IPv4 und IPv6 Systeme vermitteln.
Seitens Wirow wird für das Übertragen der Audio und Video Daten lediglich IPv4 zur Vergügung gestellt, falls die automatische Konfiguration vorgenommen wird. Der Aufwand Wirow auf gleichzeitigen IPv4/IPv6 Betrieb umzustellen ist jedoch sehr gering, es müssen lediglich 2 Parameter konfiguriert werden.
Wenn eine Verbindung zwischen ein oder mehrere Rechner nicht stattfinden kann, werden die Signale an ein TURN-Server gesendet und dieser hat die Aufgabe die Signale an den andere Rechner zu senden. Falls ein Anwender nur mit IPv4 and den anderen mit IPv6 unterwegs sind, erfolgt den Verkehr zwischen den Rechner auf jeden Fall über der TURN Relay. Manchen Mobilfunk Anbieter erschweren das Leben in dem eine direkte Verbindung zu einem weitere WebRTC Partner nicht möglich ist.
Durch das Relaybetrieb entstehen größere Latenzen (Verzögerungen) und die Verständigung kann darunter erheblich leiden. Ein gut erreichbare und nicht von vielen Menschen genutzte TURN Server sollte eingerichtet werden.
Die Browser bauen eine Verbindung zu Stun-Server teilen mit welche interne IP-Adressen vorhanden sind und auch die unterstützen Formate. Der Stun Server bewerte die Informationen und liefert einige Informationen zurück, darrunter:
Die Firewall und oder das NAT merken, dass eine Verbindung aufgebaut wird und erlauben dementsprechend der Empfang. Da beiden Partner es praktisch durchführen wird spätestens nach dem zweiten Telegramm die Kommunikation aufgebaut.
Dtls ist, für WebRTC, eigentlich Pflicht und wird von Wirow grundsätzlich verwendet, bei Jitsi-Meet muss es offenbar eiongeschaltet werden!
[main]
ip = ::
domain_name = meet.example.org
session_cookies_max_age = -1
[servers]
ice_servers = stun:stun.1und1.de:3478 stun:stun.t-online.de:3478
[rtc]
listen_announced_ips = 192.0.2.123 2001:dead:beef:cafe::1
[whiteboard]
public_available = noDies ist eine minimale Konfigurationsdatei, viel einfacher geht es nicht!
Die verschiedene Konfigurationsparameter sind in einen Beispieldatei beschrieben, einiges ist allerdings nicht optimal.
“expire_session_timeout_sec” und “expire_guest_session_timeout_sec” geben an wie lange eine Sitzung dauern darf.
“room_data_ttl_sec” gilt für das Whiteboard und bezeichnet die maqximaler Dauer der zwischengespreicherte Daten des Whiteboard. Ein Satz wird nach dem Schließen des “Whiteboard-Tabs” angelegt und wird nach der konfigurierte Zeit gelöscht. Wenn die Zeit zu kurz ist, besteht die Gefahr ein leeres Whiteboard zu finden.
| Codec | Bitrate kbps | Bemerkung |
|---|---|---|
| Opus | 6 bis 500 | Adaptiv |
| Codec | Bitrate Mbps |
|---|---|
| VP8 | 0,1 - 2 |
| Auflösung / Fps | Bitrate Mbps |
|---|---|
| 720 / 30 | 1 - 2 |
| 360 / 30 | 0.5 - 1 |
| 180 / 30 | 0.1 - 0.5 |
Die Qualität der Videobilder ist abhängig von der zur Verfügung stehende Bandbreite und der Einstellungen. Jitsi erlaubt es die Video in 4 Stufe zu übertragen, von keine Video bis maximale Qualität und größte Bandbreite. Ein DAU dürfte aber mit der Einstellung überfordert sein. Die vom Browser ausgewählte Auflösung basiert auf der ermittelte Bandbreite. Dies erfolgt nach ein “congestion” Protokoll.
WebRTC Applikationen stellen üblicherweise die Kontrahenten in ein 4:3 Format dar.
| Mögliche Formate | Std | C1 | C2 | C3 | C4 |
|---|---|---|---|---|---|
| 960*720 | * | * | |||
| 800*600 | * | ||||
| 640*480 | * | * | * | * | |
| 480*360 | * | * | |||
| 320*240 | * | * | * | ||
| 240*180 | * | ||||
| 160*120 | * | * |
Die Tabelle zeigt die im 4:3 angebotenen Formate für einer USB Webcam
Logitech C922 (C1) und die von 3 unterschiedliche Notebooks.
Mit das Kommando 4l2-ctl –list-formats-ext –device /dev/videoX kann die Liste der unterstütze Formate der Webcam gelistet werden. Damit, das richtige Format vom Browser gewählt wird, kann guvcview verwendet werden.
Std gibt die für WebRTC angegebenen bevorzugte Formate an, diese können möglicherweise vom Browser herunterskaliert werden (Simulcast mit VP8).
Formate wie beispielsweise 16:9 verschwenden nur Bandbreite und mit Rücksicht auf Teilnehmern, die nicht eine gute Internetverbindung haben, nicht genutzt werden.
Bei 11 Client mit jeweils Streams a 2,4 KBps würden wir ein gesamten Verkehr von rund 300 MBps, es bedeutet einem ausreichenden Abstand zur maximale Geschwindigkeit. Bei eine geringere Bandbreite des Systems von 300Kbs könnte über 30 Clients bedient werden.
Der Hersteller gibt als kleinste Voraussetzung 2 vCPU und 4GB RAM. Der Testserver hatte nur 2 GB RAM. Eine Begrenzung durch RAM Kapazität konnte nicht festgestellt werden, es lief praktisch kein weiteren Dienst, dafür waren die dynamischen Bibliotheken der Distribution, die zur Kompilierungszeit verwendet wurden (Fedora 36) installiert, so dass die vom Debianserver verwendete *.so Dateien nicht verwendet wurden.
Räume die von Anwender angelegt worden sind für das ersten privat, die andere Anwender haben kein Zutritt und sehen nicht diese Räume.
Wurde ein Anwender zu einem Meeting, der von ein anderen Anwender angelegt wurde, können sie, nachdem sie das Meeting besucht haben, das Meeting sehen und auch starten.
Vorteil von VP9 und noch mehr von AV1 ist die geringere notwendige Bandbreite, dafür sind die Anforderungen an der Hardware größer. Cisco gibt, für Webex mit AV1, dass der Client minimal 4 CPU-Kerne besitzen muss. VP9 muss auch explizit in Firefox konfiguriert werden (auch bevorzugte Codec).
Es gibt Möglichkeiten, für Wirow, mit externe Programme das Hintergrund zu verändern.
Falls Wirow mit eine Ersetzung/Verarbeitung des Hintergrunds versehen soll kann es beispielsweise mit backscrub und das Kernel Module v4l2loopback realisiert werden.
Die nötige Prozessorleistung ist allerdings hoch. Auf ein ältere Notebook mit Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz (4 Kerne) steigt die Processorauslastung von ca. 2 % auf bis 30 % (nur backscrub). Auf ein modernere Notebook mit 11th Gen Intel(R) Core(TM) i9-11950H @ 2.60GH (16 Kerne) steigt die CPU-Leistung um lediglich um ca. 5 %.
Auf das ältere Notebook ist das Leistungsvierbauch beim Einsetzen der Jitsi-meet Hintergrundveränderung ähnlich wie unter Einsatz von Wirow und backscrub.
Eine Übertragung von Video und Audio ist nicht vorgesehen, unter Linux kann es relativ leicht nachgerüstet werden.
pw-cli create-node adapter \
'{ factory.name=support.null-audio-sink node.name=VirtAudio
media.class=Audio/Duplex
object.linger=true
audio.position=[FL FR] }'Mit das Kommando pw-cli wird ein Object vom Typ Audio/Duplex angelegt, der Name ist in dem Fall VirtAudio. Das Object hat Eingängen die mit ein Mikrofon oder, in dem Fall, mit den Ausgang vom Mediaspieler VLC verbunden werden kann.
Unter Fedora XFCE ist damit die Verbindung VirtAudio mit der Eingang von Firefox verbunden wird mit der Lautstärke Einstellung des Mikrofons, VirtAudio zu wählen.
connectVLCToVirtAudio() {
list=$(pw-cli ls | grep alias | grep "VLC")
name=$(echo $list |sed 's/.*= "\(.*\):.*/\1/')
pw-link $1 "$name":output_FR VirtAudio:playback_FR
pw-link $1 "$name":output_FL VirtAudio:playback_FL
}Ein Aufruf der Funktion connectVLCToVirtAudio erlaubt es die Verbindung (Link) zu erzeugen oder zu entfernen, falls das Parameter -d eingegeben wurde.
Für die Mikrofone reicht es der Name des Mikrofone, beispielsweise für Mateview nachstehende Funktion auszuführen:
connectMateviewToVirtAudio() {
pw-link $1 MateView:capture_AUX0 VirtAudio:playback_FL
pw-link $1 MateView:capture_AUX1 VirtAudio:playback_FR
}Diese Lösung ist nicht benutzerfreundlich, erlaubt es in Ausnahmefälle ein Video zu Teilen.
Unter Windows oder MacOS sollten ähnliche Funktionalitäten vorhanden sein.
Es reicht aus das entsprechende Fenster, in dem Fall VLC zu teilen.