Teams Client Netzwerk

Diese Seite beschreibt die besonderen Anforderungen an das Netzwerk des Teams Client. Der Teams Client wird zukünftig eine wichtige Rolle in der Endgerätenutzung einnehmen und da er als "Browser Anwendung" nur beschränkt Zugriff auf lokale Dienste hat, kommen die meisten Daten "über das Netzwerk". Damit sind wir mitten im Thema.

Workloads

Der Microsoft Teams Client stellt verschiedene Dienste bereit, die über unterschiedliche Protokolle und an verschiedene Endpunkte zugreifen. Dieses Wissen ist für die Planung und Umsetzung wichtig,

Funktion Protokoll Endpunkt Netzwerkanforderungen

Infrastrukturpakete

  • An/Abmeldung
  • Statusaktualisierung und Anzeige
  • Adressbuchsuche
  • HTTP
  • teams.microsoft.com
  • nicht Echtzeit
  • Proxytauglich
  • eher kByte/Sek

Teamarbeit

  • Instant Messages, Teams-Chat
  • Arbeiten in Kanälen
  • Terminplanung/Kalender
  • HTTP
  • teams.microsoft.com
  • nicht Echtzeit
  • Proxytauglich
  • eher kByte/Sek
  • Mehr bei Up/Download von Dateien

Teams Audio/Video

  • 1:1 Audio/Video Calls
  • PSTN-Anrufe
  • Group-Calls
  • A/V-Meeting
  • RTP/UDP
  • RTP/TCP
  • RTP/HTTP
  • tr.teams.microsoft.com
  • lokal erreichbarer SBC
  • Echtzeit, geringe Latenzzeiten
  • Wenig Packetloss
  • Proxy nachteilig
  • Audio ca. 100kBit/Sek
  • Video ca. 1000kBt/Sek

Teams Apps

Teams kann durch zusätzliche Apps erweitert werden
  • meist HTTP
  • verschiedene App Endpunkte

Abhängig von der Applikation

Die meisten Dienste nutzen HTTP als Transport. Übertragen werden aber nicht nur HTML-Dokumente. HTTP ist auch Transport für REST/JSON/XML-Datenstrukturen, d.h. Apps in JavaScript können auf dem Client komplexe Datenabfragen- und Übertragungen ausführen.

Sonderfall Audio/Video

Es gibt sehr viele Seiten auf der MSXFAQ zu dieser besonderen Funktion aber ich möchte hier ganz kurz die wichtigsten Aussagen noch mal zusammenfassen und als Checkliste bereitstellen, die aus meiner Sicht für eine optimale Audio/Video-Leistung mit Teams erforderlich sind. Für Audio/Video sollten Sie sich folgende Fakten merken:

  • Viele kleine kontinuierliche Pakete
    Im Gegensatz zur Übertragung von "Daten", d.h. Office-Dokumente, Software, Tastatureingaben etc., bestehen Audio/Video-Pakete aus kleinen Paketen (20ms Sprache passen in 160bytes), von denen viele (50/Sek) übertragen werden. Ihre Router, Switches, Firewalls müssen viel mehr auf "Pakete/Sek" statt auf "Megabit/Sek" optimiert sein.
  • Packetloss und Retransmit
    Ein verworfenes oder zu spät eintreffendes Paket wird nicht mehr wiedergegeben. Daher ist es auch nutzlos dieses erneut anzufordern. Genau das macht aber TCP und HTTP ohne das Teams davon was mitbekommt. Teams sieht nur eine Unterbrechung des TCP-Datenstroms, bis die Lücke gefüllt ist. Das Video und der Ton werden "angehalten". Nur wenn Teams über UDP arbeitet, kann es solche Verluste überspringen und die Wiedergabe fortsetzen. Natürlich sagt Teams dem Absender bescheid, dass die Qualität schlechter ist und der Absender kann die Bitrate reduzieren (Mono statt Stereo, Narrowband statt Wideband, weniger Auflösung, weniger Bilder/Sek)
  • Bidirektional
    Bei Datenverkehr gibt es meist eine dominante Richtung, d.h. auf eine kleine Anfrage kommen viele Megabytes zurück oder ich lade eine große Datei hoch. Die Last ist "asynchron" und daher haben viele DSL-Anschlüsse ja mehr Downstream. Mit Audio/Video ändert sich das.
  • Echtzeit
    Und dann muss das alles noch schnell sein, denn wenn ein Sprachpaket über 100ms unterwegs ist, leidet die Meeting-Qualität weil sich Pausen bilden und Reaktionen verzögert werden.

Diese Anforderungen sind für Datenübertragungen nicht so streng, da hier eher stoßweise Datenübertragungen stattfinden und die fehlerfreie, verlustfreie Übertragung in der richtigen Reihenfolge sowieso erforderlich ist. Da sich kaum eine Anwendung selbst drum kümmern möchte, ist TCP oder HTTP dort der Regelfall. Das ist bei Teams aber nicht der Fall. Sie können als Teilnehmer eines Meetings aber Probleme schon am Verhalten des Clients erkennen.

Wenn das Video "einfriert", der Ton "ausfällt", dann kann das entweder ein richtig langer Paketverlust sein. Das ist aber eher selten sondern eher ein Zeichen, dass ein Paket verloren gegangen ist und der TCP-Stack nun auf die Nachlieferung wartet, ehe er die bereits empfangenen Pakete an Teams übergibt. Da Audio und Video unterschiedliche Ströme sind, könnten sich auch Abweichungen zwischen Bild und Ton sehen. Wenn das Video einfach nur "schlechter" ist aber im Grund schon kontinuierlich läuft, dann überspringt die Wiedergabe die verlorenen Pakete und macht mit den nachfolgenden Paketen weiter. Es fehlt aber nur z.B. ein 20ms Tonfragment, was kaum auffällt.

Checkliste

Mit all dem Wissen ist auch schnell beschrieben, welche Anforderungen ein Teams-Client an das Netzwerk stellt:

Kriterium Check

UDP statt TCP oder HTTP

Microsoft Teams kann alle drei Wege nutzen und starte mit UDP. Wenn dies nicht geht, nutzt er TCP und wenn auch das nicht geht, HTTPS. sogar über Proxy-Server. Aber das wollen Sie nicht und es ist auch nicht "supportet":


https://docs.microsoft.com/en-us/microsoftteams/3-envision-evaluate-my-environment#firewall-and-proxy-requirements

Das ist aber nicht nur ein "so daher gesagtes" Statement sondern es gibt schon klare technische Gründe (s.o.) für diese Forderung.

Kleiner Tipp: Über den Windows Ressource Monitor können Sie für den Prozess "Teams" die verwendeten Gegenstellen sehen. Bei einem Meeting sehen Sie allein aufgrund der Datenmenge schon, ob ein interner Proxy oder eine TCP-Verbindung statt UDP genutzt wird. Oder sie nutzen Wireshark und Co

HTTP-Proxy, nein Danke

Damit ist aber auch verständlich, dass der Umweg über einen HTTP-Proxy nicht nur etwas schlechter ist sondern den Erfolg von Teams maßgeblich gefährdet. Sie merken diese nicht bei den Daten-Paketen, d.h. An/Abmeldung, Arbeit in Teams und Kanälen und selbst die Arbeit mit Dokumenten ist damit meist problemlos möglich. Da kommt es auf 10-20 Millisekunden mehr Laufzeit nicht an und Paketverluste müssen eh korrigiert werden.

Audio/Video hat aber nichts auf diesem Weg verloren. Das beschreibt auch Zscaler.


Quelle: https://community.Zscaler.com/t/microsoft-teams-with-Zscaler/6320/3

WLAN

Eine stabile Netzwerkverbindung für Teams ist bei Audio/Video essentiell. Gerade im "Home Office" fehlt das Verständnis für die Funktion von WLAN. YouTube-Streaming ist kein Teams Video, denn Streaming kann mehrere Sekunden puffern und damit Engpässe problemlos überspielen. Auch Daten (App Updates, WhatsApp-Messages, Instagram-Bilder etc.) sind nicht zeitkritisch.

Alle Echtzeit-Plattformen, sei es Teams, Zoom, WebEx o.ä. haben hohe Anforderungen, die aber am besten über eine Kabelverbindung gelöst werden. Wenn dann die Probleme minimiert wurden, kann der Standort über ein optimiertes WLAN-Deployment nachdenken.

VPN/Local Breakout

Laufzeiten sind kurz, wenn die Wege kurz sind. Wenn ihr HomeOffice-User aber ein "TunnelVPN" in die Firma nutzt und Teams-Daten ebenfalls vom Home-Provider über ein Peering zum Firmenprovider und erst dann zu Microsoft laufen, dann ist das sicher kein Vorteil. Das gilt vergleichbar für Niederlassungen ohne eigenen Internetzugriff, bei denen die Cloud-Daten erst durch das eigene WAN laufen.

"Halb schwanger" geht nicht und wer Cloud-Dienste nutzt, vertraut dem Anbieter. Ansonsten sollten Sie ihre Daten dort nicht ablegen. Dann sollten sie aber diese Gegenstellen nicht als "Internet" bezeichnen sondern als "ausgelagertes vertrauenswürdiges Datacenter".

Dazu gehört natürlich auch eine passend konfigurierte Namensauflösung. Ihr Client sollte zumindest die Cloud-Namen entlang der Datenverbindung und nicht über das VPN oder einen unpassenden DNS-Service wie 8.8.8.8/1.1.1.1 oder 9.9.9.9 auflösen.

Dies ist nur eine Kurzfassung einer umfangreichen Analyse und Optimierung der Netzwerkverbindungen. Cloud-Dienste sind im Vergleich zu lokalen nun mal viel weiter entfernt. Wenn lokal ein Server in 1ms oder schneller erreichbar ist, sind Cloud-Dienste selbst mit selten erreichten 10ms schon 10-mal so langsam.

Weitere Links