Sniffer distributed architecture

Distributed Architecture: Client-Server and Mirroring Modes

This guide explains how to deploy VoIPmonitor in distributed architectures using client-server mode, packet mirroring, and hybrid configurations.

Overview

VoIPmonitor sniffers can be deployed in multiple architectural patterns:

• Standalone mode: Single instance capturing and analyzing traffic
• Client-Server mode: Multiple clients sending CDRs to central server
• Mirroring mode: Forwarding raw packets to another instance
• Hybrid mode: Combining mirroring with client-server (workaround)

= Architecture Diagrams (PlantUML)

Standard Architectures

Multiple Clients to Single Server (Recommended)

This is the standard and fully supported architecture for distributed deployments.

Configuration:

On each client (A, B, C):

server_destination = central.server.ip
server_destination_port = 60024
server_password = shared_secret

On central server:

server_bind = 0.0.0.0
server_bind_port = 60024
server_password = shared_secret

Important notes:

• All clients and the server must use the same server_password
• Clients do not store CDRs to MySQL (they only send to server)
• Server stores all CDRs to MySQL database
• PCAP files are stored on clients by default

Packet Mirroring

Mirror mode forwards raw network packets from one sniffer to another.

Sensor A ──(packets)──→ Sensor B

Configuration:

On source sensor A:

mirror_destination = sensor.b.ip
mirror_destination_port = 5090

On receiving sensor B:

mirror_bind = 0.0.0.0
mirror_bind_port = 5090

Use cases:

• Forwarding packets from appliances without VoIPmonitor
• Port mirroring / SPAN to VoIPmonitor instance
• Distributed packet capture with central analysis

Forwarding from SIP Probe to Central Server

This pattern is used when SIP signaling and RTP media are captured on separate machines. A SIP-only probe captures SIP packets and forwards them to a central server where RTP packets are also captured, allowing complete CDR generation.

SIP Probe (only SIP) ──(SIP packets)──→ Central Server (SIP + RTP)

Use case:

• Environment where SIP servers and RTP engines are deployed on separate machines
• Need to merge SIP signaling from one location with RTP media from another

Configuration on SIP Probe (sending SIP packets):

Edit /etc/voipmonitor.conf:

# Enable packet forwarding mode
packetbuffer_sender = yes

# Send to central server that will merge SIP with RTP
server_destination = central.server.ip
server_destination_port = 60024
server_password = shared_secret

# Do NOT set server_bind, mysqlhost, or other server options

Configuration on Central Server (receiving SIP, capturing RTP):

Edit /etc/voipmonitor.conf:

# Accept incoming packets from probes
server_bind = 0.0.0.0
server_bind_port = 60024
server_password = shared_secret

# This server should also be capturing RTP locally
# Configure interface/port as usual
interface = eth0
# ... other standard configuration

How it works:

1. SIP probe captures SIP signaling packets only
2. SIP probe forwards raw packets to central server via server_destination
3. packetbuffer_sender = yes enables packet forwarding (instead of analyzing locally and sending CDRs)
4. Central server receives SIP packets and merges them with locally captured RTP packets
5. Central server generates complete CDRs with both signaling and media information

Restart services:

# On SIP probe
systemctl restart voipmonitor

# On central server
systemctl restart voipmonitor

ℹ️ Note: This pattern uses packetbuffer_sender with server_destination/server_bind (client-server mode), which is different from packetbuffer_sender with mirror_destination/mirror_bind (mirror mode).

Hybrid Chain Configuration (Workaround)

⚠️ Warning: A single sniffer instance cannot operate in both client and server modes simultaneously using server_bind + server_destination. These options are mutually exclusive.

However, a workaround exists using mirroring combined with client mode:

A (mirror) ──(packets)──→ B (mirror_bind + server_destination) ──(CDRs/packets)──→ C (server)

Scenario 1: CDR Forwarding

In this configuration, the intermediate sniffer (B) analyzes packets and forwards only CDRs to the central server.

Sensor A (source):

mirror_destination = sensor.b.ip
mirror_destination_port = 5090

Sensor B (intermediate):

mirror_bind = 0.0.0.0
mirror_bind_port = 5090
server_destination = central.server.ip
server_destination_port = 60024
packetbuffer_sender = no

Central Server C:

server_bind = 0.0.0.0
server_bind_port = 60024

Result:

• B analyzes packets from A
• B stores PCAP files locally
• B sends only CDRs to C
• C stores CDRs in MySQL and knows PCAPs are on B

Scenario 2: Packet Forwarding

The intermediate sniffer forwards raw packets instead of CDRs.

Sensor B (intermediate):

mirror_bind = 0.0.0.0
mirror_bind_port = 5090
server_destination = central.server.ip
server_destination_port = 60024
packetbuffer_sender = yes

Result:

• B forwards raw packets from A+B to C
• C analyzes all packets and stores PCAP files
• C stores CDRs in MySQL

Compression for Mirroring

When using mirror mode, compression can reduce network bandwidth:

packetbuffer_compress = yes
packetbuffer_compress_ratio = 100
max_buffer_mem = 2000

Adjust packetbuffer_compress_ratio if CPU becomes a bottleneck.

GUI Visibility

Automatic visibility:

• Client-server mode: Only the central server appears in GUI
• Hybrid chain: Only the final server (C) and intermediate forwarder (B) appear

Manual sensor registration:

If you want sensor A to appear in GUI (for RRD charts, remote upgrades):

1. Go to GUI → Settings → Sensors
2. Add sensor A manually with its manager_ip:manager_port
3. Ensure manager_aes_key and manager_aes_iv match GUI database values

Performance Optimization

Client-Server Mode for Better Performance

Switching from standalone to client-server architecture can significantly improve MySQL insert performance:

1. Centralized writes: Single server instance handles all MySQL inserts (reduces lock contention)
2. Enable mysql_enable_set_id: Let application handle ID auto-increment instead of MySQL
3. Optimize MySQL configuration: Tune innodb_flush_log_at_trx_commit, innodb_io_capacity, etc.

Migration steps:

1. Configure server: Set server_bind, server_bind_port, server_password
2. Initially set mysql_enable_set_id = no on server
3. Migrate sniffers one by one: Set server_destination, remove mysqlhost
4. After all sniffers migrated: Enable mysql_enable_set_id = yes on server and restart

SRTP/DTLS Decryption in Mirror Mode

When using mirror mode, ensure SSL/TLS decryption is configured correctly:

On source sniffer (with mirror_destination):

sipport = 5060,5061

This ensures TCP packets (including TLS handshakes) are also mirrored.

On receiving sniffer (with mirror_bind):

Configure SSL decryption options here:

ssl_ipport = ...
ssl_sessionkey = ...

Important Limitations

⚠️ Warning: The hybrid chain workaround is not officially supported and may not work in future sniffer releases.

Key limitations:

1. server_bind and server_destination cannot coexist in one instance
2. Hybrid chain architecture is unstable across sniffer versions
3. No per-client authentication (same password for all clients)
4. Recommended: Use standard multiple clients → single server architecture

Future Enhancement (VS-1605)

A future release may support native dual-mode operation with these new options:

# Server mode (receive connections)
server_bind = 0.0.0.0
server_bind_port = 60024
server_bind_password = receive_secret

# Client mode (send to upstream)
server_destination = upstream.ip
server_destination_port = 60025
server_destination_password = send_secret

# Enable both modes
server_dual_mode = yes

This would enable clean multi-tier architectures without workarounds.

AI Summary for RAG

Summary: This guide explains how to deploy VoIPmonitor in distributed architectures using standalone, client-server, packet mirroring, and hybrid chain topologies. It documents how multiple remote sensors can send data to a central server, how mirror mode forwards raw packets between sniffers, and how a workaround combines mirroring with client mode to build multi-tier chains. The article clarifies where CDRs and PCAPs are stored in each scenario, how sensors appear in the GUI, how to manually register sensors, and how to optimize MySQL and VoIPmonitor configuration when migrating to client-server mode for better performance. It also covers forwarding SIP packets from a SIP-only probe to a central server that merges them with RTP media, using `packetbuffer_sender=yes` with `server_destination`/`server_bind` to create complete CDRs. Additionally, the article covers SRTP/DTLS decryption in mirror mode, current limitations (such as lack of dual-mode server/client in one process), and a proposed future enhancement (VS-1605) that would enable clean multi-hop deployments without workarounds. Keywords: distributed architecture, client-server mode, mirror mode, hybrid chain, remote sensor, CDR forwarding, packet mirroring, packetbuffer_sender, SIP probe forwarding, RTP media merging, server_destination, server_bind, compression, MySQL performance, SRTP, DTLS, GUI sensors, manager_ip, scalability, multi-site monitoring Key Questions:

• How do I connect multiple VoIPmonitor sensors to a single central server using client-server mode?
• When should I use packet mirroring instead of sending only CDRs from remote sensors?
• How are CDRs and PCAP files stored and accessed in client-server versus hybrid chain configurations?
• What are the limitations of combining server_bind and server_destination in a single sniffer instance?
• How can I optimize MySQL and VoIPmonitor settings when migrating from standalone to client-server architecture?
• How do I ensure that all sensors are visible in the GUI and correctly registered for remote management?
• What are the current constraints and future plans (VS-1605) for native multi-tier VoIPmonitor deployments?
• How do I forward SIP packets from a probe to a central server when SIP signaling and RTP media are captured on separate machines?
• How do I configure `packetbuffer_sender=yes` with `server_destination` to merge SIP signaling from one location with RTP media from another?