Voice, Video and QoS
Voice, Video and QoS
The Internet was designed for computer traffic. This traffic has the characteristic of requiring to be error-free (and where an error will typically cause a retransmission of data or could corrupt the received data), and not that sensitive to delays. Overall, theInternet we have created has these characteristics, and where we might get congestion at busy times, but, we can often cope with a small delay in getting network traffic from one place to the next. A single bit in error, though, can cause a whole lot of problems. But, voice and voice, are different, and where they typically require low latency and a constant bandwidth. If a data sample from voice or voice does not arrive within good time, there is a chance that the data stream will drop or at least glitch.
At one time we would have separate communication channels for our voice and our data communications, but IP routing has proved so successful that we now mix them. And, so, we feed voice and video traffic along the same routes as our computer traffic, and where computer traffic can often burst onto the network and affect our real-time traffic. Along with this, we could have real-time critical data, such as monitoring a baby’s heart rate. This data must be error-free, and free of any errors, and it shouldn’t be swamped by either non-critical computer data, and less critical voice and video data.
So, unless we have fast networks for all of our interconnected devices, and lots of spare bandwidth, we need to understand how we can engineer our network infrastructure in order to cope with the mixture of computer data and real-time data. And, so, the basic profile we might have is:
Queuing and QoS
Our networks thus need to be set up to be able to cope with the differing requirements, and this is where QoS (Quality of Service) can be defined for our intermediate devices. These devices can be configured within their data queues to give priority to certain types of traffic, such as voice and real-time data traffic, and where other packets would wait for these to be serviced. It’s a bit like on a road, where a police car with flashing lights would be waved on at a junction, while the other cars will have to wait for it to pass.
Sampling rates and bandwidth
At the basis of voice and most other analogue communication methods is its conversion into a digital form. Along with this, we must sample the signal. It was Nyquist who defined that this sample rate needs to be at least twice the highest frequency of the signal. And, so, since telephone quality voice has a maximum frequency of 4kHz, we often sample at 8,000 times per second. If we use a 12-bit sample, and then compress it to 8 bits, we get the magical base rate of 64kbps. This is often the baseline we need to reserve for our voice communications. As voice samples do not change that much between samples, we can also use a difference method to transmit just the difference between two samples. This is known as differential encoding, and can significantly reduce the required bandwidth. A well-defined standard for this is MP3 encoding.
For video, we now often use frames for our video, and where one overall frame is sent (an I-frame), and then we just send the difference between that and the next frame (a P-frame) for a few samples, and then go back to sending another full image, and so on. A well-defined standard for this is MP4 encoding. Again, for video, we need to understand the requirements for QoS, in order that computer traffic does not burst onto the network, and swamp the video stream.
And, so, how is this configured? Well, I have created a number of challenges and tests related to voice and QoS, here: