Seite wählen

NETWAYS Blog

Jitsi Customization

Custom Branding

A few months have passed since our last Jitsi features blogpost and seeing as the demand for Jitsi is still high, we are permanently looking for ways to improve our Jitsi for our customers. Therefore, I would now like to show you the new features which are currently in production.

Lately we got more and more requests for a custom branding of Jitsi. Because Jitsi does not offer such an option, we took the matter into our own hands and created a possibility that you can configure Jitsi yourself.
Many Jitsi users don’t want to have their setup with the default design. They instead want to add their own look. If you have ever searched for custom branding for Jitsi, you will quickly find out that there are already some community contributions available. This is good for the users who run their own jitsi. But for customers who rely on a service provider soon realise that these options are often not represented. Some service providers offer the possibility to create a custom setup for the customer, but such projects are usually associated with higher costs and a lot of hassle.
Therefore, we want to offer the possibility that everyone can easily configure their Jitsi on our website and finally get what they want. The watermark logo, the background and the colour scheme can be customized as desired.

Custom Domain

Apart from the appearance, we are currently also missing the option of the custom domain, but the wait will soon be over. What is also currently in demand is the possibility to have your own domain. This is unfortunately not currently possible with the current setup. But with the new structure of Jitsi, this will no longer be a problem.

JWT Authentication

If we now go a bit further in the direction of security, we come across another important point that is currently being worked on. The selection of the Jitsi authentication. Here we have also put together and provided something magical for you. As standard we have the authentication with user and password, but after our update you will have the ability to choose between standard and JWT authentication.

So it will soon be possible to configure everything on your own.
For these features we will also provide a technical blogpost, where we will explain step by step how all these configurations are implemented in Jitsi.
I hope I could peak your interest with this blogpost. If so, then you are as full of excitement as I am, because these features will be awesome.

If you are still not sure if you want to use Jitsi, check out our blog comparison of Jitsi vs Zoom vs BigBlueButton.

Joshua Hartmann
Joshua Hartmann
Systems Engineer

Joshua hat im Sommer 2023 seine Ausbildung zum Fachinformatiker für Systemintegration bei den NETWAYS Web Services erfolgreich abgeschlossen. Heute ist er ein wichtiger Teil des Teams, das sich mit großer Hingabe um die Kundenbetreuung und die kontinuierliche Weiterentwicklung der SaaS-Apps kümmert. Neben seinem musikalischen Talent am Klavier hat Joshua eine Leidenschaft für Wintersport und findet auch Freude im Gaming. Doch am allerliebsten verbringt er seine Zeit mit seiner besseren Hälfte, denn sie ist für ihn das größte Glück.

NWS Jitsi – is it really safe?

 

Zoom, Microsoft Teams, Skype, Jitsi public server – Everyone says „Your conferences are safe!“
So do we. But is your data really safe when you are using NWS Jitsi ? The answer is yes. We will give you 6 reasons/features why.

 

1. End2End Encryption

You can enable End2End Encryption at any time. Do you want to secure what is spoken and shown? No problem.

 

 

 

Only the participants which are joining your meeting and are activating E2E as well, can see and hear what you are saying. It will secure the data sent to the clients.

2. Lobby Feature

A common problem with Jitsi was that you could enter an already occupied conference with the same room name. Here is a feature that counteracts this problem.
To make Jitsi a little bit more secure there is a new lobby feature.

 

 

This feature can be easily activated by a moderator in the room. Now every participant has to enter his name and ask if he can join the session.

 

 

The moderator can then decide whether or not the participant can join the session.
To activate the lobby feature you will need to make a few following modifications to Jitsi.

 

 

3. Moderators

Moderators are the only one, which are allowed to enable the communication in a conference room, change security settings, enable E2E or the lobby feature, kick participants and so on.
Depending on the plan you have started, you can add 3 to 26 extra moderators.

 

 

You can reset the passwords of all of them, delete them again, recreate – just what you would do with admins in your own infrastructure. Keep the overview of who is allowed to manage your meetings!
Communication will be blocked unless someone with moderator rights enters the room. They are in charge!

 

4. Conference Passwords

In today’s time of home schooling, it unfortunately brings problems with it. Students who have received the invitation link can guess the name of other classes if the naming convention is the same and can anonymously log in to this class and disturb it.
Or if it is an important meeting, where you want to prevent colleagues from unintentionally logging in. It has also happened to me that I accidentally clicked on the wrong room and ended up in a conversation between two colleagues.
To protect the room with a password, the moderator has the possibility to assign a password after the room has started. To do so, he or she must enter a password in the security settings (the shield symbol in the lower right corner).
Each participant will then be asked for this password and can only enter when it is correct.
This password will only be saved for this active conference. When all participants have left the room the password will be reset and the moderator has to enter it again the next time the room is opened. Combined with the other features – you couldn’t be any safer!

5. Complexity warning

Another great feature that you can implement into your Jitsi Instance is the complexity of your room name. How many times have you had mysterious visitors appear in the middle of your meeting? Sometimes when a meeting room has been created, it is common that names like “test” and “room3” would be used and the problem here is, that these names are easy to guess. If you are holding an important meeting that you only want to discuss with select people, then you want to avoid the possibility of unwanted people joining your meeting.

By activating the complexity of the room name, a warning will be shown that the name is too short and easy to be guessed. Although it doesn’t completely stop the use of short-named rooms, it definitely makes the user think twice before opening a room with an easy name that someone could mistakenly enter.

6. Deleting the data

We delete all of the data gathered in the conference rooms every night. Chats, Etherpad edits – everything. You just keep what is stored in the cookies on your side (moderator password for example)

 

So is it safe to use NWS Jitsi for your company meetings, your classroom or for private use? We think YES. We do what ever we can to secure your meetings and your data. Compared to others, we think we are miles ahead regarding safety and security. Join us now and use Jitsi 3 months for free with the coupon code „StayAtHome“

Follow us on Twitter and share your experience with #NWSJitsi

NWS Jitsi – new features!

One reason, why our apps are so good, is we continuously develop or enable new features for the apps. The security of our apps is very important to us. But we also listen to our customers feedback. A lot messages reached us with new feature requests to improve the NWS Jitsi app.

 

We always take feedback serious and if a feature makes sense, we will release it.

And so we will do the next days. We are currently preparing our platform for two new features, which will increase the level of security in your NWS Jitsi App.

 

1. The complexity feature

If you use names like „test“ or „foobar“, it is easy to join your rooms and disturb you and your attendees.

The room name is unsafe. Unwanted participants may join your conference. Consider securing your meeting using the security button. – will be shown to you.

 

Of course you will still be able to use simple room names, but maybe you will think of it twice before typing room3?

 

2. The lobby feature

To secure your Jitsi even more, we have another feature ready for you.
Everyone who wants to secure a room, not just with a complex room name and/or a password, can now activate the „lobby“ feature.
You can enable at any time for every room, the active moderator can then decide who is allowed to join and who is not.

 

 

With these new features, which you can enable at any time for every room, the active moderator can decide, who is allowed to join and who is not.
This way an unrecognised and unknown random person joining is no longer possible.

Keeping the control over a conference room has never been so easy!

 

 

To activate this feature, just click on the shield in the lower right corner and enable it.

Currently we are working on other new features as well, but sometimes it takes time to develop features in such a way that they meet our standards.
So stay tuned and follow us on twitter to get the latest news.

 

Videokonferenz – wie funktioniert das?

Während früher für Videokonferenzen dedizierte Soft- und teilweise auch Hardware erforderlich war, klappt das heutzutage mit jedem modernen Browser. Eine Grundvoraussetzung war sicher die heute verfügbare schnellere Hardware. Was früher zwingend nach optimierten Chips verlangte lässt sich heute problemlos in Software gießen und von jeder Smartphone-CPU umsetzen. Wobei unterstützende CPU-Befehlssatzerweiterungen (z.B. für Teilaspekte der Verschlüsselung) und in Hardware gegossene Unterstützung für den ein oder anderen Videocodec natürlich nicht schaden.

Der Großteil der Arbeit wird aber in Software umgesetzt, und die Grundlagen dafür wurden nicht komplett neu erfunden. Man hat auf bewährte Komponenten gesetzt, aber auch ein paar Dinge anders gemacht. Zusammengefasst wird das Ganze unter dem Begriff WebRTC. Dahinter versteckt sich eine ganze Reihe von Komponenten und Standards. Sowohl die IETF als auch das W3C waren und sind hier mit verschiedensten zugehörigen Standards involviert.

Heute möchte ich ein paar Teilaspekte des Ganzen beleuchten, um verständlicher zu machen welche Magie sich hinter diesem Begriff versteckt. Wir werden unter die Lupe nehmen, wie:

  • Webbrowser via JavaScript Zugriff auf Kamera und Mikrofon ermöglichen
  • mögliche Übertragungswege ermittelt werden (was „dank“ NAT & Co nicht trivial ist)
  • mögliche Datenströme zwischen den Teilnehmern signalisiert werden
  • die eigentlichen Medienstreams übertragen werden
  • Verschlüsselung zustande kommt

Zugriff auf Kamera und Mikrofon

Der Zugriff auf Kamera etc ist bei der ganzen Geschichte der einfachste Teil. Alle namhaften Browser stellen Media Devices / Media Streams bereit. Wer damit experimentieren möchte kann sich entsprechend einlesen oder einfach mal dieses Schnipsel ausprobieren. Einfach in eine HTML-Datei speichern und im Browser öffnen. Wenn alles klappt, dann sollte es in etwa so aussehen:

Wenn jedoch z.B. der Zugriff auf die Kamera nicht gewährt wird, kümmert sich die Fehlerbehandlung darum, eine aussagekräftige Fehlermeldung prominent zu platzieren:

Desktopsharing ist übrigens mittlerweile ähnlich simpel, hier eine kleine Testseite von Mozilla.

Ice Ice Baby

Der nächste Schritt ist schon komplizierter. Eine provisorische Kommunikation zwischen zwei Browserfenstern lässt sich mit Hilfe von Google, Stackoverflow & Co vielleicht noch relativ einfach bewerkstelligen. Eine ernsthafte Software für Videokonferenzen ist aber erstens harte Arbeit und verlangt zweitens auch serverseitig nach entsprechenden Ressourcen.

Raketentechnik passt nicht in einen Blog-Post, aber die grundsätzlichen Prinzipien des Verfahrens möchte ich hier vermitteln:

STUN wird benutzt um mögliche eigene Kandidaten für potentielle Sessions zu ermitteln. Im Idealfall ergibt sich daraus die Möglichkeit, die eigentlichen RTP-Ströme direkt zwischen den Clients zu vermitteln. Dadurch entsteht abgesehen von der Signalisierung auf den Servern keine Last. Das lief schon vor über 10 Jahren wunderbar, und ermöglichte SIP-Providern den Großteil des Traffics gar nicht selbst stemmen zu müssen.

Während das mit dem User hinter einem x-beliebigen DSL-NAT-Router meist wunderbar klappt, scheitert das spätestens, wenn man an ein symmetrisches NAT gerät. Während man als SIP-Anbieter früher recht trickreich versuchte, dann die vermittelten Sessions on-the-fly umzuschreiben um die Datenströme dann über Proxy-Server mit öffentlichen IPs zusammenzuschalten, gibt es mittlerweile zum Glück Standards für dieses Verfahren.

Eine Kernkomponente stellen TURN-Server dar, welche bei Bedarf ein Relay auf sichere Weise bereitstellen können. Zudem wurde das ganze Verfahren zum Verbindungsaufbau unter dem Namen Interactive Connectivity Establishment (ICE) standardisiert und wird für die Kommunikation im Browser vorausgesetzt bzw mitgeliefert.

Wobei Browser hier durchaus raffiniert vorgehen und auch Erweiterungen wie Trickle zur Beschleunigung des Ganzen implementieren.

Signalisierung

ICE bringt uns direkt zum nächsten Thema, die Signalisierung. Informationen über mögliche Transportwege müssen nämlich zwischen den Teilnehmern ausgetauscht werden. Und das nicht nur beim Gesprächsaufbau, sondern auch mittendrin. Schaltet jemand sein Videosignal an oder aus, ergibt das eine Änderung an den benutzten Sessions. Wird die Videoqualität mitten im Gespräch erhöht oder verringert (passiert meist automatisch), dann werden ebenfalls neue Sessions ausgehandelt.

Mögliche Kandidaten für Streams und ausgewählte ebensolche müssen irgendwie definiert und beschrieben werden. Hier kommt ein alter Bekannter aus der SIP-Welt zum Einsatz, nämlich das Session Description Protocol (SDP). Die Art und Weise wie es in den Browsern in JSON eingepackt wird sieht zwar bereits vor, es irgendwann potentiell durch eine Alternative ersetzen zu können. Stand heute ist es aber meines Wissens die einzige Variante, die zum Einsatz kommt.

Einigen müssen sich die Teilnehmer auf Audio und/oder Videocodecs, die Anzahl der involvierten Streams – und nicht zuletzt die zugehörigen Transportwege. Während SDP bei SIP einen der möglichen Inhalte eines SIP-Pakets darstellt, wird es bei WebRTC hier komplizierter. Im Grunde kann jeder Anbieter selbst entscheiden, wie er die Session-Informationen welche sein JavaScript-Code in den jeweiligen Browsern ermittelt zwischen denen und/oder seiner Videoplattform austauscht. Theoretisch können auf dem Signalisierungsweg zwischen den Teilnehmern auch mehrere Server stehen. Auch der Transport zwischen diesen ist im Grunde nicht vorgeschrieben. Grundsätzlich nutzt man SIP (eher zwischen Servern) und/oder (vorzugsweise) XMPP.

Spätestens auf dem Weg zum Browser nutzt man besser einen Standard wie XMPP via BOSH oder Websockets, bei XMPP kommt zudem eine Erweiterung namens Jingle zum Einsatz. Zwingend ist aber die Unterstützung von JSEP, dem JavaScript Session Establishment Protocol. Um jetzt nicht zu sehr ins Detail zu gehen: stellt euch JSEP einfach wie einen JSON-Wrapper für SDP vor. Der Standard beschreibt nicht nur das einzelne Datenpaket und dessen Format, sondern auch den ganzen Ablauf des Auf- und Abbaus von Sessions. Wer es wirklich im Detail verstehen will kommt eh nicht umhin, sich die ganzen (vielen) involvierten Drafts und RFCs zu Gemüte zu führen.

Datenströme – Media Streams

Nachdem unsere Teilnehmer jetzt endlich wissen, was sie wohin senden (und woher empfangen) können, geht es endlich los: wir schicken unseren Stream auf die Reise. Zum Einsatz kommt auch hier ein alter Bekannter, das Real-Time Transport Protocol (RTP). Zum Glück ist auch RTPC, die Erweiterung zur Steuerung der Servicequalität zwingend vorgeschrieben. Bei SIP war das noch optional.

Das Protokoll übernimmt hier das Stückeln der aus dem gewählten Audio/Video-Codec fallenden Pakete. RTP muss sicherstellen, dass ein Stream kontinuierlich, synchron und linear ankommt. Laufzeitunterschiede (Jitter), also Schwankungen in der Übertragungszeit der einzelnen Pakete sollen ausgeglichen werden. Auch das ist eine Wissenschaft für sich.

Wer sich ansehen möchte, welche Streams gerade aktiv sind und wie viele Daten da drübergehen, kann das teilweise in seinem Browser machen – in Chrome z.B. unter chrome://webrtc-internals/. Via JavaScript sind diese Informationen (in unterschiedlicher Ausprägung) übrigens in allen Browsern verfügbar. Man sieht welche Codecs gerade zum Einsatz kommen, ob und wie laut gesprochen wird und wie viele Daten übertragen wurden und werden. Hier setzt übrigens an, wer die Gesprächs- und Videoqualität überwachen möchte.

Verschlüsselung und Sicherheit

Nicht zuletzt geht es spätestens bei den Streams natürlich auch um die Frage der Sicherheit. Die gute Nachricht zuerst: zumindest die Implementierung der Verschlüsselung ist im WebRTC-Standard für alle beteiligten Komponenten vorgeschrieben. Bei den Protokollen finden sich wiederum alte Bekannte, zumindest für den, der sich schon mal mit VoIP-Sicherheit auseinandergesetzt hat:

* Datagram Transport Layer Security – DTLS erlaubt TLS auch für UDP
* Secure Real-Time Transport Protocol – SRTP ist eine effiziente Verschlüsselung für RTP

Nicht verschlüsselt sind Header-Informationen wie z.B. die Lautstärke. Man „sieht“ also auch ohne die Verschlüsselung zu knacken, ob jemand gerade spricht oder nicht. Vor bei SRTP denkbaren MITM-Angriffen schützt bei WebRTC übrigens der Verbindungsaufbau via DTLS.

Die Verschlüsselung erfolgt End-to-End. Auch wenn die Streams über einen TURN-Server geleitet werden kann der Anbieter sie nicht entschlüsseln. Wer sich tiefer in das Thema einarbeiten möchte, dem empfehle ich als Einstiegspunkt A Study of WebRTC Security. Dazu sollte man vielleicht noch sagen, dass hier lediglich versprochen wird, dass die Verbindung zu meinem Gegenüber verschlüsselt ist. Wer aber letztlich mein Gegenüber ist und ob das wirklich mein Gesprächspartner ist, ob dem in der Zwischenzeit jemand das Notebook geklaut hat oder ob gar ein Proxy verschlüsselt mit uns beiden spricht und dabei in der Mitte hängt – das zu unterscheiden ist für den Endnutzer leider nicht mit vertretbarem Aufwand möglich.

Schwieriger wird das Thema Sicherheit zudem, wenn Konferenzen mit mehreren Teilnehmern stattfinden. Wenn nämlich jeder Teilnehmer seinen Stream zu jedem anderen sendet ist bei einer gewöhnlichen DSL-Leitung das Ende der Fahnenstange schnell erreicht. Mischt der Anbieter die Streams zu einem (bzw zu mehreren, weil Teilnehmer teilweise andere Codecs unterstützen), dann ist die schöne End-zu-End-Verschlüsselung aber leider im Eimer.

Eine mögliche Lösung sind SFUs (Selective Forward Units), die kennt man bereits aus der guten alten RTP-Welt. Die brauchen zwar nicht in die Streams zu sehen, können es per Definition aber leider. Eine schöne Lösung bieten hier Insertable Streams, welche mittlerweile in aktuellen Versionen von Firefox, Safari und Chrome verfügbar sind. Ein zugehöriges Jitsi-Issue liefert dem interessierten Leser einen tiefen Einblick in den aktuellen Stand der Technik und die Fortschritte der einzelnen Browserhersteller.

Jitsi ist übrigens eine wunderschöne OpenSource-Lösung für Videokonferenzen. Wer den Aufwand des Betriebs scheut oder es einfach mal ausprobieren möchte kann das jederzeit bei uns machen. Und wenn wir anderweitig zu dem Thema beratend zur Seite stehen können, machen wir das natürlich auch sehr gerne.

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

3 Gründe, wieso Du Jitsi verwenden solltest

Ich muss sagen, ich bin wirklich dankbar und schätze mich sehr glücklich, dass ich zum einen die Möglichkeit habe, von zu Hause aus arbeiten zu können und zum anderen die Möglichkeit bekomme, von zu Hause aus zu arbeiten.

Das bedeutet im Umkehrschluss natürlich, die Kolleg*innen nicht mehr jeden Tag „in echt“ zu sehen, sich mit dem mittelmäßigen Filterkaffee zu Hause zufrieden zu geben und somit nicht mehr den hervorragenden Kaffee im Office zu genießen. Für ersteres gibt es aber – zumindest virtuell – eine Lösung, und zwar Jitsi!

 

Wieso Jitsi?

Damit nicht nur offline, sondern auch online, unser aller Schutz sichergestellt ist, gibt es hier 3 Gründe, die für Jitsi sprechen: Ein Video Conferencing Tool, das es ermöglicht, einfach und unkompliziert mit Arbeitskolleg*innen in Kontakt zu bleiben und Meetings abzuhalten.

1. Deine Sicherheit hat bei uns Priorität! Auch bei der Kommunikation. Daher sind unsere Server dort, wo Du und ich zuhause sind – in Deutschland. Um genauer zu sein, hosten wir Deine Daten in Nürnberg. Ach so, Du lebst nicht in Nürnberg? Auch gut! Egal, wo Dein Zuhause ist, Deine Daten sind in unseren Rechenzentren sicher, Dein Traffic unsichtbar für alle, die ihn nicht sehen sollen.

2. Nimm‘ an Meetings oder Calls teil, wo immer Du gerade bist und von welchem Gerät Du möchtest! HD-Video Calls funktionieren auch in größerer Runde reibungslos. So sieht man sich zumindest virtuell „in echt“.

3. Teile Deinen Screen mit alle am Meeting teilnehmenden Personen, sodass Deine Präsentation, in die Du viel Herzblut gesteckt hast, von jeder*m gesehen wird und sich nicht jede*r einzeln selbst durch die Seiten klicken muss.

Wir im Marketing zum Beispiel nutzen Jitsi jeden Morgen, um unser Stand Up abzuhalten und die Aufgaben des Tages zu besprechen.

 

Noch nicht überzeugt?

Du brauchst noch weitere Gründe? Dann schau‘ Dir das folgende Video an und sieh‘ selbst, wie schnell (und anscheinend auch manchmal lustig) es sein kann, Jitsi zu verwenden:

 

Außerdem geben wir Dir die Möglichkeit, Jitsi momentan kostenfrei zu nutzen.  So siehst Du demnächst Dein Team dann online!

Happy video conferencing!

 

PS: Filterkaffee ist eigentlich ganz ok.