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.

Der Verbindungstest auf "connectivity.office.com" macht selbst einen Traceroute zu dem statischen Namen: "worldaz.tr.teams.microsoft.com"

Der Name ist mir schon mehrfach untergekommen und für die weitere Betrachtung gehen wir davon aus, dass der Teams Client für eine RDP-Verbindung über UDP, TCP oder HTTP diesen Namen nutzt.

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 OnPremises 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 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
Cicero Dantas

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.

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.

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 den Test gemacht und auch hier sind die Werte am Anfang der Messung noch identisch bei 33-35ms als Mittelwert.

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 meldet beim TCP-Handshake den Namen der Gegenstelle und beschwert sich über die schlechte Latenzzeit:

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.

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