SDN Logger
Auf der Seite SDN - Lync LiveView Version 1 habe ich ein PowerShell Projekt vorgestellt, welches die HTTP-POST-Pakete der Lync Dialog Listener (LDL) eingefangen hat. Das geht mit SDN 2.1 und neuer nicht mehr, so dass eine andere Schnittstelle erforderlich ist. Diese Seite beschreibt meinen "SDN Logger", der die Daten vom Lync Dialog Manager abgreift und ablegt. Das Skript funktioniert auch mit SDN 3.0.
Funktionsweise
Ich habe die Arbeit von SDN - Lync LiveView Version 1 einfach weiter entwickelt und nutze nun die Standard Installation von Microsoft aus LDL und LDM. Die Microsoft Software sorgt alleine dafür die Daten von allen Frontend Servern einzusammeln und über den LDM zusammen zu führen. Diesmal kommt mein Skript derart zum Einsatz, dass es als LDM-Subscriber die Daten bekommt und weiter verarbeitet
Aktuell fange ich nur die "Call Start" und "Call End" auf, die dann in einer CSV-Datei landen. Zudem sammle ich die QoE-Daten ein, die anhand der CallID als eigene Datei gespeichert werden.
Einrichten
Auf der Seite SDN 3.0 ist die allgemeine Einrichtung von SDN 3.0 beschrieben. Für die Funktion des Skripts muss im LDM ein Subscriber mit einer URL hinterlegt werden, zu der LDM die Daten per POST sendet. Dazu dienen folgende Befehlt
Add-CsSdnSubscriber ` -SdnPoolUri: http://localhost:9333/settings ` -Identifier: Subscriber1 Set-CsSdnSubscriberParameter ` -SdnPoolUri http://localhost:9333/Settings ` -Identifier Subscriber1 ` -Parameter submituri ` -Value "http://localhost:85/" Set-CsSdnSubscriberParameter ` -SdnPoolUri http://localhost:9333/Settings ` -Identifier Subscriber1 ` -Parameter "signaling" ` -Value "true"
Nun muss ich in dem Beispiel auf dem Server "Localhost" auf Port 85 einfach nur einen WebService starten.
WebServer per PowerShell
Ich habe als Test einfach ein PowerShell mit dem PowerShell als HTTPServer gebaut, der die Daten annimmt und in Dateien schreibt. Das ist aktuell natürlich weder ein Dienst und läuft auch nicht im Hintergrund. Später wäre eine Umsetzung als ASPX-Lösung oder ein Windows Dienst vermutlich der bessere Weg. Aber die Bildschirmausgabe zeigt die Funktionsweise. Sie sehen hier immer die vier "----"Zeichen, die den Beginn eines Requests kennzeichnen.
Ich sehe in dem Trace sowohl den Beginn als auch das Ende einer Sprachübertragung. Zudem erhalte ich erstmalig hier aber auch InCall QoE-Einträge, die einen Rückschluss über Qualitätsverbesserungen/Verschlechterungen ermöglichen.
Kleiner Webserver
Die aktuellen Calls und Meldungen werden anhand der CallID als Primärschlüssel in einer Hashtable vorgehalten, bis der Call auch wieder ein "CallEnd" meldet. Aktuell ist das natürlich ein kleines Speicherloch, da ein Call auch abbrechen kann und damit das "Bye" ausbleibt. Das Skript ist sicher keine Dauerlösung. Um aber zu sehen, was in meiner SfB Umgebung los ist, habe ich im dem gleichen Script auch eine Komponente eingebaut, um die Daten als sehr einfache HTML-Seite anzuzeigen.
Das hilft bei der Fehlersuche und einer Momentaufnahme. Aber mein Ziel ist es ja Kennzahlen für die Dauerbetrieb zu erhalten.
Beispieldaten
Alle POST-Daten sind eine XML-Struktur mit etwas folgendem Aufbau. Die XML-Daten sind natürlich weit umfangreicher. Hier sehen Sie einen "Start"-Event.
Schon hier sehen sie zwei "Start"-Events, da die Audio-Verbindung ja zwei Streams hat. Es können durchaus noch weitere Events kombiniert enthalten sein. Aus den POST-Daten erhalten ich bislang folgende Events.
Event | Beschreibung | |
---|---|---|
Invite |
Ein Ruf wird gestartet aber wurde noch nicht angenommen |
|
Start |
Die Audio-Verbindung wurde gestartet. Der Event enthält Informationen zu den Endpunkten und die Liste der Codecs |
|
Ended |
Die Audio-Verbindung wurde abgebaut |
|
QualityUpdate |
Am Ende das Anrufs kommt bei aktiviertem QoE-Reporting der Datensatz mit der Gesprächsquaität |
|
IncallQuality |
Sofern die Funktion InCall QoE aktiviert worden ist, erhalten Sie auch während des Gesprächs bei größeren Veränderungen. Leider sind genau die TraceRoute-Meldungen nicht enthalten. |
|
Bye |
Die Verbindung wurde auch von der Signalisierung abgebaut |
|
Error |
Damit sind alle Fehlerzustände erkennbar. Die meisten sind natürlich "Ruf abgelehnt", "Unvollständige Nummer", "Besetzt", "Keine Verbindung möglich" etc. Nicht jeder Fehler ist also ein reales Problem. |
|
Daten werden nachgereicht
Reporting und Alarmierung
Aus all den verschiedenen Events kann ich natürlich Daten extrahieren und z.B. in Datenbanken , PowerBi, Azure Log Parsing für eine weitere Auswertung senden. Im ersten Anlauf fände ich z.B. eine Erfassung der folgenden Datensätze interessant,
- Clients mit den Spalten:
IP-URI, IP-Adressen, CallIDs (mehrfach) - Streams
Audio/Video, Bandbreite, Connection, Source, Destination, CallID, Quality - Calls
CallID, Clients
Aktuell werte ich die Daten noch per PowerBI lokal aus.