Based on their opinions a Mean Opinion Score (MOS) metric was defined. Moreover,
ITU also has defined different methods by which voice quality can be measured and
matched to the original MOS values. The main methods are described in this section.
There are two ways to evaluate voice over IP, subjectively and objectively. A subjective evaluation is carried out into the way actual audio is transmitted between ends, and a group of people provide an opinion on what they believe is the quality. In contrast,objective evaluation is based on the measurements of key metrics of the transmitted data.
1 Subjective Evaluation Methods
Subjective evaluations provide the closest look at actual end user experience. Since
users actually listen to audio samples they can provide their own personal opinion. In general, subjective evaluations are very useful and are required to some extent even if quality has been evaluated with objective methods. However, carrying out subjective tests is not straightforward. Users must be carefully selected in order to provide a real idea of what the end user might be. Likewise, because humans make the grading in subjective tests, the repeatability is very difficult. If a subjective model is to be followed, ITU P.800 provides recommendations for carrying out this kind of evaluation.
2 Objective Evaluation Methods
Objective evaluation methods are based on measurements of key metrics of the
transmitted data. Although they do not involve individuals, they are very useful because of their repeatability. The main two objective evaluation methods for VoIP have been developed by ITU and are the following:
The E-Model (ITU-T 2003) is a voice quality evaluation model that is based on network
performance metrics. It is based on a mathematical algorithm and provides an “R”
performance value based on the sum of four “impairment factors” considered to be
cumulative. The algorithm is depicted in equation (1) where, “Is” is voice impairments to the signal, “Id” is delay (ms), “Ief” is packet loss impairment, and “A” is the expectation factor.
R = 100 - Is - Id - Ief + A
In practice, ITU-T proposes to use a simplified version of this algorithm. The simplified algorithm considers that noise cancellation is encountered in the network and also dismisses the expectation factor. The expectation variable is intended to provide a balance for some environments in which the user expects a degraded quality, such as satellite connections. However, since this variable is merely subjective it is recommended to ignore it. The simplified algorithm is depicted in equation (2).
R = 93.2 - Id - Ief
While this method is well suited for circuit switched communications and systems in
which delay is small and constant, it is not suitable for transmission systems with delay variations such as wireless networks. The reason is that the PESQ model does not consider delay. This can be proven with a simple example. Consider a network with a delay of two seconds. Even if the audio is perfectly transmitted from the calling end to the receiving end, the delay by itself makes carrying out a conversation nearly impossible.
The PESQ model is however useful to benchmark the quality of different codecs. With
this method it is possible to compare the quality of the same audio sample directly. It is done by storing the original audio sample stored in a lossless file type (e.g., WAV). Subsequently the sample can be transcoded with different codecs and compared directly with the original. This kind of evaluation will show the degradation of the sample after coding and decoding takes place.
In summary, PESQ can provide audio quality, but not necessarily voice or conversation
quality. The reason is that the model does not consider delay. Delay is a critical aspect in voice and particularly in conversations. Once delay becomes too large, conversation is not interactive any longer. Moreover, in wireless systems, delay is variable and one of the main aspects affecting voice quality, which makes this method unfeasible.
3 Codecs for VoIP
There are multiple codecs that can be used to compress voice audio. Each codec
provides different maximum voice quality and bitrate required. However, in case of
VoIP communications over wireless networks only a handful is relevant for this study.
Firstly, the G.711 and G.729 codecs developed by ITU. The former is a high bitrate
codec (64kbps) and the latter is a low bitrate codec (8kbps). Both codecs are extensively deployed and supported. In real life most VoIP calls are usually encoded in one of these two codecs. Despite the wide support for these two codecs, the G.711 codec in particular is not well suited for wireless systems. The reason is that it requires a large amount of bandwidth compared to other codecs. Thus, it is recommended to avoid using this codec in wireless systems. Secondly, there are two other low bitrate codecs that are important for VoIP, namely AMR and iLBC. The AMR codec was developed by wireless network vendors and aims at increasing capacity in cellular systems. The AMR codec is widely supported by some of the wireless network manufacturers, but since it is patented it is not fully compatible with other vendor’s equipment. this codec will be used between cellular operators, but not necessarily between calls to
other systems. Therefore, in practice, In contrast, the iLBC codec was developed by the Internet community IETF. This codec is mainly used in Skype VoIP software for Skype-to-Skype calls. However, it is not as widely supported as the ITU counterparts.
4 Comment :
Hi ,
Your blog is awesome and features some excellent information to our
visitors. Post was very nicely written and it contains useful facts. I am happy to find your distinguished way of writing the post.
I found your website perfect for my needs. It contains wonderful and
helpful posts. I have read most of them and it was informative for all.
You can get DallasXtreme Ventrilo Server are hosted exclusively on Tier 1 networks such as Netfire and Internap.
thanks, im using jquery on this blog.it has a very cool power to manipulate static html only by using javascript.
if you dont mind, please help me post some article for us to read, send it to sapar.man.saja@blogger.com, it will automaticly published..
Thanks for this publish. I find it hard to track down good answers out there when it comes to this subject matter. Thanks for the review!
Post a Comment