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: 04.07.2021)
  • 04.07.2021:
    • Hinweise bzgl. Update des Signaling Servers hinzugefügt.
  • 03.09.2020:
    • Signaling-Konfiguration: Definition des Backends (neuere Versionen des Signaling Servers).
  • 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:

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:

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:

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.

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

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 cd /etc/nextcloud-spreed-signaling
cd /etc/
git clone https://github.com/strukturag/nextcloud-spreed-signaling.git
cd /etc/nextcloud-spreed-signaling
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

Links

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

Kommentare: 154

  • 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

        • Jan sagt:

          Hi Tom,

          ja, das sollte klappen. Komfortabler ist das mit einer zweiten (Sub-)Domain und diese dann ebenfalls auf Port 443 laufen zu lassen.

          Gruß,
          Jan

  • 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

  • Markus Lappe sagt:

    Mich würde ja mal Interessieren wie der Durchsatz jetzt ist hat da schon jemand Erfahrungen, meine Überlegung ist ich würde gerne über unseren Cabel Internetanschluss Red Business 1000/50 die Kiste bei mir in der VM aufbauen, Ist das sinnvoll oder sollte es doch nen Server von Netcup oder so sein. Ist eben schwer zu sagen wie viele Leute dadrüber laufen.

    Gruß

    Markus

    • Jan sagt:

      Hi Markus,

      empfohlen wird 1 GBit/s Up- und Down. Für kleinere Konferenzen reicht vermutlich schon eine geringere Bandbreite aus, aber hier fehlen mir noch die Erfahrungswerte.

      Gruß,
      Jan

  • Alexander Würmli, Björn Karlen sagt:

    Fehler bei Punkt nginx.
    Unbekannter Fehler beim Einbinden in Nextcloud. (Fehler 400 ohne ssl-Zertifikat.)
    Befehl: „nano /etc/nginx/conf.d/signaling.meinedomain.de“ sollte heissen:
    „nano /etc/nginx/conf.d/signaling.meinedomain.de.conf“
    –> Das Dokument „signaling.meinedomain.de.conf“ benötigt das „.conf“ am Ende, da nginx dieser Anhang sonst nicht bearbeitet.

  • Marco sagt:

    Vielen Dank für die tolle Anleitung, Jan!

    Grundsätzlich läuft das Ganze unter Ubuntu 20.04 in einer ESXi-VM, aber ich habe ein Problem mit den NATS im Docker. Mit dem Startbefehl läuft alles prima, aber wenn der Server bzw, die VM einen Reboot macht, läuft zwar der Docker-Container NATSSERVER, aber der Bind auf Port 4222 ist nicht da (taucht also auf dem Host mit netstat -plnt nicht auf). Dementsprechend läuft der Signaling-Server nicht, er meckert den fehlenden NATS-Server an.

    Wenn ich jetzt mit

    docker stop NATSSERVER
    docker rm NATSSERVER
    docker run –name=NATSSERVER -d -p 4222:4222 -ti –restart=always nats:latest

    wieder starte, ist alles fein.

    Hat jemand eine Idee, warum der Bind auf Port 4222 nicht funktioniert, wenn der Container nach einem Reboot automatisch startet?

    • Jan sagt:

      Hi Marco,

      das ist seltsam, der Befehl zum Starten den Containers bei Systemstart ist ja mit drin.
      Laufen denn andere Docker-Container beim Systemstart los, oder gibt es vielleicht ein allgemeines Problem mit Docker?

      Gruß,
      Jan

    • Jakob sagt:

      Hallo, ich habe dasselbe Problem.
      Bei mir reicht es, wenn ich den „docker run“ command nochmals ausführe

  • Andreas sagt:

    Hallo Jan,

    Vielen Dank für die tolle Anleitung!

    Leider habe ich das gleiche Problem wie Stefan.
    Could not initialize janus MCU at ws://127.0.0.1:8188 (dial tcp 127.0.0.1:8188: connect: connection refused)
    Janus läuft zwar, aber offenbar kann der port 8188 nicht geöffnet werden am loopback device lt. janus.log:
    Aug 26 23:14:02 someserver janus[321596]: Loading transport plugin ‚libjanus_websockets.so’…

    Aug 26 23:14:02 someserver janus[321596]: [libwebsockets][INFO] Creating Vhost ‚default‘ port 188, 2 protocols, IPv6 on
    Aug 26 23:14:02 someserver janus[321596]: [libwebsockets][DEBUG] interface lo vs lo (fam 17) ipv6 1
    Aug 26 23:14:02 someserver janus[321596]: [libwebsockets][DEBUG] interface eth0 vs lo (fam 17) ipv6 1
    Aug 26 23:14:02 someserver janus[321596]: [libwebsockets][DEBUG] interface docker0 vs lo (fam 17) ipv6 1
    Aug 26 23:14:02 someserver janus[321596]: [libwebsockets][DEBUG] interface veth195acf4 vs lo (fam 17) ipv6 1
    Aug 26 23:14:02 someserver janus[321596]: [libwebsockets][DEBUG] interface lo vs lo (fam 2) ipv6 1
    Aug 26 23:14:02 someserver janus[321596]: [libwebsockets][DEBUG] lws_interface_to_sa: uplevelling ipv4 bind to ipv6
    Aug 26 23:14:02 someserver janus[321596]: [libwebsockets][DEBUG] initial if check says 0
    Aug 26 23:14:02 someserver janus[321596]: [libwebsockets][ERR] ERROR opening socket
    Aug 26 23:14:02 someserver janus[321596]: [libwebsockets][INFO] lws_protocol_init

    Muss vielleicht ipv6 aktiviert sein am loopback device?

    Gruß
    Andreas

    • Jan sagt:

      Hi Andreas,

      es kann ja sein, dass der Port schon belegt ist. In diesem Fall einfach mal einen anderen Port für Janus verwenden (z.B. 8288) und in allen Configs entsprechend anpassen.
      Mit IPv6 sollte das nichts zu tun haben, angesprochen wird er ja eh mit IPv4.

      Gruß,
      Jan

  • Andreas sagt:

    Hi Jan,

    Nein Port war nicht belegt, auch andere Ports bzw. Interfaces haben nicht funktioniert.
    Habe ipv6 enabled auf dem System, dann hats geklappt.

    Gruß
    Andreas

    • Jan sagt:

      Hi Andreas,

      das ist echt erstaunlich, dass hier IPv6 benötigt wird. Habe dafür momentan noch keine Erklärung.
      Gehen denn die Verbindungen noch, die rein über IPv4 gehen?

      Gruß,
      Jan

  • Andreas sagt:

    Hi Jan,

    Der Port ist nun zwar offen, aber leider klappt das ganze immer noch nicht.

    curl -i http://127.0.0.1:8188/api/v1/welcome
    HTTP/1.1 403 Forbidden

    Im Log finde ich das dann auch
    [Sat Aug 29 23:13:13 2020] [libwebsockets][DEBUG] lwsi_set_state(0x7f7dd0000b60, 0x20000118)
    [Sat Aug 29 23:13:13 2020] Rejecting incoming HTTP request on WebSockets endpoint
    [Sat Aug 29 23:13:13 2020] [libwebsockets][INFO] lws_issue_raw: ssl_capable_write (245) says 245
    [Sat Aug 29 23:13:13 2020] [libwebsockets][INFO] LWS_CALLBACK_HTTP closing

    Es schaut auch immer noch so aus als würde auf ipv6 gebunden werden:
    sudo netstat -anp | grep 8188
    tcp6 0 0 127.0.0.1:8188 :::* LISTEN 34679/janus

    Obwohl ich nun am lo ipv6 addresse wieder deaktiviert habe und auch in der janus.jcfg IPV6: false in der media section eingetragen habe.
    Habe auch nach https://groups.google.com/g/meetecho-janus/c/J_E0aIw1fSI noch die IP Adresse des STUN servers eingetragen, hat aber
    leider auch nichts geändert.

    ./bin/client -addr localhost:8080
    wirft leider auch nur ein
    dial tcp 127.0.0.1:8080: connect: connection refused

    Vielleicht hast du ja noch irgend eine Idee?

    Gruß,
    Andreas

    • Jan sagt:

      Hallo Andreas,

      das kommt mir auch irgendwie seltsam vor. Kann es sein, dass auf Port 8080 bzw. 8188 schon was anderes läuft?
      Ich hatte das schon einmal in einer Umgebung, wo 8080 schon von einem Docker-Container belegt war. Leg doch mal Konfdigurations-seitig den Port 8080 auf einen anderen Port (z.B. 8484). Danach nochmal testen. Wenn es dann immer noch nicht klappt, dann auch den Janus Port von 8181 auf einen anderen Port konfigurieren.

      Gruß,
      Jan

  • Boris sagt:

    Hallo Jan,

    dank Dir ganz herzlich für die Anleitung, die ist wirklich klasse!

    Ich habe den signaling server damit problemlos zum laufen bekommen.
    Ich kann den client starten und bekomme eine Ausgabe.
    In der nextcloud erhalte ich ein OK, wenn ich die URL meines servers eintrage.

    Allerdings kann ich dann auf einmal keine Verbindungen mehr aufbauen, was vorher problemlos funktioniert. Und auch sofort wieder funktioniert, wenn ich den signaling server aus der Konfiguration werfe.

    In den Logs von nextcloud finde ich die Fehlermeldung:

    GuzzleHttp\Exception\ClientException: Client error: `POST https://signaling.meinedomain.de/standalone-signaling/api/v1/room/y3wjaewp` resulted in a `403 Forbidden` response: Authentication check failed

    Wobei meinedomain.de natürlich meine richtige domain ist.

    Ich habe keine Idee, woran es liegen könnte und finde auch kein geeignetes log, dass mir mehr über den Fehler sagt.

    Hast Du eine Idee, woran es liegen könnte?

    Viele Grüße,
    Boris

    • Jan sagt:

      Hi Boris,

      er sagt hier, dass er auf der Signaling-Domain kein POST ausführen kann. Hier bitte mal in der Signaling-Konfiguration schauen, ob du die URL deiner Cloud wirklich berechtigt hast, auf den Signaling Server zuzugreifen. Sieht mir nämlich so aus, als ob das hier fehlen würde.

      Gruß,
      Jan

      • Boris sagt:

        Lieber Jan,

        super, dank Dir ganz herzlich, das hat mich auf die richtige Spur gebracht!
        Der Server läuft jetzt.

        Letztendlich hatte ich vergessen die Zertifikatsprüfung abzuschalten.

        Viele Grüße,
        Boris

  • Thorsten sagt:

    Hallo,
    hervorragendes Tutorial, herzlichen Dank dafür! Ich versuche, den Signaling Server auf einem System mit Plesk Konfiguration zu installieren. Da ist es so, dass die Apache und nginx config files von Plesk automatisch generiert werden. Ebenfalls scheint es nicht möglich, Direktiven wie „upstream“ in die vorgesehenen optionalen Felder in Plesk einzugeben. Ich frage eigentlich nur in der Hoffnung, ob jemand weiss, ob es einen Workaround gibt – der Plesk Support gab vor, dass es dieses Problem nicht gebe bzw. hat mich nicht verstanden.
    Herzlichen Dank und viele Grüße!

  • Thorsten sagt:

    Hallo Jan,

    ich sitze jetzt momentan hier fest:

    Die Einrichtung in der Talk GUI geht fehlerfrei durch (der signaling client lief lokal auch). Beim Starten einer Session hängt Talk aber endlos ohne Fehlermeldung.

    service janus status liefert:

    janus[13300]: [ERR] [config.c:janus_config_parse:206] Error parsing config file at line 26: syntax error
    janus[13300]: [WARN] Couldn’t find .jcfg configuration file (janus.transport.mqtt), trying .cfg
    janus[13300]: [ERR] [config.c:janus_config_parse:191] — Error reading configuration file ‚janus.transport.mqtt.cfg’… error 2 (No such file or directory)
    janus[13300]: MQTT SSL support disabled
    janus[13300]: [WARN] MQTT support disabled for both Janus and Admin API, giving up
    janus[13300]: JANUS MQTT transport plugin destroyed!
    janus[13300]: [WARN] The ‚janus.transport.mqtt‘ plugin could not be initialized

    Die „janus.transport.mqtt.jcfg“ existiert natürlich in /etc/janus und ist auch lesbar.

    Hast Du eine Idee?

    Vielen Dank und viele Grüße
    Thorsten

    • Jan sagt:

      Hi Thorsten,

      sieht mir eher nach einem Fehler in der Config aus (allererste Fehlermeldung) und nicht nach einer fehlenden Config aus.
      Würde daher die angepassten Configs nochmals kontrollieren.

      Gruß,
      Jan

      • Thorsten sagt:

        Hm, ich habe apt purge janus gemacht und dann erneut installiert. Der „Error parsing config file at line 26: syntax error“ kommt grundsätzlich, auch ohne dass ich irgendetwas an den config files ändere.
        Möglicherweise stimmt was mit dem backport nicht. Momentan bin ich ratlos. Aber danke.

        • Jan sagt:

          Hi Thorsten,

          bist du noch auf 18.04? Besteht die Möglichkeit, auf 20.04 upzudaten? Hier brauchst du dann keinen Backport.

          Gruß,
          Jan

          • Thorsten sagt:

            Danke Jan. Ich hab’s gelöst. Es war alles auf Anhieb richtig. Nur: Wenn ich eine Konferenz gestartet habe, wurde meine Cam und das Micro abgefragt und dann lief die „Anruf beitreten“ ewig und es passierte nichts.
            Was ich nicht letztendlich verstanden habe, ist das Konzept des allowall = false und das benennen der Backends. Da habe ich die Domain eingetragen, die allen teilnehmenden NC/Talk Instanzen gemein ist, also das Equivalent zu „meinedomain.de“. Was eben nicht funktioniert. Nach Änderung in allowall = true funktionierte es sofort.

            Darüberhinaus setht im Kommentar zu „secret“: „Common shared secret for requests from and to the backend servers if „allowall“ is enabled. This must be the same value as configured in the Nextcloud admin ui.“
            Also „if „allowall“ is enabled“, klingt als müsse das bei Verwendung des secrets so sein. Weisst Du hierzu genau, wie sich das verhält?

            Und letztendlich „Error parsing config file at line 26: syntax error“ war eine Nebelkerze aus der janus.transport.mqtt.jcfg. Wenn das richtig verstehe, wird die gar nicht genutzt. Wenn man den „snakeoil“ Eintrag in der Zeile auskommentiert, verschwindet die Meldung. Aber wenn irgendwie das ganze nicht funktioniert, klammert man sich ja an Strohalme …

            Nochmals vilen Dank für die Arbeit, die Du hier reinsteckst! Hat „eigentlich“ super für mich funktioniert, Dein Tutorial :)

            Viele liebe Grüße
            Thorsten

          • Jan sagt:

            Hi Thorsten,

            dieses „allow all“ sollte man nur zu Testzwecken aktivieren. Besser ist es (bei neueren Versionen des Signaling Servers), einzelne Backends zu definieren (in deinem Fall vermutlich nur eins). Dann kannst du „allow all“ auch auf false setzen.

            Edit: Ich habe den Artikel soeben diesbzgl. überarbeitet.

            Gruß,
            Jan

  • Thorsten sagt:

    Klasse, jezt hab ich’s verstanden und jetzt funktioniert es auch.
    Vielleicht nimmst Du noch „allowall = false“ explizit oben in das Tutorial rein, damit der Zusammenhand unmissverständlich wird? Es steht sonst auch noch einmal unten im Test aber das könnte man überlesen.

    Tausend Dank nochmal!

  • Thorsten sagt:

    Moin und sorry, ich nerve wahrscheinlich langsam aber ich habe nun mal einen signaling Server und deutschlandweit mehrere Talk Instanzen, die den als Backend nutzen sollen.

    Sobald ich mit mehr als einem Backend arbeite und sowas mache:
    [backend]
    backends = eins, zwei
    [eins]
    url = https://eins.domain.de
    [zwei]
    url = https://zwei.domain.de

    bekomme ich:
    backend_configuration.go:88: Backend eins is missing or incomplete, skipping
    backend_configuration.go:106: Backend zwei added for https://zwei.domain.de/
    … und natürlich bekommt nur https://zwei.domain.de den Zugriff.

    Das hier funktioniert, wird aber angemäkelt, man solle doch bitte den neuen „backends“ Mechanismus nutzen.
    [backend]
    allowed = eins.domain.de, zwei.domain.de

    Das ist jetzt kein Call for help, was soll man da machen, es funktioniert einfach nicht. Ich poste es nur in die Diskussion für den Fall, dass jemand sich auch mit mehreren Backends rumschlägt.

    Lieben Dank und viele Grüße
    Thorsten

    • Jan sagt:

      Hi Thorsten,

      so wie ich das sehe, musst du für jedes Backend auch ein Secret mit angeben (auch wenn für alles Backends gleich). Des weiteren konnte ich feststellen, dass es mitunter Probleme gibt, wenn in der Backend-Definition (in den eckigen Klammern) bestimmte Sonderzeichen enthalten sind.
      Vielleicht ist das ja ein Hinweis.

      Gruß,
      Jan

      • Thorsten sagt:

        Jan, Du hast natürlich Recht, jedes Backend benötigt einen secret Eintrag. Wenn man die server.conf.in ganz sorgfältig liest, steht das da sogar drin (#[another-backend] und danach nochmal secret).

        Vielen Dank und ein schönes Wochenende Dir!
        Thorsten

  • Jakob sagt:

    „useradd –system –gid signaling –shell /usr/sbin/nologin –comment „Standalone signaling server for Nextcloud“

    sollte

    „useradd signaling –system –gid signaling –shell /usr/sbin/nologin –comment „Standalone signaling server for Nextcloud“ “

    lauten, oder?

    • Jan sagt:

      Hi Jakob,

      oh, da hat in der Tat etwas gefehlt. Liegt vermutlich an der Umstellung des Plugins für die Code-Blöcke.
      Habe dies gleich mal korrigiert. Danke für den Hinweis!

      Gruß,
      Jan

  • Chartman123 sagt:

    Hallo Jan,

    erst mal danke für die tolle Anleitung. :-) Ich habe noch eine Frage zum coTURN: Du hast in deiner Anleitung ja was vom API-Key geschrieben. Wie hast du denn deinen coTURN dann konfiguriert? In der Standard-Konfiguration, die für Nextcloud empfohlen wird, ist meines Wissens nach die API ja nicht aktiviert.

    LG Chris

    • Jan sagt:

      Hi Chris,

      ich denke, dass du da was verwechselst. Der coturn-Key ist das sog. Secret für coturn. Der API-Key bezieht sich aber auf Janus. Dies sind andere Keys und haben erst einmal nichts miteinander zu tun.

      Gruß,
      Jan

      • Chartman123 sagt:

        Hi Jan,

        laut der Doku aus dem Janus-Configfile wird der API-Key aber dafür verwendet, sich am coTURN zu authentifizieren und dort Credentials zu erzeugen… Ansonsten brauch ich den API-Key gar nicht.

        LG Chris

        • Jan sagt:

          Hi Chris,

          trotzdem scheint es aber zu funktionieren. Der coturn ist genau nach dieser Anleitung hier konfiguriert. Für den Signaling Server ist hier keine besondere Konfiguration notwendig.

          Gruß,
          Jan

          • Chartman123 sagt:

            Hi Jan,

            ja, funktionieren tut es. Ich dachte nur, dass du vllt weißt, wie der coturn konfiguriert werden muss, damit die API genutzt werden kann.

            LG Chris

          • Jan sagt:

            Hi Chris,

            damit habe ich mich noch nicht beschäftigt, da die API ja nicht benötigt wird. Schnittstellen-technisch sollte man hier aber aus Sicherheitsgründen nichts aktivieren, was man gar nicht benötigt. Was nicht aktiviert ist, kann nicht angegriffen werden…

            Gruß,
            Jan

  • Sascha sagt:

    Hallo Jan,

    super Anleitung. Habe alles soweit befolgt und kann den Signaling Server problemlos in NC19 im Webinterface einbinden.
    Wenn ich jedoch einen Videocall machen möchte, verbindet sich der Client und trennt sich wieder, beides die ganze Zeit im Wechsel.
    Beim Janus service kommt die Ausgabe:
    Okt 06 23:39:24 nextcloud janus[3103]: [8591571626705188] Audio SSRC changed: 1370650370 –> 1392670092
    Okt 06 23:39:24 nextcloud janus[3103]: [8591571626705188] Video SSRC (#0) changed: 679250651 –> 1035309174
    Okt 06 23:39:24 nextcloud janus[3103]: [8591571626705188] Video SSRC (#0 rtx) changed: 1451000170 –> 1203907256
    Okt 06 23:39:24 nextcloud janus[3103]: [8591571626705188] Restarting ICE…
    Okt 06 23:39:24 nextcloud janus[3103]: [8620903108142500] Updating existing session
    Okt 06 23:39:24 nextcloud janus[3103]: Creating new handle in session 4985883353318673: 2930631790290113; 0x7f866c0017c0 0x7f866c00b490
    Okt 06 23:39:24 nextcloud janus[3103]: [2930631790290113] Creating ICE agent (ICE Full mode, controlled)
    Okt 06 23:39:24 nextcloud janus[3103]: Creating new handle in session 4985883353318673: 6726183261613538; 0x7f866c0017c0 0x7f866c00b7d0
    Okt 06 23:39:24 nextcloud janus[3103]: [WARN] Subscriber is using the legacy ‚listener‘ ptype
    Okt 06 23:39:24 nextcloud janus[3103]: [ERR] [plugins/janus_videoroom.c:janus_videoroom_handler:5180] No such feed (1)

    Verwende 20.04 LTS und habe das identische Setup wie in deiner Anleitung. Der einzige Unterschied ist, dass ich beim ngnix den Signalling auf der gleichen Domäne und auf einem anderen Port laufen lasse.
    Hast du vielleicht eine Idee was die beiden letzten beiden Meldungen [WARN] und [ERR] bedeuten könnten?

    Viele Grüße
    Sascha

    • Jan sagt:

      Hi Sascha,

      die Meldungen sagen mir nun leider nichts.
      Kann es aber sein, dass die Singaling-Domain auf Port 443 bereit gestellt werden muss?

      Gruß,
      Jan

      • Sascha sagt:

        Hallo Jan,

        war mir da auch erst nicht ganz sicher. Aber zumindest kommt von der NC GUI erst eine positive Rückmeldung, wenn man auch den alternativen Port angegeben hat. Zudem kann ich in der Ausgabe bei Janus sehen, dass sich in der Ausgabe (siehe oben) ein neuer Session Handle erzeugt wird, sobald sich ein Client einwählt. Wenn der 2. dazu kommt, kommt die Ausgabe mit [WARN] und [ERR].
        Ich denke momentan, dass es ein Problem bei Janus gibt, und dass mein NGNIX setup mit eigenem Port und Mapping auf den 8080 Upstream nicht das Porblem dar stellt. Ich werde hier berichten, sobald ich eine Lösung gefunden habe.

        • Sascha sagt:

          Hallo Jan,

          ich habe den fehler finden können. Da wir den Janus Server nur das lokale Interface gegeben haben, gab es Probleme beim auflösen des DNS Namens des STUN-Servers.

          Laut deiner Anleitung sollte in der janus.cfg folgendes rein:
          stun_server = „turn.meinedomain.de“

          Nachdem ich dieses durch den local host 127.0.0.1 ersetzt hatte, konnte Janus auch starten. Wundert mich, dass sonst niemand das Problem hier hatte.

          • Jan sagt:

            Hi Sascha,

            dem Janus gebe ich immer nur das lokale Interface. Hier sollte er dann auch in der Lage sein, die coturn-Domain aufzulösen.
            Ein anderer Workaround wäre, per /etc/hosts die coturn-Domain auf eine fixe IP aufzulösen.

            Aber auf jeden Fall danke für den Hinweis.

            Gruß,
            Jan

  • Johannes Rohr sagt:

    Hallo, danke für die Anleitung. Was recht ungewöhnlich ist ist dass Du die Binaries nach /etc installierst. Hat das einen Grund?

    Warum braucht man die Debian-Version von libsrtp2-1? Ubuntu ist derzeit bei derselben Upstream-Version, nur die interne Revisionsnummer ist anders (-2)

    • Jan sagt:

      Hi,

      ich habe es einfach mal unter /etc eingerichtet. Das kann aber auch ein beliebiges anderes Verzeichnis sein.

      Den Hinweis mit der libsrtp unter Debian habe ich entfernt. Unter Debian 10 muss man hier nichts manuell nachinstallieren.

      Gruß,
      Jan

  • Johannes Rohr sagt:

    Du schreibst oben:

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

    Das verwirrt mich, denn coturn ist ja der turn server, nicht der stun-server. Als Stun-server ist bei Nextcloud talk per Vorgabe stun.nextcloud.com:443 eingetragen, was ich bislang auch nicht geändert habe.

  • Johannes Rohr sagt:

    Warum sollte den Janus denn überhaupt einen stun-Server benötigen? Einen solchen braucht man doch nur bei NAT, auf das ein richtiger Server i.d.R. nicht angewiesen ist.

  • Hans Jochens sagt:

    Danke für die Anleitung.
    Habe die Installation hinbekommen und die Videokonferenzen mit 6 Teilnehmern laufen endlich stabil.

    Gibt es Erfahrungen, wie viele Teilnehmer pro Server zu empfehlen sind und / oder was für Hardware für Gespräche mit 50 Personen benötigt wird?

    • Jan sagt:

      Hi Hans,

      bei mehr Teilnehmern ist v.a. die Bandbreite entscheidend. Hier sollte der Server 1 GBit/s (Up- und Down) haben. Ansonsten habe ich hier noch wenig Erfahrungswerte mit größeren Konferenzen. Ich würde aber für 50 Teilnehmer aus dem Bauch raus sagen: Min 6 CPU-Kerne, min 16 GB RAM (besser 32).

      Gruß,
      Jan

1 2

Schreibe einen Kommentar

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