Nextcloud Talk mit eigenem Signaling-Server (High Performance Backend)

Nextcloud unterstützt mit Nextcloud Talk schon seit längerem Video-Konferenzen. Zu diesem Thema gab es hier im Blog bereits einen Artikel, wie man Nextcloud Talk mit eigenem TURN-Server (coturn) aufsetzen kann: Nextcloud Talk mit eigenem TURN-Server (coturn).

Leider hatte die Lösung einen Haken: Video-Chats mit mehr als vier bis fünf Personen waren hier nicht möglich. Nextcloud hat hier immer ab einer gewissen Teilnehmerzahl eine Warnung ausgegeben und man konnte darauf warten, dass die Verbindung irgendwann abbricht.

Dennoch gab es hier Potential nach oben: Mit dem sog. High Performance Backend für Nextcloud sind Video-Konferenzen mit sehr viel mehr Teilnehmern möglich. Hier benötigte man jedoch immer eine Nextcloud Enterprise-Subscription, die sich aber für die eigene Familien-Cloud preislich nicht gelohnt hat.

Nun hat sich Nextcloud mit seinem Partner Struktur AG dazu entschlossen, diese Vorteile an die Community weiterzugeben. Ab sofort ist der Teil des High Performance Backends, welche für Talk interessant ist, als Open Source verfügbar (siehe Nextcloud Blog). Genauer gesagt handelt es sich dabei um den sog. Signaling Server.

Die Installation ist aber nicht gerade trivial, so dass es hier bisher noch sehr wenige Anleitungen gibt. Daher soll dieser Artikel nun die Installation und Konfiguration des Signaling Servers und dessen Einbindung in Nextcloud beschreiben.

Voraussetzungen

Für die Installation eines eigenen Signaling Server gelten folgende Voraussetzungen:

Server

Die Hardware, auf dem der Signaling Server betrieben wird, sollte folgende Voraussetzungen erfüllen:

• 4 CPU Cores
• 16 GB RAM
• 1 GBit/s Netzwerk (Up und Down)

Auf schwächerer Hardware lässt sich der Signaling Server auch betreiben, hier kann es allerdings zu Einbußen bzgl. Performance und Teilnehmerzahl kommen.

Betriebssystem/Distribution

Ich verwende für diesen Artikel Ubuntu Server 20.04 LTS. Für ältere Versionen der Distribution (z.B. 18.04) ist das gezeigte Vorgehen so nicht umsetzbar, da die in den Paketquellen enthaltene Version von Janus zu alt ist. Hier muss man u.U. auf Backports von Janus aufsetzen.
Hinweis: Anfang 2022 wurde für die o.g. Backports der Support für Ubuntu 18.04 gestrichen. Hier kann man die benötigten Software-Pakete noch über launchpad beziehen.

Daher empfehle ich für einen Signaling Sever den einsatz vom Ubtuntu Server 20.04 LTS.

Software/Webserver/Domain

Für diesen Artikel setze ich ebenfalls folgendes Voraus:

• Eine bestehende Nextcloud Installation, siehe Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban.
• Eine bestehende Nextcloud Talk Installation inkl. coturn, siehe Nextcloud Talk mit eigenem TURN-Server (coturn).
• Eine Domain, auf die der Signaling Server betrieben werden kann.
• Eine Webserver-Konfiguration, die diese Domain bereits mit einem validen SSL-Zertifikat bedient. Siehe hierzu die Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx, RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung) und TLSv1.3 unter Ubuntu Server 18.04 LTS mit nginx.
• Eine bestehende Docker-Installation, siehe Docker auf Ubuntu Server.

Beispielhaft nutze ich in diesem Artikel die Domain signaling.meinedomain.de für den Signaling Server. Der verwendete TURN-Server (coturn) ist unter turn.meinedomain.de erreichbar. Nextcloud selbst hat die fiktive URL nextcloud.meinedomain.de.

Installation des Signaling Servers

Der Signaling Server (bzw. das sog. High Performance Backend für Nextcloud) besteht aus mehreren Komponenten:

• Dem Signaling Server selbst.
• Janus (WebRTC Server).
• NATS-Server.

Keys erzeugen

Für die Einrichtung der verschiedenen Komponenten werden unterschiedliche Keys benötigt, die wir hier im Vorfeld generieren können:

• Janus API-Key: openssl rand -base64 16
• Hash-Key: openssl rand -hex 16
• Block-Key: openssl rand -hex 16
• Nextcloud Secret Key: openssl rand -hex 16

Am besten man erstellt diese Keys und speichert sich diese irgendwo sicher ab.

Im weiteren Verlauf dieses Artikels wird auf diese Keys immer in spitzen Klammern verwiesen (z.B. <Janus API-Key>).

Daneben wird noch der Turn-Server-Key benötigt, der bei der Einrichtung von coturn vergeben wird (Variable static-auth-secret in der Datei /etc/turnserver.conf). Diesen sollte man nun auch nochmal raus suchen und mit den anderen Keys notieren.

libSRTP

Janus benötigt eine recht aktuelle Version des Pakets libsrtp2-1. Die in den Ubuntu Paketquellen enthaltene Version ist hier leider zu alt, so dass man hier eine manuelle Installation per DEB-Datei (aus dem kommenden Ubuntu-Release) vornehmen muss:

cd /tmp
wget http://de.archive.ubuntu.com/ubuntu/pool/universe/libs/libsrtp2/libsrtp2-1_2.3.0-4_amd64.deb
apt install /tmp/libsrtp2-1_2.3.0-4_amd64.deb
rm libsrtp2-1_2.3.0-4_amd64.deb

Signaling Server

Als nächstes kann ich schon der Signaling Server installiert werden. Hier gibt es keine fertigen Pakete, so dass man sich die Software selbst bauen muss:

apt install golang-go
cd /etc/
git clone https://github.com/strukturag/nextcloud-spreed-signaling.git
cd /etc/nextcloud-spreed-signaling
make build

Nach ein paar Augenblicken sollte der Build durchgelaufen sein.

Anschließend muss die Konfigurations-Datei angepasst werden:

cd /etc/nextcloud-spreed-signaling
cp server.conf.in server.conf
nano server.conf

Die Datei ist in verschiedene Sektionen aufgeteilt:

• Sektion „http“:
  • Hier wird die IP und der Port angegeben (diese Zeile muss daher einfach einkommentiert werden):

    listen = 127.0.0.1:8080

• Sektion „sessions“:
  • Angabe des Hash-Keys (s.o.):

    hashkey = <Hash-Key>

  • Angabe des Block-Keys (s.o.):

    blockkey = <Block-Key>

• Sektion „backend“:
  • Hier wird die URL der Cloud-Instanz als sog. Backend angegeben, so dass nur diese auf den Signaling Server zugreifen kann.
  • Dazu trägt man das Backend unter backends ein (der Name ist hier eigtnlich egal):

    backends = backend1

  • Weiter unten wird dieses Backend dann definiert:

    [backend1]
    # URL of the Nextcloud instance
    url = https://cloud.meinedomain.de
    
    # Shared secret for requests from and to the backend servers. This must be the
    # same value as configured in the Nextcloud admin ui.
    secret = <Nextcloud Secret Key>

  • Der Name des Backends ist hier „backend1“ (angegeben in eckigen Klammern) und muss dem Namen entsprechen, welcher weiter oben unter „backends“ angegeben wurde.
• Sektion „mcu“:
  • Hier wird die Verbindung zum Websocket von Janus festgelegt:

    type = janus
    url = ws://127.0.0.1:8188

• Sektion „turn“:
  • Hinzufügen des Janus API-Keys:

    apikey = <Janus API-Key>

  • Hinzufügen des Secret Keys vom TURN-Server (coturn):

    secret = <Turn-Server-Key>

  • Angabe der TURN-Server-URL:

    servers = turn:turn.meinedomain.de:5349?transport=udp,turn:turn.meinedomain.de:5349?transport=tcp

Hinweis: Die Variable allowall sollte aus Gründen der Sicherheit in dieser Konfoguration immer auf false gesetzt werden. Die einzige Ausnahme besteht zum Testen des Signaling Servers mittels des mitgelieferten Clients (siehe unten).

Bevor wir den Signaling Server nun starten können, müssen die restlichen Programme installiert werden.

Janus

Die Installation erfolgt hier über einen Befehl:

apt install janus

Anschließend müssen hier ebenfalls die Konfigurations-Dateien bearbeitet werden:

nano /etc/janus/janus.jcfg

Hier konfigurieren wir den STUN-Server (coturn), aktivieren die Option „Full Trickle“ und tragen den API-Key ein:

# ...
stun_server = "turn.meinedomain.de"
stun_port = 5349
# ...
full_trickle = true
# ...
turn_rest_api_key = "<Janus API-Key>"
# ...

Anschließend wird Janus so konfiguriert, dass es nur lokal (d.h. nicht über das Netzwerk) angesprochen werden kann:

nano /etc/janus/janus.transport.http.jcfg

Das Interface wird dabei auf „lo“ gesetzt:

# ...
interface = "lo" 
# ..

Das gleiche wird auch für den Websocket gemacht:

nano /etc/janus/janus.transport.websockets.jcfg

# ...
ws_interface = "lo"
# ...

NATS

Ebenfalls benötigt wird ein NATS-Server. Diesen Installieren wir der Einfachheit halber mittels Docker:

docker pull nats:latest
docker run --name=NATSSERVER -d -p 4222:4222 -ti --restart=always nats:latest

Hier muss weiter nichts konfiguriert werden, der Docker-Cointainer wird nur so angelegt, dass dieser beim Systemstart automatisch mit gestartet wird.

nginx

Nun muss nich dafür gesorgt werden, dass der Signaling Server durch nginx (oder einen anderen Webserver) erreichbar ist. Hierzu bearbeiten wir den virtuellen Host, der die Signaling-Domain bedient:

nano /etc/nginx/conf.d/signaling.meinedomain.de.conf

Hier werden nun der Upstream zu Signaling Server selbst und zwei location-Blöcke hinzugefügt. Die erweiterte Konfiguration des vHosts (z.B. SSL- bzw. Header-Konfiguration) wird an dieser Stelle nicht weiter behandelt.

upstream signaling {
    server 127.0.0.1:8080;
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name signaling.meinedomain.de;

        # SSL and header configuration omitted

        location /standalone-signaling/ {
                proxy_pass http://signaling/;
                proxy_http_version 1.1;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /standalone-signaling/spreed {
                proxy_pass http://signaling/spreed;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "Upgrade";
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}

Nach einem Neustart von nginx ist dieser Teil auch abgeschlossen:

service nginx restart

Starten des Signaling Servers

Nun kommt der spannende Teil: Wir starten zum ersten mal den Signaling Server!
Dazu wird erst einmal der Janus-Dienst neu gestartet:

service janus restart

Anschließend wird das Programm für einen ersten Test im Vordergrund aufgerufen:

cd /etc/nextcloud-spreed-signaling 
./bin/signaling --config server.conf

Hier wird u.U. sehr viel Output erzeugt, aber es sollten keine Fehler darunter zu finden sein.

Signaling Server als Systemdienst

Damit der Signaling Server nicht jedes Mal über die Konsole im Vordergrund gestartet werden muss, sollte dieser als Systemdienst installiert werden. Dazu stoppen wir erst einmal die Konsolen-Instanz.

Zunächst legen wir uns einen speziellen User für den Signaling Server an:

groupadd signaling
useradd --system --gid signaling --shell /usr/sbin/nologin --comment "Standalone signaling server for Nextcloud Talk." signaling

Anschließend wird die Konfigurationsdatei des Servers noch an einen anderen Ort kopiert (damit diese z.B. bei Update nicht überschrieben wird). Ebenso werden die entsprechenden Berechtigungen gesetzt:

mkdir -p /etc/signaling
cp server.conf /etc/signaling/server.conf
chmod 600 /etc/signaling/server.conf
chown signaling: /etc/signaling/server.conf

Nun editieren wir noch die Datei für den Systemdienst:

nano dist/init/systemd/signaling.service

Folgendes ist hier einzutragen:

[Unit]
Description=Nextcloud Talk signaling server

[Service]
ExecStart=/etc/nextcloud-spreed-signaling/bin/signaling --config /etc/signaling/server.conf
User=signaling
Group=signaling
Restart=on-failure

[Install]
WantedBy=multi-user.target

Der Dienst wird im System registriert und aktiviert:

cp dist/init/systemd/signaling.service /etc/systemd/system/signaling.service
systemctl enable signaling.service
systemctl start signaling.service

Anschließend wir der Signaling Server immer beim Systemstart mit geladen.

Einbinden des Signaling Servers in Nextcloud

Die Konsole packen wir erst einmal bei Seite und hinterlegen den neuen Signaling Server in der Nextcloud-Instanz. Dies geschieht unter Einstellungen > Talk. Ganz unten wird nun ein Signaling Server mit dem Plus-Zeichen hinzugefügt. Die Domain lautet hierfür https://signaling.meinedomain.de/standalone-signaling. Unter Gemeinsames Geheimnis wird nun der Nextcloud Secret Key hinterlegt, den wir ganz am Anfang erzeugt haben:

Die Option SSL Zertifikat überprüfen sollte hier aktiviert werden, wenn der Signaling Server über ein valides Zertifikat verfügt (z.B. Let’s Encrypt).

Anschließend sollte man Talk mit einer Videokonferenz testen. Dazu fragt man am besten einen anderen Cloud-User um Hilfe, oder testet dies einfach über eine Talk-Konferenz mit mehreren Endgeräten (z.B. PC, Notebook, Handy, etc.). Wenn hier Chat- und Videofunktionen gegeben sind, läuft der Signaling Server korrekt.

Benchmark/Test

Für den Signaling Server gibt es ebenfalls einen mitgelieferten Client, mit dem man den Server testen bzw. einen Benchmark ausführen kann.

Dazu muss der Client erst einmal gebaut werden:

cd /etc/nextcloud-spreed-signaling 
make client

Als nächstes muss die Server-Konfiguration noch geändert werden, damit Verbindungen mit den Client möglich sind:

nano /etc/signaling/server.conf

Hier muss in der Backend-Sektion die Variable allowall auf true gesetzt werden, damit keine Einschränkung auf bestimmte Domains besteht.

[backend]
# ...
allowall = true
# ...

Der Service ist dann noch neu zu starten:

service signaling restart

Nun kann mit den Client ein Benchmark durchgeführt werden:

cd /etc/nextcloud-spreed-signaling 
./bin/client -addr localhost:8080

Der Client baut daraufhin 100 Verbindungen zum Server auf und zeigt den Durchsatz an.

Wichtig ist hier v.a., dass sämtliche Verbindungen zu Stande kommen („All connections established“). Im Hintergrund sieht man, dass das System CPU-seitig ordentlich unter Last gesetzt wird.

Wichtig: Aus Sicherheitsgründen sollte die Variable allowall in der server.conf nach dem Test wieder auf false gesetzt werden (Neustart des Services nicht vergessen).

Update des Signaling Servers

Der Signaling Server wird kontinuierlich weiterentwickelt. Hier bietet es sich an, von Zeit zu Zeit ein Update durchzuführen.

Hierzu müssen einfach die Schritte zum Bauen des Servers wiederholt werden. Da wir die Konfigurationsdatei server.conf aus dem Verzeichnis des geclonten GitHub-Repositories ausgelagert haben, ist das ganze schnell erledigt:

service signaling stop
rm -r /etc/nextcloud-spreed-signaling
cd /etc/
git clone https://github.com/strukturag/nextcloud-spreed-signaling.git
cd /etc/nextcloud-spreed-signaling
make clean
make build
service signaling start

Mit folgendem Befehl kann dann noch kontrolliert werden, ob es beim Starten der neuen Version zu Fehlern/Meldungen gekommen ist:

service signaling status

Damit ist das Update dann auch schon durchgeführt.

Fazit

Mit einem eigenen Signaling Server ist es nun mit Nextcloud Talk endlich möglich, Konferenzen mit mehr als vier bis fünf Teilnehmern zu realisieren. Die Installation ist durchaus etwas aufwendiger, aber man hat anschließend eine gute (Video-)Chat-Lösung für die eigene Cloud.

Weiterführende Artikel

• Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
• Nextcloud Talk mit eigenem TURN-Server (coturn)
• Let’s Encrypt Zertifikate mit acme.sh und nginx
• RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung)
• TLSv1.3 unter Ubuntu Server 18.04 LTS mit nginx
• Docker auf Ubuntu Server

Links

• Signaling Server auf GitHub
• WebRTC (Wikipedia)

Ähnliche Artikel:

Nextcloud Talk mit eigenem TURN-Server (coturn) Jitsi Meet: Videokonferenz-System unter Ubuntu Server mit nginx Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban Matrix Synapse auf Ubuntu Server 20.04 LTS mit nginx, PostgreSQL und Let’s Encrypt