Teams RTP Kommunikation

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

Workloads

Dabei müssen wir verschiedene Anwendungsfälle unterscheiden, denn nicht alle Dienste nutzen die gleichen Protokolle. Ich unterteile Teams dabei in in drei Dienste:

Dienst

Protokoll

Beschreibung

Teams Native Daten

HTTPS://*.teams.microsoft.com
und einige andere

Ein großer Anteil der Daten wird über HTTPS zum Teams-Backend übertragen. Dazu zähle ich Anmelde-Verkehr, Adressbuchsuche, Chats aber auch die Signalisierung für Telefonate und Meetings, Termine und Teams-Daten

Teams externe Daten

HTTPS://<Serviceurl>

Teams kann weitere Dienste integrieren, z.B. 3rd Party Dateiablagen wie Google Drive, DropBox etc., die vom Client dann direkt angesprochen werden. Auch Webseiten und Apps ,die in einem Kanal eingebunden werden, können am Teams Backend vorbei kommunizieren. Aber auch hier kommt meist einfach HTTPS zum Einsatz.

Teams RTP Daten

SRTP/UDP mit Fallback HTTPS

Echtzeitdaten sind alles, was Audio, Video aber auch Desktops-Sharing ist. Hier werden Sprache und Bilder quasi in "Echtzeit" übertragen. Das stellt besondere Herausforderungen an Bandbreiten aber auch Laufzeiten und die Wahl der Wege.

Im folgenden geht es um die "RTP-Daten" und wie diese übertragen werden

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.

Endpunkte und Zwischenstationen

Entsprechend ergeben sich folgende Komponenten und Stationen:

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.

Szenario

Tln 1

Tln 2

Übertragungsweg Audio

A

Standort1

Standort1

Wenn lokale Virenscanner ihnen keinen Strich durch die Rechnung machen, dann sprechen die beiden Endpunkte direkt mit einander. Natürlich ist es erforderlich, dass die Endgeräte auch eingehende Verbindungen erlauben. Eine lokale 3rd Party Firewall kann das verhindern. Smarthones erlauben oft keine eingehende Verbindung.

B

Standort1

Standort2

Ohne Gegenmaßnahmen würden auch hier beide Endpunkte direkt miteinander für RTP kommunizieren. Wenn Sie dies nicht wollen, dann sollten Sie auf dem WAN die Übertragung von RTP-Paketen z.B. über die Port-Range (50000-50059/UDP) unterbinden. Dann müssen die Client über den lokalen Internetausgang über die Media Relays gehen. Das kann soweit führen, dass ein Client in Deutschland ein Relay in Amsterdam nutzt und der Kollegen in den USA z.B. sein naheliegendes Relay in Seattle und die Daten werden dann über das Microsoft Global Netzwerk qualitätsgesichert übertragen.

C

Standort1

Homeoffice

Diese Konstellation entspricht dem Szenario B mit blockierter WAN-Verbindung

D

Standort1

Konferenz

Sobald eine Konferenz im Spiel ist, müssen alle Daten zur Konferenz MCU in der Cloud. Der einzige Weg dorthin geht über die MediaRelays in der Cloud

E

Standort1

Telefon über Microsoft

Telefonverbindungen ins Amt über Microsoft Dialpläne gehen ebenfalls über die Media Relays

F

Standort1

Telefon Direct Routing

Telefonverbindungen ins Amt über einen eigenen SIP-Trunk laufen ohne besondere Einrichtung dennoch erst einmal über die Media-Relays, die dann die Daten über den SIP-Trunk wieder zum eigenen SBC. Der lokale SBC weiß ja nichts über den Standort des Clients

G

Standort1

Telefon Direct Routing Bypass

Sie können aber "Media Bypass" konfigurieren, denn der Client sendet auch seine lokalen Adressen zum Teams Backend und mit "Media Bypass" werden diese Adressen an den SBC weiter gegeben. Ein entsprechend eingerichteter SBC und eine Firewall kann es nun erlauben, dass der Client mit seiner privaten IP-Adresse die öffentliche SBC-Adresse erreicht und RTP damit lokal bleibt und nicht zweimal über das Internet muss.

H

Standort2

Telefon Direct Routing

Dieser Fall entspricht aber wieder dem Fall F, denn der Client ist ja in einem anderen Standort und da zieht es Microsoft erst einmal vor, dass die Sprache über das Teams Backend läuft.

I

Standort2

Telefon Direct Routing Bypass

Sie können aber durchaus die Konfiguration so anpassen, dass der Client im Standort 2 genau wie im Szenario G den SBC im Standort 1 direkt anspricht. Allerdings müssen dann Leitwege, Firewalls und NAT-Regeln dies zulassen und ihre WAN-Leitung die erforderliche Qualität bereitstellen können.

J

Standort2

Telefon Direct Routing LocalMedia

Diese neue Funktion ist im Bild nicht berücksichtigt. Sie können aber einen SBC in einer Niederlassung als Anbindung an eine lokale TK-Anlage oder Amt einrichten, ohne dass dieser SBC auch als SIP-Trunk mit Teams verbunden ist. Dann bleibt RTP dennoch lokal.

K

Home Office

Konferenz

Ein Benutzer zuhause nutzt die Media Relays für eine Meeting-Teilnahme. Dies entspricht dem Szenario "D"

L

Home Office

Telefon über Microsoft

Dieser Fall entspricht dem Szenario "E"

M

Home Office

Telefon Direct Routing

Dieser Fall entspricht dem Szenario "F"

N

Home Office

Telefon Direct Routing Bypass

Sie mögen zwar Media Bypass auf dem SIP-Trunk konfiguriert haben, aber da SBC und Client sich nicht erreichen sollten, gehen die Daten über die Mediarelays wie auch im Szenario "E"

O

Home Office

Telefon Direct Routing LocalMedia

Auch in einer Niederlassung mit SBC ohne SIP-Trunk muss der Client Zuhause erst einmal per RTP über den SIP-Trunk zum zentralen SBC, der dann die Daten über die interne WAN-Verbindung zum SBC und Client vor Ort weitergibt.

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:

Szenario Bandbreite je Richtung

1:1 Audioanruf

30 KBit/s

1:1 Audio mit Bildschirm-Sharing

130 KBit/s

1:1 Video mit 360p mit 30fps

500 KBit/s

1:1 Video HD 720p mit 30fps

1.2 MBit/s

1:1 Video HD 1080p mit 30fps

1.5 MBit/s

Videokonferenz (Je Endpunkt)

500 KBit/s

Gemessene Bandbreite

Zudem habe ich natürlich bei meinem eigenen Taskmanager einfach mal die Auslastung in verschiedenen Konstellationen angeschaut
Szenario Bandbreite ausgehend Bandbreite eingehend

Videokonferenz HD 540p Videos auf einem 1080p Bildschirm (Je Endpunkt)

1 MBit/s

2 MBit/s (vor Corona)

Video-Konferenz (1 Sprecher, 1 PowerPoint, minimiert 12 eingehende Videos im großen Katalog) mit ausgehendem Video/Ton

1 MBit/s

1 MBit/s

Video-Konferenz (1 Sprecher, 1 PowerPoint, minimiert 12 eingehende Videos im großen Katalog) ohne ausgehendes Video/Ton

120 KBit/s

1 MBit/s

Video-Konferenz (1 Sprecher, groß 12 eingehende Videos im großen Katalog) ohne ausgehendes Video/Ton

120 KBit/s

1,6 MBit/s

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.

Achtung: Per Default ist QoS und DSCP abgeschaltet.

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:

Media traffic Client source port Protocol DSCP value DSCP class

Audio

50000–50019

TCP/UDP

46

Expedited Forwarding (EF)

Video

50020–50039

TCP/UDP

34

Assured Forwarding (AF41)

Application/Screen Sharing

50040–50059

TCP/UDP

18

Assured Forwarding (AF21)

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.

Leider sehen Sie hier nicht direkt die UDP-Pakete mit den Port 3478-3481. Wir müssen als schauen, dass im unteren Bereich bei den TCP-Verbindungen keine Daten übertragen werden während bei der Netzwerkaktivität Pakete angezeigt werden.

Kontrolle mit Wireshark

Wenn sie mit Wireshark genauer nachschauen, dann sehen Sie natürlich die UDP-Pakete einer aktiven Sprachverbindung. Sie können einfach auf die

Die Portrange 3479 wird für eine ausgehende Audio-Übertragung genutzt. Das ist dann ein deutlichen Zeichen, dass ich keine 1:1 Verbindung zu meinem Netzwerknachbarn habe und den TURN-Server in der Cloud genutzt habe. Bei einer Verbindung über Direct Routing hingegen ist das Bild etwas anders. Anscheinend stehen die Media-Endpunkte hier direkt im Internet und wenn ich deren Ports direkt erreiche, dann umgeht Teams das Media Relay:

Hier sehen sie gut, dass die Pakete mit dem Codec 104 (SILK/16000) übertragen werden aber manchmal auch 118 (CN/16000) zum Einsatz kommt. Natürlich melden beide Seiten per RTCP auch ihren Status. Die Payload selbst, d.h. Audio, ist natürlich verschlüsselt. Dennoch kann man zumindest sehen, welcher Codec verwendet wird.

Als Beispiel für eine direkte Verbindung im gleichen Subnetz sehen Sie hier eine Verbindung von meinem PC (192.168.178.50) zu einem anderen PC (192.168.178.33), an dem ein Teams User eines anderen Tenant per Federation mit ein Video und Audio gesendet hat.

Beide Systeme kommunizieren direkt mit einander aber jede Richtung nutzt eigene Ports. Grün ist die bidirektionale Audio-Verbindung, die sowohl RTP als auch RTCP enthält. Das Verhalten kann sich aber immer mal ändern. Hier sehe ich eine Audio-Verbindung zwischen zwei Teams-Usern im Homeoffice, die beide über die Office 365 MediaRelay Server gehen.

Hier sehen Sie genau eine aktive UDP-Verbindung, bei der mein Client mit der 192.168.178.50 mit der 52.112.15.208 spricht und in beide Richtungen viele Pakete laufen

Kontrolle mit Fiddler

Damit bleibt natürlich immer noch die Frage, ob man den Handshake nicht auch in der Signalisierung sehen kann. Leider sind die Daten in den mit "CTRL+ALT+SHIFT+1" generierten Protokolldateien noch nicht in Klartext lesbar. Aber Fiddler kann ja den HTTPS-Datenstrom aufbrechen. Allerdings findet man da nur die Signalisierung. Bei einem eingehenden Anruf habe ich auf die anrufender Nummer gefiltert und gesehen, dass der Client eine "Poll" absendet, der dann ca. 30 Sekunden später mit einem 200 OK beantwortet wird.

Die anrufende Nummer erscheint aber nur in genau diesem einen Paket. Der Name des Anrufers erscheint nicht aber wird mit angezeigt. Die "from"-Zeile ist wohl ein Verweis auf einen Kontakt in meiner Umgebung, der aber wohl schon im lokalen Cache vorliegt, denn der Teams Client fordert keine Details an.

Noch viel störender ist aber die Tatsache, dass in keinem Paket die IP-Adresse, ein Port oder SDP-Kandidaten enthalten sind.

Kontrolle im Teams Admin Center

Auf der Suche nach dem Handshake der Kandidaten ist auch das Teams Admin Center nützlich. Wenn ich über "Users" auf meinen Benutzer gehe, dann kann der Administrator unter "Call History" die Verbindungen des Anwenders einsehen.

Wenn Sie dann in den Details des Anrufs auf "Debug" gehen, dann sehen sie eine Unmenge an Parametern mit den entsprechenden Werten. Leider sind diese leider nicht ausführlicher dokumentiert und wenn Sie in einer Konferenz mit Audio, Video und Sharing arbeiten, dann gibt es für jede Verbindung einen eigenen Report, der zudem aus meiner Sicht nicht gerate übersichtlich ist. Ich habe hier einen Report etwas zusammengeschoben, um ein paar interessante Felder abzubilden:

Mit etwas Fantasie können Sie hier zwar nicht alle angebotenen Kandidaten sehen, sondern nur die letztlich genutzten Endpunkte. Hier sind zwei Verbindungen.

  • Teams-Meeing
    Ich habe in keinem meiner Netzwerke eine 10.0136.0 und erst gar nicht als Host. Dabei dürfte es sich in dem Fall um eine Teams Online MCU oder Mediation Server handeln. Dafür spricht auch die PortRange und die direkte Verbindung per UDP von meinem Client zur RemoteSite.
    In die Gegenrichtung ist die 217.91.247.0 eine öffentliche Telekom-IP, hinter der mein Client mit einer privaten IP sitzt. Da er nicht direkt erreichbar ist, muss er sich einem Mediarelay bedienen.
Connectivity_LocalSite             10.0.136.0:52338
Connectivity_LocalAddress          10.0.136.0:52338
Connectivity_PortRange             49152:53247
Connectivity_MediaPathLocal        HostUDP
Connectivity_MediaPathPipe         UDP
Connectivity_RemoteSite            217.91.247.0:7270
Connectivity_RemoteAddress         217.91.247.0:7270
Connectivity_ICEWarn               0x1400000
Connectivity_LocalMR               52.113.201.34:3479
Connectivity_MediaPathRemote       StunUDP
Connectivity_MrDnsE                eu52.tr.teams.microsoft.com
Connectivity_MrDnsU                127.0.0.1
Connectivity_PortRange             50000:50019
  • Eingehender Anruf hinter DSL mit Direct Routing
    Diese Kandidaten sehe ich, wenn ein Amtsteilnehmer mich über meine Nummer bei Net at Work im Homeoffice anruft. 192.168.178.0 ist das private Subnetz hinter der Fritz!Box und 91.48.120.0 die öffentliche DSL-Adresse, vereinfacht auf ein 24er-Subnetz, und wird als Indikator für die Site herangezogen. Ich habe aber wohl eine direkte Verbindung zu dem SBC in Office 365 in deren Subnetz 52.112.148.0
Connectivity_BaseAddress           192.168.178.0:50010
Connectivity_LocalAddress          192.168.178.0:50010
Connectivity_LocalSite             91.48.120.0:62685
Connectivity_RemoteAddress         52.112.148.0:49714
Connectivity_RemoteSite            52.112.148.0:49714
Skype_ResultDetail                 Call cancelled as it was accepted by another fork.

Sie sehen, dass fast alle IP-Adresse auf 24er Subnetze gerundet werden, was zwar für die Bestimmung der Örtlichkeit reicht aber keinen Rückschluss auf das einzelne Gerät zulässt.

Media mit IOS/Android

Bei der Analyse der RTP-Datenströme habe ich auch eine Verbindung zwischen meinem Smartphone und meinem PC aufgebaut. Dazu habe ich mich auf dem Smartphone mit einem Benutzer aus einem anderen Tenant authentifiziert und dann einen VoIP-Call über Federation aufgebaut

  • PC = 192.168.178.50
  • IPhone = 192.168.178.21

Anhand der Wireshark Conversation auf dem PC sehen sie in der ersten Zeile die Richtung vom Smartphone zum PC. Das habe ich erwartet.

In der Gegenrichtung sendet mein PC aber die Daten nicht von der 192.168.178.50 an die 192.168.178.21. Eine Firewall auf dem Smartphone scheint diese eingehende UDP-Verbindung zu verhindern. Die Daten laufen in dem Fall über das Mediarelay. Das ist wichtig zu wissen, wenn in einer Firma sehr viele mobile Smartphones eingesetzt werden. Hier gibt es zumindest in die eine Richtung kein Local Media. Der gleiche Test mit einem Samsung Tab A10.1 (Android 9) zeigte das gleiche Verhalten.

Media Relay und TURN

Das hat mich natürlich erst recht neugierig gemacht, wie Teams den Handshake der Kandidaten ermittelt. Ich habe also Teams beendet, den DNS-Cache geleert und mich mit Fiddler und Wireshark auf die Lauer gelegt. Weiter oben habe ich ja schon beschrieben, dass der Teams Client immer das netzwerktechnisch naheliegenden MediaRelay nutzt. Es gibt Beschreibungen, dass Teams dazu sich mit der Anycast IP-Adresse "52.113.192.2:3478" verbindet und dann zu einem anderen MediaRelay und je nach Dienst auf den den Port 3479-3481 umgeleitet wird.

Das konnte ich so aber nicht beobachten. Mein Teams Client fragte nach "euaz.tr.teams.microsoft.com: type A, class IN" und ist dann über zwei CNAMEs bei einem Server gelandet.

Ich habe dann einen Wireshark-Filter "udp.port ==3478" eingesetzt und dabei ist mit die folgende TURN-Anfrage an einen Server mit der Adresse 52.113.200.3 aufgefallen. Der Client verbindet sich und bekommt natürlich einen 401 zurück. Der Client versucht es dann aber nicht wieder sondern springt nun direkt auf den Server 52.113.201.34.

Wenn Sie sich aber die erste Antwort anschauen dann finden Sie in dem 401 auch ein unbekannten Session Traversal Attribute mit 269 Bytes, die Wireshark noch nicht kennt. Wenn Sie dann die IP-Adresse "52.113.201.34" einmal in HEX-Zahlen (0x34 0x71 0x9c 0x22) umrechnen, dann finden Sie diese Werte in der Antwort. Auch die Suche nach 3479 wird mit "0xd0 0x97" fündig.

Ich interpretiere das dergestalt, dass Teams per DNS sich einen TURN-Server sucht und dieser auf die Verbindungsanfrage mit einer 401-Ablehnung reagiert, in der aber noch weitere Informationen enthalten sind. Diese Verhalten kann Microsoft natürlich jederzeit wieder ändern, da Sie sowohl den Client als auch das Backend betreiben und aktualisieren.

Und Microsoft hat das Verhalten schon geändert, denn mit "eu.turn.microsoft.com" gibt es einen anderen Service, der etwas anders reagiert:

Hier kommt einfach ein "401 Unauthorized" zurück ohne Verweis auf andere Dienste.

UDP mit Carrier Grade NAT

Eine besondere Konfiguration habe ich beim Einsatz mit Carrier Grade NAT gesehen. Ich habe hinter meinem Anschluss bei der "Deutsche Glasfaser" (FTTH mit IPv6 (DG) habe ich keine öffentlichen IPv4-Adresse mehr auf reinem Router. Dennoch zeigt der Ressource Monitor, dass ich meine Desktop Sharing direkt auf die Telekom-IP meines Kollegen im Homeoffice sende.

Das ist ja noch zu verstehen aber ich habe mit Wireshark dann geschaut, ob ich da native IPv6 nutze und wie der Weg ist. Gefunden habe ich dann folgendes Bild:

Sie sehen, dass die Clients über UDP Port 50040 und 50057 direkt 1:1 miteinander kommunizieren Dabei ist es aber interessant, wie der Weg denn funktionieren kann, wenn ich hinter einen Carrier-Grade-NAT sitze. Bei Skype for Business war es normal, dass die Clients in jede Richtung eine Verbindung verhandelt haben (Siehe ICE, Kandidaten, STUN und TURN) aber mit Teams scheint es hier eine neue Option zu geben, dass die Gegenseite auf eine bestehende ausgehende Verbindung auch antwortet und es keinen eigenen Kanal für RTCP gibt. Ich sehe hier nur die beiden direkten Verbindungen.

Local Media SDP

Einen kompletten Ersatz für UCCAPILOG-Analysen und insbesondere die Aushandlung von Teams für RTP-Verbindungen steht noch aus. Mir fehlt z.B.: die Information, wie sich zwei Endgeräte im gleichen Subnetz finden. Der Teams Client kann nicht wirklich wissen, ob er nun in einem Firmennetzwerk oder extern unterwegs ist. Natürlich kann er immer die bekannten MediaRelay-Server in der Cloud ansprechen aber ich hoffe doch noch mal zu ermitteln, wann und wie der Client seine lokalen Kandidaten mit seinem gegenüber im gleichen Netzwerk austauscht. Bislang habe ich in den Fiddler-Traces dazu noch nichts gefunden. Es könnte aber sein, dass die Daten natürlich nicht direkt lesbar sind.

Sobald ich hier mehr weiß, werde ich es hier dokumentieren.

Weitere Links

Sehr interessante Vorträge sind auch:

Understanding Media Flows in Microsoft Teams - BRK4016
https://youtube.com/watch?v=1tmHMIlAQdo

Media in Teams - Media Flow
https://youtube.com/watch?v=p8ml3jYt9KI