Teams RTP Kommunikation

Wer über die Bandbreite redet, muss natürlich erst einmal wissen, wie Teams kommuniziert und welche Wege genutzt werden.

References:

LogoTeams RTP KommunikationMSXFAQ
URL
1MB
Teams RTP Kommunikation.pdf
PDF
Open
Download entire document

RTP-Verbindungen

Bei der Kommunikation in SIP-Systemen erfolgt nur die Signalisierung über SIP und die Audio-Daten werden ebenfalls per RTP übertragen.

  • 1:1 Same Site Wenn zwei Clients im gleichen Netzwerk sind, dann ist eine direkte Verbindung der beiden Clients natürlich optimal. Das passiert unabhängig davon, in welchem Tenant die Anwender sind sondern ist eine reine IP-Verbindung.

  • 1:1 Cross Site Das stimmt so aber nicht mehr unbedingt, wenn sie zwei Client in einem Verbundnetzwerk betrachten, die sich direkt erreichen könnten aber die dies nicht wollen. Eine Firma mit zwei Standorten und einem eigenen WAN möchte vielleicht gerade nicht, dass diese Datenleitung nun auch durch Sprache oder gar Video belastet wird. Wenn jeder Standort einen eigenen Internetausgang hat, ist das sogar möglich.

  • 1:n Konferenz Sobald mehr als zwei Personen miteinander kommunizieren, ist eine Konferenz-MCU der Mittelpunkt, die von Microsoft bereit gestellt wird. Alle Clients verbinden sich dann über das Media-Relay in der Cloud mit der Microsoft MCU

  • 1: Telefon Microsoft Dialplan Wer über Microsoft ein Amtsgespräch führt und dazu die Dialpläne gekauft hat, muss seine Audiodaten natürlich zum passenden Übergang bei Microsoft übertragen.

  • Federation und Homeoffice Verbindungen zu anderen Firmen oder Mitarbeitern zuhause sind ebenfalls nicht direkt möglich. Selbst wenn Sie per VPNs oder Site-Links zu Partnerfirmen eine geroutete Verbindung ermöglichen, sollten Sie Audio besser nicht durch solche Tunnel schicken.

Die Stationen können folgende Verbindungen aufnehmen:

  1. Firmenclient im Standort 1 Der Client kann bei einer 1:1 Verbindung zu einem anderen internen Client im gleichen Standort direkt kommunizieren. Zu anderen Standorten muss dies nicht der Fall sein. Er muss aber auch die Mediarelay-Systeme von Teams in der Cloud idealerweise über UDP-Port 3478-3481 erreichen

  2. Firmenclient im Standort 2 Entspricht dem Firmenclient im Standort 1

  3. Anwender zuhause oder Konferenzgast Der Client zuhause kann natürlich keine direkten Verbindungen aufbauen und spricht für Audio/Video quasi immer mit dem Media-Relay. Es sei denn zwei Mitarbeiter wären im gleichen Homeoffice.

  4. Mediarelays / TURN-Server Dies sind die Arbeitstiere für Audio/Video, das Sie mit ihrem öffentlichen IP-Adressen von allen Endpunkten erreicht werden sollen und als Relay für die Daten agieren. Das für den Client passende Relay ermittelt das Teams Backend anhand der Netzwerk-Nähe zum Client. Bei Skype for Business war der Edge-Server durch den Pool vorgegeben. Die Relays leihen jedem Client quasi eine öffentliche IP-Adresse:Port-Kombination und leitet die Pakete einfach weiter. Es findet hier keine Umcodierung oder Entschlüsselung statt.

  5. MCU - Multicast Unit Konferenzen werden über diese Systeme vermittelt. Die Clients müssen immer über ein Media Relay ankommen und eine Konferenz läuft meines Wissens auch weiterhin immer auf genau einer MCU. Die MCU muss die verschlüsselten SRTP-Pakete decodieren, neu zusammenstellen (Mixen) und neu verschlüsselt wieder an die anderen Teilnehmer übermitteln.

  6. SBC zum PSTN Um noch klassische Telefone und Mobilfunk einzubinden, können Sie über die Session Border Controller bei Microsoft (Dialplan-Kosten) oder eigene SBCs bzw. Provider (Direct Routing) die Verbindung herstellen.

Nicht immer kommen alle roten Wege zum Einsatz.

Matrix

ich habe daher folgende Tabelle erstellt.

Die Tabelle gilt so nur, wenn Sie die Empfehlungen von Microsoft bezüglich Firewalls und Netzwerkfreischaltungen berücksichtigt haben und insbesondere die UDP-Ports 3478-3481 in Richtung der Teams MediaRelays freigeschaltet sind. Ansonsten kann Teams die Daten immer noch über 443/TCP tunneln.

Sonderfall Smartphone Bei allen Verbindungen, die eingehende UDP-Pakete erlauben sollen, muss der Client auch UDP-Ports öffnen können. Das ist bei vielen Smartphones nicht immer möglich, so dass diese ausgehend noch direkt senden aber eingehende Ströme über die TransportRelays gehen.

Auch wenn dies erst einmal viele Szenarien bedeuten, so sind einige Szenarien identisch. Ich habe Sie dennoch zur Erläuterung mit aufgeführt. Wenn Sie einmal verstanden haben, wie Teams "tickt" und welche Komponenten ineinandergreifen, dann können Sie sich die Lösung auch selbst herleiten.

Geplante Bandbreite

Audio und Video-Verbindungen sind immer 1:1 Verbindungen zwischen zwei Endpunkten. Bei einer Konferenz ist die MCU die Spinne im Netzwerk. Für jede Verbindung können sie aber eine erwartete Bandbreite angeben, die je nach verwendeter Funktion unterschiedlich hoch ist.

Das sind alles Durchschnittswerte. Wenn Sie nichts sagen, dann wechselt Teams den Code auf "Comfort Noise (CN)" und überträgt weniger Daten. Wenn sich im Video nicht viel bewegt, dann reduziert sic auch die Datenmenge. Beim der Bildschirmfreigabe hat natürlich die Auflösung entsprechende Auswirkungen. Da die komplette Signalisierung über die Cloud geht, kann Microsoft hier aktiv in den Handshake eingreifen und bestimmte Codecs und Limits vorgeben. Während der COVID-19-Zeit wurden z.B. Videokonferenzen auf 1MBit pro Client gedrosselt.

Microsoft nennt selbst folgende Werte für die eigenen Berechnungen:

Für ein seriöses Sizing müssen Sie pro Standort die Anzahl der gleichzeitigen Verbindungen vermitteln. Das ist nie genau möglich, da selbst die bisherige Nutzung einer Konferenzlösung nur bedingt für eine Vorhersage der zukünftigen Teams-Nutzung ist.

Hier ist also Erfahrung und eine belastbare Einschätzung erforderlich. Darauf verlassen würde ich mich aber nie. Sie sollten ein Netzwerk Assessment nutzen und auch die Auslastung aktiv überwachen.

Netzwerk und QoS

Wie wissen zwar nun, welche Bandbreite auf ihrem Netzwerk erwartet werden kann aber die Qualität der Übertragung ist nur gewährleistet, wenn genug "Platz" ist. In einem unmanaged WAN kommen aber viele Absender und Ziele zusammen und stauen sich im schlimmsten Falle an den Engstellen. hier kann es sinnvoll sein, die Bandbreiten zu steuern, quasi die BUS/TAXI-Spur für Teams-Pakete. Dafür muss das Netzwerk aber erst einmal verstehen, welche Pakete zu Teams gehören. Es gibt ja durchaus noch weitere UDP-Pakete und die Verschlüsselung macht die Erkennung auch nicht leichter.

Im Teams AdminCenter können und sollten Sie als Administrator die QoS-Markierung in Abstimmung mit den Netzwerken aktivieren. Viel wichtiger finde ich aber die Möglichkeit die von Teams für die drei Dienste verwendeten Ports vorgeben zu können.

So können Sie auf Firewalls nicht nur die "Allow-Regeln" enger fassen sondern auch noch die Pakete auf Routern und Switches besser klassifizieren und z.B. per NetFlow auswerten.

Die QoS-Settings weisen folgende DSCP Tags per Default aus:

Ich habe noch nicht kontrolliert, ob Teams als "user" oder im Browser auch diese QoS-Tags tatsächlich setzen kann. Sie sind aber nicht änderbar. Allerdings kann ein Netzwerk-Administrator auf dem Switch in der Regel die Taggings entfernen und neu vergeben. Ein Administrator kann auch per Gruppenrichtlinien unter Windows die Tags setzt oder auf dem Switch umschreiben.

TransportRelay und MCU-Auswahl

Mit Skype for Business hatten Sie als Anwender einen "Home-Pool" und ausgehend von diesem Pool wurde ihnen auch eine MCU und Edge-Server zugeteilt. Die Zuordnung war statisch und hat keine Rücksicht auf ihre Position im Netzwerk genommen. Das konnte dazu führen, dass ein Mitarbeiter in einem europäischen Tenant, der zu Besuch in der US-Niederlassung war, sich nicht nur mit dem Home-Pool in Amsterdam für die Signalisierung verbunden hat sondern auch die Meetings und Edge-Services aus Amsterdam geliefert wurden. Die Pakete gingen also bis zu zweimal über den Atlantik. Wenn Sie dann ein Meeting gestartet haben, wurde auch das im Land ihres Tenant gehostet, selbst wenn die Mehrzahl der Anwender auf der anderen Seite der Erde war. Mit Teams wurde dies geändert.

  • TransportRelay Es wird immer das aus Sicht des Netzwerks "nächste" TransportRelay genutzt. Es handelt sich dabei um eine Anycast-IP-Adresse (Siehe Anycast-Routing) und führt den Client selbst bei Fehlerhafter DNS-Konfiguration in der Regel zum "nächsten" Azure Transport-Relay

  • KonferenzMCU Der erste Teilnehmer, der das Meeting startet verbindet sich über sein TransportRelay zu einer nahestehenden MCU. Das kann natürlich bedeuten, dass die MCU nicht in der Nähe des Präsenters ist. Alle anderen Teilnehmer verbinden sich mit der gleichen MCU, selbst wenn es ein 1000er Meeting ist. Da die Verbindung aber immer über das schnelle Azure-Netzwerk geht, sollten die Latenzzeiten erträglich sein.

Dennoch kann natürlich folgende Situation eintreten:

  • Sie planen ein Meeting mit mehreren Teilnehmern in ihrer Firma in Deutschland und wenigen Teilnehmern aus USA bzw. APAC.

  • Die Teilnehmer aus USA/APAC sind "früh" im Meeting Damit kann die MCU in den USA oder auch APAC genutzt werden.

  • Ineffektiv für DE Die deutschen Teilnehmer haben dann eine deutlich längere Latenzzeit zur MCU auf der anderen Seite der Welt.

Das ist in dem Fall nicht zu ändern. Sie können aber über zwei Wege dieses Verhalten steuern

  • Früher sein Sie können natürlich das Meeting einfach früher selbst starten.

  • Versteckter Link Sie können einen "Link-Verkürzer" nutzen, den sie den Teilnehmern senden. Der richtige Meeting-Link haben dann erst einmal nur die Organisatoren. Erst kurz vor dem Meeting aktivieren Sie die Weiterleitung der Kurz-URL auf das eigentliche Meeting.

Allerdings ist das natürlich ein zusätzlicher Aufwand mit entsprechendem Wissen.

Kontrolle mit Bordmittel

Bei Skype for Business war es aus meiner Sicht noch einfacher, die angebotenen und letztlich ausgehandelten Kandidaten zu analysieren. Über das UCCAPI-Logging (Siehe Lync Keyhole Diagnose) konnten Sie die SIP-Pakete mitschneiden und darin gezielt nach den SDP-Kandidaten (siehe ICE, Kandidaten, STUN und TURN) suchen. Das ist in Teams nicht mehr ganz so einfach, da die Kommunikation nun über HTTPS erfolgt und Sie die Pakete nur indirekt über Fiddler sehen können. Als erste Kontrolle würde ich daher immer den Windows Ressourcenmonitor heranziehen, der auch die aktuell übertragenen Pakete anzeigt. Ich filtere immer zuerst auf den Prozess "Teams" und dann betrachte ich die Netzwerkaktivität. Hier habe ich mit "Jetzt Besprechen" ein Meeting mit nur mit als Teilnehmer gestartet.

Last updated