Share via

What is the basis for classifying a call as poor in Lync 2013 QoE?

  • Article

In Lync 2013 we changed how we classify poor calls in QoE. The flag is called ClassifiedPoorCall and it is now available in the MediaLine table. It is moved here, because we now support classifying poor calls for audio, video and application sharing. We use the same classification in Skype for Business 2015.

The conditions we use to classify poor calls are shown in the 3 tables below. The poor call flag is set if one or more the conditions are met. Please note that a record in the MediaLine table can cover multiple media streams. The flagging occurs on the MediaLine level, so if you want to understand specifically which stream was the reason for the classification you need to look at the individual streams and use the columns in the tables below.

Column in AudioStream Table

Condition

Explanation

DegradationAvg

> 1.0

Network MOS Degradation for the whole call. This metric shows the amount the Network MOS was reduced because of jitter and packet loss

RoundTrip

> 500

Round trip time

PacketLossRate

> 0.1

The packet loss rate

JitterInterArrival

> 30

Average network jitter

RatioConcealedSamplesAvg

> 0.07

Average ratio of concealed samples generated by audio healing to typical samples

 

Column in VideoStream Table

Condition

Explanation

VideoPostFECPLR

> 0.1

The packet loss rate after forward error correction has been applied

VideoLocalFrameLossPercentageAvg

> 10

The percentage of total video frames that are lost

RecvFrameRateAverage

< 7

Average video frame rate used by the receiver

LowFrameRateCallPercent

> 10

Percentage of the call below the low frame rate threshold

VideoPacketLossRate

> 0.1

The packet loss rate

InboundVideoFrameRateAvg

< 7

The average video frame rate received during the call

OutboundVideoFrameRateAvg

< 7

The average video frame rate sent during the call

DynamicCapabilityPercent

> 10

Percentage of the call where the client experienced high CPU load when processing video

 

Column in AppSharingStream Table

Condition

Explanation

SpoiledTilePercentTotal

> 36

This value is the percentage of the content from the sharer that did not reach the viewer. Content may be discarded (or spoiled) when the sharer discards tiles from the graphics source or the ASMCU tiles discards tiles from Sharer respectively.

RDPTileProcessingLatencyAverage

> 400

Acceptable value of the average RDP tile processing latency in the AS Conferencing Server over the duration of the viewing session

RelativeOneWayAverage

> 1.75

Optimal value for the relative one-way delay between the two media endpoints involved in the application sharing. This is a single-hop latency measure

Comments

  • Anonymous
    January 01, 2003
    Thanks for the article, quite informative. With the generally adopted value of 150ms max RTT for an optimal VoIP call, isn't the >500ms roundtrip value a bit generous? Jens>Hi Alessio. You might be right, but for now we are sticking with 500 ms.

  • Anonymous
    March 15, 2014
    Thank you. Great to know!

  • Anonymous
    June 12, 2014
    Pingback from If your looking to ramp on Lync On Premises here are some useful Lync resources well worth investigating

  • Anonymous
    December 11, 2014
    En ocasiones hemos tenido casos reportados de pérdida de audio o video durante comunicaciones

  • Anonymous
    July 30, 2015
    The 500ms rating is for RTP, while the commonly accepted 150ms is for UDP packets, seen as testing with PING.