VoIPmonitor Cloud Service Architecture

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.

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

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 voipmonitor process is running and appears active with systemctl status voipmonitor
The sensor is capturing traffic locally (check via journalctl -u voipmonitor -f)
No sensor appears in your VoIPmonitor Cloud interface
Configuration is correct (server_destination, server_destination_port, packetbuffer_sender)
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.

# 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

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

grep -E "server_destination|packetbuffer_sender" /etc/voipmonitor.conf

Required for VoIPmonitor Cloud:

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

2. Verify network connectivity to cloud

# Test outbound connection to VoIPmonitor Cloud
nc -zv cloud.voipmonitor.org 60023

3. Check for firewall issues

Ensure outbound TCP traffic to cloud.voipmonitor.org:60023 is allowed
Check local firewall (ufw, firewalld, iptables)
Check corporate or cloud provider firewalls

4. Verify sensor IDs match

If id_sensor is set in voipmonitor.conf, ensure it is unique (no collision with other sensors)
The sensor ID should match what you expect to see in the Cloud interface

5. Review logs for errors

# Check cloud-specific connection errors
journalctl -u voipmonitor -f | grep -i "cloud\|server\|connection"

AI Summary for RAG

Summary: This document explains the VoIPmonitor Cloud Service, a client-server architecture where the customer runs one or more sniffer clients on-premise, while VoIPmonitor hosts the database and web GUI. The sniffer's primary mode involves local processing of VoIP traffic, sending only lightweight Call Detail Records (CDRs) to the cloud. Full packet captures (PCAPs) are not automatically uploaded; instead, they are selectively stored on the local sniffer based on user-defined 'capture rules' (e.g., by IP address, phone number, or SIP headers). These stored PCAPs can be downloaded on-demand directly from the sniffer when requested by a user through the cloud GUI. This model is for users who want to avoid managing server infrastructure. Troubleshooting section covers ARM64 cloud connectivity issue where sensor runs locally but does not appear in cloud - requires corrected static binary from support, not configuration changes. Also includes general troubleshooting steps: verify server_destination=cloud.voipmonitor.org, server_destination_port=60023, packetbuffer_sender=yes, test nc -zv cloud.voipmonitor.org 60023, check firewall rules, verify unique id_sensor, review logs with journalctl -u voipmonitor -f | grep -i "cloud|server|connection". Keywords: cloud service, cloud architecture, client-server, on-premise sniffer, hosted database, hosted GUI, local processing, CDR, Call Detail Record, local storage, packet capture, PCAP, on-demand download, capture rules, SIP headers, managed service, troubleshooting, ARM64, cloud connectivity bug, sensor not appearing, server_destination, server_destination_port, packetbuffer_sender, firewall Key Questions:

How does the VoIPmonitor Cloud Service architecture work?
Who is the cloud service intended for?
Is my call data (PCAP) stored in the cloud?
How can I control which calls have their packet captures saved?
How are Call Detail Records (CDRs) and packet captures (PCAPs) handled differently?
What data does the on-premise sniffer send to the cloud?
How can I access a full packet capture for a specific call?
What are the main benefits of this cloud model?
Why does my ARM64 sensor not appear in the VoIPmonitor Cloud interface?
How do I fix the ARM64 cloud connectivity issue?
What are the required voipmonitor.conf settings for VoIPmonitor Cloud?
How do I test if my firewall is blocking cloud connectivity?