Do I Want Quality of Service or Quality of Experience?Do I Want Quality of Service or Quality of Experience?
If we think about all the things that can go wrong on a phone call or on a video call, the list is much longer than just the IP-network transport.
January 14, 2009
If we think about all the things that can go wrong on a phone call or on a video call, the list is much longer than just the IP-network transport.
Quality of Experience (QoE) is a methodology that helps measure the actual experience of the user. The theory is that delivering packets across the network with low jitter and low loss is a good thing, and certainly contributes to good quality voice and video. But it may not be enough. The overnight delivery service might be able to get your sensitive package across the country quickly and reliably, but if the box was drop-kicked three times in the process and the contents are now broken, we really haven't met the users' goals. Let's look at how this applies to voice and videoconferencing.If we think about all the things that can go wrong on a phone call or on a video call, the list is much longer than just the IP-network transport. A phone call may be passing through carriers, IP trunks, gateways to the PSTN, the PSTN itself and back again on its way from speaker to listener. Along this path any number of transformations may take place that can affect the quality of the call. The QoS or CoS function I wrote about last week only ensures our packets get through the IP-portion of this network until we reach an IP termination.
Suppose we have the network diagram below. Voice traffic has to (right to left) cross an IP network, through a session border where it may be transcoded, across a SIP trunk, through a PSTN gateway and across the PSTN before reaching its destination.
If QoS is implemented, it is on the IP network. If it was done right, QoS will ensure that packets originating from the phone can get to the SBC with low loss and jitter. But suppose the original call is G.711 or even wideband, and the SBC transcodes the call into G.729 to save bandwidth on the SIP trunk. Then suppose that the PSTN gateway has poor echo canceling where it connects to the PSTN and the PSTN last mile has a signal-to-noise problem. By the time our high quality voice signal gets from speaker to listener there is not much quality left to listen to.
The classic approach to debugging a problem like this is to take measurements along the way. If we had a voice quality measurement capability at each of the yellow arrows, we could quickly see how the quality drops as it moves along the path and find the design or equipment failures that are degrading the quality of the voice.
There are a few vendors today who are providing tools that can do this job. They have to look inside the IP packets or the PSTN bits and reconstruct the audio signal. Then it has to be tested for voice quality, echo, signal-to-noise ratio and other characteristics to make an estimate of the end-user experience. By estimating the actual user experience along the path of the network, these tools can provide a very fast determination about which underlying network components or endpoint equipment components are causing the problem and lead to a speedy resolution.
Here are some interesting resources on QoE:
Psytechnics White Papers on QoE and Voice Quality
Microsoft on how the right Codec can overcome network issues
Apparent Networks on Three Classes of Measurement (QoS, QoA and QoE)
Telchemy Application Notes on Managing Voice QualityIf we think about all the things that can go wrong on a phone call or on a video call, the list is much longer than just the IP-network transport.
