Lync QOE means “Quality of Experience”. This comes up occasionally and there are many tools to troubleshoot this issue. I do have a very commonly overlooked fix you should review. 1) If your VPN is connected to your laptop and you make a call, using Lync, there is a good chance your call will be lousy in quality. Unless your Network is setup for split tunneling, Lync media flow will go through the VPN tunnel. Here is the common scenario I see:
1, You working from home
2. You are logged into your work VPN, getting mail or planning a call.
3. You login to Lync
4. You make the call with Lync.
5. No one can hear you, or you keep cutting out.
The issue here is your Lync client will use the VPN tunnel, for media, double encrypting the call. This makes for lousy quality. Now here is a scenario that may work, if you need to access your email on the call:
1. Working from home, Logout of your VPN.
2. Log into Lync.
3. Make your Lync Call.
4. Login to the VPN after the call is connected.
5. Use your email
The difference here is the call is already established. This is a small difference, but it is enough to allow you to work on your VPN and Lync, at the same time. Again, Split Tunneling, Network Segmentation, or Call Access Control are other components may need to be configured, to solve this issue completely. However, if you are the user, and your IT department has not fixed this issue, you should be aware of the work around. Please let your IT department know this is annoying, and ask them to call for support to diagnose this issue, and fix it as soon as possible.
If I am the IT department What thresholds do I look for?
I wanted to get these numbers together on one page so I could refer back to them. Below Please find the definition of a “slow Lync call”. Below find the components of the Quality of Experience (QUE) metric “ClassifiedPoorCall”. This is described in the Technet article here. Oddly enough, this flag is part of the Media Line Table, But it does not show in the documentation. To me, this means this information may become hard to find. These will change, over time, I am sure. However, It should give you some way to quantify the call in your own terms, using some relativity to these numbers.
Audio Streams
DegradationAvg ->> greater then 1.0
RoundTrip > 500
PacketLossRate > 0.1
JitterInterArrival > 30
RatioConcealedSamplesAvg > 0.07
Video Streams
VideoPostFECPLR > 0.1
VideoLocalFrameLossPercentageAvg > 10
VideoPacketLossRate > 0.1
OutboundVideoFrameRateAvg < 10
AppSharing Stream
RDPTileProcessingLatencyAverage > 400
RelativeOneWayAverage > 1.75
I hope this helps someone. There are many tools to calculate all of this. with third party tools becoming more and more common. However, If you need to baseline, This list above is good to compare with. In terms of tools, the client side issues have a great Lync Pre-Call Diagnostics tool. This is a great tool to use. Information about this troubleshooting tool is located at TechNet. The server side tool called the “Lync Tripp Tool, is also very good to see if your network is capable of getting good numbers to the Office 365 service, in the cloud. This effectively tests your network.
There are also some new Network Assessment tools coming out, as well as defined MS curriculum and specifications. The network is our number one concern, as Lync Deployment and Design personnel. The health of your network will dictate the reliability and Experience, your customers and employees will have. We take pride in how Lync sounds better then the PBX in voice quality. The bottom line is don’t scrimp out. Buy some new network equipment with the money your saving when you move over to Lync 2013!
In Conclusion, I hope this is helpful in giving some client and server side tools to look at, review, test and fix your slow call problem. I didn’t go into the call logging aspect of this process. I have other posts about that. I simply showed you canned tools, which are readily available, which do not require any special voice knowledge to use. they can be very powerful, and they don’t require hours of squinting at log files.
Louis
