Sniffer distributed architecture

This guide explains how to deploy multiple VoIPmonitor sensors in a distributed architecture using the modern Client-Server mode.

Overview

VoIPmonitor v20+ uses a Client-Server architecture for distributed deployments. Remote sensors connect to a central server via encrypted TCP channel.

Mode	What is sent	Processing location	Use case
Local Processing	CDRs only	Remote sensor	Multiple sites, low bandwidth
Packet Mirroring	Raw packets	Central server	Centralized analysis, low-resource remotes

The mode is controlled by a single option: packetbuffer_sender

For comprehensive deployment options including on-host vs dedicated sensors, traffic forwarding methods (SPAN, GRE, TZSP, VXLAN), and NFS/SSHFS alternatives, see VoIPmonitor Deployment & Topology Guide.

Client-Server Mode

Architecture

Configuration

Remote Sensor (client):

id_sensor               = 2                    # unique per sensor
server_destination      = central.server.ip
server_destination_port = 60024
server_password         = your_strong_password

# Choose one:
packetbuffer_sender     = no     # Local Processing: analyze locally, send CDRs
# packetbuffer_sender   = yes    # Packet Mirroring: send raw packets

interface               = eth0
sipport                 = 5060
# No MySQL credentials needed on remote sensors

Important: Source IP Binding with manager_ip

For remote sensors with multiple IP addresses (e.g., in High Availability setups with a floating/virtual IP), use the manager_ip parameter to bind the outgoing connection to a specific static IP address. This ensures the central server sees a consistent source IP from each sensor, preventing connection issues during failover.

# On sensor with multiple interfaces (e.g., static IP + floating HA IP)
manager_ip              = 10.0.0.5     # Bind to the static IP address
server_destination      = 192.168.1.100
# The outgoing connection will use 10.0.0.5 as the source IP instead of the floating IP

Useful scenarios:

• HA pairs: Sensors use static IPs while floating IP is only for failover management
• Multiple VNICs: Explicit source IP selection on systems with multiple virtual interfaces
• Network ACLs: Ensure connections originate from whitelisted IP addresses

Central Server:

server_bind             = 0.0.0.0
server_bind_port        = 60024
server_password         = your_strong_password

mysqlhost               = localhost
mysqldb                 = voipmonitor
mysqluser               = voipmonitor
mysqlpassword           = db_password

# If receiving raw packets (packetbuffer_sender=yes on clients):
sipport                 = 5060
# ... other sniffer options

Connection Compression

The client-server channel supports compression to reduce bandwidth usage:

# On both client and server (default: zstd)
server_type_compress = zstd

Available options: zstd (default, recommended), gzip, lzo, none

High Availability (Failover)

Remote sensors can specify multiple central server IPs for automatic failover:

# Remote sensor configuration with failover
server_destination = 192.168.0.1, 192.168.0.2

If the primary server becomes unavailable, the sensor automatically connects to the next server in the list.

Local Processing vs Packet Mirroring

	Local Processing	Packet Mirroring
packetbuffer_sender	no (default)	yes
Packet analysis	On remote sensor	On central server
PCAP storage	On remote sensor	On central server
WAN bandwidth	Low (CDRs only)	High (full packets)
Remote CPU load	Higher	Minimal
Use case	Standard multi-site	Low-resource remotes

PCAP Access in Local Processing Mode

When using Local Processing, PCAPs are stored on remote sensors. The GUI retrieves them via the central server, which proxies requests to each sensor's management port (TCP/5029).

Firewall requirements:

• Central server must reach remote sensors on TCP/5029
• Remote sensors must reach central server on TCP/60024

Dashboard Statistics

Dashboard widgets (SIP/RTP/REGISTER counts) depend on where packet processing occurs:

Configuration	Where statistics appear
packetbuffer_sender = yes (Packet Mirroring)	Central server only
packetbuffer_sender = no (Local Processing)	Both sensor and central server

Note: If you are using Packet Mirroring mode (packetbuffer_sender=yes) and see empty dashboard widgets for the forwarding sensor, this is expected behavior. The sender sensor only captures and forwards raw packets - it does not create database records or statistics. The central server performs all processing.

Enabling Local Statistics on Forwarding Sensors

If you need local statistics on a sensor that was previously configured to forward packets:

# On the forwarding sensor
packetbuffer_sender = no

This disables packet forwarding and enables full local processing. Note that this increases CPU and RAM usage on the sensor since it must perform full SIP/RTP analysis.

Data Storage Summary

• CDRs: Always stored in MySQL on central server
• PCAPs:
  • Local Processing → stored on each remote sensor
  • Packet Mirroring → stored on central server

GUI Visibility

Remote sensors appear automatically when connected. To customize names or configure additional settings:

1. Go to GUI → Settings → Sensors
2. Sensors are identified by their id_sensor value

Legacy: Mirror Mode

Note: The older mirror_destination/mirror_bind options still exist but the modern Client-Server approach with packetbuffer_sender=yes is preferred as it provides encryption and simpler management.

Critical Requirement: SIP and RTP must be captured by the same sniffer instance

VoIPmonitor cannot reconstruct a complete call record if SIP signaling and RTP media are captured by different sniffer instances.

Important: Single sniffer requirement
What does not work:	* Sniffer A in Availability Zone 1 captures SIP signaling Sniffer B in Availability Zone 2 captures RTP media Result: Incomplete call record, GUI cannot reconstruct the call
Why:	Call correlation requires a single sniffer instance to process both SIP and RTP packets from the same call. The sniffer correlates SIP signaling (INVITE, BYE, etc.) with RTP media in real-time during packet processing. If packets are split across multiple sniffers, the correlation cannot occur.
Solution:	Forward traffic so that one sniffer processes both SIP and RTP for each call. Options: Route both SIP and RTP through the same Availability Zone for capture Use Packet Mirroring mode to forward complete traffic (SIP+RTP) to a central server that processes everything Configure network routers/firewalls to forward the required stream to the correct zone

Configuration parameters like receiver_check_id_sensor and cdr_check_exists_callid are for other scenarios (multipath routing, duplicate Call-ID handling) and do NOT enable split SIP/RTP correlation. Setting these parameters does not allow SIP from one sniffer to be merged with RTP from another sniffer.

Limitations

• All sensors must use the same server_password
• A single sniffer cannot be both server and client simultaneously
• Each sensor requires a unique id_sensor (< 65536)
• Time synchronization (NTP) is critical for correlating calls across sensors
• Maximum allowed time difference between client and server: 2 seconds (configurable via client_server_connect_maximum_time_diff_s)

For a complete reference of all client-server parameters, see Sniffer Configuration: Distributed Operation.

AI Summary for RAG

Summary: VoIPmonitor v20+ uses Client-Server architecture for distributed deployments with encrypted TCP connections (port 60024, zstd compression). Two modes: Local Processing (packetbuffer_sender=no) analyzes locally and sends CDRs, Packet Mirroring (packetbuffer_sender=yes) forwards raw packets. Dashboard widgets for SIP/RTP/REGISTER counts: with Packet Mirroring, statistics appear only on central server (sender has empty widgets); with Local Processing, statistics appear on both sensor and central server. To enable local statistics on a forwarding sensor, set packetbuffer_sender=no (increases CPU/RAM usage). Supports failover with multiple server IPs. CDRs stored centrally; PCAPs on sensors (Local Processing) or centrally (Packet Mirroring). CRITICAL: A single sniffer instance MUST process both SIP signaling and RTP media for the same call. Splitting SIP and RTP across different sniffers creates incomplete call records that cannot be reconstructed. Keywords: distributed architecture, client-server, server_destination, server_bind, packetbuffer_sender, local processing, packet mirroring, remote sensors, failover, encrypted channel, zstd compression, dashboard widgets, statistics, empty dashboard, SIP RTP correlation, split sensors, single sniffer requirement, availability zone Key Questions:

• How do I connect multiple VoIPmonitor sensors to a central server?
• What is the difference between Local Processing and Packet Mirroring?
• Where are CDRs and PCAP files stored in distributed mode?
• What is packetbuffer_sender and when should I use it?
• How do I configure failover for remote sensors?
• Why are dashboard widgets (SIP/RTP/REGISTER counts) empty for a sensor configured to forward packets?
• How do I enable local statistics on a forwarding sensor?
• Can VoIPmonitor reconstruct a call if SIP signaling is captured by one sniffer and RTP media by another?
• Why does receiver_check_id_sensor not allow merging SIP from one sensor with RTP from another?