R is the unweighted sum of factors, each of which describes some call-quality aspect. Because addition is commutative, the same set of numbers added in different orders produce the same value, but the interpretation of the numbers differ. For example, swapping significantly different values for delay and noise objectively produce the same R but subjectively produce different calls.
The answers, in no particular order and approximately verbatim:
R rating is given by R = R0 - Is - Id - Ic + A where R0 is the background noise or circuit level noise. Is it the signaling noise. Id is the delay and echo where as Ie is the special equipment used like the codecs. A is the customer satisfaction factor. If we consider Id and Ie parameters with respect to two calls assuming values of R0, Is, and A to be the same we can have something like this. Consider the first call where delay is 10 ms (Id = 10 ms) where as there is no codec bit rate problem or distortion. The signal is very clear at receiver end. (Ie = 0). So R = 10 + 0.
Now in second call say there is no delay (Id = 0) but the clarity of signal is not good (Ie = 10). Thus R = 10 + 0.
Considering the above two cases we get the same value for R, i.e., two calls have the same R rating albeit the different values for Id & Ie. i.e., the quality is different
R (rating) = R0 - Id - Ie - Ic + A where
R0 = function of circuit noise level.
Id = impairment caused by codec, packet loss.
Ie = impairment caused by echo, loss of interactivity, etc.
Ic = impairment caused by dejittering decoding.
So, two calls can have the same value of R but can have different values of Id, Ie, or Ic and hence different quality of voice. One call can have long duration of white spaces another call can have echo.
R = R0 - Is - Id - Ie + A
Id comprise the network delay, i.e., propagation delay and Ie comprise of listener echo, talker echo. If propagation delay for Id has higher value but Ie value is less means less echo effect during call and vice versa make same R rating but in terms of quality, both calls are different. In summary, one call with higher delay but less echo effect has same R rating as call with low delay but higher echo effect.
On the positive side, lower bit-rate codecs can produce reasonable quality using fewer bits overall, which should improve transport characteristics. On the negative side, lower bit-rate codecs may increase delay due to extra processing time and make error correction harder due to redundancy loss. In addition unsophisticated low bit-rate codecs can reduce voice quality to much less than what is available in the PSTN.
The answers, in no particular order and approximately verbatim:
There will be delay in receiving the packets sent by lower bit rate codecs or while decoding there can be delay. Lower bit-rate codecs creates more distortion and hence affects the call quality. Predictive codecs are the examples of lower bit-rate codecs. Predictive codecs predicts the voice samples from the previous samples while processing the digital signal. There are some codecs which also tries to detect whether the voice signal contains background noise. This also adds to delay but a good voice active detection doesn't provide any distortion.
Codecs encode the data to send on network. Consider the following: bit rate is 32 kbps.
The predictive property of codec helps to reduce or increase the bit rate. However, bit rate codec will send out packets at low bit rate reducing quality of call as delay increases Also when the codec has to encode the packets it has to remove the background noise. The codec generally has to wait for few samples before encoding which introduces lookahead delay to avoid encoding background noise.
Codecs does not convert audio signals to packets right away, waits for sample of audio to make sure it's a direct audio, not noise. Some times it waits for few samples. This is called look-ahead delay. If lower bit-rate codecs are used, then it adds significant delay in the call and effect call quality. Same problems can occur at both end during encoding and decoding process during call.
| This page last modified on 8 July 2008. |
|