Ein Wort der Warnung: BBB braucht wirklich Ressourcen. Minimal: Auf dem Blech, 4 Cores, 8GB Ram reicht für ca. 200 gleichzeitige Verbindungen ohne Video.
Supporten kann ich das hier leider nicht, aber als Basis ist es vielleicht besser, als wenn jeder seine eigene Suppe kocht - und die die es ausprobieren können sich ja selber helfen. Ich lese mit.
Ein Wort der Warnung: BBB braucht wirklich Ressourcen. Minimal: Auf dem
Blech, 4 Cores, 8GB Ram reicht für ca. 200 gleichzeitige Verbindungen
ohne Video.
zum selberschätzen auch noch meien Resourcen des bbb servers.
Im Seminar hat er 8 Kerne (leider ein Xeon Prozessor und kein Ryzen) mit
8GB RAM.
Das hat gereicht für wenigstens zwei Parallele Klassenräume mit je ca.
15 Leuten.
Mehr ist vielleicht auch drin: noch sind wir da nicht angeschlagen.
In der Schule hat er 4 Kerne und 4 GB RAM.
Hier sind die produktivläufe noch selten.
Ich hatte eien Sitzung für eine Stunde mit 6 Leuten (alle auch Video),
das gab keinerlei Probleme.
Freitag mach ich da eine MAthe 9te Klasse Fragestunde: das sind 24
Schüler: mal sehen wieviele kommen udn wie das läuft.
In XML-Dateien verlaeuft man sich ja gerne und wenn man hier ein Kommentarzeichen vergisst oder irgendeine Kleinigkeit mit dem Editor verhunzt, dann kommt nach dem Reboot Tomcat nicht mehr hoch, ich wuerde das also nicht gerade tun, wenn ein paar Konferenzen laufen.
Die Empfehlung config-Dateien (vor allem bei XML-Moloch) erstmal wegzukopieren, duerfte ja bekannt sein, ich war eben froh.
Meine Config laeuft uebrigens immer noch nicht, habe den alten Stand zurueckkopiert und neu gestartet, Fehler suche ich in einem Wartungsfenster.
Wir haben BBB naemlich gestern offiziell ausgerollt und das will ich jetzt nicht gleich mit Testreboots torpedieren.
Gruss Harry
Edith: Sprengstoff hier koennten die Kommentarzeichen, die man loeschen muss, sein, danach fliegen uns die Klartextkommentare im Block um die Ohren, die muessen auch weg. Test heute Nacht.
<!--bean id="turn1" class="org.bigbluebutton.web.services.turn.TurnServer">
Secret:
<constructor-arg index="0" value="secret"/>
TURN server URL, use turn: or turns:
<constructor-arg index="1" value="turn:turn1.example.com"/>
TTL in seconds for shared secret
<constructor-arg index="2" value="86400"/>
</bean-->
ich hatte heute eine Sitzung mit 30 PErsonen, davon am Ende 15 Mal Video.
Der Server von/bei hetzner ist der 12-kerner (hyperthreaded) mit 24GB RAM. Die erste Hälfte der Zeit waren auch noch 6 Threads komplett mit folding@home beschäftigt und es tat trotzdem super.
Aber: aus irgendeinem Grund war die Last auf meinem linuxmsuter.net Server sehr hoch, unzählige Samba prozesse. Die LDAP-Auth. von Greenlight kann das eigentlich nicht sein, so dass ich nicht glaube, dass da ein Zusammenhang bestehen kann.
Kann mal jemand eine funktionsfaehige /usr/share/bbb-web/WEB-INF/classes/spring/turn-stun-servers.xml (ohne Secret!) mit TURN-Server-Eintrag hier posten?
Ich habe eine Kollegin, die an Fehler 1007 verzweifelt und wenn ich im Firefox TURN abschalten, siehe Tipp fuer Server bei Diensteanbieter , dann bekomme ich Fehler 1007 ebenfalls beim Anmelden.
TURN scheint mir irgendwie doch wie Raketenbau. @ironiemix: Hast Du Last auf dem TURN-Server? Da muesste ja der ganze Traffic von den Firewallgeschaedigten druebergehen oder habe ich das falsch verstanden und er wird nur fuer den Verbindungsaufbau benoetigt?
Ich habe eine Kollegin, die an Fehler 1007 verzweifelt
bei uns waren Probleme immer nur dann vorhanden, wenn der Client nicht
Firefox, Chrome oder Chromium verwendet hat.
Hast du das mit der Kollegin geklärt?
Applenutzer meinen ja oft es gäbe nur einen Browser und der heißt Safari
und Apple ist grundsätzlich nie an Problemen schuld: war ja schließlich
teuer.
Wenn sie schon einen der besagten Browser verwendet, dann würde ich mal
nachfühlen, wie sie da angebunden ist.
Ist das DSL?
Oder Kabel?
Hat die ein DSlite tunnel (ipv6/ipv4)
Ist von zuhause, Telekomanschluss und irgendein Plasterouter von denen.
Ich versuche gerade mehr herauszufinden.
Mich wuerde aber grundsaetzlich das Debugging von TURN interessieren, mich wuerde nicht wundern, wenn da viele Konfigurationen gar nicht tun und es niemand mitbekommt.
kopieren und dann BBB neu starten, das sollte dann tun.
VG
Frank
P.S.: Der Turnserver ist praktisch „lastlos“, allerdings hab ich im ganzen Geraffel vergessen, den direkt ins Monitoring zu tun, sehe also keine History sondern nur den „Jetzt-Zustand“. Nächste Woche mehr…
@ironiemix: Frank, ich bin Dir gerade zutiefst dankbar und das meine ich ernst.
Deine turn-stun-servers.xml tut einwandfrei und ist viel schlanker als die originale und vor allem die erste, die funktioniert. Ich such den Fehler bei meineren jetzt nicht mehr, aber Fehler 1007 ist zumindest bei meinem Firefox mit erzwungenem TURN-Server Geschichte.
Ueberpruefen mit
Firefox TURN erzwingen mit about:config => media.peerconnection.ice.relay_only auf true setzen.
Mit tcpdump oder wireshark schauen ob der Client den TURN-Server ueberhaupt konnektiert: tcpdump -n -i wlan1 dst host 95.216.219.160
Einer Konferenz beitreten und den Echotest machen, dabei gehen Pakete an die 95.216.219.169
Da gingen vor der Aenderung keine Pakete an turn.linuxmuster.net (95.216.219.169)
Bin mal gespannt, ob das jetzt auch bei meiner Kollegin tut.
Edith: @ironiemix nochmal. Der gesamte Kamera- und Mikrofontraffic geht jetzt allerdings ueber Deinen TURN-Server, keine Ahnung, ob das representativ ist, weiss nicht genau, was die Firefoxumkonfiguration anders macht. Vielleicht erzwingt sie das sogar.
Wie das mit TLS jetzt tut weiss ich auch nicht, wo ist das terminiert? MITM?
Der Echotest mit Firefox geht uebrigens mit TURN wesentlich schneller als ohne, bis allerdings das Video erscheint vergeht eine Minute.
TURN bleibt fuer mich erstmal ein kleines Raetsel.
Frage zum Turn Server, auf welchem Port läuft der? Ich habe selbst einen Turn Server aufgesetzt, der läuft auf Port 3478. Hatte heute aber ein paar einzelne Clients, die Probleme hatten beim Verbinden mit dem Fehler 1007. Ich vermute, dass die Firewall bei denen sehr restriktiv ist und falls dein TURN Server auf 80 oder 443 läuft, wäre das genial zum testen, ob es daran lag.
Frage zum Turn Server, auf welchem Port läuft der? Ich habe selbst einen
Turn Server aufgesetzt, der läuft auf Port 3478. Hatte heute aber ein
paar einzelne Clients, die Probleme hatten beim Verbinden mit dem Fehler
1007. Ich vermute, dass die Firewall bei denen sehr restriktiv ist und
falls dein TURN Server auf 80 oder 443 läuft, wäre das genial zum
testen, ob es daran lag.
das glaube ich nicht.
Der Turnserver ist ja nur Vermittler: danach laufen die Sachen ja
trotzdem direkt über den BBB Server.
Läuft dein BBB den auf dem Blech oder virtualisiert?
Als meien BBB noch virtualisiert waren, hatte ich auch vereinzelt 1007
Fehler, seit er auf dem Blech ist, gab es keine Problmee mehr.
Das stimmt so soweit ich weiss nicht. Es gibt mehrere Möglichkeiten, wie der TurnServer eingreifen kann, unter anderem auch durch Umleitung des Traffics über Ihn, wenn eben eine direkte Verbindungsaufnahme nicht mögclich ist. Das legt auch die Trafficstatistik nahe:
Und dann kann es schon sein, dass der Port eine Rolle spielt.
Hallo allerseits,
Thema „TURN-Server“ ist nicht ganz so einfach wie es hier oft dargestellt oder verstanden wird - sorry wenn ich das so direkt schreibe. Das Ganze hat seinen Ursprung bei der Einführung von privaten IP-Adressen die geNATet werden. SIP, VoIP, Video- und Mediadatenströme gehören aber zu Protokollen die davon ausgehen, dass man Ende-zu-Ende-Kommunikation über öffentliche IP-Adressen hat. Tja, und die hat man halt mit privaten IP-Adressen, NATing, Firewalling, … partout nicht.
Also haben die sich vor vielen Jahren hingesetzt und haben Lösungen entwickelt um den Problem ein wenig Herr zu werden. Ganz kurz sieht das so aus:
Begonnen hat man mit STUN. Das läuft auf Port 3478 (siehe die Frage von oben)
Dann hat man erkannt - Scheiße, STUN löst nicht alle Szenarien und hat TURN hinterhergeschoben. Das läuft dann auf Port 80 und/oder 443. TURN setzt aber auf STUN auf, womit ich entweder einen gesonderten STUN-Server brauche, oder beides auf einem Server betreibe. Der häufigst verwendete Coturn-Server hat deshalb auf Port 3478 seine STUN-Komponente, und dann auf den anderen Ports sein TURN.
Dann hat man erkannt - Scheiße, TURN löst nicht alle Szenarien und hat noch ICE hinterhergeschoben.
So weit kurzer historischer Überblick über die 3 Protokolle die da zugange sind, und aufeinander aufsetzen. Beim Echotest von BBB werden alle Stufen durchlaufen, bis hin zu ICE.
Wird dabei festgestellt, dass es gelang die Firewall zu öffen, das NATing geht, kann der Client direkt mit dem BBB-Server kommunzieren, und beide Seiten wissen wie sich sich gegenseitig erreichen.
In komplexeren Umgebungen, bei BBB jetzt dann seltener der Fall, stellt man bei ICE fest, dass die Direktkommunikation gar nicht, und der TURN-Server als Relay-Station für die Datenströme herhalten muss. Das läuft dann über UDP-Ports im oberen Bereich.
Langer Rede kurzer Sinn: Ganz so einfach ist das nicht, und mit ein oder zwei Ports ist das auch nicht. Da müsst ihr schon schauen was lt. Doku in der Firewall vor euren STUN/TURN/ICE-Server (denn das ist Coturn in Wirklichkeit) so alles offen sein muss. Ist das nicht offen, dann ist … (wie Jesko immer sagt - hi Jesko )
Zumindest so habe ich das verstanden und dann kriegt der schon ordentlich Verkehr ab - vorausgesetzt es sind viele beschnittene Clients am Start.
Datenschutzfrage stellt sich hier ja auch massiv, wo wird TLS terminiert?
Hi,
wer’s genau wissen will nimmt Startpage und sucht die „Libray Genesis“ auf. Dort sucht man dann nach Anton Badach und seinem Buch Voice over IP. Dort liest der geneigte Netzwerktechniker dann die Seiten 426 bis 443. Danach ist die Person dann schlauer, oder hat vorher Seite 443 aufgehört zu lesen.
In diesem Sinne liebe Pinguine, schönes Wochenende,
und viele Grüße, Hans
Ich teste demnach mit dem Festnageln von Firefox auf TURN die Relay/„Proxy“-Funktion von dem TURN-Server, die im normalen Verlauf eher nicht vorkommt?
Zum Testen ob der TURN-Server ueberhaupt angesprochen werden kann, duerfte meine Vorgehensweise mit tcpdump zulaessig sein, oder?
Ich teste demnach mit dem Festnageln von Firefox auf TURN die Relay/„Proxy“-Funktion von dem TURN-Server, die im normalen Verlauf eher nicht vorkommt?
Genau!
Zum Testen ob der TURN-Server ueberhaupt angesprochen werden kann, duerfte meine Vorgehensweise mit tcpdump zulaessig sein, oder?
Ja!
Aber eigentlich kann man die STUN/TURN/ICE-Verhandlungen mit den daraus resultierenden Candidates auch in der Console des Browsers sehen. Da hat u.a. ein Kollege im Betatest-Forum unserer BBB-Infrastruktur eine nette Anleitung gegeben. Damit kann man das dann sogar ohne tcpdump sehen.
Selbiger Kollege (Andreas Gol… ich will mich da nicht mit fremden Federn schmücken) hat mir dann auch noch folgendes verraten:
Ich hatte gestern Nacht auch noch eine nette interne Funktion in Chrome / Chromium gefunden. Kannte ich noch nicht.
chrome://webrtc-internals/ aufrufen und dann eine Web-RTC Anwendung (BBB via moodle) starten. Unten sieht man dann auch die Hostnamen, auch zu STUN/TURN…
)