Nextcloud Talk einrichten

Zitat von ASS

Aber bei BBB braucht man doch fast nie einen Turn Server.

Man braucht bei BBB definitiv einen turn, wenn der Nutzer hinter einer restriktiven Firewall sitzt. (Frag mich nicht warum genau, WebRTC-Krempel)

In unserem Fall war das so, das von einer Schule aus ohne turn überhaupt kein sinnvoller Zugriff auf BBB möglich war.

Bei meinem turn habe ich für diesen Zweck beide Ports gebraucht (3478 und 443)

Ich bin aber kein Fachmann für coturn/turn-Server sondern habe mich dabei an HowTos entlang gehangelt. Konkret u.a. dieses hier:

https://docs.bigbluebutton.org/admin/setup-turn-server.html

Zitat von aRaphael

hinter einer restriktiven Firewall sitzt

Dann gibt es dort wohl kein Nat und Rückkanäle sind verboten.

Dann ist in diesem Fall aber die Firewall falsch konfiguriert, denn sie lässt keine Videokonferenzen zu.

Da sollte man die Firewall anpassen und nicht auf einen Proxy setzen.

Wenn jemand glaubt so restriktive Firewallregeln zu brauchen, dann sollte er auch fähig sein, Videokonferenzen freizuschalten. Ansonsten sind diese ja sowieso unerwünscht, denn ein Proxy umgeht ja in den Fall bewusst die Firewall.

Ja, Schulfirewalls sind oft unsinnig (vor)eingestellt und die vor Ort Admins haben keine Ahnung.

Zitat von ASS

Ja, Schulfirewalls sind oft unsinnig (vor)eingestellt und die vor Ort Admins haben keine Ahnung.

Die Admins dort sind durchaus sehr kompetent. (Was nicht selbstverständlich ist, denn das sind in der Regel Lehrer, die das nebenher machen müssen) Es ist aber keine Firewall dieser Schule selbst, sondern sie hängt als eine der wenigen an einem Netz des Landes, das außer 80 und 443 so gut wie nichts durchlässt.
Man kann von dort aus noch nicht mal per ssh auf externe Server zugreifen. (Ich habe dafür einen jumpserver eingerichtet)

Zitat von ASS

Im Allgemeinen kann man sagen: Jitsi hat kleine Serveranforderungen, aber bei vielen gleichzeitigen Videos "hohe" Clientanforderungen, weil es die Streams nur verteilt.

BBB hat hohe Serveranforderungen, aber kleine Clientanforderungen, weil die Streams vom server zusammengefasst werden und die Clients nur einen Stream erhalten.

Ich habe BBB eine ganze Weile betrieben, daher kann ich nur dazu sprechen. Ich kenne auch Jitsi, das Prinzip WebRTC ist ja das gleiche.

BBB fasst Audio über den Server zusammen, bei Video gibt es jedoch keine Zusammenfassung, die laufen von jedem zu jedem Partner. Siehe https://support.bigbluebutton.…can-I-share-in-a-meeting- zu der schnellen Potenzierung gleichzeitiger Streams. Daher gilt: es ist durchaus möglich, mit moderaten HW Bedarfen eine One-to-Many Veranstaltung zu hosten, z.B. eine Präsentation, eine Konferenz, eine Schulstunde, wo nur ein Videostream / ein Screensharing existiert. Wenn aber alle Teilnehmer ihre Kamera anhaben wollen/sollen, steigt der Aufwand und die Bandbreite (bei den Clients!) bei diesem P2P Prinzip sehr schnell sehr hoch an.

Ergänzend möchte ich anmerken, dass zumindest mit etwas älteren Versionen von BBB, mehrere Browser außer Chrome Probleme hatten. Jemandem einen Browser vorzuschreiben ist aber ungut und nicht immer machbar.

Veranstaltungen, bei denen 200 Leute alle ihre Kamera anhaben können sollen, können imho nur die Dienste, die auch Video serverseitig zusammenfassen, ergo z.B. Zoom oder MS Teams. Diese bieten dann häufig auch noch zusätzliche Einstellungen, um eine solche Vielzahl von Leuten überhaupt zu handhaben (z.B. Controls für den Admin, alle Mikros stummzuschalten etc.).

TLDR: wir sind auch bei sehr großen Veranstaltungen mit Zoom sehr gut gefahren, daher kann ich eigentlich nur das wirklich empfehlen.

Zitat von TBT

bei Video gibt es jedoch keine Zusammenfassung, die laufen von jedem zu jedem Partner.

Hmn, dann wäre ja aber ein Proxy zwingend!? War es nicht so, dass BBB die Streamauflösung der Clients runtergerechnet und erst dann verteilt hat?

Bei mir ist es genau umgekehrt, ich habe mich nach der anfänglischen Entscheidung nurnoch mit Jitsi näher befasst.

Zitat von TBT

mit Zoom sehr gut gefahren, daher kann ich eigentlich nur das wirklich empfehlen.

Zoom kann ich aus Datenschutzgründen als allerletztes empfehlen.

Wenn, dann nur mit speizieller individueller Datenschutzvereinbarung zwischen Zoom und Nutzer (gibt es wohl für xxxx$).

Zitat von ASS

Hmn, dann wäre ja aber ein Proxy zwingend!? War es nicht so, dass BBB die Streamauflösung der Clients runtergerechnet und erst dann verteilt hat?

Meines Wissens nicht. Der BBB Link, den ich gepostet habe, scheint das auch so zu sehen. Was soll da ein Proxy bringen? Die Direkt-Videoverbindungen "sieht" der Server im Endeffekt wohl gar nicht. Audio wird, wie gesagt, vom Server remuxt, Video nicht. Wenn man das weiß, ist klar, für welche Anwendungen BBB geeignet ist und für welche nicht.

Zitat

Zoom kann ich aus Datenschutzgründen als allerletztes empfehlen.

Wenn, dann nur mit speizieller individueller Datenschutzvereinbarung zwischen Zoom und Nutzer (gibt es wohl für xxxx$).

Besondere DS Vereinbarungen haben wir als Hochschule. Mag aus Datenschutzgründen nicht toll sein, aber technisch funktionierts halt auch mit Dutzenden oder Hunderten von angeschalteten Videostreams (selbst mit 200 TN Sitzungen erlebt) immer und überall.

Zitat von TBT

Besondere DS Vereinbarungen haben wir als Hochschule.

Da solltest du bei einer Empfehlung von Zoom aber auch deutlich darauf hinweisen, dass ihr eine Hochschule mit Sondervereinbarungen zum Datenschutz seid.

So aus dem Zusammenhang gerissen denkt nämlich der Normaluser, Zoom wäre auch für ihn brauchbar.

Ist es definitiv NICHT!

Zitat von TBT

Der BBB Link, den ich gepostet habe, scheint das auch so zu sehen.

Hab ich zugegegben (noch) nicht gelesen. Das war das, was ich von vor einem Jahr als Basisunterschied im Konzept zwischen BBB und Jitsi im Kopf hatte.

Wenn ich mal etwas mehr Muße hab, werd ich da mal nochmal reinschaun.

Zitat von TBT

technisch funktionierts halt auch mit Dutzenden oder Hunderten von angeschalteten Videostreams

Ja, klar. Eben weil es so arbeitet, wie ich es bei BBB im Kopf hatte. Jeder Stream wird nur zum Server gesendet und jeder Client erhält nur genau _einen_ Stream zurück, der vom Server umgerechnet wurde. Das braucht natürlich massige Rechenleistung am Server und nur geringe Bandbreite und Rechenleistung der Clients.