Quality analyzer module - Revision history

Dana at 07:16, 23 May 2014

2014-05-23T07:16:38Z

Monica: /* Examples */

2013-11-04T11:13:00Z

‎Examples

Dana at 11:08, 11 June 2013

2013-06-11T11:08:42Z

Dana: Created page with " 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 al..."

2012-10-19T12:42:57Z

Created page with " 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 al..."

New page

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.

=== 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).

=== 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.

===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

← Older revision		Revision as of 11:13, 4 November 2013
Line 57:		Line 57:
	* [[Rmanager]]		* [[Rmanager]]
	* [[Modules]]		* [[Modules]]
		+
		+	[[Category:Test module]]

← Older revision		Revision as of 11:08, 11 June 2013
Line 51:		Line 51:

	$1234567$=analyzer/probe		$1234567$=analyzer/probe
		+
		+
		+	'''See also'''
		+
		+	* [[Rmanager]]
		+	* [[Modules]]

@@ 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.
-=== How it works===
+=== 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.