SDN LDM 2 Network

Auf Basis des SDN 2.1 API, welches Microsoft noch einmal deutlich gegenüber den Vorgängerversionen umgestellt hat, habe ich die Pakete zwischen Lync Dialog Manager und den nachgelagerten Netzwerkkontroller analysiert. Durch den Einsatz einer unverschlüsselten Verbindung konnte ich die Pakete mitschneiden, die der Lync MDM an den Controller sendet.

Basisfunktion

Dass es sich um "irgendwas mit HTTP" handeln muss, kann man schon in der Konfiguration des LDM sehen, an der als nächstes Ziel der oder die Controller angegeben werden:

Entsprechend habe ich hier mal einen Servernamen und Port eingegeben, und auf dem Port einen TCP-Listener laufen lassen. So konnte ich mit Wireshark und den Debuglogs mir die Daten anschauen, die der LDM zum "Network Controller" sendet. Denn eine passende Dokumentation habe ich noch nicht gefunden. So kommt der POST dann in Wireshark an.

POST /site HTTP/1.1
Content-Type: text/xml
Accept: text/xml
Host: ldmlogger.netatwork.de:80
Content-Length: 5217
Expect: 100-continue

<LyncDiagnostics Version="C">
.... die Daten hier werden im folgenden in Bildern beschrieben.
</LyncDiagnostics>

Es ist gut zu sehen, dass der Hostheader samt Port mitkommt und der Pfad der URL als Pfad beim "Post" erscheint. Mehr ist im Header aber nicht zu sehen. Interessanter ist sicher die per POST gesendete XML-Struktur.

LDM-Post XML

Es ist schnell zu sehen, dass sich die Pakete gar nicht allzu viel von den vorherigen Versionen unterscheiden, die mit dem Skript SDN - LiveView schon ausgewertet werden. ,Genau genommen sind die Daten etwas umfangreicher und die XML-Tags anders. Die XML-Struktur für einen neuen Call sieht wie folgt vereinfacht aus:

Das Tag "<LyncDiagnostics Version ="C">" umrahmt den Datensatz. Darin werden unter "<ConnectionInfo>" dann die Daten für diesen Call vorgehalten. Die Sektion "<Start>" ist hier zweimal vorhanden da ein Audiocall auch zwei Richtungen hat. Der Bereich "ConnectionInfo" ist für alle Pakete des gleichen Calls gleich aufgebaut. Bei einem Begin eines Calls ist aber der Bereich "<From>" und "<To>" interessant. Stehen hier doch die Kommunikationspartner drin, die per Default aber "Obfuscated" sind.

Der Bereich "<Properties>" enthält die erwartete Bandbreite und die Codec

Beim Ende eines Calls steht stattdessen ein "<Ended> in der XML-Struktur"

Während die Informationen in "<connectioninfo>", "<From>" und "<To>" wie beim Start aufgebaut sind, ist der Wert bei "Properties" hier deutlich kleiner.

Sofern Sie QoE in ihrer Lync-Umgebung aktiviert haben, werden auch diese Daten über den LDL und den LDM an den Netzwerkcontroller gesendet.

Durchaus interessante Daten, um diese in einem Echtzeitstatus auszuwerten.

Post-Antwort

Natürlich erwartet der Lync Dialog Manager auch eine Antwort auf seien Post. Ohne passenden Netzwerkkontroller ist es aber sehr schwer hier eine Antwort vorzugeben. Ich habe daher erst einmal eine leere Seite mit einem "200 OK" zurück gegeben. Damit war der LDM erst einmal zufrieden. Aber nachdem ich per PowerShell da erste Auswerteskript gebaut hatte, kamen Meldungen immer wieder herein. Anscheinend braucht der LDM eine passende Rückmeldung als Quittung die über einen "200 OK" hinaus geht. Nachdem ich etwas die Schnittstelle zwischen LDL und LDM betrachtet habe, habe ich es einfach mal versucht eine XML-Antwort mit der USN zu liefern.

200 OK
Content-Length: 17
Content-Type: application/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Fri, 20 Feb 2015 06:30:40 GMT

<count>15</count>

Die 15 ist in dem Beispiel die Antwort auf den POST mit der 15 als "CSEQ"

Der LDM hält eine Queue vor, d.h. wenn der WebService die Daten nicht annehmen kann, werden sie später gesendet. Wenn der Webservice eine ältere Sequenznummer verwendet, dann werden die älteren Daten noch einmal gesendet. Ich weiß aber nicht, wie groß der Puffer ist aber 100 "Nachlieferungen" habe ich schon zählen können.

XML Daten im Details

Ich habe zwar ein paar Zeilen vorher schon in Bildern die XML-Dateien auseinander gelegt aber natürlich ein paar Informationen ausgelassen. Hier habe ich eine XML-Datei zum Download bereit gestellt, in der die Daten des LDM an mein SDN-Watcher eines Textanrufs enthalten sind. Ein paar Randbedingungen

  • Der Call wurde um 7:30 Ortszeit von mir über den Lync Client zum "TestBot" ausgeführt
  • Der Client war mein Notebook in den USA im Hotel WiFi
  • Die Verbindung wurde also über den Edge-Server zum Frontend aufgebaut

sdnldm2network.txt

Wer sich die Daten genau anschauen, wird als IP-Endpunkt die öffentliche IP-Adresse in den USA und die öffentliche "Edge-IP"-Adresse erkennen. Im XML-File kann man neben den Ports leider nicht erkennen, ob die Verbindung per UDP oder TCP hergestellt wurde.

Das zeigt mir das Skript auch an:

SDN protokolliert in dem Fall also nicht die internen Adressen. Das ist hier auch sinnvoll so, da der Edge Server und der Frontend Server in der gleichen Lync-Site stehen und daher "gut verbunden" sind. Hier macht es kaum Sinn mit SDN oder CAC oder QoS etwas zu steuern.

Ich muss diese Messungen noch mal in einer größeren Umgebung mit Client in verschiedenen Gegenstellen wiederholen.

Wenn man verschiedene Clients an verschiedenen Stellen nutzen, dann ist es schon interessant zu sehen, welche IP-Kandidaten im SDN-Paket enthalten sind

Beschreibung Client A
Intern in Remote Site		 Client C
Extern via Edge		 IP1 IP2

Interne direkte Verbindung oder (Same Site,

 

 

 

Zentrale Site nach Extern (Via Edge)

 

 

 

 

Remote Site nach Extern (Via Edge)

 

 

 

 

Extern mit Extern

 

 

 

 

Intern mit Federation

 

 

 

 

PSTN Gateway ohne Media Bypass

 

 

 

 

PSTN Gateway mit Media Bypass

 

 

 

 

Conf DialIn/Out

 

 

 

 

Weitere Links