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.

Deployment Scenarios

Monitoring 4 Separate VoIP Servers

When you need to monitor multiple VoIP servers, you have three primary architectural options depending on your network topology and requirements:

Option 1: Centralized Sniffing (Recommended for Same Data Center/LAN)

If all 4 VoIP servers are in the same local network (same rack/building), the simplest architecture is to mirror traffic to a single dedicated sensor.

• How it works: Configure your network switch to mirror (SPAN/RSPAN) traffic from the 4 VoIP server ports to a single dedicated VoIPmonitor sensor host. This centralizes all processing, storage, and management.
• Advantage: Single sensor to manage, centralized storage, simplified deployment.
• Consideration: Requires switch configuration and the monitoring server must handle the aggregate traffic from all 4 sources.
• Configuration: See Physical Network Tapping below for SPAN/RSPAN setup.

Option 2: Distributed Client-Server Architecture (Recommended for WAN/Sites)

If your servers are distributed across different physical locations (WAN), or if you want centralized analysis with remote capture points, use the Client-Server mode.

• How it works: Install a lightweight sensor (client) on each VoIP server. These connect to a central, more powerful server (GUI + Database) that processes and stores data. Two sub-modes are available:
  • Local Processing (`packetbuffer_sender=no`): Remote sensors analyze calls and send only CDRs (metadata). Good for low bandwidth. PCAPs stay on sensors.
  • Packet Mirroring (`packetbuffer_sender=yes`): Remote sensors send raw packets to central server. Central server does all processing. Good when remote servers have low CPU.
• Advantage: Centralized management and unified view across locations. Sensors can run in low-resource mode.
• Configuration: See Distributed Architecture: Client-Server Mode for detailed configuration.

Option 3: Independent Installations (Simple but Less Scalable)

Install the complete VoIPmonitor application (sensor + local database + optional local GUI) on each of the 4 VoIP servers.

• How it works: Each server runs its own completely independent voipmonitor instance. No centralization, no connection between them.
• Advantage: Absolute isolation (failure of one doesn't affect others), no network dependencies, simple initial setup (just 4 standard installations).
• Trade-offs:
  • Uses more CPU/RAM/disk on each VoIP server (may impact call quality if resources are limited)
  • No unified view - you must log into each server separately
  • More maintenance (4 separate databases to upgrade, backup, monitor)
  • No centralized reporting across all servers
• Use case: When servers are isolated (no network connectivity between them), or when complete independence is the priority over management convenience.

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.

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.

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 can be achieved through several methods:

Method 1: Switch Port Mirroring (SPAN/RSPAN)

Most network switches offer a feature known as Port Mirroring or SPAN (Switched Port Analyzer). This allows you to copy traffic from one or more source ports to a destination port connected to the Sensor. Consult your network switch's documentation to see if it supports this feature.

Limitation of SPAN: Many switches can mirror to only a single destination port. If you need to send traffic to multiple monitoring tools or sensors, you must use alternative solutions (see Method 2 or Method 3 below).

Method 2: Hardware TAP (Test Access Point)

A Hardware TAP is a passive device that is placed inline on a network link between two devices (e.g., between a switch and a PBX). Unlike SPAN which is a switch feature, a TAP is a physical device that copies all traffic to one or more monitor ports.

Advantages of Hardware TAPs:

• Bypasses switch limitations: No dependency on switch SPAN capabilities or port restrictions
• 100% traffic visibility: Captures all packets including errors and malformed frames that switches may drop
• No impact on network performance: Passive TAPs do not introduce latency or affect traffic flow
• Multiple destinations: TAPs with multiple monitor ports can forward traffic to several sensors simultaneously
• Layer 1 visibility: Captures at the physical layer, seeing everything on the wire

Hardware TAP vs Network Packet Broker:

• For monitoring a single link: Use a basic TAP with one or two monitor ports
• For aggregating traffic from multiple TAPs to multiple sensors: Use a network packet broker

Use Case for TAPs: When your network switch cannot send SPAN traffic to multiple destinations, a hardware TAP provides a reliable alternative that does not rely on switch capabilities.

Method 3: Software-based Tunnelling

Alternatively, some SBCs and PBXs can mirror packets using tunneling protocols like IP-in-IP, which VoIPmonitor can decode natively. See the Sniffing Modes guide for detailed tunneling configuration options.

Method 4: Distributed Architecture

If hardware changes are not possible, consider the Client/Server architecture where a remote sensor receives the single SPAN stream and forwards data (CDRs or packets) to a central server for processing. This allows multiple VoIPmonitor users or sensors to benefit from a single SPAN port through software-based packet forwarding.

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 for monitoring multiple VoIP servers: (1) Centralized Sniffing (SPAN/RSPAN to single sensor for LAN), (2) Distributed Client-Server Architecture (sensors connect to central GUI/DB for WAN), which includes two sub-modes: Local Processing (`packetbuffer_sender=no`) where sensors analyze locally and send CDRs, and Packet Mirroring (`packetbuffer_sender=yes`) where sensors send raw packets to central server, and (3) Independent Installations (complete voipmonitor on each server with no centralization - tradeoffs: more resource usage per server, no unified view, more maintenance; use case: isolated servers or independence priority). The article also covers the All-in-One Server setup and Distributed Architecture methods for remote sensors: local processing (remote probing) which minimizes network traffic, and software packet mirroring (SPOOF mode) which minimizes CPU on source. Physical network tapping methods: (1) Switch Port Mirroring (SPAN/RSPAN), (2) Hardware TAP (passive inline device for 100% visibility), (3) Software-based tunneling, (4) Distributed Client/Server architecture. Hardware TAPs are solution when switches cannot send SPAN traffic to multiple destinations. Network packet brokers aggregate traffic from multiple TAPs to multiple sensors. 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, hardware TAP, test access point, packet broker, inline tapping, physical layer, multiple destinations, monitoring 4 separate servers, centralized sniffing, independent installations, multi-server monitoring, WAN deployment, centralized server, unified view Key Questions:

• What are the main components of VoIPmonitor?
• What is the difference between a Sensor and the GUI?
• How do I monitor 4 separate VoIP servers?
• What are the three architectural options for monitoring multiple VoIP servers?
• What is the difference between Centralized Sniffing, Distributed Client-Server, and Independent Installations?
• When should I use Centralized Sniffing with SPAN/RSPAN for multiple VoIP servers?
• What is the difference between Local Processing and Packet Mirroring in client-server mode?
• What are the trade-offs of running independent voipmonitor installations on each server?
• What are the advantages and disadvantages of independent voipmonitor installations?
• When should I choose independent voipmonitor installations over client-server mode?
• 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?
• What is the solution if a network switch cannot send TAP/SPAN traffic to multiple destinations?
• What is a hardware TAP and how does it differ from SPAN?
• What are the advantages of using a hardware TAP over switch-based mirroring?
• When should I use a hardware TAP vs a network packet broker?