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 MedieRelays 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.

Netzwerk 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 kbps

1:1 Audio mit Bildschirm-Sharing

130 kbps

1:1 Video mit 360p mit 30fps

500 kbps

1:1 Video HD 720p mit 30fps

1.2 Mbps

1:1 Video HD 1080p mit 30fps

1.5 Mbps

Videokonferenz (Je Endpunkt)

500kbps/1Mbps

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

1Mbps/2Mbps

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.

Mediarelay 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.

  • Media Relay
    Es wird immer das aus Sicht des Netzwerks "nächste" Media-Relay genutzt. Weiter unten beschreibe ich, wie Teams vermutlich dieses Relay ermittelt
  • MCU
    Hier wird ebenfalls der Standort gewählt, damit die Teilnehmer kurze Wege haben. Maßgeblich ist der geografische Standort des ersten Teilnehmers, der in das Meeting eintritt.

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 Ressourcemonitor 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.

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-trackes 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