Microsoft Lync Call Quality Factors

Microsoft Lync Call Quality Factors

If you are using a VoIP phone system (any platform), there is a good chance you have experienced poor call quality. Is this statement true? My personal experience of a decade into communications world, says something else. In my opinion, if the deployment is done with holistic understanding of product and considering various factors which determine call quality, then there is extremely remote chance of users experiencing poor call quality.

Many Lync customers complaint about the call quality issues. When they try to connect to a Lync conference or make a peer to peer call, the audio or video quality may be choppy, tinny, or delayed. Ever wondered what could be the contributing factors? In this article, we would try to understand such factors which play an important role in determining Lync call quality.

Call Quality Factors

 

Codec

Codec is hardcoded in Microsoft Lync. You don’t get option to choose options for any of the call scenarios. Peer-to-peer audio calls between Lync endpoints will use either RTAudio (8kHz) or RTAudio (16kHz) when you factor in the bandwidth and prioritization of codecs. Conference calls between Lync endpoints and the A/V Conferencing service will use either G.722 or Siren. Calls to the public switched telephone network (PSTN) either to or from Lync endpoints will use either G.711 or RTAudio.

The TechNet Article http://technet.microsoft.com/en-us/library/jj688118.aspx talks about the bandwidth requirements for various codecs.

Since you can’t chose the codec for any call scenario, it’s suggested that you understand the bandwidth requirement of various codecs, and plan your network accordingly.

Packet Loss

Packet loss causes the audio quality to be distorted at the receiving end. A general guidance to follow on whats acceptable and what’s not!

< 3% is considered good

> 5% impacts audio

> 7% is not good (some consider +7% packet loss “huge”)

> 10% & above is bad or worse

 

Latency

Lower the latency, better the quality would be. Let’s take a look of general guidance around it.

For RTP packets as reported in the monitoring reports:

< 200 ms is good

> 200 ms is poor

> 500 ms is bad

For basic UDP packets used by the ping command line:

< 100 ms is considered decent

> 150 ms is considered problematic

 

Jitter

Jitter (ms) measures the variability of packet delay and results in a distorted or choppy audio experience. Jitter can increase latency on networks.

< 20 ms is good

> 30 ms is avergae

> 45 ms is not acceptable

 

QoS

Microsoft Lync audio traffic is passed on the network together with the rest of the data. As a result, the audio packets are sharing the same network resources with the other data packets (browsers, mail, applications etc). This results into degradation in the audio quality.

The solution for this known problem is to use QoS in the network. This specifies that audio packets are getting precedence over data packets. If you ask me what is the ideal scenarios… my answer would be pretty simple… use two different networks – one for audio and one for data.

Non Optimized Devices

Microsoft runs a program to qualify phones and devices for Lync. These devices are optimized for Lync and go through rigorous audio quality testing to ensure that you experience good audio quality. Non-optimized devices may exhibit inferior audio quality caused. We always suggest our client to use the optimized devices instead of non-optimized ones. You can find qualified list of phones & devices here… http://technet.microsoft.com/en-us/office/dn788944

HW/SW Specifications

Many times the availability and performance of CPU, memory, desk etc determine the call quality. It’s always strongly recommended to use the Microsoft recommended HW specifications for servers and clients.

 

Additional Resources

Devcentrics: http://devcentrics.com/

Lync Call Quality Methodology poster: http://www.microsoft.com/en-in/download/details.aspx?id=41698

Troubleshooting Lync Call Quality Locally with Snooper: http://blogs.technet.com/b/nexthop/archive/2012/12/10/troubleshooting-call-quality-locally-with-snooper.aspx