|
|
| (140 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| = Komponenten des HighPerformanceBackends =
| | Nextcloud Talk '''H'''igh '''P'''erformance '''B'''ackend |
| '''TODO: ''' Grafische Darstellung der Kooperation der verwendeten Dienste | |
|
| |
|
| == Janus WebRTC gateway == | | = Beschreibung = |
| '''TODO: ''' Funktion und Aufgabe des Dienstes beschreiben
| | ; Komponenten |
| | | {| class="wikitable sortable" |
| WebRTC ist eine Abkürzung für '''Web''' '''R'''eal-'''T'''ime '''C'''ommunication, also Echtzeitkommunikation. WebRTC ist ein offener Standard der durch eine Sammlung von Kommunikationsprotokollen und Programmierschnittstellen definiert wird. Dieser Standard ermöglicht es Clients (wie beispielsweise Webbrowsern) eine '''direkte''' Verbindung zueinander aufzubauen. Der Vorteil besteht darin, daß keine zusätzliche Software installiert werden muß, wie es etwa bei Skype oder Zoom der Fall ist. Desweiteren werden Server-Ressourcen geschont. WebRTC läuft innerhalb der Browser-Sandbox und ist dadurch auch sicher - es werden keine PlugIns benötigt oder andere Prozesse getstartet. Damit die Clients voneinander erfahren, wie sie die direkte Verbindung zueinander aufbauen können, sind die Dienste eines Signaling-Servers notwendig.
| | |- |
| | | ! Komponente !! Aufgabe !! Link !! Beschreibung |
| === Weitere Informationen ===
| | |- |
| # https://github.com/meetecho/janus-gateway Janus
| | | Janus || WebRTC Gateway || [[Nextcloud/Talk:HPB:Janus]] || |
| | | |- |
| == NATS messaging server ==
| | | NATS || Messaging Server || [[Nextcloud/Talk:HPB:NATS]] || |
| '''TODO: ''' Funktion und Aufgabe des Dienstes beschreiben
| | |- |
| | | | Signaling-Servern || Signaling-Servern || [[Nextcloud/Talk:HPB:Signaling-Server]] || |
| === Weitere Informationen ===
| | |- |
| # https://nats.io/
| | | Webserver Frontend || Webserver Frontend || [[Nextcloud/Talk:HPB:Apache]] || |
| | | |} |
| == Nextcloud Talk signaling server ==
| |
| '''TODO: ''' Funktion und Aufgabe des Dienstes beschreiben
| |
| | |
| Der Signaling-Server ermöglicht Clients, die eine direkte Verbindung zueinander aufbauen wollen, den Austausch von Informationen, die dies gewährleisten. Möchte sich ein Client A mit einem Client B verbinden, '''signalisiert''' er dies dem Signaling-Server. Sollte Client B der Verbindungsanfrage zustimmen, übermittelt dieser seine Verbindungsinformationen an den Signaling-Server, der diese an Client A weiterreicht. Daraufhin erfolgt der direkte Verbindungsaufbau zwischen den Clients A und B.
| |
| | |
| === Weitere Informationen ===
| |
| # https://github.com/strukturag/nextcloud-spreed-signaling
| |
| | |
| == Apache Webserver ==
| |
| '''TODO: ''' Funktion und Aufgabe des Dienstes beschreiben
| |
| | |
| Der Apache Webserver ist einer der meistgenutzten Webserver im Internet. Die Software ist modular aufgebaut und dementsprechend durch die Installation von zusätzlichen Modulen in ihrer Funktionalität erweiterbar. Für den Signaling-Server wir eine eigene Subdomain erzeugt (signaling.foxtom.de) und Apache als Reverse-Proxy konfiguriert. Bei einem solchen Szenario beantwortet der Webserver die Anfragen nicht selbst, sondern übergibt sie an einen Backend-Server, der keine direkte Verbindung zum Internet hat. Der Backend-Server - in diesem Fall der Signaling-Server - bearbeitet die Anfrage und übergibt den Inhalt zurück an den Apache-Webserver, der damit die HTTP-Antwort erzeugt und zurück an den anfragenden Client sendet. Im Endeffekt wird hier ein Zugang zum Signaling-Server über HTTPS geschaffen.
| |
| | |
| === Weitere Informationen ===
| |
| '''TODO'''
| |
| # https://httpd.apache.org/docs/2.4/ Dokumentation zum Apache HTTP Server
| |
| # https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html Reverse Proxy
| |
| | |
| = Vorbereitung der Installation =
| |
| * Für die einzelnen Komponenten werden Schlüssel (keys) benötigt
| |
| * die im Vorfeld wie folgt erzeugt werden können:
| |
| | |
| '''TODO: ''' Was machen und bedeuten die folgenden Kommandos?
| |
| | |
| '''TODO: ''' Warum brauchen wir diese Schlüssel?
| |
| | |
| '''TODO: ''' Sind die vorgeschlagenen Einstellungen sicher genug?
| |
|
| |
|
| '''TODO: ''' Wie ist mit diesen Daten umzugehen?
| | = Installation = |
| | == Server-Daten == |
|
| |
|
| == <api-Key> für Janus == | | {| class="wikitable sortable" |
| openssl rand -base64 16
| | |- |
| | | ! Server !! URL |
| == Hash-Key ==
| | |- |
| openssl rand -hex 16
| | | Nextcloud-Server || cloud.foxtom.de |
| | | |- |
| == Block-Key ==
| | | TURN-Server || turn.foxtom.de:5349 |
| openssl rand -hex 16
| | |- |
| | | | Signaling Server || signaling.foxtom.de |
| == Secret Key für die Nextcloud ==
| |
| openssl rand -hex 16
| |
| | |
| == Schlüssel für den TURN-Server ==
| |
| * Talk-Einstellungen der Nextcloud
| |
| '''TODO:''' Beschreibung des Klickwegs als Text
| |
| '''TODO:''' Screenshot hinzufügen
| |
| | |
| Sofern bereits ein TURN-Server installiert ist, kann der benötigte Schlüssel im Administrator-Bereich der Nextcloud ausgelesen werden: Einstellungen >> Talk.
| |
| Über den Link: https://cloud.itw-berlin.net/settings/admin/talk gelangt man direkt zu den Einstellungen. Der Schlüssel findet sich auch in der Datei /etc/turnserver.conf (static-auth-secret=<Schlüssel>).
| |
| | |
| {|
| |
| | [[Datei:TURN-Server-Key.png | links | 800px | TURN-Server-Konfiguration im Administrator-Bereich der Nextcloud-Talk-App]] | |
| |} | | |} |
|
| |
|
| == Server-Adressen == | | = Konfiguration = |
| '''Nextcloud-Server:''' cloud.itw-berlin.net | | == Schlüssel (keys) erstellen == |
| '''TURN-Server:''' cloud.itw-berlin.net:5349 | | {| class="wikitable sortable" |
| '''Signaling Server:''' signaling.foxtom.de | | |- |
| | | ! Aufgabe !! Befehl |
| = Janus =
| | |- |
| == Installation ==
| | | Api-Key für Janus || openssl rand -base64 16 |
| apt install janus | | |- |
| | | | Hash-Key || openssl rand -hex 16 |
| == Konfiguration ==
| | |- |
| === /etc/janus/janus.jcfg ===
| | | Block-Key || openssl rand -hex 16 |
| ... | | |- |
| stun_server = "cloud.itw-berlin.net" | | | Secret Key für die Nextcloud || openssl rand -hex 16 |
| stun_port = 5349 | | |} |
| ... | |
| full_trickle = true | |
| ... | |
| turn_server = "cloud.itw-berlin.net" | |
| turn_port = 5349 | |
| ... | |
| turn_rest_api_key = "<api-Key>" | |
| ...
| |
|
| |
|
| === /etc/janus/janus.transport.http.jcfg ===
| | ;siehe auch '''[[Openssl]]''' |
| Janus-Server soll nur das lokale Interface abhören
| |
| ...
| |
| interface = "lo"
| |
| ...
| |
|
| |
|
| === /etc/janus/janus.transport.websockets.jcfg === | | == Einbinden in Nextcloud Talk == |
| '''TODO: '''Warum muss das hier nochmals konfiguriert werden? | | siehe '''[[Nextcloud/Talk:HPB:Einbinden in Nextcloud Talk]]''' |
|
| |
|
| Janus-Server soll nur das lokale Interface abhören
| | == Firewall konfigurieren == |
| ...
| | # apt install ufw |
| ws_interface = "lo"
| |
| ... | |
|
| |
|
| == Dienst starten ==
| | # ufw allow http |
| '''TODO: ''' Gibt es eine Möglichkeit, dass ''systemctl start'' direkt eine Statusmeldung ausgibt?
| | # ufw allow https |
| | # ufw allow ssh |
| | # ufw allow 5349/tcp |
| | # ufw allow 5349/udp |
|
| |
|
| Der Janus-Server kann mit dem Befehl systemctl start/stop manuell gestartet bzw. angehalten werden. Eine Ausgabe eventueller Fehler erhält man jedoch nicht. Zur Fehlersuche läßt sich das Programm jedoch manuell starten, indem mit der Option '''debug-level''' festgelegt werden kann, wie detailliert die Ausgabe erfolgen soll.
| | # ufw enable |
|
| |
|
| # janus --debug-level=<1..7> | | # ufw status |
| | | Status: active |
| # systemctl start janus | |
| | |
| == Status prüfen ==
| |
| '''TODO: ''' Was bedeutet diese Ausgabe?
| |
| | |
| '''TODO: ''' Wie ist der gemeldete Fehler zu korrigieren?
| |
| | |
| '''TODO: ''' Welche Bedeutung haben die einzelnen Warnungen?
| |
| | |
| # '''systemctl status janus'''
| |
| | | |
| ● janus.service - Janus WebRTC gateway | | To Action From |
| Loaded: loaded (/lib/systemd/system/janus.service; enabled; vendor preset: enabled)
| | -- ------ ---- |
| Active: active (running) since Wed 2021-01-06 23:53:56 CET; 12s ago
| | 80/tcp ALLOW Anywhere |
| Docs: https://janus.conf.meetecho.com/docs/index.html | | 443/tcp ALLOW Anywhere |
| Main PID: 10220 (janus)
| | 22/tcp ALLOW Anywhere |
| Tasks: 24 (limit: 2296)
| | 5349/tcp ALLOW Anywhere |
| Memory: 11.1M
| | 5349/udp ALLOW Anywhere |
| CGroup: /system.slice/janus.service
| | 80/tcp (v6) ALLOW Anywhere (v6) |
| └─10220 /usr/bin/janus -o | | 443/tcp (v6) ALLOW Anywhere (v6) |
| | | 22/tcp (v6) ALLOW Anywhere (v6) |
| Jan 06 23:53:57 signaling janus[10220]: '''[ERR] [config.c:janus_config_parse:191] -- Error reading configuration file 'janus.transport.rabbitmq.cfg'... error 2 (No such file or directory)''' | | 5349/tcp (v6) ALLOW Anywhere (v6) |
| Jan 06 23:53:57 signaling janus[10220]: RabbitMQ SSL support disabled | | 5349/udp (v6) ALLOW Anywhere (v6) |
| Jan 06 23:53:57 signaling janus[10220]: '''[WARN] RabbitMQ support disabled (Janus API)'''
| |
| Jan 06 23:53:57 signaling janus[10220]: '''[WARN] RabbitMQ support disabled (Admin API)'''
| |
| Jan 06 23:53:57 signaling janus[10220]: '''[WARN] RabbitMQ support disabled for both Janus and Admin API, giving up'''
| |
| Jan 06 23:53:57 signaling janus[10220]: '''[WARN] The 'janus.transport.rabbitmq' plugin could not be initialized'''
| |
| Jan 06 23:53:57 signaling janus[10220]: '''[WARN] libnice version outdated: 0.1.14 installed, at least 0.1.15 recommended'''
| |
| Jan 06 23:53:57 signaling janus[10220]: HTTP transport timer started
| |
| Jan 06 23:54:09 signaling janus[10220]: Creating new session: 7609464843575521; 0x7f1b4c001db0
| |
| Jan 06 23:54:09 signaling janus[10220]: Creating new handle in session 7609464843575521: 3636178337595333; 0x7f1b4c001db0 0x7f1b4c0031a0
| |
|
| |
|
| == Debugging == | | == Dateien == |
| === Log prüfen ===
| |
| === Debug-/Loglevel einstellen ===
| |
|
| |
|
| = NATS = | | = Anwendung = |
| == Installation ==
| |
| === Repository hinzufügen ===
| |
| '''TODO: ''' Ausgabe der Befehle hinzufügen
| |
|
| |
|
| Der folgende Befehl erzeugt keine Ausgabe. Mit ihm wird der öffentliche Schlüssel des Repositorys bezogen und im Verzeichnis /etc/apt/trusted.gpg.d abgelegt:
| | = Sicherheit = |
| | | = Dokumentation = |
| # curl -sL -o /etc/apt/trusted.gpg.d/morph027-nats-server.asc https://packaging.gitlab.io/nats-server/gpg.key
| | == Projekt == |
| | | # https://github.com/strukturag/nextcloud-spreed-signaling |
| Der nächste Befehl fügt der Konfiguration des Paketmanagers das Repository des NATS-Servers hinzu. Es wird im Verzeichnis /etc/apt/sources.list.d die Datei morph027-nats-server.list erstellt und der einzutragende Inhalt ausgegeben:
| |
| | |
| # echo "deb https://packaging.gitlab.io/nats-server nats main" | tee /etc/apt/sources.list.d/morph027-nats-server.list
| |
| | |
| === Installation durchführen ===
| |
| # apt update
| |
| # apt install nats-server
| |
| | |
| == Konfiguration == | |
| === /etc/nats/nats.conf === | |
| '''TODO: '''Was machen diese Befehle?
| |
| | |
| '''TODO: '''Warum sollte man hier sudo und nicht root benutzen?
| |
| | |
| '''TODO: '''Bitte Warum sollte man hier sudo und nicht root benutzen?
| |
| install
| |
| | |
| Mit dem folgenden Befehl wird wird das Verzeichnis /etc/nats erzeugt und dieses dem Besitzer sowie der Gruppe nats zugewiesen:
| |
| | |
| # install -d -o nats -g nats /etc/nats
| |
| | |
| Anschließend wird (als Benutzer nats) die Konfigurationsdatei für den NATS-Server erzeugt, die nur einen Eintrag erhält (listen: 127.0.0.1:4222).
| |
| | |
| # sudo -u nats echo "listen: 127.0.0.1:4222" > /etc/nats/nats.conf
| |
| | |
| == Dienst starten ==
| |
| sudo systemctl start nats-server
| |
| sudo systemctl status nats-server
| |
|
| |
| ● nats-server.service - NATS messaging server
| |
| Loaded: loaded (/lib/systemd/system/nats-server.service; enabled; vendor preset: enabled)
| |
| Active: active (running) since Thu 2021-01-07 00:00:02 CET; 9s ago
| |
| Docs: https://docs.nats.io/nats-server/
| |
| Main PID: 10269 (nats-server)
| |
| Tasks: 6 (limit: 2296)
| |
| Memory: 6.5M
| |
| CGroup: /system.slice/nats-server.service
| |
| └─10269 /usr/bin/nats-server --config /etc/nats/nats.conf
| |
|
| |
| Jan 07 00:00:02 signaling systemd[1]: Started NATS messaging server.
| |
| Jan 07 00:00:02 signaling nats-server[10269]: [10269] 2021/01/07 00:00:02.815032 [INF] Starting nats-server version 2.1.9
| |
| Jan 07 00:00:02 signaling nats-server[10269]: [10269] 2021/01/07 00:00:02.815675 [INF] Git commit [7c76626]
| |
| Jan 07 00:00:02 signaling nats-server[10269]: [10269] 2021/01/07 00:00:02.816182 [INF] Listening for client connections on localhost:4222
| |
| Jan 07 00:00:02 signaling nats-server[10269]: [10269] 2021/01/07 00:00:02.816342 [INF] Server id is NDBF27HOCXESCE4M7QWO6T3ZWCRQPRSXLJWWJDCTXFGD36LOFCTZJAYR
| |
| Jan 07 00:00:02 signaling nats-server[10269]: [10269] 2021/01/07 00:00:02.816475 [INF] Server is ready
| |
| | |
| = Signaling Server =
| |
| Zur Installation des Servers wird das Paket '''golang-go''' benötigt, welches über die Paketverwaltung installiert werden kann:
| |
| apt install golang-go
| |
| | |
| == Installation ==
| |
| Die benötigten Quellpakete werden über GitHub bezogen und hier im Verzeichnis /usr/src abgelegt:
| |
| cd /usr/src
| |
| git clone https://github.com/strukturag/nextcloud-spreed-signaling.git
| |
| cd /usr/src/nextcloud-spreed-signaling
| |
| | |
| Der anschließende Befehl '''make build''' erstellt das Programm '''bin/signaling'''
| |
| make build
| |
| | |
| == Konfiguration ==
| |
| Beispielkonfiguration
| |
| /usr/src/nextcloud-spreed-signaling/server.conf.in
| |
| | |
| Diese Datei wird nach /etc/signaling/server.conf kopiert:
| |
| mkdir -p /etc/signaling
| |
| cd /usr/src/nextcloud-spreed-signaling
| |
| cp server.conf.in /etc/signaling/server.conf
| |
| | |
| Um den Signaling-Server als Systemdienst installieren zu können, wird ein Benutzer und eine Gruppe angelegt:
| |
| groupadd signaling
| |
| useradd --system --gid signaling --shell /usr/sbin/nologin --comment "Standalone signaling server for Nextcloud Talk." signaling
| |
| | |
| und die Berechtigungen angepasst:
| |
| chmod 600 /etc/signaling/server.conf
| |
| chown signaling: /etc/signaling/server.conf
| |
| | |
| Entsprechend den lokalen Begebenheiten wir diese Datei wie folgt editiert:
| |
| listen = 127.0.0.1:8080
| |
| ...
| |
| [sessions]
| |
| hashkey = <Hash-Key>
| |
| ...
| |
| blockkey = <Block-Key>
| |
| ...
| |
| [backend]
| |
| backends = backend1
| |
|
| |
| [backend1]
| |
| url = https://cloud.itw-berlin.net
| |
| ...
| |
| secret = <Nextcloud Secret Key>
| |
| ...
| |
| [nats]
| |
| url = nats://localhost:4222
| |
| ...
| |
| [mcu]
| |
| type = janus
| |
| ...
| |
| url = ws://127.0.0.1:8188
| |
| ...
| |
| [turn]
| |
| apikey = <api-key>
| |
| secret = <TURN-Server-Key>
| |
| servers = turn:cloud.itw-berlin.net:5349?transport=udp,turn:cloud.itw-berlin.net:5349?transport=tcp
| |
| ...
| |
| | |
| Zum automatischen Starten des Signaling-Servers als Systemdienst werden die folgenden Befehle ausgeführt:
| |
| cp dist/init/systemd/signaling.service /etc/systemd/system/signaling.service
| |
| systemctl enable signaling.service
| |
| systemctl start signaling.service
| |
| | |
| == Starten des Signaling-Servers ==
| |
| Ist Janus-Server bereits gestartet, kann der Signaling-Server für einen Test direkt aufgerufen werden:
| |
| sudo /usr/src/nextcloud-spreed-signaling/bin/signaling --config /etc/signaling/server.conf
| |
|
| |
| 2021-01-06 15:11:51.109402 I | main.go:130: Starting up version 64cccab641874b3e688c1eb9029b5bb9215741e5/go1.11.6 as pid 9913
| |
| 2021-01-06 15:11:51.109824 I | main.go:139: Using a maximum of 1 CPUs
| |
| 2021-01-06 15:11:51.111647 I | natsclient.go:116: Connection established to nats://localhost:4222 (ND2IPCPXAOZMW5QPQ3R476UVGKI42RUNGIQ7YOHLNHK3QLTS7HXIVIWH)
| |
| 2021-01-06 15:11:51.111713 I | backend_configuration.go:77: Backend backend1 added for https://cloud.itw-berlin.net/
| |
| 2021-01-06 15:11:51.111723 I | hub.go:177: Using a maximum of 8 concurrent backend connections per host
| |
| 2021-01-06 15:11:51.111739 I | hub.go:184: Using a timeout of 10s for backend connections
| |
| 2021-01-06 15:11:51.111759 I | hub.go:270: Not using GeoIP database
| |
| 2021-01-06 15:11:51.113242 I | mcu_janus.go:289: Connected to Janus WebRTC Server 0.9.2 by Meetecho s.r.l.
| |
| 2021-01-06 15:11:51.113260 I | mcu_janus.go:293: Found JANUS VideoRoom plugin 0.0.9 by Meetecho s.r.l.
| |
| 2021-01-06 15:11:51.113269 I | mcu_janus.go:299: Data channels are supported
| |
| 2021-01-06 15:11:51.113274 I | mcu_janus.go:305: Full-Trickle is enabled
| |
| 2021-01-06 15:11:51.113280 I | mcu_janus.go:308: Maximum bandwidth 1048576 bits/sec per publishing stream
| |
| 2021-01-06 15:11:51.113285 I | mcu_janus.go:309: Maximum bandwidth 2097152 bits/sec per screensharing stream
| |
| 2021-01-06 15:11:51.114259 I | mcu_janus.go:315: Created Janus session 6900302758812903
| |
| 2021-01-06 15:11:51.114951 I | mcu_janus.go:322: Created Janus handle 7778710372665701
| |
| 2021-01-06 15:11:51.115064 I | main.go:226: Using janus MCU
| |
| 2021-01-06 15:11:51.115132 I | hub.go:357: Using a timeout of 10s for MCU requests
| |
| 2021-01-06 15:11:51.115192 I | backend_server.go:94: Using configured TURN API key
| |
| 2021-01-06 15:11:51.115250 I | backend_server.go:95: Using configured shared TURN secret
| |
| 2021-01-06 15:11:51.115315 I | backend_server.go:97: Adding "turn:cloud.itw-berlin.net:5349?transport=udp" as TURN server
| |
| 2021-01-06 15:11:51.115372 I | backend_server.go:97: Adding "turn:cloud.itw-berlin.net:5349?transport=tcp" as TURN server
| |
| 2021-01-06 15:11:51.115420 I | backend_server.go:104: No IPs configured for the stats endpoint, only allowing access from 127.0.0.1
| |
| 2021-01-06 15:11:51.115613 I | main.go:302: Listening on 127.0.0.1:8080
| |
| | |
| | |
| == Debugging ==
| |
| | |
| === Test-Client ===
| |
| | |
| Zum Testen des Signaling-Servers wird ein einfaches Client-Programm zur Verfügung gestellt, welches jedoch zuvor kompiliert werden muß:
| |
| | |
| $ cd /usr/src/nextcloud-spreed-signaling/src/client
| |
| $ make client
| |
| | |
| Das Programm befindet sich im Anschluß im Verzeichnis /usr/src/nextcloud-spreed-signaling/bin/ und kann mit folgenden Optionen ausgeführt werden:
| |
| | |
| * -addr <http-Service-Adresse> (Standard ist localhost:28080)
| |
| * -config <Konfigurationsdatei>
| |
| * -maxClients <Anzahl der Client-Verbindungen> (Standardwert ist 100)
| |
| | |
| '''Wichtig''': Vor dem Ausführen des Programms muß die Konfigurationsdatei des Signaling-Servers dahingehend editiert werden, daß nicht nur das eigentliche Backend zugelassen wird, sondern alle. Dazu muß in der Datei /etc/signaling/server.conf der Eintrag "'''allowall = true'''" vorhanden sein. Nachdem Neustart des Signaling-Servers kann der Test-Client gestartet werden:
| |
| | |
| $ sudo systemctl restart signaling
| |
| $ sudo ./client -addr localhost:8080 -config /etc/signaling/server.conf
| |
| | |
| Bei der derzeitigen Implementierung des (laufenden) Signaling-Servers werden jedoch Fehler erzeugt:
| |
| | |
| 2021-02-01 12:53:51.717590 I | Using a maximum of 1 CPUs
| |
| 2021-02-01 12:53:51.717978 I | Backend server running on http://95.217.178.11:33031
| |
| 2021-02-01 12:53:51.718066 I | Connecting to [ws://localhost:8080/spreed]
| |
| 2021-02-01 12:53:51.718130 I | Starting 100 clients
| |
| 2021-02-01 12:53:51.720849 I | Unsupported message type: {Id: Type:error Error:Incomplete OCS response Hello:<nil> Bye:<nil> Room:<nil> Message:<nil> Control:<nil> Event:<nil>}
| |
| ...
| |
| 2021-02-01 12:53:51.856629 I | Unsupported message type: {Id: Type:error Error:Incomplete OCS response Hello:<nil> Bye:<nil> Room:<nil> Message:<nil> Control:<nil> Event:<nil>}
| |
| 2021-02-01 12:53:51.857998 I | Clients created
| |
| 2021-02-01 12:53:51.859424 I | Unsupported message type: {Id: Type:error Error:Incomplete OCS response Hello:<nil> Bye:<nil> Room:<nil> Message:<nil> Control:<nil> Event:<nil>}
| |
| 2021-02-01 12:53:54.072980 I | Received bye: &{Reason:hello_timeout}
| |
| ...
| |
| 2021-02-01 12:53:54.090515 I | Received bye: &{Reason:hello_timeout}
| |
| | |
| | |
| === Log prüfen ===
| |
| === Debug-/Loglevel einstellen ===
| |
| | |
| = Frontend-Webserver (Apache) =
| |
| * '''[Normalerweise?]''' wird der Signalisierungsserver hinter einem Webserver ausgeführt, der das SSL-Protokoll ausführt oder als Load Balancer für mehrere Signalisierungsserver fungiert.
| |
| | |
| == Installation ==
| |
| | |
| == Konfuguration ==
| |
| * Um den Apache-Webservice als Frontend für den Signalisierungsserver zu konfigurieren
| |
| * müssen die Module mod_proxy_http und mod_proxy_wstunnel aktiviert sein
| |
| * damit WebSocket- und API-Backend-Anforderungen weitergeleitet werden können
| |
| | |
| # a2enmod proxy
| |
| # a2enmod proxy_http
| |
| # a2enmod proxy_wstunnel
| |
| | |
| == Virtual-Host einrichten ==
| |
| Jetzt kann die Virtual-Host-Konfiguration von Apache erweitert werden, um Anfragen an den Signalisierungsserver weiterzuleiten (vorausgesetzt, der Server wird auf der lokalen Schnittstelle an Port 8080 ausgeführt). Für signaling.foxtom.de sollte die Datei /etc/apache2/sites-available/signaling.foxtom.de.conf wie folgt editiert werden:
| |
| | |
| <IfModule mod_ssl.c>
| |
| <VirtualHost *:443>
| |
|
| |
| ServerAdmin webmaster@localhost
| |
| DocumentRoot /var/www/html
| |
|
| |
| ErrorLog ${APACHE_LOG_DIR}/error.log
| |
| CustomLog ${APACHE_LOG_DIR}/access.log combined
| |
|
| |
| ServerName signaling.foxtom.de
| |
| SSLCertificateFile /etc/letsencrypt/live/signaling.foxtom.de/fullchain.pem
| |
| SSLCertificateKeyFile /etc/letsencrypt/live/signaling.foxtom.de/privkey.pem
| |
| Include /etc/letsencrypt/options-ssl-apache.conf
| |
|
| |
| ProxyErrorOverride On
| |
| DocumentRoot "/var/www/html"
| |
| ProxyPass /error/ !
| |
| ErrorDocument 404 /error/404_proxy.html
| |
| ProxyPass / "http://127.0.0.1:8080/"
| |
| RewriteEngine on
| |
| RewriteCond %{HTTP:Upgrade} websocket [NC]
| |
| RewriteCond %{HTTP:Connection} upgrade [NC]
| |
| RewriteRule ^/?(.*) "ws://127.0.0.1:8080/$1" [P,L]
| |
|
| |
| </VirtualHost>
| |
| </IfModule>
| |
| | |
| == Debugging ==
| |
| === Log prüfen ===
| |
| === Debug-/Loglevel einstellen ===
| |
| | |
| = Firewall konfigurieren =
| |
| '''TODO:''' Welche Ports müssen geöffnet sein?
| |
| | |
| '''TODO:''' Welche Schritte sind notwendig, um dies mit ufw zu tun?
| |
| | |
| '''TODO:''' Wie kann die Konfiguration geprüft werden?
| |
| | |
| = Einbinden in Nextcloud Talk =
| |
| * 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
| |
| | |
| Die Option'' SSL Zertifikat überprüfen'' sollte hier aktiviert werden, wenn der Signaling Server über ein valides Zertifikat verfügt (zum Beispiel Let’s Encrypt).
| |
| | |
| | |
| Quelle: https://nichteinschalten.de/signalisierungsserver-fuer-nextcloud-aufsetzen-how-to/
| |
| | |
| netstat -tulpen | grep 8080
| |
| | |
| [http://nats.io/documentation/tutorials/gnatsd-install/ http://nats.io/documentation/tutorials/gnatsd-install/]
| |
| | |
| | |
| [https://github.com/meetecho/janus-gateway https://github.com/meetecho/janus-gateway]) can be used to act as a WebRTC gateway. See the documentation of Janus on how to configure and run the server. At least the <tt>VideoRoom</tt> plugin and the websocket transport of Janus must be enabled.
| |
| | |
| The signaling server uses the <tt>VideoRoom</tt> plugin of Janus to manage sessions. All gateway details are hidden from the clients, all messages are sent through the signaling server. Only WebRTC media is exchanged directly between the gateway and the clients.
| |
| | |
| Edit the <tt>server.conf</tt> and enter the URL to the websocket endpoint of Janus in the section <tt>[mcu]</tt> and key <tt>url</tt>. During startup, the signaling server will connect to Janus and log information of the gateway.
| |
| | |
| The maximum bandwidth per publishing stream can also be configured in the section <tt>[mcu]</tt>, see properties <tt>maxstreambitrate</tt> and <tt>maxscreenbitrate</tt>.
| |
| | |
| = Test und Benchmarking =
| |
| == Benchmark client ==
| |
| === Installation ===
| |
| === Konfiguration ===
| |
| === Anwendung ===
| |
| === Bewertung der Ergebinisse ===
| |
|
| |
|
| = Links = | | = Links = |
| == Intern == | | == Siehe auch == |
| '''TODO: '''Links zu relevanten internen Artikeln hinzufügen
| | # https://de.wikipedia.org/wiki/WebRTC |
|
| |
|
| == Extern == | | == Weblinks == |
| '''TODO: ''' Linke beschreiben und ich Gruppen aufteilen
| |
| # https://github.com/strukturag/nextcloud-spreed-signaling
| |
| # https://de.wikipedia.org/wiki/WebRTC
| |
| # https://decatec.de/home-server/nextcloud-talk-mit-eigenem-signaling-server-high-performance-backend/ | | # https://decatec.de/home-server/nextcloud-talk-mit-eigenem-signaling-server-high-performance-backend/ |
| # https://decatec.de/home-server/nextcloud-auf-ubuntu-server-20-04-lts-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/ | | # https://decatec.de/home-server/nextcloud-auf-ubuntu-server-20-04-lts-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/ |
| Zeile 442: |
Zeile 99: |
| # https://decatec.de/home-server/docker-auf-ubuntu-server/ | | # https://decatec.de/home-server/docker-auf-ubuntu-server/ |
|
| |
|
| [[Kategorie:Entwurf]]
| | |
| [[Kategorie:Nextcloud]] | | |
| | |
| | |
| | [[Kategorie:Nextcloud/Talk]] |