Many, if not most, users who measure bandwidth as part of a VoIP assessment do so by running a speed test. The purpose of a bandwidth test is simply to assess whether a connection has sufficient resources to support the VoIP application because unlike data VoIP packets must arrive on time. This is like comparing your drive home from work to a drive to the airport to catch a flight. The latter requires you to be on time or the purpose of the journey fails.
The problem with running a speed test is that the data protocol does not care about time, it only cares about the data accuracy. To ensure accuracy the data protocol must therefore cater for data that does not arrive regardless of the reason. Because data integrity is paramount (imagine bank data for example, losing a decimal place could dramatically change the amount of a paycheck) the data throughput measure is not a valid measure for VoIP.
VoIP packets do not care about data integrity only arriving on time. That being said, what affects time? Delay. As human beings, we witness this every time we drive on the roads. If there is a lot of traffic we know that our journey will take longer. If we do not accurately factor in the delays of our journey it could cause us to be late. How should we measure bandwidth for VoIP applications? Well, it just so happens that traffic on the road is a very good starting point for several reasons.
First, it is fair to assume that if the road is empty of traffic then the time it takes to get to the destination (assuming the speed limit is obeyed) will be the fastest possible. There can be no delays due to traffic. For example, a journey on a 60mph road that is 10 miles long, will take 10 minutes, i.e. 1 mile per minute. As roads always have traffic, the question now becomes one of “will the amount of traffic that is using the 10-mile road cause me to be delayed?”. That is a tough question to answer. Can we test this?
Sticking with the driving analogy the ideal test would be to drive on the road to the destination while at the same time increasing the demand of traffic on the road. Such a test would quickly identify the delays that impact arrival time and by how much. An arrival time of >10mins means there is not enough bandwidth. The higher the number the bigger the problem. With that said there is still one further question, "how much bandwidth has to be consumed before my VoIP call quality becomes threatened?".
The good news is that VoIP has two inherent measurements, packet jitter (essentially the change in the time between consecutive packets) and packet loss (missing packets). To understand threats to VoIP quality, a VoIP bandwidth test must be able to increase bandwidth demand while at the same time ensuring that packet jitter, and packet loss, do not exceed what the service level agreement (SLA) is willing to tolerate.
The important test question to ask then becomes "what is the minimum amount of bandwidth required so large data packets and data applications do not aggravate jitter to a point where call quality fails?". Once this minimum bandwidth value is defined, configuring a test to measure to the minimum while ensuring jitter and loss do not exceed the SLA provides a perfect bandwidth test dedicated to VoIP quality. A speed throughput test is not up to the job.
MCS provides just this capability, so we advise pairing the test with a VoIP test to understand how viable VoIP is for a connection.
The MCS solution allows you to easily deploy a VoIP/Video assessment portal for your own business. A powerful API allows for endless scope in terms of how the portal is presented to your end-users. Data can be easily segmented and the highly customizable reporting system makes analyzing results easily.
Testing your connection will uncover the true user experience.
Browser-based assessment testing allows you to present a customized portal to your end-users, which allows them to assess their home or work connection.
Satellite technology. Utilize our powerful MCS Satellites (software and hardware) to create testing points across your network. Continuous testing can then be set up between any and all end-points.