Imagine that you are a car manufacturer. Of course I am talking about Ford. You have a meeting with the county and they determine that they will do no more road maintenance because they cannot afford to pay inspectors to review the integrity of the roads. Unless you’re a real man and drive a Ford Pickup Truck this is horrible news. Fairly soon the road will have so many pot holes that driving a car will become very difficult and unpleasant.
Your users will no longer enjoy taking drives in their cars. Car sales will fall off and you will soon be laying off all of your employees. Users will go back to using your competitor’s products; horse and buggy, motorcycle, walking, etc.
You have two options:
- Explain to your users that it is the county’s fault for not monitoring their roads.
- Now imagine that you make a deal with the county. Since your employees travel down the county roads every day, you will have your employees provide feedback to the county when they find a pot hole. Then the county can dispatch a maintenance crew to repair that specific area of the road. You do not need to shut down your factories and lay everybody off. Users are happy again.
It’s a win-win situation.
Hopefully you can see where I am going with this. You need to use the Skype monitoring reports, especially the location report, to let the networking team know what the issue is and the IP addresses of the end points that experienced the issues.
Skype is the canary in the coal mine. (Shout out to our President for putting our coal miners back to work.) Real time Audio and Video will find every little issue with the network. Providing this information to the networking team will help everybody involved.
Key network issues that affect Skype:
Packet loss: I have seen the following cause this
- Quality of Service (QoS). This is very common when QoS is configured properly on Skype and the OS but not properly configured on the internal network or the ISP’s network. I have found with Verizon that they have a service called Gold Car where they expedite all traffic in the EF queue. However, if the customer’s network equipment is putting Audio packets in the EF queue but Gold Car is not configured on the Verizon circuit, all of the audio packets are dropped.
- Congestion on the network. There just simply is not enough bandwidth to handle all of the demands. Packets will be dropped.
- Maxim Transmission Unit (MTU) size mismatch. The maximum size of the packets is set on the computer and the network equipment. If the computer is using a larger packet size than the network equipment then those packets must be fragmented, often leading to Packet drops. A common issue is when the MTU size is set differently at remote locations than it is at the datacenter.
Jitter: I have seen the following cause this:
- Congestion on the network.
- MTU size mismatch
- Jitter buffer http://searchunifiedcommunications.techtarget.com/definition/jitter-buffer
Latency: When it takes the packets too long to get from point A to point B the quality of the audio and video will be significantly degraded.
- When dealing with international organizations the distances between locations can be too great to get the packets to their destination in a timely manner.
- Routing. I have seen many cases where routing was not properly configured to use the most efficient path for the packets. You can provide evidence of this to the networking team by doing a trace route between the end points and providing the screen capture of the results.
I have saved screen shots of trace routes to my key locations, when all is well, so that I can compare them to new trace routes when I suspect a routing issue. It is not uncommon for the route to change as network equipment goes offline. Also Performance based routing can cause a route change.
The maximum latency that Microsoft considers acceptable for Skype Audio and Video is 150ms per direction. Meaning that for an A/V conference there should be no more than 150ms from the client to the server and 150ms from the server back to the client.
I have built a good relationship with my networking teams at most of my customers. There was one that no matter how nice I was they hated me because my application was using their bandwidth and I wouldn’t allow them to perform deep packet inspection on traffic to and from the Edge servers.
At my current customer I have almost daily meetings with the network team to explain where there are possible issues. This makes things much better for the users, rather than me complaining about the network and doing nothing of value.
Working with the closely with the networking team we have reduced the poor call quality from 40% to below 1%.