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

Weitere Links