SDN 3.0

Ende 2017 hat Microsoft für viele unbemerkt die Version 3.0 des Software Defined Network-Listeners für Skype for Business released. Wesentliche Änderungen sind RLS 1.2 Unterstützung und nun auch Daten zu WiFi-Verbindungen etc. Zudem versteht SDN 3.0 nun auch Video Based Screen Sharing (VBSS). Also höchste Zeit die neue Version noch mal anzuschauen.

Beachten Sie dazu auch InCall QoE

Installation LDL

Die Einrichtung unterscheidet sich nicht wirklich von der Skype for Business SDN 2.4.

SDN Version 3.0
https://www.microsoft.com/en-us/download/details.aspx?id=54685

Beachten Sie, dass das Setup als Administrator gestartet werden muss, da die Routine direkt in der XDS-Datenbank Veränderungen vornimmt und dies sonst nicht möglich ist.

Es passiert aber nichts, denn das Setup erkennt dies als Fehler und führt die Installation nicht aus.

Bei der Installation müssen die mehrere Dialoge beantworten.

Das Zielverzeichnis ist identisch und das DebugLog landet aus meiner Sicht immer noch fälschlicherweise im TEMP-Verzeichnis des installierenden Benutzers anstatt einem Systemverzeichnis. Ich ändere den Pfad für die SDNLogs hier natürlich.

In meinem Beispiel ist die Gegenseite, d.h. der LDM, auf dem gleichen Server. Wenn Sie mehrere Server haben, dann sollten Sie irgendwo einen zentralen LDM aufbauen, der die Meldungen aller Listener annimmt.

Wer erhöhte Anforderungen an die Sicherheit hat, kann die Verbindung zwischen LDL und LDM per Zertifikat absichern lassen.

Zuletzt müssen Sie noch eine Entscheidung treffen, mit welchen Anmeldedaten der LDL-Dienst läuft. Ich lasse hier Network Service.

Hinweis: Die LDL-Installation addiert ein MSPL-Script, Wie Sie recht einfach erkennen können. Der Name "SDN22) ist natürlich irreführend.

PS C:\Temp\SDN.3.0> Get-CsServerApplication | ft priority,name,enabled,critical -AutoSize

Priority Name                Enabled Critical
-------- ----                ------- --------
       0 SDN22                  True    False
       1 ClientVersionFilter    True     True
       2 TranslationService     True     True
       3 UdcAgent               True    False
       4 XmppListener           True    False
       5 UserServices           True     True
       6 InterClusterRouting    True     True
       7 IIMFilter              True     True
       8 UserPinService         True     True
       9 DefaultRouting         True     True
      10 ExumRouting            True     True
      11 OutboundRouting        True     True
      12 XmppRouting            True    False
       0 IIMFilter              True     True
       1 OptionsHandler         True    False

Zudem wird auch noch eine Abhängigkeit mit dem Windows Dienst RTCSRV eingetragen, damit die SDN-Dienste erst starten, wenn der RTCSRV läuft.

.

Damit ist die Installation des "Lync Dialog Listeners" (LDL) abgeschlossen.

Installation LDM

Die zweite Komponenten ist der SDN Manager (LDM), der auf Port 9333 die Verbindung der LDL-Instanzen und deren Daten annimmt und diese zusammenführt. Auch hier finde ich die Wahl des Log-Verzeichnisses unglücklich:

Bei der Topologie haben Sie die Auswahl zwischen drei Varianten. Per Default ist ein "Join Redis" eingestellt. Da ich aber nur eine Instanz habe, habe ich die dritte Option "Standalone" gewählt.

Weitere Abfragen kommen dann nicht. Wer natürlich eine SQL-Datenbank im Hintergrund betreibt, wird in den Folgedialogen zu weiteren Eingaben aufgefordert.

Eventlog und Debuglog

Sowohl der Listener als auch der Manager protokollieren Meldungen in dem gleichen eigenen Eventlog.

Hier ist gut zu sehen, dass zuerst noch eine Fehlermeldung kommt, weil der LDL nicht mit dem LDM kommunizieren kann. Erst nachdem auch der LDM gestartet ist, sind beide "ruhig". In den Verzeichnisse, die bei der Installation als Log-Ziel angegeben wurden, finden sich noch ausführlichere Informationen.

Konfiguration

Nach der Installation lauscht der Listener schon mal die SIP-Pakete ab, sammelt die Daten der Clients ein und sendet diese zum bei der Installation schon angegebenen konfigurierten LDM. Der LDM nimmt die Verbindungen an aber damit ist die Konfiguration noch lange nicht abgeschlossen. Die eigentliche Parametrisierung erfolgt über PowerShell. Das war bei Skype for Business SDN 2.4 schon sehr ähnlich. Alle Commandlets beginne mit *-cssdn*.

Sie finden die PowerShell im Startmenü unter "Start Menu\Programs\Skype for Business - SDN Interface". Gestartet wird eine PowerShell mit folgenden Parametern.

cd $env:UserProfile;
Write-Host 'Loading Module for Skype for Business SDN Interface ...'; 
Import-Module 'C:\Program Files\Microsoft Skype for Business Server\Microsoft Skype for Business SDN Manager\SdnCommands.psm1'

Dann stehen ihnen die folgenden Befehle zur Verfügung:

(Get-Command *cssdn*).Name

Add-CsSdnListener
Add-CsSdnSubscriber
Get-CsSdnCatalog
Get-CsSdnListener
Get-CsSdnLog
Get-CsSdnManager
Get-CsSdnStatus
Get-CsSdnSubscriber Get-CsSdnSubscriberStatus
Set-CsSdnListenerParameter
Set-CsSdnManagerParameter
Set-CsSdnSubscriberParameter
Remove-CsSdnListener
Remove-CsSdnSubscriber

Zuerst lese ich ein paar Werte aus. Die PowerShell verbindet sich dazu per HTTP mit dem LDM. Die URL dazu muss man immer mit angeben. Leider nutzt die Powershell nicht per Default den Eintrag "https://localhost:9993/settings".

Zuerst schaue ich mir die Einstellung der Listener an:

Get-CsSdnListener -SdnPoolUri http://localhost:9333/settings
<Configuration Version="2.0" culture="en-US" LastModified="2018-02-25T20:06:00.4783797Z">
  <Configuration Version="2.0" culture="en-US" Kind="Listener" Identifier="sfb01.msxfaq.net" LastModified="2018-02-25T20:06:00.4783797Z">
    <parameter key="submituri">http://localhost:9333/LDL</parameter>
    <parameter key="alternativeuri">
    </parameter>
    <parameter key="clientcertificateid">
    </parameter>
    <parameter key="submitqueuelen">1000</parameter>
    <parameter key="maxbackoff">30</parameter>
    <parameter key="maxdelaylimit">5</parameter>
    <parameter key="maxopen">100</parameter>
    <parameter key="maxretry">100</parameter>
    <parameter key="maxretrybeforefailover">10</parameter>
    <parameter key="requester">sfb01.msxfaq.net</parameter>
  </Configuration>
</Configuration>

Die globale Konfiguration zeigt u.a. an, dass Obfuscation noch eingeschaltet ist.

PS C:\> Get-CsSdnCatalog -SdnPoolUri http://localhost:9333/settings
<Catalog Version="A" xmlns="uctp.skype.microsoft.com" xmlns:s="uctp.skype.micro
soft.com">
  <Identity>
    <Name>sfb01.msxfaq.net</Name>
    <PoolName>MySDNDB</PoolName>
    <Role>UCS</Role>
    <Scope>
    </Scope>
  </Identity>
  <Endpoints>
    <Connection Transport="WebSockets" Encoding="text/xml" />
    <Connection Transport="WebSockets" Encoding="application/json" />
  </Endpoints>
  <Topic Name="LyncDiagnostics" Version="1.0" Schemas="SDNInterface.Schemas.D">
    <Element Name="SendRawSDP" Version="2.0" />
    <Element Name="Quality" Version="2.0" />
    <Element Name="Signaling" Version="2.0" />
    <Element Name="ObfuscationSeed" Version="2.0" />
  </Topic>
  <Topic Name="VQ" Version="1.0" Schemas="ms-rtcp-metrics,ms-rtcp-metrics.v2,ms
-rtcp-metrics.v3,ms-rtcp-metrics.v4,ms-rtcp-metrics.v5">
    <Element Name="ObfuscationSeed" Version="3.0" />
  </Topic>
  <Topic Name="SBCQuality" Version="1.0" Schemas="sbc.uctp.skype">
    <Element Name="DeviceOverview" />
    <Element Name="Addressing" />
    <Element Name="UserInfo" />
    <Element Name="Summary" />
    <Element Name="Update" />
    <Element Name="Attempt" />
  </Topic>
  <Topic Name="NCQuality" Version="1.0" Schemas="nc.uctp.skype">
  </Topic>
</Catalog>
PS C:\>

Ich werde also die "Endpunkte", d.h. die SIP-Adresse der Teilnehmer nicht im Klartext sehen.

Daten bekommen

Schön, wenn die Clients ihre QoE-Daten zum Frontend senden, der LDL die Daten abgreift und an den LDM sendet. Irgendwo müssen die aber auch rauskommen. Auf Skype for Business SDN 2.4 habe ich schon den gleichen Ansatz gewählt. Ich muss erst mal einen Subscriber addieren und konfigurieren.

Add-CsSdnSubscriber `
   -SdnPoolUri: http://localhost:9333/settings `
   -Identifier: Subscriber1

Dann muss ich noch die URL des Subscriber hinterlegen, an die der LDM die Daten sendet.

Set-CsSdnSubscriberParameter `
   -SdnPoolUri http://localhost:9333/Settings `
   -Identifier Subscriber1 `
   -Parameter submituri `
   -Value "http://localhost:85/sdndata.aspx"

Und neben der Quality-Daten möchte ich auch noch die Signalisierungsdaten.

Set-CsSdnSubscriberParameter `
   -SdnPoolUri http://localhost:9333/Settings `
   -Identifier Subscriber1 `
   -Parameter "signaling" `
   -Value "true"

Zur Bestätigung haben ich mir die Parameter noch mal anzeigen lassen:

get-CsSdnSubscriber -SdnPoolUri http://localhost:9333/Settings -Identifier subscriber1
<Configuration Version="2.0" culture="en-US" Kind="Subscriber" Identifier="SUBSCRIBER1" LastModified="2018-02-26T15:23:44.2948760Z">
  <parameter key="submituri">http://localhost:85/sdndata.aspx</parameter>
  <parameter key="outputschema">D</parameter>
  <parameter key="clientcertificateid">
  </parameter>
  <parameter key="domainfilters">
  </parameter>
  <parameter key="subnetfilters">
  </parameter>
  <parameter key="tenantfilters">
  </parameter>
  <parameter key="trunkfilters">
  </parameter>
  <parameter key="quality">True</parameter>
  <parameter key="signaling">true</parameter>
  <parameter key="sendrawsdp">False</parameter>
  <parameter key="maxbackoff">30</parameter>
  <parameter key="maxdelaylimit">5</parameter>
  <parameter key="maxopen">100</parameter>
  <parameter key="maxretry">100</parameter>
  <parameter key="submitqueuelen">1000</parameter>
  <parameter key="obfuscationseed">
  </parameter>
  <parameter key="schemaextension">true</parameter>
  <parameter key="Created">Manual</parameter>
</Configuration>

Nun brauche ich natürlich "etwas", was auf Port 85 Pakete annimmt und irgendwie weiter verarbeitet.

The LSM is then responsible for packaging the diagnostic data in XML and posting them to the preconfigured web service of one or more network management systems
Using the Lync SDN API 2.0 https://msdn.microsoft.com/en-us/library/dn439294.aspx

Also habe ich mir auf einem IIS einfach mal schnell eine Webseite angelegt:

Nachdem ich dann auch in der Windows Firewall den Port eingehend geöffnet habe, konnte ich per Browser einen Zugriff durchführen und nun galt es zu warten, ob der LDM etwas sendet. Über das Logging habe ich aber schon gesehen, was passiert:

Get-CsSdnLog -SdnPoolUri http://localhost:9333/Settings -Identifier lneapplog

2018-02-26T16:26:49.8622102+01:00       [TransmissionError]     Processing the message failed. 
  Stop tracking this call. CallId: 643d271c36794548a3a9fb369c669497
  Context: Invite       Subscriber: SUBSCRIBER1 Uri: http://localhost:85/       Name: N/A
  Open: 1 QueueLen: 27     Calls: 6        Waiting: 6      Bad: 52 Dropped: 13     
  V11: InternalServerError        
  E12: System.Net.WebException: The remote server returned an error: (405) Method Not Allowed.
   at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar,
 Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Rtc.Enlightenment.Hub.ConnectionState.&lt;Post&gt;d__28.MoveNext()
2018-02-26T16:26:49.9712128+01:00       [TransmissionError]     Dropping message!
   CallId: 643d271c36794548a3a9fb369c669497      Context: Invite Subscriber: SUBSCRIBER1
  Uri: http://localhost:85/   Name: N/A       Open: 0 QueueLen: 27    Calls: 6
  Waiting: 6      Bad: 52       Dropped: 14     V11: Too many failed attempts.
2018-02-26T16:26:49.9721831+01:00       [TransmissionError]     Dropping message!
    CallId: 643d271c36794548a3a9fb369c669497      Context: StartOrUpdate  Subscriber: SUBSCRIBER1
    Uri: http://localhost:85/       Name: N/A       Open: 0 QueueLen: 26 Calls: 6        Waiting: 5
    Bad: 52 Dropped: 15     V11: Too many failed attempts.

Mein Service reagiert noch nicht auf "POST". Ich habe dann aber erst mal IIS - Webserver Troubleshooting bemüht. Da konnte ich schon mal den POST sehen.

In meinem Fall ist es einfach ein Post auf die angegeben URL. Die Schnittstelle unterscheidet sich nach meinen Analysen nicht von der Beschreibung auf SDN - Lync Link LDL->LDM.. Es sollte also kein Problem sein einen eigenen WebService diesbezüglich zu entwickeln. Eine Nutzung dieser Schnittstelle habe ich auf SDN Logger beschrieben.

Enterprise Logging

Interessant wird die Schnittstelle natürlich, wenn ich einen Service nutze, der die Daten einfach als passende Datei in ein LogVerzeichnis ablegt. Dann könnten andere Agenten wie Telegram, Filebeat u.a. diese Daten einsammeln und weiter visualisieren.

Aktuell habe ich noch keine Software hierfür geschrieben.

Weitere Links