Eigene Jitsi Meet Instanz installieren (Docker / Ubuntu / Nginx)

Jitsi Meet ist eine Open Source Videokonferenz Software die durch die Corona Pandemie in aller Munde ist. Ich persönliche finde Jitsi Meet eine der besten Alternativen zu Diensten wie Zoom, Teams und Co. Warum dies so ist und wie man Jitsi Meet benutzt beschreibe ich hier im
Tutorial: Videokonferenzen mit Jitsi Meet.

Ich möchte euch in dieser Anleitung zeigen wie die adminForge Jitsi Meet Instanz aufgesetzt wurde.

Aufbau des Setups:

  • Ubuntu/Debian 11 als Betriebssystem
  • Bereits laufender NGINX Webserver. Wir verwenden diesen als Proxy.
  • Let’s Encrypt SSL Zertifikat (oder anderes)
  • Aktuelle Docker CE Version
  • Aktuelle Docker Compose Version
  • Eine (Sub)domain wird benötigt die auf die IP-Adresse des Servers verweist – wie meet.example.com oder teamjoin.de

Offene Ports in der Firewall:

  • 80/tcp
  • 443/tcp
  • 4443/tcp
  • 10000/udp

Punkt 1: Docker CE installieren

Wir installieren Docker CE nach Anleitung.

Benötigte Pakete installieren:

GPG Key herunterladen:

Repository hinzufügen Ubuntu:

Repository hinzufügen Debian:

Docker CE installieren:

Die aktuellste Docker Compose Version installieren wir mit diesem Befehl:

Eine aktuelle Docker Compose Version, oder andere Installationsmöglichkeiten, gibt es hier: Docker Compose Anleitung

Punkt 2: Jitsi Meet Docker herunterladen

Zuerst erstellen wir uns einen Docker Ordner:

Wir wechseln in den Ordner und klonen das Git Repository:

Nun wechseln wir in diesen Ordner und kopieren die .env Konfigurationsdatei:

Jetzt erstellen wir sichere Passwörter mit dem vorhandenen Script:

Die Konfigurationsordner in unserem Verzeichnis .jitsi-meet-cfg müssen wir manuell erstellen:

Punkt 3: Jitsi Meet .env anpassen

Bevor es losgeht müssen wir ein paar Mindeständerungen vornehmen.

Ich habe den Konfigurationsordner von Jitsi Meet gerne im selben Docker Pfad. Darum passen wir diesen an:

Da wir später unseren Nginx Proxy vorschalten stellen wir die HTTP Ports von Jitsi Meet auf localhost um:

Nun estellt die Timezone in Deutschland auf Europe/Berlin:

Nun tragen wir die (Sub)domain die wir für diese Jitsi Meet Instanz verwenden möchten ein:

Einschalten von ein paar nützlichen Funktionen:

Etherpad URL setzen, um gemeinsam an Dokumenten arbeiten zu können:

Damit alles reibungslos läuft, tragen wir die Docker Host IP-Adresse ein:

Einen STUN Server für P2P Videokonferenzen (max. 2 Personen) hinterlegen wir ebenfalls. Damit werden nicht die von jitsi.net oder damals Google verwendet. Ihr dürft gerne die adminForge STUN Server verwenden:

Damit nicht die unstable Version genutzt wird forcieren wir stable:

Punkt 4: Nginx Port 80 vHost erstellen

Nginx installieren.

Wir wechseln in den Nginx vHost Ordner.

Nun erstellen wir einen Port 80 vHost für Let’s Encrypt und zur Weiterleitung an HTTPS.

Wir aktivieren die Konfiguration.

Nun laden wir die Konfiguration.

Wir erstellen uns ein kostenloses Let’s Encrypt SSL-Zertifikat. Ich beschreibe ausführlich wie dies funktioniert hier.

Eure Domain meet.example.com muss vor diesem Schritt bereits auf die Server IP-Adresse auflösen!

Let’s Encrypt Kurzanleitung:

Punkt 5: Nginx Port 443 vHost erstellen

Nun erstellen wir einen vHost für SSL, bsp. meet.example.com_ssl.conf. Bitte passt nach eurem Bedarf alles an.

WICHTIG: Damit der Jitsi Meet Desktop Client funktioniert, darf der Security Header X-Frame-Options nicht gesetzt werden und Content-Security-Policy nur abgeschwächt!

Wenn alles angepasst ist erstellen wir den Symlink, ersetzt hier auch wieder meet.example.com:

Jetzt prüfen wir ob alles korrekt ist un laden Nginx Konfigurationen neu:

Punkt 6: Docker Container starten

Die Docker Container können nun gestartet werden. Wir verwenden dazu den sehr praktischen docker-compose Befehl, der uns gleich alle 4 Container korrekt startet:

Ob alles läuft prüfen wir mit diesem Befehl:

Stoppen könnt ihr alles mit docker-compose down.

WICHTIG: Wenn Anpassungen an der .env gemacht wurden, muss der Config-Ordner .jitsi-meet-cfg gelöscht werden um die Änderungen wirksam zu machen!

Fertig! Unter https://meet.example.com ist eure eigene Jitsi Meet Instanz nun erreichbar.

Als nächstes: Jitsi Meet Docker Instanz anpassen

Euer adminForge Team

UnterstützenDas Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende.
3

dominion

Linux Systemadministrator

Das könnte dich auch interessieren …

46 Antworten

  1. Matthias sagt:

    Danke für die Anleitung. Hab das gestern auch mal gemacht. Ich muss aber sagen, dass das ganze mit dem offiziellen Ubuntu-Paket DEUTLICH einfacher ging, als per Docker. Nach 5min war man durch. Keine weitere Konfiguriation nötig.

    • Dominion sagt:

      Natürlich kann man auch die offizielle Debian/Ubuntu Anleitung befolgen: https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md
      Die einfache Docker Quick Install ist auch sehr kurz: https://github.com/jitsi/docker-jitsi-meet#quick-start

      Aber hier möchte ich ja ein wenig mehr beschreiben als nur eine Schnellinstallation.

      • Markus sagt:

        Hi Dominion,

        habe gestern das ganze der Anleitung nach installiert. Ich mag Docker, allerdings greift mir die Lösung hier zu kurz, da man dennoch am Hostsystem konfigurieren muss. Eine reine Dockerlösung wäre dann wahrscheinlich einfacher zu nutzen als das Kochrezept von Dir – was im übrigen Klasse ist und mir den schnellen Einstiegt erst ermöglicht hat – Danke. Ich werde aber evtl. auf die klassische Methode schwenken, da ich die Benutzerverwaltung mit prosody nutzen möchte und ich mich sonst zu sehr einarbeiten müsste. Würde aber wenn Du Interesse mit Dir zusammen das ganze auf das nächste Level heben. 1. Nginx in den Docker Container. 2.) Basis Config via Key/Value Paaren in der docker-compose.yml 3) Automatische Konfiguration der Docker Container inkl. letsencrypt setup. -> Ziel „apt get install docker; #get docker-compose.yml; #set ENV Key/values in docker-compose.yml; docker-compose up -d“. Mail mir wenn Du interesse hast. Vielen Dank jedenfalls für diesen super Artikel. Markus

  2. Christian sagt:

    Hallo,
    vielen Dank für diese ausführliche Anleitung.
    Ich komme bis zum Ende von Punkt 3 gut klar, danach ist unklar wie es weitergeht.
    Punkt 4 sagt: Nginx Proxy vHost erstellen – in Ordner wechseln cd /etc/nginx/sites-available/ und Datei „meet.example.com.conf“ erstellen, alles nach Bedarf anpassen. Dann der Hinweis auf SSL Let’s Encrypt.
    Was von beidem mache ich zuerst? Und wenn ich erst der Let’s Encrypt-Anleitung folge, bekomme ich immer eine Fehlermeldung:
    _CURL=’curl -L –silent –dump-header /root/.acme.sh/http.header -g ‚
    _ret=’0′
    code=’200‘
    MEINEDOMAIN.de:Verify error:Invalid response from http://MEINEDOMAIN.de/.well-known/acme-challenge/LETSENCRYPTCODE [MEINE IP]:
    Debug: get token url.

    Ich komme da leider nicht weiter und würde mich sehr über Hilfe freuen!

    • Dominion sagt:

      Die Anleitung habe ich angepasst. Schau mal ob es so verständlicher ist.

      • Christian sagt:

        Super, vielen Dank.
        Nun klappt auch das Zertifikat (auch wenn es zwischendurch den Fehler gab, dass der acme.sh-Befehl nicht existiert, obwohl ich acme.sh per curl geladen habe).
        Nun tut sich aber ein neues Problem auf: Punkt 5 – Nginx-Konfiguration testen.
        nginx -t gibt aus:
        nginx: [emerg] unknown directive „ssl_early_data“ in /etc/nginx/sites-enabled/meet.MEINEDOMAIN_ssl.conf:16
        nginx: configuration file /etc/nginx/nginx.conf test failed

        Da ich den hier beschriebenen Teil im Code aber nur kopiert habe und Dr. Google mir nicht weiterhelfen kann, frage ich hier noch mal. Würde mich riesig über eine Lösung freuen!

  3. Gero sagt:

    Vielen Dank, super Anleitung!
    Damit Jitsi Meet automatisch startet, kann man noch einen kleine Systemd Unit erstellen nach diesem Vorbild:
    https://github.com/docker/compose/issues/4266#issuecomment-302813256
    Dann kann man die Instanz mit systemctl enable docker-compose@docker-jitsi-meet zum Systemstart vormerken.

  4. c0by sagt:

    Tolle Anleitung, danke. Eine Frage noch.

    Das wären alle Ports die man mit ufw freigeben müsste?

    0.0.0.0:10000->10000/udp, 0.0.0.0:4443->4443/tcp
    5222/tcp, 5269/tcp, 5280/tcp, 5347/tcp

  5. Geniale Anleitung, alles hat so funktioniert wie es hier beschrieben war. Wer möchte kann meinen Jitsi Server gern verwenden.

    https://meet.blankenberg.eu

  6. Stefan sagt:

    Auch von mir, vielen Dank für die gute Anleitung. Hat alles funktioniert.
    Allerdings habe ich nun links und rechts einen schwarzen Balken beim Videobild. Nur übern Browser, App kein Problem. Gleicher Browser öffentlicher Server tritt dieses Problem nicht auf.
    Hast du evtl. noch einen Tipp für mich?

  7. kultex sagt:

    danke für die Anleitung – ich habe vorab eine Frage. Funktioniert die Anleitung auch für einen Pi4 oder Rock64 mit 4GB? Ich brauche die Instanz nur im LAN für 2 Laptops, die auf der Bühne stehen. Die Konferenz wird projiziert.

    Ich möchte auf Tournee nicht davon abhängig sein, dass ich einen guten Internetanschluss vom Haus zur verfügung gestellt bekomme.

    Guß

  8. Plastikschnitzer sagt:

    Kann es sein, dass Jitsi an den Docker Containern einiges geändert hat? Habe die Anleitung vor ein paar Wochen befolgt, lief ohne Probleme.

    Jetzt an einem anderen Projekt versucht, kommt nur noch Error 502 am nginx.
    Ports in der .env sind jetzt anders (8000 und 8443) aber die kann man ja frei wählen und sollten kein Problem sein, daran liegt es auch nicht.
    Das restart.sh skript enthält auch andere Container-Namen.

    Kann jemand bestätigen, dass die Anleitung hier noch aktuell ist?

    • Dominion sagt:

      Da wurde nichts angepasst, das Datum hat sich nur geändert da ich einmal die STUN Server geändert habe und nun noch einen Tippfehler gefunden habe.

      1) Wurde 127.0.0.1:180 in der .env gesetzt? Ansonsten kann Nginx nichts finden
      2) laufen die Container auch? „docker ps“
      3) Die Containernamen sind anders, der Schritt „mv docker-jitsi-meet/ jitsi-meet/“ muss ausgeführt werden
      4) Das restart.sh Script greift auf den Ordner jitsi-meet zu, dazu musste der Ordner umbenannt werden „cd $DOCKERPATH/jitsi-meet“

      Um schneller helfen zu können schau einfach in https://adminforge.de/chat/ vorbei.

    • Andi sagt:

      Moin, hast du da mittlerweile was hinbekommen? Hab das gleiche Problem :X die nginx-errorlogs sagen bei mir was von connection refused [error] 213#213: *4225 connect() failed (111: Connection refused) while connecting to upstream, client: 92.117.114.229, server: domain.de, request: „GET /favicon.ico HTTP/2.0“, upstream: „http://127.0.0.1:180/favicon.ico“, host: „domain.de“

      • Dominion sagt:

        Hallo Andi,

        ich hoffe du hast nicht wirklich domain.de in der Nginx Konfiguration stehen? 😉
        Dort bitte die eigene überall eintragen.

        Gruß

        • Andi sagt:

          Heyho, danke für die Antwort, war natürlich nur exemplarisch. Habe mittlerweile mein Problem ergründet. Ich verwende auf meinem Server das PaaS-System CapRover, welches recht cool und praktisch ist. Leider stresst da das Jitsi-Deploy rum (jvb möchte keine Verbindungen aufbauen) weshalb ich versucht hab, jitsi über docker-compose zu deployen. habe nun herausgefunden, dass der connection refused-Fehler durch die network-Einstellungen in docker-compose entstanden ist. CapRover nutzt docker und ein eigenes network für die Kommunikation der Dienste untereinander. Hab dann im Docker-Compose-File für Jitsi noch das externe Netzwerk hinzugefügt und schwupps hat alles funktioniert. Schon ganz interessant das Ganze aber die Komplexität ist wohl nicht zu unterschätzen 😀 Beste Grüße

        • Andi sagt:

          Ok noch ein kurzes Update: Funktioniert hat das ganze nun mit der Verison 4416, wenn ich die latest builds nehme bekomme ich wieder ein 502 und der jitsi meldet ein „no route to host“. So ein Krampf mit diesem Jitsi 😀

      • Klaus sagt:

        Hallo, ich hänge hier auch an diesem Punkt fest. Selbst ein lokales w3m http://127.0.0.1:180 läuft in ein Timeout. Irgendwie scheint Docker die Portweiterleitungen nicht richtig einzurichten.

  9. Jo sagt:

    Bin leider netzwerk-seitig etwas schwach auf der Brust. Anknüpfend an die Frage von Kultex: wenn ich ein Testszenario mit Ubuntu-Hyper-V-VMs nur innerhalb eines abgeschotteten LANs aufbauen möchte, funktioniert die Anleitung auch dafür? Welche Schritte kann bzw. muss ich dabei weglassen?
    Ein erster Versuch geht natürlich bei der SSL-Zertifizierung schief. Der nginx-Check und -Restart bringt folglich auch Fehler.
    Grüße

    • Dominion sagt:

      Hallo Jo,

      richtig, genau sowas müsstest du weg lassen oder besser noch auf ein selbst signiertes SSL Zertifikat setzen.
      Dann werden die Browser aber sich beschweren. ZUm Test kannst du ja auch erstmal ohne SSL arbeiten.

      Gruß
      Dominion

  10. Wolfram sagt:

    Hallo Dominion,

    ich habe Probleme bei der Anlage von usern. Ich gehe gemäß der Anleitung auf https://community.jitsi.org/t/docker-authentication/39060/4 vor :

    prosodyctl –config /config/prosody.cfg.lua register TheDesiredUsername meet.jitsi TheDesiredPassword

    Dann scheitert der Befehl am Hostnamen. Ich gebe die öffentlich Adresse ein, jedoch ist der Hostname für proody der Name des Containers. Und damit scheitert der Befehl, wenn ich die öffentlice Adresse angeben. Mit Rechnernamensangebe des betreffenden Containers passiert gar nichts.

    Aus diesem grunde kann ich derzeit die Atuhentifizierung nicht nutzen.

    Freundiche Grüße
    Wolfram

  11. Wolfram sagt:

    Hallo Dominion,

    ich verstehe nicht, warum .jitsi-meet-cfg gelöscht werden muß. Das stellt nämlich im Zusammenhang mit der Authentifizierung ein Problem dar. In meinem Testlauf gestern waren nach Löschen dieses Verzeichnisses die User (noch waren es nur 3) verschwunden.
    Das hätte zur Folge, daß bei einer Änderung in .env die User neu angelegt werden müßten.
    Ich habe nicht den Eindruck, daß an Deiner Anleitung etwas fehlerhaft oder unvollständig -im Gegenteil ich finde sie weit mehr als hervorragend- ist.
    Ist es so schädlich, die config zu behalten? Falls ich das Prinzip der volumes verstanden habe, könnte man nicht die Config-Files „auslagern“ und persistent bleibend bearbeiten?
    Hast Du da vielleicht eine Idee?
    Ich werde auch nochmals forschen und Ergebnisse hier mitteilen.

    Freundliche Grüße
    Wolfram

    • Dominion sagt:

      Hallo Wolfram,

      das ist vollkommen richtig, wenn man Authentifizierung aktiv. Im Tutorial beschreibe ich jedoch eine öffentliche Instanz ohne Benutzerverwaltung!
      Der Ordner muss gelöscht werden da ansonsten die Änderungen in der .env nicht übernommen werden.
      Du kannst dir die .dat Dateien mit den Benutzern ja vorher weg kopieren und nach dem Update wieder an die selbe Stelle zurück kopieren.

      Gruß
      Dominion

      • David sagt:

        Hallo Dominion,

        kannst du eventuell etwas ausführen, welche Docker-Mechanismen greifen, dass der Ordner gelöscht werden muss? Der Ordner wird doch nur als Docker-Volume gemountet. Ich bin ziemlich neu mit Docker und verstehe nicht ganz, wieso die .env erst neu eingelesen wird, wenn der Ordner fehlt. Laut einer anderen Quelle macht Docker das automatisch. Danke dir im Voraus!

        Grüße,
        David

        • Dominion sagt:

          Hallo David,

          also so war es zumindest als ich die Anleitung geschrieben habe:
          – Wenn .jitsi-meet-cfg existiert, liest er nicht die .env neu ein.
          – Wenn .jitsi-meet-cfg gelöscht wurde, erstellt er die Ordnerstruktur und Configs neu – liest somit die .env wieder ein um neue Configs zu erstellen.

          Gruß
          Dominion

  12. Holger sagt:

    Hi!

    Kleiner Hinweis: ich wollte aus Gründen xmpp-websocket aktivieren und dafür musste ich in der „location /“ noch folgendes ergänzen, da sonst die Verbindungsanforderung an den Websocket schief läuft:

    proxy_http_version 1.1;
    proxy_set_header Connection „upgrade“;
    proxy_set_header Upgrade \$http_upgrade;
    tcp_nodelay on;

    Da dieser PR (https://github.com/jitsi/docker-jitsi-meet/pull/502) gemergt wurde, dachte ich, ich sags mal. Nur für den Fall, das kommt unerwartet in einem nächsten Docker Image Release und jemand läuft dann mit der Beschreibung hier vor das gleiche Problem, wie ich 🙂

    LG
    Holger

  13. Chris sagt:

    Super Anleitung, danke. Was mich in Richtung STUN/Turn interessieren würde: Es gibt in der Config zwar einen Parameter für den Discovery-Server, gibt es aber auch etwas in Richtung Shared Secret für diesen Server? Betreibe einen eigenen Server, der ist aber nicht public…

    Zweite Frage: Was hat es denn mit XMPP_BOSH_URL_BASE=http://xmpp.meet.jitsi:5280 auf sich? Das steht in der Config default und wird nicht behandelt? Ist das für irgendeine Federation?

    Gruß
    Chris

    • Dominion sagt:

      Hallo Chris,

      es gibt „turncredentials_secret“ was original in der „turn.cfg.lua“ konfiguriert wird. Für Docker benötigst du noch das mod_turncredentials.lua Prosody Modul.
      Ich habe es bei meet.adminforge.de aktiv, aber noch nicht getestet ob es auch korrekt funktioniert. Die Docker Version soll ja TURN bekommen, da würde ich noch abwarten.

      Der BOSH Port 5280 lauscht ja nur auf dem internen Netzwerk und wird nicht fürs föderieren genutzt.

      Gruß
      Dominion

  14. Ralph sagt:

    habe mit Interesse den Beitrag gelesen. Wie kann man denn das Ganze in einem unter Plesk installierten Docker-Container realisieren? Irgendwie stehe ich da völlig auf dem Schlauch. Kennt jemand ein vernünftiges HowTo für das Szenario? Via Google ist nicht wirklich was brauchbares zu finden.

  15. Mészi sagt:

    Hallo, danke für die ausführliche Anleitung. Alles in allem bin ich zu einem funktionierenden ViKo-System gekommen, allerdings mit einer Einschränkung: Auf einem teilnehmenden System in einem abgeschotteten Firmennetzwerk wird keine Videoverbindung aufgebaut (10000/udp blockiert). Ich habe schon ein wenig gegoogelt und meine, die Lösung in der Notwendigkeit eines eigenen Coturn-Servers ausgemacht zu haben. Ich hätte sogar Zugriff auf einen. Macht es grundsätzlich Sinn, in diese Richtung weiter zu forschen oder gibt es ggf. einen sinnvolleren Ansatz?

  16. Hoerli sagt:

    Hallo, danke für die Anleitung!
    Leider klappt das nicht (mehr) so wie beschrieben.
    Ich hab mehrere Probleme, die ein erfolgreichen Verbindungsaufbau verhindern.

    Die aller neuste Version, welche man per git bekommt, ist wohl defekt.
    Die Container lassen sich nicht sauber starten und der Log haut nur irgendwelche Nonsense-Java-Fehler raus.
    Mit dem Release stable-5390-3 funktioniert immerhin der Startvorgang sauber.

    Ich kann ein Meeting mit Teilnehmern im gleichen Netzwerk starten (also z.B. im LAN).
    Sobald ein Teilnehmer aus einem anderen Netz dazu kommt, kann er dem Meeting beitreten, Video und Audio-Chat gehen aber dann nicht.
    Das eine Problem ist, das man jetzt auch intern alles via HTTPS durchleiten muss.
    Die nginx-Config habe ich daher so angepasst, dass die HTTPS-Ports genutzt werden.
    Das Problem hatte ich bei einem anderen Fall letztens schon einmal (andere Software, aber gleiches Phänomen) und konnte es so direkt lösen.
    Das kein gültiges Zertifikat hinterlegt ist, ist nicht schlimm. Geht trotzdem.

    Beim Verbindungsaufbau kommt aber nun folgendes Problem:

    Firefox meldet das hier:
    2021-04-10T19:31:55.825Z [modules/connectivity/ParticipantConnectionStatus.js] : Detector RTCEvents.ENDPOINT_CONN_STATUS_CHANGED(1618083115825): ed7816c6: false Logger.js:154:22
    2021-04-10T19:31:55.825Z [modules/connectivity/ParticipantConnectionStatus.js] : Figure out conn status for ed7816c6, is video muted: false is active(jvb): false video track frozen: false p2p mode: false is in last N: true currentStatus => newStatus: interrupted => interrupted Logger.js:154:22
    2021-04-10T19:31:56.326Z [modules/RTC/BridgeChannel.js] : Endpoint connection status changed: ed7816c6 active=false Logger.js:154:22

    Der Docker-Log gibt folgendes aus:
    web_1 | 172.21.0.1 – – [10/Apr/2021:21:32:09 +0200] „POST /http-bind?room=test123 HTTP/1.0“ 200 318 „-“ „okhttp/3.12.1“
    jvb_1 | Apr 10, 2021 9:32:12 PM org.jitsi.utils.logging2.LoggerImpl log
    jvb_1 | INFO: Performed a successful health check in PT0S. Sticky failure: false

    Ich habe jetzt 8 Stunden mit Internetsuche und Probieren verbracht, aber nichts hilft.
    Aktuell nervt das Zeugs einfach nur noch.
    Hast du eine Idee, woran das liegen könnte?

    • Dominion sagt:

      Hallo Hoerli,

      also die stable-5390-3 ist auch noch die aktuellste Version. Container lasse ich in der Anleitung nicht bauen.
      Dein Problem klingt sehr stark nach fehlender PUBLIC_URL Konfiguration, hast du die Variable gesetzt?
      Du kannst mal im Browser in die F12 Konsole schauen welche Fehler dort auftreten.

      Gerne auch hier weiter diskutieren: https://community.adminforge.de/

      Gruß
      Dominion

      • Dominion sagt:

        Hallo Hoerli,

        ich habe das Problem gerade selbst feststellen können.
        Die docker-compose.yml und .env aus dem git Master Branch sind zu neu für „stable-5390-3“, welche noch als latest getagged ist.
        Wenn du die beiden Dateien aus dem Release Source Code nimmst startet auch alles normal: https://github.com/jitsi/docker-jitsi-meet/releases

        Ich vermute es liegt an dem neuen OCTO was vor ein paar Tagen eingebaut wurde.

        Gruß
        Dominion

  17. Timo sagt:

    Hallo Zusammen,

    ich würde gerne die Breakout Rooms aktivieren. Ich weiß aber nicht wie ich das im Docker Umfeld aktivieren kann. Meine yml Datei habe ich angepasst. Muss ich in meiner .env Datei noch diese aktivieren?
    Vielen Dank

  18. Hello,
    I have followed the complete guide and set up my server as well but my jitsi is too slow I don’t know why, when I click join meeting it takes too much time.

Schreibe einen Kommentar

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