PreCallDiagnostics 2013

Mit Lync 2013 gibt es eine neue Version des PreCallDiagnostics-Tools, mit dem ein Anwender quasi vor dem Anruf testen kann, wie gut die Verbindung sein wird. Natürlich wird nun kein Anwender dieses Programm nutzen. Es ist daher für den 1st/2nd-Level Support interessant. Die Software läuft auf Windows 7 und 8/8.1. Zudem gibt es eine App im Windows AppStore.

Download und Installation

Die Funktion ist leider nicht im Lync Client enthalten. Sie müssen dies also manuell herunterladen und installieren. Ein Anwender kann in der Regel keine Software installieren

Download Win7/8 http://www.microsoft.com/en-us/download/details.aspx?id=40733
Download App http://apps.microsoft.com/windows/en-us/app/9607fe33-2b51-403d-9615-c23f248e7c88

Standardmäßig wird das Programm nach "C:\Program Files (x86)\Microsoft\Lync 2013 PreCall Diagnostics 1.1" installiert. Viele Bytes sind es aber nicht.

Nach der Installation kann das Program gestartet werden. Allerdings verhindert die Windows Firewall in den meisten Fällen die Funktion, da das Setup leider nicht entsprechende Ausnahmen einträgt. Beim ersten Start fragt Windows daher nach, ob diese Software eingehende Verbindungen annehmen darf.

Start und Anzeige

Danach können Sie das Programm einfach starten und müssen eigentlich nur eine SIP-Adresse eingeben. Per Default läuft der Test 2 Minuten und beendet sich dann auch wieder alleine:

Das Tools verbindet sich mit ihrer Lync Umgebung und sendet und empfängt RTP-Daten und misst die PaketLoss, Jitter und den MOS.

In dem Beispiel war die Verbindung eigentlich sehr gut. Der MOS-Wert war immer bei 4 und die Varianz des Jitter war mit weniger als 3ms minimal. Hier dann noch mal ein Hotel WLAN

Zumindest am Anfang war die Qualität deutlich schlechter aber selbst dann hat der MOS nicht mehr die 4 erreicht und daran ist sicher auch die Jitterzeiten mit Schuld. Leider geht aus den Zahlen aber nicht hervor, wie lange die Pakete unterwegs waren. Eine Latenzzeit war nicht zu sehen. Die Messing erfolgt aus einem Gäste-LAN bei Microsoft in Redmond gegen den Server in Deutschland.

Im Hintergrund

Natürlich will ich wissen, was das Tool im Hintergrund macht. Per Wireshark lässt sich sehen, dass hier wirklich RTP-Pakete samt Rückkabel gesendet werden

Das Programm unterstützt Edge mit STUN/TURN, sonst hätte hier der Zugriff von extern nicht funktioniert. Aber das ist ja auch sinnvoll, den damit ist die Messung z.B. im Homeoffice gerade erst möglich.

Interessant ist nun natürlich zu wissen, welche "Gegenstelle" das Tool dabei verwendet. Zuerst habe ich über die SDN-Implementierung einen Call zu finden. Das war aber negativ und auch ein SIP-Trace mit Snooper hat nichts gezeigt. Der Blick in die Anleitung  auf https://technet.microsoft.com/en-us/library/dn451255.aspx&  beschreibt, dass UCWA verfügbar sein muss, was aber wohl nur für die Store App gültig ist, denn die Windows Version hat nur Lyncdiscover benutzt.

Da im Wireshark eine Verbindung zum Edge Server zu sehen ist, habe ich dort mit Netmon in einer ruhigen Minute geschaut und gesehen, das beim Zugriff von Extern die RTP-Daten nur bis zum Edge Server gehen aber von dort nicht mehr weiter nach intern z.B. zum Lync Frontend gesendet werden. Also muss der Edge als "Endpunkt" dienen. Ein Snooper-Trace auf dem Edge hat auch keine SIP-INVITE o.ä. gegen den Frontend gezeigt. Es wird also gar kein "Lync Anruf" richtig aufgebaut.

Aber über einen SIP Service konnte ich sehen, dass der Client sich anscheinend ein MRAS-Ticket samt der Konfiguration geholt hat:

In der Antwort war dann auch schön zu sehen:

Also musste wieder ein Netzwerkmitschnitt her, in dem man den STUN/TURN-Handshake sehen konnte. Hier gibt es zwei UDP-Streams:

Was dann im Trace zu sehen ist, ist die Anforderung von zwei TURN-Verbindungen, über die dann RTP-Simulationsdaten übertragen werden.

Das Tool "PreCall Diagnostics" macht also gar keinen Call per SIP zu einer Gegenstelle auf, sondern nutzt SIP nur, um sich MRAS-Token und Edge-Namen zu besorgen und fordert dann zwei TURN-Kandidaten an, über die es sich dann gegenseitig Pakete zu sendet. Das ist durchaus pfiffig gelöst, da damit diese Tests nicht im SIP-Trace oder CoE/CDR-Datenbanken erscheinen und keine Gegenstelle intern erforderlich ist. Der Edge-Server erfüllt einfach seine originäre Funktion eines TURN-Servers.

Wer nun genau aufgepasst hat, sieht hier dennoch eine Lücke. Ich bin mal gespannt, ab wann der erste Trojaner (oder Geheimdienst) diesen Weg entdeckt, um Informationen quasi über VoIP unbemerkt zu versenden. Technisch muss der Client natürlich sich erst ein MRAS-Token besorgen. Je mehr Anwender aber Lync nutzen, desto eher könnte das der Fall sein. Im Gegensatz zu einer Mail (Messagetracking) oder Webübertragung (HTTP-Proxy-Logs) oder als Lync Filetransfer (QoE/CDR-Datenbank) wird dieser Tunnel per Default nicht protokolliert.

Lync nutzt natürlich nur SRTP, also verschlüsseltes RTP, aber dabei wird nur die Playload innendrin verschlüsselt. der Rahmen drum herum bleibt sichtbar. Entsprechend kann Wireshark auch die Statistiken erstellen:

In 2 Minuten werden also 1501 Pakete übertragen, oder 12 Pakete/Sek. Dabei kommen ca. 350kbyte, also ca. 20KBit in jede Richtung zusammen. Das kommt natürlich nicht an eine Audio-Verbindung mit 50 Pakete/Sek a 20ms Sampling und ca. 100kbit/Sek heran aber reicht für einen Hintergrundtest in der Regel aus. Vermutlich lassen sich nur langsame GSM-Verbindungen so nicht testen, die bei 100kbit zusammenbrechen aber bei 20kBit unauffällig bleiben.

Trotzdem hätte ich mir gerne gewünscht, dass man z.B.: die Bitrate auf reale Werte oder frei einstellen kann. Auch wenn der primäre Fokus erst einmal Audio ist, so wäre dann Test mit vielleicht 650kbit (VGA Video) oder ca. 1,5 MBit (HD 720p) erst möglich.

Der Payload ist allerdings nicht zu verarbeiten. Wireshark kann ihn zwar noch zusammensetzen aber schon die Wave-Anzeige stellt klar, dass es sich dabei wohl nicht um hörbare Töne handelt oder dank SRTP und der Nutzung des Codex "115 RTAudio" die Daten sowieso nicht gelesen werden könen.

Einschätzung und Einschränkungen

Das "PreCall Diagnostic" Tool ist ein erster Ansatz, um eine VoIP-Verbindung und die Erreichbarkeit des Edge-Servers zu prüfen aber nicht mehr und nicht weniger. Es ist prädestiniert für den Einsatz auf Clients im Homeoffice durch den 1st Level Support aber hier sind allein die Zahlen nicht aussagekräftig. Sicher fällt auf, wenn der Edge-Server nicht zu erreichen ist und daher gar nicht passiert oder die Jitter-Zeiten stark schwanken. Auf der anderen Seite sollte man dabei schon eine praxisnahe Datenrate oder sogar eine etwas höhere Rate einstellen können, um die Grenzen ausloten zu können.

Ich hätte mir gewünscht, dass dies kein eignes Programm ist sondern die Funktion im Lync Client mit enthalten ist. Der Anwender hat heute schon eine "Test-Funktion" um mit einem Anruf beim Lync "TestBot" das Headset zu testen.

Dabei werden auch durch die Ansage ca. 10 Sek, durch die eigene Sprachaufzeichnung noch mal 7 Sekunden, und die Wiedergabe weitere 25 Sekunden übertragen. Diese Anrufe werden auch mit QoE/CDR-Datenbanken gespeichert und sind damit wunderbare "Probes" sowohl für den Anwender als auch den Administrator. Es fehlt nur eine entsprechende Anzeige analog zu PCD bei diesem Testcall.

Leider kennt das Tool keinen "Kommandozeilenmodus", so dass es nicht einfach mal als gesteuerte Probe eingesetzt werden kann. Aber im Dauerbetrieb kann es genutzt werden , um durch die Wohnung zu laufen und die WiFi Verfügbarkeit zu müssen. Wobei auch hier die Qualität weniger von der Entfernung oder einer Stichprobe abhängt, sondern eher von den Mitbewohnern und Mitnutzern.

Weitere Links