Silence detection: Difference between revisions

From VoIPmonitor.org
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 1: Line 1:
VoIPmonitor is able to detect silence in RTP streams (currently only for G711a/u). Silence threshold can be changed by silencethreshold option (default 512 - which is tolerant to a little noice, lower values means not tolerant to a noice.
{{DISPLAYTITLE:Audio Analysis: Silence & Clipping Detection}}
[[Category:GUI manual]]


'''This guide explains how to enable and use VoIPmonitor's advanced audio analysis features for G.711 codecs, including silence detection and audio clipping detection. These tools are invaluable for diagnosing audio quality issues that are not caused by network packet loss, such as one-way audio, muted microphones, or faulty endpoint hardware.'''


silencedetect    = yes
== Overview & Use Cases ==
silencethreshold = 512
Standard network metrics like packet loss and jitter can only identify problems that occur during network transport. However, many audio quality issues originate at the endpoint itself. The Silence & Clipping Detection engine analyzes the decoded G.711 (a-law/u-law) audio stream to identify these problems.


Enable this feature to diagnose issues like:
* A user complaining about "dead air" when the network statistics look perfect.
* One-way audio scenarios where one party is not transmitting any sound.
* Identifying calls with audio clipping, which is often perceived as clicks or distortion.
* More accurately assessing call quality by penalizing MOS scores for periods of absolute silence.


MySQL table cdr must have those columns:
== Prerequisites ==
Before enabling this feature, please ensure the following requirements are met:


caller_silence, called_silence, caller_silence_end, called_silence_end
;1. Codec Limitation:
caller_clipping_div3, called_clipping_div3
:This feature currently only supports calls using the '''G.711 a-law/u-law''' codec. Audio streams from other codecs will not be analyzed.
a_mos_silence_min_mult10, b_mos_silence_min_mult10, _mos_silence_mult10, b_mos_silence_mult10


If any of those columns are missing this feature will be not enabled and you need manually alter cdr table (it can take long time blocking access to GUI and sniffers during the upgrade).  
;2. CPU Resources:
:Decoding and analyzing audio streams is a CPU-intensive process. Enabling these features will increase the overall CPU load on the sensor. Monitor your system's performance after enabling them.


;3. Database Schema:
:All modern VoIPmonitor installations (approximately since 2020) include the necessary database columns by default. If you are running a current version, '''you do not need to perform any database modifications'''. The sensor will log an error on startup if any required columns are missing, which should only happen on very old legacy systems.


Full alter commands: (remove columns from following sql command which you already have in the cdr table). When you run voipmonitor it also prints alter commands which are missing (on syslog and stdout)
== Configuration ==


=== Step 1: Enable in voipmonitor.conf ===
To activate the features, add or uncomment the following lines in `/etc/voipmonitor.conf`:


ALTER TABLE cdr
<pre>
# Enables both silence and clipping detection logic
silencedetect    = yes
 
# Enables the specific feature that detects clipped audio frames
clippingdetect = yes
 
# Defines the audio level threshold for silence. The default of 512 is
# tolerant to low-level background noise. Lower values are stricter.
silencethreshold = 512
</pre>
 
=== Step 2: For Legacy Upgrades - Adding Database Columns ===
'''Note:''' This step is only required if you are upgrading from a very old VoIPmonitor installation and the sensor logs errors about missing columns on startup. For all recent installations, these columns already exist.
 
If required, you can add the columns to your `cdr` table with the following SQL command. Only add the columns that are reported as missing.
 
<pre>
ALTER TABLE cdr
  ADD COLUMN caller_silence tinyint unsigned default NULL,
  ADD COLUMN caller_silence tinyint unsigned default NULL,
  ADD COLUMN called_silence tinyint unsigned default NULL,
  ADD COLUMN called_silence tinyint unsigned default NULL,
  ADD COLUMN caller_silence_end smallint default NULL,
  ADD COLUMN caller_silence_end smallint default NULL,
  ADD COLUMN called_silence_end smallint default NULL;,
  ADD COLUMN called_silence_end smallint default NULL,
  ADD COLUMN caller_clipping_div3 smallint unsigned default NULL,
  ADD COLUMN caller_clipping_div3 smallint unsigned default NULL,
  ADD COLUMN called_clipping_div3 smallint unsigned default NULL,
  ADD COLUMN called_clipping_div3 smallint unsigned default NULL,
Line 29: Line 59:
  ADD COLUMN a_mos_silence_mult10 tinyint unsigned DEFAULT NULL,
  ADD COLUMN a_mos_silence_mult10 tinyint unsigned DEFAULT NULL,
  ADD COLUMN b_mos_silence_mult10 tinyint unsigned DEFAULT NULL;
  ADD COLUMN b_mos_silence_mult10 tinyint unsigned DEFAULT NULL;
</pre>
== Features & Metrics ==
Once enabled, you will have access to several new metrics and visualizations throughout the GUI.


When enabled following metrics are produced:
=== 1. Silence as Packet Loss & MOS Adjustment ===
The system identifies frames of absolute silence (e.g., from a muted mic) and treats them as a form of packet loss. This allows VoIPmonitor to correctly calculate a low MOS score for calls that were silent, even if no actual packets were lost on the network.


* Number of absolute silence audio frames (with 20ms length) which are treated as packet loss. On the following picture see the holes in the first audio stream - this example is taken from a call where RTP stream is coming without any packet loss or jitter, those audio drops are encoded directly in the RTP audio stream. With silencedetection = yes feature voipmonitor will calculate number of those silence frames and counts them as packet loss and calculates MOS score.  
This is visualized in the CDR Graph Detail, where a new MOS score labeled '''"Sil"''' (Silence MOS) will appear.


[[File:cdr_spectral_silence_example.png]]
[[File:cdr_spectral_silence_example.png]]
The MOS score is shown in the Graph in CDR detail as new MOS value "Sil" - see the RED 2.8 number


[[File:cdr_graph_silence_lowmos_example.png]]
[[File:cdr_graph_silence_lowmos_example.png]]


 
=== 2. Overall Silence Percentage ===
* Another silence feature is overall percentage of silence in each direction of a call which will be shown in cdr detail. Calls with >95% percent of a silence would indicate problem.  
The CDR Detail view will show the total percentage of silence for both the caller and callee audio streams. A call with over 95% silence in one direction is a strong indicator of a one-way audio problem.


[[File:cdr_detail_silence_table.png]]
[[File:cdr_detail_silence_table.png]]


* Next feature is number of silence seconds counter from the end of the last RTP packet - this might be the reason why someone hanged up the call because although RTP packets were coming, there was a silence. If value is non zero it will be shown also in CDR summary:
=== 3. Silence at the End of a Call ===
This metric measures the duration of silence leading up to the end of the call. A high value may indicate that a user hung up out of frustration because they couldn't hear the other party. This value is shown directly in the main CDR listing.


[[File:cdr_summary_silence_example.png]]
[[File:cdr_summary_silence_example.png]]


* Number of clipped frames (clipped frame has the highest volume) - perceived as audible clicks - this value is shown in cdr detail table. It can be filtered and used in charts. Must be enabled in voipmonitor.conf
=== 4. Audio Clipping Detection ===
The system counts the number of "clipped" audio frames, which occur when the audio signal is too loud and hits the maximum amplitude, causing distortion. This metric is shown in the CDR detail and can be used for filtering and creating charts to find problematic endpoints.


clippingdetect = yes
[[File:charts_silence_values.png]]


Data series in charts for silence, silence end and clipped frames:
== AI Summary for RAG ==
 
'''Summary:''' This document describes the configuration and benefits of VoIPmonitor's Silence and Clipping Detection features. It explains that this functionality is specific to the G.711 (a-law/u-law) codec and is CPU-intensive. The guide details the required `voipmonitor.conf` settings (`silencedetect`, `clippingdetect`). It clarifies that while the feature requires specific database columns, these are included by default in all modern installations, and provides the `ALTER TABLE` command only for users upgrading from very old legacy systems. The key benefits are then explained: 1) Treating absolute silence as packet loss to produce a more accurate MOS score. 2) Calculating the overall percentage of silence to identify one-way audio. 3) Measuring silence at the end of a call to find frustration-based hangups. 4) Counting clipped audio frames to detect distortion.
[[File:charts_silence_values.png]]
'''Keywords:''' silence detection, clipping, one-way audio, no audio, dead air, MOS, G.711, alaw, ulaw, `silencedetect`, `clippingdetect`, `silencethreshold`, database schema, alter table, legacy upgrade, audio quality, audio analysis
'''Key Questions:'''
* How can I diagnose one-way audio problems?
* Why is a call's MOS score high even though the user reported hearing nothing?
* How does VoIPmonitor detect silence in a call?
* What does the "Silence MOS" or "Sil" score mean in the CDR graph?
* Do I need to alter my database table to use silence detection?
* How can I find all calls that have audio clipping?
* What configuration is needed to enable silence detection?

Latest revision as of 16:27, 30 June 2025


This guide explains how to enable and use VoIPmonitor's advanced audio analysis features for G.711 codecs, including silence detection and audio clipping detection. These tools are invaluable for diagnosing audio quality issues that are not caused by network packet loss, such as one-way audio, muted microphones, or faulty endpoint hardware.

Overview & Use Cases

Standard network metrics like packet loss and jitter can only identify problems that occur during network transport. However, many audio quality issues originate at the endpoint itself. The Silence & Clipping Detection engine analyzes the decoded G.711 (a-law/u-law) audio stream to identify these problems.

Enable this feature to diagnose issues like:

  • A user complaining about "dead air" when the network statistics look perfect.
  • One-way audio scenarios where one party is not transmitting any sound.
  • Identifying calls with audio clipping, which is often perceived as clicks or distortion.
  • More accurately assessing call quality by penalizing MOS scores for periods of absolute silence.

Prerequisites

Before enabling this feature, please ensure the following requirements are met:

1. Codec Limitation
This feature currently only supports calls using the G.711 a-law/u-law codec. Audio streams from other codecs will not be analyzed.
2. CPU Resources
Decoding and analyzing audio streams is a CPU-intensive process. Enabling these features will increase the overall CPU load on the sensor. Monitor your system's performance after enabling them.
3. Database Schema
All modern VoIPmonitor installations (approximately since 2020) include the necessary database columns by default. If you are running a current version, you do not need to perform any database modifications. The sensor will log an error on startup if any required columns are missing, which should only happen on very old legacy systems.

Configuration

Step 1: Enable in voipmonitor.conf

To activate the features, add or uncomment the following lines in `/etc/voipmonitor.conf`:

# Enables both silence and clipping detection logic
silencedetect    = yes

# Enables the specific feature that detects clipped audio frames
clippingdetect = yes

# Defines the audio level threshold for silence. The default of 512 is
# tolerant to low-level background noise. Lower values are stricter.
silencethreshold = 512

Step 2: For Legacy Upgrades - Adding Database Columns

Note: This step is only required if you are upgrading from a very old VoIPmonitor installation and the sensor logs errors about missing columns on startup. For all recent installations, these columns already exist.

If required, you can add the columns to your `cdr` table with the following SQL command. Only add the columns that are reported as missing.

ALTER TABLE cdr
 ADD COLUMN caller_silence tinyint unsigned default NULL,
 ADD COLUMN called_silence tinyint unsigned default NULL,
 ADD COLUMN caller_silence_end smallint default NULL,
 ADD COLUMN called_silence_end smallint default NULL,
 ADD COLUMN caller_clipping_div3 smallint unsigned default NULL,
 ADD COLUMN called_clipping_div3 smallint unsigned default NULL,
 ADD COLUMN a_mos_silence_min_mult10 tinyint unsigned DEFAULT NULL,
 ADD COLUMN b_mos_silence_min_mult10 tinyint unsigned DEFAULT NULL,
 ADD COLUMN a_mos_silence_mult10 tinyint unsigned DEFAULT NULL,
 ADD COLUMN b_mos_silence_mult10 tinyint unsigned DEFAULT NULL;

Features & Metrics

Once enabled, you will have access to several new metrics and visualizations throughout the GUI.

1. Silence as Packet Loss & MOS Adjustment

The system identifies frames of absolute silence (e.g., from a muted mic) and treats them as a form of packet loss. This allows VoIPmonitor to correctly calculate a low MOS score for calls that were silent, even if no actual packets were lost on the network.

This is visualized in the CDR Graph Detail, where a new MOS score labeled "Sil" (Silence MOS) will appear.

2. Overall Silence Percentage

The CDR Detail view will show the total percentage of silence for both the caller and callee audio streams. A call with over 95% silence in one direction is a strong indicator of a one-way audio problem.

3. Silence at the End of a Call

This metric measures the duration of silence leading up to the end of the call. A high value may indicate that a user hung up out of frustration because they couldn't hear the other party. This value is shown directly in the main CDR listing.

4. Audio Clipping Detection

The system counts the number of "clipped" audio frames, which occur when the audio signal is too loud and hits the maximum amplitude, causing distortion. This metric is shown in the CDR detail and can be used for filtering and creating charts to find problematic endpoints.

AI Summary for RAG

Summary: This document describes the configuration and benefits of VoIPmonitor's Silence and Clipping Detection features. It explains that this functionality is specific to the G.711 (a-law/u-law) codec and is CPU-intensive. The guide details the required `voipmonitor.conf` settings (`silencedetect`, `clippingdetect`). It clarifies that while the feature requires specific database columns, these are included by default in all modern installations, and provides the `ALTER TABLE` command only for users upgrading from very old legacy systems. The key benefits are then explained: 1) Treating absolute silence as packet loss to produce a more accurate MOS score. 2) Calculating the overall percentage of silence to identify one-way audio. 3) Measuring silence at the end of a call to find frustration-based hangups. 4) Counting clipped audio frames to detect distortion. Keywords: silence detection, clipping, one-way audio, no audio, dead air, MOS, G.711, alaw, ulaw, `silencedetect`, `clippingdetect`, `silencethreshold`, database schema, alter table, legacy upgrade, audio quality, audio analysis Key Questions:

  • How can I diagnose one-way audio problems?
  • Why is a call's MOS score high even though the user reported hearing nothing?
  • How does VoIPmonitor detect silence in a call?
  • What does the "Silence MOS" or "Sil" score mean in the CDR graph?
  • Do I need to alter my database table to use silence detection?
  • How can I find all calls that have audio clipping?
  • What configuration is needed to enable silence detection?