Cloud: Difference between revisions

From VoIPmonitor.org
(Review: přidán diagram architektury, oprava konfiguračního příkladu (odstraněn nesprávný [general] header))
(Rewrite: improved structure - specs upfront, architecture before quick start, condensed AWS section, clearer troubleshooting)
Line 1: Line 1:
= VoIPmonitor Cloud Service Architecture =
= VoIPmonitor Cloud Service =


This document details the architecture of the '''VoIPmonitor Cloud Service'''. In this service model, the customer is responsible only for running the on-premise sniffer, while the database and web GUI are hosted and managed by VoIPmonitor.
The '''VoIPmonitor Cloud Service''' is a managed hosting model where you run only the on-premise sniffer, while VoIPmonitor hosts and manages the database and web GUI.


== Quick Start: Getting Started with Cloud Service ==
== Service Specifications ==


'''Free 30-Day Trial:'''
{| class="wikitable"
! Specification !! Value
|-
| Max Concurrent Channels || 2000
|-
| CDR Retention || 25 days
|-
| PCAP Storage || Local only (on sniffer, not in cloud)
|}


If you do not have a VoIPmonitor Cloud Service license, you can try the cloud GUI free for 30 days. To start your trial:
{{Note|If your requirements exceed these limits, consider an on-premise deployment.}}


# Log in to the VoIPmonitor client area at https://www.voipmonitor.org/portal/
== Architecture ==
# Navigate to the '''my services''' section
# Order the free 30-day trial for the cloud GUI service
# The trial gives you full access to all cloud features for 30 days


After ordering the trial, follow the steps below to connect your server.
<kroki lang="mermaid">
%%{init: {'flowchart': {'nodeSpacing': 15, 'rankSpacing': 40}}}%%
flowchart LR
    subgraph Customer["Customer Network"]
        S1[Sniffer 1]
        S2[Sniffer 2]
        PBX[PBX/SIP Server]
    end


== Quick Start: Connecting Your On-Premise Server to the Cloud ==
    subgraph Cloud["VoIPmonitor Cloud"]
        DB[(Database)]
        GUI[Web GUI]
    end


This is the fastest and recommended way to connect your on-premise VoIP server (or PBX) to the hosted VoIPmonitor cloud GUI.
    PBX -->|Traffic| S1
    PBX -->|Traffic| S2
    S1 -->|CDR Metadata| DB
    S2 -->|CDR Metadata| DB
    DB --> GUI
    GUI -->|On-demand PCAP| S1
    GUI -->|On-demand PCAP| S2
</kroki>


=== Automated Installation Script Method (Recommended) ===
=== Data Flow ===


This method requires only 3 steps and automatically configures your sniffer to send data to the cloud GUI.
* '''Sniffer (Client):''' Captures and processes VoIP traffic locally. Multiple sniffers can connect from different locations.
* '''Cloud (Server):''' Hosts the database (CDR metadata) and web GUI for analysis and reporting.


;Step 1: Download the Installation Script
=== How Data is Transferred ===
* Log in to the '''VoIPmonitor Portal''' at https://www.voipmonitor.org/portal/
* Navigate to the '''my services''' section
* Find your Cloud service (trial or licensed) and locate the '''Cloud Service installation script'''
* Download the script (it will be a small shell script with a .sh extension)


;Step 2: Run the Script on Your Sniffer Server
;Standard Mode (Default)
* Upload or copy the script to your sniffer server (the machine that will capture VoIP traffic)
The sniffer analyzes traffic locally and sends '''only CDR metadata''' to the cloud. Voice packets (PCAP) are discarded after analysis. This minimizes bandwidth usage.
* Make the script executable and run it with root or sudo privileges:
 
;On-Demand PCAP Retrieval
If packet capture is enabled via [[Capture_rules|Capture Rules]], PCAPs are stored '''locally on the sniffer'''. When a user requests a PCAP through the cloud GUI, the file streams directly from the sniffer to the user's browser - it is never uploaded to the cloud.
 
== Quick Start ==
 
=== Free Trial ===
 
# Log in to [https://www.voipmonitor.org/portal/ VoIPmonitor Portal]
# Navigate to '''my services'''
# Order the free 30-day Cloud GUI trial
 
=== Method 1: Installation Script (Recommended) ===
 
# Download the installation script from VoIPmonitor Portal ('''my services''' > your Cloud service)
# Run on your sniffer server:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
chmod +x voipmonitor-cloud-install.sh
chmod +x voipmonitor-cloud-install.sh
Line 38: Line 72:
</syntaxhighlight>
</syntaxhighlight>


The script will automatically:
The script automatically installs and configures everything.
* Download and install the latest voipmonitor sniffer binary
* Configure <code>voipmonitor.conf</code> with the correct cloud server settings
* Set up the service to start automatically
* Connect to your cloud account using your license key


;Step 3: Verify Connection
=== Method 2: Manual Configuration ===
* After the script completes, wait a few seconds for the sensor to register
* Log in to your VoIPmonitor Cloud GUI
* Your sensor should automatically appear in the dashboard


This is the recommended method as it eliminates manual configuration errors and ensures all settings are correct.
Edit <code>/etc/voipmonitor.conf</code>:
 
=== Manual Configuration Method ===
 
If you prefer to configure your sniffer manually (for example, if you already have voipmonitor installed and want to keep your existing setup), you must manually edit <code>voipmonitor.conf</code> to set the cloud server destination and enable packet sender mode.
 
Required configuration in <code>/etc/voipmonitor.conf</code>:


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
Line 62: Line 83:
packetbuffer_sender = yes
packetbuffer_sender = yes
</syntaxhighlight>
</syntaxhighlight>
After making these changes, restart the voipmonitor service:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
Line 69: Line 88:
</syntaxhighlight>
</syntaxhighlight>


Then verify your sensor appears in the VoIPmonitor Cloud GUI dashboard.
{{Tip|For general client-server architecture details, see [[Sniffer_distributed_architecture]].}}
 
== Cloud Service on AWS: Resource Configuration ==
 
When deploying the VoIPmonitor sniffer on AWS EC2 instances (for example, for a hosted SIP server like Brekeke), it is important to configure resource limits properly to prevent memory exhaustion and ensure stable operation.
 
AWS environments have finite CPU, RAM, and disk resources. If VoIPmonitor is not properly configured, it can consume all available memory, leading to packet loss, service crashes, or performance degradation on the host system.
 
=== Required Configuration Parameters ===
 
Add these settings to <code>/etc/voipmonitor.conf</code> on your AWS EC2 instance:
 
==== Ringbuffer Configuration ====
 
<code>ringbuffer</code> controls the size of the packet capture ring buffer in memory. Larger values help handle traffic bursts but consume more RAM.
 
<syntaxhighlight lang="ini">
ringbuffer = 500
</syntaxhighlight>
 
'''Recommended values based on traffic volume:'''
 
* '''10-100 Mbit traffic''': <code>ringbuffer = 50-100</code>
* '''100-500 Mbit traffic''': <code>ringbuffer = 500-1000</code>
* '''500+ Mbit traffic''': <code>ringbuffer = 1000-2000</code> (maximum allowed)
 
'''AWS Note:''' If you are running VoIPmonitor on the same EC2 instance as your PBX/SIP server, be conservative with ringbuffer to avoid starving the PBX of memory.
 
==== Memory Buffer Limit ====
 
<code>max_buffer_mem</code> limits the total memory VoIPmonitor can use for packet buffers. This prevents the service from consuming all available system RAM.
 
<syntaxhighlight lang="ini">
max_buffer_mem = 2000
</syntaxhighlight>
 
'''Default value:''' 2000 (MB)


'''AWS Considerations:'''
== AWS EC2 Configuration ==
* On EC2 instances with limited RAM (e.g., t3.small with 2GB), reduce this value (e.g., <code>max_buffer_mem = 500</code>)
* On larger instances (e.g., m5.large with 8GB or more), the default value is typically acceptable
* Monitor memory usage with <code>htop</code> or AWS CloudWatch metrics after deployment


==== Spooldir Configuration ====
When deploying on AWS, configure resource limits to prevent memory exhaustion and disk full conditions.


<code>spooldir</code> defines the directory where captured packet files (PCAPs) are stored. AWS EC2 instances typically use ephemeral instance store or EBS volumes.
=== Required Parameters ===
 
<syntaxhighlight lang="ini">
spooldir = /var/spool/voipmonitor
</syntaxhighlight>
 
'''AWS Best Practices:'''
 
* Use EBS volumes (gp3 or io2) for durable storage. Instance store is lost if the instance stops.
* Ensure the volume has sufficient IOPS for your workload:
** For low traffic (under 10 concurrent calls): <code>gp2</code> or general purpose <code>gp3</code>
** For high traffic (50+ concurrent calls): <code>gp3</code> with provisioned IOPS or <code>io2</code> volume type
* Mount EBS volume to <code>/var/spool/voipmonitor</code> or configure alternative spooldir location
 
Example: Using EBS volume mounted at <code>/mnt/voipmonitor</code>:
<syntaxhighlight lang="ini">
spooldir = /mnt/voipmonitor
</syntaxhighlight>
 
==== Storage Pool Size Limit ====
 
<code>maxpoolsize</code> sets the maximum disk space (in MB) that VoIPmonitor will use for PCAP files before the auto-cleanup process removes old files.
 
<syntaxhighlight lang="ini">
maxpoolsize = 204800
</syntaxhighlight>
 
'''Default behavior:''' If unset, VoIPmonitor continues writing until the disk is full, which can cause the system to crash.
 
'''AWS Environment Recommendations:'''


{| class="wikitable"
{| class="wikitable"
! EC2 Instance Size !! Typical EBS Volume Size !! Recommended maxpoolsize
! Parameter !! Purpose !! Recommended Value
|-
|-
| t3.small (2GB RAM) || 20-50 GB gp3 || <code>maxpoolsize = 40960</code> (20 GB) or higher
| <code>ringbuffer</code> || Packet capture buffer size (MB) || 50-100 (low traffic), 500-1000 (medium), 1000-2000 (high)
|-
|-
| m5.large (8GB RAM) || 100-200 GB gp3/io2 || <code>maxpoolsize = 102400</code> (100 GB) or higher
| <code>max_buffer_mem</code> || Max memory for buffers (MB) || 500 for t3.small, 2000 for m5.large+
|-
|-
| m5.xlarge (16GB RAM) || 300-500 GB gp3/io2 || <code>maxpoolsize = 204800</code> (200 GB) or higher
| <code>maxpoolsize</code> || Max PCAP storage (MB) || Set to ~80% of available disk
|-
|-
| Custom/high traffic || 500+ GP3/io2 || <code>maxpoolsize = 307200</code> (300 GB) or higher
| <code>spooldir</code> || PCAP storage path || Use EBS volume (gp3/io2), not instance store
|}
|}


* Always set <code>maxpoolsize</code> to leave some free space for OS and logs (at least 10-20% of total disk space)
{{Warning|1=Always set <code>maxpoolsize</code> - without it, VoIPmonitor will fill the disk until the system crashes.}}
* Monitor disk usage with: <code>df -h /var/spool/voipmonitor</code>
* Consider <code>maxpooldays</code> as an alternative cleanup strategy (based on time vs. size):
<syntaxhighlight lang="ini">
maxpooldays = 30
</syntaxhighlight>


=== Complete Example Configuration for AWS ===
=== Example AWS Configuration ===


Here is a complete AWS-optimized configuration for a medium-workload instance (m5.large, 8GB RAM, 100 GB EBS gp3 volume):
For m5.large (8GB RAM, 100GB EBS gp3):


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# Cloud connection settings
# Cloud connection
server_destination = cloud.voipmonitor.org
server_destination = cloud.voipmonitor.org
server_destination_port = 60023
server_destination_port = 60023
packetbuffer_sender = yes
packetbuffer_sender = yes


# Sensor identification
# Sensor ID
id_sensor = 1
id_sensor = 1


Line 180: Line 126:
interface = eth0
interface = eth0


# AWS Resource Limits
# AWS resource limits
ringbuffer = 500
ringbuffer = 500
max_buffer_mem = 2000
max_buffer_mem = 2000
# Storage settings (adjust paths if using EBS mount)
spooldir = /var/spool/voipmonitor
spooldir = /var/spool/voipmonitor
maxpoolsize = 102400
maxpoolsize = 102400
</syntaxhighlight>
</syntaxhighlight>


=== AWS License Configuration ===
=== AWS License Fix ===


When deploying VoIPmonitor on AWS EC2 instances, you must configure the system to allow license checks to function correctly. AWS instances may have restricted access to certain device files that are used for license validation.
AWS EC2 instances require this permission for license checks:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# On AWS EC2 instances, allow license checks by setting correct permissions
chmod 644 /dev/root
chmod 644 /dev/root
</syntaxhighlight>
</syntaxhighlight>


{{Warning|The <code>chmod 644 /dev/root</code> command is required for AWS EC2 instances to allow VoIPmonitor license activation and validation. Without this permission, the license check may fail and the GUI will display licensing errors.}}
== Troubleshooting ==
 
=== Monitoring and Debugging in AWS ===


;Check resource usage:
=== Sensor Not Appearing in Cloud ===
<syntaxhighlight lang="bash">
# Check memory usage
free -h


# Check disk usage on spooldir
;First-Time Setup: Initialize Database
df -h /var/spool/voipmonitor
If you see '''failed read rsa key''' or '''loss connection''' errors, you must first log in to the Cloud GUI to initialize your database:


# Check VoIPmonitor service status
# Log in to [https://cloud.voipmonitor.org Cloud GUI] with your portal credentials
systemctl status voipmonitor
# This creates the necessary database tables
# Restart the sniffer: <code>systemctl restart voipmonitor</code>
# Verify sensor appears green in '''Settings -> Sensors'''


# View real-time logs for buffer issues
;Verify Configuration
journalctl -u voipmonitor -f | grep -i "buffer\|memory\|full"
</syntaxhighlight>
 
;Common AWS-Specific Issues:
 
;Out of Memory Errors:
* Symptoms: VoIPmonitor process killed by OOM (Out of Memory) killer
* Solution: Reduce <code>max_buffer_mem</code> and/or <code>ringbuffer</code>, or upgrade to a larger EC2 instance
 
;Disk Full Errors:
* Symptoms: System becomes unresponsive, "No space left on device"
* Solution: Always configure <code>maxpoolsize</code> or <code>maxpooldays</code> to prevent uncontrolled growth
 
;High CPU Usage:
* Symptoms: Packet drops in logs, slow UI response
* Solution: Increase EC2 vCPU count or optimize <code>sipport</code> and capture filters
 
== Service Specifications ==
 
The VoIPmonitor Cloud Service has the following service limits and specifications:
 
* '''Concurrent Channels Maximum:''' The service supports up to '''2000 concurrent channels'''.
* '''CDR Retention Period:''' Call Detail Records (CDRs) are retained for '''25 days''' in the cloud database.
* '''PCAP Storage Location:''' SIP+RTP packet storage (PCAP files) is NOT stored in the cloud. If packet capture storage is enabled, all PCAP files are stored on the '''local sniffer's storage''' only.
 
These limits are fixed and apply to all Cloud Service customers. If your requirements exceed these specifications, consider an on-premise VoIPmonitor deployment.
 
== Core Architecture: Client-Server Model ==
 
The architecture separates the data capture process (on-premise) from the data storage and analysis interface (in the cloud).
 
<kroki lang="mermaid">
%%{init: {'flowchart': {'nodeSpacing': 15, 'rankSpacing': 40}}}%%
flowchart LR
    subgraph Customer["Customer Network"]
        S1[Sniffer 1]
        S2[Sniffer 2]
        PBX[PBX/SIP Server]
    end
 
    subgraph Cloud["VoIPmonitor Cloud"]
        DB[(Database)]
        GUI[Web GUI]
    end
 
    PBX -->|Traffic| S1
    PBX -->|Traffic| S2
    S1 -->|CDR Metadata| DB
    S2 -->|CDR Metadata| DB
    DB --> GUI
    GUI -->|On-demand PCAP| S1
    GUI -->|On-demand PCAP| S2
</kroki>
 
*  '''Sniffer (Client):''' A VoIPmonitor sniffer runs on the customer's network (either on a dedicated machine or the PBX itself). Its only job is to capture and process VoIP traffic locally. Multiple sniffers can be deployed across various locations.
*  '''Cloud Platform (Server):''' The central database (storing call metadata) and the web GUI are hosted and managed by VoIPmonitor. All user interaction, analysis, and reporting is done through this central cloud interface.
 
=== Data Flow from Sniffer to Cloud ===
 
The key aspect of the cloud architecture is how data is transmitted from the customer's sniffer to the hosted server. The system primarily operates in one of two modes.
 
==== 1. Standard Mode: Local Processing & CDR Upload ====
 
This is the default and most efficient mode. The on-premise sniffer captures all VoIP traffic, analyzes it locally, and generates a '''Call Detail Record (CDR)''' for each call.
 
*  The sniffer sends '''only the CDR metadata''' to the cloud database.
*  The actual voice packets (PCAP) are '''not''' sent to the cloud; they are discarded after local analysis.
 
This model ensures minimal bandwidth usage, as only small metadata files are transferred over the internet.
 
==== 2. Optional Mode: On-Demand Packet Capture Retrieval ====
 
For deep diagnostics, users can enable packet capture storage. The process is designed to keep sensitive data on-premise unless explicitly needed.
 
# '''Selective Local Storage:''' Storing packet captures is not an all-or-nothing feature. The user defines granular '''Capture Rules''' to control exactly which calls are saved. These rules can be based on criteria like IP addresses, telephone numbers, or even specific SIP packet headers. Only calls that match a rule will have their PCAP file saved to the sniffer's '''local disk'''.
# '''On-Demand Request:''' A user can request to download a PCAP file or listen to a call through the cloud web GUI.
# '''Direct Download:''' The cloud platform instructs the sniffer to serve the requested file. The download then occurs directly from the customer's sniffer to the user's browser, bypassing a permanent upload to the cloud.
 
This on-demand mechanism ensures that large and sensitive packet capture files remain within the customer's network perimeter, only traversing the internet when requested by an authorized user.
 
== Troubleshooting: Sensor Not Appearing in Cloud ==
 
If your on-premise sniffer is running but does not appear in the VoIPmonitor Cloud interface, follow these troubleshooting steps.
 
=== Common Issue: ARM64 Cloud Connectivity Bug ===
 
On ARM64 architecture systems (aarch64), certain voipmonitor binary builds have a known cloud connectivity issue where the sensor runs locally but fails to properly handshake with the cloud server.
 
;Symptoms:
:* The <code>voipmonitor</code> process is running and appears active with <code>systemctl status voipmonitor</code>
:* The sensor is capturing traffic locally (check via <code>journalctl -u voipmonitor -f</code>)
:* No sensor appears in your VoIPmonitor Cloud interface
:* Configuration is correct (<code>server_destination</code>, <code>server_destination_port</code>, <code>packetbuffer_sender</code>)
:* Firewall rules allow outbound TCP to port 60023
 
;Solution: Update to the Corrected ARM64 Binary
 
This issue is resolved by downloading and installing a special static binary build that includes the ARM64 cloud connectivity fix.
 
<syntaxhighlight lang="bash">
# 1. Stop the voipmonitor service
systemctl stop voipmonitor
 
# 2. Request the corrected ARM64 static binary from VoIPmonitor support
# The support team will provide a specific download link for the corrected build
# Example URL format:
# wget https://download.voipmonitor.org/path/to/voipmonitor-arm64-fixed.tar.gz
 
# 3. Extract the archive
tar xzf voipmonitor-arm64-fixed.tar.gz
cd voipmonitor-*-static
 
# 4. Backup the existing binary and replace it
mv /usr/local/sbin/voipmonitor /usr/local/sbin/voipmonitor.backup
cp voipmonitor /usr/local/sbin/voipmonitor
 
# 5. Restart the service
systemctl start voipmonitor
 
# 6. Verify the sensor appears in Cloud interface
journalctl -u voipmonitor -f
</syntaxhighlight>
 
;Important Notes:
:* Do NOT compile from source to fix this issue - use the corrected static binary provided by support
:* The fix is specific to ARM64 architecture; x86_64 and 32-bit systems are not affected
:* After installing the corrected binary, the sensor should appear in Cloud within a few seconds
 
=== General Configuration Verification ===
 
If the ARM64 issue is not applicable, verify your cloud connectivity configuration:
 
;1. Check voipmonitor.conf cloud settings:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
grep -E "server_destination|packetbuffer_sender" /etc/voipmonitor.conf
grep -E "server_destination|packetbuffer_sender" /etc/voipmonitor.conf
</syntaxhighlight>
</syntaxhighlight>


Required for VoIPmonitor Cloud:
Required settings:
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
server_destination = cloud.voipmonitor.org
server_destination = cloud.voipmonitor.org
Line 358: Line 165:
</syntaxhighlight>
</syntaxhighlight>


;2. Verify network connectivity to cloud:
;Check Network Connectivity
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Test outbound connection to VoIPmonitor Cloud
nc -zv cloud.voipmonitor.org 60023
nc -zv cloud.voipmonitor.org 60023
</syntaxhighlight>
</syntaxhighlight>


;3. Check for firewall issues:
Ensure outbound TCP to port 60023 is allowed through all firewalls (local, corporate, cloud provider).
* Ensure outbound TCP traffic to <code>cloud.voipmonitor.org:60023</code> is allowed
* Check local firewall (ufw, firewalld, iptables)
* Check corporate or cloud provider firewalls


;4. First-Time Setup: Initialize Cloud Database
;ARM64 Architecture Issue
On ARM64 (aarch64) systems, a known bug prevents cloud connectivity. Contact VoIPmonitor support for a corrected ARM64 static binary.


If this is your first time connecting to VoIPmonitor Cloud, you must log in to the Cloud GUI to initialize your cloud database before the service will connect correctly.
Symptoms:
* Sensor runs locally (visible in logs)
* Configuration is correct
* Firewall allows traffic
* Sensor does not appear in Cloud GUI


;Symptoms of uninitialized database:
Solution:
:* '''"failed read rsa key"''' error in <code>journalctl -u voipmonitor -f</code>
:* '''"loss connection"''' errors when trying to connect to the cloud service
:* The voipmonitor service fails to start or repeatedly tries to reconnect
:* Sensor configuration (<code>server_destination</code>, <code>server_destination_port</code>, <code>packetbuffer_sender</code>) is correct
 
;Solution: Initialize Your Cloud Database
 
<ol>
<li>Log in to the '''VoIPmonitor Cloud GUI''' at https://cloud.voipmonitor.org using your voipmonitor.org client area credentials.</li>
<li>This action automatically creates the necessary tables and content in your cloud database.</li>
<li>Restart the voipmonitor service on your server:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
systemctl restart voipmonitor
systemctl stop voipmonitor
# Download corrected binary from support
mv /usr/local/sbin/voipmonitor /usr/local/sbin/voipmonitor.backup
cp voipmonitor-arm64-fixed /usr/local/sbin/voipmonitor
systemctl start voipmonitor
</syntaxhighlight>
</syntaxhighlight>
</li>
<li>Verify that the sniffer appears as '''green''' in the Cloud GUI under '''Settings -> Sensors'''.</li>
</ol>
The RSA key error occurs because the service cannot authenticate with your cloud database until the database structure has been created.


;5. Verify sensor IDs match:
== See Also ==
* If <code>id_sensor</code> is set in <code>voipmonitor.conf</code>, ensure it is unique (no collision with other sensors)
* The sensor ID should match what you expect to see in the Cloud interface


;6. Review logs for errors:
* [[Sniffer_distributed_architecture]] - Client-server architecture details
<syntaxhighlight lang="bash">
* [[Capture_rules]] - Configuring selective PCAP storage
# Check cloud-specific connection errors
* [[Sniffer_configuration]] - All sniffer configuration parameters
journalctl -u voipmonitor -f | grep -i "cloud\|server\|connection"
</syntaxhighlight>


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


'''Summary:''' VoIPmonitor Cloud Service is a managed hosting model where customer runs on-premise sniffer while VoIPmonitor hosts database and web GUI. Free 30-day trial available via portal (my services section). Setup: download installation script from portal or manually configure <code>server_destination=cloud.voipmonitor.org</code>, <code>server_destination_port=60023</code>, <code>packetbuffer_sender=yes</code>. Sniffer processes traffic locally, sends only CDR metadata to cloud. PCAPs stored locally, downloadable on-demand via GUI. Service limits: 2000 concurrent channels, 25 days CDR retention. AWS deployment requires resource configuration: <code>ringbuffer</code> (50-2000 based on traffic), <code>max_buffer_mem</code> (reduce on small instances), <code>maxpoolsize</code> (always set to prevent disk full), use EBS gp3/io2 volumes. Troubleshooting: ARM64 requires special binary from support; first-time setup requires logging into cloud GUI to initialize database (fixes "failed read rsa key" error); verify firewall allows TCP 60023.
'''Summary:''' VoIPmonitor Cloud Service is a managed hosting model where customer runs on-premise sniffer while VoIPmonitor hosts database and web GUI. Service limits: 2000 concurrent channels, 25 days CDR retention, PCAP stored locally only. Free 30-day trial via portal. Setup: use installation script from portal or manually configure <code>server_destination=cloud.voipmonitor.org</code>, <code>server_destination_port=60023</code>, <code>packetbuffer_sender=yes</code>. Sniffer sends only CDR metadata to cloud; PCAPs stay local and stream on-demand. AWS deployment requires resource limits: <code>ringbuffer</code>, <code>max_buffer_mem</code>, <code>maxpoolsize</code> (critical to prevent disk full), and <code>chmod 644 /dev/root</code> for license. Troubleshooting: first-time users must log into Cloud GUI to initialize database (fixes "failed read rsa key"); ARM64 requires special binary from support.


'''Keywords:''' cloud service, hosted GUI, on-premise sniffer, server_destination, packetbuffer_sender, port 60023, CDR, PCAP, local storage, on-demand download, AWS, EC2, ringbuffer, max_buffer_mem, maxpoolsize, EBS volume, ARM64, cloud database initialization, failed read rsa key, free trial
'''Keywords:''' cloud service, hosted GUI, on-premise sniffer, server_destination, packetbuffer_sender, port 60023, CDR metadata, PCAP local storage, on-demand download, AWS, EC2, ringbuffer, max_buffer_mem, maxpoolsize, EBS volume, ARM64, cloud database initialization, failed read rsa key, loss connection, free trial, 2000 channels, 25 days retention


'''Key Questions:'''
'''Key Questions:'''
Line 419: Line 211:
* How do I fix "failed read rsa key" error?
* How do I fix "failed read rsa key" error?
* Does VoIPmonitor Cloud offer a free trial?
* Does VoIPmonitor Cloud offer a free trial?
* What are the service limits (channels, retention)?
* What are the cloud service limits (channels, retention)?
* How do I prevent memory/disk exhaustion on AWS?
* How do I fix ARM64 cloud connectivity issues?

Revision as of 16:47, 8 January 2026

VoIPmonitor Cloud Service

The VoIPmonitor Cloud Service is a managed hosting model where you run only the on-premise sniffer, while VoIPmonitor hosts and manages the database and web GUI.

Service Specifications

Specification Value
Max Concurrent Channels 2000
CDR Retention 25 days
PCAP Storage Local only (on sniffer, not in cloud)

ℹ️ Note: If your requirements exceed these limits, consider an on-premise deployment.

Architecture

Data Flow

  • Sniffer (Client): Captures and processes VoIP traffic locally. Multiple sniffers can connect from different locations.
  • Cloud (Server): Hosts the database (CDR metadata) and web GUI for analysis and reporting.

How Data is Transferred

Standard Mode (Default)

The sniffer analyzes traffic locally and sends only CDR metadata to the cloud. Voice packets (PCAP) are discarded after analysis. This minimizes bandwidth usage.

On-Demand PCAP Retrieval

If packet capture is enabled via Capture Rules, PCAPs are stored locally on the sniffer. When a user requests a PCAP through the cloud GUI, the file streams directly from the sniffer to the user's browser - it is never uploaded to the cloud.

Quick Start

Free Trial

  1. Log in to VoIPmonitor Portal
  2. Navigate to my services
  3. Order the free 30-day Cloud GUI trial

Method 1: Installation Script (Recommended)

  1. Download the installation script from VoIPmonitor Portal (my services > your Cloud service)
  2. Run on your sniffer server:
chmod +x voipmonitor-cloud-install.sh
sudo ./voipmonitor-cloud-install.sh

The script automatically installs and configures everything.

Method 2: Manual Configuration

Edit /etc/voipmonitor.conf: 

server_destination = cloud.voipmonitor.org
server_destination_port = 60023
packetbuffer_sender = yes

systemctl restart voipmonitor

💡 Tip: For general client-server architecture details, see Sniffer_distributed_architecture.

AWS EC2 Configuration

When deploying on AWS, configure resource limits to prevent memory exhaustion and disk full conditions.

Required Parameters

Parameter Purpose Recommended Value
ringbuffer Packet capture buffer size (MB) 50-100 (low traffic), 500-1000 (medium), 1000-2000 (high)
max_buffer_mem Max memory for buffers (MB) 500 for t3.small, 2000 for m5.large+
maxpoolsize Max PCAP storage (MB) Set to ~80% of available disk
spooldir PCAP storage path Use EBS volume (gp3/io2), not instance store

⚠️ Warning: Always set maxpoolsize - without it, VoIPmonitor will fill the disk until the system crashes.

Example AWS Configuration

For m5.large (8GB RAM, 100GB EBS gp3): 

# Cloud connection
server_destination = cloud.voipmonitor.org
server_destination_port = 60023
packetbuffer_sender = yes

# Sensor ID
id_sensor = 1

# Capture interface (typically eth0 or ens5 on AWS)
interface = eth0

# AWS resource limits
ringbuffer = 500
max_buffer_mem = 2000
spooldir = /var/spool/voipmonitor
maxpoolsize = 102400

AWS License Fix

AWS EC2 instances require this permission for license checks: 

chmod 644 /dev/root

Troubleshooting

Sensor Not Appearing in Cloud

First-Time Setup
Initialize Database

If you see failed read rsa key or loss connection errors, you must first log in to the Cloud GUI to initialize your database:

  1. Log in to Cloud GUI with your portal credentials
  2. This creates the necessary database tables
  3. Restart the sniffer: systemctl restart voipmonitor
  4. Verify sensor appears green in Settings -> Sensors
Verify Configuration
grep -E "server_destination|packetbuffer_sender" /etc/voipmonitor.conf

Required settings: 

server_destination = cloud.voipmonitor.org
server_destination_port = 60023
packetbuffer_sender = yes
Check Network Connectivity
nc -zv cloud.voipmonitor.org 60023

Ensure outbound TCP to port 60023 is allowed through all firewalls (local, corporate, cloud provider).

ARM64 Architecture Issue

On ARM64 (aarch64) systems, a known bug prevents cloud connectivity. Contact VoIPmonitor support for a corrected ARM64 static binary.

Symptoms:

  • Sensor runs locally (visible in logs)
  • Configuration is correct
  • Firewall allows traffic
  • Sensor does not appear in Cloud GUI

Solution: 

systemctl stop voipmonitor
# Download corrected binary from support
mv /usr/local/sbin/voipmonitor /usr/local/sbin/voipmonitor.backup
cp voipmonitor-arm64-fixed /usr/local/sbin/voipmonitor
systemctl start voipmonitor

See Also

AI Summary for RAG

Summary: VoIPmonitor Cloud Service is a managed hosting model where customer runs on-premise sniffer while VoIPmonitor hosts database and web GUI. Service limits: 2000 concurrent channels, 25 days CDR retention, PCAP stored locally only. Free 30-day trial via portal. Setup: use installation script from portal or manually configure server_destination=cloud.voipmonitor.org, server_destination_port=60023, packetbuffer_sender=yes. Sniffer sends only CDR metadata to cloud; PCAPs stay local and stream on-demand. AWS deployment requires resource limits: ringbuffer, max_buffer_mem, maxpoolsize (critical to prevent disk full), and chmod 644 /dev/root for license. Troubleshooting: first-time users must log into Cloud GUI to initialize database (fixes "failed read rsa key"); ARM64 requires special binary from support.

Keywords: cloud service, hosted GUI, on-premise sniffer, server_destination, packetbuffer_sender, port 60023, CDR metadata, PCAP local storage, on-demand download, AWS, EC2, ringbuffer, max_buffer_mem, maxpoolsize, EBS volume, ARM64, cloud database initialization, failed read rsa key, loss connection, free trial, 2000 channels, 25 days retention

Key Questions:

  • How do I connect my sniffer to VoIPmonitor Cloud?
  • What are the required voipmonitor.conf settings for cloud connectivity?
  • Is my call data (PCAP) stored in the cloud?
  • How do I configure VoIPmonitor on AWS EC2?
  • What is the recommended maxpoolsize for AWS instances?
  • Why is my sensor not appearing in Cloud interface?
  • How do I fix "failed read rsa key" error?
  • Does VoIPmonitor Cloud offer a free trial?
  • What are the cloud service limits (channels, retention)?
  • How do I fix ARM64 cloud connectivity issues?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Cloud&oldid=10051"