Quality analyzer module
| (One intermediate revision by one user not shown) | |||
| Line 6: | Line 6: | ||
The audio path under test must be digital and use only the G.711 companders. An analog segment or a different codec will probably make the test fail. | The audio path under test must be digital and use only the G.711 companders. An analog segment or a different codec will probably make the test fail. | ||
| − | === How it | + | === How it Works=== |
The probe signal is the '''tone/probe''' generated by [[tonegen]] consisting of an 125Hz sine wave added with a 2kHz sine wave. The low frequency tone makes the signal sensitive to disruptions of the order of typical VoIP packetization (20 or 30ms) while the high frequency tone tries to catch problems with resamplers, codecs and analog segments. | The probe signal is the '''tone/probe''' generated by [[tonegen]] consisting of an 125Hz sine wave added with a 2kHz sine wave. The low frequency tone makes the signal sensitive to disruptions of the order of typical VoIP packetization (20 or 30ms) while the high frequency tone tries to catch problems with resamplers, codecs and analog segments. | ||
| Line 57: | Line 57: | ||
* [[Rmanager]] | * [[Rmanager]] | ||
* [[Modules]] | * [[Modules]] | ||
| + | |||
| + | [[Category:Test module]] | ||
Latest revision as of 09:16, 23 May 2014
This is a module designed to check the quality of the digital audio path of a call. It works by analyzing if a probe signal generated by the tonegen module is received altered.
The problems that can be detected are gaps (interruptions), cracks, stutter and short audio loops. The reported quality is not related to the subjective voice quality factor.
The audio path under test must be digital and use only the G.711 companders. An analog segment or a different codec will probably make the test fail.
[edit] How it Works
The probe signal is the tone/probe generated by tonegen consisting of an 125Hz sine wave added with a 2kHz sine wave. The low frequency tone makes the signal sensitive to disruptions of the order of typical VoIP packetization (20 or 30ms) while the high frequency tone tries to catch problems with resamplers, codecs and analog segments.
The receiver side in the analyzer module itself computes the spectrum of the probe signal after it passes the audio path. The percentage of packets that match the expected 2 peaks spectrum is reported as the quality of the call.
The number and total length of discontinuities in the timestamps of the received data are also counted. These can be detected only on VoIP calls since in PSTN the timestamp information is not present (the network is supposed to be synchronized to a single clock source).
[edit] Usage
The probe calls can be made in two modes:
- Call from analyzer to a remote digital echo device
- Call to a remote Yate providing analyzer module
The second way should be used if possible as it detects problems separately on each direction.
[edit] Examples
For a call made from rmanager:
output on call analyzer/probe 1234567 ... wait ... status analyzer/1 ... wait ... drop analyzer/1
The end reports displayed on screen and written to logs will look like:
Finished 'analyzer/1' status: dropped,routetime=0.011,answertime=0.102,totaltime=14.019, gaps=0,gaplen=0,samples=111840,rate=8006,quality=100.00 ... Finished 'analyzer/2' status: dropped,routetime=0.007,answertime=0.217,totaltime=27.913,gaps=2, gaplen=320,samples=221600,rate=8001,quality=97.978
If the remote echo device is another Yate server it can have the following line in regexroute.conf:
$1234567$=conf/probe-${id};smart=no;echo=yes
If the remote runs another Yate analyzer use in regexroute.conf:
$1234567$=analyzer/probe
See also
