Alerts: Difference between revisions

From VoIPmonitor.org
(Add documentation about using external scripts for alert actions (webhooks, Datadog, Slack integration))
(Fix template syntax - remove curly braces from 'from' and 'to' field names)
 
(33 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{DISPLAYTITLE:Alerts & Reports}}
{{DISPLAYTITLE:Alerts & Reports}}
Category:GUI manual
[[Category:GUI manual]]


== Alerts & Reports ==
= Alerts & Reports =


Alerts & Reports generate email notifications based on QoS parameters or SIP error conditions. The system includes daily reports, ad hoc reports, and stores all generated items in history.
Email notifications triggered by QoS thresholds, SIP errors, or sensor health conditions. The system stores all alerts in history for review.
 
=== Overview ===
 
The alert system monitors call quality and SIP signaling in real-time, triggering notifications when configured thresholds are exceeded.


<kroki lang="plantuml">
<kroki lang="plantuml">
Line 14: Line 10:
skinparam shadowing false
skinparam shadowing false
skinparam defaultFontName Arial
skinparam defaultFontName Arial
 
rectangle "Sensor" as sensor
rectangle "VoIPmonitor\nSensor" as sensor
database "MySQL" as db
database "MySQL\nDatabase" as db
rectangle "Cron\n(1min)" as cron
rectangle "Cron Job\n(every minute)" as cron
rectangle "Alert\nProcessor" as processor
rectangle "Alert\nProcessor" as processor
rectangle "MTA\n(Postfix/Exim)" as mta
rectangle "MTA" as mta
actor "Admin" as admin
actor "Admin" as admin
 
sensor --> db : CDRs
sensor --> db : CDRs with\nQoS metrics
cron --> processor : Trigger
cron --> processor : Trigger
processor --> db : Query alerts\n& CDRs
processor --> db : Query
processor --> mta : Send email
processor --> mta : Email
mta --> admin : Alert notification
mta --> admin : Alert
@enduml
@enduml
</kroki>
</kroki>


=== Email Configuration Prerequisites ===
== Prerequisites ==


Emails are sent using PHP's <code>mail()</code> function, which relies on the server's Mail Transfer Agent (MTA) such as Exim, Postfix, or Sendmail. Configure your MTA according to your Linux distribution documentation.
=== Email Configuration ===


==== Setting Up the Cron Job ====
Alerts use PHP's <code>mail()</code> function via the server's MTA (Postfix/Exim/Sendmail).


Alert processing requires a cron job that runs every minute:
{| class="wikitable"
|-
! Setting !! Location !! Description
|-
| From Address || GUI > Settings > System Configuration > Email || <code>DEFAULT_EMAIL_FROM</code> - sender address for all alerts
|-
| Cron Job || <code>/etc/crontab</code> || Required for alert processing
|}


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Add to /etc/crontab (adjust path based on your GUI installation)
# Add cron job (required)
echo "* * * * * root php /var/www/html/php/run.php cron" >> /etc/crontab
echo "* * * * * root php /var/www/html/php/run.php cron" >> /etc/crontab
# Reload crontab
killall -HUP cron  # Debian/Ubuntu
killall -HUP cron  # Debian/Ubuntu
# or
# or: killall -HUP crond  # RHEL/CentOS
killall -HUP crond  # CentOS/RHEL
</syntaxhighlight>
</syntaxhighlight>


=== Configure Alerts ===
== Alert Types ==
 
Email alerts can trigger on SIP protocol events or RTP QoS metrics. Access alerts configuration via '''GUI > Alerts'''.


[[File:alertgrid.png|frame|center|Alert configuration grid]]
Access via '''GUI > Alerts'''.


==== Alert Types ====
=== RTP Alerts ===


===== RTP Alerts =====
Trigger on voice quality metrics:
 
* '''MOS''' - below threshold
RTP alerts trigger based on voice quality metrics:
* '''MOS''' (Mean Opinion Score) - below threshold
* '''Packet loss''' - percentage exceeded
* '''Packet loss''' - percentage exceeded
* '''Jitter''' - variation exceeded
* '''Jitter''' - variation exceeded
* '''Delay''' (PDV) - latency exceeded
* '''Delay''' (PDV) - latency exceeded
* '''One-way calls''' - answered but one RTP stream missing
* '''One-way calls''' - one RTP stream missing
* '''Missing RTP''' - answered but both RTP streams missing
* '''Missing RTP''' - both RTP streams missing


Configure alerts to trigger when:
Configure alerts to trigger when number of incidents OR percentage of CDRs exceeds threshold.
* Number of incidents exceeds a set value, OR
* Percentage of CDRs exceeds a threshold


[[File:alertrtpform.png|frame|center|RTP alert configuration form]]
=== RTP&CDR Alerts ===


===== SIP Response Alerts =====
Combine RTP metrics with CDR conditions including '''PDD (Post Dial Delay)'''.


SIP response alerts trigger based on SIP response codes:
'''Using Filter Templates:'''
* '''Empty response field''': Matches all call attempts per configured filters
# Create CDR filter in '''GUI > CDR'''
* '''Response code 0''': Matches unreplied INVITE requests (no response received)
# Save as template
* '''Specific codes''': Match exact codes like 404, 503, etc.
# In alert config, select from '''Filter template''' dropdown


[[File:alertsipform.png|frame|center|SIP response alert configuration form]]
{{Tip|1=Use filter templates for complex conditions like <code>duration > 14400</code> (calls over 4 hours) or <code>absolute_timeout</code> (truncated recordings).}}


===== Sensors Alerts =====
=== SIP Response Alerts ===


Sensors alerts monitor the health of VoIPmonitor probes and sniffer instances. This is the most reliable method to check if remote sensors are online and actively monitoring traffic.
{| class="wikitable"
 
|-
Unlike simple network port monitoring (which may show a port as open even if the process is frozen or unresponsive), sensors alerts verify that the sensor instance is actively communicating with the VoIPmonitor GUI server.
! Response Code !! Meaning
 
|-
;Setup:
| Empty || All call attempts per filters
:# Configure sensors in '''Settings > Sensors'''
|-
:# Create a sensors alert to be notified when a probe goes offline or becomes unresponsive
| '''0''' || No response received (routing loops)
 
|-
===== SIP REGISTER RRD Beta Alerts =====
| '''408''' || Timeout after provisional response (server unresponsive)
|-
| Specific || Exact codes (404, 503, etc.)
|}


The '''SIP REGISTER RRD beta''' alert type monitors SIP REGISTER response times and alerts when REGISTER packets do not receive a response within a specified threshold (in milliseconds). This is useful for detecting network latency issues, packet loss, or failing switches that cause SIP retransmissions.
==== "from all" Checkbox (Percentage Thresholds) ====


This alert serves as an effective proxy to monitor for registration issues, as REGISTER retransmissions often indicate problems with network connectivity or unresponsive SIP servers.
{{Warning|1=This setting is critical for IP group monitoring.}}


;Configuration:
* '''CHECKED''': % calculated from ALL CDRs in database
:# Navigate to '''GUI > Alerts'''
* '''UNCHECKED''': % calculated only from filtered CDRs (correct for specific IP groups)
:# Create a new alert with type '''SIP REGISTER RRD beta'''
:# Set the response time threshold in milliseconds (e.g., alert if REGISTER does not receive a response within 2000ms)
:# Configure recipient email addresses
:# Save the alert configuration


The system monitors REGISTER packets and triggers an alert when responses exceed the configured threshold, indicating potential SIP registration failures or network issues.


[[File:alertgrid.png|frame|center|Alert configuration grid]]


==== Common Filters ====
==== SIP Response vs Last SIP Response ====


All alert types support the following filters:
There are two different fields for matching SIP responses:


{| class="wikitable"
{| class="wikitable"
|-
|-
! Filter !! Description
! Field !! Location !! Supports % Threshold !! Use Case
|-
| IP/Number Group || Apply alert to predefined groups (from '''Groups''' menu)
|-
|-
| IP Addresses || Individual IPs or ranges (one per line)
| '''SIP response''' || GUI > Alerts > SIP Response Alerts || {{Yes}} || Match by numeric code (e.g., 487, 503)
|-
|-
| Numbers || Individual phone numbers or prefixes (one per line)
| '''Last sip response''' || GUI > Alerts > Filter common || {{No}} || Match by full text (e.g., "487 Request Terminated")
|-
| Email Group || Send alerts to group-defined email addresses
|-
| Emails || Individual recipient emails (one per line)
|-
| External script || Path to custom script to execute when alert triggers (see below)
|}
|}


[[File:alertgroup.png|frame|center|Alert filter configuration]]
{{Warning|1=The GUI '''cannot trigger alerts based on percentage of full textual response strings'''. If you need percentage-based triggering for SIP response codes, use the '''SIP response''' numeric field instead.}}
 
=== Using External Scripts for Alert Actions ===
 
Beyond email notifications, alerts can execute custom scripts when triggered. This enables integration with third-party systems (webhooks, Datadog, Slack, custom monitoring tools) without sending emails.
 
==== Configuration ====


1. Navigate to '''GUI > Alerts'''
The '''Last sip response''' field supports wildcard patterns (%, %Request Terminated%, %487%) but only triggers based on count thresholds, not percentages.
2. Create or edit an alert (RTP, SIP Response, Sensors, etc.)
=== International Call Alerts (Called Number Prefixes) ===
3. In the configuration form, locate the '''External script''' field
4. Enter the full path to your custom script (e.g., <code>/usr/local/bin/alert-webhook.sh</code>)
5. Save the alert configuration


The script will execute immediately when the alert triggers.
Monitor calls to international destinations using '''prefix-based matching''' (dialing patterns like 00, +).


==== Script Arguments ====
{{Note|1=This uses phone number prefix detection, NOT IP geolocation. For GeoIP-based detection, see [[Anti-fraud|Anti-Fraud Rules]].}}


The custom script receives alert data as command-line arguments. The format is identical to anti-fraud scripts (see [[Anti-fraud|Anti-Fraud Rules]]):
'''Configuration:'''
# '''GUI > Settings > Country prefixes''' - Define international prefixes (00, +), local country, minimum digits
# '''GUI > Alerts > Filter common''' - Configure:


{| class="wikitable"
{| class="wikitable"
|-
|-
! Argument !! Description
! Setting !! Description
|-
|-
| <code>$1</code> || Alert ID (numeric identifier)
| Called number prefixes || Which prefixes trigger alert (uncheck ALL for all international)
|-
|-
| <code>$2</code> || Alert name/type
| Exclude called number || Country codes to exclude (e.g., +44, 0044 for UK)
|-
|-
| <code>$3</code> || Unix timestamp of alert trigger
| Strict for prefixes || Require international prefix (00/+)
|-
|-
| <code>$4</code> || JSON-encoded alert data
| NANPA || North American Numbering Plan
|}
|}


==== Alert Data Structure ====
=== Sensors Alerts ===


The JSON in the fourth argument contains CDR IDs affected by the alert:
Monitor sensor health and status:
* '''Offline detection''' - Sensor not communicating
* '''Old CDR''' - No recent CDRs written (capture or DB issue)
* '''Big SQL queue stat''' - Growing queue indicates DB bottleneck (warning: >20 files, critical: >100)


<syntaxhighlight lang="json">
=== SIP REGISTER Alerts ===
{
  "cdr": [12345, 12346, 12347],
  "alert_type": "MOS below threshold",
  "threshold": 3.5,
  "actual_value": 2.8
}
</syntaxhighlight>


Use the <code>cdr</code> array to query additional information from the database if needed.
{| class="wikitable"
 
|-
==== Example: Send Webhook to Datadog ====
! Alert Type !! Purpose !! Use Case
|-
| '''SIP REGISTER RRD beta''' || Response time monitoring || Network latency, packet loss
|-
| '''SIP failed Register (beta)''' || Failed registrations by IP || Brute-force, credential stuffing
|-
| '''multiple register (beta)''' || Same account from multiple IPs || Credential compromise detection
|}


This bash script sends an alert notification to a Datadog webhook API:
{{Warning|1='''multiple register (beta)''' detects SIMULTANEOUS registrations from multiple IPs (security). For detecting IP changes when device moves networks, use CDR&RTP alert with external script.}}


<syntaxhighlight lang="bash">
#!/bin/bash
# /usr/local/bin/datadog-alert.sh


# Configuration
WEBHOOK_URL="https://webhook.site/your-custom-url"
DATADOG_API_KEY="your-datadog-api-key"


# Parse arguments
==== Alert Output Fields ====
ALERT_ID="$1"
ALERT_NAME="$2"
TIMESTAMP="$3"
ALERT_DATA="$4"


# Convert Unix timestamp to readable date
The '''multiple register (beta)''' and other SIP REGISTER alerts output the following fields in email notifications and GUI:
DATE=$(date -d "@$TIMESTAMP" '+%Y-%m-%d %H:%M:%S')


# Extract relevant data from JSON
{| class="wikitable"
cdrCount=$(echo "$ALERT_DATA" | jq -r '.cdr | length')
|-
threshold=$(echo "$ALERT_DATA" | jq -r '.threshold // empty')
! Field !! Source !! Description
actualValue=$(echo "$ALERT_DATA" | jq -r '.actual_value // empty')
|-
 
| '''username''' || SIP Contact header || The registered user identity
# Build webhook payload
|-
PAYLOAD=$(cat <<EOF
| '''from''' fields || SIP From header || From-number, From-domain extracted from From header
{
|-
  "alert_id": "$ALERT_ID",
| '''to''' fields || SIP To header || To-number, To-domain extracted from To header
  "alert_name": "$ALERT_NAME",
|-
  "triggered_at": "$DATE",
| '''lookup name''' || Tools > Prefix Lookup || Custom label if phone number matches a configured prefix entry
  "cdr_count": $cdrCount,
|}
  "threshold": $threshold,
  "actual_value": $actualValue,
  "source": "voipmonitor"
}
EOF
)
 
# Send webhook
curl -X POST "$WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DATADOG_API_KEY" \
  -d "$PAYLOAD"
</syntaxhighlight>
 
Make the script executable:
 
<syntaxhighlight lang="bash">
chmod +x /usr/local/bin/datadog-alert.sh
</syntaxhighlight>
 
==== Example: Send Slack Notification ====
 
<syntaxhighlight lang="bash">
#!/bin/bash
# /usr/local/bin/slack-alert.sh
 
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
 
ALERT_NAME="$2"
ALERT_DATA="$4"
cdrCount=$(echo "$ALERT_DATA" | jq -r '.cdr | length')
 
curl -X POST "$SLACK_WEBHOOK" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "VoIPmonitor Alert: '"$ALERT_NAME"'",
    "attachments": [{
      "color": "danger",
      "fields": [
        {"title": "CDRs affected", "value": "'"$cdrCount"'"}
      ]
    }]
  }'
</syntaxhighlight>
 
==== Example: Store Alert Details in File ====
 
<syntaxhighlight lang="bash">
#!/bin/bash
# /usr/local/bin/log-alert.sh
 
LOG_DIR="/var/log/voipmonitor-alerts"
mkdir -p "$LOG_DIR"
 
# Log all arguments for debugging
echo "=== Alert triggered at $(date) ===" >> "$LOG_DIR/alerts.log"
echo "Alert ID: $1" >> "$LOG_DIR/alerts.log"
echo "Alert name: $2" >> "$LOG_DIR/alerts.log"
echo "Timestamp: $3" >> "$LOG_DIR/alerts.log"
echo "Data: $4" >> "$LOG_DIR/alerts.log"
echo "" >> "$LOG_DIR/alerts.log"
</syntaxhighlight>
 
==== Important Notes ====
 
* '''Script execution time''': The alert processor waits for the script to complete. Keep scripts fast (under 5 seconds) or run them in the background if processing takes longer.
* '''Script permissions''': Ensure the script is executable by the web server user (typically <code>www-data</code> or <code>apache</code>).
* '''Error handling''': Script failures are logged but do not prevent email alerts from being sent.
* '''Querying CDRs''': The script receives CDR IDs in the JSON data. Query the <code>cdr</code> table to retrieve detailed information like caller numbers, call duration, etc.
* '''Security''': Validate input before using it in commands or database queries to prevent injection attacks.
 
=== Sent Alerts ===
 
All triggered alerts are saved in history and can be viewed via '''GUI > Alerts > Sent Alerts'''. The content matches what was sent via email.
 
[[File:alert-sentalerts.png|frame|center|Sent alerts history]]
 
==== Parameters Table ====
 
The parameters table shows QoS metrics with problematic values highlighted for quick identification.
 
[[File:alert-perameters.png|frame|center|Alert parameters with highlighted bad values]]
 
==== CDR Records Table ====
 
The CDR records table lists all calls that triggered the alert. Each row includes alert flags indicating which thresholds were exceeded:
* '''(M)''' - MOS below threshold
* '''(J)''' - Jitter exceeded
* '''(P)''' - Packet loss exceeded
* '''(D)''' - Delay exceeded
 
=== Anti-Fraud Alerts ===
 
VoIPmonitor includes specialized anti-fraud alert rules for detecting attacks and fraudulent activity. These include:
* Realtime concurrent calls monitoring
* SIP REGISTER flood/attack detection
* SIP PACKETS flood detection
* Country/Continent destination alerts
* CDR/REGISTER country change detection
 
For detailed configuration of anti-fraud rules and custom action scripts, see [[Anti-fraud|Anti-Fraud Rules]].
 
=== Alerts Based on Custom Reports ===
 
In addition to native alert types (RTP, SIP response, Sensors), VoIPmonitor supports generating alerts from custom reports. This workflow enables alerts based on criteria not available in native alert types, such as SIP header values captured via CDR custom headers.
 
==== Workflow Overview =====
 
1. [[Settings#CDR_Custom_Headers|Capture custom SIP headers]] in the database
2. Create a custom report filtered by the custom header values
3. Generate an alert from that report
4. Configure alert email options (e.g., limit email size)
 
==== Example: Alert on SIP Max-Forwards Header Value =====
 
This example shows how to receive an alert when the SIP <code>Max-Forwards</code> header value drops below 15.
 
'''Step 1: Configure Sniffer Capture'''
 
Add the header to your <code>/etc/voipmonitor.conf</code> configuration file:
 
<syntaxhighlight lang="ini">
# Capture Max-Forwards header
custom_headers = Max-Forwards
</syntaxhighlight>
 
Restart the sniffer to apply changes:
 
<syntaxhighlight lang="bash">
service voipmonitor restart
</syntaxhighlight>
 
'''Step 2: Configure Custom Header in GUI'''
 
1. Navigate to '''GUI > Settings > CDR Custom Headers'''
2. Select <code>Max-Forwards</code> from the available headers
3. Enable '''Show as Column''' to display it in CDR views
4. Save configuration
 
'''Step 3: Create Custom Report'''
 
1. Navigate to '''GUI > CDR Custom Headers''' or use the Report Generator
2. Create a filter for calls where <code>Max-Forwards</code> is less than 15
3. Since custom headers store string values, use a filter expression that matches the desired values:
<syntaxhighlight lang="text">
15 14 13 12 11 10 0_ _
</syntaxhighlight>
  Include additional space-separated values or use NULL to match other ranges as needed.


4. Run the report to verify it captures the expected calls
{{Note|1=The '''lookup name''' column displays custom labels from [[Tools#Prefix_Lookup|Prefix Lookup]] when a phone number matches a configured prefix. If no match exists, the field remains empty or shows the raw number.}}
=== CDR Trends Alerts ===


'''Step 4: Generate Alert from Report'''
Monitor metric deviations from historical baselines (e.g., ASR drops).


You can create an alert based on this custom report using the Daily Reports feature:
1. Navigate to '''GUI > Reports > Configure Daily Reports'''
2. Click '''Add Daily Report'''
3. Configure the filter to target the custom header criteria (e.g., Max-Forwards < 15)
4. Set the schedule (e.g., run every hour)
5. Save the daily report configuration
'''Step 5: Limit Alert Email Size (Optional)'''
If the custom report generates many matching calls, the alert email can become large. To limit the email size:
1. Edit the daily report
2. Go to the '''Basic Data''' tab
3. Set the '''max-lines in body''' option to the desired limit (e.g., 100 lines)
==== Additional Use Cases =====
This workflow can be used for various custom monitoring scenarios:
* '''SIP headers beyond standard SIP response codes''' - Monitor any custom SIP header
* '''Complex filtering logic''' - Create reports based on multiple custom header filters
* '''Threshold monitoring for string fields''' - When numeric comparison is not available, use string matching
For more information on configuring custom headers, see [[Settings#CDR_Custom_Headers|CDR Custom Headers]].
=== Troubleshooting Email Alerts ===
If email alerts are not being sent, the issue is typically with the Mail Transfer Agent (MTA) rather than VoIPmonitor.
==== Step 1: Test Email Delivery from Command Line ====
Before investigating complex issues, verify your server can send emails:
<syntaxhighlight lang="bash">
# Test using the 'mail' command
echo "Test email body" | mail -s "Test Subject" your.email@example.com
</syntaxhighlight>
If this fails, the issue is with your MTA configuration, not VoIPmonitor.
==== Step 2: Check MTA Service Status ====
Ensure the MTA service is running:
<syntaxhighlight lang="bash">
# For Postfix (most common)
sudo systemctl status postfix
# For Exim (Debian default)
sudo systemctl status exim4
# For Sendmail
sudo systemctl status sendmail
</syntaxhighlight>
If the service is not running or not installed, install and configure it according to your Linux distribution's documentation.
==== Step 3: Check Mail Logs ====
Examine the MTA logs for specific error messages:
<syntaxhighlight lang="bash">
# Debian/Ubuntu
tail -f /var/log/mail.log
# RHEL/CentOS/AlmaLinux/Rocky
tail -f /var/log/maillog
</syntaxhighlight>
Common errors and their meanings:
{| class="wikitable"
{| class="wikitable"
|-
|-
! Error Message !! Cause !! Solution
! Parameter !! Description
|-
|-
| Connection refused || MTA not running or firewall blocking || Start MTA service, check firewall rules
| Type || Metric to monitor (ASR, ACD, etc.)
|-
|-
| Relay access denied || SMTP relay misconfiguration || See "Configuring SMTP Relay" below
| Offset || Historical baseline (1 week, 1 day)
|-
|-
| Authentication failed || Incorrect credentials || Verify credentials in sasl_passwd
| Range || Current evaluation window (1 hour)
|-
|-
| Host or domain name lookup failed || DNS issues || Check /etc/resolv.conf
| Method || Deviation (%) or Threshold (absolute)
|-
|-
| Greylisted || Temporary rejection || Wait and retry, or whitelist sender
| Limit Inc./Dec. || Trigger threshold percentage
|}
|}


==== Step 4: Check Mail Queue ====
== Common Filters ==
 
Emails may be stuck in the queue if delivery is failing:
 
<syntaxhighlight lang="bash">
# View the mail queue
mailq


# Force immediate delivery attempt
All alert types support:
postqueue -f
* '''IP/Number Group''' - Predefined groups from '''Groups''' menu
</syntaxhighlight>
* '''IP Addresses''' / '''Numbers''' - Individual values (one per line)
* '''Email Group''' / '''Emails''' - Recipients
* '''Last sip response''' - Filter by response text (requires <code>save_sip_history = responses</code>)
* '''External script''' - Custom script path for integrations


Deferred or failed messages in the queue contain error details explaining why delivery failed.
{{Warning|1=Alerts use '''OR logic''' between conditions. AND logic is NOT supported. Workaround: create separate alerts and correlate manually.}}


==== Configuring SMTP Relay ===
=== Caller vs Called Filtering ===


If you encounter "Relay access denied" errors, your Postfix server cannot send emails through your external SMTP server. There are two solutions:
The Numbers filter matches against '''both caller and called fields'''. You cannot create alerts that trigger only when a number is the caller or only the called. Use IP Groups with Trunk/Server checkboxes for direction-based filtering. See [[Groups]].


'''Solution 1: Configure External SMTP to Permit Relaying (Recommended for Trusted Networks)'''
== External Scripts ==


If the VoIPmonitor server is in a trusted network, configure your external SMTP server to permit relaying from the VoIPmonitor server's IP address:
Enable webhook integration (Datadog, Slack, custom systems).


1. Access your external SMTP server configuration
'''Configuration:''' Enter full absolute path in '''External script''' field (e.g., <code>/usr/local/bin/alert-webhook.sh</code>).
2. Add the VoIPmonitor server's IP address to the allowed relay hosts (mynetworks)
3. Save configuration and reload: <code>postfix reload</code>


'''Solution 2: Configure Postfix SMTP Authentication (Recommended for Remote SMTP)'''
'''Arguments passed to script:'''
{| class="wikitable"
|-
! Arg !! Description
|-
| <code>$1</code> || Alert ID
|-
| <code>$2</code> || Alert name
|-
| <code>$3</code> || Unix timestamp
|-
| <code>$4</code> || JSON data with CDR IDs
|}


If using an external SMTP server that requires authentication, configure Postfix to authenticate using SASL:
'''Example - Slack notification:'''
 
1. Install SASL authentication packages:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Debian/Ubuntu
#!/bin/bash
sudo apt-get install libsasl2-modules
# /usr/local/bin/slack-alert.sh
 
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
# RHEL/CentOS/AlmaLinux/Rocky
curl -X POST "$SLACK_WEBHOOK" -H "Content-Type: application/json" \
sudo yum install cyrus-sasl-plain
  -d '{"text": "VoIPmonitor Alert: '"$2"'"}'
</syntaxhighlight>
</syntaxhighlight>


2. Configure Postfix to use the external SMTP relay:
{{Note|1=IP addresses in CDR table are decimal integers. Use <code>long2ip()</code> (PHP) or <code>INET_NTOA()</code> (MySQL) for conversion.}}


Edit <code>/etc/postfix/main.cf</code>:
== Sent Alerts ==
<syntaxhighlight lang="ini">
# Use external SMTP as relay host
relayhost = smtp.yourprovider.com:587


# Enable SASL authentication
View triggered alerts via '''GUI > Alerts > Sent Alerts'''. Shows:
smtp_sasl_auth_enable = yes
* '''Parameters table''' - QoS metrics with highlighted bad values
* '''CDR records''' - Calls that triggered alert with flags: (M)OS, (J)itter, (P)acket loss, (D)elay


# Use SASL password file
== Custom Report Alerts ==
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd


# Disable anonymous authentication (use only SASL)
Alert on criteria not in native types (e.g., custom SIP headers).
smtp_sasl_security_options = noanonymous


# Enable TLS (recommended)
'''Workflow:'''
smtp_tls_security_level = encrypt
# Capture header in <code>/etc/voipmonitor.conf</code>: <code>custom_headers = Max-Forwards</code>
</syntaxhighlight>
# Enable in '''GUI > Settings > CDR Custom Headers'''
# Create filter in CDR view, save as template
# Create Daily Report with filter in '''GUI > Reports > Configure Daily Reports'''


3. Create the SASL password file with your SMTP credentials:
{{Note|1=Custom report alerts cannot group by caller/called for threshold detection (e.g., "alert if same caller has >X failures"). Use CDR Summary reports for aggregated data.}}


<syntaxhighlight lang="bash">
== Troubleshooting ==
# Create the file (your SMTP username and password)
echo "[smtp.yourprovider.com]:587 username:password" | sudo tee /etc/postfix/sasl_passwd


# Secure the file (rw root only)
=== Email Not Sent ===
sudo chmod 600 /etc/postfix/sasl_passwd


# Create the Postfix hash database
'''Diagnosis:'''
sudo postmap /etc/postfix/sasl_passwd
* Entries in "Sent Alerts" but no email → MTA issue
 
* No entries in "Sent Alerts" → Alert conditions or cron issue
# Reload Postfix
sudo systemctl reload postfix
</syntaxhighlight>
 
4. Test email delivery:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
echo "Test email" | mail -s "SMTP Relay Test" your.email@example.com
# Test MTA
</syntaxhighlight>
echo "Test" | mail -s "Test" your@email.com


If successful, emails should be delivered through the authenticated SMTP relay.
# Check MTA status
systemctl status postfix  # or exim4/sendmail


==== Step 5: Verify Cronjob ====
# Check logs
tail -f /var/log/mail.log  # Debian/Ubuntu
tail -f /var/log/maillog  # RHEL/CentOS


Ensure the alert processing script runs every minute:
# Check mail queue
 
mailq
<syntaxhighlight lang="bash">
# Check current crontab
crontab -l
</syntaxhighlight>
</syntaxhighlight>


You should see:
'''Status 250 or "Queued mail for delivery"''' = Your server delivered successfully. If recipient didn't receive, issue is on their side (spam folder, quarantine, blacklisting).
<syntaxhighlight lang="bash">
'''Mail Queue Not Delivering:'''
* * * * * root php /var/www/html/php/run.php cron
If emails accumulate in the queue but are not being sent:
</syntaxhighlight>


If missing, add it:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
crontab -e
# Verify queue manager is running
# Add the line above, then reload cron
ps aux | grep qmgr
killall -HUP cron
</syntaxhighlight>
 
==== Step 6: Verify Alert Configuration in GUI ====
 
After confirming the MTA works:
# Navigate to '''GUI > Alerts'''
# Verify alert conditions are enabled
# Check that recipient email addresses are valid
# Go to '''GUI > Alerts > Sent Alerts''' to see if alerts were triggered
 
'''Diagnosis:'''
* Entries in "Sent Alerts" but no emails received → MTA issue
* No entries in "Sent Alerts" → Check alert conditions or cronjob


==== Step 7: Test PHP mail() Function ====
# Restart Postfix
systemctl restart postfix


Isolate the issue by testing PHP directly:
# Force immediate delivery of queued emails
 
postfix flush
<syntaxhighlight lang="bash">
php -r "mail('your.email@example.com', 'Test from PHP', 'This is a test email');"
</syntaxhighlight>
</syntaxhighlight>
=== Alerts Not Triggering ===


* If this works but VoIPmonitor alerts don't → Check GUI cronjob and alert configuration
'''Enable debug logging:'''
* If this fails → MTA or PHP configuration issue
 
=== Troubleshooting Alerts Not Triggering ===
 
If alerts are not appearing in the '''Sent Alerts''' history at all, the problem is typically with the alert processor not evaluating alerts. This is different from MTA issues where alerts appear in history but emails are not sent.
 
==== Enable Detailed Alert Processing Logs ====
 
To debug why alerts are not being evaluated, enable detailed logging for the alert processor by adding the following line to your GUI configuration file:
 
<syntaxhighlight lang="bash">
# Edit the config file (adjust path based on your GUI installation)
nano ./config/system_configuration.php
</syntaxhighlight>
 
Add this line at the end of the file:
<syntaxhighlight lang="php">
<syntaxhighlight lang="php">
<?php
// Add to ./config/system_configuration.php
define('CRON_LOG_FILE', '/tmp/alert.log');
define('CRON_LOG_FILE', '/tmp/alert.log');
?>
</syntaxhighlight>
</syntaxhighlight>
This enables logging that shows which alerts are being processed during each cron job run.
==== Increase Parallel Processing Threads ====
If you have many alerts or reports, the default number of parallel threads may cause timeout issues. Increase the parallel task limit:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Edit the configuration file
# Monitor processing
nano ./config/configuration.php
tail -f /tmp/alert.log
</syntaxhighlight>
</syntaxhighlight>


Add this line at the end of the file:
'''Common causes:'''
<syntaxhighlight lang="php">
* Cron not running - verify with <code>crontab -l</code>
<?php
* PHP CLI version mismatch - use <code>update-alternatives --set php /usr/bin/php8.x</code>
define('CRON_PARALLEL_TASKS', 8);
* SQL queue growing - DB can't keep up (see [[Scaling]])
?>
* Alert disabled or filter mismatch
</syntaxhighlight>


The value of 8 is recommended for high-load environments. Adjust based on your alert/report volume and server capacity.
=== Concurrent Calls Alerts ===


==== Monitor Alert Processing Logs ====
{| class="wikitable"
|-
! Type !! Data Source !! Aggregation !! Timing
|-
| '''Fraud concurrent calls''' || SIP INVITEs (realtime) || Source IP only || Immediate
|-
| '''Regular concurrent calls''' || CDRs (database) || Source/Dest IP, Domain, Custom || Delayed
|}


After enabling logging, monitor the alert log file to see which alerts are being processed:
Use regular concurrent calls for destination IP monitoring (trunk capacity).
'''Investigating Fraud: Realtime Concurrent Calls Alerts'''


<syntaxhighlight lang="bash">
Since this alert type triggers before CDRs are written, use the following procedure to investigate the calls that triggered the alert:
# Watch the log in real-time
# Navigate to '''GUI → CDR'''
tail -f /tmp/alert.log
# Use the filter form to add the '''is international''' filter
</syntaxhighlight>
# Set the '''from''' and '''to''' date range to match the time the alert was sent
# Go to the bottom of the CDR view and enable grouping by '''country'''
# Analyze the traffic by country to identify the source of the fraudulent activity
=== External Script Not Running ===


The log shows entries like:
# Use '''preview button''' to test alert triggers
<syntaxhighlight lang="text">
# Verify absolute path (not relative)
begin alert [alert_name]
# Check permissions: <code>chmod 755 /path/to/script.sh</code>
end alert [alert_name]
# Include shebang: <code>#!/bin/bash</code>
</syntaxhighlight>
# Use full command paths (e.g., <code>/usr/bin/curl</code>)
# For URLs, create script with curl/wget - cannot put URL directly in field


'''Interpreting the logs:'''
=== "Crontab Log Too Old" Warning ===
* If you '''do not see''' your alert name in the logs → The alert processor is not evaluating it. Check your alert configuration, filters, and data availability.
* If you '''see''' the alert in logs but it does not trigger → The alert conditions are not being met. Check your thresholds, filter logic, and verify the CDR data matches your expectations.
* If logs are completely empty → The cron job may not be running or the GUI configuration files are not being loaded. Verify the cron job and file paths.


==== Alert Not Appearing in Logs ====
'''Causes:'''
# Cron not running → Add cron entry
# PHP CLI version mismatch → <code>update-alternatives --set php /usr/bin/php8.x</code>
# Database overload → Check SQLq in '''GUI > Settings > Sensors''', see [[Scaling]]


If your alert does not appear in `/tmp/alert.log`:
== See Also ==


1. '''Verify the cron job is running:'''
* [[Anti-fraud|Anti-Fraud Rules]] - Realtime fraud detection
<syntaxhighlight lang="bash">
* [[Reports]] - Daily reports and report generator
# Check the cron job exists
* [[Groups]] - IP and number groups for filtering
crontab -l


# Manually test the cron script to see errors
php ./php/run.php cron
</syntaxhighlight>


2. '''Verify data exists in CDR:'''
<syntaxhighlight lang="bash">
# Check if the calls that should trigger the alert exist
# Navigate to GUI > CDR > Browse and filter for the timeframe
</syntaxhighlight>


3. '''Check alert configuration:'''
* Verify alert is enabled
* Verify filter logic matches your data (IP addresses, numbers, groups)
* Verify thresholds are reasonable for the actual QoS metrics
* Verify GUI license is not locked (Check '''GUI > Settings > License''')


=== See Also ===


* [[Anti-fraud|Anti-Fraud Rules]] - Detailed fraud detection configuration
* [[Reports|Reports]] - Daily reports and report generator
* [[Sniffer_troubleshooting|Sniffer Troubleshooting]] - General troubleshooting


== AI Summary for RAG ==
== AI Summary for RAG ==


'''Summary:''' VoIPmonitor Alerts & Reports system for email notifications on QoS and SIP issues. Covers RTP alerts (MOS, jitter, packet loss), SIP response alerts, sensors health monitoring, SIP REGISTER RRD beta alerts for monitoring registration response times, and creating alerts from custom reports based on CDR custom headers. Includes email troubleshooting for MTA configuration, detailed debugging for alerts not triggering using CRON_LOG_FILE and CRON_PARALLEL_TASKS, and external scripts for webhook integration (Datadog, Slack, third-party monitoring).
'''Summary:''' VoIPmonitor Alerts system provides email notifications for QoS thresholds (RTP: MOS, jitter, packet loss), SIP response codes (0=no response, 408=timeout), sensor health, and registration monitoring. Alert types include RTP, RTP&CDR (with filter templates for duration/absolute_timeout), SIP Response (use "from all" unchecked for IP group percentages), International Calls (prefix-based, NOT GeoIP), Sensors, SIP REGISTER alerts (RRD beta for latency, failed Register beta for brute-force, multiple register beta for credential compromise), and CDR Trends (ASR deviation monitoring). External scripts enable webhook integrations. CRITICAL: Alerts use OR logic only - AND not supported. IP addresses stored as integers - use long2ip()/INET_NTOA() for conversion.


'''Keywords:''' alerts, email notifications, QoS, MOS, jitter, packet loss, SIP response, sensors monitoring, SIP REGISTER RRD beta, REGISTER retransmissions, registration monitoring, crontab, MTA, Postfix, Exim, troubleshooting, custom headers, custom reports, Max-Forwards, daily reports, CRON_LOG_FILE, CRON_PARALLEL_TASKS, alert not triggering, /tmp/alert.log, begin alert, end alert, configuration.php, system_configuration.php, external scripts, webhooks, Datadog, Slack, command-line arguments, JSON data, CDR array
'''Keywords:''' alerts, email notifications, QoS, MOS, jitter, packet loss, SIP response, 408 timeout, sensors monitoring, SIP REGISTER, brute force, credential stuffing, international calls, called number prefixes, CDR trends, ASR, external scripts, webhooks, from all checkbox, OR logic, crontab, MTA, Postfix, CRON_LOG_FILE, concurrent calls, SQL queue


'''Key Questions:'''
'''Key Questions:'''
* How do I set up email alerts in VoIPmonitor?
* How do I configure email alerts in VoIPmonitor?
* What types of alerts are available (RTP, SIP, Sensors, REGISTER RRD beta)?
* What alert types are available (RTP, SIP, Sensors)?
* How do I monitor and alert on SIP REGISTER retransmissions?
* How do I configure international call alerts with prefix filtering?
* How do I detect registration response time issues?
* What does the "from all" checkbox do in percentage alerts?
* How can I use SIP REGISTER RRD beta alert for detecting switch problems?
* How do I integrate alerts with webhooks (Slack, Datadog)?
* How do I configure crontab for alert processing?
* Why are my alerts not triggering?
* How do I monitor remote sensor health?
* How do I troubleshoot email delivery issues?
* Why are email alerts not being sent?
* What is the difference between fraud and regular concurrent calls alerts?
* How do I troubleshoot MTA email issues?
* How do I detect SIP registration attacks (brute-force)?
* How can I create alerts based on SIP headers like Max-Forwards?
* Do alerts support AND logic between conditions?
* How do I use CDR custom headers for custom reports?
* How do I limit the size of alert emails from custom reports?
* Why are alerts not triggering or appearing in Sent Alerts?
* How do I enable detailed alert processing logs using CRON_LOG_FILE?
* How do I increase parallel alert processing threads with CRON_PARALLEL_TASKS?
* How do I monitor /tmp/alert.log for alert processing debug information?
* How do I configure external scripts for alerts?
* How do I send webhooks from VoIPmonitor alerts to Datadog?
* How do I send alerts to Slack from VoIPmonitor?
* What command-line arguments are passed to alert scripts?
* What JSON data structure is provided to external scripts?

Latest revision as of 10:34, 17 January 2026


Alerts & Reports

Email notifications triggered by QoS thresholds, SIP errors, or sensor health conditions. The system stores all alerts in history for review.

Prerequisites

Email Configuration

Alerts use PHP's mail() function via the server's MTA (Postfix/Exim/Sendmail).

Setting Location Description
From Address GUI > Settings > System Configuration > Email DEFAULT_EMAIL_FROM - sender address for all alerts
Cron Job /etc/crontab Required for alert processing 
# Add cron job (required)
echo "* * * * * root php /var/www/html/php/run.php cron" >> /etc/crontab
killall -HUP cron   # Debian/Ubuntu
# or: killall -HUP crond  # RHEL/CentOS

Alert Types

Access via GUI > Alerts.

RTP Alerts

Trigger on voice quality metrics:

  • MOS - below threshold
  • Packet loss - percentage exceeded
  • Jitter - variation exceeded
  • Delay (PDV) - latency exceeded
  • One-way calls - one RTP stream missing
  • Missing RTP - both RTP streams missing

Configure alerts to trigger when number of incidents OR percentage of CDRs exceeds threshold.

RTP&CDR Alerts

Combine RTP metrics with CDR conditions including PDD (Post Dial Delay).

Using Filter Templates:

  1. Create CDR filter in GUI > CDR
  2. Save as template
  3. In alert config, select from Filter template dropdown

💡 Tip: Use filter templates for complex conditions like duration > 14400 (calls over 4 hours) or absolute_timeout (truncated recordings).

SIP Response Alerts

Response Code Meaning
Empty All call attempts per filters
0 No response received (routing loops)
408 Timeout after provisional response (server unresponsive)
Specific Exact codes (404, 503, etc.)

"from all" Checkbox (Percentage Thresholds)

⚠️ Warning: This setting is critical for IP group monitoring.

  • CHECKED: % calculated from ALL CDRs in database
  • UNCHECKED: % calculated only from filtered CDRs (correct for specific IP groups)


SIP Response vs Last SIP Response

There are two different fields for matching SIP responses:

Field Location Supports % Threshold Use Case
SIP response GUI > Alerts > SIP Response Alerts ✓ Yes Match by numeric code (e.g., 487, 503)
Last sip response GUI > Alerts > Filter common ✗ No Match by full text (e.g., "487 Request Terminated")

⚠️ Warning: The GUI cannot trigger alerts based on percentage of full textual response strings. If you need percentage-based triggering for SIP response codes, use the SIP response numeric field instead.

The Last sip response field supports wildcard patterns (%, %Request Terminated%, %487%) but only triggers based on count thresholds, not percentages.

International Call Alerts (Called Number Prefixes)

Monitor calls to international destinations using prefix-based matching (dialing patterns like 00, +).

ℹ️ Note: This uses phone number prefix detection, NOT IP geolocation. For GeoIP-based detection, see Anti-Fraud Rules.

Configuration:

  1. GUI > Settings > Country prefixes - Define international prefixes (00, +), local country, minimum digits
  2. GUI > Alerts > Filter common - Configure:
Setting Description
Called number prefixes Which prefixes trigger alert (uncheck ALL for all international)
Exclude called number Country codes to exclude (e.g., +44, 0044 for UK)
Strict for prefixes Require international prefix (00/+)
NANPA North American Numbering Plan

Sensors Alerts

Monitor sensor health and status:

  • Offline detection - Sensor not communicating
  • Old CDR - No recent CDRs written (capture or DB issue)
  • Big SQL queue stat - Growing queue indicates DB bottleneck (warning: >20 files, critical: >100)

SIP REGISTER Alerts

Alert Type Purpose Use Case
SIP REGISTER RRD beta Response time monitoring Network latency, packet loss
SIP failed Register (beta) Failed registrations by IP Brute-force, credential stuffing
multiple register (beta) Same account from multiple IPs Credential compromise detection

⚠️ Warning: multiple register (beta) detects SIMULTANEOUS registrations from multiple IPs (security). For detecting IP changes when device moves networks, use CDR&RTP alert with external script.


Alert Output Fields

The multiple register (beta) and other SIP REGISTER alerts output the following fields in email notifications and GUI:

Field Source Description
username SIP Contact header The registered user identity
from fields SIP From header From-number, From-domain extracted from From header
to fields SIP To header To-number, To-domain extracted from To header
lookup name Tools > Prefix Lookup Custom label if phone number matches a configured prefix entry

ℹ️ Note: The lookup name column displays custom labels from Prefix Lookup when a phone number matches a configured prefix. If no match exists, the field remains empty or shows the raw number.

CDR Trends Alerts

Monitor metric deviations from historical baselines (e.g., ASR drops).

Parameter Description
Type Metric to monitor (ASR, ACD, etc.)
Offset Historical baseline (1 week, 1 day)
Range Current evaluation window (1 hour)
Method Deviation (%) or Threshold (absolute)
Limit Inc./Dec. Trigger threshold percentage

Common Filters

All alert types support:

  • IP/Number Group - Predefined groups from Groups menu
  • IP Addresses / Numbers - Individual values (one per line)
  • Email Group / Emails - Recipients
  • Last sip response - Filter by response text (requires save_sip_history = responses)
  • External script - Custom script path for integrations

⚠️ Warning: Alerts use OR logic between conditions. AND logic is NOT supported. Workaround: create separate alerts and correlate manually.

Caller vs Called Filtering

The Numbers filter matches against both caller and called fields. You cannot create alerts that trigger only when a number is the caller or only the called. Use IP Groups with Trunk/Server checkboxes for direction-based filtering. See Groups.

External Scripts

Enable webhook integration (Datadog, Slack, custom systems).

Configuration: Enter full absolute path in External script field (e.g., /usr/local/bin/alert-webhook.sh).

Arguments passed to script:

Arg Description
$1 Alert ID
$2 Alert name
$3 Unix timestamp
$4 JSON data with CDR IDs

Example - Slack notification: 

#!/bin/bash
# /usr/local/bin/slack-alert.sh
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
curl -X POST "$SLACK_WEBHOOK" -H "Content-Type: application/json" \
  -d '{"text": "VoIPmonitor Alert: '"$2"'"}'

ℹ️ Note: IP addresses in CDR table are decimal integers. Use long2ip() (PHP) or INET_NTOA() (MySQL) for conversion.

Sent Alerts

View triggered alerts via GUI > Alerts > Sent Alerts. Shows:

  • Parameters table - QoS metrics with highlighted bad values
  • CDR records - Calls that triggered alert with flags: (M)OS, (J)itter, (P)acket loss, (D)elay

Custom Report Alerts

Alert on criteria not in native types (e.g., custom SIP headers).

Workflow:

  1. Capture header in /etc/voipmonitor.conf: custom_headers = Max-Forwards
  2. Enable in GUI > Settings > CDR Custom Headers
  3. Create filter in CDR view, save as template
  4. Create Daily Report with filter in GUI > Reports > Configure Daily Reports

ℹ️ Note: Custom report alerts cannot group by caller/called for threshold detection (e.g., "alert if same caller has >X failures"). Use CDR Summary reports for aggregated data.

Troubleshooting

Email Not Sent

Diagnosis:

  • Entries in "Sent Alerts" but no email → MTA issue
  • No entries in "Sent Alerts" → Alert conditions or cron issue
# Test MTA
echo "Test" | mail -s "Test" your@email.com

# Check MTA status
systemctl status postfix  # or exim4/sendmail

# Check logs
tail -f /var/log/mail.log  # Debian/Ubuntu
tail -f /var/log/maillog   # RHEL/CentOS

# Check mail queue
mailq

Status 250 or "Queued mail for delivery" = Your server delivered successfully. If recipient didn't receive, issue is on their side (spam folder, quarantine, blacklisting). Mail Queue Not Delivering: If emails accumulate in the queue but are not being sent: 

# Verify queue manager is running
ps aux | grep qmgr

# Restart Postfix
systemctl restart postfix

# Force immediate delivery of queued emails
postfix flush

Alerts Not Triggering

Enable debug logging: 

// Add to ./config/system_configuration.php
define('CRON_LOG_FILE', '/tmp/alert.log');

# Monitor processing
tail -f /tmp/alert.log

Common causes:

  • Cron not running - verify with crontab -l
  • PHP CLI version mismatch - use update-alternatives --set php /usr/bin/php8.x
  • SQL queue growing - DB can't keep up (see Scaling)
  • Alert disabled or filter mismatch

Concurrent Calls Alerts

Type Data Source Aggregation Timing
Fraud concurrent calls SIP INVITEs (realtime) Source IP only Immediate
Regular concurrent calls CDRs (database) Source/Dest IP, Domain, Custom Delayed

Use regular concurrent calls for destination IP monitoring (trunk capacity). Investigating Fraud: Realtime Concurrent Calls Alerts

Since this alert type triggers before CDRs are written, use the following procedure to investigate the calls that triggered the alert:

  1. Navigate to GUI → CDR
  2. Use the filter form to add the is international filter
  3. Set the from and to date range to match the time the alert was sent
  4. Go to the bottom of the CDR view and enable grouping by country
  5. Analyze the traffic by country to identify the source of the fraudulent activity

External Script Not Running

  1. Use preview button to test alert triggers
  2. Verify absolute path (not relative)
  3. Check permissions: chmod 755 /path/to/script.sh
  4. Include shebang: #!/bin/bash
  5. Use full command paths (e.g., /usr/bin/curl)
  6. For URLs, create script with curl/wget - cannot put URL directly in field

"Crontab Log Too Old" Warning

Causes:

  1. Cron not running → Add cron entry
  2. PHP CLI version mismatch → update-alternatives --set php /usr/bin/php8.x
  3. Database overload → Check SQLq in GUI > Settings > Sensors, see Scaling

See Also




AI Summary for RAG

Summary: VoIPmonitor Alerts system provides email notifications for QoS thresholds (RTP: MOS, jitter, packet loss), SIP response codes (0=no response, 408=timeout), sensor health, and registration monitoring. Alert types include RTP, RTP&CDR (with filter templates for duration/absolute_timeout), SIP Response (use "from all" unchecked for IP group percentages), International Calls (prefix-based, NOT GeoIP), Sensors, SIP REGISTER alerts (RRD beta for latency, failed Register beta for brute-force, multiple register beta for credential compromise), and CDR Trends (ASR deviation monitoring). External scripts enable webhook integrations. CRITICAL: Alerts use OR logic only - AND not supported. IP addresses stored as integers - use long2ip()/INET_NTOA() for conversion.

Keywords: alerts, email notifications, QoS, MOS, jitter, packet loss, SIP response, 408 timeout, sensors monitoring, SIP REGISTER, brute force, credential stuffing, international calls, called number prefixes, CDR trends, ASR, external scripts, webhooks, from all checkbox, OR logic, crontab, MTA, Postfix, CRON_LOG_FILE, concurrent calls, SQL queue

Key Questions:

  • How do I configure email alerts in VoIPmonitor?
  • What alert types are available (RTP, SIP, Sensors)?
  • How do I configure international call alerts with prefix filtering?
  • What does the "from all" checkbox do in percentage alerts?
  • How do I integrate alerts with webhooks (Slack, Datadog)?
  • Why are my alerts not triggering?
  • How do I troubleshoot email delivery issues?
  • What is the difference between fraud and regular concurrent calls alerts?
  • How do I detect SIP registration attacks (brute-force)?
  • Do alerts support AND logic between conditions?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Alerts&oldid=10738"