Teams Transport Relay
Wenn sich zwei Teams Endpunkte nicht direkt (im LAN) erreichen können oder ein Meeting nutzen, dann müssen die RTP-Daten über das Teams Transport Relay in der Cloud laufen. Auf dieser Seite analysiere ich den Weg vom Teams Client zu diesem Relay und welche Fehler dabei auftreten können.
Welche Relay ist das richtige?
Darauf gibt es genau eine Antwort: "Das Nächste aus Netzwerksicht". Wer die Prinzipien der Office 365 Verbindungen kennt (Siehe Cloud Verbindung) weiß, dass Microsoft den Weg über das "Internet" möglichst kurz halten möchte und über entsprechende Peerings sein Azure Netzwerk möglichst nahe an die Kunden bringt. Es kann also sogar sinnvoller sein, in einer Niederlassung direkt diese Ziele ins Internet ausbrechen zu lassen und über einen kurzen Weg zum nächsten Azure-Eingang zu leiten. Microsoft hat dazu entsprechende Vorträge gehalten, dass Teams eine Anycast-IP-Adresse nutzt (Siehe auch Anycast-Routing)
Understanding Media Flows in Microsoft Teams - BRK4016
(2018)
https://youtu.be/1tmHMIlAQdo?t=967
“Theoretically All Transport relays have the same IP-Address"
Media in Teams - Media Flow
https://youtu.be/p8ml3jYt9KI?t=443
Das Problem dabei ist aber, dass ich mit Wireshark keine Verbindungen auf die Adresse 52.113.192.2 finden konnte aber dafür DNS-Anfragen auf einen Namen.worldaz.tr.eams.microsoft.com. Interessant finde ich aber auch die Aussage auf "https://youtu.be/1tmHMIlAQdo?t=967", dass es eine Unterscheidung nach dem Tenant gibt. Aufgrund legislativer Vorgaben müssen einige Tenants bestimmte Transport Relays nutzen und EU-Tenants nutzen angeblich nur die Transportrelais in EU und NA. Es gibt natürlich viele Standorte und in dem folgenden Vortrag ist das Bild auch nur ein Bespiel.
Quelle:https://youtu.be/1tmHMIlAQdo?t=1169
In dem Zuge ist dann noch die folgende Folie interessant, wie der Client arbeitet:
Quelle:
https://youtu.be/1tmHMIlAQdo?t=1421
- HTTP für Credentials
Er nutzt HTTPS://teams.microsoft.com um sich Credentials zu holen - UDP über Anycast-IP an einen TURN-Server
Hier greift er dann auf einen TURN-Server zu und bekommt angeblich die Dedicated-IP des Servers - ICE
Dann kommt der ICE-Handshake, bei dem der Client sich auch Kandidaten vom Transport Relay besorgt und dann
In dem Bild ist aber nicht dokumentiert, dass der Client seine ICE-Auswahl an die Gegenstelle dann wieder per HTTPS übermittelt.
Relay im Provisioning
Die Aussage, dass EU-Tenants nur die Relays in EU nutzen, hat mich etwas irritiert. Allein aus dem UDP-Paket kann ein TURN-Server ja nicht ermitteln. welcher Region mein Tenant zugeordnet ist. Also habe ich Teams im Browser gestartet und per Chromium Debugger im Local Storage nach "Relay" gesucht. Ich wurde hier auch direkt fündig:
Hier taucht der Name "eu.turn.teams.microsoft.com" auf. Der Name verweist auch auf die ebenfalls abgelegte IP-Adresse 13.107.65.150 (Stand Juni 2022) und dürfte die Anycast-Adresse für europäische Tenants sein. Welche Namen z.B. Chinesische Tenants nutzen, weiss ich noch nicht aber die "weltweiten" Tenants verwenden vermutlich "worldaz.tr.teams.microsoft.com"
Office Connectivity Test
Denn acuh die Microsoft Testseite auf https://connectivity.office.com nutzt selbst für mich als angemeldeten Benutzer nicht die EU-Adresse, sondern macht selbst einen Traceroute zu dem statischen Namen: "worldaz.tr.teams.microsoft.com"
Damit unterscheidet sich Teams von Skype vor Business fundamental. Bei Skype for Business hat der Client bei einer externen Anmeldung über den Edge Server an seinen Frontend Server auch den Namen des Edge-Servers erhalten. Der Client nutzte immer den seinem Pool zugewiesenen Edge-Server.
Der in dem Fall auf Dienstreise in den USA war aber einen Skype for Business On-Premises Homeserver in Deutschland hatte, hat sich aus den USA "über das Internet" bis zum Edge-Server in Deutschland verbunden.
DNS und worldaz.tr.teams.microsoft.com
Mit dem Wissen um den Namen können wir nun eine Auflösung starten.
PS C:\> Resolve-DnsName worldaz.tr.teams.microsoft.com -type A Name Type TTL Section NameHost ---- ---- --- ------- -------- worldaz.tr.teams.microsoft.com CNAME 0 Answer worldaz.tr.teams.trafficmanager.net worldaz.tr.teams.trafficmanager.net CNAME 0 Answer a-tr-teasc-ukwe-07.ukwest.cloudapp.azure.com Name : a-tr-teasc-euwe-13.westeurope.cloudapp.azure.com QueryType : A TTL : 10 Section : Answer IP4Address : 52.114.253.113
An meinem Anschluss liefert die erste Auflösung einen CNAME auf "worldaz.tr.teams.trafficmanager.net", der dann wieder einen CNAME auf "a-tr-teasc-ukwe-07.ukwest.cloudapp.azure.com" liefert, der dann auf eine IP-Adresse gemappt wird. Mich interessiert hier natürlich der A-Eintrag und hier insbesondere, welche Antworten ich auf mehrere DNS-Anfragen bekomme.
Eine ähnliche Auswertung habe ich auch auf Teams Turn over TCP schon beschrieben.
Zuerst wollte ich mal die IP-Adressen kennenlernen und habe aus dem DNS einfach nur die IP-Adresse extrahiert:
PS C:\> (Resolve-DnsName worldaz.tr.teams.microsoft.com -Type A)[-1].ipaddress
Diese Zeile habe ich nun einfach 1000-mal gestartet und die Ausgabe gruppiert. Ich habe in meinem Fall 166 Einträge ermittelt und entsprechend wurden einige IP-Adressen natürlich mehrfach geliefert:
PS C:\> $iplist= 1..1000 | %{(Resolve-DnsName worldaz.tr.teams.microsoft.com -Type A)[-1].ipaddress} |group -NoElement PS C:\> $iplist.count 166 PS C:\> $iplist | sort count -Descending Count Name ----- ---- 14 52.112.172.3 11 52.114.255.115 11 52.114.231.4 11 52.112.175.0 11 52.114.233.7 10 52.112.175.3 10 52.112.168.216 10 52.112.175.43 10 52.114.253.253 10 52.113.202.126 10 52.112.172.5 10 52.112.175.41 9 52.113.201.195 9 52.113.201.194 9 52.114.255.116 9 52.114.93.12 9 52.114.73.2 9 52.112.172.4 9 52.114.255.113 9 52.114.251.235 9 52.114.249.121 9 52.114.252.5 9 52.112.171.13 8 52.112.173.8 8 52.113.200.173 8 52.113.200.117 8 52.112.168.210 8 52.114.252.6 8 52.114.94.5 8 52.114.90.2 8 52.114.242.3 8 52.114.249.194 8 52.114.233.75 8 52.112.168.80 8 52.114.255.119 8 52.112.172.255 8 52.114.93.13 8 52.113.202.223 8 52.112.171.15 8 52.112.172.108 8 52.113.201.206 7 52.114.254.176 7 52.114.233.3 7 52.114.233.2 7 52.114.253.35 7 52.114.231.3 7 52.114.255.117 7 52.114.255.118 7 52.113.204.104 7 52.113.204.127 7 52.113.204.62 7 52.113.200.192 7 52.114.93.228 7 52.112.168.212 7 52.112.168.214 7 52.114.250.45 7 52.112.170.248 7 52.114.251.80 7 52.112.171.11 7 52.114.73.0 7 52.114.93.15 7 52.112.172.110 7 52.112.172.252 7 52.114.251.81 7 52.114.93.11 7 52.114.79.25 7 52.114.89.0 6 52.112.175.40 6 52.114.94.220 6 52.114.253.252 6 52.114.242.0 6 52.114.242.1 6 52.114.242.2 6 52.114.251.82 6 52.114.252.7 6 52.113.200.4 6 52.112.168.211 6 52.114.249.120 6 52.112.168.209 6 52.114.249.122 6 52.114.252.8 6 52.113.202.255 6 52.114.249.220 6 52.114.233.1 6 52.113.201.197 6 52.114.93.229 6 52.112.173.9 6 52.112.171.181 6 52.114.254.20 6 52.114.231.0 6 52.114.254.205 6 52.114.93.2 6 52.113.204.24 6 52.114.93.16 6 52.112.173.76 6 52.113.201.207 6 52.114.93.14 6 52.114.233.145 6 52.114.251.79 5 52.114.255.255 5 52.114.93.9 5 52.114.94.184 5 52.114.94.4 5 52.114.93.0 5 52.112.168.208 5 52.114.94.8 5 52.112.175.1 5 52.113.202.67 5 52.113.204.9 5 52.112.175.38 5 52.114.231.2 5 52.112.170.249 5 52.113.201.192 5 52.114.233.0 5 52.114.94.7 5 52.112.171.12 5 52.114.241.12 5 52.112.172.109 5 52.112.172.2 5 52.114.248.1 5 52.114.248.240 5 52.114.248.44 5 52.114.249.195 5 52.114.251.77 5 52.112.172.0 4 52.114.79.0 4 52.114.93.192 4 52.114.255.191 4 52.112.175.39 4 52.114.89.2 4 52.114.231.1 4 52.112.171.14 4 52.114.253.57 4 52.112.168.217 4 52.114.253.254 4 52.114.253.113 4 52.114.242.4 4 52.114.249.193 4 52.113.201.196 4 52.113.200.6 3 52.114.94.47 3 52.112.172.1 3 52.114.94.48 3 52.114.94.6 3 52.112.172.254 3 52.114.233.4 3 52.114.89.1 3 52.112.175.42 3 52.114.249.192 3 52.113.201.193 3 52.113.201.205 3 52.113.202.62 3 52.112.173.7 2 52.112.173.10 2 52.112.168.213 2 52.114.252.9 2 52.114.253.193 2 52.112.168.215 2 52.114.93.230 2 52.114.253.8 2 52.112.171.10 2 52.114.255.211 2 52.113.200.5 2 52.113.200.0 2 52.114.253.4 2 52.114.251.234
Interessant ist aber, dass ich bei jeder Anfrage immer wieder eine neue Adresse bekommen habe. Hier greift also weder der DNS-Cache meiner FRITZ!Box noch der Provider o.ä. Aber Europa scheint zu dem Zeitpunkt gerade mal 166 Server als Transport Relay bereitstellt. Wenn Sie genau hingeschaut haben, dann enthält auch der Name eine "geografische Region:
PS C:\> (Resolve-DnsName worldaz.tr.teams.microsoft.com -Type A)[-1].name a-tr-teasc-ukso-05.uksouth.cloudapp.azure.com
Da steht der Servername aber auch eine Region an zweiter Stelle.
Achtung: Es ist nicht sichergestellt, dass an der zweiten Stelle immer die Region liegt.
Auch diesen Wert kann ich per PowerShell einfach extrahieren:
PS C:\> (Resolve-DnsName worldaz.tr.teams.microsoft.com -Type A)[-1].name.split(".")[1] uksouth
Auch hier bietet sich mal eine 1000er Serie mit Gruppierung an:
PS C:\> 1..1000 | %{(Resolve-DnsName worldaz.tr.teams.microsoft.com -Type A)[-1].name.split(".")[1]} | group -NoElement Count Name ----- ---- 152 francecentral 193 northeurope 175 uksouth 272 ukwest 208 westeurope
Auch diese Auswertung ist durchaus interessant, da Sie mir ja sagt, welche Datacenter meinem Internetzugang zugeordnet sind. Es quasi keine Affinität meines Clients zu genau einen Transportrelay und nicht mal einem geografischen Standort.
Nun hat mit natürlich interessiert, wie dies mit anderen Regionen aussieht und über "ungefiltert-Surfen.de" lassen sich einfach DNS-Server im Internet finden, die mir Antworten liefern. So habe ich am 11.4.2021 dann eine Testserie mit folgendem Aufruf gestartet.
1..100 ` | %{(Resolve-DnsName ` -Name worldaz.tr.teams.microsoft.com ` -Type A -Server <servername ` )[-1].name} ` | group -NoElement ` | ft -AutoSize
Da die meisten Antworten aber die gleichen Server liefern, hilft die Gruppierung.
Bei der Wahl der DNS-Server müssen Sie aufpassen, dass Sie wirklich einen DNS-Server vor Ort erreichen und nicht eine Firewall, Provider oder ein Anycast-DNS ihre Anfrage lokal beantwortet. Den Traceroute und Ping zur Laufzeitmessung habe nicht weiter dokumentiert. Die Zahlen passen nicht immer genau, da Sie aus mehreren Messungen entstanden sind.
DNS-Server wurden von www.ungefiltert-surfen.de entnommen.
DNS-Server | Land | Regionen | Namen |
---|---|---|---|
198.199.103.49 |
San Francisco, USA |
Count Name ----- ---- 6 canadacentral.cloudapp.azure.com 8 canadaeast.cloudapp.azure.com 31 eastus.cloudapp.azure.com 14 eastus2.cloudapp.azure.com 5 northcentralus.cloudapp.azure.com 25 westus.cloudapp.azure.com 9 westus2.cloudapp.azure.com |
Dass die amerikanischen Anwender primär in den USA landen, war so zu erwarten. Ich habe auch 1000 Abfragen gestellt, um über Mehrfachantworten etwas die Gesamtzahl der Server in der Region abschätzen zu können. Insgesamt habe ich 60 unterschiedliche Server aufgelöst. |
200.148.191.197 |
Sao Paulo Brasilien |
Count Name ----- ---- 7 canadacentral 10 canadaeast 28 eastus 18 eastus2 13 northcentralus 17 westus 7 westus2 |
Anscheinend gibt es in Südamerika keine lokalen Transportrelay-Systeme für Teams, denn alle Namen verweisen auf USA oder sogar Kanada. |
114.114.115.115 |
Baidu, China |
eastus westus |
Count Name ----- ---- 8 a-tr-teasc-usea-06.eastus.cloudapp.azure.com 11 a-tr-teasc-usea2-05.eastus2.cloudapp.azure.com 77 b-tr-teams-usea-01.eastus.cloudapp.azure.com |
180.76.76.76 |
China |
koreasouth koreacentral |
koreasouth.cloudapp.azure.com koreacentral.cloudapp.azure.com |
146.230.128.6 |
Durban, Südafrika TENET-1 |
koreasouth koreacentral japanwest eastasia |
Count Name ----- ---- 1 a-tr-teams-krcn-02.koreacentral.cloudapp.azure.com 1 a-tr-teasc-asea-02.eastasia.cloudapp.azure.com 7 a-tr-teasc-jpwe-01.japanwest.cloudapp.azure.com 1 b-tr-teams-krso-01.koreasouth.cloudapp.azure.com |
146.230.254.16 |
Durban, Südafrika TENET-1 |
Count Name ----- ---- 12 francecentral 25 northeurope 20 uksouth 15 ukwest 26 westeurope |
Interessant sind hier die anderen Regionen, obwohl 146.230.254.16 und 146.230.128.6 am gleichen Ort und sogar gleichen Provider sind. Da wäre schon mal interessant zu wissen, welche Clients diese DNS-Server fragen, denn die einen landen quasi in Europa während die anderen in APAC landen. |
154.73.209.69 |
Johannesburg Südafrika |
koreasouth koreacentral japanwest eastasia |
Count Name ----- ---- 11 b-tr-teasc-jpwe-02.japanwest.cloudapp.azure.com 10 a-tr-teams-krcn-02.koreacentral.cloudapp.azure.com 9 a-tr-teams-krcn-01.koreacentral.cloudapp.azure.com 6 a-tr-teasc-jpwe-02.japanwest.cloudapp.azure.com 6 b-tr-teasc-asse-01.southeastasia.cloudapp.azure.com 6 b-tr-teasc-asse-06.southeastasia.cloudapp.azure.com 5 a-tr-teams-krso-01.koreasouth.cloudapp.azure.com 5 b-tr-teasc-asea-04.eastasia.cloudapp.azure.com 5 b-tr-teasc-asse-02.southeastasia.cloudapp.azure.com 4 a-tr-teams-krso-02.koreasouth.cloudapp.azure.com 4 a-tr-teasc-asea-03.eastasia.cloudapp.azure.com 4 a-tr-teasc-asea-04.eastasia.cloudapp.azure.com 4 a-tr-teasc-asse-03.southeastasia.cloudapp.azure.com 4 a-tr-teasc-asse-05.southeastasia.cloudapp.azure.com 4 b-tr-teams-krcn-02.koreacentral.cloudapp.azure.com 4 b-tr-teams-krso-01.koreasouth.cloudapp.azure.com 4 b-tr-teasc-asea-02.eastasia.cloudapp.azure.com 1 b-tr-teasc-asea-01.eastasia.cloudapp.azure.com 1 b-tr-teasc-asse-03.southeastasia.cloudapp.azure.com |
117.18.119.42 |
Hongkong Commercial Internet Exchange |
Count Name ----- ---- 12 eastasia 26 japanwest 12 koreacentral 4 koreasouth 46 southeastasia |
Count Name ----- ---- 4 a-tr-teams-krcn-01.koreacentral.cloudapp.azure.com 8 a-tr-teams-krso-01.koreasouth.cloudapp.azure.com 3 a-tr-teams-krso-02.koreasouth.cloudapp.azure.com 3 a-tr-teasc-asea-01.eastasia.cloudapp.azure.com 4 a-tr-teasc-asea-02.eastasia.cloudapp.azure.com 3 a-tr-teasc-asse-01.southeastasia.cloudapp.azure.com 4 a-tr-teasc-asse-02.southeastasia.cloudapp.azure.com 4 a-tr-teasc-asse-05.southeastasia.cloudapp.azure.com 4 a-tr-teasc-jpwe-01.japanwest.cloudapp.azure.com 1 a-tr-teasc-jpwe-03.japanwest.cloudapp.azure.com 10 b-tr-teams-krcn-01.koreacentral.cloudapp.azure.com 3 b-tr-teams-krso-01.koreasouth.cloudapp.azure.com 3 b-tr-teasc-asea-02.eastasia.cloudapp.azure.com 8 b-tr-teasc-asea-03.eastasia.cloudapp.azure.com 4 b-tr-teasc-asse-01.southeastasia.cloudapp.azure.com 3 b-tr-teasc-asse-03.southeastasia.cloudapp.azure.com 4 b-tr-teasc-asse-04.southeastasia.cloudapp.azure.com 7 b-tr-teasc-asse-06.southeastasia.cloudapp.azure.com 8 b-tr-teasc-jpwe-01.japanwest.cloudapp.azure.com 8 b-tr-teasc-jpwe-02.japanwest.cloudapp.azure.com 4 b-tr-teasc-jpwe-03.japanwest.cloudapp.azure.com |
45.225.123.34 |
Brasilien |
Count Name ----- ---- 57 eastus 7 eastus2 15 northcentralus 5 westus 16 westus2 |
Count Name ----- ---- 4 a-tr-teams-caea-02.canadaeast.cloudapp.azure.com 1 a-tr-teams-usea-01.eastus.cloudapp.azure.com 3 a-tr-teams-uswe-01.westus.cloudapp.azure.com 6 a-tr-teams-uswe-02.westus.cloudapp.azure.com 5 a-tr-teams-uswe2-02.westus2.cloudapp.azure.com 2 a-tr-teasc-usea2-05.eastus2.cloudapp.azure.com 2 a-tr-teasc-uswe-01.westus.cloudapp.azure.com 13 b-tr-teams-caea-02.canadaeast.cloudapp.azure.com 3 b-tr-teams-usea-02.eastus.cloudapp.azure.com 18 b-tr-teasc-usea-01.eastus.cloudapp.azure.com 3 b-tr-teasc-usea-05.eastus.cloudapp.azure.com 21 b-tr-teasc-usea2-06.eastus2.cloudapp.azure.com 19 b-tr-teasc-uswe-02.westus.cloudapp.azure.com |
203.63.219.26 |
Perth, Australien |
Count Name ----- ---- 49 australiaeast 51 australiasoutheast |
Count Name ----- ---- 10 a-tr-teams-auea-01.australiaeast.cloudapp.azure.com 19 a-tr-teams-ause-01.australiasoutheast.cloudapp.azure.com 12 a-tr-teams-ause-02.australiasoutheast.cloudapp.azure.com 4 a-tr-teams-ause-03.australiasoutheast.cloudapp.azure.com 3 a-tr-teasc-auea-01.australiaeast.cloudapp.azure.com 5 a-tr-teasc-auea-02.australiaeast.cloudapp.azure.com 15 b-tr-teams-auea-01.australiaeast.cloudapp.azure.com 2 b-tr-teams-ause-01.australiasoutheast.cloudapp.azure.com 15 b-tr-teams-ause-02.australiasoutheast.cloudapp.azure.com 3 b-tr-teams-ause-03.australiasoutheast.cloudapp.azure.com 12 b-tr-teasc-auea-02.australiaeast.cloudapp.azure.com |
Die Daten sind schon interessant und wenn ich viele DNS-Server weiterer Provider sehr oft abfragen würde, könnte man eine umfangreiche Liste der Standorte und der Anzahl von Teams Transport Relays ermitteln.
-
CNAME vs A-Record
Die richtige Art einen Alias auf echte Server zu verweisen
166 + 60 Turn-Server
Ich habe mich natürlich gefragt, ob diese Zahl an Servern stimmen kann. Laut Satya Nadella in der Keynote zur MSBuild 2021 nutzen täglich ca. 145 Mio Benutzer Teams. Die werden nun nicht alle auch damit dauernd telefonieren oder in Meetings sein. Technisch sind aber all diese Anwender "Extern" und müssen über ein Transport Relay den Weg zu ihrer Konferenz-MCU finden. Nur bei 1:1 Gesprächen zwischen internen Teilnehmern oder gegen ein Gateway mit Direct Routing und Media Bypass kann das Transport-Relay entfallen.
Dennoch kann ich natürlich 145 Mio Anwender nicht mit echten Anwendern gleichsetzen. Es gibt ja viele Kunden mit "Teams for Collab Only" oder anderen Konferenzlösungen. Gehen wir aber mal davon aus, dass dennoch 20% in einer Audio-Konferenz sind. Dann sind das 28Mio Anwender mit ca. 100kBit, was sie zu 2,8 TBit aufsummiert. Wenn diese Last auf vielleicht 200 Server verteilt wird, dann sind das 14GBit/Server. Das ist schon unverschämt viel Last, die ja auch durch das Transport Relay empfangen und gesendet werden müssen.
In der Rechnung ist ja noch nicht mal Video enthalten. Ich bin sehr sicher, dass die ermittelte Anzahl der Server deutlich höher ist und einfach per DNS-Anfragen nicht ermittelt werden kann.
Wenn ich irgendwann einmal reale Zahlen in Erfahrung bringen kann und darüber schreiben darf, dann finden Sie dies hier.
- Direct Routing und Media Bypass
- Where in the world will my Microsoft
Teams meeting be hosted?
https://tomtalks.blog/2019/06/where-in-the-world-will-my-microsoft-teams-meeting-by-hosted/
Latenz zu worldaz.tr.teams.microsoft.com
Aber das Bild liefert mir noch eine zweite wichtige Information. DNS ist wichtig. Wenn Sie alle DNS-Server nach dem Namen ""teams.microsoft.com" befragen. dann bekommen Sie immer die gleiche IP-Adresse geliefert. Der HTTPS-Datenstrom nutzt "Anycast-Routing-Adressen" aber die RTP-Datenstrom nutzt durchaus Geo-DNS.
Damit ist es wichtig, dass ihr Client die "richtige DNS-Auflösung" nutzt. Ein Split-VPN nutzt nichts, wenn der Mitarbeiter dennoch alle DNS-Anfragen durch den VPN-Tunnel zur Firma sendet.
Die Media-Relays und Latenzzeit habe ich mit End2End-UDP3478 schon mehrfach untersucht und auch der Microsoft Connectivity Analyzer unter "https://connectivity.office.com" testet auch die Laufzeit zum Transport Relay.
Ich habe auf dem gleichen System parallel auch mein End2End-UDP3478 laufen lassen und ähnliche Werte erhalten:
s
Meine Latenzzeiten (Average) lagen anfangs bei 32-37ms. Aber dann hab es 20 "Aussetzer" und danach war die durchschnittliche Latenzzeit sogar konstant bei 10ms.
Ich muss das Skript später noch einmal erweitern, damit es auch den real angesprochenen TURN-Server ausgibt.
Bei dem Test-System handelte es sich um eine AzureVM in der Region EASTUS.
Auf dem Computer habe ich auch mit Rimscout (https://www.rimscout.com) den Test gemacht und auch hier sind die Werte am Anfang der Messung noch identisch bei 33-35ms als Mittelwert.
Quelle: Rimscout Client
Mein Rimscout Client (https://www.rimscout.com) läuft idealerweise auf allen Desktops im Hintergrund mit und prüft kontinuierlich die Verbindung. Die Daten werden auf dem Client nur bei Fehlerfällen angezeigt aber im Rimscout-Portal für die IT für Auswertungen bereitgehalten. Weitere Informationen zu Rimscout finden Sie hier https://www.rimscout.com
Ganz so falsch kann die Messung also wohl nicht sein. Allerdings zeigt dies, dass auch eine VM in Azure nicht extrem schnell unterwegs ist. Es kann durchaus sein, dass meine VM in einem anderen Datacenter als die Transport-Relays lag.
Falsche DNS-Server
Sie haben oben an der Liste gesehen, dass es sehr viele Transport Relays für Teams Audio/Video/Desktop-Sharing gibt und dass die Anfrage an den DNS-Server über die Antwort entscheidet. DNS-Fehlkonfigurationen sind natürlich möglich und entsprechend habe ich den Versuch gestartet, absichtlich einen falschen Server als Gegenstelle zu nutzen. Hier bin ich in Deutschland und verbinde mich absichtlich mit einem Server in Asien. Ich wollte so testen, ob Microsoft vielleicht doch die IP-Adresse zu einem lokalen Transportrelay umleitet.
Die Zahlen sagen aber etwas anderes. Die durchschnittliche Roundtrip-Time ist hier konstant zwischen 197-215ms. Ich interpretiere diese Werte so, dass mein Client über eine kurze Stecke Internet und dann durch das MGN - Microsoft Global Network bis zum Server in Asien geht. Wenn die DNS-Konfiguration auf meinem Client also "falsch" ist dann kann genau so etwas passieren.
Test mit Teams
Um diese Fehlkonfiguration zu testen, habe ich meinem PC manuell den DNS-Server 117.18.119.42 (Hongkong Commercial Internet Exchange) eingetragen, welcher schon beim PING sehr weit weg ist
C:\>ping 117.18.119.42 Ping wird ausgeführt für 117.18.119.42 mit 32 Bytes Daten: Antwort von 117.18.119.42: Bytes=32 Zeit=254ms TTL=114 Antwort von 117.18.119.42: Bytes=32 Zeit=250ms TTL=114 Antwort von 117.18.119.42: Bytes=32 Zeit=255ms TTL=114 Antwort von 117.18.119.42: Bytes=32 Zeit=250ms TTL=114
Hinweis: Wenn ihr PC auch eine IPv6-Verbinung hat, dann fragt der Client den Namen auch per IPv6 ab und in dem Fall bekommt er dann wieder die lokale Einstellung. Man muss als schon temporär IPv6 unterbinden, wenn man mit IPv4 testen möchte.
Per Wireshark habe ich dann gesehen, welche IP-Adresse der Teams Client aktiv genutzt hat. Der Port 3479 ist der Port für Audio-Übertragungen. Der Mitschnitt war nur sehr kurz und "ruhig".
Leider hat Microsoft die Transportrelays nicht mehr per ICMP-Ping erreichbar gemacht, so dass eine schnelle Laufzeitmessung nicht mehr über den Weg möglich ist. Aber ein Traceroute zeigt zumindest den Weg in die Richtung und belegt, dass ich einen "ungünstigen" TURN-Server verwendet habe.
PS C:\> tracert 52.114.53.236 Routenverfolgung zu 52.114.53.236 über maximal 30 Hops 1 1 ms 1 ms 1 ms 192.168.178.1 2 8 ms 6 ms 6 ms 100.124.1.18 3 6 ms 5 ms 6 ms 100.127.1.132 4 9 ms 6 ms 6 ms 185.22.46.129 5 14 ms * 15 ms ams-ix-1.microsoft.com [80.249.209.20] 6 13 ms 14 ms 14 ms ae22-0.icr01.ams30.ntwk.msn.net [104.44.232.167] 7 196 ms 198 ms 197 ms be-120-0.ibr02.ams30.ntwk.msn.net [104.44.22.223] 8 199 ms 195 ms 197 ms be-9-0.ibr02.fra21.ntwk.msn.net [104.44.19.237] 9 196 ms 198 ms 198 ms be-6-0.ibr02.zrh20.ntwk.msn.net [104.44.18.86] 10 198 ms 197 ms 195 ms be-2-0.ibr02.gva20.ntwk.msn.net [104.44.17.255] 11 199 ms 197 ms 197 ms be-7-0.ibr02.mrs21.ntwk.msn.net [104.44.29.58] 12 205 ms 196 ms 198 ms 104.44.28.173 13 198 ms 198 ms 198 ms be-18-0.ibr02.sin30.ntwk.msn.net [104.44.28.208] 14 199 ms 197 ms 198 ms be-9-0.ibr02.sg2.ntwk.msn.net [104.44.28.38] 15 198 ms 198 ms 198 ms be-1-0.ibr02.sg3.ntwk.msn.net [104.44.7.18] 16 199 ms 198 ms 197 ms 104.44.29.95 17 199 ms 197 ms 198 ms be-1-0.ibr02.hkg31.ntwk.msn.net [104.44.7.3] 18 198 ms 197 ms 193 ms ae120-0.icr01.hkg31.ntwk.msn.net [104.44.11.140] 19 * * * Zeitüberschreitung der Anforderung. 20 * * * Zeitüberschreitung der Anforderung.
Auch mein Rimscout (https://www.rimscout.com) meldet beim TCP-Handshake den Namen der Gegenstelle und beschwert sich über die schlechte Latenzzeit:
Weitere Informationen zu Rimscout finden Sie hier https://www.rimscout.com
Und das liegt nur daran, dass ich hier absichtlich einen falschen DNS-Server gefragt habe. Aber können Sie ausschließen, dass ihr Client immer den richtigen DNS-Server fragt? Bei mehreren Netzwerk-Assessments in der Vergangenheit habe ich genau solche Unstimmigkeiten ermittelt, z.B. weil ein Client in Singapur mi lokalem Internetausgang per HTTP-Proxy zwar lokal "gesurt" hat aber für Teams-UDP über das Firmen-WAN die internen DNS-Server in Deutschland gefragt und damit die TURN-Server in EMEA bekommen hat.
Es kann natürlich sein, dass Microsoft irgendwann auch noch diese "Probleme" über Anycast-Routing" irgendwann in der Zukunft löst.
DNS eu.turn.teams.microsoft.com
Die gleiche Serie, die ich für "worldaz.tr.teams.microsoft.com" durchgeführt habe, habe ich auch für eu.turn.teams.microsoft.com gestartet. Hier die verkürzten Ergebnisse.
PS C:\> Resolve-DnsName eu.turn.teams.microsoft.com -type A Name Type TTL Section IPAddress ---- ---- --- ------- --------- eu.turn.teams.microsoft.com A 2036 Answer 13.107.65.150
Interessant ist hier, dass ich nur eine IP-Adresse erhalte und keine weitere Information zur Region oder Standort. Entsprechend liefert auch eine immer wieder wiederholte Anfrage immer nur eine IP-Adresse:
1..1000 | %{(Resolve-DnsName worldaz.tr.teams.microsoft.com -Type A)[-1].ipaddress} |group -NoElement Count Name ----- ---- 1000 13.107.65.150
Insofern macht es auch wenig Sinn die Server dahinter zählen zu wollen. Auf der Seite Teams RTP Kommunikation habe ich aber beschrieben, dass das Transport-Relay eine Umleitungs-Adresse im ersten UDP-Paket zu 3478 mit dem 401-Fehler liefert.
Die Hexadezimalwerte müssen Sie natürlich mal schnell decodieren:
0d 97 = 3479 34 72 fb d6 = 52 114 251 214
Meine Verbindung zu 52.114.249.58 wird mit einer Umleitung zu einer anderen Adresse beantwortet. Es bleibt aber nicht nur bei der einen Verbindung, wenn ich ein "Meet Now" mit mir selbst und "Audio only" mache.
Da passiert noch einiges mehr mit dem Teams-Client auf Electron-Basis. Teams im Browser mit WebRTC kann sich wieder anders verhalten und fragen Sie mich bitte nicht, warum in keinen der Tests eine Verbindung zu "eu.turn.teams.microsoft.com" aufgebaut wurde.
Das ist natürlich eine "Microsoft Lösung" und kann sich jederzeit ändern.
Zwischenstand
Mit meiner Testserie am 10. April 2021 habe ich bewiesen, dass der Teams Client, anders als Skype for Business, keine Relay-Server per "Inband-Provisioning" zugeteilt bekommt, sondern er diese einfach per DNS-Auflösung findet und Microsoft abhängig von der Client-IP einen "naheliegenden" TURN-Server liefert. Durch entsprechende DNS-Einstellungen bekommt mein Client mit jeder Anfrage auch immer wieder die neue Antwort.
Weitere Links
- Teams RTP Kommunikation
- Teams Turn over TCP
- Teams Local Media Optimization
- Direct Routing und Media Bypass
- Cloud Verbindung
- End2End-UDP3478
-
CNAME vs A-Record
Die richtige Art einen Alias auf echte Server zu verweisen - MGN - Microsoft Global Network
- Office 365 DNS Details
- Office 365: DNS-Routing
- Anycast-Routing
- PublicDNS Provider und Probleme
-
Where in the world will my Microsoft Teams
meeting be hosted?
https://tomtalks.blog/2019/06/where-in-the-world-will-my-microsoft-teams-meeting-by-hosted/
Understanding Media Flows in Microsoft Teams - BRK4016
https://youtube.com/watch?v=1tmHMIlAQdo
Media in Teams - Media Flow
https://youtube.com/watch?v=p8ml3jYt9KI