Seite wählen

NETWAYS Blog

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.

Versteckte Director-Features: Update-Only Sync-Regeln

Heute möchte ich ein neues kleines Feature im Icinga-Director vorstellen: die Möglichkeit, mit Sync-Regeln keine vollständigen Objekte zu verwalten, sondern nur bestimmte Eigenschaften von bestehenden Objekten zu steuern. Das klingt erst mal banal, also wozu das Ganze?

Bereits seit der ersten Director-Version ist es möglich, mehrere Import-Quellen in einer Sync-Regel miteinander zu kombinieren. Allerdings ist das in der Praxis nicht immer ganz so einfach. Spätestens wenn die zweite Quelle nur Zusatzinfos liefern soll, dabei aber mehr Hosts als die erste enthält – dann wird es kompliziert. Viele Import-Quellen lassen sich filtern, da kommt man schon weiter. Und seit einiger Zeit gibt es auch wenn die Quelle das nicht kann die Möglichkeit, via Property-Modifier Zeilen filterbasiert zuzulassen oder abzuweisen.

Der übliche Trick an der Stelle ist dann aber häufig das Anlegen von entsprechenden Datenlisten im Director. Diese befüllt man über dedizierte Sync-Regeln mit Leben und kann sie dann via Map-Modifier am primären Host-Import nutzen. Das funktioniert einwandfrei, ist aber ein wenig umständlich.

Director Sync-Rule - Update-Only

Director Sync-Rule – Update-Only

Beides ist mittlerweile nicht mehr erforderlich. Im aktuellen Master-Branch und in der kommenden Version 1.8 gibt es die Möglichkeit, sogenannte “Update-only” Sync-Regeln anzulegen. Dabei kann man einem beliebigen Objekt-Typ (meist Hosts) eine Reihe von zusätzlichen Eigenschaften aus einer anderen Quelle verpassen, ohne aber zu riskieren dass diese Zweitquelle jetzt ungewollt Hosts hinzufügt oder gar entfernt.

Einfach, aber nützlich. Und das war’s auch schon für heute, wünsche euch ein schönes Wochenende!

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.

Das Runde ist das Fleckige

Pandemie. Es sollte wohl so sein,
Jetzt hab ich Zeit und bin daheim.
Blöd gelaufen, doch was mach ich nun?
Ach, es gibt doch immer was zu tun.

Jetzt ist Icinga hier am Start,
Das ging schnell, war nicht hart.
Die Installation ging flott voran,
Doch der Stress fing dann erst an.

Schließlich will ich alles messen
Und dabei auch nichts vergessen.
Dabei war ich ganz beflissen
Um alles überwacht zu wissen.

Ich hab an diesen freien Tagen
Manchen Sensor neu vergraben,
Den halben Garten neu verrohrt
Und manchen Türstock angebohrt.

Kann Kälte und auch Wärme messen,
Weiß wer den ganzen Strom gefressen.
Bewegungsmelder und 'ne Webcam dran:
So seh ich was der Rasenmäher kann.

Mit Gewichtssensor und ein paar Platten
Muss ich jetzt auch nicht mehr raten
Wieviel von diesem schwarzbraunweißen
Zeug die Tauben täglich runter... schmeißen.

Und so meint' ich alles wär bedacht,
Doch wurd ich überrumpelt über Nacht.
Ungeplant war da ein Change passiert
Frech, unverhofft und ungeniert.

Eine Notification gab es nicht,
Keine Webcam hielt was sie verspricht.
Der ganze Garten voll, in jeder Ecke
Ihr glaubt es kaum was ich entdecke.

Das muss wohl dies' Corona sein
Jetzt zieht es auch bei mir hier ein.
Ich flipp gleich aus, das Zeugs ist rund
Sieht aus Eier - doch in bunt!

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.

Irgendwer muss es halt machen

Ostern ist gerade erst vorbei,
Dann Tag der Arbeit, erster Mai.
Davor, danach brauchst Brückentage:
Zur Erholung, keine Frage.

Die Völlerei der letzten Wochen
Zehrte ziemlich an den Knochen.
Die Magenwand hat überstrapaziert
Wer gefastet hat und nicht trainiert.

Geniert euch nicht, euch sei's gegönnt:
Schaltet ab, sooft ihr's könnt.
Bald ist Pfingsten, Christi Himmelfahrt,
Das Leben das ist ganz schön hart.

Nur einer, der muss ständig laufen,
Darf nicht rasten, niemals saufen.
Wird gern beschimpft, sieht selten Lohn
Schuftet mühsam, schwer und monoton.

Muss ständig in die Runde fragen
Bis wirklich alle Hallo sagen,
Meldet alsdann jeden als gestört
Der sein Rufen nicht erhört.

Wer opfert sich für solche Sachen?
Irgendwer muss es halt machen.
Einsam tut damit hervor
Sich von Icinga 2 der Core.

Die Moral von der Geschichte?
Lasst ihn schuften, zu die Kiste.
Eure Woche ist erst mal zu Ende,
Tschüss Icinga, es ist Wochenende!

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.

Monitoring: alles ist geregelt. Aber!

Es könnte so einfach sein. Auf der einen Seite eine Reihe von Import- und Sync-Definitionen welche aus den unterschiedlichsten Quellen unsere zu überwachenden CI’s importieren. Excel, CMDB, Datenbanken, AWS, JSON, YAML, LDAP, VMware, Active Directory – alles geht. Quellen werden kombiniert, Daten angereichert und wo nötig geradegebogen. Egal wie mies die Daten sind, der Director wird’s schon richten.
Auf der anderen Seite stehen mächtige Apply-Regeln. Diese weisen regelbasiert aus einem liebevoll vorbereiteten Service-Katalog das zu was passt. Ausnahmen von der Regel sind knifflig, nämlich dann wenn wöchentlich jemand wieder einen Schwellwert anders haben möchte. Genau dort wo wir’s nicht bedacht haben, dort wo Konstrukte mit vars am Host schnell hässlich werden.

Auch hier hilft der Director, mit den “Custom Variable Overrides” fühlt es sich so an als würde man wirklich diesem einen Service auf dem einen Host einen anderen Schwellwert verpassen. Alles gut soweit. Die Regeln sitzen, für Schwellwerte sind die Overrides da.

Nun ist unsere Welt aber leider nicht perfekt. Und das ist auch gut so, sonst wäre sie furchtbar langweilig. Für unsere Regeln bedeutet das leider, dass sie im Laufe der Zeit immer umfangreicher und komplizierter werden. Bis wir erneut an dem Punkt angelangen, an dem wir wieder am liebsten alles selbst machen würden. Wir haben nämlich Angst, dass es kaputt wird wenn es ein Kollege anpackt.
Klar, der Director hat ein wunderbares Aktivitätslog, man kann hinterher mit dem Finger auf eben diesen Kollegen zeigen und es heroisch selbst wieder geradebiegen. Ein Klick auf “Restore” hilft dabei. Aber wenn man sich dann allein dadurch besser fühlt, dann hat man charakterlich durchaus noch Möglichkeiten an sich selbst zu arbeiten.
Zudem gab es vorher unnötigen Stress. Über zwei Wochen ist niemandem aufgefallen, dass die Checks für einen wichtigen Job auf ein paar Servern verschwunden sind. Am Wochenende ist das Ding an die Wand gerannt, das Monitoring blieb stumm. Bemerkt hat’s der Kunde, und wir mussten uns mal wieder so doofe Sprüche wie “Ja habt ihr denn kein Monitoring?” anhören. Und alles nur, weil jemand mal wieder eine simple doppelte Verneinung falsch verstanden hat.
Mit dem Director v1.5.0 sind die häufigsten Ausnahmen von der Regel jetzt ein Kinderspiel. Man muss die Apply-Regel gar nicht mehr anfassen, einfach auf besagtem Host die Services anzeigen lassen, einen wählen, Blacklist, fertig:

Im Hintergrund rendert der Director passende Ignore-Regeln und alles ist gut. Man kann wieder einen Task mehr an seine Kollegen delegieren und sich um Wichtigere Dinge kümmern. Also den Raspberry der den Wasserstand der Kaffeemaschine im Auge behält. Was in der v1.5.0 sonst noch alles neu ist steht im Release-Blogpost des Icinga-Blogs.

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.

Veranstaltungen

Mi 20

Icinga 2 Advanced Training (englisch class) | Online

Januar 19 @ 09:00 - Januar 21 @ 17:00
Feb 02

Elastic Stack Training | Online

Februar 2 @ 09:00 - Februar 4 @ 17:00
Feb 10

GitLab Fundamentals Training | Online

Februar 10 @ 09:00 - Februar 11 @ 17:00
Feb 23

Terraform mit OpenStack Training | Online

Februar 23 @ 09:00 - Februar 24 @ 17:00
Feb 23

Fundamentals for Puppet | Online

Februar 23 @ 09:00 - Februar 25 @ 17:00