Wirow

Reservierung - Moderation

• Einsatzzweck:
  • Moderierte SHG Arbeit
  • Die Teilnehmer möchten Informationen erhalten, Frage stellen.
  • Sie sind im deutschsprechenden Raum verteilt.
  • Sie haben keine große Erfahrung (Video-Konferenz).

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.

Handheben

• Auf sich aufmerksam machen
  • Die moderierende Person kann es wahrnehmen.
  • Eine Steuerung der Gespräche ist leichter möglich.
  • Ersatzweise kann einer echten Hand erhoben werden, ist allerdings nicht optimal.

Dieser Punkt gehört eigentlich zu den wichtigsten Moderationshilfen, wenn die Teilnehmer ungeschult sind.

Chat

• Warum Chat
  • Die Chatfunktionalität ist wichtig.
  • Informationen können an alle Teinehmer in Schriftform gegeben werden (Links, Mitteilungen, …)

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.

Bildschirm teilen

Anzeige von wichtige Informationen.

Durch Teilen des Bildschirmes (oder einem einzelnen Fenster) können Einige Informationen geteilt werden, allerdings als Bildmaterial.

Vorträge können leicht gehalten werden.

Auch wenn jeder, sowohl mit Jitsi-meet wie mit Wirow ihr Bildschirm teilen können, ist die Funktion, bei Wirow flexibler.

Darstellung

Was möchte man sehen:

• Bisherige Erfahrungen zeigen, dass die meisten Anwender alle anderen
• Teilnehmer auf das Bildschirm sehen möchten.
• Einige mögen eher, dass die sprechende Person den ganuen Bildschirm platz einnimmt.
• Wenige möchten sich auf eine einzelne Person konzentieren.

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.

MESH, MCU, SFU, …

• MESH (Direkte Verbindung zwischen den Browser)
  • Anzahl der Verbindungen je Rechner 2 * N * (N-1), die einzelne Systeme werden schnell überfordert!
• SFU (Selective Forwarding Unit), der WebRTC Server erhält die Streams jeden einzelnen Rechner und sendet diesen an den Client.
  • Sowohl Wirow wie Jitsi-meet verwenden eine SFU (Selective Forwarding Unit)
• MCU Wie SFU aber mit Verarbeitung der Streams (Umkodierung, Mischung, …)
  • Eine MCU wird, im private Umfeld eigentlich nicht verwendet, sie erfordert sehr leistungsfähige Server.
  • Vorteil jede Client muss nur je ein Video/Audio Ausgangsstream aufbauen.
  • BigBlueButton verwendet einer Software MCU.

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.

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.

SFU und Wirow

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.

ICE und Relay (TURN)

• Eine Verbindung zwischen 2 Systeme ist nicht immer gewährt
  • Daher ist es zwingend notwendig ein ICE Server, mit der Fähigkeit ein TURN Server zu installieren.

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.

Wie funktioniert STUN mit WebRTC

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:

• Externe IP-Adresse deren Erreichbarkeit: host, srflx, prflx. relay
  • Host: Adresse ist öffentlich oder im selben LAN.
  • Srflx: NAT, Ports werden nicht verändert.
  • Rrflx: NAT, Ports werden verändert.
  • Relay: Die Verbindung muss über ein Relay stattfinden. Administratoren. Hersteller oder Anbieter haben eine tolle Arbeit geleistet!

WebbRTC und IPv6

• Auf den Clients müssen temporäre IPv6 Adressen vorhanden sein, sonst werden kein IPv6 Kandidaten über das stun Protokoll publiziert.
• Es ist möglich ein eigenen WebRTC Server hinter ein CG-NAT Anschluss zu betreiben, wenn die andere Clients über IPv6 Adressen verfügen, sollte es problemlos funktionieren.

Verschlüssellung der Übertragung

Dtls ist, für WebRTC, eigentlich Pflicht und wird von Wirow grundsätzlich verwendet, bei Jitsi-Meet muss es offenbar eiongeschaltet werden!

Wirow Konfiguration

[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 = no

Dies 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.

Übertragungsrate

Was kann erwartet werden

• CPU

  Virtual Server 2 VCore Prozessoren, 2 GB RAM.

  CPU Verbrauch 1 Client < 02 % (1,3)

  CPU Verbrauch 2 Client < 04 % (2,6 - 3,7)

  CPU Verbrauch 3 Client < 07 % (5,3 - 6,7)

  CPU Verbrauch 4 Client < 09 % (7,3 - 8,6)

  CPU Verbrauch 5 Client < 10 % (7,0 - 9,7)

• Bandbreite

  Bis zu 400 Mbps.

  Bandbreite je Client, ca 300 KBps - 2,4 KBps.

  Dies scheint der limitierende Faktor zu sein (11 - 30 Clients).

• RAM der Verbrauch an RAM war sehr gering.

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.

Tests Wirow und Jitsi-Meet - Ergebnisse

• Die Verbindung über Wirow lief ein wenig besser, auf beide PC wurden die Videostreams übertragen. Mit Jisi-Meet war am Rechner der über Freifunk angemeldet das Bild vom “Heim Notebook” nicht immer zu sehen!
• Bei Verbindungsabbruch fordert Jitsi-Meet, sofern ein Passwort gesetzt ist, erneut die Eingabe der Logindaten.
  Wirow ist hier gutmütiger das Neuladen der Fenster führt direkt zum Meeting,
  • Das automatisches Wiederverbinden von Wirow, mit den alte Daten kann manchmal zu Nebeneffekte führen.

Audio Konfiguration

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.

Umstellen der Audioeingang

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.

Umstellen der Videoeingang

Es reicht aus das entsprechende Fenster, in dem Fall VLC zu teilen.

• Mit die Tastenkombination [Strg]+[h] können Menü und Steuerungselemente ausgeblendet werden.
• Unter Zuhilfenahme von devilspie2 (Siehe Paketmanagement) kann die Windowsdekoration eliminiert und auch die Größe des VLC Fenster gesetzt werden.