Kategorie: Open Source

Jitsi mit einem eigenen Open Source Streaming-Server betreiben


Jitsi Videokonferenzen funktionieren bei geeigneten Einstellungen mit über 100 Teilnehmern. Voraussetzung dafür ist, dass der erste Teilnehmer (der Veranstalter) dafür sorgt, dass der erste Teilnehmer (Moderator des Raumes) in den Settings “Everyone start muted”, “Everyone start hidden” und “Everyone follows me” anwählt. Dieses Szenario ist mit über 90 Teilnehmern erfolgreich getestet worden. Dann senden die Zuschauer nicht, können ihre Kamera und Mikrofon aber selber einschalten. Wenn das der Reihe nach getan wird, kann sehr einfach ermittelt werden, wie viele gleichzeitige Teilnehmer funktionieren, da der Teilnehmer mit der geringsten Bandbreite das Nadelöhr darstellt. Für reine Vorlesungsszenarien reicht das aber häufig schon aus.

Jitsi bietet aber auch die Möglichkeit externe Streaming Dienste anzubinden wie z.B, youtube oder einen eigenen nginx-Streamingserver. Wie das technisch realisiert werden kann, wird hier kurz beschrieben. Mir fehlt leider die Zeit das detailliert zu tun, da ich nicht mehr lange für die Uni Duisburg-Essen (UDE) arbeiten werde.

Die Komponente in Jitsi, die Aufzeichnungen und Stream ermöglicht heißt Jibri. https://github.com/jitsi/jibri

Bitte beachten, wenn mehrere Streams oder Aufzeichnung zur gleichen Zeit erfolgen sollen, benötigt man eine ganze Farm von Jibri-Maschinen, die mit einem unterschiedlichen „Nickname“ (siehe unten) konfiguriert werden müssen. Best Practice: Einen jibri konfigurieren und dann klonen. („Nickname“ anpassen nicht vergessen). Das schreit eigentlich nach dynamischen Instanzen, die per Docker oder ähnlich on the fly erzeugt werden können (hier nicht realisiert, nur als Idee angerissen).

Die Installation von Jibri funktioniert, anders als in der Anleitung angegeben, auch unter Ubuntu 18.4LTS (und sehr wahrscheinlich auch 20.4LTS). Wichtig ist aber, dass unbedingt Java8 konfiguriert wird:

$ sudo update-alternatives –config java

Achtung: Anders als in der Anleitung heißen die Jitsi-internen Virtual Hosts für die beiden Control-Kanäle (hier im Beispiel heißt der Jitsi-Server jitsi.zim.uni-due.de, dass muss individuell angepasst werden):

VirtualHost “auth.jitsi.zim.uni-due.de” (in /etc/prosody/conf.avail )

und

Component “internal.auth.jitsi.zim.uni-due.de” “muc”

Diese Namen müssen sich in der jibji config.json wiederspiegeln.

Unbedingt sind dann auch die Passwörter für die richtigen “virtuellen” Domänen (mit Domain meint Jitsi ein eigenes virtuelles Subdomain-Konzept, dass gar nichts mit echten Subdomains zu tun hat) zu setzen:

$ prosodyctl register jibri auth.jitsi.zim.uni-due.de *********

$ prosodyctl register recorder recorder.jitsi.zim.uni-due.de ********

(Mit den vergebenen Passwörtern im Config-File.)

Damit alle Komponenten zusammenspielen, muss auch die Jicofo-Konfiguration angepasst werden:

Man editiere dazu  /etc/jitsi/jicofo/sip-communicator.properties, um für die MUC (Multi User Conference, Jitsi basiert ja auf Jabber) die Jitsi-Stream-Brauerei (ein Bier für den Admin ;-) , also die Jibri-Worker bekannt zu  machen. Das muss mit dem Eintrag in der jibri’s config.json korrespondieren. Jicofo muss nach der Änderung neu gestartet werden.

org.jitsi.jicofo.jibri.BREWERY=JibriBrewery@internal.auth.yourdomain.com

muss bei unserem Beispiel

org.jitsi.jicofo.jibri.BREWERY=JibriBrewery@internal.auth.jitsi.zim.uni-due.de

sein!

Dann müssen noch in /usr/share/jitsi-meet/interface_config.js
die  TOOLBAR_BUTTONS für ‘livestreaming’ aktiviert werden.

Damit kann man dann z.B. schon zu youtube streamen, wenn man dort einen Streaming Account hat. Ich denke auch Wowza würde  mit dem /etc/hosts Hack gehen, ich hatte aber keine Zeit mehr das an der UDE auszuprobieren.

Damit die Jibri-Instanzen (Farm) nicht zu youtube sondern auf einen eigenen Server streamen, einfach in /etc/hosts für youtube.com die IP des Streamingservers einsetzen. D.h. die Rechner der Jibri-Farm halten den eigenen Streamingserver für youtube. Das hat den Vorteil, dass nichts im Jitsi-Quellcode geändert werden muss.

Im Beispiel an der UDE heißt der Streamingserver livestream.zim.uni-due.de .

Die  JIBRI Farm

Jeweils in /etc/jitsi/jibri/config.json die Nicknamen ändern.

“nickname”: “jibri-nickname2″

siehe: https://github.com/jitsi/jibri/issues/187 (ganz unten)

dann

$ sudo systemctl restart jibri

In den Logfiles sieht man dann, ob sich die Jibri-Instanzen ordentlich am jicofo anmelden.

Ein eigener Open-Source Streaming-Server

Der Streaming-Server, hier ganz in Open Source ist ein nginx mit selbst kompilierten Modul realisiert worden:

Prinzipiell bin ich nach dieser Anleitung vorgegangen

https://obsproject.com/forum/resources/how-to-set-up-your-own-private-rtmp-server-using-nginx.50/

Zum Bauen des nginx:

$ sudo apt-get install build-essential libpcre3 libpcre3-dev libssl-dev

$ wget http://nginx.org/download/nginx-1.15.1.tar.gz

Das RTMP-Modul:

$ wget https://github.com/sergey-dryabzhinsky/nginx-rtmp-module/archive/dev.zip

$ tar -zxvf nginx-1.15.1.tar.gz

$ unzip dev.zip

$ cd nginx-1.15.1

Build  nginx:

$ ./configure –with-http_ssl_module –add-module=../nginx-rtmp-module-dev

$ make

$ sudo make install

Als Ergänzung habe ich auch ein LDAP-Modul in den nginx einkompiliert:

hiermit:

https://github.com/kvspb/nginx-auth-ldap/blob/master/example.conf

mit

$ ./configure –with-http_ssl_module –add-module=../nginx-rtmp-module-dev  –add-module=../nginx_ldap_module/nginx-auth-ldap-master

$ make

$ sudo make install

Restart nginx:

$ sudo /usr/local/nginx/sbin/nginx -s stop

$ sudo /usr/local/nginx/sbin/nginx

Der nginx ist selbstkompiliert und lebt nach install unter /usr/local/nginx.

Gestartet wird er bei einem Reboot über einen cronjob:

@reboot root /usr/local/nginx/sbin/nginx

@reboot root /home/zim026/worker.sh 2>/dev/null (für die Playlist, siehe unten)

So wie er nun ist, kann man den Streaming-Server mit OBS-Studio oder Videolan per RTMP füttern und sich den Stream in einem vlc medial player anschauen.

Per OBS-Studio geht das so:

Ein Profil erzeugen mit:

Streaming Service: Custom
Server: rtmp://<your server ip>/live
Play Path/Stream Key: test

Und dann mit VLC (Videolan):

rtmp://<your server ip>/live/test

Das war der einfache Teil ;-).

Ich will aber mehr und den Stream im Browser per Javascript als HLS anschauen. Dazu habe ich folgendes getan:

Der Job /home/zim026/worker.sh (landet in der Crotab) erzeugt eine dynamische Übersichtsseite:

#!/bin/bash

#erst mal dauernd
while :
do
cd /tmp/hls
#alias proj=”cd /tmp/hls”

#jhome () {
#  cd /tmp/hls

#touch test.m3u8
#touch test2.m3u8
echo > /usr/local/nginx/html/playlist_cont.html
j=0
x=X
for i in *.m3u8 ; do
if [ "${i:0:1}" != "X" ]
then
echo “<a href=’https://livestream.zim.uni-due.de/stream5.html?s=$i’>Stream: [$i] <base target=”_parent”></a><br><br>” >> /usr/local/nginx/html/playlist_cont.html
fi
j=$(( $j + 1 ))
done

OUTPUT=`cat /usr/local/nginx/html/playlist_cont.html`
if echo “$OUTPUT” | grep -q “*”; then
echo “<p>Kein öffentlicher Livestream verfübar.</p>” >/usr/local/nginx/html/playlist_cont.html
j=$(( $j – 1 ))
fi

echo  “<p>”  >>/usr/local/nginx/html/playlist_cont.html
echo $j >> /usr/local/nginx/html/playlist_cont.html
echo ‘ aktive Streams.’  >> /usr/local/nginx/html/playlist_cont.html

#cat /usr/local/nginx/html/playlist_head.html /usr/local/nginx/html/playlist.txt /usr/local/nginx/html/playlist_footer.html > /usr/local/nginx/html/playlist.html

#} # fuer das cd

sleep 5
done

Optional können auch verborgene Streams erzeugt werden, denen im Namen ein “X” vorangestellt wird. Diese tauchen dann nicht auf der Playlist auf, sind aber, wie unten in der Anleitung beschreienen, aufrufbar.

Das passende stream5.html HTML dazu, dass die hls-Videos mit Hilfe des  videojs-contrib-hls.js javascript-Library abspielt:
Siehe auch (es klappt bei mir mit Version 7):
https://videojs.com/getting-started/

Da es Umbruchprobleme im Blog gibt, hier die Datei stream5.html auch zum Herunterladen.

<!DOCTYPE html>
<html>
<head>
<meta charset=utf-8 />
<title>ZIM Livestream</title>

<!–

Uses the latest versions of video.js and videojs-contrib-hls.

To use specific versions, please change the URLs to the form:

<link href=”video-js.css” rel=”stylesheet”>
<script src=”video.js”></script>
<script src=”videojs-contrib-hls.js”></script>

–>

<link href=”videojs7/video-js.css” rel=”stylesheet”>
<script src=”videojs7/video.min.js”></script>

</head>
<body>
<!– onload=”myFunction()”> –>
<img src=”UDE-logo-claim.svg” height=”100″><img src=”zim.jpg” height=”100″>
<h1>Livestream – Play Button klicken fC<r Start</h1>

<video id=”myvideo1″ controls preload=”auto”
width=”640″
height=”360″
data-setup=’{}’>

<!–   <source src=”https://livestream.zim.uni-due.de/hls/novideo.m3u8″ type=”applicat
–>

</video>
<br>
<a href=”playlist.html”>zurC<ck zur Live-Stream Auswahl</a>

<script>
window.onload = myFunction();

function myFunction(){

function getUrlParam(parameter, defaultvalue){
var urlparameter = defaultvalue;
if(window.location.href.indexOf(parameter) > -1){
urlparameter = getUrlVars()[parameter];
}
return urlparameter;
}

function getUrlVars() {
var vars = {};
var parts = window.location.href.replace(/[?&]+([^=&]+)=([^&]*)/gi, function(m,key,
vars[key] = value;
});
return vars;
}

var mystream = getUrlParam(‘s’,'Empty’);
var video = document.getElementById(‘myvideo1′);
/*alert(video);*/
var source = document.createElement(‘source’);
var streambase = ‘https://livestream.zim.uni-due.de/hls/’;
var streamurl = streambase.concat(mystream);
source.setAttribute(‘src’, streamurl);
source.setAttribute(‘type’, “application/x-mpegURL”);
video.appendChild(source);
/*let insertedNode = myvideo.insertBefore(insertedNode, source);*/
/*
video.play();
*/
}
</script>

</body>
</html>

Der Datei wird der Stream-URL durch die Playlist per Parameter übergeben und es wird ein bisschen mit Javascript gezaubert. Die Geschichte mit dem Parameter und der Playlist stammt von mir. Das kann man sicher mit einem beliebigen Framework viel eleganter machen, ist wollte allerdings eine rasche Lösung, da ich erwartet hatte, dass so etwas in Corona-Zeiten an der UDE benötigt wird.
Dieses ist meine fertige nginx.conf. Wer auf LDAP verzichten will, lässt die entsprechenden Konfigurationseintrage füe LDAP und das Modul einfach weg. Das Streaming geht auch ganz ohne LDAP. Das war nur ein Feature für die Uni Duisburg-Essen, um auch hochschulöffentliche Streams zu realisieren, die erst nach Anmeldung angeschaut werden können:

Da es Umbruchprobleme im Blog gibt, hier die Datei nginx.cfg auch zum Herunterladen.

#user  nobody;
worker_processes  10;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;

events {
worker_connections  2048;
}

http {
include       mime.types;
default_type  application/octet-stream;

#log_format  main  ‘$remote_addr – $remote_user [$time_local] “$request” ‘
#                  ‘$status $body_bytes_sent “$http_referer” ‘
#                  ‘”$http_user_agent” “$http_x_forwarded_for”‘;

#access_log  logs/access.log  main;

sendfile        on;
#tcp_nopush     on;

#keepalive_timeout  0;
keepalive_timeout  65;

#gzip  on;
#LDAP
ldap_server test1 {
url ldaps://ldap2.uni-duisburg-essen.de/ou=people,dc=uni-duisburg-essen,dc=de?uid?sub?(objectClass=inetOrgPerson);
binddn “cn=*******,ou=admin,dc=uni-duisburg-essen,dc=de”;
binddn_passwd “********”;
#group_attribute uniquemember;
group_attribute_is_dn on;
require valid_user;
}
#bis hier LDAP

server {
#listen 80;
listen 443 ssl;
#ssl on;
##  livestream.zim.uni-due.de-key.pem  livestream_cert.pem root@stream:/usr/local/nginx/certs
ssl_certificate /usr/local/nginx/certs/livestream_cert.pem;
ssl_certificate_key /usr/local/nginx/certs/livestream.zim.uni-due.de-key.pem;
server_name livestream.zim.uni-due.de;
#  server_name  localhost;
#LDAP
# auth_ldap “Anmeldung mit UDE-Unikennung/Passwort”;
# auth_ldap_servers test1;
#LDAP bis hier
#charset koi8-r;

#access_log  logs/host.access.log  main;

location / {
root   html;
index  index.html index.htm;
}

#error_page  404              /404.html;

# redirect server error pages to the static page /50x.html
#
error_page   500 502 503 504  /50x.html;
location = /50x.html {
root   html;
}

# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
#    proxy_pass   http://127.0.0.1;
#}

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
#    root           html;
#    fastcgi_pass   127.0.0.1:9000;
#    fastcgi_index  index.php;
#    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
#    include        fastcgi_params;
#}

# deny access to .htaccess files, if Apache’s document root
# concurs with nginx’s one
#
#location ~ /\.ht {
#    deny  all;
#}
# Andreas
location /hls/ {
root /tmp;
add_header Cache-Control no-cache;
}
# Andreas
location ~  /hls/U {
root /tmp;
add_header Cache-Control no-cache;
auth_ldap “Anmeldung mit UDE-Unikennung/Passwort”;
auth_ldap_servers test1;

}

}

# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
#    listen       8000;
#    listen       somename:8080;
#    server_name  somename  alias  another.alias;

#    location / {
#        root   html;
#        index  index.html index.htm;
#    }
#}

# HTTPS server
#
#server {
#    listen       443 ssl;
#    server_name  localhost;

#    ssl_certificate      cert.pem;
#    ssl_certificate_key  cert.key;

#    ssl_session_cache    shared:SSL:1m;
#    ssl_session_timeout  5m;

#    ssl_ciphers  HIGH:!aNULL:!MD5;
#    ssl_prefer_server_ciphers  on;

#    location / {
#        root   html;
#        index  index.html index.htm;
#    }
#}

}

rtmp {
server {
listen 1935;
chunk_size 4096;

application live2 {
live on;
record off;
#Andreas
meta copy;
wait_key on;
wait_video on;
idle_streams off;
hls on;
hls_path /tmp/hls;

}
}
}

Aus der Nutzeranleitung, die ich für die UDE erstellt habe:

Livestreams bzw. Webcasts
Wählen Sie zur Nutzung von Livestreams bzw. Webcasts auf dem Server
jitsi.zim.uni-due.de  (nicht auf jitsi.uni-due.de) die Funktion “start live stream” im Menue rechts unten (drei Punkte übereinander). Vergeben Sie dann im Dialog einen aussagekräftigen Namen für den Stream (ohne Leerzeichen). Der Stream wird nicht zu youtube gesendet, wie es im GUI angezeigt wird, sondern zum Server https://livestream.zim.uni-due.de . Wenn Sie ein großes “X” dem Stream-Namen voranstellen, wird dieser nicht in der Streamübersicht angezeigt. Ihre Studierenden können den Stream dann unter der URL

https://livestream.zim.uni-due.de/stream5.html?s=X<ihrstreamname>.m3u8

betrachten. Sie müssen Ihren Studierenden den URL dann per Mail oder in Moodle mitteilen. Bitte keine Leer- oder Sonderzeichen im Stream-Namen verwenden.
Wenn Sie dem Stream-Namen mit einem großen “U” beginnen, z.B. “Utest”, können nur NutzerInnnen der UDE erst nach Eingabe der Unikennung und dem Passwort den Stream ansehen.
Stoppen können Sie den Livetream ebenfalls über das Menue.
Der Livestream kann dann über die Seite livestream.zim.uni-due.de von vielen hundert Teilnehmern angeschaut werden,

Den Streamingserver livestream.zim.uni-due.de können Sie beispielsweise aber auch mit Hilfe von OBS-Studio produzierten Livestreams aus dem Uninetz auf den Port 1935 beschicken. Die beiden Optionen mit dem vorangestellten “X” bzw. “U” gelten dann ebenfalls.

Ich hoffe diese Zusammenstellung hilft dem einen oder anderen Admin weiter. Insbesondere für große Veranstaltungen kann das sehr hilfreich sein.


Die Jitsi-/BBB-/ZOOM-Story – oder Videokonferenzen in der Covid19 Pandemie an der Universität Duisburg-Essen


Als kurz vor dem Lockdown der DFN-Verein (Deutsches Forschungsnetz) ankündigte, dass der DFN-Conf Videokonferenzservice für alle Eventualitäten gerüstet sei und keine Kapazitätsprobleme zu erwarten sind, war Fachleuten im ZIM sofort klar, dass die Kapazitäten niemals ausreichen werden. Der DFN-Verein hat in Vor-Corona-Zeiten Kapazitäten von gerade einmal 2000 gleichzeitigen Videokonferenzteilnehmern bereitgehalten. Bei über 400 angeschlossenen Hochschulen kann so eine geringe Kapazität nicht ausreichen, wenn der Dienst plötzlich stark nachgefragt wird.

Leider hat aber das zentrale Videokonferenzangebot des DFN dafür gesorgt, dass lokal an vielen Hochschulen keine eigenen Lösungen mehr vorgehalten worden sind. An der UDE war das anders. Unterstützt von den Kolleginnen und Kollegen im Bereich Lerntechnologien habe ich mir vor einigen Jahren diverse freie Videokonferenzsoftwarelösungen (z.B. OpenMeetings, Palava, Jitsi-Desktop) angeschaut. Openmeetings, ein freier Adobe Connect Clone, war einige Zeit im Testbetrieb an der UDE und damals noch Flash-basiert. OpenMeetings , Jitsi und BigBlueButton (BBB) nutzen WebRTC als Basistechnologie. BBB hat ähnlich wie OpenMeeting früher Flash als Video- und Audio-Übertragungstechnik eingesetzt.

Es war zu Beginn des Lockdowns nicht klar, wie die Hochschullehre im folgendem Semester organisiert werden kann. Sollte der Weg gewählt werden alle Vorlesungen einfach per Videokonferenz anzubieten oder nur in eine Richtung ohne Rückkanal für die Studierenden ein Stream anzubieten oder besser auf ein Learning Content Management System wie Moodle gesetzt werden, um die Lehre asynchron zu realisieren? Im (aus IT-Sicht) Worst-Case-Szenario würde man alle Veranstaltungen einfach per Videokonferenz anbieten. Allerdings kommen Videokonferenzlösungen dann sehr schnell an Ihre Grenzen. Wenn Sie beispielweise eine Videokonferenz mit 100 Teilnehmern veranstalten möchten, muss jeder Teilnehmer 99 Videobilder gleichzeitig empfangen können, was private Internetzugänge von der benötigten Bandbreite nicht hergeben. Deshalb reduzieren alle Videokonferenz-Werkzeuge die Anzahl der maximal gleichzeitig übertragenen Streams.  Teilnehmerzahlen von über 1000 sind so gar nicht zu realisieren. Bei einem normalen synchronen Vorlesungsbetrieb an einer Universität mit über 40.000 Studierenden ist das technisch mit Inhouse-Lösungen zu Spitzenlastzeiten möglicherweise auch nicht zu stemmen. Da sich aber die Hochschule für einen asynchronen Lehrbetrieb mit Moodle entschieden hat, verteilt sich die benötigte Bandbreite über den ganzen Tag und Lastspitzen werden vermieden.

Wir im ZIM haben uns dazu entschieden, mehrgleisig auf die neuen Bedarfe zu reagieren. Einerseits haben wir sehr rasch einen Jitsi-Server für WebRTC-Videokonferenzen aufgesetzt und später Lizenzen für ZOOM-basierte Videokonferenzen in der Cloud beschafft. In der Fakultät Biologie hat Ken Dreger zeitgleich damit begonnen den WebRTC-Dienst BigBlueButton zu evaluieren. Dieser Dienst wurde später gemeinsam mit der Fakultät Biologie, der Wirtschaftsinformatik und dem ZIM auch hochschulweit in den Betrieb genommen. Ein spezieller BBB-Server für die Gremienarbeit, der für alle Teilnehmer eine Anmeldung mit der Unikennung erzwingt, wurde ebenfalls realisiert.

Bei der eingekauften proprietären Lösung ZOOM liegen die live Audio- und Video-Streams Prinzip bedingt beim Anbieter auf dem Vermittlungsserver unverschlüsselt vor. Um auch Konferenzen zu ermöglichen, in denen personenbezogene Daten oder anderweitig schützenswerte Inhalte ausgetauscht werden, wurde im ZIM auch ein sogenannter „on-premise“ ZOOM-Server installiert, bei dem alle Audio-und Videodaten unverschlüsselt nur auf einem Server in der Hochschule vorliegen. Um die Sammlung von Metadaten durch den Anbieter zu verhindern, ist nun auch eine völlig anonyme Anmeldung der Initiatoren einer Zoom-Videokonferenz im ZIM realisiert worden. Wenn allerdings auch nur ein Teilnehmer per Telefon oder WebRTC an einer Konferenz auf dem ZOOM-on-premise-Server teilnimmt, werden im ersten Fall Audio und im zweiten Fall auch das Video der Konferenz über ZOOM-Server in die Cloud geleitet. Die Daten, die Sie darüber hinaus in Ihrem ZOOM-Profil pflegen und auch die Aufzeichnungen dort, verantworten Sie aber als Lehrende selber.

WebRTC (Web Real Time Conferencing)

WebRTC, also Echtzeitkonferenzen im Browser sind heute in allen aktuellen Browsern nutzbar, selbst der Microsoft Browser Edge und Apples Safari beherrschen das mittlerweile gut. Dazu ist in den Webbrowsern Programmcode integriert, der auf die Webcam und das Audio-Interface (Mikrofon/Lautsprecher) zugreift, Ton und Video komprimiert (kodiert) und empfangene Daten dekomprimiert (dekodiert).  Diese Softwarekomponente wird CODEC (von coding und decoding) genannt. Wegen der im WebRTC-Standard notwendigen Interoperabilität der verschiedenen Browser muss die das W3C-Standartisierungsgremium (World Wide Web Consortium) auf CODECs einigen, die von allen Browser-Herstellern unterstützt werden (VP8, H264 für Video und Opus, G711 PCMA und PCMU für Audio). Da die beiden führenden Browser mit einer Open Source-Lizenz entwickelt werden, müssen auch die verwendeten CODECs Open Source sein. Und hier zeigt sich der wesentliche Unterschied zu proprietärer Videokonferenz Software wie z.B. Zoom. Diese muss nicht mit anderer standardisierter Software zusammenarbeiten, ist nur für diesen einzigen Zweck geschrieben worden und kann auch hochwertige kommerzielle Closed Source CODECS einsetzen, die eine höhere Kompression ermöglichen. Insofern ist der Vergleich der Audio- und Video-Qualität von WebRTC basierten Lösungen mit proprietären, nicht interoperablen Lösungen müßig. WebRCT-basierte Videokonferenzen mit BBB und Jitsi werden an der UDE über Uni-eigene Server abgewickelt. Weder Metadaten (wer kommuniziert mit wem) noch Inhalte können auch dem über sichere HTTPS abgesicherten Transportweg abgehört werden. Eine echte Ende-zu-Ende Verschlüsselung kann Prinzip bedingt auf einfache Weise nun zwischen zwei Kommunikationspartnern realisiert werden. Jitsi bietet beispielsweise so eine Möglichkeit. Wenn Sie zu zweit eine Jitsi-Konferenz durchführen, werden weder Ton noch Bild über den Jitsi-Server der UDE geleitet. Sie kommunizieren dann direkt Ende-zu Ende verschlüsselt und kein Geheimdienst dieser Welt kann sie abhören, sofern sie Ihrem PC und dem installierten Betriebssystem vertrauen können.  Eine Ende-zu-Ende Verschlüsselung mit mehr als zwei Teilnehmern ist viel schwieriger zu realisieren, da dann beim Verbindungsaufbau ein geheimer Session-Schlüssel mit allen Teilnehmern ausgetauscht werden müssen, den der zentrale Server nicht mitbekommen darf.

Ein weiterer Vorteil der WebRTC-Dienste ist die einfache Integration in vorhandene Webdienste wie z.B. Moodle und Rocket-Chat.

In Webbrowsern sind Sicherheitsmechanismen eingebaut, die verhindern sollen, dass eine Browser-Nutzerin oder ein Nutzer heimlich beim Besuch einer Webseite abgehört wird. Deshalb fragen die Browser immer nach, ob der Zugriff auf Kamera, Mikrofon und gegebenenfalls den Desktop, falls etwas präsentiert werden soll, durch den Nutzer erlaubt wird. Die Freigabe wird für jeden Server einzeln gespeichert und kann auch widerrufen werden. Im Falle von BBB sind das aber 10 verschiedene Server auf die, je nach aktueller Last, verwiesen wird. Leider ist das für ungeübte Nutzer eine zusätzliche Fehlerquelle bei webbasierten Videokonferenzen. Übrigens unterstützt auch ZOOM den Zugang über WebRTC zu Videokonferenzen ohne Installation des ZOOM-Clients. Allerdings ist diese Funktion (möglicherweise beabsichtigt) etwas versteckt und funktioniert nicht so zuverlässig wie von Jitsi und BBB gewohnt.

WebRTC-Probleme mit Mikrofon, Kamera oder Netzwerkanbindung können Sie auf dieser Testseite ganz hervorragend eingrenzen: https://test.webrtc.org/

Beschränkte Internetzugänge

Alle hier beschriebe Dienste funktionieren nun auch über extrem limitierte Internetzugänge, wie z.B. dem Verwaltungsfirewall der UDE oder in NAT-Netzen mit privaten Internet-Adressen. Auch die von Providern gerne verkauften limitierten DSLite-Internetzugänge stellen kein Problem mehr dar. Sofern auch nur der Port 443 für HTTPS offen ist, lassen sich Jitsi und BBB nutzen. Ermöglicht wird das durch im ZIM betriebene STUN und TURN-Server, die bei solchen limitierten Zugängen für eine „Vermittlung“ zwischen Client und Server sorgen. Auf wenn diese „Vermittlung“ wegen einem beschränten Internetzugang beim Verbindungsaufbau benötigt wird, bleibt die oben erwähnte Ende-zu-Ende-Verschlüsselung bei Jitsi mit zwei Teilnehmern intakt.

Echtzeit Videokonferenz versus Live-Stream versus Stream einer Konserve

Häufig wird die Qualität einer Videokonferenz an Streaming-Angeboten für vorher aufgezeichnete und komprimierte  Videokonserven wie Netflix oder Youtube gemessen. Da bei einer Videokonferenz die Latenz höchsten 150 Millisekunden betragen darf, ist der technische Aufwand aber bei einer Konferenz ungleich höher als bei einem Live- oder Konserven-Stream.  Bei höheren Verzögerungen fallen sich die Teilnehmerinnen unabsichtlich ins Wort, weil sie von einer Sprechpause des Gegenübers ausgehen. Bei einem (Live) Stream ist es völlig egal, ob er erst nach 10 Sekunden beginnt und der CODEC die Zeit für eine verbesserte Kompression und für ein Puffern (Buffering) nutzen kann, welches Latenz und Jitter (Verzögerungen und ungleichmäßige Übertragung in Paketen) überbrücken kann. Insofern ist es für eine Streaming-Anwendung im Gegensatz zu einer Videokonferenz auch gleichgültig, ob LAN oder WLAN eingesetzt wird, wenn nur die verfügbare Bandbreite insgesamt ausreicht. Die Kompression über eine lange Pufferzeit spart viel Übertragungsbandbreite, weil der CODEC nur Blöcke im Bild neu übertragen muss, in denen sich etwas ändert. Der CODEC kann in einem langen Puffer auch Blöcke zwischenspeichern, was schnelle Bewegungen im Vordergrund bei wenig Veränderung im Hintergrund abfedert. Daher schaffen Streaming-Dienste es, eine höhere Videoqualität mit geringerem Bandbreitenbedarf zu übertragen, als es in Videokonferenzen möglich ist. Und hier wird bisher nur ein wirklicher Live-Stream mit einer Echtzeit-Videokonferenz verglichen. Wenn eine Quelle als Konserve vorliegt, kann mit speziellen CODECS vorher offline komprimiert werden, da der CODEC dann “alle Zeit der Welt” hat, um das Video vorab zu komprimieren. Hochkomprimierende offline-CODECS für Konserven benötigen dazu ein Vielfaches der Laufzeit des Videos und sind deshalb für Live-Anwendungen nicht geeignet. All das ist einem CODEC für Echtzeit-Videokonferenzen nur eingeschränkt oder im Fall der Konserve gar nicht möglich.

Welches Tool für welche Anwendung?

Für eine spontane kleine Videokonferenz oder selbstorganisierte Lerngruppen von Studierenden ohne große Organisation eignet sich besonders Jitsi, da gar keine Zugangsdaten eingegeben werden müssen und man sich den Raum, also die URL einfach ausdenken kann. Z.B. https://jitsi.uni-due.de/spontanestreffen funktioniert sofort und weltweit. Der erste Teilnehmer kann auch die Eingabe eines Passwortes erzwingen, so dass sichergestellt werden kann, dass der Nutzerkreis eines Raumes eingeschränkt wird. Ein spezieller Datensparmodus ermöglicht auch die Teilnahme ausschließlich per Audio, so dass notfalls auch ein sehr limitierter Internetzugang, beispielsweise ein stark volumenbeschränkter LTE-Zugang, ausreicht.  Für Android und IOS gibt es jeweils auch eine komfortable Jitsi-App. Auch ein Streaming-Server für automatisierte Streams ist im ZIM an Jitsi angebunden worden. In der aktuellen Jitsi-Version ist es auch möglich eine sehr große Teilnehmerzahl mit zunächst abgeschalteten Mikrofonen und Kameras beitreten zu lassen, wenn der Moderator (Initiator) dieses in den Einstellungen festlegt. Der Moderator ist aber auf die Disziplin der Teinehmer angewiesen. Schauen Sie sich für Details die Dokumentation auf den ZIM-Seiten zu Jitsi an. Für Konferenzen ab ca. 10 Teilnehmern nutzen Sie aber besser BBB, dass dem Moderator wesentlich mehr Möglichkeiten bietet.

Für sehr komfortable Konferenzen in BBB mit guter Präsentations- und Moderationsmöglichkeiten ist es erforderlich, dass zumindest die/der Einladende sich mit Unikennung und Passwort am BBB-Server anmeldet um einen Meeting-Raum zu erstellen. Die Berechtigung dazu muss vorher dazu vergeben werden, wenden Sie dafür an die Hotline des ZIM. Sowohl für Jitsi als auch BBB (Gremienserver) ist im ZIM eine Telefoneinwahl mit FreePBX (Asterisk) realisiert worden.

Über den Microsoft-Bundesvertrag haben Sie darüber hinaus auch die Möglichkeit kostenfrei MS-Teams zu nutzen. Dazu müssen sie aber als Einzelperson die Vertragsbedingungen von Microsoft akzeptieren und ein MS-Office365-Konto anlegen. Das ist allerdings kein Dienst des ZIM und wir können keinen Support oder eine Datensicherung dazu anbieten. Damit Studierende und Lehrende dort überhaupt zusammenarbeiten können, war eine Zusammenlegung der Tenents für Mitarbeiter und Studierende der UDE durch Kollegen im ZIM notwendig. Sie sind persönlich verantwortlich, wenn Sie in der Microsoft-Cloud dienstliche personenbezogene Daten speichern und verarbeiten. Bedenken Sie dabei die DSGVO und die vom EUGH „gekippte“ Privacy Shield Regelung. Aktuell hält ein Arbeitskreis der Datenschutzkonferenz  den rechtskonformen Einsatz von Microsoft 365 in öffentlichen Institutionen für unmöglich.

Auch der DFN-Conf-Dienst scheint nun wieder zuverlässig zu funktionieren. Ob er allerdings dem Semesterbeginn Stand hält, bleibt aber abzuwarten.

Den ZOOM-Cloud-Dienst können Sie für Lehre einsetzen, sofern Sie keine Datenschutzbedenken haben. Bei Dienstbesprechungen dürfen Sie ausschließlich Dienste einsetzen, die an der UDE betrieben werden, d.h. Jitsi, BBB oder ZOOM mit dem „on-premise“-Server. Für Gremiensitzungen empfehlen wir ausdrücklich den BBB-Gremienserver, da dort bei der Anmeldung jeder Teilnehmer mit Unikennung und Passwort authentifiziert wird.

Was alles schiefgehen kann – die drei Feinde der Videokonferenz:

  • Latenz und Jitter
    Wenn Sie am Teilnahmeort eine LAN-Verkabelung haben, nutzen Sie diese auch! Im WLAN haben Sie immer ein geteiltes Medium, daheim mit Nachbarn und Familienangehörigen an der Uni mit Kollegen und Studierenden, die unvermittelt und unabsichtlich für kurzfristige Verzögerungen beim Datentransfer sorgen. Selbst wenn Sie ganz allein einen WLAN-Router nutzen und wirklich Niemand mit einem Gerät in der Nähe ist, fangen Sie sich durch das WLAN eine vermeidbare zusätzliche Latenz (also Verzögerungen) ein. Sowohl bei der Telefonie als auch bei einer Videokonferenz akzeptieren Menschen eine Latenz von höchstens 150 Millisekunden. Bei höheren Verzögerungen fallen sich die Teilnehmerinnen unabsichtlich ins Wort, weil sie von einer Sprechpause des Gegenübers ausgehen. Schlimm wird es auch wenn Sie sich den WLAN Funkkanal teilen und Audio- und Video-Pakete unregelmäßig verzögert ankommen (Jitter), da dann Aussetzer in Ton und Bild vorkommen.
  • Rückkopplungen
    Benutzen Sie bei Videokonferenzen immer ein Headset oder zumindest einen Kopfhörer. Ansonsten kann es passieren, dass ihr Mikrofon den Ton aus Ihrem Lautsprecher aufnimmt und so ein Echo der aktuell Sprechenden erzeugt, was speziell für den Sprecher aber auch für alle Teilnehmerinnen sehr unangenehm ist. Im schlimmsten Fall erzeugen sie sogar einen unangenehmen Pfeifton, der sich immer weiter aufschaukelt. Moderne Videokonferenzsysteme versuchen solche Echos per Software zu unterdrückten, was aber nicht immer zuverlässig funktioniert. Auch eine schlechte Entkopplung von Mikrofon und Lautsprecher in einem minderwertigen Headset kann so eine Rückkopplung auslösen. Einige Bluetooth-Headsets vertragen sich nicht gut mit dem WAN-Chipsatz mancher Notebooks und können so für zusätzliche Latenz sorgen. Wenn Sie über kein Headset verfügen, schalten Sie Ihr Mikrofon immer ab, wenn Sie nicht selber sprechen.
  • Bandbreite Zuhause / der gebuchte Tarif und die Wirklichkeit
    Internet-Provider überbuchen ihre verfügbare Bandbreite, weil sie davon ausgehen, dass nicht alle ihre Kunden den Zugang gleichzeitig mit der gebuchten Maximalgeschwindigkeit nutzen. Deshalb können Sie nicht davon ausgehen, dass Ihnen wirklich die gebuchte Bandbreite immer zur Verfügung steht. Derzeit sind durch massive Homeoffice-Nutzung viele Internetprovider überlastet.  Unter unter https://www.uni-due.de/zim/speedtest/ können Sie testen, wie schnell Ihr Internetzugang wirklich ist.  Auch kurzfristige Verzögerungen und Jitter durch einen geteilten Zugang können Probleme verursachen. Ihre Internetverbindung ist immer der Flaschenhals, ganz selten der Server. Fast alle privaten Internetzugänge sind asynchron konfiguriert, d.h. die Daten von Ihrer Webcam bzw. Audio sind im Upstream (also von Ihnen aus zum Server) begrenzt. Vermeiden Sie die zeitgleiche Nutzung auch durch Familienmitglieder von anderen Internetdiensten während einer Videokonferenz. Wählen Sie immer eine geringe Videoauflösung, sofern die VC-Software das erlaubt. Die Tonübertragung benötigt sehr viel weniger Bandbreite als ein Videobild. Wenn es in einer größeren Konferenz Probleme gibt, sollte nur der aktuell Sprechende ein Videobild senden. Notfalls sollten Sie ganz auf Video zugunsten der Audiokonferenz verzichten.
    Alternativ können Sie Ihren Router daheim so konfigurieren, dass die Bandbreite fair aufgeteilt wird. Das funktioniert rudimentär mit jeder Fritz-Box  und ganz ausgezeichnet mit einem Router der mit der Open Source DD-WRT-Firmware (Einstellung unter NAT/QoS) betrieben wird. Die Fritzboxen priorisieren in der Default-Einstellung Dienste, die sie für Echtzeitanwendungen halten, allerdings liegen sie dabei häufig falsch. Beispielsweise wird der Dienst Wetransfer von Fritzboxen als Echtzeitanwendung priorisiert und killt bei einem großen Upload dann gerne gleichzeitig ablaufende Videokonferenzen. In der DD-WRT-Routerfirmware ist, im Gegensatz zu OpenWRT , die Priorisierung komfortabel konfigurierbar, ohne dass Software nachinstalliert werden muss. Möglichweise haben Sie noch ein älteres unterstütztes Gerät herumliegen, dass Sie für diesen Zweck weiterverwenden können.