Architecture

This article describes the fundamental architecture of the VoIPmonitor system. It guides you through its key components and explains the main deployment models, from a simple all-in-one installation to complex, distributed solutions for monitoring multiple sites.

Core Components

The VoIPmonitor system consists of three primary, logically separate components that can run on a single server or be distributed across multiple machines for scalability.

1. Web GUI

The Web GUI is the main presentation and management layer. Built on PHP and enhanced with high-performance C++ binaries, it provides a powerful interface for analyzing calls, viewing statistics, and configuring the system. It can run on the same server as the database and sensor, or on a completely dedicated machine.

2. Database Server (MySQL/MariaDB)

VoIPmonitor uses a MySQL-compatible database (including forks like MariaDB) to store Call Detail Records (CDRs), call quality metrics, and system data. For high-traffic environments, the database can be deployed on a dedicated, high-performance server to ensure maximum throughput and reliability. All communication between the GUI/Sensor and the database occurs over the standard MySQL TCP interface.

3. Sensor (Sniffer)

The Sensor (also called a sniffer or probe) is the core data collection engine. It is a passive network analyzer, similar in principle to tools like `tcpdump` or `wireshark`, which performs the following real-time operations:

• Traffic Analysis: It listens to network traffic to identify SIP signaling and its associated RTP (audio/video) streams.
• Call Reconstruction: It pieces together the SIP and RTP packets that belong to a single VoIP call.
• CDR Generation: From the analyzed data, it creates a detailed CDR which is then sent to the MySQL database.
• Packet Storage: If enabled, it saves the complete call (both SIP and RTP streams) to a local disk in the standard PCAP file format. This allows for detailed, packet-level troubleshooting and call playback directly from the GUI.

The sensor is designed to run on Linux (recommended) or FreeBSD operating systems. It supports x86_64 and ARMv7/v8 architectures and can be deployed on dedicated physical hardware, virtual machines, or in cloud environments. [2]

Deployment Scenarios

All-in-One Server

The most common and simplest setup involves running the GUI, MySQL database, and Sensor on a single server. This is suitable for many small to medium-sized environments. In this model, the GUI reads PCAP files from the local disk and communicates with the database via localhost. [1]

Distributed Architecture: Central GUI/DB with Remote Sensors

For larger or geographically dispersed environments, a distributed model is recommended. This typically involves a central server for the GUI and Database, which collects data from one or more remote Sensors. Remote Sensors can be configured in two primary ways, depending on the resources available on the machine where traffic is captured. [1]

Method 1: Remote Probing (Local Processing)

This is the standard mode for remote sensors. The Sensor is installed on the remote PBX/SBC or a dedicated machine at the remote site.

• How it works: The remote Sensor processes all packets locally, generates the CDRs, and saves PCAP files to its own disk. It only sends the small CDR data to the central MySQL database over the network.
• Use Case: Ideal when the remote machine has sufficient CPU, RAM, and disk I/O to handle the processing load.
• Advantage: Keeps network traffic between the remote site and the central server to an absolute minimum.
• Configuration: For details, see the Multiple Remote Sensors guide.

Method 2: Software Packet Mirroring (SPOOF Mode)

This special mode should not be confused with hardware port mirroring (SPAN). It involves a pair of sensors: a sender and a receiver.

• How it works: The "sender" sensor, installed on the remote PBX/SBC, does no processing. It simply captures all VoIP packets and forwards them over a compressed TCP stream to a central "receiver" sensor. The receiver then processes the packets from multiple senders.
• Use Case: Perfect for scenarios where the remote PBX/SBC is a low-resource appliance (or you do not want to add any processing load to it) and direct network tapping is not possible.
• Advantage: The sender sensor has a minimal CPU and memory footprint.
• Trade-off: This mode generates significantly more network traffic between the sender and receiver compared to local processing.
• Configuration: For details, see the Mirroring Sniffer guide.

Physical Network Tapping

If the VoIPmonitor Sensor cannot be installed directly on the server generating the traffic (e.g., a hardware PBX or a locked-down appliance), you must mirror the network traffic to a dedicated server running the Sensor.

This is typically achieved at the hardware level using a network switch feature known as **Port Mirroring** or **SPAN (Switched Port Analyzer)**. Consult your network switch's documentation to see if it supports this feature.

Additionally, some SBCs and PBXs can mirror packets using tunneling protocols like IP-in-IP, which VoIPmonitor can decode natively. [2]

AI Summary for RAG

Summary: This article details the three-component architecture of VoIPmonitor: the Web GUI, a MySQL database, and the Sensor (sniffer). It explains deployment models, including a simple all-in-one setup and a distributed architecture. Two primary methods for remote data collection are described: local processing (remote probing), which minimizes network traffic, and software packet mirroring (SPOOF mode), which minimizes CPU load on the source machine. The article also touches upon physical network tapping via hardware switch features like SPAN ports. Keywords: architecture, deployment, sensor, sniffer, probe, Web GUI, MySQL, database, distributed, all-in-one, single server, remote sensor, local processing, packet mirroring, SPOOF, hardware mirroring, SPAN, RSPAN, network tap Key Questions:

• What are the main components of VoIPmonitor?
• What is the difference between a Sensor and the GUI?
• How can I monitor multiple remote PBX servers?
• What is the difference between local processing and SPOOF mode for remote sensors?
• When should I use software packet mirroring instead of local processing?
• What is a SPAN port and when do I need it?x