Zoom

Vor kurzem wurde ich tatsächlich das erste mal in ein "Zoom"-Meeting eingeladen. Ein externer Dienstleister zwei zwei weitere Teilnehmer und mich in einer Video-Konferenz über sein Vorgehen informiert. Neben dem interessanten Inhalte haben ich natürlich die Chance genutzt, auch die "Erfahrung" mit dem Zoom Client als Konferenzteilnehmer zu protokollieren.

Mittlerweile habe ich an sehr vielen Zoom-Meetings teilgenommen und stelle fest, dass auch die Anzeige von mehr als 9 Video-Streams durchaus seinen Reiz hat. Für eine Video-Lösung ist das ein Vorteil. Aber mich nervt, dass dann Whiteboards z.B. über miro.com, Kanalchats über Slack und Dateifreigaben dann über Dropbox, GoogleDrive o.ä. ablaufen. Da ist mit der Teams-Ansatz angenehmer, bei dem alles an einer Stelle ist.

Diese Seite wird nicht laufend aktualisiert und einige Aussagen sind sckher nicht mehr aktuell.

Datenschutz

Zoom ist, wie WhatsApp und Microsoft 365/Teams eine Cloud-Lösung. Der Anbieter betreibt die entsprechenden Server und erhebt in der Regel nicht nur Daten zur Anmeldung und sichert den Betrieb, sondern sammelt oft auch weitere Daten. Bewerten sie daher jeweils den aktuellen Stand. Insbesondere "kostenfreie" Angebote bezahlen durch die Preisgabe von Daten oder die Sicherheit der Lösung hat nicht die gewünschte Wichtigkeit:

Wobei man auch hier relativieren muss. Gerade das letzte Szenario mit "End-to-end" Meetings ist bei Skype und Teams auch nicht anders. Die Konferenz-MCU in der Mitte kann auch bei Teams mitlesen, da sie die Daten ja vom Sender entschlüsseln und zu jedem Empfänger neu verschlüsseln muss. Sonst könnte auch "Recording" nicht funktionieren.

Join und Installation

Es fängt wie immer mit einer URL an. Bei Zoom haben die das Format "https://zoom.us/j/<nummer>" und sind insofern nicht so gar viel unterschiedlich zu Teams, Skype, Cisco und Co. Heute ist Internet und ein Browser fast immer der Einstiegspunkt und der Anbieter kann über den Browser dem Anwender die verschiedenen Optionen ermitteln und anbieten. Bei mir wurde vom Browser ein kleiner Client gestartet, der dann einen größeren Client heruntergeladen und installiert hat. Ich durfte meinen Namen zur späteren Anzeige im Meeting eingeben und musste mich mit den Nutzungsbedingungen und Datenschutzrichtlinien einverstanden erklären

 

Soweit nichts besonderes. Durch die Installation sind in meinem Startmenü zwei Einträge zum Start und Deinstallation des Zoom Clients addiert wordem

Der eigentliche Zoom-Client mit ca. 30 MB landete in "C:\Users\username\AppData\Roaming\Zoom"  (%appdata%\zoom). So ist keine Zustimmung des Administrators erforderlich.

Meeting

Die eigentliche Meeting-Teilnahme ist für jemand, der schon mit Livemeeting/OCS, Lync, Skype for Business und Teams gearbeitet hat, nicht sonderlich überraschend Natürlich sehen Bildschirm und Menüs etwas anderes aus, aber es ist alles an einem erwarteten Platz. Wenn sie mehrere Autos unterschiedlicher Hersteller fahren, dann kommen Sie mit den Grundfunktionen ja auch zurecht.

  • Teilbild
    Wenn ich das Meeting als Fenster auf meinem Desktop anzeige, dann habe ich folgende Ansicht gesehen.
  • Vollbild
    Bei einer Umschaltung zum "Vollbild" auf FullHD sind die Bilder der Teilnehmer nach Rechts gewandert.

Das Layout unterscheidet sich also etwas von Teams.

Netzwerk/RTP

Natürlich hat mich interessiert, wie Zoom im Hintergrund arbeitet. Ich kenne ja schon recht gut die Funktionen von Skype for Business hinsichtlich RTP; ICE, STUN und TURN und meine Firewall hat ausgehend auch 3478/UDP erlaubt. Dennoch scheint Zoom nur 443/TCP zu verwenden. Audio und Video wurden über diesen Weg zu mir übertragen und auch meine Sprache wurde per 443/TCP versendet.

Solange die Verbindung wenig "paketloss" hat, ist dieses Verfahren durchaus nutzbar und Teams/Skype nutzen auch 443/TCP, wenn der Weg per UDP nicht möglich ist. Sobald aber Paketverluste einsetzen, versucht der TCP-Stack die fehlenden Pakete wieder anzufordern. Diese Retransmits sind überflüssig, da die Informationen ja schon in der Vergangenheit liegen. UDP wäre hier auf jeden Fall besser.

Bei einem Meeting im Mai 2020 mit Zoom Version 5.0.4 habe ich noch einmal die Verbindung analysiert und diesmal kam UDP zum Einsatz:

Leider kann WireShark die Pakete selbst nicht als RTP-Protokoll decodieren.

Das macht es für Firewall-Administratoren nicht gerade einfacher diese Pakete anhand der Payload passieren zu lassen. Aber das ist bei Office 365 auch nicht viel anders. Hier müssen auch IP-Adressen frei gegeben werden

Das Meeting wurde über eine US-Meeting-URL gestartet aber laut Informationsanzeige in europäischen Datacenter gehostet.

Der Name des Hosts "us02web.zoom.us" [3.235.73.94] suggeriert natürlich ein System in USA und auch wenn es ein europäisches Meeting ist, würden Metadaten des Meetings außerhalb von Europa landen. Ein Traceroute belegt auch, dass zumindest im Mai 2020 dieser Service noch in den USA liegt:

C:\>tracert us02web.zoom.us

Routenverfolgung zu us02web.zoom.us [3.235.73.120] über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.178.1]
  2     5 ms     4 ms     5 ms  p3e9bf2dc.dip0.t-ipconnect.de [62.155.242.220]
  3    12 ms    12 ms    12 ms  217.5.116.106
  4    11 ms    11 ms    12 ms  ffm-b4-link.telia.net [213.248.93.186]
  5   102 ms   103 ms   102 ms  ffm-bb1-link.telia.net [62.115.114.88]
  6   103 ms   102 ms   103 ms  prs-bb3-link.telia.net [62.115.123.13]
  7   101 ms   101 ms   101 ms  ash-bb2-link.telia.net [62.115.112.242]
  8   101 ms   101 ms   101 ms  ash-b1-link.telia.net [62.115.143.121]
  9   102 ms   102 ms   102 ms  vadata-ic-333120-ash-b1.c.telia.net [62.115.11.249]
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11     *        *        *     Zeitüberschreitung der Anforderung.
 12   108 ms   108 ms   107 ms  52.93.29.24
 13     *        *        *     Zeitüberschreitung der Anforderung.
 14     *        *        *     Zeitüberschreitung der Anforderung.

Über 100ms bedeutet, dass der Service hinter 3.235.73.120 nicht mehr in Europa ist.

Daher habe ich auch die UDP-Gegenstelle mir mal genauer angeschaut und ermittelt, wo 3.124.41.70 zu verorten ist.. Ein Traceroute bringt hier den Weg, über die Latenzzeit die Entfernung und anhand der aufgelösten Namen etwas Licht ins Dunkel:

C:\>tracert 3.124.41.70

Routenverfolgung zu ec2-3-124-41-70.eu-central-1.compute.amazonaws.com [3.124.41.70] über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  fritz.box [192.168.178.1]
  2     5 ms     5 ms     5 ms  p3e9bf2dc.dip0.t-ipconnect.de [62.155.242.220]
  3    12 ms    12 ms    13 ms  217.5.116.98
  4    12 ms    11 ms    11 ms  62.157.251.154
  5    25 ms    25 ms    24 ms  54.239.107.244
  6    11 ms    11 ms    12 ms  52.93.111.140
  7    25 ms    24 ms    25 ms  52.93.111.141
  8    14 ms    13 ms    12 ms  54.239.107.139
  9    41 ms    39 ms    37 ms  150.222.104.48
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11     *        *        *     Zeitüberschreitung der Anforderung.
 12     *        *        *     Zeitüberschreitung der Anforderung.
 13     *        *        *     Zeitüberschreitung der Anforderung.
 14     *        *        *     Zeitüberschreitung der Anforderung.
 15     *        *        *     Zeitüberschreitung der Anforderung.
 16    12 ms    13 ms    13 ms  ec2-3-124-41-70.eu-central-1.compute.amazonaws.com [3.124.41.70]

Die Zoom-MCU dieses Meetings wurde bei Amazon gehostet und der Name suggeriert ein europäisches Datacenter. Auch die Geschwindigkeit belegt zumindest die räumliche Nähe. Über einen Ozean wären hier 50-80ms zu addieren.

Prozesse

Während des Meeting, bei dem ich mein Video gesendet und vier drei kleine andere Streams empfangen habe, konnte ich folgende CPU- und Netzwerklast sehen:

Die Last ist richtig niedrig und während des Meetings scheint der Client nur mit einem Host zu kommunizieren.

Bei einem aktiven Meeting ist im Mail 2020 besser zu sehen, dass UDP genutzt wird und Zoom auch eingehende UDP-Ports geöffnet hat.

 

Mit 300kBit/Sek war der Bandbreitenbedarf vertretbar. Wenn wir mal 50-100KBit für Audio annehmen, dann sind 200-250kBit für Video natürlich kein HD der VGA-Strom. Wenn die Gegenstellen auch nur "kleine Bilder" gesehen haben, dann ist das erklärbar. Bei der Netzwerkanalyse war ja zu sehen, dass Zoom über TCP/443 geht und damit entfällt natürlich ein tieferer Blick in die RTP-Datenströme, so dass ich nichts zu Codecs oder Auflösungen sagen kann.

Ende

Alles hat irgendwann ein Ende und so habe ich meine Teilnahme nicht selbst beendet, sondern habe abgewartet. In meinem Fall wurde auch meine Sitzung beendet, als der Moderator, der zu dem Meeting eingeladen hat, das Meeting verlassen hat.

Ich habe nicht verifizieren können, wie sich das Meeting bei einem ungeplanten Verbindungsverlust des Moderators verhält. Ich hoffe, dass Zoom das Meeting dann nicht sofort beendet sondern etwas wartet, ob der Moderator sich wieder verbunden hat. Wenn Sie als Moderator das Meeting verlassen, dann sehen Sie den folgenden Dialog:

Also Organisator haben Sie also die Wahl, ob Sie das Meeting für alle Teilnehmer beenden. Als Organisator kann ich auch alle Teilnehmer stumm schalten aber die Stummschaltung auch für alle Teilnehmer wieder aufheben.

Das bedeutet, dass der Leiter aus der Ferne das Mikrofon der vorher stumm geschalteten Teilnehmer wieder aktivieren kann. Der Teilnehmer bekommt weder eine Rückfrage noch eine deutlich Meldung sondern sieht nur, dass da Mikrofon-Symbol nicht mehr durchgestrichen ist.

Hinterlassenschaft

Mit dem Ende des Meetings und der Bestätigung per "OK" hat sich aber der Zoom-Client nicht beendet. Ich habe es nicht sofort bemerkt, aber in der Taskleiste hat sich der Zoom-Client eingenistet.

Da ich selbst bislang noch nie Zoom verwendet habe und auch kein kostenpflichtiges Konto besitze, habe ich mit dem Meeting-Ende auch erwartet, dass sich der Client beendet. Ich habe ja sonst keine Verwendung dafür. Dass er sich nicht gleich deinstalliert, ist ja wohl in der Branche üblich und machen WebEx und andere auch so. Also habe ich ohne ein Meeting aber mit Fiddler den Client gestartet und zugeschaut, was er macht:

Er nutzt die Proxy-Einstellungen des Windows Hosts und diese Pakete sind alle am Anfang übertragen worden. Ich habe danach über 30Min keine weiteren Übertragungen gesehen. Der Client fällt zumindest nicht mit einen Heartbeat o.ä. auf. Allerdings sind die Pakete durchaus interessant. Zuerst habe ich mir einen Host geschnappt, um die Entfernung und Latenzzeit zu ermitteln

C:\>tracert us04as.zoom.us

Routenverfolgung zu us04as.zoom.us [3.80.20.173] über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.178.1]
  2     5 ms     5 ms     4 ms  62.155.242.220
  3    11 ms    10 ms    10 ms  217.5.116.114
  4    11 ms     *       11 ms  ffm-b4-link.telia.net [213.248.93.186]
  5    98 ms    97 ms    98 ms  ffm-bb2-link.telia.net [62.115.114.90]
  6   100 ms     *      100 ms  prs-bb4-link.telia.net [62.115.114.98]
  7    98 ms     *        *     ash-bb3-link.telia.net [62.115.122.159]
  8   113 ms   112 ms   113 ms  ash-b1-link.telia.net [62.115.143.79]
  9   116 ms   116 ms   117 ms  vadata-ic-333118-ash-b1.c.telia.net [62.115.11.183]
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11     *        *        *     Zeitüberschreitung der Anforderung.
 12   113 ms   112 ms   113 ms  52.93.29.44
 13     *        *        *     Zeitüberschreitung der Anforderung.
 14     *        *        *     Zeitüberschreitung der Anforderung.

Die letzte IP-Adresse, die eine Antwort gegeben hat, ist bei Amazon verortet.


Quelle: http://geoiplookup.net/ip/52.93.29.44

Da auch die Latenzzeit entsprechend hoch ist, dürfte die Angabe stimmen, dass Zoom hier Services von Amazon AWS nutzt.

XMPP, Inventory und mehr

Wenn ich mit Fiddler die HTTP-Anfragen schon mal mitgeschnitten habe, dann schaue ich da natürlich auch rein. Schon die Hostnamen lassen vermuten, was hier passiert:

  • Inventory
    Ein wenig möchte Zoom wohl schon über den verwendeten Client in Erfahrung bringen.
  • XMPP Pakete
    Anscheinend nutzt Zoom zur Signalisierung das Protokoll XMPP. Mein User hat wohl auch eine Art SIP-Adresse in der Domain "xmpp.zoom.us"
  • WebSocket für Audio/Video?
    Der Hostname "zpnspbx" deutet auf "PBX = Telefonie" hin und könnte ein Hinweis für eine Audio-MCU sein. Das ist es dann wohl sinnvoll den HTTPS Stream zu einem WebSocket hochzustufen.
  • Media-Relay über HTTPS
    Mehr sieht man hier noch beim Start eines Meetings:
  • Ignoriert Zertifikate
    Mehr als einmal hat Fiddler sich aber beschwert, dass der vom Client angefragt Name nicht mit dem gelieferten Zertifikat übereinstimmt

    Entweder ignoriert der Zoom-Client den Fehler oder die Verbindung. Beides wäre nicht schön

Einschätzung

Wenn es um Audio/Video-Konferenzen im Internet mit PCS, Browsern aber auch Konferenz-Systemen geht, ist Zoom in der kurzen Zeit der Gründung (2011) bis jetzt ein neuer gewichtiger Player im Feld geworden, der es anderen Lösungen wie WebEx, TeamViewer aber auch Teams hinsichtlich Konferenzen schwer machen kann. Jeder kann kostenfrei Konferenzen mit bis zu 40 Minuten Dauer einladen. Das kann für gelegentliche Konferenzen kleinerer Firmen ausreichend sein. Durch entsprechende Partnerschaften (HP Hardware Poly Hardware, Slack) und die Integration von bestehenden Konferenzgeräten (Cisco, Poly) und Interoperabilität mit Lync/Skype und bald auch Teams könnte die Nutzerbasis weiter wachsen.

Allerdings ist Zoom aktuell eben "nur" eine Audio/Video"-Plattform aus der Cloud und mit Teams daher nur bedingt vergleichbar. Ich könnte mit aber vorstellen, dass Zooms z.B. in Slack integriert wird oder ein anderer Hersteller sein Portfolio damit erweitert.

Meine Meetings wurden bei meinen Tests aber über Server in den USA betrieben. Eine Einwahl über Telefon ist in Deutschland über zwei normale Berliner Rufnummern möglich. Das funktioniert trotz der Latenzzeiten bislang recht passabel. Wem das nicht reicht kann mittlerweile sogar eigene lokale Server betreiben. Wenn Zoom weiter wächst, erwarte ich auch näher stehende Server.

Weitere Links