Schneller jitsi STUN Server gesucht

  • Hallo,

    hat jemand Tipps für einen _schnellen_ STUN server, der in Europa oder Deutschland steht?

    Der neue Default ist so überlastet, dass es schon bei 2 Teilnehmern laggt. Die Google Server klappen zuwar gut, aber - Google...

    Aber bitte nicht der Verweis auf die Gesamtliste bei Github!

    Ich hoffe auf konkrete Tipps für meinen 300 Clients Server...

  • timkoop und ich haben jeweils einen.


    Meinen kannst du gerne nutzen --> stun.li4u.de

    Ich habe selber keine Jitsi Instanz zum Testen - wenn es Probleme gibt, melde dich einfach! :)


    Dei Domain von timkoop seinem liegt irgendwo im längsten Thema vergraben...


    Die Performance sollte eigentlich klar gehen, läuft auf einem RS 2000 neben ein paar nahezu ungenutzten Gameservern.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Die Performance sollte eigentlich klar gehen

    Was veranlasst dich zu dieser Aussage? Wieviel Traffic läuft denn über den STUN Server?

    Die RS von NC haben sich für mich allesamt für den jitsi Server als untauglich erwiesen. Vermutlich wegen der shared NIC.

    Ich habe jetzt ein echtes Blech mit einer echten NIC und einer garantierten Bandbreite von 1gig für den jitsi Server. Der jitsi STUN ist um Längen zu überlastet (wie zu erwarten). Mit den Google STUN läuft es gut, diese will ich jedoch möglichst nicht benutzen.

    was deine Anforderungen an Schnelligkeit sind.

    Da ich nicht weiß, wieviel Traffic über die STUN Server geht, kann ich das nicht beurteilen. Wäre auch eine Nebenfrage zum Thema.

    Der Server soll etwa 300-600 Clients gleichzeitig bedienen können (in Gruppen zu jeweils 10 bis 25).


    Für Suchmaschinen bin ich mittlerweile wohl zu blöd (wenn ich nach "Nasen" suche, krieg ich Hundefutter angezeigt);

    deshalb sind auch Links zu Erklärungen gerne genommen.

  • ASS Mein Bauchgefühl + die erfahrungsgemäße Leistung des RS und die Tatsache, dass der STUN Server aktuell nicht genutzt wird.


    Wie gesagt - probier es doch einfach aus. Ich kanns dir nicht sagen. Deinen Aussagen zu Folge kann es aber eh nicht schlimmer werden, von daher... ;)

    Wenn du mehrere STUN Server hast, kannst du ja auch die Last ein wenig verteilen.


    Du musst halt nehmen, was du bekommst. Keiner wird sich für dich nen dedi hinstellen und da nen STUN Server hosten.

    Wenn du unbedingt meinst, du brauchst nen dedi, dann miete dir bitte selbst einen (sind ja mittlerweile sehr günstig zu haben) und installier dir dort coturn.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Wie gesagt - probier es doch einfach aus.

    Um es selbst auszuprobieren fehlt mir die Zeit. Wenn ich die hätte, würde ich die Liste bei Github durchprobieren.

    Das kann ich aber nicht 600 Schüler machen lassen, die ab Montag darüber Videounterricht erhalten.

    Und selbstverständlich werde ich selbst einen oder mehrere STUN Server hinstellen und betreiben, wenn mir mal klar ist, wieviel Traffic über den geht, wieviel Leistung er braucht und für welche Aktionen genau er benutzt wird.

    Wenn der Stun wesentlich an der Videoqualität und an der Ruckelfreiheit, oder an der möglichen Teilnehmeranzahl beteiligt ist, hat es wenig Sinn, wenn ich den auf einem virtualisierten NC RS mit shared NIC betreibe, oder einen dort betriebenen benutze.

    Es würde mir für den Anfang schon genügen, wenn mir jemand das Auswahlschema für den STUN Server erklären kann. Vielleicht muss ich mir ja nur 30 der Server aus der Github Liste raussuchen und diese alle eintragen?


    Auch Links zu diesen Infos sind willkommen.

  • Das kann ich aber nicht 600 Schüler machen lassen, die ab Montag darüber Videounterricht erhalten.

    Evtl. könntest du danach ja mal berichten, wie das lief mit 600 gleichzeitig. Das wäre nett. :)

    Insbesondere auch welchen Server du dafür verwendet hast. (Falls der es ausgehalten hat. ;))

  • Meinem Verständnis nach ist so ein STUN-Server nur zu Anfang an dem Verbindungsaufbau beteiligt. Dieser teilt nämlich dem Client mit, unter welcher öffentlichen Adresse und welchem Port er erreichbar ist. Außerdem ermittelt der STUN-Server die NAT-Art. Diese Informationen braucht der Client dann z.B. für Protokolle wie SIP. Dass der nachfolgende Traffic vollständig über diesen STUN-Server geht, wäre mir neu. Der Traffic sollte also ziemlich gering sein.


    Ich finde das ganze wird hier ganz gut erklärt: https://www.ip-insider.de/was-ist-ein-stun-server-a-899709/

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Es würde mir für den Anfang schon genügen, wenn mir jemand das Auswahlschema für den STUN Server erklären kann. Vielleicht muss ich mir ja nur 30 der Server aus der Github Liste raussuchen und diese alle eintragen?

    Das Auswahlschema ist relativ... STUN ist ja grundsätzlich mal nichts, wo tatsächlich Video- oder Audiotraffic durchfließt. Es ist ja nur zur Erkennung des NAT Typs da. Daher denke ich, dass hier nicht sehr viel Traffic aufkommt bzw. die Auswirkung auf die Performance erstmal nicht zu krass ist.


    Nach meinem Verständnis wird die STUN Abfrage auch nur beim Neuaufbau einer Verbindung durchgefürt - sprich, das läuft nicht permanent bei allen Clients.


    Das Problem bei Jitsi ist, dass es ohne funktionstüchtige(n) STUN Server den kompletten Traffic nicht mehr p2p abwickelt, sondern durch deine Videobridge (Jitsi Instanz) zieht. Und das wäre bei 600 Leuten dezent ungeil.


    Du könntest ja einen eigenen STUN Server auf einem dedi hinstellen und nimmst den von timkoop und meinen dazu.


    TCP/UDP: stun.0x58.de:3478

    TCP[/UDP] TLS: stun.0x58.de:5349

    Meiner wäre:
    TCP/UDP: stun.li4u.de:80

    TCP[/UDP] TLS: stun.li4u.de:443

    bzw.
    TCP/UDP: turn.li4u.de:80

    TCP[/UDP] TLS: turn.li4u.de:443

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Das Problem bei Jitsi ist, dass es ohne funktionstüchtige(n) STUN Server den kompletten Traffic nicht mehr p2p abwickelt, sondern durch deine Videobridge (Jitsi Instanz) zieht. Und das wäre bei 600 Leuten dezent ungeil.

    Jain... Die STUN-Server werden benutzt, um bei (standardmäßig (?)) aktiviertem P2P den Traffic nicht über die Videobridge zu leiten. Dies wird jedoch nur bei zwei Teilnehmern einer Sitzung gemacht (klang bei dir ein bisschen anders). Da es Jitsi/Videobrige nicht interessiert, was passiert wenn kein STUN-Server antwortet, bricht die Zweiersitzung einfach zusammen. Da grundsätzlich jede Sitzung zu Beginn irgendwann eine Sitzung mit zwei Teilnehmern ist, ist es wichtig, dass immer mindestens ein STUN-Server aus der Konfiguration verfügbar ist (egal wie schnell); andernfalls können keine Sitzungen mehr aufgebaut werden.

    STUN-Server werden von Jitsi-meet jedoch auch genutzt, um die IP-Adresse des Servers/Videobridge zu ermitteln. Dies wird jedoch nur gemacht, wenn NAT benutzt wird oder (so war es zumindest bei der Docker-Version) wenn keine (öffentliche) IP-Adresse hinterlegt wurde.

  • Ich kann mir schon vorstellen, dass es bei 2er Meetings dort Probleme geben kann. Ich weiß jetzt nicht wie genau sich das äußert, wenn das Meeting schon läuft und dann der Server nicht mehr rechtzeitig antwortet, aber im Wireshark kann ich ständige Verbindungen sehen.


    jitsi_stun.PNG


    Aber ja, sobald eine dritte Person dazukommt, verpuffen die STUN Pakete.

    Ich denke doch solche Anbieter wie sipgate oder 1&1 sollten genug Ressourcen für sowas bereitstehen haben... oder man schaltet die P2P Funktion komplett ab.

  • Ich verzichte mal auf die Zitate und antworte nur allgemein.

    Also: ich habe p2p eh deaktiviert. Bei mir gehen auch 2erkonferenzen über die Bridge.

    Da die stun Server nur bei p2p eingetragen sind und ich auch in Beiträgen von vor 5 Jahren gelesen habe, dass jitsi keine Tunnelserver mehr braucht, habe ich die Hoffnung, dass STUN jetzt eigentlich komplett unnötig ist.

    Letztlich wird aber wirklich nur Testen helfen, da die spärlichen Infos sich da zum Teil auch widersprechen.

    Ich werde also bald mal meinem ersten jitsi Testserver wieder einen fqdn verpassen und dann gerne eure 3 stun eintragen.

    Dann könnt ihr Konferenzen testen und schaun, ob und wann etwas über eure stun Server kommt.

    Da am Donnerstag dann auch hier die Osterferien beginnen, werde ich dazu wohl spätestens nächstes wochenende Zeit haben.

    Rückmeldungen zum Test des großen Servers habe ich noch keine, werde die dann aber gerne weiterreichen.

    Übrigens: Sipgate hat seine stun Server für jitsi anscheined komplett gesperrt und in den Sipgate Anleitungen steht "jitsi wird nicht (mehr) unterstützt"...

  • Nachtrag:

    Bei dieser ganzen Sache geht es m.e. garnicht um die stun funktionalität, sondern um die turn funktion eines stun Servers.

    Ich habe jetzt noch bemerkt, dass auf meiner alten jitsi Installation nur jitsi läuft, auf der Neuen aber auch jede Menge turnserver Tasks auf Port 3479 lauschen.

    In welchem config File von jitsi lege ich denn fest, welcher turn Server verwendet wird?

  • Bei dieser ganzen Sache geht es m.e. garnicht um die stun funktionalität, sondern um die turn funktion eines stun Servers.

    I.d.R. sind STUN Server gleichzeitig TURN Server, sofern das Paket coturn genutzt wird.

    Für verschlüsseltes TURN ist ein Secret notwendig, was der Betreiber auf Anfrage herausgeben kann. :)


    Bzgl. des Config Files kann ich dir leider nicht helfen. :(

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Ich verstehe hier den Sinn überhaupt nicht. Wo liegt das Problem, einen eigenen STUN-Server aufzusetzen? Wer jitsi bzw. Nextcloud Talk aufsetzt, soll auch STUN-Server aufsetzen können. Die Einrichtung ist wirklich so einfach. Schau hier und setze das um. Die Nginx-Konfiguration auch an eigene Konfiguration anpassen. STUN-Server braucht keine Leistung, ein VPS200 tut es auch ;) STUN ist dafür da, die Endpunkte (in diesem Sinne Gesprächspartner) (auch hinter dem NAT) zu ermitteln und an Nextcloud Talk bzw. jitsi zu übergeben

  • I.d.R. sind STUN Server gleichzeitig TURN Server, sofern das Paket coturn genutzt wird.

    Für verschlüsseltes TURN ist ein Secret notwendig, was der Betreiber auf Anfrage herausgeben kann. :)


    Bzgl. des Config Files kann ich dir leider nicht helfen. :(


    In der /etc/prosody/conf.avail/<FQDN>.cfg.lua findet man folgendes:


    jitsi_turnserver.PNG


    Zumindest bei mir steht da die Jitsi Maschine selbst drin.

  • Was spricht dagegen das sich jeder jitsi Server Betreiber einen eigenen stun hinstellt?

    Nichts. Bzw doch. Wenn eine erhebliche Menge Traffic durch den turn Server geht, braucht nicht nur der jitsi Server eine dedizierte gigabit Anbindung, sondern zusätzlich auch noch der stun/turn Server.


    Wo liegt das Problem, einen eigenen STUN-Server aufzusetzen?

    Du hast offensichtlich nicht alle Posts im Thread gelesen, oder die Präzisierung der Frage nicht verstanden.

    Es ist natürlich keinerlei technisches Problem, einen stun Server aufzusetzen. Die Frage geht hier um turn und die dort benötigte Bandbreite.


    In der /etc/prosody/conf.avail/<FQDN>.cfg.lua findet man folgendes:

    Danke! Das half mir sehr!


    Ein kleines Resümee:

    Meine ersten jitsi Server habe ich am 21.3. aufgesetzt.

    Dann folgten weitere in den folgenden 2 Wochen und der bisher Letzte am 3.4.

    Alle funktionierten auf Anhieb; jedoch:

    ALLE haben unterschiedliche default Configs! und auch unterschiedliche default Pakete!

    Ich habe alle Server auf einem frischen Debian10 mittels der identischen quick config Anleitung und identischen Befehlen installiert.

    Der erste Install hatte die Google stun drin.

    Einige der Folgenden den jitsi stun und garkein turn in der Config..

    Der letzte Install installierte und konfigurierte nun sofort auch den eigenen stun auf derselben Maschine mit und schrieb diesen auch als turn Server in die config.

    Die Konfusion hat also bei mir erstmal ein Ende. Die Frage nach der notwendigen turn Bandbreite ist für mich deshalb nicht mehr ganz akut,

    kann es aber sehr schnell wieder werden, wenn der turn Server denn tatsächlich dafür sorgen kann, dass mehr Benutzer gleichzeitig ruckelfrei arbeiten können.

    Nach meiner momentanen Meinung wird dazu dann aber eher ein zweiter Server, auf dem eine slave Videobridge läuft, helfen (nur, braucht der dann wieder nen eigenen turn Server?).

  • Einen eigenen TURN Server wird die zweite Bridge nicht benötigen. Deine Konfusion kann ich verstehen aber sie auch gleich entkräftigen: In den letzten Tagen hab es viele Updates von Jitsi in denen viel an der Standardkonfiguration geschraubt wurde. Dass sich die Konfigurationen hier unterscheiden ist also völlig OK und durchaus gewollt.


    Je nach Auslastung kannst du die STUN/TURN Server definitiv auf den Jitsi Servern mitlaufen lassen. Bei deiner Auslastung würde ich aber eher dazu raten den STUN/TURN Server extra als VM zu betreiben. Der braucht auch nicht viele Ressourcen und schon garnicht viel Traffic (zumindest konnte ich bisher nichts in diese Richtung beobachten).