How to Ensure High-Quality Voice and Video Streaming With QoS

 Originally published on February 20, 2017 by Kimberley Parsons Trommler
Last updated on January 23, 2024 • 10 minute read

QoS (Quality of Service) and QoE (Quality of Experience) are important criteria for network applications that require real-time streaming, such as online videos or VoIP (Voice over IP). User acceptance depends on high call and video quality.  And your job, as the system administrator responsible for these systems, is to ensure this quality.

You need to plan and operate streaming technologies in a complex environment of applications, mobile devices, fixed devices, servers, and the underlying network.  In addition to carefully designing your environment to meet the challenges of real-time streaming, you need effective monitoring tools to keep track of what's going on.  You don't want to be working blind when your CxO calls to complain about call quality.

But why is it so difficult to stream video or voice over standard LAN and WAN networks? The classical telephone network is over 100 years old and offers much better quality than IP networks. 

Why can't the IP network, which is much newer, provide even better quality than the old telephone network?

Connection-Oriented Versus Connectionless Networks

The answer lies in the fundamental design decisions that underlie the two networks. The telephone network is a "connection oriented" network. That is, when you place a call, the phone system reserves an end-to-end connection for your call, and maintains the end-to-end connection for the entire duration of the call. You have a guaranteed connection and guaranteed reserved bandwidth for the entire call.

Two Telephones

IP-based data networks, on the other hand, were never designed to carry real-time traffic. They were designed to transfer data reliably, even when parts of the network fail, and to find alternative routes around failures. The goal was to ensure that packets do eventually arrive, but there is no guarantee that the packets arrive in the same order they were sent, nor that they arrive within a certain timeframe.

IP networks are inherently "connectionless". That is, they don't set up or maintain an end-to-end connection, at least not at the IP layer. Each individual data packet takes its own route through the network, and packets can arrive at the destination in a different order than they were sent, and with differing travel times. This is fine for data traffic such as email or web pages, because they aren't sensitive to delays or out-of-order delivery. For voice or video, however, packets arriving out-of-order or at different speeds is a disaster-you can't understand what the person is saying anymore.  


So, to transmit high-quality voice/video over an IP network, you need to use additional mechanisms at other layers in the OSI model. TCP, for example, is connection-oriented, so it initially seems like a good choice for VoIP.  However, while TCP sets up a connection between the two end points, it also prioritizes accuracy over speed: the packets will arrive in the correct order, but they could be seriously delayed.  This leads to jitter in the network, which means very choppy speech in your call.

UDP, unlike TCP, is connectionless, which initially makes it seem like a poor choice for VoIP.  However, since UDP doesn't have the overhead that TCP does, it delivers packets much faster, although it might deliver packets out-of-order or not at all. While it seems counterintuitive, this is actually better for voice quality than TCP: humans deal with dropped packets (a tiny bit of missing information) better than with jitter (choppy voice).

But we see that neither TCP nor UDP alone can guarantee good voice quality. This is where QoS settings on your network devices come into play.  Different techniques and protocols are available to prioritize voice traffic over data traffic, and you may need to use one or more of these to ensure acceptable voice quality in your network. As you implement QoS methods, be sure to monitor your network before, during and after changes to your QoS settings, to ensure that your changes are effective.

How Can You Measure Quality for Streaming?

The most important quality metrics for video and VoIP are delay, jitter, and MOS:

  • DELAY (also called LATENCY) is the length of time it takes for a packet to get from Sanduhrthe sender to the receiver. In a LAN, delay is usually very small, but over a WAN or the Internet, delay can be so long that you need to wait a few seconds before you hear anything. When you see newscasts from war zones, where the reporter waits a few seconds before answering, that's delay at work! The reporters are usually connected via satellite, which has high bandwidth but very long delay. Long delay times mean poor video/voice quality, and they make live interaction very frustrating.    
  • JITTER is a measure of variation in the delay. That is, jitter measures how consistent the delay is: Do all packets have a similar delay (low jitter), or are some packets fast and some packets slow (high jitter)? Voice and video streaming require low jitter, otherwise the quality is very choppy.
  • MOS, the Mean Opinion Score, is a measure of how humans perceive the quality of the network, and it's often used as the single overall benchmark of quality for a VoIP call. Since you can't set up an army of humans to judge the quality of each call, MOS is calculated using a combination of the number of lost packets in percent, the average delay, the average jitter, and an R-value which expresses the subjective quality of the connection.

Monitor Before, During and After

If you're planning to implement VoIP or video streaming in your network, you should measure these parameters in your network ahead of time, so you know if your network is going to be able to handle the voice/video or not.  If not, then you can plan upgrades and/or additional QoS protocols before you roll out VoIP, to avoid costly emergency upgrades afterwards. A good monitoring tool acts as an early warning system to ensure smooth operation before, during and after rollout.

Want to Know More?

To read:

To watch: