End2End-UDP3478
Für eine effektive Übertragung von Audio/Video eignet sich am besten eine direkte Verbindung per UDP. Da dies oft nicht geht, ist eine indirekte Verbindung per STUN/TURN erforderlich. Der dazu genutzte Port ist eigentlich immer 3478/UDP. Es ist daher wichtig einen Test zu haben, ob dieser Port erreichbar ist und wie weit er "weg" ist. Daher habe ich mir End2end-UDP3478 geschrieben.
Hinweis: Dieser Test ist auch in meiner kommerzielle Lösung Rimscout enthalten. Weitere Informationen finden Sie dazu auf https://www.rimscout.com
https://www.youtube.com/watch?v=fR9b1ZO3xio
Beachten Sie zu den technischen Hintergründen die folgenden Seiten:
Funktionsweise
Zuerst habe ich einer funktionierenden Verbindung auf die Finger geschaut. Mit dem Skype for Business Online Network Assessment Tool habe ich einen Test-Call ausgeführt und die ersten Pakete betrachtet. Sie sehen direkt einen "STUN Allocate Request" der aber ohne Anmeldedaten natürlich daneben geht. Aber mir reicht das um das anfragende Paket zu erhalten.
Diese Daten habe ich nun direkt als Byte-Array in meinem PowerShell-Script genutzt, um das gleiche Paket abzusenden.
$byteBuffer = @(0x00,0x03,0x00,0x54,0x21,0x12,0xa4,0x42,0xd2,0x79,0xaa,0x56,0x87,0x86,0x48, 0x73,0x8f,0x92,0xef,0x58,0x00,0x0f,0x00,0x04,0x72,0xc6,0x4b,0xc6,0x80,0x08, 0x00,0x04,0x00,0x00,0x00,0x04,0x00,0x06,0x00,0x30,0x04,0x00,0x00,0x1c,0x00, 0x09,0xbe,0x58,0x24,0xe4,0xc5,0x1c,0x33,0x4c,0xd2,0x3f,0x50,0xf1,0x5d,0xce, 0x81,0xff,0xa9,0xbe,0x00,0x00,0x00,0x01,0xeb,0x15,0x53,0xbd,0x75,0xe2,0xca, 0x14,0x1e,0x36,0x31,0xbb,0xe3,0xf5,0x4a,0xa1,0x32,0x45,0xcb,0xf9,0x00,0x10, 0x00,0x04,0x00,0x00,0x01,0x5e,0x80,0x06,0x00,0x04,0x00,0x00,0x00,0x01)
Das Paket sende ich dann per UDP-Client (Siehe auch PowerShell und UDP) an die Adresse und warte auf die Antwort. Der Verhalten bei Microsoft Teams ist sehr ähnlich, was den ersten Kontakt angehen: Wobei hier mehrere Ziel-IP-Adressen angesprochen werden.
Schaut man aber genau hin, dann gibt es auch hier Verbindungen, die wie bei Skype for Business einen "Allocate Bandwidth" machen. In meinem Beispiel ist es hier die 52.113.193.5 und eine Verbindung zu diesem Server funktioniert genau wie auch bei Skype for Business.
Empfehlung Microsoft
Microsoft hat sogar explizit erwähnt, dass ein Test per "PING" nicht hinreichend ist und die Transportrelays von Microsoft ab Januar 2020 nicht mehr auf ICMP-Anfragen antworten. Stattdessen sollte man per UDP testen.
Es geht aber noch weiter:
- Internes Netzwerk und Office 365
Auch das interne LAN sollte ausgemessen werden - Längere Zeit messen
Laut Microsoft sollte es mindestens eine Woche kontinuierlich Messung sein - Regelmäßig alle 10 Min und 90% Percentil
Damit meint Microsoft wohl eine Stichprobe mit ihrem eigenen SfB Network Assessment Tool. - Auch zukünftig immer weiter messen
Erreichbarkeitstest
Um zu prüfen, ob die Gegenstelle erreichbar ist, sende ich dann einfach das Paket los. Auf meine Anfrage bekomme ich dann auch eine Antwort zurück, die ich mit dem gleichen UDP-Client annehmen kann. Die empfangenen Daten kann ich prüfen, ob es ein "STUN Allocate Error" ist und damit die erfolgreiche Verbindung über Port 3478 bestätigen. Selbst ohne eine genaue Prüfung ist schon allein der Empfang einer UDP-Antwort ein ausreichend guter Indikator, so dass folgender Code schon alle Merkmale mitbringt:
# Simple Skype for Business Online Edge Turn test [int]$sourceudpport=50000 [int]$remoteudpport=3478 [string]$remoteip = "13.107.8.2" $udpClient = new-Object System.Net.Sockets.Udpclient($sourceudpport) $udpClient.Client.ReceiveTimeout = 1000 #$udpClient.Client.Blocking = $true # Session Traversal Utilities for NAT # STSUN Packet from SfB Network Assessment Tool $byteBuffer = @(0x00,0x03,0x00,0x54,0x21,0x12,0xa4,0x42,0xd2,0x79,0xaa,0x56,0x87,0x86,0x48, 0x73,0x8f,0x92,0xef,0x58,0x00,0x0f,0x00,0x04,0x72,0xc6,0x4b,0xc6,0x80,0x08, 0x00,0x04,0x00,0x00,0x00,0x04,0x00,0x06,0x00,0x30,0x04,0x00,0x00,0x1c,0x00, 0x09,0xbe,0x58,0x24,0xe4,0xc5,0x1c,0x33,0x4c,0xd2,0x3f,0x50,0xf1,0x5d,0xce, 0x81,0xff,0xa9,0xbe,0x00,0x00,0x00,0x01,0xeb,0x15,0x53,0xbd,0x75,0xe2,0xca, 0x14,0x1e,0x36,0x31,0xbb,0xe3,0xf5,0x4a,0xa1,0x32,0x45,0xcb,0xf9,0x00,0x10, 0x00,0x04,0x00,0x00,0x01,0x5e,0x80,0x06,0x00,0x04,0x00,0x00,0x00,0x01) $RemoteIpEndPoint = New-Object System.Net.IPEndPoint([system.net.IPAddress]::Parse("0.0.0.0"),0); $sentbytes = $udpClient.Send($byteBuffer, $byteBuffer.length, $remoteip, $remoteudpport) try { $receive=$udpClient.Receive([ref]$remoteIpEndpoint) write-host "TTL $($_) Answer received" $result=[System.BitConverter]::ToString($receive); } catch { write-host "TTL $($_) NO Answer received" } $udpClient.close()
So einfach ist schon mal die generelle Durchgängigkeit von einem Client zu einem Office 365 STUN-Server zu prüfen. Sie können natürlich daraus auch eine Überwachung machen. Allerdings ist ein STUN-Request noch kein RTP-Paket. Um für VoIP aussagekräftige Daten zu bekommen, sollten Sie schon RTP übertragen und dafür eignet sich das Skype for Business Online Network Assessment Tool viel besser.
Auswerten der Rückantwort
Ob ich nun wirklich einen STUN/TURN-Server erreicht habe, kann ich nur durch einen Vergleich der Antwort mit einem Sollwert überprüfen. Auch hier hilft mir Wireshark mit, welcher die Antwort nicht nur anzeigt, sondern auch parst. Da es sein kann, dass die Antwort sich verändert, wollte ich nun nicht den kompletten Rückgabewert vergleichen sondern nur einen Teil davon.
Ich beschränke mich auf den Wert "01 13", der für einen "Allocate Error Response" steht und am Ende das "rtcmedia" steht. Das geht ganz einfach mit:
if ($result.startswith("01-13") -and $result.endswith("72-74-63-6D-65-64-69-61-22")){ write-host "Edge reachable" } else { write-host "unexpected answer" }
Microsoft scheint mittlerweile verschiedene Media-Relays zu betreiben, denn auf eu.turn.teams.microsoft.com reagiert der Service mit einem "Unauthorized"
Hier ist aber kein Hinweis auf einen anderen Relay-Service enthalten. Daher habe ich den Code mittlerweile für beide Antworten wie folgt angepasst:
Rimscout
Der Test ist auch in Rimscout enthalten. Rimscout ist ein kommerzielles Produkt, in welche viele dieser End2End-Test eingeflossen sind und bei dem ein Client die Test zentral gesteuert ausführt, an ein Backend berichtet und auswertbar macht. Hier sehen Sie z.B. einen Client in einem Standort, in dem UDP geblockt ist:
Die Test zum Turn-Server über TCP funktionieren hingegen. Bei so einer Situation werden die Anwender keine Probleme bemerken, bis die Leitung schlechter wird und der TCP-Stack versucht die Paketverluste zu reparieren und Audio/Video-Daten nachfordert, die eh nicht mehr wiedergegeben werden.
Sie können in Rimscout auch auf jede einzelne Messung zurückgreifen und so sehen wir hier sehr gut den MO502273 Cloud Ausfall am 25. Jan 2023, bei dem einige Stunden gar nicht mehr ging.
Sie können sehen, dass es kurze Moment gab, zu der die Verbindung wieder möglich war. Viel interessanter ist aber die sichtbare Verschlechterung der Latenzzeit schon viele Minuten vor dem eigentlichen Totalausfall. Microsoft fordert ja 100ms und schon gegen 08:15 meldet Rimscout hier die ersten Fehler und Warnungen, weil die geforderte Latenzeit überschritten wird. Solche Auswertungen sind mit einem einfachen PowerShell-Skript natürlich nicht möglich.
Weitere Informationen zu Rimscout finden Sie dazu auf https://www.rimscout.com
PRTG Modul
Ich habe das Skript dann gleich noch etwas erweitert, dass es als Custom Sensor unter PRTG eingesetzt werden kann. Es erweitert die Rückgabe dann einfach um eine XML-Struktur, die von PRTG ausgewertet wird. Der Einsatz unter PRTG ist als PRTG - Custom Sensor einzurichten. Nach einigen Stunden sollten Sie dann eine Grafik sehen:
Das ist mein T-DSL Anschluss zuhause, der interessanterweise nicht nur eine längere Latenzzeit in den Abendstunden aufweist (Netflix?) sondern dann auch die Anzahl der Hops anfängt zu schwanken. Da wäre es schon mal interessant, welche Stationen da genau durchlaufen werden. Auch sieht man gut, dass die Roundtriptime (RTT) in der Zeit auch zunimmt. Ich bin mal gespannt, wie die Werte bei Firmenanschlüssen aussehen.
Um aber mehr Details über die Leitwege zu bekommen, müsste ich einen Traceroute mit ICMP-Verarbeitung aufsetzen, was mit dem PowerShell UDP-Manager meines Wissens nicht so einfach möglich ist.
- Traceroute ICMP - So funktioniert Traceroute intern
- Traceroute TURN - Traceroute mit UDP gegen TURN Server
Aber auch so ist der Monitor sehr hilfreich um z.B. schnell zu erkennen, wenn eine Regeländerung der Firewall Port 3478 plötzlich sperrt oder Störungen im WAN zu größeren Umwegen führen. Insofern sollten Sie nach der Einrichtung des Sensors auch entsprechende Warn- und Fehlergrenzwerte samt Benachrichtigung in PRTG konfigurieren. Bei einer Firmen-Installation hatte ich dann folgende Bild:
Die Entfernung ist eigentlich immer 12 Hops aber es gibt auch hier die ein oder andere Veränderungen im Routing. Seit dem 26.12.2018 scheint der HopCount sich auf höherem Niveau stabilisiert zu haben. Die Roundtrip-Time ist dadurch zumindest noch nicht sichtbar schlechter geworden. Auch hier ist eine Betrachtung über mehrere Monate natürlich interessant. Der Sensor lief aber erst einige Wochen.
Die End2End-UDP3478 Funktion ist aber nicht auf Office 365 beschränkt. Sie können damit jeden TURN-Server, also auch den eigenen Edge-Server testen. Das funktioniert auch von einer Niederlassung über das eigene WAN zum Edge-Server in der Hub-Site. Hier sollten Sie dann natürlich deutlich schnellere Werte erhalten:
Ergänzend zu dem Sensor können Sie natürlich auch mit anderen Sensoren weiter Daten ermitteln:
Download/Tool
Das folgende PowerShell-Script können Sie einfach interaktiv starten oder als Custom-Sensor in PRTG einbinden. Über den Parameter "Remote-IP" könne sie ihren eigenen Edge-Server einbinden. Wenn Sie "o365", "skype" oder "teams" eingeben, nutzt das Skript hinterlegte Turn-Server, die aber zukünftig ggfls. falsch sein können. Wenn Sie eine PRTG-URL als Parameter oder Umgebungsvariable gesetzt haben, dann sendet Das Skript per HTTPPush die Daten am Ende jedes Durchlaufs an einen PRTG - HTTP Push-Sensor . Das macht natürlich nur Sinn, wenn Sie mit "averageintervalsec" einen ausreichend langen Zeitraum, z.B. 60 Sek) angeben.
end2end-udp3478.ps1
Hinweis: Die CSV-Dateien sind nicht kompatibel. Benennen Sie
eine bestehende ältere CSV-Datei um und starten sie mit eine
neuen Datei
Je nach System müssen Sie den verwendeten Sourceport (Default:UDP 50019) noch in der Firewall freigeben
Beim einfachen Aufruf sehen Sie die Aktionen und Ergebnisse direkt auf dem Bildschirm. Hier die Betriebsart "End2End", bei der quasi kontinuierlich Pakete mit ca. 20ms Abstand sende. (Also immer 20ms nachdem die Antwort angekommen ist.
Wenn ich die Betriebsart "TTLCheck" nutze, dann werden nur wenige Latenztest gemacht um dann aber mit dem absteigenden TTL die Entfernung zu ermitteln:
Hier wir per Default nur eine Sekunde mit maximaler Wiederholrate gemessen und dann die Distanz ermittelt. Ich habe mittlerweile die Detailausgaben alle mit "Write-Verbose" versteckt und mittels Farbe die Antworten sichtbar gemacht. Die Daten landen natürlich auch in der CSV-Datei für spätere Auswertungen und können auch z.B. an PRTG gesendet werden.
Parameter
Wenn Sie in den Sourcecode schauen, dann finden Sie einige Parameter am Anfang. Sie müssen diese nicht nutzen. Per Default macht das Skript einen end2end-Test gegen die Skype for Business Online Server. Sie können aber das Verhalten auch ihren Anforderungen anpassen. Die Bedeutung ist:
Parameter | Werte | Default | Beschreibung |
---|---|---|---|
mode |
end2end |
end2end |
Damit bestimmten Sie, ob das Skript einen End2End-Dauertest macht oder zwischendrin einen TTL-Entfernungstest addiert, aber in der Zeit keine Roundtrip-Tests machen kann. |
remoteip |
O365, Teams |
O365 |
Per Default wird der Skype for Business Online Edge-Server genutzt. Sie können aber auch Teams oder sogar ihren eigenen Skype for Business Edge-Server verwenden. Dann geben Sie bitte die IP-Adresse oder den DNS-Namen ein |
sourceudpport |
0..65535 |
50019 |
Mit diesem Port geht das Skript raus. Es bietet sich an, einen Port der Skype for Business Audio-Ports zu nutzen, um den gleichen Firewall-Regeln und QoS-Einstufungen unterworfen zu werden. |
remoteudpport |
0..65535 |
3478 |
Der UDP-Port auf der anderen Seite, auf der TURN-Server reagiert. Das ist eigentlich immer 3478 |
maxttl |
0-.128 |
20 bei TTLCheck |
Mit diesem TTL werden die Pakete auf die Reise geschickt. Jeder Router erniedrigt den Counter und bei 0 wird das Paket verworfen. |
maxretries |
0..65535 |
5 bei TTLCheck |
Wenn ein Paket nicht innerhalb der bei $ReceiveTimeout angegeben Millisekunden beantwortet wurde, dann wird es so oft wiederholt |
avgintervalsec |
0..65535 |
1 bei TTLCheck |
Beim TTLCheck wird eine Sekunde lang die Roundtrip-Zeit gemessen und dann der TTL-Check absteigend von $maxttl ausgeführt. Beim End2End-Check sammle ich die Daten 60 Sekunden ein |
interpacketsleepms |
0..65535 |
0 bei TTLCheck |
Beim TTLCheck lege ich keine Pause nach der Verarbeitung ein. Beim End2End-Check warte ich 20ms nach der Verarbeitung ab. Der Abstand zwischen Paketen wird also etwas länger sein. |
sleeptime |
0..65535 |
0 bei TTLCheck |
Nach Durchlaufen einer Runde kann ich eine Pause einlegen. Bei beiden Betriebsarten ist dies per Default nicht der Fall |
ReceiveTimeout |
500 |
0..65535 |
Zeit in Millisekunden, die der UDP-Listener nach dem Versand eines Pakets wartet. Nach 500ms bricht der Empfang ab und ich fange den Fehler ab. Das Paket zählt nach der Zeit als "verloren". Es wird je nach Einstellung von $maxretries erneut gesendet. |
SendToPipeline |
$false |
$true/$False |
Wenn Sie die Ergebnisse mit einem anderen Programm weiter verarbeiten wollen, dann können Sie mit dem Schalter die Ausgabe des Result-Objects in die Pipeline anfordern. Per Default ist dies abgeschaltet, um die Bildschirmausgabe nicht zu stören. |
resultcsv |
Dateipfad |
Dateipfad |
In diese CSV-Datei werden die Ergebnisse geschrieben. So können Sie das Skript auch lange laufen lassen und später die Daten auswerten oder mit anderen Endpunkten vergleichen. |
prtgpushurl |
$null |
URI |
Am Ende jedes Laufs schreibt end2end-udp3478 nicht nur die CSV-Datei, sondern kann die Daten acuh an eine PRTG-Instanz übermitteln. Richten Sie dazu einen PRTG - HTTP Push-Sensor ein und geben Sie hier die URI an, z.B. "http://<prtgserver>:<pushport>/<sensorcode> |
Details
End2End-UDP3478 sammelt ja die Daten über eine Minute und liefert diese an die Monitoring-Plattform. Mit den Rohdaten kann man natürlich weitere Auswertungen fahren. Ich habe hier die RTT auf die X-Achse gelegt und auf der Y-Achse die Anzahl der "Treffer". Es hat den Eindruck, dass ich von meinem Standort entweder unterschiedliche Laufzeiten habe oder unterschiedliche Datacenter nutze. Es gibt eine Häufung um 19ms aber auch um 37ms.
Genaugenommen sehen Sie aber sogar fünf Datacenter, die ich hier gekennzeichnet habe. Dies ist immer nur eine "Momentaufnahme" und hängt von ihrem Provider, dem Routing/Peering und der Auslastung ab. Die Auflösung auf "worldaz.tr.teams.microsoft.com" liefert immer wieder unterschiedliche Endpunkte.
PS C:\> 1..100 | %{Resolve-DnsName worldaz.tr.teams.microsoft.com | where {$_.querytype -eq "A"}} | group name -NoElement | ft -AutoSize Count Name ----- ---- 1 a-tr-teams-frcn-03.francecentral.cloudapp.azure.com 1 a-tr-teams-frcn-04.francecentral.cloudapp.azure.com 1 a-tr-teams-frcn-06.francecentral.cloudapp.azure.com 2 a-tr-teams-ukso-01.uksouth.cloudapp.azure.com 2 a-tr-teams-ukso-04.uksouth.cloudapp.azure.com 1 a-tr-teams-ukso-06.uksouth.cloudapp.azure.com 1 a-tr-teams-ukso-07.uksouth.cloudapp.azure.com 1 a-tr-teams-ukso-08.uksouth.cloudapp.azure.com 1 a-tr-teams-ukwe-01.ukwest.cloudapp.azure.com 2 a-tr-teams-ukwe-02.ukwest.cloudapp.azure.com 2 a-tr-teams-ukwe-04.ukwest.cloudapp.azure.com 1 a-tr-teasc-euno-01.northeurope.cloudapp.azure.com 2 a-tr-teasc-euno-02.northeurope.cloudapp.azure.com 2 a-tr-teasc-euno-05.northeurope.cloudapp.azure.com 1 a-tr-teasc-euno-08.northeurope.cloudapp.azure.com 1 a-tr-teasc-euno-15.northeurope.cloudapp.azure.com 1 a-tr-teasc-euwe-01.westeurope.cloudapp.azure.com 1 a-tr-teasc-euwe-02.westeurope.cloudapp.azure.com 1 a-tr-teasc-euwe-05.westeurope.cloudapp.azure.com 2 a-tr-teasc-euwe-06.westeurope.cloudapp.azure.com 1 a-tr-teasc-euwe-07.westeurope.cloudapp.azure.com ....
Insofern ist eine gewisse Häufung durchaus möglich und wenn Sie hier die vier Regionen sehen, dann finden sie in der Grafik auch vier lokale "Peaks" bei 18ms, 20ms, 37ms und 45ms.
Weitere Links
- Teams Transport Relay
- Teams Turn over TCP
- Teams RTP Kommunikation
- End2End-NTP
-
Netzwerk SLA
Messen Sie keine Bandbreiten sondern besser die Latenzzeit -
End2End Bandbreite und Performance
Richtig Messen am Beispiel von Bandbreite und Latenz - Ende zu Ende Monitoring
- Traceroute ICMP - So funktioniert Traceroute intern
- Traceroute TURN - Traceroute mit UDP gegen TURN Server
- PowerShell und UDP
- Skype for Business Online Network Assessment Tool
- End2End für Skype for Business Network Assessment
- PRTG - HTTP Push-Sensoren
- Test-EdgeConnectivity.ps1
https://greiginsydney.com/test-edgeconnectivity-ps1/
PowerShell-Script zum Test der Edge-Ports - Windows 2000 TCP/IP - TCP/IP
Troubleshooting - Overview of TCP/IP -
Troubleshooting Tools - Tracert
https://technet.microsoft.com/en-us/library/cc940128.aspx
beschreibt schön, dass Windows nur ICMP zum Ermitteln der Route nutzt statt UDP - PsPing v2.1
https://docs.microsoft.com/en-us/sysinternals/downloads/psping
Kann auch TCP oder UDP-Pakete senden aber braucht eine kompatible Gegenstelle - Media Quality and Network Connectivity Performance in Skype for Business
Online
https://docs.microsoft.com/en-us/skypeforbusiness/optimizing-your-network/media-quality-and-network-connectivity-performance - Stop Blaming Teams and Skype for your network – Your traffic graphs are
LYING!
https://www.ucmadscientist.com/stop-blaming-teams-and-skype-for-your-network-your-traffic-graphs-are-lying/ - Improving Real-Time Application Performance
https://www.plixer.com/blog/network-monitoring/improving-real-time-application-performance/ - Einfacher Test mit WebRTC
https://test.webrtc.org/ (Offline?) - Netzwerk-, Audio- und Videoprobleme in Meet beheben
https://support.google.com/a/answer/7582554?hl=de&ref_topic=7302695#zippy=%2Clatenz-messen
Google vertraut auf PING End2End-Ping - Netzwerk auf Meet-Videoanrufe vorbereiten
https://support.google.com/a/answer/1279090
Google nutzt UDP 19302–19309 für RTP - Von Steam benötigte Ports
https://support.steampowered.com/kb_article.php?ref=8571-GLVN-8711&l=german - Steam: Netzwerk-/Verbindungsprobleme beheben
https://support.steampowered.com/kb_article.php?ref=1456-EUDN-2493&l=german