Skype for Business Online Network Assessment Tool

Microsoft erweitert die Länder mit Rufnummern, so dass immer mehr Kunden sogar ihre Telefonie über Skype for Business Online bereitstellen können. Das geht natürlich nur mit entsprechender Qualität der Verbindungsnetze. Wer auch immer VoIP betreibt, sollte entsprechende Tests und Überwachungen umsetzen.

Beachten Sie dazu auch die Seite PRTG und SfB Online Network Assesssment, Office 365 Network Assessment und RTP-Portcheck

Achtung: Im Nov 2017 hat Microsoft eine neue Version released, die wieder funktioniert, nachdem die "alte" die Funktion eingestellt hat obwohl beide das gleiche Backend nutzen.

Einsatzbereich

Das "Skype for Business Online Network Assessment Tool" ist kein Ersatz für ein vollwertiges Monitoring einer WAN-Leitung oder eines Durchsatzes. Aber es simuliert eine Audio-Verbindung von dem aufrufenden Client zu einem "nahestehenden" Edge-Server in der Cloud und ermittelt durch eine ca. 20 Sek langen Audio-Verbindung folgende Daten:

  • Packet loss
    Wie viele Pakete nicht im Ziel ankommen. En paar Verluste sind bei UDP unkritisch (z.B. weniger als 2%)
  • Jitter
    Wie lang die Laufzeit der Pakete schwankt. Je größer diese Zahl ist, desto schlechte ist die Leitung und desto größer wird der Jitter-Buffer beim Empfänger und damit die "gehörte" Latenz
  • Round-trip latency
    Wie lange die Pakete für den Hin- und Rückweg zusammen brauchen. Alles über 200ms ist schon Grenzwertig
  • Reorder packet percentage
    Wie viele Pakete falsch sortiert wieder zurück kommen. Das ist ein Indikator für unterschiedliche Wege und unterschiedlichen Laufzeiten und oft ein Hinweis auf Überlastete Teilstrecken.

Über die Konfiguration können auch mehrere Anrufe sequentiell gestartet werden. Der Einsatz des Programms ist auf einem Desktop aber auch auf dem Edge-Server im Unternehmen möglich. Das Ziel ist es ja die Qualität zum Office 365 Edge zu messen.

Zudem können Sie damit sehr schnell prüfen, welche TURN-Server wie erreichbar sind.

Download und Installation

Zuerst steht aber einmal der Download selbst an. Die unter 10 MB große Datei ist heute schnell herunter geladen.

Skype for Business Network Assessment Tool
https://www.microsoft.com/en-us/download/details.aspx?id=53885
http://aka.ms/SOF-MNA-Tool

Die erste Version war noch eine ZIP-Datei, die nur auszupacken war. Mittlerweile ist es ein Installier der keine Werte abfragt, sondern den Code direkt nach "C:\Program Files\Microsoft Skype for Business Network Assessment Tool" installiert. Interessant sind die drei markierten Dateien.

Es gibt aber keinen Eintrag im Startmenü was aber kein Problem ist, denn es gibt auch keine GUI. Das enthaltenen EXE-Programme ist für die Kommandozeile gedacht.

Hinweis:  (32bit!)
Für die Funktion muss die 32Bit!  Visual C-Runtime 2015 (14.0.23026) installiert sein. Früher mussten Sie das manuell machen, da sonst die Datei "Microsoft.Rtc.Internal.Media.dll" nicht geladen werden kann
Download VC 2015 Runtime: https://www.microsoft.com/en-us/download/details.aspx?id=48145.
Im MSI-Installer ist diese Datei mittlerweile enthalten.

Firewall

Rufen Sie das erste mal das NetworkAssessmentTool.exe "als Administrator" auf, da das Setup leider nicht die Allow-Regeln in der Firewall einträgt. Ohne Admin sehen Sie das folgende Fenster.

Als Admin können sie dann die Einrichtung hier nachholen:

 

Ich habe mir angewöhnt solche Programme über die Windows Firewall explizit freizugeben.

Name: SfB Network Assessment Tool
Aktion: Allow
Programm: %ProgramFiles%\Microsoft Skype for Business Network Assessment Tool\NetworkAssessmentTool.exe
Protokolle: ALLE
Bereich: beliebige Adressen
Profile: Domäne, Privat, Public

Natürlich könnte man die Regel noch "enger" fassen. Das obliegt ihren eigenen Richtlinien. Meine "Probe-Systeme" stehen sowieso hinter meiner Firewall, in der die Zugänge auch noch eingerichtet werden müssen.

Testcalls

Der erste einfache Aufruf macht genau einen Testcall:

Das Ergebnis dieses Calls landet auf der Konsole aber zugleich auch in einer CSV-Datei. Bei mir landet es eben im lokalen APPDATA-Verzeichnis %LOCALAPPDATA%\Microsoft Skype for Business Network Assessment Tool\performance_results.tsv.

Es nutzt dann die Konfiguration-Datei "NetworkAssessmentTool.exe.config", welcher in der Auslieferung folgenden Inhalt hat:

Es wird also genau ein Audio-Call auf die IP-Adresse 13.107.8.20 gemacht und die Ergebnisse werden auf den Bildschirm ausgegeben und in die Ausgabedatei geschrieben. Interessant für später sind hier die markierten Werte. Insbesondere die "NumIterations" sind interessant. Die Datei "Connectivity_results.txt" habe ich leider noch nicht gefunden.

Achtung
Bei jedem Aufruf wird die Ausgabedatei überschrieben.

Hinweis:
Bei der 13.107.8.20 handelt es sich um eine Anycast-IP, die immer zum nächsten Edge geroutet werden sollte. Microsoft betreibt mehrere Server mit der gleichen IP-Adresse und per BGP-Routen werden diese propagiert. Ihr Provider nutzt aber den "kürzesten" Weg und damit landet das Paket quasi auch ohne Geo-DNS beim netztechnisch nächsten Server. Siehe auch "Anycast" https://de.wikipedia.org/wiki/Anycast
Schaut man sich den TLS-Handshake an, dann kommt der Hostname "transport_relay.skype.net" drin vor, der aber nicht per DNS auflösbar ist.

Netzwerkkommunikation

Mit Wireshark (vormals Ethereal) und Co können Sie natürlich dem Programm etwas genauer auf die Finger schauen. Der Client versucht über drei Wege eine Verbindung zu erreichen.

  1. Direkt 3478/UDP
    DAs wäre die präferierte Lösung, die sie immer anstreben sollten.
  2. Direkt 443
    Wenn UDP geblockt ist, versucht der Client eine direkte TCP-Verbindung zu 443.
  3. HTTPS über Proxy
    Wenn Weg 1 und Weg 2 verbaut sind, dann kann er nur über HTTPS und Proxy-Server gehen. Das ist sicher die schlechteste Option.

Leider zeigt das Programm nicht mit an, welcher Weg letztlich zum Trage gekommen ist. Sie können dies aber durch Netmon(/Wireshark recht einfach sehen:

In dem Beispiel habe ich absichtlich alle Wege "verbaut". Sieh sehen also dass der STUN-Request keine Antwort bekommt aber auch der TCP-Connect auf 443 nach dem Timeout nach 3 Sekunden eine Retransmission versucht und der Proxy-Server ist zwar erreichbar, aber verweigert die Authentifizierung. In dem Fall kommt natürlich gar keine Verbindung zu stande.

performance_results.tsv

Das Ergebnis des Anrufs ist eine TSV-Datei, bei der die Felder durch einen "Tabulator" getrennt sind.

Achtung
Die TSV-Datei wird bei jedem Start überschrieben und nicht angehängt. Ich habe noch keine Option gefunden, einen Append zu konfigurieren.

Bei einer früheren Version war der Name "result.tsv" Hier ein Beispiel:

CallStartTime       PacketLossRate RoundTripLatencyInMs PacketsSent PacketsReceived AverageJitterInMs PacketReorderRatio
03.10.2016 15:39:37 0,008225617                     123         851             844          52,01257                  0

Für die Auswertung liefert Microsoft aber auch gleich noch mit dem Programm "ResultsAnalyzer.exe" ein Werkzeug mit, welche die Werte interpretiert.

C:\Temp\>ResultsAnalyzer.exe results.tsv
Skype for Business - Network Assessment Tool - Results Analyzer
Input file:           results.tsv
Total rows read:      1
Total rows skipped:   0
Total rows processed: 1

90th percentile values per metric:
Packet loss rate:     0,8225617%
RTT latency:          123
Jitter:               52,01257
Packet reorder ratio: 0%

If this is a Skype for Business Client machine connecting to the Microsoft network Edge:
Packet loss rate:     PASSED
RTT latency:          FAILED
Jitter:               FAILED
Packet reorder ratio: PASSED

If this is a network Edge connecting to the Microsoft network Edge:
Packet loss rate:     FAILED
RTT latency:          FAILED
Jitter:               FAILED
Packet reorder ratio: PASSED

Leider überschreibt jeder Aufruf von "NetworkAssessmentTool.exe" die vorherige TSV-Datei anstatt eine neue Messung einfach dran zu hängen. Insofern ist eine regelmäßige Messung nur mit Zusatzskripten möglich.

Sie können aber über die XML-Datei zwar das Verhalten bezüglich des Überschreibens nicht ändern aber wir können das Programm anweisen, mehrere Testanrufe durchzuführen. In der TSV-Datei landen dann doch mehrere Einträge, die weiter ausgewertet werden können.

Pass oder Fail

Die Entscheidung, ob die Messung letztlich ein "PASSED" oder "FAILED" bekommt hat Microsoft hier dokumentiert:

In aller Kürze legt der ResultsAnalyzer.exe folgende Grenzwerte an:

Wert Client zu Edge Edge zu Edge
Packet loss rate

<10% in einem 200ms Intervall
<1% innerhalb eines 15s Intervall

<1% in einem 200ms Intervall
RTT Latency

<100ms

<60ms
Jitter

<30ms innerhalb 15s Intervall

<15ms innerhalb 15s Intervall
Packet reorder

<0,05%

<0,01%

Die Grenzen beim "Client" sind etwas entspannter, da für ein Heimnetzwerk mit WiFi etc. Kompromisse eingegangen werden müssen. ein Edge-Server einer Firma sollte über einen "Business-Anschluss" eine andere Qualität erreichen können. Schließlich kosten 100MBit hier deutlich mehr als ein "100MBit Kabelanschluss".

Hintergründe

Das das Programm im Hintergrund anstellt ist eigentlich keine besondere Aktion. Wer sich mit VoIP und Wireshark etwas auskennt, kann die Daten reicht einfach erkennen, dass hier erst ein STUN-Request an den Server geht, der durch einen TLS-Handshake begleitet wird.

Später sind dann genau die Daten zu sehen, dass der Client Pakete über 3478/UDP  zum Server sendet und wieder bekommt.

Insgesamt sind es für einen 17 Sek Anruf ca.1800 Pakete mit 95kbit/Sek, also ca. 155Kbyte/Min je Richtung. Sie können also eine Datenrate von 60 Megabyte/Stunde je Richtung erwarten. Das erscheint erst mal nicht viel aber addiert sich über einen Monat natürlich auf 43 Gigabyte!

Grafische Auswertung mit PowerBI

Die Daten der CSV-Datei können natürlich auch mit Excel, PowerBI o.a. grafisch ausgewertet werden. Es ist ja eine einfache Tabelle mit einem Datum als erste Spalte und den verschiedenen Ergebnissen. Das Programm Power BI ist hier sehr leistungsstark, denn es kann die TSV-Dateien direkt einlesen

Mit wenigen Mausklicks können Sie Grafiken wie die folgende Auswertung erstellen. Einige Hürde kann das Datum sein, welches abhängig den dein Landeseinstellungen auf dem Computer geschrieben wird und daher bei wechselnden Ländern ggfls. konvertiert werden muss.

  • Einfache Anzeige der Werte über die Zeitachse
    Dies ist das einfachste Diagramm, bei der die Zeit auf die X-Achse und die Werte auf die Y-Achse gelegt werden. Die Messung hier war "nur" 24h lang. Sie sollten für ein aussagekräftiges Audit mindestens eine Woche einplanen.

    Hier muss aber am 19. Okt gegen Mitternacht ein Aussetzer passiert sein. Das könnte eine DSL-Zwangstrennung gewesen sein. Es scheint aber auch so zu sein, dass tagsüber aufgrund von Fremdverkehr die Roundtrip-Zeit etwas ansteigt und bis auf wenige Ausreißer doch unter 50ms bleibt.
  • Verteilung der Latenzzeit
    die X-Achse zeigt die Latenzzeit in Millisekunden und die Y-Achse die Anzahl der Vorkommen. Beachten Sie die logarithmische Skalierung. Die meisten Pakete waren also im Bereich 20-50ms unterwegs.

James Cussen (MVP, Australien) hat ein Programm entwickelt, welches die Kommandozeile in einer grafischen Oberfläche verpackt.

Stabilität und Fehlermeldungen

Ich nutze das Tool um über einen PRTG-Sensor eine Dauerüberwachung zu erreichen. Den Code dazu habe ich auf PRTG und SfB Online Network Assesssment ebenfalls veröffentlicht. Allerdings muss man das Skript schon etwas überwachen, denn manchmal bricht die EXE mit der ein oder anderen Fehlermeldung ab und wartet dann auf eine Bestätigung durch den Anwender (Windows Dialog). Eine komplett unbewachter Betrieb geht so natürlich nicht. Eine gute Monitoring-Lösung erkennt natürlich das "Ausbleiben" von Daten und meldet dies. Folgende Fehler habe ich bislang gesehen:

Fehler Beschreibung und Hinweise

Error: Failed to parse call network data (QoE).
Message: Invalid value for Pakets Sent Count reported851

Vermutlich verhindert eine lokale 3rd Party Firewall, Virenscanner o.ä. den Zugriff auf die  Netzwerkstatistiken.

ERROR: Failed to establish connection with remote endpoint.
ERROR: Check that the relay is configured correctly in your config file.

In der Konfig-Datei ist die IP-Adresse 13.107.8.2 als Testgegenstelle hinterlegt. Vermutlich blockiert eine Netzwerkfirewall den Zugriff auf diesen Server. Sie können mit Wireshark u.a. sehr einfach kontrollieren, welche Pakete gesendet und ob "ICMP not reachable" empfangen werden.

Unable https://use.config.skype.com/config/v1/Skype/3611_1.0.0.1

 

Weitere Meldungen werde ich noch nachtragen. Interessant war aber schon z.B. die URL einer Fehlermeldung.

https://use.config.skype.com/config/v1/Skype/3611_1.0.0.1
{"ports":{
	"relayPortUdp":3478,
	"relayPortTcp":443,
	"relayPortUdpAudio":3479,
	"relayPortUdpVideo":3480,
	"relayPortUdpVbss":3481}

Unter der Adresse kommt eine JSON-Datei zurück, die sehr viele weitere Daten liefert, z:B. könnte man daraus auf die Funktion der neuen UDP-Port 3479, 3480 und 3481 schließen. Wenn diese von Skype und Teams genutzt werden, dann ergeben sich ganz neue Funktionen zum Erfassen und Priorisieren von von Bandbreiten.

Einschätzung

Das Skype for Business Online Network Assessment Tool ist endlich mal ein Kommandozeilenwerkzeug zum Testen der VoIP-Tauglichkeit einer Verbindung zu Office 365. Es ist damit ein Grundwerkzeug um mal eben schnell eine Verbindung auch über einige Stunden hinweg zu messen, z.B. mit vielen Anrufen und entsprechenden Pausen dazwischen. Es ist natürlich kein Ersatz für eine vollwertige Analyseumgebung und eignete sich auch nicht zum rein internen messen. Die "Gegenstelle" ist nämlich ein Edge-Server in Office 365 und kein beliebiger interner Computer. Insofern bleibt für interne Messungen noch genug Raum für Drittprodukte. Auch hinsichtlich Office 365 ist dies sicher nur ein Anfang aber das Skript kann durchaus z.B. in eigene Monitoring-Lösungen eingebunden werden .z.B. indem per Taskplaner das Programm gestartet wird und am Ende die Ausgaben eingelesen und an ein Monitoring übergeben werden.

Weitere Links