Sniffing modes

This guide provides a comprehensive overview of VoIPmonitor's deployment models. It covers the fundamental choice between on-host and dedicated sensors, methods for capturing traffic, and detailed configurations for scalable, multi-site architectures.

Core Concept: Where to Capture Traffic

The first decision in any deployment is where the VoIPmonitor sensor (sniffer) will run.

1. On-Host Capture (on the PBX/SBC)

The sensor can be installed directly on the same Linux server that runs your PBX or SBC.

• Pros: Requires no extra hardware, network changes, or port mirroring. It is the simplest setup.
• Cons: Adds CPU, memory, and disk I/O load to your production voice server. If these resources are critical, a dedicated sensor is the recommended approach.

2. Dedicated Sensor

A dedicated Linux server runs only the VoIPmonitor sensor. This is the recommended approach for production environments as it isolates monitoring resources from your voice platform. To use a dedicated sensor, you must forward a copy of the network traffic to it using one of the methods below.

Methods for Forwarding Traffic to a Dedicated Sensor

A. Hardware Port Mirroring (SPAN/RSPAN)

This is the most common and reliable method. You configure your physical network switch to copy all traffic from the switch ports connected to your PBX/SBC to the switch port connected to the VoIPmonitor sensor. This feature is commonly called Port Mirroring, SPAN, or RAP. Consult your switch's documentation for configuration details.

The VoIPmonitor sensor interface will be put into promiscuous mode automatically. To capture from multiple interfaces, set interface = any in voipmonitor.conf and enable promiscuous mode manually on each NIC (e.g., ifconfig eth1 promisc).

B. Software-based Tunnelling

When hardware mirroring is not an option, many network devices and PBXs can encapsulate VoIP packets and send them to the sensor's IP address using a tunnel. VoIPmonitor natively supports a wide range of protocols.

• Built-in Support: IP-in-IP, GRE, ERSPAN
• UDP-based Tunnels: Configure the corresponding port in voipmonitor.conf:
  • udp_port_tzsp = 37008 (for Mikrotik's TZSP)
  • udp_port_l2tp = 1701
  • udp_port_vxlan = 4789 (Common in AWS environments)
• Proprietary & Other Protocols:
  • AudioCodes Tunneling (uses udp_port_audiocodes or tcp_port_audiocodes)
  • HEP (v3+) (enable hep* options)
  • IPFIX (for Oracle SBCs) (enable ipfix* options)

Distributed Deployment Models

For monitoring multiple remote offices or a large infrastructure, a distributed model is essential. This involves a central GUI/Database server collecting data from multiple remote sensors.

Classic Mode: Standalone Remote Sensors

In this traditional model, each remote sensor is a fully independent entity.

• How it works: The remote sensor processes packets and stores PCAPs locally. It connects directly to the central MySQL database to write CDRs. The central GUI must also have direct network access to each sensor's management port (default 5029) to fetch PCAP files.
• Pros: Simple conceptual model.
• Cons: Requires opening firewall ports to each sensor and managing database credentials on every remote machine.

Modern Mode: Client/Server Architecture (v20+)

This is the recommended model for all new distributed deployments. It uses a secure, encrypted TCP channel between remote sensors (clients) and a central sensor instance (server). The GUI only needs to communicate with the central server.

This model supports two modes of operation:

1. Local Processing: Remote sensors process packets locally and send only the small CDR data over the encrypted channel. PCAPs remain on the remote sensor.
2. Packet Mirroring: Remote sensors do no processing. They forward the entire raw packet stream over the encrypted channel to the central server, which handles all processing and storage. This is ideal for low-resource remote devices.

Comparison of Remote Deployment Modes

Deployment Model	Packet Processing Location	PCAP Storage Location	Network Traffic to Central Server	GUI Connectivity
Classic Standalone	Remote	Remote	Minimal (MySQL CDRs)	GUI ↔ each Sensor (management port)
Modern Client/Server (Local Processing)	Remote	Remote	Minimal (Encrypted CDRs)	GUI ↔ Central Server only
Modern Client/Server (Packet Mirroring)	Central	Central	High (Encrypted full packets)	GUI ↔ Central Server only

Configuration & Checklists

Client/Server Configuration Example

Below is a minimal configuration for the modern client/server model.

On each Remote Sensor (Client)

# /etc/voipmonitor.conf on the remote sensor

id_sensor               = 2      # MUST be unique for each sensor, < 65536
server_destination      = 10.0.0.1 # IP address of your central server
server_destination_port = 60024
server_password         = your_strong_password

# Optional: Uncomment the next line to enable packet mirroring mode
# packetbuffer_sender   = yes

On the Central Server

# /etc/voipmonitor.conf on the central server

server_bind             = 0.0.0.0
server_bind_port        = 60024
server_password         = your_strong_password

# Remember to configure mysql* options for the central database connection
mysqlhost               = localhost
mysqldb                 = voipmonitor
mysqluser               = root
mysqlpassword           = db_password

Firewall Checklist

• Modern Client/Server Mode (v20+):
  • On Central Server: Allow inbound TCP/60024 from remote sensors. Allow inbound TCP/5029 for GUI management access.
• Cloud Mode:
  • On Remote Sensors: Allow outbound TCP/60023 to cloud.voipmonitor.org.

Time Synchronization

Accurate and synchronized time is critical for correlating call legs from different sensors. All servers (GUI, DB, and all Sensors) must run an NTP client (like `chrony` or `ntpdate`) to keep their clocks in sync.

AI Summary for RAG

Summary: This guide covers the deployment topologies for VoIPmonitor. It contrasts running the sensor on the same host as a PBX versus on a dedicated server. For dedicated sensors, it details methods for forwarding traffic, including hardware-based port mirroring (SPAN) and various software-based tunneling protocols (IP-in-IP, GRE, TZSP, VXLAN, HEP, etc.). The core of the article explains distributed architectures for multi-site monitoring, comparing the "classic" standalone remote sensor model with the modern, recommended "client/server" model. It details the two operational modes of the client/server architecture: local processing (sending only CDRs) and packet mirroring (sending full, raw packets for central processing), which is ideal for low-resource endpoints. The guide concludes with minimal configuration examples and firewall rules for the client/server setup and emphasizes the critical importance of time synchronization using NTP. Keywords: deployment, architecture, topology, on-host, dedicated sensor, port mirroring, SPAN, RSPAN, traffic mirroring, tunneling, GRE, TZSP, VXLAN, HEP, remote sensor, multi-site, client server mode, packet mirroring, local processing, firewall rules, NTP, time synchronization, cloud mode Key Questions:

• How do I set up VoIPmonitor to monitor multiple remote locations?
• What is the difference between the classic remote sensor and the modern client/server mode?
• When should I use packet mirroring (packetbuffer_sender) instead of local processing?
• What are the firewall requirements for the client/server deployment model?
• Can I run the sensor on the same machine as my Asterisk/FreeSWITCH server?
• What is a SPAN port and how is it used with VoIPmonitor?
• Why is NTP important for a distributed VoIPmonitor setup?