InCall QoE
Schon lange hat Lync und Skype for Business über die Funktion QoE (Monitoring und CDR) eine Funktion die Audio-Verbindungen zu erfassen. Dazu sendet die Clients am Anfang und Ende ihrer Verbindung eine entsprechende Meldung an den Frontend Server, der die angehängte Information extrahiert und die Daten in eine SQL-Datenbank überträgt.
Seit Skype for Business kann der Server die kompatiblen Clients nun auch anweisen. diese Meldungen während des Gesprächs zu senden. Diese Funktion wird per SDN-Schnittstelle erfasst und ausgeleitet. Sie ist daher nicht direkt mit der QoE-SQL-Datenbank verbunden.
Konfiguration
Ich habe dazu in einer meiner Testumgebungen folgende Konfiguration umgesetzt:
- Kein Monitoring-Server
- Aktive QoE-Konfiguration in der Skype
for Business Topologie
Der Parameter "EnableQoE" ist auf $True gesetzt
PS C:\> Get-CsQoEConfiguration Identity : Global ExternalConsumerIssuedCertId : EnablePurging : True KeepQoEDataForDays : 60 PurgeHourOfDay : 1 EnableExternalConsumer : False ExternalConsumerName : ExternalConsumerURL : EnableQoE : True
- Anpassen der CsMediaConfiguration
Hier wird der Wert "InCallQoSIntervalSeconds" und EnableInCallQoS gesetzt
# Standardeinstellung PS C:\> Get-CsMediaConfiguration Identity : Global EnableQoS : False EncryptionLevel : RequireEncryption EnableSiren : False MaxVideoRateAllowed : VGA600K EnableInCallQoS : False InCallQoSIntervalSeconds : 35 EnableRtpRtcpMultiplexing : True EnableVideoBasedSharing : True # Setzen der Einstellung Get-CsMediaConfiguration | Set-CsMediaConfiguration -EnableQoS $True -EnableInCallQoS:$true #oder Set-CsMediaConfiguration ` -Identity Global ` -EnableInCallQoS:$TRUE ` -InCallQoSIntervalSeconds 35
- Anpassen der CSClientPolicy
Über einen Parameter in der Client Policy kann zusätzlich noch der Weg der Daten zwischen den beiden Endpunkten ermittelt werden. Skype for Business erstellt dazu einen Tracert und sendet diese Daten im QoE-Report an den Server als auch über die SDN-API.
# Vorbereiten des Policy-Eintrags $Policyentry = New-CsClientPolicyEntry -Name "EnableTraceRouteReporting" -Value "TRUE" # Addieren des Eintrags an alle Client Policies foreach ($Policy in get-csclientpolicy) { $policy = get-csclientpolicy -identity $Policy.identity $policy.PolicyEntry.Add($Policyentry) set-csclientpolicy -instance $policy } # Kontrolle Get-CsClientPolicy | fl identity,pol*
Dieser Eintrag ist etwas ungewöhnlich vorzunehmen, Es gibt keinen eigenen "Parameter" sondern er wird quasi als Freifeld addiert. Siehe dazu auch Lync Client Policies
Bitte nicht irritieren lassen, dass der Name auf "InCallQoSIntervalSeconds" lautet. Es hat nichts mit QoS mit Skype for Business auf dem Netzwerk zu tun. Ein "QoE" wäre weniger verwirrend gewesen.
Die "35 Sekunden" bedeuten nicht, dass nun alle 35 Sekunden eine Statusmeldung kommt. Der Client sendet eine Meldung nur, wenn sich die Qualität signifikant verändert. Insofern ist es auch nicht gefährlich hier "1 Sekunde" einzutragen.
Leider werden die "TraceRoute"-Ergebnisse nicht per SDN übermittelt, sondern nur in der QoE-Meldung an die Monitoring Datenbank.
Leider habe ich den folgenden Text zu spät gesehen. Sonst hätte ich die Installation des LDL abgewartet um zu schauen, welchen Wert der LDL hier ändert.
If using the latest official build of Skype for Business Server (build
7.0.1017.3) as well as the Skype for Business client (16.x.x.x), sending
InCallQuality messages will be activated automatically once the dialog listener
is installed. No manual configuration is necessary.
Quelle: Configuring InCallQoE Messages
https://msdn.microsoft.com/en-us/library/office/mt654029(v=office.16).aspx
Diese Werte können gesetzt werden, wenn gar keine Monitoring-Rolle installiert ist. Im Skype for Business Control Panel ist aber nur ein Teil der Einstellungen zu sehen
Steuerung des Clients
Natürlich muss der Client auch erfahren, dass er diese Daten liefern muss. Ob die Einstellungen auf dem Server auf dem jeweiligen Client wirklich "wirken", können Sie einfach per UCCAPILOG ermitteln. Hier sollten Sie die Einstellungen in der Provisioning Antwort auf den Subscribe finden. Suchen Sie einfach nach:
Content-Type: application/vnd-microsoft-roaming-provisioning-v2+xml
In der etwas längeren XML-Struktur sollten Sie folgende Einträge finden:
SIP/2.0 200 OK Contact: <sip:SfB01.UCLABOR.DE:5061;transport=tls> From: "User1"<sip:User1@uclabor.de>;tag=face7f42b6;epid=038b692c2f To: <sip:User1@uclabor.de>;tag=35620080 CSeq: 1 SUBSCRIBE Content-Type: application/vnd-microsoft-roaming-provisioning-v2+xml Event: vnd-microsoft-provisioning-v2 <provisionGroupList xmlns="http://schemas.microsoft.com/2006/09/sip/provisiongrouplist-notification"> <provisionGroup name="ServerConfiguration" > <qosEnabled>true</qosEnabled> <enableInCallQoS>true</enableInCallQoS> <inCallQoSIntervalSeconds>35</inCallQoSIntervalSeconds> <ucDiffServVoice>40</ucDiffServVoice> </provisionGroup> <provisionGroup name="endpointConfiguration" > <propertyEntryList > <property name="EnableTraceRouteReporting" >TRUE</property> </propertyEntryList> </provisionGroup> </provisionGroupList>
Wenn der Client "neu" genug ist, sollte er diese Anweisung verstehen. Wenn Sie die Funktion testen wollen aber keinen Zugriff auf den Server haben, dann können Sie den Client auch über eine lokale "ocapi_test.config"-Datei entsprechend instruieren
Generate the XML configuration file (ocapi_test.config) and copy it to the
installation path of each Skype for Business client that contains the Lync.exe (for
example, C:\Program Files (x86)\Microsoft Office\root\Office16)
Quelle: Configuring InCallQoE Messages
https://msdn.microsoft.com/en-us/library/office/mt654029%28v=office.16%29.aspx
Der Inhalt sollte wie folgt erweitert werden oder aussehen:
<?xml version="1.0"?> <settings> <InCallQosEnabled>true</InCallQosEnabled> <InCallQoSPeriodInSec>35</InCallQoSPeriodInSec> </settings>
Nach dem Neustart des Clients sollten Sie dann im lokalen UCCAPILOG des Clients auch folgende Meldungen finden:
Meldung beim Beginn eines Calls
Wenn ich einen 1:! Call, z.B.: von Skype for Business zu einem Mobiltelefon starten, dann gibt es keine Meldung des Clients an den Server. Man könnte allenfalls den INVITE und ReINVITE mit den Candidates auswerten, um die ausgehandelte Partnerschaft zu ermittelt. Das macht z.B. SDN um die Verbindung zu melden.
Wenn Sie per VoIP aber einen Meeting beitreten (Meeting-Jopin), dann sendet der Client eine erste Meldung ab. Diese Meldung hat noch nichts mit dem eigentlichen "InCallQoE" zu tun sondern zeigt nur am Beginn einer Konferenzteilnahme, wie lange der Join gedauert hat. Es ist dennoch schon eine interessante Meldung zur Messung von Performance und was die Anwender fühlen.
Hier noch mal eine andere Meldung in Textform für Google und Co.
SERVICE sip:User1@uclabor.de SIP/2.0 Via: SIP/2.0/TLS 192.168.102.62:52580 Max-Forwards: 70 From: <sip:User1@uclabor.de>;tag=a4cc7e1d30;epid=b6c76ccc34 To: <sip:User1@uclabor.de> Call-ID: xxxx CSeq: 1 SERVICE Contact: <sip:User1@uclabor.de;opaque=User:epid:vNBEMOBCTFycA3OEXHBIGQAA;gruu> User-Agent: UCCAPI/16.0.8730.2046 OC/16.0.8730.2127 (Skype for Business) Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="3A296369", targetname="BLU2A05FES02.infra.lync.com", crand="3905c628", cnum="30", response="xxxx" Content-Type: application/msrtc-reporterror+xml Content-Length: 1047 <reportError xmlns="http://schemas.microsoft.com/2006/09/sip/error-reporting" > <error toUri="Unknown" callId="xxxx" fromTag="xxx" toTag="xxx" requestType="INVITE" responseCode="200" > <diagHeader>51027; EscalationType="MeetNow" ;SpeakersConfiguredLyncState="1" ;SpeakersConfiguredWindowsState="Active" ;MicConfiguredLyncState="1" ;MicConfiguredWindowsState="Active" ;InRemoteSession="0" ;IsAnoymousJoin="0" ;AvailablePhysMem="1400 MB" ;UsedPhysMem="6488 MB" ;AvailableVirtualMem="1011 MB" ;UsedVirtualMem="1036 MB" ;MajorOSVersion="10" ;MinorOSVersion="0" ;HrErrorCode="0x0" </diagHeader> <progressReports> <progressReport> <diagHeader>51028;FocusJoinTimeMsecs="1500"</diagHeader> </progressReport> <progressReport> <diagHeader>51029;MediaJoinTimeMsecs="3703";call-id="xxxx";from-tag="4a6f95aa8c";to-tag="34796813f6"</diagHeader> </progressReport> </progressReports> </error> </reportError>
SIP Service während einer Audio-Verbindung
Durch die Aktivierung von InCallQoE sendet der Client in den eingestellten Intervallen eine Statusmeldung per SIP an den Skype for Business Server, die auch im UCCAPILOG des Clients protokolliert wird. Suchen Sie einfach nach:
Content-Type: application/vq2midcall-rtcp+xml
Die XML-Version finden Sie auch in der UCCAPILOG-Datei, wen Sie nach "INFO :: Qoe media line: " suchen
Sie finden eine sehr umfangreiche XML-Information: Diese Meldung hier bezieht sich auf eine Konferenzverbindung und ist etwas mehr als 6kbyte groß
Der Datensatz sieht dem klassischen QoE-Datensatz sehr ähnlich. Vergleichbare Meldungen kommen auch bei einem Voice-Anruf. Hier die Meldung nach 35 Sekunden eines "Telefonats" von Skype for Business zu einem Mobiltelefon. Sie ist deutlich umfangreicher und mehr als doppelt so groß wie die Konferenz-Meldung (16kB statt 6kB)
Da stehen schon sehr viele Daten drin, die für eine Verkehrsplanung, eine Echtzeitanzeige und andere Dinge interessant sein könnten. Insbesondere auch die Route der Pakete bei aktivierter TraceRoute-Option. Allerdings sehen Sie hier auch, dass diese Daten auch hinsichtlich des Datenschutzes zu betrachten sind.
Soweit ich gesehen habe, sendet mein Client diese Meldung einmal nach der eingestellten Zeit (35 Sek) aber dann nicht wieder.
Auch Skype for Business Online hat den TraceRoute aktiv
SIP Service am Ende des Call
Wenn eine Verbindung ordentliche und geplant beendet wird, sendet jeder kompatible Endpunkt bei vorhandener Monitoring-Rolle eine Schlussmeldung an den Frontend. Sie können diese einfach über eine Textsuche nach folgender Zeit in den lokalen UCCAPILogs suchen.
Content-Type: application/vq-rtcpxr+xml
Eine Meldung kann dann wie folgt aussehen. Diese landet in der QoE (Monitoring und CDR) Datenbank für spätere Auswertungen:
Diese Meldung kann natürlich nur versendet werden, wenn der Client "geplant" die Verbindung beendet hat. Sollte der Client während des Calls die Verbindung verlieren, was bei WLAN oder UMTS/LTE durchaus möglich ist, dann geht diese Meldung verloren.
Auswertung von InCallQoE
Alle Mitschnitte habe ich auf einem Client mit aktiviertem UCCAPILOG generiert. Über die auf der Seite Keyhole-Debugging beschriebenen Wege können Sie als Anwender schon diese Daten auslesen und auswerten. Ok, der normale Anwender kann das natürlich nicht. Als Administrator kommen sie aber üblicherweise nicht an den Client heran, so dass Sie nur auf dem Server diese Pakete abgreifen können.
Sie haben sicher gesehen, dass alle Pakete einfache "SIP SERVICE"-Pakete sind, die man per Skript auf dem Server natürlich abfangen könnte. Allerdings müssen Sie sich diese Arbeit gar nicht machen, da Microsoft die Schlussmeldungen am Ende eines Anrufs schon mal in die eigne QoE-Datenbank überführt.
Die Komponente SDN - Software Defined Networks fängt mit dem SDN - Lync Dialog Listener (LDL) alle interessanten Pakete auf dem Frontend Server ab und meldet diese an den SDN - Lync Link LDL->LDM. An dieser Stelle können Sie nun die Daten einfach abgreifen.
Cloud und Teams
Wenn Sie sich die SIP-Traces genau anschauen, dann sehen Sie natürlich das Ziel: Der Client sendet die Information per TLS verschlüsselt an den Homeserver. Wenn Sie aber nun Skype for Business Online nutzen, dann haben Sie die SDN-Daten natürlich in der Cloud. Microsoft stellt dort auch entsprechende Dashboards zur Anzeige bereit.
Diese Reports gelten für Teams und Skype for Business
- Announcement: Skype for Business Online
Call Quality Dashboard updates (April 26th
2017)
https://techcommunity.microsoft.com/t5/Skype-for-Business-IT-Pro/Announcement-Skype-for-Business-Online-Call-Quality-Dashboard/td-p/65127 - Dimensions and measures available in
Call Quality Dashboard
https://docs.microsoft.com/en-us/SkypeForBusiness/using-call-quality-in-your-organization/dimensions-and-measures-available-in-call-quality-dashboard - CxdCallData
https://www.powershellgallery.com/packages/CxdCallData/1.1.4.0
Weitere Links
- SDN - Software Defined Networks
- QoE (Monitoring und CDR)
- Parse-UCCAPILog.ps1
- Keyhole-Debugging
- ClientLogParser
- BYE-Telemetrie
- Lync Client Policies
- MSXFQ: INcall QoE Auf die SDN Seite addieren
https://www.msxfaq.de/skype_for_business/technik/lyncqoe.htm - Configuring InCallQoE Messages
https://msdn.microsoft.com/en-us/library/office/mt654029(v=office.16).aspx - In-Call QoE Reports in Skype for Business
http://ucken.blogspot.de/2015/07/in-call-qoe-in-skype4b.html - How to get InCallQuality message with Lync SDN 2.1
https://social.msdn.microsoft.com/Forums/office/en-US/d0bdd695-8a02-4761-8100-1caf03008728/how-to-get-incallquality-message-with-lync-sdn-21?forum=ucmanagedsdk - Skype for Business SDN API 2.4.1 installation and configuration guide
https://gallery.technet.microsoft.com/lync/Skype-for-Business-SDN-API-26d2484a - Enabling QoS in Lync Server 2013 for devices that are not
based on Windows
https://technet.microsoft.com/en-us/library/jj204750%28v=ocs.15%29.aspx - Enabling quality of service in Lync 2013 deployment
https://uctales.blogspot.de/2014/04/enabling-quality-of-service-in-lync.html - Configuring InCallQoE Messages
https://msdn.microsoft.com/en-us/library/office/mt654029(v=office.16).aspx - In-Call QoE Reports in Skype for Business
http://ucken.blogspot.de/2015/07/in-call-qoe-in-skype4b.html - How to get InCallQuality message with Lync SDN 2.1
https://social.msdn.microsoft.com/Forums/office/en-US/d0bdd695-8a02-4761-8100-1caf03008728/how-to-get-incallquality-message-with-lync-sdn-21?forum=ucmanagedsdk - Skype for Business SDN API 2.4.1 installation and
configuration guide
https://gallery.technet.microsoft.com/lync/Skype-for-Business-SDN-API-26d2484a - Capturing Network Traceroutes in Lync/Skype for Business
http://ucken.blogspot.de/2015/10/capturing-lync-sfb-traceroutes.html