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.<Post>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
- SDN Logger
- InCall QoE
- Skype or Business SDN 2.4
- Lync Server API - MSPL
- Overview of Skype for Business SDN Interface
https://docs.microsoft.com/en-us/skype-sdk/sdn/articles/overview - Skype for Business SDN Interface architecture
https://docs.microsoft.com/en-us/skype-sdk/sdn/articles/interface-architecture - Using the Skype for Business SDN Interface
https://docs.microsoft.com/en-us/skype-sdk/sdn/articles/using-the-sdn-interface - Lync SDN Interface Schema Reference
https://docs.microsoft.com/en-us/lync/sdn-interface/lync-sdn-interface-schema-reference - Configuring LSM to send messages to network controllers
https://docs.microsoft.com/en-us/lync/sdn-interface/configuring-lsm-to-send-messages-to-network-controllers