DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

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

Nextcloud Talk Logo

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.

Update-Historie (letztes Update: 28.07.2020)
  • 28.07.2020:
    • Empfehlung für Ubuntu Server 20.04, Hinweise für ältere Versionen ergänzt.
  • 14.07.2020:
    • STUN-Server zur Janus-Konfiguration hinzugefügt.

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.

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:

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:

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:

Unter Debian kann man hier eine aktuelle Version des Paketes herunter laden: http://ftp.de.debian.org/debian/pool/main/libs/libsrtp2/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:

Nach ein paar Augenblicken sollte der Build durchgelaufen sein.

Anschließend muss die Konfigurations-Datei angepasst werden:

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 angegeben, so dass nur diese auf den Signaling Server zugreifen kann: allowed = nextcloud.meinedomain.de
    • Der Secret-Key für Nextcloud wird hier ebenfalls angegeben (s.o.): secret = <Nextcloud Secret Key>
  • Sektion „mcu“:
    • Hier wird die Verbindung zum Websocket von Janus festgelegt: 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

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

Janus

Die Installation erfolgt hier über einen Befehl:

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

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

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

Das Interface wird dabei auf „lo“ gesetzt:

Das gleiche wird auch für den Websocket gemacht:

NATS

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

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:

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.

Nach einem Neustart von nginx ist dieser Teil auch abgeschlossen:

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:

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

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:

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:

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

Folgendes ist hier einzutragen:

Der Dienst wird im System registriert und aktiviert:

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:

Hinterlegen des Signaling Servers in der Nextcloud Talk Konfiguration

Hinterlegen des Signaling Servers in der Nextcloud Talk Konfiguration

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:

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

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

Der Service ist dann noch neu zu starten:

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

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

Benchmark des Signaling Servers

Benchmark des Signaling Servers

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

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

Links

, , , , , , , , , , , ,

Kommentare: 26

  • Stefan sagt:

    Danke, sehr gute Anleitung!!

    Ich pflege hier https://gitlab.com/packaging/nextcloud-spreed-signaling/ fertige Pakete für das HPB und hier https://gitlab.com/packaging/janus auch noch aktuellere Janus Backports (inkl. der aktuelleren srtp libraries).

    • Jan sagt:

      Hi Stefan,

      danke für den Hinweis. Das sollte die Installation um einiges einfacher machen.
      Funktioniert die Docker-Variante schnell und problemlos?

      Gruß,
      Jan

  • Jakob sagt:

    Hallo Jan,
    vielen Dank, das ist eine tolle Anleitung.
    Ist es auch möglich den Signalisierungsserver direkt auf dem Nextcloud Server zu installieren?

    • Jan sagt:

      Hi Jakob,

      ja, dürfte kein Problem sein, da Janus usw. alles lokal läuft. Wichtig ist hier nur die Proxy-Konfiguration für die URL des Signaling Servers.

      Gruß,
      Jan

      • Tom sagt:

        D.h. man kann für den Signallingserver auch einen anderen Port als 443 nehmen (und das auch bei Nextcloud so eintragen),
        also z.B. signaling.tld.de:445

  • Marco sagt:

    Wenn ich für den Signalisierungsserver die subdomain sig.xxxx.de habe und der Signalisierungsserver auf der selben Machine wie die Nextcloud cloud.xxxx.de laufen lassen möchte, wie genau muss denn dann die Proxy Konfiguration für die URL aussehen?

    Gruß
    Marco

    • Jan sagt:

      Hi Marco,

      in dem Fall kannst du das gut trennen, indem du einen vHost pro Domain nimmst.
      Auslagern würde ich dann nur allgemeine Einstellungen (SSL, Header), die du dann per include in beiden vHosts einbinden kannst.

      Gruß,
      Jan

      • Marco sagt:

        Hi Jan,

        Vielen Dank. Hab ich hinbekommen.
        Wenn ich nun meinen Signalingserver in Nextcloud mit https://signal.xxxx.de eintrage, meldet Nextcloud OK: Laufende Version: 3d73ab48dbdcf956808498cefed3f748d3d8fe77, Beim Verbindungsaufbau bekomme ich allerdings folgende Fehlermeldung: Fehler beim Aufbau der Signalisierungsverbindung. Trage ich ws://signal.xxxx.de ein, lautet die Fehlermeldung: Der Aufbau der Signalisierungsverbindung dauert länger als erwartet. Eine Virbindunk kommt in beiden Fällen nicht zustande.

        Gruß
        Marco

  • Eine gute Anleitung – sowohl technisch als auch optisch. Wieder einmal tolle Arbeit, dankeschön!

    Den Test am Ende kannte ich so noch gar nicht, das muss ich nachher einmal ausprobieren, wenn Feierabend ist.

    • Jan sagt:

      Hi Lars,

      dieser Test prüft aber nur die Verarbeitung von 100 Clients lokal auf dem Signaling Server. Wenn hier 100 Clients bedient werden können, heißt dies aber nicht auch automatisch, dass NC Talk 100 Konferenz-Teilnehmer verkraftet. Dies ist von sehr viel mehr Faktoren abhängig (CPU/RAM, Bandbreite Client- und Server-seitig, etc.).
      Aber zumindest kann man mit dem kurzen Test verifizieren, ob der Signaling Server prinzipiell läuft.

      Gruß,
      Jan

  • Stefan sagt:

    Hallo Jan,
    kurze Frage zu Deiner Super-Anleitung. Bekomme beim Testen die Meldung: „Could not initialize janus MCU at ws://127.0.0.1:8188 (dial tcp 127.0.0.1:8188: connect: connection refused)“ und stehe da etwas auf dem Schlauch. in der websocket conf steht der Port zwar drinnen aber muss ich da noch intern etwas öffnen oder so?
    Habe allerdigns Apache 2 im Einsatz und die Config so übernommen wie sie auf der github Seite von https://github.com/strukturag/nextcloud-spreed-signaling steht.
    Fehlt da was oder hast Du Ideen?

    Gruß
    Stefan

    • Jan sagt:

      Hi Stefan,

      ich denke mal, dass Janus hier ein Problem hat und ggf. gar nicht läuft (Kontrolle mit „service janus status“). Der nächste Schritt wäre dann ein Blick in die Logs (erst Janus, dann nginx/Apache, dann Singnaling Server).

      Gruß,
      Jan

  • Steffen sagt:

    Hallo Jan,

    danke für Deine Anleitungen. Ich orientiere mich immer gern an dem, was Du hier an Anleitungen machst.

    Ich habe die Anleitung heute für meinen Webserver unter Ubuntu 18.04 versucht umzusetzen. Das klappt leider gar nicht. Trotz aller Bemühungen bekomme ich das Ganze einfach nicht zum Laufen. Ich denke das die Janus-Version (0.2.6) unter Ubuntu 18.04 einfach zu alt ist. Die Probleme fingen schon damit an, dass die *.jcfg-Dateien in der alten Version noch *.cfg-Dateien sind. Das aber nur am Rande.
    Die Dienste Janus und Signaling können zwar beide gestartet werden und laufen dann auch anscheinend als „active“. Zumindest gibt dies der Status an. Aber es lässt sich nicht nutzen, weder von intern noch über extern. Ich denke Janus müsste mit einer neueren oder der neusten Version für Ubuntu 18.04 im Vorfeld selbst kompiliert werden, damit das Ganze lauffähig ist.
    Hauptproblem scheint zu sein, dass unter der alten Janus Version „Could not create janus MCU at ws://0.0.0.0:8188: Data channels are not supported“ kommt. Wobei 0.0.0.0 schon ein Workaround ist, da in alten Janus Versionen 127.0.0.1 oder localhost noch nicht funktioniert haben soll. Es geht mit nichts davon.

    Auf einem Ubuntu 20.04 Testserver läuft das Ganze perfekt und sofort.

    Was ich damit sagen will, vielleicht hast Du für Ubuntu 18.04 Nutzer einen Tipp, wie das Ganze funktionieren kann oder einen Hinweis darauf, dass die Anleitung unter 18.04 nicht funktioniert.

    Grüße
    Steffen

    • Jan sagt:

      Hi Steffen,

      ja, das ist mir auch schon aufgefallen, dass es unter 18.04 Probleme gibt. Wenn man nicht selbst kompilieren will, dann am besten die Backports aus einem der ersten Kommentare unter diesem Artikel hier nutzen.
      Ich werde den Artikel aber noch nachbessern und einen deutlichen Hinweis anbringen, dass man hierfür 20.04 nutzen sollte.

      Gruß,
      Jan

      • Steffen sagt:

        Hallo Jan,

        kleiner Nachtrag zu meinem Hinweis. Mit dem Janus Backport von Stefan aus dem ersten Kommentar funktioniert es auch unter Ubuntu 18.04 perfekt. Es liegt definitiv an der alten Version von Janus aus den Standard-Repositories von Ubuntu 18.04.

        Einen kleinen Tipp habe ich noch. Falls es notwendig wird, den Vhost unter nginx zu testen, weil man doch etwas verändern musste, um den aktuellen Gegebenheiten des eigenen Systems Rechnung zu tragen oder weil man eine Fehlersuche betreiben möchte, geht dies über einen Browser mit https://signaling.meinedomain.de/standalone-signaling/api/v1/welcome oder über ssh mit curl -i https://signaling.meinedomain.de/standalone-signaling/api/v1/welcome
        Wenn die Welcome-Nachricht {„nextcloud-spreed-signaling“:“Welcome“,“version“:“***“} ausgegeben wird, funktioniert alles.

        Grüße
        Steffen

  • Marcel sagt:

    Hallo Jan,

    danke für deine Anleitung,
    habe jedoch das Problem das mir in der Talk-App angezeigt wird:
    „Fehler beim Aufbau der Signaling-Verbindung“

    Im Nextcloud-Ui lässt sich der Server ohne Probleme einbinden.

    Habe die Nextcloud, den Turnserver und den Signaling-Server auf einer einem Ubuntu 18.04 LTS mit Apache2 als Webserver installiert.

    Grüße Marcel

    Vielleicht hast du ja einen Tipp für mich wo ich noch nach einem Fehler schauen kann.

    • Jan sagt:

      Hi Marcel,

      wie hast du das dann bei Ubuntu 18.04 mit Janus gelöst, nutzt du Backports?
      Die Fehlermeldung der NC App sagt leider sehr wenig aus, da müsstest du denke ich mal in den Logs nach etwas aussagekräftigerem suchen.

      Gruß,
      Jan

      • Marcel sagt:

        Hallo Jan,

        Janus habe ich mit Backports installiert,
        der Signaling Server läuft auch soweit,
        der Performance Test ist auch ohne Probleme durgelaufen.

        Wo kann ich den die Logs finden?

        Grüße

        Marcel

        • Jan sagt:

          Hi Marcel,

          wenn der Performance-Test funktioniert, dann läuft der Signaling Server inkl. Janus. Weil das aber alles rein lokal installiert ist (localhost), vermute ich den Fehler „weiter vorne“, d.h. schau mal in die nginx-Logs (nginx veräußert den Signaling Server ja erst über die öffentliche IP/Domain), oder auch in die Nextcloud-Logs.
          Ansonsten: Läuft der coturn? Hier mal in den Logs checken, ob dieser beim Start korrekt hochgefahren wird. Wenn es z.B. ein Problem mit den Zertifikaten gibt, dann bringt coturn keine Fehlermeldung, sondern switcht einfach auf den HTTP-Port um. Dies fällt aber beim Start des Dienstes nicht auf.

          Gruß,
          Jan

          • Marcel sagt:

            Hallo Jan,

            konnte leider noch nicht alle Tipps durchgehen.

            Mir ist jedoch aufgefallen das mit der curl-Abfrage bei der Version nicht wie im Beispiel bei
            https://github.com/strukturag/nextcloud-spreed-signaling
            „version“:“1.0.0″
            sondern ein verschlüsselter Wert.
            z.B „9563c55b2cd94aa243793c12bac4737e737d562e“.

            Vielleicht kannst du damit etwas anfangen.

            Der Webserver ist im übrigen ein Apache2.

            Grüße

            Marcel

          • Jan sagt:

            Hi Marcel,

            ich denke, dass dieser „verschlüsselte Wert“ genau der selbe ist, wie unter den NC-Einstellungen zu Talk. Das hat sich bei NC 19 geändert, vorher wurde hier nichts angezeigt. Da der Request aber generell eine Antwort liefert (und keine Fehlermeldung/Fehlercode), sollte dies nicht die Ursache für deine Probleme sein.
            Bei meinen Instanzen ist dies übrigens genau so, habe das gerade mal getestet.

            Gruß,
            Jan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.