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.

 

Weitere Links