SDN - Lync LiveView Version 1

Achtung: Diese Version funktioniert nur mit SDN2.0. Microsoft hat mit SDN2.1 die Schnittstelle zwischen LDL und LDM umfangreich geändert. Ich arbeite daher an einer Version für SDN 2.0.

Schon länger überlege ich, wie ich einen "LiveView" für Lync erreichen kann, d.h. eine Anzeige der aktuellen RTP-Verbindungen. Ich habe schon länger überlegt dazu mit MSPL eine Lösung zu bauen aber nun kommt mir das SDN-API entgegen.

Nachdem Sie nun genau wissen, wie SDN mit Lync funktioniert und welche Informationen vom Lync Dialog stener per HTTP-POST an den Lync Dialog Manager gesendet werden, dann können Sie sich vielleicht vorstellen, wie schnell diese Schnittstelle mein Interesse geweckt hat. Der LDL kommt von Microsoft und ist damit robust, getestet und supportet und die Funktion des LDM kann ich auch selbst anbieten.

There is an short english version available at SDN Live View

Der Lösungsansatz

Nachdem mein Kollege Thomas Torggler und ich die verwendeten Protokolle analysiert und verstanden haben (Siehe Lync LDL2LDM) haben wir uns daran gemacht, zuerst per PowerShell und einem einfachen HTTP-Listener (Siehe PS HTTPServer) die Daten anzunehmen. Als erster Proof of Concept braucht ich einen Service, der per HTTP erreichbar ist und die POST-Requests des LDL einfach annimmt und speichert. Da ich erst mal keinen IIS mit einer ASPX Seite dazu aufsetzen wollte und ja noch nicht weiß, was da überhaupt gePOSTed wird, hat ein kleiner HTTP-Listener auf Basis von PowerShell schon mal gereicht:

Nachdem dies geschafft war, haben wir im zweiten Schritt noch eine Schnittstelle eingebaut, um die Daten per Browser abzurufen. Es war etwas knifflig, bis wir die verschiedenen Fälle korrekt verarbeitet haben und eine halbewegs brauchbare Aufbereitung als HTML-Tabelle implementiert hatten. Das sollte ja alles erst mal in einem einzelnen PowerShell-Skript laufen und nicht gleich in eine große Aufgabe mit installiertem IIS, SQL-Backend etc. ausarten. Aber eine Ausgabe der erhaltenen Daten in eine Datei ist natürlich schon enthalten.

Die Idee

Erstes Ziel war eine einfache Lösung ohne umfangreiche Installation. Es soll einfach und ohne große Installation funktionieren und gar keine langfristigen Daten ermitteln. Daher verzichte ich auf SQL-Datenbanken o.ä. Dafür gibt es den Lync Monitoring Server. Die erste Version ist daher eine einfache PowerShell-Variante und ein Webbrowser ohne SSL oder Authentifizierung als Client. Eine spätere Weiterentwicklungen auf einer "richtigen" Plattform als Dienst und ASPX-basierte Oberfläche mit Filtern, sortieren, Verschlüsselung, Authentifizierung etc. kann ja immer noch kommen.

Drei Dinge soll die Lösung bereit stellen:

  • ActiveCalls
    Per Browser möchte ich eine Liste der gerade aktiven Lync Calls sehen mit den Informationen zum Zeitpunkt, der Teilnehmer und der Call ID. Da ein Call auch mehrere "Modalities" haben kann (also Audio, Video, RDP etc.) soll auf der Übersicht auch nur angezeigt werden, welche Verwendung aktiv ist. Über einen Details-Link, z.B. über die CallID als Schlüssel möchte ich aber auch sehen, welche IP-Adressen Ports und ggfls. Codecs dahinter stehen.
  • Call Logs
    Im Lync Monitoring Server steht sehr viel drin aber auch wenn Sie QoE installiert haben, kann diese Skript dennoch die ein oder anderen Daten für die Fehlersuche loggen. Es ist gut sichtbar, dass im Code noch viel mehr drin schlummert, als Microsoft aktuell für die Funktion SDN benötigt
  • Alarm
    Interessant könnte es auch sein auf aktuelle Probleme sehr schnell zu regieren, z.B. wenn ein Call fehlschlägt. Hierzu müssen natürlich erst noch Daten gesammelt werden, welche Fehler wie im XML-Status sichtbar werden.

Die Liste der Anforderungen wurde absichtlich klein gehalten, um erst einen Proof of Concept zu erhalten und bei der Entwicklung letztlich auch zu lernen, welche Funktionen in welcher Ausprägung sinnvoll sind.

Technische Umsetzung

Aus dem Lync SDN-API-Paket müssen Sie auf dem Frontend Server den "Lync Dialog Listener" installieren und idealerweise bei der Installation schon eine passende URL, z.B. "http://localhost:9200" angeben, hinter der dann der nächste Baustein lauscht. Ein paar kleine Einstellungen sind in der Konfiguration erforderlich, z.B. Um den Obfuscator abzuschalten. Schließlich möchte ich in der Übersicht schon die "richtigen Teilnehmer" sehen. Der zweite Teil in der Kette hat einfach die Aufgabe HTTP-Post-Anfragen von den Lync Frontend Servern anzunehmen und die XML-Daten auseinander zu schneiden. Dazu pflegt das Skript intern zwei Datenstrukturen:

  • ActiveCalls-Hastabelle mit CallID als Key
    SIP-Verbindungen werden über eine eindeutige CallID identifiziert. Entsprechend merkt sich das Skript hier aktive Calls und kann nachfolgende Meldungen eindeutig zuordnen. Die Daten enthalten ein PSObject mit den beiden Endpunkten (SIP-Adresse) und dem Zeitpunkt des ersten Auftretens und die aktuell genutzten Funktionen (Audio/Video/DesktopSharing etc)
  • SDP-Tabelle
    Zu jeder SIP-Verbindung kann es ein oder mehrere SDP-Verbindungen geben. Wenn Sie per Lync "telefonieren", dann gibt es zu einer CallID zwei SDP-Sitzungen, je eine pro Richtung für die Audiosignale. Wird noch Video genutzt, dann sind es zwei weitere SDP-Endpunkte. In einer Konferenz können es mit Roundtable sogar noch mehr sein. Diese Tabelle enthält diese aktive Verbindungen mit der CallID, dem Startzeitstempel, die Nutzlast /Audio, Video u.a.) und den IP-Endpunkten samt Port.

Über den Auswertezugang wird zuerst eine Liste der aktiven Calls basierend auf der Hashtable aufgebaut und wenn der Administrator einen Call genauer sehen will, dann werden die entsprechenden Zeilen aus der SDP-Tabelle gefiltert und ausgegeben

Das Skript hat also die Aufgabe die per POST eingelieferten Daten aus der XML-Struktur zu extrahieren und in den Datenstrukturen abzulegen und zugleich daraus einfache HTML-Ausgaben zu erzeugen, die von einem Client angezeigt werden können. Zudem sollte es natürlich seine Aktivitäten protokollieren und für spätere Auswertungen die Änderungen an der SDP-Tabelle und der ActiveCalls-Hastabelle in Logfiles ablegen

Zwischenstand

Nach relativ kurzer Zeit konnten wir so Vollzug melden und jede SDN-Meldung an das Skript wurde in einer Datentabelle hinterlegt und konnte per Browser abgerufen werden. Noch ein kleines "HTTP-Referesh" als Meta eingebaut und schon war die Anzeige im Browser schon "beinahe Realtime". Hier mal ein Blick auf ein Beispiel.

Der Browser zeigt hier den einen aktiven Call von mir zuhause zum Lync stbot" an, für den es zwei Audio-Verbindungen gibt. Anhand der Kandidaten kann man aber sehen, dass hier die 173.10.121.193 wohl die DSL-IP-Adresse zuhause ist, die eine Verbindung zum Edge-Server (80.66.20.21) aufgebaut hat. Die interne Audioverbindung vom Edge zum Lync Server ist hier nicht sichtbar. für SDN extern ist das natürlich optimal, wer intern mit SDN sein Netzwerk optimieren will, wird dies aber erst mal vermissen.

Voraussetzungen für den eigenen Einsatz

Die aktuelle Lösung ist "sehr" einfach. Sie müssen die Lync SDN-API herunterladen und aus dem Archiv nur den Lync Dialog Listener installieren und so konfigurieren, dass er die Daten zu dem Server weiter gibt, auf dem das PowerShell-Skript zum Einsatz kommt.

Das Skript selbst wird einfach nur "als Administrator" gestartet. Ohne administrative Rechte kann der HTTP-Listener nicht on the Fly einen Port öffnen. Um eine Debug-Ausgabe zu sehen, sollte man ein "-verbose" anhängen.

c:\start-lyncLifeView.ps1 -verbose

Danach sollten sie den Dienst "Lync Dialog Listener" starten. Wenn der Dienst vorher schon läuft, kann es etwas dauern, bis er wieder die Verbindung aufnimmt.

Download

Das Skript kann auch zur Überwachung von Gesprächen eingesetzt werden, so dass ich es nicht einfach zum Download bereit stelle. Bitte sprechen Sie mich an, wenn Sie mittels der SDN-API erweiterte Realtime-Auswertungen ihrer Umgebung benötigen.

Das erste Skript hat mit der SDN 2.0 sauber funktioniert. Leider hat Microsoft mit der SDN 2.1 die Funktion erweitert und erwarte ein paar Daten, die ich erst noch nachrüsten muss, ehe das Skript auch für SDN 2.1 nutzbar ist.

Weiterentwicklung

Das bisher Erreichte zeigt, dass mit den Modulen von Microsoft für SDN auch ganz andere Lösungen gestrickt werden können. Aber die bestehende Umsetzung kann natürlich noch deutlich weiter entwickelt werden, z.B.:

  • C# Dienst anstelle eines PowerShell-Skripts
    Ein PowerShell-Skript ist natürlich nur für den gelegentlichen Gebrauch aber kein "Systemdienst". für einen Dauerbetrieb sind deutlich mehr Anforderungen zu erfüllen, z.B. das Starten als Dienst mit einem niedrig privilegierten Konto, entsprechendes Logging und Alarmierungen im Eventlog, effektives Speichermanagement etc.
  • Sicherheit des POST
    Aktuell akzeptiert das Skript POST-Daten von jeder Quelle und ist damit "störgefährdet", zumindest wenn der Port von nicht vertrauenswürdigen Clients erreicht werden kann. Eine einfache IP-Whitelist wäre ein erster Ansatz. Auch eine Verschlüsselung des Request per HTTPS wäre eine Idee.
  • Client Zugriff mit SSL und Authentifizierung
    Ebenso generiert das Skript für jeden Client, der die IP-Adresse und den Port erreicht, die Information. Die Daten sind nicht verschlüsselt aber sobald eine Authentifizierung gefordert ist, sollte auch SSL notwendig werden
  • "Rich GUI"
    Statische HTML-Seiten ohne Filter o.ä. sind natürlich noch WEB 1.0. Filtern, Sortieren, Gruppieren etc. geht so nicht wirklich. Aber dann kommt man langsam zu dem Punkt diese Bewegdaten in einer SQL-Datenbank abzulegen und die Sammlung und die Aufbereitung zu trennen. Dann sollte auch nicht mehr der Dienst selbst als "mini Webserver" dienen, sondern z.B. in IIS mit ASPX zum Einsatz kommen

Das PowerShell-Skript war nur ein "Proof of concept" aus dem noch mehr werden wird. Allerdings benötigt das natürlich Zeit und einige Dinge sind noch nicht abschließend geklärt, z.B.

  • Fehlermeldungen eskalieren
    In den XML-Daten finden sich auch Fehlermeldungen. Es wäre sehr interessant, die Fehler einzusammeln und z.B. nach Standorten korrelieren. Wenn Standorte z.B. gehäuft Fehler über die gleiche WAN-Strecke melden, kann das auf Überlastsituationen hinweisen. Auch können die Fehler z.B. Probleme bei Gateway quasi "real time" erkennen
  • Interne Verbindungen
    Ich muss noch mal nachschauen, wie die XML-Struktur aussieht, wenn interne Teilnehmer involviert sind oder nur interne Teilnehmer A/V nutzen. Bei der Erstellung dieser Seite in Seattle konnte ich das aber noch nicht nachstellen.
  • Meldungen ohne QoE
    Zudem muss ich noch prüfen, wie die Ausgaben sich verändern, wenn in der Lync Topologie kein QoE-Server vorhanden ist.
  • "Echter Dienst" statt PowerShell
    Auf dauer ist ein PowerShell natürlich keine geeignete Lösung für einen Serverbetrieb. Interessant wäre z.B. ein "Windows Dienst" oder gleich eine ASPX-Applikation, die im IIS als als eigenständiger WebService die Daten annimmt, vielleicht auch "in der Cloud" und dann nicht nur berichtet, sondern auch aktiv Meldungen absetzen kann.

Es bleibt also noch etwas zu tun.

Weitere Links