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: 23.12.2022)- 23.12.2022:
- Anleitung zum Update des Signaling-Servers aktualisiert.
- 11.01.2022:
- Hinweis auf launchpad hinzugefügt, da der Support für Ubuntu 18.04 in den Janus-Backports entfernt wurde.
- 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.
Inhalt
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
- Hier wird die IP und der Port angegeben (diese Zeile muss daher einfach einkommentiert werden):
- Sektion „sessions“:
- Angabe des Hash-Keys (s.o.):
hashkey = <Hash-Key>
- Angabe des Block-Keys (s.o.):
blockkey = <Block-Key>
- Angabe des Hash-Keys (s.o.):
- 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
- Hier wird die Verbindung zum Websocket von Janus festgelegt:
- 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
- Hinzufügen des Janus API-Keys:
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
Danke erstmal für deine Anleitung.
Die config unter Ubuntu 20.04 LTS lief problemlos.
Nextcloud 20 auf einem Server mit cotun –> läuft
turn von extern testen funktioniert
Janos, signal und nats auf einem 2ten server –> läuft
allowall = true und client-test funktioniert, allowall = false natürrlich wieder eingestellt
Vom Nextcloud-Server ein curl -k -i https://xxxxx.de/standalone-signaling/api/v1/welcome funktioniert auch.
In der Nextcloud eingetragen funktioniert auch, „OK: Laufende Version: 18c1874333c03425a9a459f23c8cd7238ef8aa28“
leider geht talk aber nicht ;(
„Fehler beim Aufbau der Signaling-Verbindung. Versuche erneut…“
Hat jemand eine Idee woran da sliegen könnte ???
Hi,
von deinen Tests her sieht es erst einmal gut aus. Hier können dir wohl nur die Logs aufzeigen, woran es hapert…
Gruß,
Jan
Joop, ich hab es gefunden …
Nachdem ich in der Nextcloud verify bei den certs für den Signal-Server aktiviert hatte kam auch ein connect zum Signal-Server und Janos zu stande … da taucht dann im log der Fehler auf, mit debug 7… intermed’s beim cert des Nextcloud-Servers vergessen ….
Also immer schön darauf achten das alles mit den passenden Cert’s incl. Intermed’s versehen ist !!! Dann geht alles perfekt …
PS: Danke nochmal für die gute Anleitung hier …
Hallo, vor dem gleichen Problem stehe ich auch. Was genau meinst du mit „Nachdem ich in der Nextcloud verify bei den certs für den Signal-Server aktiviert hatte“? Wie kann ich das bei mir auch einstellen?
Hi Marcus,
ich denke, er meint die Option „SSL-Zertifikat überprüfen“ bei den Talk-Einstellungen in der Nextcloud.
Gruß,
Jan
Hallo,
erstmal danke für diese Super Anleitung. Beim zweiten Anlauf hat es dann auch fast geklappt. Genauso wie Ray habe ich die Test gemacht und die gleichen Ergebnisse.
Fehler ist dann auch „Fehler beim Aufbau…..“
wenn ich mir jetzt den Status des signaling Dienstes anzeige sehe ich zuhauf folgende Meldungen:
signaling[588]: hub.go:1888: Could not upgrade request from X.X.X.1: websocket: not a websocket handshake: ‚websocket‘ token not found in ‚Upgrade‘ header
(habe noch nicht gefunden wo singaling oder Janus seine Logs ablegt)
Dabei ist X.X.X.1 eine Firewall -> Sophos in der ich eine normale 443 Webveröffentlichung gemacht habe. Ich vermute, das der Signaling Server nicht die wirkliche IP des Benutzers, sondern die IP der Firewall sieht.
Wenn ich mir aber dein Nginx conf anschaue, hast du das ja schon mit abgefangen? Leider komme ich von Apache und bin auch dort nicht so sehr bewandert das ich die nginx conf einfach auf apache2 ummünzen kann. Somit habe ich die ngnix Installation unberührt gelassen und nur deine conf erstellt und angepasst und die ssl.conf für das Zertifikat erstellt und angepasst.
Hi,
hier ist denke ich der erste Ansatz die Sophos: Diese blockt denke ich die „Weitergabe“ der Websockets. Ebenso muss die Firewall die echte IP des Clients „durchlassen“.
Aber zunächst würde ich mich hier um die Sache mit den Websockets kümmern.
Gruß,
Jan
also die Firewall gibt die IP weiter.
Das sehe ich an meinen apache2 Webserver, der kann die wirklichen IPS sehen nachdem ich die Einstellung in der apache2.conf dafür vorgenommen habe.
Websockets könnte sein. Ich sehe im Log der Firewall aber keine Fehler oder Blockierungen, aber ein paar 400Meldungen die wohl von meinem Webserver kommen.
Erstmal Danke für die Anleitung, habe aber leider ein Problem,
(ich sollte erwähnen, das ich eigentlich mit Linux nix am Hut habe….)
Die Status Abfragen sind OK. Nginx, Signaling, Janus (bindet sich auch an den StunServer) und bei Nats bekomme ich auf ein Ping ein Pong….Nextcloud kann den Signalig Server auch einbinden. Aber der Clienttest geht in die Hose:
„unsupported message type: {Id: Type:error Error:unsupported_content_type Hello: Room Control Event
Backend checksum verification failed“
kannst du mir da vielleicht weiterhelfen?
Danke Alfred
Hallo Alfred,
das sieht mir so aus, als ob das Backend in der Signaling-Konfiguration nicht richtig hinterlegt/konfiguriert wurde („Backend checksum verification failed“).
Daher bitte nochmal die Backend-Sektion in der server.confg kontrollieren/anpassen.
Gruß,
Jan
Hallo Jan,
vielen Dank für die schnelle Antwort. Das wars…Es hatte sich ein kleiner
Fehlerteufel eingeschlichen.
nochmals Danke
Alfred
Hallo Jan,
der Signaling-Server alleine isf für ein HPB (High Performance Backend) nicht ausreichend. Damit kann vielleicht eine Videokonferenz mit mehr als 4 bis 5 Teilnehmer realisiert werden, aber man kommt sehr schnell ans Limit, insbesondere bei einer Vielzahl von Teilnehmern und mehreren Konferenzräumen, da weiterhin über eine Peer-to-Peer Verbindung gestreamt wird.
Für ein HPB ist zwingend die Implementierung einer SFU (Select Forwarding Unit) erfordelich.
Eine SFU ist eine Videokonferenzarchitektur, welche folgende Datenübertragungsprozesse zwischen dem Server und den Endpunkten bietet:
1. Der Server empfängt eingehende Videostreams von allen Endpunkten.
2. Der Server sendet mehrere Kopien unkomprimierter Videostreams anderer Teilnehmer an jeden Endpunkt.
3. Die Endpunkte führen eingehende Videostreams zusammen.
Dank der SFU muss der Client nicht jedem Teilnehmer das gleiche ausgehende Signal senden, so wie es bei der Peer-to-Peer-Verbindung der Fall ist, sondern der Stream wird an den Server gesendet und an alle Benutzer verteilt. Infolgedessen sendet der Teilnehmer ein ausgehendes Signal und empfängt Streams anderer Benutzer vom Server.
Für Deine Konfiguration ist das Video-Room-Plugin für Janus geeignet.
Alternativen von SFU sind Asterisk, Jitsi Videobridge (JVB) etc. etc.
Mit einer MCU (Multipoint Conferencing Unit) kann ein HPB neben dem Signaling-Server auch realisiert werden, aber die Streams werden bei dieser Videokonferenzarchitektur ständig decodiert und wieder neu codiert, wodurch eine erhebliche Rechenleistung des Servers notwendig ist.
Viele Grüße
Harry
Hi Harry,
danke für deine Ausführungen. Wie ich das sehe, ist für den Signaling Server selbst Janus notwendig. Ohne Janus bekommt man das vermutlich gar nicht ans Laufen. Dass hier auch das Video-Room-Plugin genutzt wird, kann ich bestätigen, da bei zu alten Janus-Versionen, die ohne Video-Room-Unterstützung ausgeliefert wurden (z.B. unter Ubuntu 18.04) eine eindeutige Fehlermeldung kommt, dass Video-Rooms nicht unterstützt werden.
Interessant wäre hier, wie man den Signaling Server mit einer JVB zusammen bringen kann. Hast du hier schon Erfahrungen?
Gruß,
Jan
Hallo Jan,
ja, zum Signaling-Server ist zursätzlich ein WebRTC-Server und eine SFU Voraussetzung, damit nicht mehr Peer-To-Peer verwendet wird und die Streams über den Server laufen. Dann können auch 50, einige hundert oder mehr Anwender Talk nutzen.
Janus WebRTC Server (siehe link)
https://github.com/meetecho/janus-gateway
Da hat sich beim gestrigen Post ein kleiner Fehler eingeschlichen.
Das Video Room Plugin ist nicht zwingend erforderlich.
Ich meinte natürlich das Janus SFU Plugin (siehe link)
https://github.com/mozilla/janus-plugin-sfu
Wir haben ca. 650 Clients und sind wieder weg von Talk und verwenden derzeit Cisco Webex mit 250 Lizenzen, aufgrund fehlender Funktionen, die Talk nicht bieten kann wie z.B. automatische Transkription, Meeting Management, Webcasts, Sitzungsaufzeichnung etc.
Aber ich werde bei nächster Gelegenheit ein HPB für Nextcloud Talk als Backup-Lösung einrichten, da bei uns der Bedarf an Videokonferenz auf Grund der jetzigen Lage kontinuierlich steigt. Die Cisco Webex Lösung ist zwar sehr gut und ausgereift, aber sehr teuer.
Viele Grüße
Harry
Hallo Jan. Einmal mehr ein tolles Tutorial. Werde nun definitiv bei Nexcloud mit Ubuntu 20.04 gemäss einem anderen Tutorial von Dir umsteigen. Weisst Du, wie dieser Signaling-Server hinter einem Nginx Reverse Proxy betrieben werden kann?
Hi Adrian,
hier wird der Endpunkt für den Signaling-Server in nginx konfiguriert. Dies ist im Prinzip schon eine Proxy-Anweisung. Natürlich kann der Signaling-Server (inkl. Janus usw.) auf einer anderen Maschine als der nginx laufen. In diesem Fall muss der Signaling-Server nur so konfiguriert werden, dass dieser nicht nur auf die lokale IP (127.0.0.1) lauscht.
Gruß,
Jan
Hallo Jan,
ich schon wieder…Der Test klappt zwar aber beim Versuch eine Talk Session
zu starten kommt „Fehler beim Aufbau der Signaling Verbindung“
1.Frage kann man beim Signaling ein Log einschalten und wenn ja wie?
ich habe nur ein nginx log mit einem post „POST /standalone-signaling/api/v1/room/“xxxxx“ HTTP/1.1 200 2″ Im Janus log stehen keine Infos.
2.Frage muss die Chose über Public IP’s laufen oder geht es auch rein Intern ?
Ich muss zu meiner Ehrenrettung nochmal erwähnen das das alles relatives Neuland für mich ist (ich stand halt noch als die Musik zu spielen aufhörte…)
viele Grüße
Alfred
Hi Alfred,
also lokal sollte es funktionieren. Hier kannst du dann nur keine Let’s Encrypt Zertifikate nutzen. Ich kann mir hier auch vorstellen, dass Nextcloud die Einbindung eines Signaling Servers unterbindet, wenn keine „echten“ Zertifikate zum Einsatz kommen.
Die Janus-Logs müssten im syslog auftauchen. Der beste Weg ist hier vermutlich, den Signaling Server manuell über die Kommandozeile zu starten (also nicht per systemd-Unit). Dann im Browser eine Verbindung aufbauen. Nun solltest du auf der Kommandozeile „im Hintergrund“ einen Output bekommen, der vielleicht eine Fehlermeldung offenbart.
Gruß,
Jan
Hm. Ich habe jetzt nach längerem Frickeln das HPB zum Laufen bekommen, allerdings habe ich erst nachdem ich in der server.conf bei [mcu] den Wert „type“ einkommentiert und auf „janus“ gesetzt habe. Der Doku zufolge wird nämlich sonst die MCU komplett deaktiviert:
# The type of the MCU to use. Currently only „janus“ and „proxy“ are supported.
# Leave empty to disable MCU functionality.
type = janus
Der Default ist „type =“, also leer, und damit wohl gar keine MCU konfiguriert.
Habe ich da einen Denkfehler – wird gar keine MCU benutzt? Wozu dann die Angabe des MCU URL?
Hi Chris,
danke für den Hinweis. Dass bei „type“ nicht mehr automatisch „janus“ angegeben wird, wurde wohl in einer neueren Version des Signaling Servers geändert. Ich habe das gleich mal im Artikel so angepasst.
Gruß,
Jan
Hello,
I hope you do not mind that I write in English. I’m from Holland and I can read German, but knowledge is not good enough to write in German. Sorry about that, and no problem if you answer in German….
I have trouble understanding one point:
in janus.jcfg we configure the turn_rest_api_key, but we do not configure a turn server and we do not configure a URL to access the api server in this configuration file.
Also, in the turnserver.conf file of cotrun, I would expect that we have to enable the API server and configure the same secret key? But we do not do that.
When I start janus, I get the following entry in the logfile:
[Wed Nov 11 10:10:43 2020] TURN REST API backend: (disabled)
So, I think something is wrong with the API configuration.
Do you have any hints or suggestion for me?
Fortunately, the signaling servers seems to work anyway, although joining a session is a bit slow (did not yet do an extensive test). So, maybe this turn API stuff is not important?
Kind regards,
Frank
p.s.: thank you very much for this extensive and well written documentation. It was very helpful!
Hi Frank,
as I see it, we configure the turn rest API key in the janus configuration and this is the key for the signaling server, not for coturn. Maybe that’s only a naming problem of the variables.
Where exactly you get this output (which log file)?
Best regards,
Jan
The log entry is in the /var/log/janus.log logfile.
Hi Frank,
I’ve never seens this message in the logs so far. If it works anyway, I think you can ignore this message.
Best regards,
Jan
Hallo Jan,
erstmal ein riesen Kompliment für deine Anleitung. So detailiert findet man eine solche nur selten im Netz. Ich konnte sowohl den Nats, als auch den Janus, Stun/Turn und signaling Server erfolgreich installieren. Den ersten Test habe ich nur mit dem Stun/Turn Server durchgeführt, läuft ohne Probleme. Wenn ich aber den Signaling Server eintrage, lädt die NC Talk App ohne ein Ende zu finden. Der Test mit den 100 Verbindungen läuft aber erfolgreich. Auch die Welcome URL baut die Verbindung auf. Auch in der Syslog gibt es ausschließlich Erfolgmeldungen. Einzige Meldung, die ich finden konnte, war in dem NC Log:
Client error: `POST https://signaling.domain.com/standalone-signaling/api/v1/room/kzjfjibx` resulted in a `403 Forbidden` response: Authentication check failed
Für Ideen oder Hinweise wäre ich sehr dankbar!
Viele Grüße!
Andre
Hi Andre,
die Infos sind etwas dürftig, ich würde aber zunächst mal die Backend-Konfiguration vom Signaling-Server kontrollieren. Sieht nämlich so aus, als ob nur der Zugriff durch deine Cloud selbst geblockt wird.
Gruß,
Jan
Hi Jan,
seltsam, im Backend scheint alles richtig zu sein:
—————-
url = https://cloud.mydomain.com
secret = aabdba7….334
—————-
diese Secret habe ich auch als geheimnis bei den Talk Einstellungen beim Signaling Server eingetragen.
Beim herstellen der Verbindung scheint es auf dem signaling Server zu funktionieren:
———Signaling————–
signaling[27789]: client.go:252: Client from 213.168.83.234 has RTT of 1 ms (1.972382ms)
Nov 11 12:07:56 srvsignaling01 signaling[27789]: client.go:252: Client from 203.153.83.xxx has RTT of 2 ms (2.612001ms)
Nov 11 12:07:58 srvsignaling01 signaling[27789]: client.go:252: Client from 203.153.83.xxx has RTT of 2 ms (2.623099ms)
Nov 11 12:07:59 srvsignaling01 signaling[27789]: client.go:252: Client from 203.153.83.xxx has RTT of 2 ms (2.064688ms)
Nov 11 12:08:00 srvsignaling01 signaling[27789]: client.go:252: Client from 203.153.83.xxx has RTT of 2 ms (2.059613ms)
————————————
Beim Janus Service sieht es eig. auch gut aus…:
—————-Janus Service———————
Nov 11 12:03:31 srvsignaling01 janus[27733]: [WSS-0x7fbdfc000b60] Destroying WebSocket client
Nov 11 12:03:31 srvsignaling01 janus[27733]: Destroying session 5517310898768157; 0x7fbe54002d70
Nov 11 12:03:31 srvsignaling01 janus[27733]: Detaching handle from JANUS VideoRoom plugin; 0x7fbe54003fd0 0x7fbdfc001440 0x7fbe54003fd0 0x7fbe54003380
Nov 11 12:03:31 srvsignaling01 janus[27733]: [janus.plugin.videoroom-0x7fbdfc001440] No WebRTC media anymore; 0x7fbe54003fd0 0x7fbe54003380
Nov 11 12:03:31 srvsignaling01 janus[27733]: [1507852527871844] Handle and related resources freed; 0x7fbe54003fd0 0x7fbe54002d70
Nov 11 12:03:31 srvsignaling01 janus[27733]: Creating new session: 3446790375674101; 0x7fbe54002930
Nov 11 12:03:31 srvsignaling01 janus[27733]: Creating new handle in session 3446790375674101: 4318126726419730; 0x7fbe54002930 0x7fbe54002af0
——————————————————
Sehr seltsam… Ich kann mir nicht erklären, wo der Fehler sein soll.
Viele Grüße!
Andre
Hi Andre,
einen direkten Fehler kann ich hier erst einmal nicht erkennen, sorry.
Aber nochmal zur Kontrolle: In der server.conf definierst du erst einmal ein Backend (z.B. [backend1]). Hier URL deiner Cloud und das Secret eingeben. Dann weiter oben in der backend-Sektion selbst muss dieses Backend noch unter „backends = …“ aufgenommen werden. Hier trage ich dann für gewöhnlich auch nochmal das NC-Secret ein (ein paar Zeilen darunter).
Gruß,
Jan
Hallo Jan,
ich habe die Config nun nochmals komplett neu angelegt. jetzt funktioniert es plotzlich. Vermutlich hat sich in der config ein Fehler eingeschlichen.
Vielen Dank für deine Hilfe!
Grüße!
Andre
Hallo,
vielen Dank für die ausführliche Anleitung!
Bei mir scheitert leider der Client-Test, es kommt pro Verbindungsversuch einmal diese Meldung:
Unsupported message type: {Id: Type:error Error:Incomplete OCS response Hello: Bye: Room: Message: Control: Event:}
und einmal diese:
Received bye: &{Reason:hello_timeout}
und dann steht der Client, und man kann ihn nur mehr per kill von außen abschießen (Ctrl+C hilft nicht). Habe keine Ahnung was diese Meldung genau bedeuten könnte, und wäre für jede Info was es da haben könnte, sehr dankbar!
Hi,
die Meldung sagt mir nun erst einmal nichts. Hast du mal ausprobiert, die Backports von Janus (siehe hier) zu nutzen? Oftmals kommt es bei älteren Janus-Versionen zu Problemen, vielleicht ist das schon die Lösung.
Gruß,
Jan
Hallo,
hab leider (vermutlich) das gleiche Problem. Beim Test kommt bei mir:
Unsupported message type: {Id: Type:error Error:Incomplete OCS response Hello: Bye: Room: Message: Control: Event:}
Durch den Tipp von Jan (an der Stelle auch noch mal vielen Dank für die Anleitung!!) bin ich auf die neuere Version von Janus gestoßen und hab diese installiert. Extra mit neuen Config-Dateien, die ich dann wieder angepasst habe.
Leider ist der Fehler gleich geblieben.
Mach jetzt mit dem Server schon einige Stunden rum. Vielleicht hat ja jemand noch eine Idee. ;)
Vielen Dank und Gruß
Max
Hi Max,
hier lohnt es sich meiner Erfahrung nach immer, in der Browser-Console (F12) nach Fehlermeldungen zu suchen. Meist liefert erst das dann einen konkreteren Hinweis. In den Server-Logs findet man hier u.U. nicht viel, da die Verbindung bereits Client-seitig nicht richtig aufgebaut werden kann (daher auch die Suche auf der Client-Seite).
Gruß,
Jan
Auch bei mir hat ein Update von Janus leider keine Verbesserung gebracht.
> hier lohnt es sich meiner Erfahrung nach immer, in der Browser-Console (F12) nach Fehlermeldungen zu suchen.
Das Problem tritt bei mir mit dem test client auf, nicht im Webbrowser – fürchte da kann ich nicht in die Browser-Console sehen?
Hi,
wenn der Test-Client nicht funktioniert, dann stimmt irgend etwas mit der Installation/Konfiguration des Signaling Servers (oder der verwendeten Komponenten) nicht. In diesem Fall wirklich noch mal alle Schritte kontrollieren und ggf. nachbessern.
Gruß,
Jan
es gibt bereits ei issue auf github
https://github.com/strukturag/nextcloud-spreed-signaling/commit/559f1e28aedd8dfbe4195fc65bcd157eef46f988
Workaroud: mit
#skipverify = false
skipverify = true
funktionierts
Entchuldigt bitte, Workaround funktioniert nicht
(ich war in Verzeichis einer alten Version)
Entschuldigt bitte, der Workaround funktioniert nicht
(war im Verzeichnis einer alten Version)
Hallo!
Vielen Dank für die Anleitung – habe sie mit etwas Mühe auf einem Server mit openSUSE Leap 15.2 realisieren können, am schwierigsten war hier Janus zu starten, das klappte erst nach manuellem compilen von Libwebsockets, Austausch des Videotransport Plugins mit dem einer anderen Janusversion, und laden der respektiven Libwebsockets. Scheint nun aber stabil und problemlos zu funktionieren – hoffentlich bleibt das bei etwaigen Package-Updates auch so.
Eine Frage zur Signaling Software, ich habe die Anleitung mehrfach durchgelesen, entweder übersehe ich etwas, oder der Ersteller hat den Punkt ausgelassen: Es wird die Installation des NATS Servers kurz erklärt, aber nicht, dass man diesen auch in der SIgnaling server.conf eintragen soll. Ich habe dies selbstständig gemacht, unter [nats], frage mich aber ob es einen Grund gibt, warum in der Anleitung NATS lediglich installiert, aber nicht „verknüpft“ wird? Ich habe NATS zwar manuell installiert, und nicht via Docker, dies sollte aber keinen Unterschied machen.
Hallo Georg,
die Option für den NATS-Server ist in der server.conf zwar auskommentiert, dieser wird meiner Erfahrung nach aber dennoch genutzt. Ist denke ich eine Default-Einstellung. Hier braucht man also nur Änderungen an der Option durchführen, wenn z.B. ein anderer Port genutzt wird.
Gruß,
Jan
Hallo Jan, da fehlt eigentlich nur noch ein Coturn Stun der auf TCP 443 hört. Dann würde das auch aus vielen Firmennetzen funktionieren.
Hi Horst,
coturn läuft eigentlich auf Port 5349 (siehe hier).
Aber du hast recht: In Firmennetzen funktioniert das u.U. nur zu 100%, wenn coturn auf Port 443 läuft. In diesem Fall kann dann aber nichts mehr anderes auf Port 443 laufen (z.B. Webserver). Diesen „Luxus“ kann man sich daher nur gönnen, wenn man für coturn eine extra Maschine bereit stellen kann.
Gruß,
Jan
Hallo Jan,
erstmal Danke für deine Anleitung!
Ich habe soweit alles am laufen. Der Client funktioniert und kann alle Verbindungen herstellen, Talk in der NC erkennt den Server.
OK: Laufende Version: 61000f5f698a9bdf6f5a5ea2c56f0d412fac55c3
Sobald der Signaling Server aktiv ist, funktioniert aber der Videochat nicht mehr.
Es wird ja zyklisch wss://signaling.meinedomain.net/standalone-signaling/spreed mit folgendem Request aufgerufen:
{„type“:“hello“,“hello“:{„version“:“1.0″,“auth“:{„url“:“https://cloud.sg-meinedomain.de/ocs/v2.php/apps/spreed/api/v1/signaling/backend“,“params“:{„userid“:“vorname.nachname“,“ticket“:“MBm36wKVPV37uVOI:1611926831:vorname.nachname:c640e51c5d663c5e2064822697f65f1f7b041d98cf09959a2ce367d5ed5797ff“}}},“id“:“1″}
Die Antwort darauf lautet:
{„id“:“1″,“type“:“error“,“error“:{„code“:“invalid_request“,“message“:“The request could not be authenticated.“}}
Hast du eine Idee woran das liegen könnte?
Viele Grüße
Stefan
Hi Stefan,
hier stimmt wohl etwas mit der Authentifizierung nicht. Sind die Keys (Hash/Block/Turn) in der Signaling/Janus Konfiguration richtig hinterlegt?
Gruß,
Jan
Hallo Jan,
die waren richtig hinterlegt. Ich habe nun nochmals neue Keys erzeugt und laut Anleitung hinterlegt. Aber keine Besserung.
Funktioniert der Test mit dem Benchmark Client denn wenn die Keys falsch hinterlegt sind?
Gruß
Stefan
Hi Stefan,
das war nur meine erste Vermutung. Wenn der Client-Test funktioniert, ist der Signaling Server korrekt aufgesetzt.
Hier hapert es wohl bei der Einbindung in die Nextcloud. In der server.conf (des Signaling Servers) ist die Cloud-Instanz korrekt als Backend hinterlegt (und dieses Backend auch aktiviert)?
Gruß,
Jan
Hallo Jan,
danke für deine Hilfe. Ich habe einfach noch mal Schritt für Schritt alles überprüft und neue Keys gesetzt. Jetzt läuft es.
Gruß
Stefan
Hi Stefan,
perfekt, dann war es wohl wirklich nur irgend eine Kleinigkeit.
Danke für die positive Rückmeldung!
Gruß,
Jan
Hallo Jan,
auch von mir vielen Dank für diese Anleitung.
Ich habe alles soweit aufgesetzt, auch der Test per Client funktioniert nach einem Update nun.
Das Ansprechen des Signaling-Servers per ‚https://signaling.meine-domain/standalone-signaling/api/v1/welcome‘ zeigt mir die Welcome-Meldung.
In den Settings von Nextcloud Talk habe ich den STUN-Server eingetragen (keine Fehlermeldung zu erkennen) sowie den TURN-Server (der Test des Servers gibt ein OK zurück).
Wenn ich allerdings den Signaling-Server in das entsprechende Feld eintrage erscheint dahinter „Fehler: Ein unbekannter Fehler ist aufgetreten“. Wenn ich im Browser ‚Element untersuchen‘ ausführe, sehe ich einen Status „403/Forbidden“.
Wo kann ich evtl. noch Hinweise finden, was diesen Fehler auslöst?
Viele Grüße
Jörg
Hi Jörg,
bei „Forbidden“ ist es meistens ein Fehler in der Konfiguration des Signaling Servers. Hier besonderes Augenmerk auf die Backend-Konfiguration legen.
Ansonsten können dir eigentlich nur die Logs (Signaling, Janus, nginx) weiter helfen. Hier also mal einen Blick rein werfen.
Gruß,
Jan
Ok, danke. Ich nutze Apache und vermute den Fehler irgendwo dort. Ist Dir ein öffentlicher (Test-)Signaling-Server bekannt, den ich mal eintragen könnte, um einen Test zu starten?
Hi Jörg,
eine öffentliche Test-Instanz kenne ich leider auch nicht, sorry.
Wenn du den Webserver in Verdacht hast, dann würden da doch sicher im Log Fehlermeldungen o.ä. auftauchen, oder?
Gruß,
Jan
[Meine erste Antwort ist irgendwie verschollen, darum jetzt nochmal, ein wenig abgewandelt]
Hallo Jan,
ich nutze Apache und vermute mittlerweile dort ein Problem oder bei Nextcloud: wenn ich den Signaling Service stoppe, bekomme ich unter ‚https://signaling.meine-domain/standalone-signaling/api/v1/welcome‘ keine Welcome-Nachricht mehr. Bei den Talk Settings ändert sich nichts an der Fehlermeldung und am ‚Forbidden‘.
Gibt es irgendwo einen (Test-)Signaling-Server, den man zum probieren nutzen kann, um Probleme bei Nextcloud (Talk) auszuschließen?
Meine Apache VirtualHost Config hab ich auch nur irgendwo abgeschrieben, evtl. passt da was noch nicht.
Viele Grüße
Jörg
Hi Jörg,
dein vorheriger Kommentar ist denke ich im Spam-Filter stecken geblieben. Diesen habe ich dann manuell freigegeben und darauf geantwortet.
Komisch ist hier nur, dass du immer noch einen Forbidden-Fehler bekommst, wenn der Webserver gar nicht mehr läuft. Denn dann würde ich im Allgemeinen einen HTTP 404 („not found“) erwarten.
Die weiter oben erwähnten Logs sollten aber mit etwas Glück einen Hinweis liefern.
Gruß,
Jan
Hallo Jan,
mittlerweile glaube ich, dass der Signaling-Server wahrscheinlich nicht das Problem ist (habe jedenfalls in den logs noch nichts dazu gefunden). Irgendwas ist evtl bei meinem Nextcloud nich tin Ordnung. Denn die ‚400 – Forbidden‘ Medlung an der gleichen Stelle bekomme ich, wenn ich irgendwas in das Feld des Signaling-Servers eintrage (also ‚google.com‘ oder ‚bla‘). Im Nextcloud log taucht aber auch kein Error auf. Es ist zum Haare raufen.
Hat jemand schonmal was ähnliches beobachten können?
VG
Jörg
Hi Jörg,
taucht hier irgendwas in den Webserver-Logs auf?
Das einzige, was mit hier einfällt: Ich hatte mal einen Fall, bei dem etwas mit dem Zertifikat nicht stimmte, über das der Signaling Server versorgt wurde. Dies führte dann auch dazu, dass es irgendwie nicht geklappt hat. Daher vielleicht nochmal bei Qualys das SSL-Cert checken.
Gruß,
Jan
Hallo Jan,
SSL-Cert bei Qualys gecheckt, alles i.o.
In den Logs des Webservers taucht nur das hier auf, wenn ich bei Talk den eignen Signaling-Server eintrage:
cloud.meine_domain.com:443 – – [07/Feb/2021:16:15:42 +0100] „POST /ocs/v2.php/apps/provisioning_api/api/v1/config/apps/spreed/signaling_servers HTTP/1.1“ 200 1336 „-“ „Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0“
cloud.meine-domain.com:443 – – [07/Feb/2021:16:15:42 +0100] „GET /ocs/v2.php/apps/spreed/api/v1/signaling/welcome/0 HTTP/1.1“ 403 918 „-“ „Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0“
Fehler sehe ich da keinen, der Signaling-Server wird aber auch nicht angesprochen. Wenn ich im Browser ‚https://signaling.meine-domain.com/standalone-signaling/api/v1/welcome‘ ansurfe, steht im Server-Log dies hier:
signaling.meine-domain.com:443 – – [07/Feb/2021:16:26:34 +0100] „GET /standalone-signaling/api/v1/welcome HTTP/1.1“ 200 4375 „-“ „Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0“
Wie gesagt, das Interessante dabei ist, dass, egal, was ich als Signaling-Server bei Nextcloud Talk eintrage (auch unsinniges, was keine Domain ist), dort immer wieder ‚403‘ zurückgegeben wird. Also ob in der Spreed-Api irgendwas kaputt ist.
VG
Jörg
Hi Jörg,
der Meldung in der NC-Oberfläche würde ich da nicht zu 100% trauen – wie du schon sagst, kommt hier ja die gleiche Fehlermeldung, wenn du hier Quatsch eingibst.
Wenn du den Signaling-Server als Dienst gestartet hast, dann beende diesen mal und starte den Signaling Server direkt über die Kommandozeile (siehe hier). Dann den Signaling-Server nochmal bei NC hinzufügen. Auf der Kommandozeile kommen dann hoffentlich aussagekräftigere Fehlermeldungen.
Gruß,
Jan
Hallo Jan,
zwischendrin mal wieder ein Dank für Deine Bemühungen zur Hilfe bei der Lösungsfindung.
Der Start des Signaling-Servers auf der Konsole wirft außer zwei Warnings nichts auffälliges aus. Nach ‚main.go:302: Listening on 127.0.0.1:8080‘ folgt nichts weiter.
Die Eintragung auf der Einstellungsseite NC – Talk führt zu keiner weiteren Ausgabe, der NC kontaktiert also den Signaling-Server nicht. :-(
VG
Jörg
Hi Jörg,
dann prüfe mal die „Verbindung“ der einzelnen Dienste, spricht die verwendeten und konfigurierten Ports. Vielleicht ist hier ja noch etwas falsch, so dass sich die Dienste untereinander nicht finden können…
Gruß,
Jan
Hallo Jan,
ich hab nun alles nochmals gecheckt und auch die entsprechenden Dienste per Befehlszeile gestartet, um dort direkt Aktivitäten zu sehen und Fehler zu entdecken. Auch dort nichts auffälliges. Ich denke, ich geb an der Stelle auf.
Die einzige Spur, die ich hab: Wenn ich den Signaling Server per Browser direkt anspreche, erhalte ich die ‚Welcome‘-Nachricht und im Log des Webservers (Apache2) sehe ich den Zugriff auf die Signaling-Subdomain. Wenn ich den Signaling-Server in Nextcloud einbinde, sieht es in der Talk-Einstellungsseite so aus, als ob ein Zugriff probiert wird (mit der entsprechenden Fehlermeldung im Anschluss), aber im Apache-Log ist kein Zugriff auf die Subdomain aufgeführt. Es erfolgt also kein Zugriff von Nextcloud dorthin.
VG
Jörg
Hi Jörg,
was passiert, wenn du auf der NC-Maschine mit curl einen Abruf der „Welcome-URL“ des Signaling Servers ausführst?
Nicht, dass aus irgendeinem Grund der Aufruf nur vom NC-Server nicht klappt…
Gruß,
Jan
Hallo Jan,
der curl Aufruf gibt dies zurück:
>>
HTTP/1.1 200 OK
Date: Mon, 22 Feb 2021 07:33:51 GMT
Server: nextcloud-spreed-signaling/97a604915479b16d6faa996e5218fb38341db751
Strict-Transport-Security: max-age=15768000
Content-Type: application/json; charset=utf-8
Content-Length: 94
{„nextcloud-spreed-signaling“:“Welcome“,“version“:“97a604915479b16d6faa996e5218fb38341db751″}
<<
Aber: Mit großer Wahrscheinlichkeit haben wir hier Gespenster gejagt. Der 'Quick-Check' auf der Talk-Settings Page gibt immer noch 'unbekannter Fehler' zurück und ich sehe ein 'Forbidden'.
Erst wennn ich einen Call über Talk starte, sehe ich im WebLog Zugriffe auf die Signaling Domain und dort dann auch keine offensichtliche Fehlermeldung. Wahrscheinlich funzt es ja im Regelbetrieb und nur dieser Check hat ein Problem. Ein 'Lasttest' steht noch aus.
Sorry, dass wir so lange in die falsche Richtung gerannt sind. Aber vielleicht hilft das hier ja anderen, die sich auch auf die positive Rückmeldung der NC-Talk-Einstellungsseite verlassen.
VG
Jörg
Hi Jörg,
entscheidend ist hier der Funktionstest mit einer echten Konferenz. Hier sieht man dann sehr schnell, ob es klappt oder nicht – das ist beim Signaling Server ein „entweder ganz oder gar nicht“. Wenn es klappt (mit Video/Ton), dann ist der Server korrekt eingerichtet.
Trotzdem würde es mich wundern, da ich noch nie einen Signaling Server aufgesetzt habe, der über die NC-Einstellungen einen Fehler geworfen hat, aber „in echt“ funktioniert hat…
Gruß,
Jan
Hallo Jan,
ich kann nur sagen, dass ich den Signaling-Server entsprechend eingetragen habe und eine 2er-Konferenz zum Test durchgeführt habe was auch funktioniert hat. Während diese lief, konnte ich Zugriffe auf die Signaling-Subdomain beobachten. Ich nehme an, dass dies darauf hindeutet, das der Signaling-Server benutzt wird.
VG
Jörg
Hi Jörg,
OK, dann scheint der Signaling Server zu funktionieren. Ansonsten würde hier auch keine Konferenz mit zwei Teilnehmern zustande kommen.
Von daher würde ich sagen: alles gut.
Gruß,
Jan
Hallo Jan,
danke für diese Anleitung.
Die Konfiguration hat geklappt, leider klappt die Videoübertragung aber nicht..
Was mich etwas verwirrt hat:
Warum gibt es die server.conf einmal unter
/etc/signaling/
und
/etc/nextcloud-spreed-signaling/
Hi Moritz,
die beiden Configs liegen darin begründet, dass für die systemd Unit die Config woanders hin kopiert wird. Dann kann im Falle, dass das GitHub-Repo nochmals gepulled wird, nichts überschrieben werden.
Wegen der Videoübertragung: Normalerweise funktioniert es entweder ganz oder gar nicht. Hier würde ich zunächst mal in die Browser-Console schauen, ob es hier irgendwelche Fehlermeldungen gibt und dann mit den Logs am Server weiter machen.
Gruß,
Jan
Danke für deine Antwort. Habe jetzt bemerkt dass es nur im Firefox nicht funktioniert. Im Chrome und über die App funktioniert es ohne Probleme.
bei service janus status habe ich allerdings folgende Meldungen:
[WARN] Unix Sockets server disabled (Janus API)
[WARN] Unix Sockets server disabled (Admin API)
[WARN] No Unix Sockets server started, giving up…
[WARN] The ‚janus.transport.pfunix‘ plugin could not be initialized
janus[1524]: Loading transport plugin ‚libjanus_nanomsg.so’…
anus[1524]: [WARN] Nanomsg server disabled (Admin API)
janus[1524]: JANUS Nanomsg transport plugin initialized!
janus[1524]: Nanomsg thread started
Ist das normal?
Hi Moritz,
das könnte daran liegen, dass Janus so konfiguriert ist, dass es rein lokal (localhost) läuft. Wenn Konferenzen zustande kommen, kannst du die Meldungen getrost ignorieren.
Gruß,
Jan
Alles klar danke!
Hast du viellecht eine Idee warum das in Firefox nicht funktioniert? Hab das gleiche Problem wenn ich den Signal Server weglasse und sogar das ganze mit einem öffentlichen STUN/TURN Server versuche
Hi Moritz,
Firefox scheint für WebRTC nicht optimal zu sein. Jitsi funktioniert mit dem Firefox auch nicht ideal. Mit NC Talk hatte ich mir Firefox bisher noch keine Probleme.
Gruß,
Jan
Guten Tag zusammen,
vielen Dank für die hervorragende Anleitung. Letztlich ist es mir gelungen, das Video Backend am laufen zu bekommen. Bei einem Test mit ca. 8 Clients ist mir aufgefallen, dass die CPU Last bei meinem Haupt-PC (einziger Computer, die restlichen Clients waren iOS und Android) sehr hoch war. Der Rechner ist jedoch nicht schwach bestückt, daher war ich erstaunt.
nload hat ergeben, dass der Signaling Server (darauf läuft auch NC) durchschnittlich 6MBits empfangen und 35MBits gesendet hat. Daraus würde ich schließen, dass der Signaling-Server (erstaunlich wenig) empfängt, aber an alle teilnehmenden Clients verteilt. Im Syslog und top ist auch ersichtlich, dass janus usw. fleißig am arbeiten ist. Ich hätte dennoch erwartet, dass die CPU Last geringer ist. Ist dies nur darauf zurückzuführen, dass alle eingehenden Videostreams vom Client decodiert werden müssen?
Zudem ist (als teilweise mehr als 10 Clients verbunden waren) aufgefallen, dass kurzzeitig die Fehlermeldung erschient, dass der Signaling-Server nicht erreichbar ist. Dies lies sich bei geringerer Last nicht mehr reproduzieren.
Der Signaling-Server ist ein 10-Kerner mit 64GB, also eigentlich keine schwache VM. Wie kann ich sichergehen, dass der Signaling-Server auch tatsächlich gegriffen hat, bzw. sind meine o.g. Beobachtungen Bestätigungen genug?
Vielen Dank nochmals und liebe Grüße an alle.
Hi Tobias,
NC Talk arbeitet meines Wissens nach als SFU, daher wird am Server nichts transkodiert. Daher wäre mal interessant, welche Prozesse genau so viel CPU schlucken.
Ob der Signaling Server „gegriffen“ hat, bekommt man recht leicht raus: Wenn dieser in den Talk-Einstellungen hinterlegt ist und eine Konferenz zustande kommt, läuft dies über den Signaling Server. Wenn irgendwas mit dem Signaling Server nicht passt, kommt keine Verbindung zustande.
Gruß,
Jan
Hallo Zusammen,
erstmal vielen Dank für die Anleitung, mit welcher ich erfolgreich einen Signaling-Server in Betrieb nehmen konnte. Ich bin nun etwas am verzweifeln, da ich eine Nextcloud-Instanz auf Docker-Basis aufgesetzt habe und diese versuche mit dem bestehenden Signaling-Server zu verheiraten. Bei einer normalen Instanz funktioniert die Anbindung an den Signaling-Server ohne Probleme. Bei der Docker-Variante wird mir zwar in den Einstellungen im Web-Interface angezeigt, das das HPA erfolgreich eingebunden ist, aber sobald ich eine Konferenz starten möchte kommt die Fehlermeldung „Fehler beim Aufbau der Signaling-Verbindung…“. Der Container der Nextcloud wir über einen nginx-Reverse-proxy angesprochen. Für den Nextcloud-Container selbst habe ich die folgenden Ports freigegeben (80,5349,8080,4222,3478). Einige aus lauter Verzweiflung ;). Ich bin mir ziemlich sicher, dass es irgendwas mit der Namensauflösung oder mit Ports zu tun hat. Aber es will einfach nicht klappen.
Hallo Robert,
wenn du es so wie im Tutorial aufgesetzt hast, dann läuft die Verbindung zum Signaling Server nur über Port 443. Der coturn-Port (5349 oder 3478) muss auch nur „outgoing“ offen sein.
Leider sagt die Fehlermeldung ja einfach nur „geht nicht“ – das ist ein bisschen wenig. Daher denke ich, dass hier kein Weg daran vorbei führt, mal in die Logs zu schauen:
Da sollte auf jeden Fall ein Hinweis zu finden sein, warum dies nicht funktioniert.
Gruß,
Jan
Hallo Jan,
es gibt eine neue Version des signaling Servers.
Könntest du diese vielleicht in das Tutorial aufnehmen?
Das wäre super!
Danke und Gruss,
Jakob
Hi Jakob,
danke für den Hinweis. Ich habe den Artikel mal bzgl. der Signaling Updates erweitert.
Allerdings kann ich bei der neuen Signaling-Version keine Features ausmachen, die ein Update empfehlenswert machen würden.
Gruß,
Jan
Hallo Jan,
ich werde den signaling Server bald auf 0.4 heben.
Soll ich auch Janus und/oder Nats updaten?
Danke und Gruss,
Jakob
Hi Jakob,
Janus wird ja schon über „apt upgrade“ auf dem aktuellsten Stand gehalten. Bei NATS kannst du dir einfach die aktuellste Version über Docker ziehen. Schaden tut es auch jeden Fall nicht.
Gruß,
Jan
Hallo Jan,
ich habe wieder einmal eine vielleicht hilfreiche Anmerkung für alle, die noch auf ubuntu 18.04 unterwegs sind.
Die Anleitung funktioniert auch für ubuntu 18.04 allerdings nur, wenn Janus und golang-go über Backports auf aktuellere Versionen geupdatet werden. Die Versionen aus ubuntu 18.04 reichen bei beiden Sachen nicht mehr.
Übrigens: Der Backport für Janus, den du zum Zeitpunkt dieses Kommentars in der Anleitung noch angibst, geht jetzt nicht mehr. Unter diesem Backport wurde der Support für Bionic (ubuntu 18.04) vor ein paar Tagen eingestellt.
Über launchpad.net lassen sich für beide Programme aber Backports finden, bei denen aber jeder für sich selbst entscheiden muss, ob er diesen vertraut oder nicht. Im Zweifel bleibt dann halt nur noch selbst kompilieren übrig.
Hi Steffen,
ja, dass der Support von 18.04 hier nicht mehr gegeben ist, habe ich vor ein paar Tagen auch mitbekommen.
Danke für deinen Hinweis, ich habe hier mal einen Hinweis im Artikel ergänzt.
Gruß,
Jan
Hello Jan!
Thank you very much for your contribution!
I’m working on building my signaling server right now, but I have a really silly question.
Is the signaling server being installed on the same server as Nextcloud or on a separate Virtual Machine for example?
Grateful!
Hello,
not a silly question at all!
You can install the signaling server in the same server as Nextcloud, but you could also use a separate machine. No real difference here because the request for the signaling server are terminated at the webserver.
Best regards,
Jan
Heyyy!!
hm also ich habe das jetzt versucht auf einen Server mit Openmediavault zu installieren!
bekomme die meldung in Talk „Fehler: Der Server hat nicht mit korrektem JSON geantwortet“
Konnte in google leider nichts finden mit dieser Fehlermeldung.
Hi,
da könnte der Endpunkt nicht korrekt konfiguriert werden. Was passiert, wenn du folgendes im Browser aufrufst (nur mit angepasster Domain): https://meinedomain.de/standalone-signaling/api/v1/welcome
Hier sollte dann eigentlich eine „Welcome-Antwort“ im JSON-Format kommen.
Gruß,
Jan
Ich bekomme auch die Fehlermeldung “ Fehler: Server hat nicht mit korrektem JSON geantwortet“. Was kann ich dagegen tun bzw wie behebe ich dies?
Bei mir wird beim aufrufen von https://meinedomain.de/standalone-signaling/api/v1/welcome folgendes angezeigt:
nextcloud-spreed-signaling „Welcome“
version „12a8fa98d08676922b3326c880414147746ade85“
Hi,
also die JSON-Response sieht hier eigentlich gut aus. Wo genau kommt hier diese Fehlermeldung „Fehler: Server hat nicht mit korrektem JSON geantwortet“? Direkt bei der Angabe der Signaling-Daten in den Admin-Einstellungen von Talk?
Gruß,
Jan
Bei den Admin-Einstellungen von Talk.
Allerdings kam nun ein neues Problem dazu, was mir nun sagt
„Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.“
Obwohl alles Läuft Nats, Janus, Signalling sowie Coturn etc
Hi,
„Service Unavailable“ klingt irgendwie nach einem HTTP 503 oder so. Da würde ich erst einmal bei den nginx-Logs mit der Fehlersuche beginnen. Daraufhin die Logs der ganzen Backend-Services durchforsten. Irgendwo sollte hier eine plausible Begründung aufgeführt sein, warum es zu einem Fehler kommt.
Gruß,
Jan
Hi Jan,
wenn ich mal mit einer Frage zum benchmark kommen darf….
Ich habe gerade das aktuelle Versionsupdate vom singaling reingepackt. Danach den Benchmark gestart (allowall ist auf true). Er sagt mir trotz vieler Fehlermeldungen (Unsupported Message type…snipped), dass alle Verbindungen established sind. In der Auswertung dann aber kommt nicht wirklich was richtiges bei raus (Stats: sent=10057753 (49058/sec), recv=200 (0/sec), delta=10057553). Das sieht irgendwie nicht korrekt aus.
Gestern Abend wollte ich ein meeting machen und obwohl wir beide im richtigen Room wahren, hat das System dies nicht realisiert und uns beide als einzigen in den Raum gebracht. Das obligatorische „Warten auf weitere Teilnehmer“ haben wir beide gesehen.
Hast Du da eine Idee?
Hi Stefan,
das klingt für mich so, als wenn da grundsätzlich etwas nicht passen würde. Der Benchmark ist hier nicht entscheidend, aber dass sich die Sessions anscheinend nicht „finden“ ist definitiv ein Fehler.
Da müsstest du mal die Logs aller beteiligten Komponenten durchforsten, was hier schief geht. Mehr kann ich da leider ohne genaue Analyse auch nicht dazu sagen.
Gruß,
Jan