Author: Rob Pitfield

Publication date: December 2008

Product version: Office Communications Server 2007 R2

Once the QoE Service is installed and associated with a pool and Mediation Server it should start getting statistics.  You’ll also need to exit Office Communicator or the Live Meeting clients and sign in again to ensure the changes take place. If you don’t see any data being written to the database there are several things you can check to make sure all is working as expected:
Whenever a device or client logs in, they get information sent down via inband provisioning (in SIP traffic) which makes them aware of a QoE Server:
<qosUri>sip:QOE.domain.com@domain.com;gruu;opaque=srvr:QoS:h6pN5zNPUUeVKT66Y_obawAA </qosUri>

To find this information you can enable logging in Office Communicator by selecting the “Turn on logging in Communicator” checkbox under Tools -> Options and then selecting the General tab.

Once you’ve enabled logging, sign into Office Communicator and then search for the string qosUri in the Communicator-uccp log file. The log is located in %userprofile%\tracing\ on the client machine.  You can open it in Notepad or download the Snooper tool (part of the OCS 2007 Resource Kit). 

Once you see the <qosUri> you can be sure that the pool you’re logging into is associated with the QoE server listed.  If you don’t see that, check your QoE Server and ensure that it’s associated with the pool you expect it to be by either checking the Monitoring Status information for Pool Associations and Mediation Server Associations or running the QoE Monitoring Server Configure Associations Wizard in the QoE MMC.

Once you’ve checked that and all appears well you can check to see if your clients are sending QoE Reports after finishing calls.  Whenever a client who is enabled for QoE hangs up a call it sends a QoE Report to the OCS Front End Server via a Service request that looks like this:

10/03/2008|09:41:53.558 E2C:1038 INFO  :: Sending Packet – 192.168.2.1:5061 (From Local Address: 192.168.2.2:55478) 4747 bytes:
10/03/2008|09:41:53.558 E2C:1038 INFO  :: SERVICE sip:OCSPool.domain.com@domain.com;gruu;opaque=srvr:QoS:clfJSBfVcUKdlDLYM5Ej9QAA SIP/2.0
Via: SIP/2.0/TLS 192.168.2.2:55478
Max-Forwards: 70
From: <sip:joe@domain.com>;tag=03d35603d9;epid=c34fae5c3d
To: <sip:OCSPool.domain.com@domain.com;gruu;opaque=srvr:QoS:clfJSBfVcUKdlDLYM5Ej9QAA>
Call-ID: f590839c3b7042fb89a0a3803e0ead7b
CSeq: 1 SERVICE
Contact: <sip:joe@domain.com;opaque=user:epid:-WjXg6bFul6b39g5ZrJ10gAA;gruu>
User-Agent: UCCAPI/2.0.6789.0 OC/2.0.6789.0 (Microsoft Office Communicator)
Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="942056C3", targetname="OCSserver.microsoft.com", crand="15dd1df5", cnum="375", response="01000000a00000009ce2b5c67d6b9a06"
Content-Type: application/vq-rtcpxr+xml
Content-Length: 3881

<?xml version="1.0"?>
<VQReportEvent xmlns="ms-rtcp-metrics"><VQSessionReport SessionId="e482f6b3e3ca44b4adb7db50383749f9;from-tag=001ef1887e;to-tag=9dbb7915c"><Endpoint Name="computer.domain.com"/><DialogInfo CallId="e482f6b3e3ca44b4adb7db50383749f9" FromTag="001ef1887e" ToTag="9dbb7915c" Start="2008-10-03T14:41:46.0654Z" End="2008-10-03T14:41:53.0428Z"><FromURI>sip:joe@microsoft.com</FromURI><ToURI>sip:+14692351836@microsoft.com;user=phone</ToURI><Caller>true</Caller><LocalContactURI>sip:joe@domain.com;opaque=user:epid:-WjXg6bFul6b39g5ZrJ10gAA;gruu</LocalContactURI><RemoteContactURI>sip:mediationserver.domain.com@domain.com;gruu;opaque=srvr:MediationServer:NbvuggL1N0i2cpeLZHbjHAAA;grid=ab2be358af684f39a59b534d599bb00c</RemoteContactURI><LocalUserAgent>UCCAPI/2.0.6789.0 OC/2.0.6789.0 (Microsoft Office Communicator)</LocalUserAgent><RemoteUserAgent>RTCC/2.0.0.0 MediationServer</RemoteUserAgent></DialogInfo><MediaLine Label="main-audio"><Description><Connectivity><Ice>DIRECT</Ice><IceWarningFlags>327680</IceWarningFlags></Connectivity><Security>SRTP</Security><Offerer>true</Offerer><Transport>UDP</Transport><NetworkConnectivityInfo><NetworkConnection>wired</NetworkConnection><LinkSpeed>1000000000.000000</LinkSpeed></NetworkConnectivityInfo><LocalAddr><IPAddr>192.168.2.1</IPAddr><Port>50028</Port><Inside>true</Inside><SubnetMask>255.255.255.0</SubnetMask></LocalAddr><RemoteAddr><IPAddr>192.168.2.3</IPAddr><Port>63344</Port></RemoteAddr><CaptureDev><Name>Microphone (High Definition Audio Device)</Name></CaptureDev><RenderDev><Name>Speakers (High Definition Audio Device)</Name></RenderDev></Description><InboundStream Id="1295251570"><Network><Jitter><InterArrival>5</InterArrival><InterArrivalMax>6</InterArrivalMax></Jitter><PacketLoss><LossRate>0.004762</LossRate><LossRateMax>0.009524</LossRateMax></PacketLoss><BurstGapLoss><BurstDensity>0</BurstDensity><BurstDuration>0</BurstDuration><GapDensity>0</GapDensity><GapDuration>3360</GapDuration></BurstGapLoss><Utilization><Packets>234</Packets></Utilization></Network><Payload><Audio><Signal><SignalLevelLoudSpeaker>-19</SignalLevelLoudSpeaker><SpeakerGlitchRate>0</SpeakerGlitchRate><SpeakerClipRate>0</SpeakerClipRate><RxAGCSignalLevel>0</RxAGCSignalLevel><RxAGCNoiseLevel>0</RxAGCNoiseLevel></Signal></Audio></Payload><QualityEstimates><Audio><NetworkMOS><OverallAvg>2.950000</OverallAvg><OverallMin>2.950000</OverallMin><DegradationAvg>0.000000</DegradationAvg><DegradationMax>0.000000</DegradationMax><DegradationJitterAvg>0.000000</DegradationJitterAvg><DegradationPacketLossAvg>0.000000</DegradationPacketLossAvg></NetworkMOS></Audio></QualityEstimates></InboundStream><OutboundStream Id="2363501468"><Network><Jitter><InterArrival>1</InterArrival><InterArrivalMax>2</InterArrivalMax></Jitter><PacketLoss><LossRate>0.000000</LossRate><LossRateMax>0.000000</LossRateMax></PacketLoss><Delay><RoundTrip>92</RoundTrip><RoundTripMax>166</RoundTripMax></Delay><Utilization><Packets>419</Packets></Utilization></Network><Payload><Audio><PayloadDescription>x-msrta</PayloadDescription><SampleRate>8000</SampleRate><Signal><SignalLevel>1286</SignalLevel><SpeakerFeedbackMicIn>-66</SpeakerFeedbackMicIn><SpeechLevelMicIn>-26</SpeechLevelMicIn><SpeechLevelPostProcess>-26</SpeechLevelPostProcess><BackGroundNoiseMicIn>-72</BackGroundNoiseMicIn><BackGroundNoiseSent>-64</BackGroundNoiseSent><LocalSpeechToEcho>40</LocalSpeechToEcho><MicGlitchRate>0</MicGlitchRate><MicClipRate>0</MicClipRate><RxAGCSignalLevel>0</RxAGCSignalLevel><RxAGCNoiseLevel>0</RxAGCNoiseLevel></Signal></Audio></Payload><QualityEstimates><Audio><SendListenMOS>2.840000</SendListenMOS><SendListenMOSMin>2.840000</SendListenMOSMin></Audio></QualityEstimates></OutboundStream><LocalConversationalMOS>-21474836.000000</LocalConversationalMOS></MediaLine></VQSessionReport></VQReportEvent>


10/03/2008|09:41:53.558 E2C:1038 INFO  :: End of Sending Packet – 192.168.2.1:5061 (From Local Address: 192.168.2.2:55478) 4747 bytes

It’s quite a bit of information.  It looks much prettier in the QoE reports on the SQL Server.  If you want to know more about the statistics collected, review the Office Communications Server 2007 Quality of Experience (QoE) Monitoring Server Audio and Video Metrics Processing Guide.  We’re trying to make sure the data is making it to the QoE Server.  If the client is sending this data (which again will be in the communicator uccp log) using Notepad or Snooper then the next place to check will be on the SIPStack log on the OCS Server.  In there you should see the server make a SIP MTLS connection to the QoE Server using TCP Port 5061 and forward the request over to the QoE Server.  If that’s successful then you’re home free.  If it’s not there are a few other things to look at:

  • In the QoE Management console select the relevant QoE Server. Click on the Performance Tab in the right pane.  Once selected there are a set of default counters that will help you quickly determine if reports are making it to the server.  If you’re unsure, try looking at LC:QMS – 00 QoEMonitoringServer and selecting “Total number of metrics reports received”, “Total number of metrics reports accepted” and “Number of rejected metrics reports”.  This will tell you if the server is getting any QoE Metrics reports and if the reports are valid.
  • If you don’t see any metrics reports making it to the QoE Server you can run a network trace on both the OCS Server and the QoE Server to ensure you’re seeing successful TCP Sessions from the OCS Front End Server to the QoE Server on TCP Port 5061.  Beware of firewalls between the machines or on them.
  • Ensure the OCS Front End Server and QoE Server both have valid certificates and that they both trust each other’s Certificate Authorities, as the connections between them are using MTLS.
  • Check DNS name resolution between the servers.
  • Check if the QMS Service is started.
  • Check Event viewer to see if there are any errors/warnings raised by QMS.
  • If you see the value of performance counter “Total number of metrics reports received”/” Total number of metrics reports accepted” is correct, but there is still no data in database you can check if there is something wrong with the MSMQ or database. Check the following:
    • Performance counter “Total number of MSMQ messages sent”. This indicates the number of reports that are written to MSMQ. If this is zero, usually it means there is something wrong with MSMQ. Check the Event Viewer for errors.
    • These performance counters: “Total number of message transactions completed”, “Total number of message transactions that failed”, “Total number of reports that were dropped due to database insertion failure”,  and “Number of MSMQ messages received with an incorrect type or version”.  These counters show if the reports are written to the QoEMetrics database or if the reports are dropped due to errors.
    • Finally, ensure the SQL Server is operating correctly and the QoEMetrics database is accessible.

Lync Server Resources

We Want to Hear from You