Signalisierungsserver für Nextcloud aufsetzen: How-To

24

Vor kurzem wurde die Software zum Betrieb von Nextcloud Talk in größeren Nextcloudumgebungen als Open Source veröffentlicht: man braucht einen eigenen Signalisierungsserver, um mit mehreren parallel Leuten effektiv über Nextcloud Talk arbeiten zu können. Per Default wird der interne verwendet. Wie wird dieser Signalisierungsserver nun aufgesetzt?

Voraussetzungen

Ich würde sowohl einen STUN Server als auch den Signalisierungsserver auf eigenen VMs betreiben. Ich würde hier direkt die Hetzner Cloud empfehlen: preiswert, performant und sehr einfach zum Hochskalieren. Zwei kleine Maschinen reichen für den Anfang. Den STUN Server solltest du bereits auf einer anderen Maschine gesondert fertig installiert haben.

Bitte beachte, dass ich bisher auch nur einen laufenden Signalisierungsserver hinbekommen habe, aber noch nicht tiefer getestet und Security Hardening betrieben habe. Es sind die ersten Gehversuche, die ich hier zeigen möchte.

Installation der Services

Ich gehe hier von Debian 10 aus. Als erstes solltest du Docker, nginx und sonstige Grundprogramme wie git, unzip etc. installiert haben.

Den Signaling Server direkt von Github selbst kompilieren:


apt install git automake golang build-essential certbot nginx apt-transport-https ca-certificates curl gnupg-agent software-properties-common
git clone https://github.com/strukturag/nextcloud-spreed-signaling.git
cd nextcloud-spreed-signaling/
make build
cp bin/signaling /usr/bin/


Nun die Konfigurationsdatei aus dem Repo an die richtige Stelle kopieren.:


mkdir /etc/signaling/
cp server.conf.in /etc/signaling/server.conf
useradd --system --shell /usr/sbin/nologin --comment "Standalone signaling server for Nextcloud Talk." signaling
chown signaling: /etc/signaling/server.conf
chmod 600 /etc/signaling/server.conf


Anschließend den Service für den Signaling Server einrichten und vorher natürlich die Systemd Datei entsprechend eurer Pfade anpassen, wenn abweichend:


cp dist/init/systemd/signaling.service /etc/systemd/system/signaling.service
systemctl daemon-reload
systemctl enable signaling

Nun müssen wir die einzelnen Services für den Signaling Server aufsetzen. Zunächst den NATS Server, den ich der Einfachheit halber mit Docker installiert habe, da es kein Repo gibt:


curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian \
$(lsb_release -cs) \
stable"
apt-get update
apt-get install docker-ce docker-ce-cli containerd.io
docker run --restart=always --name='natsserver' -d -p 4222:4222 -ti nats:latest

Außerdem brauchen wir einen Janus Server:


apt install janus

Nun muss der Service konfiguriert werden: nano /etc/janus/janus.jcfg
Hier habe ich mich an diese Anleitung gehalten und folgende Werte gesetzt:  turn_rest_api_key (mittels openssl rand -base64 16 erstellen, ist derselbe String wie bei apikey in der signaling conf!), full_trickle = true und die ssl Zeilen auskommentieren.

general: {
        configs_folder = "/etc/janus"                   # Configuration files folder
        plugins_folder = "/usr/lib/x86_64-linux-gnu/janus/plugins"                      # Plugins folder
        transports_folder = "/usr/lib/x86_64-linux-gnu/janus/transports"        # Transports folder
        events_folder = "/usr/lib/x86_64-linux-gnu/janus/events"                        # Event handlers folder
        debug_level = 4                                                 # Debug/logging level, valid values are 0-7
        server_name = "Janus Speibox"# Public name of this Janus instance
}
# Certificate and key to use for DTLS (and passphrase if needed).
#certificates: {
#       cert_pem = "/etc/ssl/certs/ssl-cert-snakeoil.pem"
#       cert_key = "/etc/ssl/certs/ssl-cert-snakeoil.key"
        #cert_pwd = "secretpassphrase"
#}
nat: {
        nice_debug = false
        full_trickle = true
        turn_rest_api_key = "apikey from server.conf"
}

Damit kann der Dienst gestartet werden.

Es braucht natürlich noch einen coturn Server. Dieser wird ganz simpel mit apt install coturn installiert und sollte wie bereits erwähnt nach dieser Anleitung schon installiert sein.

Konfiguration des Signaling Servers

Abschließend müssen wir den Signaling Server noch konfigurieren: nano /etc/signaling/server.conf:

  • hashkey mit openssl rand -hex 16 generieren
  • blockkey mit openssl rand -hex 16 generieren
  • internalsecret ebenfalls mit einem String Generator setzen
  • unter allowed alle Hostnamen eintragen, die dieses Backend verwenden dürfen
  • direkt darunter bei secret ein Secret generieren. Das wird später bei Nextcloud in den Settings eingetragen
  • connectionsperhost sollte adaptiert werden
  • unter nats wird die url so gesetzt: url = nats://localhost:4222
  • bei mcu wird die url so gesetzt: url = ws://0.0.0.0:8188 (Janus läuft nicht localhost, ist noch ein offenes Security Thema)
  • unter turn wird apikey mit dem gleichen Wert vom Janus Server (turn_rest_api_key)  gesetzt
  • das secret in der Rubrik turn bekommt den gleichen Wert wie static-auth-secret des Turnserver gesetzt
  • bei servers werden alle Turnserver kommasepariert so gesetzt: turn:116.202.113.XXX:5349?transport=tcp

Nun sollte service signaling start erfolgreich sein.

nginx vhost

Ich habe meine nginx Installation nicht groß konfiguriert und möchte nur kurz meinen ssl vhost darstellen, den ihr auch 1:1 aus dem offiziellen Repo übernehmen könnt:


upstream signaling {
    server 127.0.0.1:8080;
}

server {
    listen 443 ssl http2;
    server_name signaling.xy.de;
        ssl_certificate /etc/letsencrypt/live/signaling.xy.de/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/signaling.xy.de/privkey.pem;
        add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

    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;
    }
}

Wenn ihr nun alles richtig gemacht habt, sollte curl -i https://signaling.xy.de/standalone-signaling/api/v1/welcome folgende Antwort liefern:

HTTP/1.1 200 OK
Date: Thu, 05 Jul 2018 09:28:08 GMT
Server: nextcloud-spreed-signaling/1.0.0
Content-Type: application/json; charset=utf-8
Content-Length: 59

{"nextcloud-spreed-signaling":"Welcome","version":"1.0.0"}

Nextcloud Integration

Installiert die Beta Version von Nextcloud Talk – am besten zum Testen mal in einer eigenen Installation auf dem Beta Release Channel für Nextcloud 19 (für Nextcloud 18 habe ich das nicht probiert). In den Einstellungen von Nextcloud im Reiter Talk nun folgende Konfiguration setzen:

STUN und Signaling Server laufen bei mir auf getrennten Maschinen. Das Gemeinsame Geheimnis ist das secret aus der Signaling Server conf.


Du möchtest regelmäßig Neuigkeiten von meinem Blog? Trag dich für meinen Newsletter ein:

24 Comments
  1. DarkSchnitzel says

    Hi,

    ich scheitere noch an der Integration von janus mit coturn. Coturn selber scheint zu funktionieren, Nextcloud meldet das funktionierende ICE Kandidaten gesendet werden. Jedoch habe ich in janus noch schwierigkeiten mit der REST API. Koenntest du dazu vielleicht noch einmal beschreiben was du dort genau eingetragen hast? Der link https://morph027.gitlab.io/post/nextcloud-spreed-signaling ist leider nicht mehr verfuegbar (404 nach anmeldung bei gitlab)

    LG

    1. Benjamin Hartwich says

      Ich habe die wesentlichen Auszüge nun ergänzt. Du musst den turn_rest_api_key = apikey von der Signaling server.conf setzen. Ansonsten sagt dir die Log ganz genau, wo es hakt.

      1. DarkSchnitzel says

        Hallo Benjamin,

        danke für die schnelle Antwort. coturn, janus und das signaling laufen alle auf dme gleichen ubuntu 20.04 Host. Das mit dem Api Key verstehe ich, wenn jedoch nur dieser gesetzt ist wird die turn rest api deaktiviert:
        TURN REST API backend: (disabled)

        Der Abschnitt den ich meine ist folgender in meiner janus.jcfg:
        # … or you can make use of the TURN REST API to get info on one or more
        # TURN services dynamically. This makes use of the proposed standard of
        # such an API (https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00)
        # which is currently available in both rfc5766-turn-server and coturn.
        # You enable this by specifying the address of your TURN REST API backend,
        # the HTTP method to use (GET or POST) and, if required, the API key Janus
        # must provide.
        #turn_rest_api = „http://domain.de“
        turn_rest_api_key = „shared_secret_turnserver“
        #turn_rest_api_method = „GET“

        Ich kann auch nirgends eine Info finden wo genau die api url genannt wird.
        LG

        1. Benjamin Hartwich says

          Ich habe wie erwähnt nur den turn_rest_api_key verwendet und gesetzt. Mehr wird auch in der offiziellen Anleitung der StrukturAG nicht erwähnt. Ich arbeite mit Debian10. Ich kann daher nicht genau sagen, was nun eigentlich das Problem ist, da Nextcloud soweit meinen Signalisierungsserver als laufend erkennt.

    2. Stefan says

      Das ist dann wohl dem neuen Theme geschuldet 😉

      Liegt jetzt hier: https://morph027.gitlab.io/blog/nextcloud-spreed-signaling/

  2. Leon says

    Hello Benjamin, I followed your guide, but still got some issues, when i test i get error:
    HTTP/2 502
    server: nginx/1.14.0 (Ubuntu)
    date: Thu, 28 May 2020 09:15:24 GMT
    content-type: text/html
    content-length: 182

    And when i do systemctl status of signaling i get:
    Could not initialize janus MCU at wss://signalingfqdn:8188 (tls: oversized record received with length 20527) will retry in x s

    any ideas what i am missing? NGINX logs:

    [error] 32636#32636: *3 connect() failed (111: Connection refused) while connecting to upstream, client: 172.x.x.x, server: signalingserverfqdn, request: „GET /standalone-signaling/api/v1/welcome HTTP/2.0“, upstream: „http://127.0.0.1:8080/api/v1/welcome“, host: „signalingfqdn“

    1. Benjamin Hartwich says

      Yes, your mcu address is wrong. Have a look at my article: ws://0.0.0.0:8188. I think your janus server is not secured by a cert, so wss doesn´t make sense?

    2. Leon says

      Could not initialize janus MCU at wss://signalingfqdn:8188 (tls: oversized record received with length 20527) will retry in x s

      i fixed this one, as in server.conf port 8188 was configured, while janus is running 8088…

  3. Stefan says

    Für den NATS Server habe ich jetzt auch ein Repo bereit gestellt: https://gitlab.com/packaging/nats-server/

    Ansonsten ist denke ich die Janus Konfiguration mit 0.0.0.0 nicht passend, da das meinem Verständnis nach den Clients announced wird:

    > Only WebRTC media is exchanged directly between the gateway and the clients.

    Ich denke, da sollte eine erreichbare URL mit FQDN rein (bei mir hinter dem Reverse Proxy unter /janus/)

    1. Benjamin Hartwich says

      Danke für die Info – werde ich bei Gelegenheit einarbeiten.

  4. Fabio says

    Hallo Benjamin,
    Ich bin deinem Guide gefolgt und konnte soweit alles machen. Beim Starten des Signaling Server hat er jedoch nun die folgende Meldung:
    Jun 05 21:23:52 srv-ncsignal-01 signaling[4017]: 2020/06/05 21:23:52.745578 main.go:175: Could not create janus MCU at ws://0.0.0.0:8188: Data channels are not supported
    Jun 05 21:23:52 srv-ncsignal-01 signaling[4017]: 2020/06/05 21:23:52.745592 main.go:182: Could not initialize janus MCU at ws://0.0.0.0:8188 (Data channels are not supported) will retry in 16s
    Jun 05 21:24:08 srv-ncsignal-01 signaling[4017]: 2020/06/05 21:24:08.746892 mcu_janus.go:279: Connected to Janus WebRTC Gateway 0.2.6 by Meetecho s.r.l.
    Jun 05 21:24:08 srv-ncsignal-01 signaling[4017]: 2020/06/05 21:24:08.746923 mcu_janus.go:283: Found JANUS VideoRoom plugin 0.0.9 by Meetecho s.r.l.
    Jun 05 21:24:08 srv-ncsignal-01 signaling[4017]: 2020/06/05 21:24:08.746931 main.go:175: Could not create janus MCU at ws://0.0.0.0:8188: Data channels are not supported
    Jun 05 21:24:08 srv-ncsignal-01 signaling[4017]: 2020/06/05 21:24:08.746939 main.go:182: Could not initialize janus MCU at ws://0.0.0.0:8188 (Data channels are not supported) will retry in 16s
    Jun 05 21:24:24 srv-ncsignal-01 signaling[4017]: 2020/06/05 21:24:24.748300 mcu_janus.go:279: Connected to Janus WebRTC Gateway 0.2.6 by Meetecho s.r.l.
    Jun 05 21:24:24 srv-ncsignal-01 signaling[4017]: 2020/06/05 21:24:24.748328 mcu_janus.go:283: Found JANUS VideoRoom plugin 0.0.9 by Meetecho s.r.l.
    Jun 05 21:24:24 srv-ncsignal-01 signaling[4017]: 2020/06/05 21:24:24.748335 main.go:175: Could not create janus MCU at ws://0.0.0.0:8188: Data channels are not supported
    Jun 05 21:24:24 srv-ncsignal-01 signaling[4017]: 2020/06/05 21:24:24.748343 main.go:182: Could not initialize janus MCU at ws://0.0.0.0:8188 (Data channels are not supported) will retry in 16s

    Was habe ich übersehen? Beim Testen mit dem Curl erhalte ich:
    HTTP/2 502
    server: Caddy
    content-length: 0
    date: Fri, 05 Jun 2020 21:23:48 GMT

    Ich hoffe du hast mir einen Tipp, was an meiner janus Installation nicht stimmen könnte.

    1. Benjamin Hartwich says

      Schwer zu sagen – prüf mal Janus selbst, ob er wirklich läuft.

      1. Heiko says

        Sorry, war wohl zu blöd zum kopieren gestern Abend:

        Das ist die Meldung :
        HTTP/1.1 200 OK
        Date: Mon, 08 Jun 2020 07:39:39 GMT
        Server: Apache
        Content-Type: application/json; charset=utf-8
        Content-Length: 94
        Vary: Accept-Encoding

        {„nextcloud-spreed-signaling“:“Welcome“,“version“:“563658bf59cfeae40cee75eb0a7b009feb9e79cd“}

        Trotzdem erscheint bei Auswahl eines Gesprächs sofort: „Fehler beim Aufbau der Signalisierungsverbindung“

        1. Heiko says

          Das Problem ist mittlerweile gelöst.
          Es lag an unserer Firewall die die Pakete umgeschrieben hat.
          Nun Funktioniert alles.
          Danke nochmal für den Guide und für das Feedback!

          1. Marco says

            Hallo Heiko,

            Kannst du sagen, wie genau das Problem gelöst wurde? Stehe nämlich vor dem gleichen Problem.

            Danke.

  5. Heiko says

    Hallo Benjamin!

    Erstmal danke für deinen Guide!
    Leider bin ich aber am verzweifeln:
    Wenn ich den die Verbindung testen möchte erhalte ich:

    HTTP/1.1 200 OK
    Date: Sun, 07 Jun 2020 17:13:39 GMT
    Server: Apache
    Content-Type: application/json; charset=utf-8
    Content-Length: 94
    Vary: Accept-Encoding

    In NextCloud wird die Verbindung auch erkannt.

    Aber wenn ich in ein Gespräch wähle erscheint sofort die Meldung:
    Fehler beim Aufbau der Signalisierungsverbindung

    Alles ist wie von dir beschrieben konfiguriert.

    Kann mir irgendwer helfen?

    1. Benjamin Hartwich says

      Die Antwort des Servers ist auch falsch, wenn du es mit meinem Blogartikel Auszug vergleichst. Sieht danach aus als würde der Reverse Proxy gar nicht verwendet bzw. wohin führen, wo kein Signalisierungsserver läuft.

  6. Manuel says

    Hallo Zusammen,

    Umgebung:
    3x VMs hinter einer Firewall mit NAT usw Kann das NAT nicht beeinflussen. Andere Geschichte.

    Aktueller Stand:
    – Signalisierungsserver läuft
    – Erreichbar von intern und extern. (intern über hosts datei gelöst)
    – NC mit letsencrypt gesichert
    – TURN und SIGNAL Server ohne SSL ZERT

    Curl meldet version und Welcome zurück (intern wie extern).
    NC sagt sie findet den Server und zeigt eine Version an.

    Wenn ich einen Videoanruf starte:
    „Die Verbindung zum Signalisierungsserver dauert länger als erwartert“

    Syslog:
    Jun 10 15:20:06 signal signaling[35957]: 2020/06/10 17:20:06.962058 backend_client.go:345: Could not send request {„type“:“auth“,“auth“:{„version“:“1.0″,“params“:{„userid“:“vidAdSprinz“,“ticket“:“kZ0/o4nqIfXWBSfK:1591801576:vidAd:d77b512955848b0d6424d3a0cad7dd1591aa6ac46d49a607d6f360368a6f9857″}}} to http://…blah.eu/nextcloud/ocs/v2.php/apps/spreed/api/v1/signaling/backend: context deadline exceeded

    Was bedeutet das ?
    Danke für die Hilfe.

  7. Christian Rößner says

    Hallo, auch von meiner Seite herzlichsten Dank. Soweit habe ich alles eingerichtet. Dienste laufen auch. Ich habe nur eine Minifrage:

    Wenn ich STUN und Signaling im WebUI konfiguriert habe, kann ich dann TURN dort weg lassen?

    Vielen Dank im Voraus

    Christian

    1. Benjamin Hartwich says

      TURN brauchst du wie von Nextcloud geschrieben eher in lokalen Netzwerken mit vielen Firewall Beschränkungen.

  8. Fabio says

    Hallo Zusammen,

    Meine Umgebung: 1x Ubuntu 18.04 mit Nextcloud 19 in der DMZ, mit Public IP + 1x Ubuntu 18.04 mit dem HPB. Ein Curl ergibt mir die folgende Antwort, woraus ich davon ausgehe dass alles korrekt ist:

    HTTP/2 200
    content-type: application/json; charset=utf-8
    date: Fri, 26 Jun 2020 12:11:39 GMT
    server: Caddy
    server: nextcloud-spreed-signaling/563658bf59cfeae40cee75eb0a7b009feb9e79cd
    content-length: 94

    {„nextcloud-spreed-signaling“:“Welcome“,“version“:“563658bf59cfeae40cee75eb0a7b009feb9e79cd“}

    Wenn ich den Server allerdings in Nextcloud hinzufüge erscheint die Fehlermeldung: Fehler: Ein unbekannter Fehler ist aufgetreten.

    Das Syslog von Janus und Signaling ist:

    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.117857 natsclient.go:108: Connection established to nats://localhost:4222 (NB5GEHTYL3K5OANMKXKMMXBOW3PDH6C4H624YY7VRBNOGOO3Y2B2KFYI)
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.117902 backend_client.go:63: WARNING: All backend hostnames are allowed, only use for development!
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.117918 hub.go:175: Using a maximum of 8 concurrent backend connections per host
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.117937 hub.go:182: Using a timeout of 10s for backend connections
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.117952 hub.go:218: Not using GeoIP database
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119112 mcu_janus.go:279: Connected to Janus WebRTC Server 0.10.2 by Meetecho s.r.l.
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119134 mcu_janus.go:283: Found JANUS VideoRoom plugin 0.0.9 by Meetecho s.r.l.
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119140 mcu_janus.go:289: Data channels are supported
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119149 mcu_janus.go:293: WARNING: Full-Trickle is NOT enabled in Janus!
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119155 mcu_janus.go:298: Maximum bandwidth 1048576 bits/sec per publishing stream
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119161 mcu_janus.go:299: Maximum bandwidth 2097152 bits/sec per screensharing stream
    Jun 26 14:04:10 srv-ncsignal-01 janus[3128]: Creating new session: 6080415146940616; 0x7f100000a7d0
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119344 mcu_janus.go:305: Created Janus session 6080415146940616
    Jun 26 14:04:10 srv-ncsignal-01 janus[3128]: Creating new handle in session 6080415146940616: 8290578843621219; 0x7f100000a7d0 0x7f1000004580
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119561 mcu_janus.go:311: Created Janus handle 8290578843621219
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119571 main.go:197: Using MCU janus at ws://127.0.0.1:8188/janus
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119579 hub.go:277: Using a timeout of 10s for MCU requests
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119587 backend_server.go:91: Using „****“ as TURN API key
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119591 backend_server.go:92: Using ****“ as shared TURN secret
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119594 backend_server.go:94: Adding „turn:ncsignal.reinach-bl.ch:3478“ as TURN server
    Jun 26 14:04:10 srv-ncsignal-01 signaling[4822]: 2020/06/26 14:04:10.119700 main.go:272: Listening on 127.0.0.1:8080

    Kann mir da jemand weiterhelfen an was das liegt?

    Vielen Dank im Voraus

    Fabio

  9. Lars Schilsong says

    Vielen Dank für die Anleitung. Wir haben deine Anleitung befolgt, mit den Janus-Inhalten von Stefan kombiniert und aus folgendem Skript noch ein paar interessante Konfigurationstipps entnommen: https://github.com/lnobach/nctalk-backend-cloud-config .

    Für den Janus-Server brauchten wir eine Version, die wir hier gefunden haben: https://launchpad.net/~fancycode/+archive/ubuntu/janus .

    Es läuft tadellos, die Bitrate-Konfiguration haben wir mittlerweile schon ein paar Mal angepasst, was besonders bei sehr schwachen WLAN-Verbindungen von Teilnehmenden hilfreich war.

  10. akr says

    „Data channels are not supported“ in your janus server.

    I think you need to run a janus WebRTC server _with_ data channel support. You’ll probably need to build it, see https://github.com/meetecho/janus-gateway

  11. Hans Jochens says

    Hi, ich würde gerne Hardware für Konferenzen mit 40 Personen kaufen aber finde keine Infos zu den Anforderungen.
    Habe ein laufendes Testsystem aufgesetzt, das mit 6 Personen zufriedenstellend läuft.
    Gibt es Tipps durch Praxiserfahrung?

Leave A Reply

Your email address will not be published.