Architecture: Difference between revisions

From VoIPmonitor.org
No edit summary
No edit summary
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= 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.'''


The VoIPmonitor product contains WEB presentation layer (WEB GUI), Database server (currently only MySQL supported) and Sniffers (called also sensors).  
== 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.


== WEB GUI ==
<kroki lang="plantuml">
The WEB GUI is PHP encoded application with some C++ binaries and can run independently on sniffers and database although it is common to run the GUI alongside with MySQL server and sniffer.
@startuml
title VoIPmonitor Architecture


== Database MySQL server ==
skinparam backgroundColor white
The MySQL server can run independently on WEB GUI or Sniffer on dedicated server. The GUI and Sniffer communicates with MySQL TCP interface. It is common to run GUI database and sniffer on one server.
skinparam defaultFontColor #1e293b
skinparam ArrowColor #475569


== Sniffers (sensors) ==
skinparam rectangle {
The sniffer (sensor) is passive network sniffer (like tcpdump or wireshark). The sniffer analyses packets in realtime and transforms all SIP calls with associated RTP streams into database CDR record which is sent over the TCP to MySQL server (remote or local). If enabled saving SIP / RTP packets the sniffer stores each VoIP call into separate files in native pcap format (to local storage).
    BackgroundColor #e0f4fc
    BorderColor #00A7E3
    RoundCorner 8
}


The sniffer can run only on Linux (or FreeBSD) OS either under virtual server or dedicated native hardware. Currently x86 and >armv5 are supported and tested. Other hardware platforms were not yet tested although it should be compatible with any hardware running Linux OS.
skinparam database {
    BackgroundColor #fef3e2
    BorderColor #f78d1d
}


[[File:architecture.png]]
skinparam storage {
    BackgroundColor #f1f5f9
    BorderColor #475569
}


= single / multiple setup =
skinparam cloud {
    BackgroundColor #e0f4fc
    BorderColor #00719A
}


== Single server ==
rectangle "**Web GUI**\nPHP + C++ binaries\nAnalysis & Reports" as GUI
The most common setup is running GUI, MySQL and Sniffer on a single server but it is often split into dedicated GUI + MySQL server having multiple remote sniffers.


== Central Database with GUI and 1..N remote sniffers (or local sniffer + 1.N remote) ==
database "**MySQL/MariaDB**\nCDR Storage" as DB


Remote sniffers can be configured in two ways - local processing or packet mirroring.
rectangle "**Sensor**\nPacket Capture\nQuality Analysis" as SENSOR


=== Local processing ===
cloud "**Network**\nSIP / RTP / WebRTC" as NET


The sniffer is processing packets and analyses all SIP / RTP packets. The result is database CDR and saved pcap files. This uses CPU and I/O resources accordingly to concurrent calls but keeps network throughput between sniffer and database/GUI at minimal. For more details how to configure it please see this: [[Sniffing_modes#Multiple_remote_sensors_one_DB.2FGUI_server]]
storage "**PCAP**\nRecordings" as PCAP


=== packet mirroring ===
NET -down-> SENSOR : capture\n(SPAN/TAP)
SENSOR -down-> DB : CDR
SENSOR -down-> PCAP : packets
GUI -down-> DB : query
GUI -down-> PCAP : playback
GUI -right-> SENSOR : live\nsniffer


@enduml
</kroki>


Packet mirroring mode (do not confuse it with HW switch packet mirroring or TAP) is special mode where the sniffer is sending every single packet without any processing over TCP compressed stream to another VoIPmonitor sniffer located on another server. This setup is common in situation where you are not able to mirror packets directly via port spanning or taping and you need to install it directly on linux server where the PBX/SBC runs and you do not have enough CPU or I/O or storage resources to process all packets there - the sender sensor uses minimal CPU / memory resources with trade off for higher network throughput. The receiving sniffer can process multiple sniffer senders. The receiver is the same sniffer binary and can be located on the same server with GUI / Database but it can be also dedicated server. For more details please see this [[Sniffing_modes#Mirroring_sniffer]]
=== 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.


= Hardware mirroring =
=== 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.


If the sniffer cannot run directly on PBX/SBC you need to mirror packets to sniffer server. Common approach is to do it in hardware switch. This feature is called spanning / mirroring / taping ports. Check if your switch can do this. Some PBX/SBC are capable of mirroring packets using IP in IP protocol which voipmonitor supports natively (enabled by default).
=== 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 [[Sniffing_modes#Multiple_remote_sensors_one_DB.2FGUI_server|Multiple Remote Sensors guide]].
 
<kroki lang="plantuml">
@startuml
title Remote Probing (Local Processing)
 
skinparam backgroundColor white
skinparam defaultFontColor #1e293b
skinparam ArrowColor #475569
 
skinparam rectangle {
    BackgroundColor #e0f4fc
    BorderColor #00A7E3
    RoundCorner 8
}
 
skinparam database {
    BackgroundColor #fef3e2
    BorderColor #f78d1d
}
 
skinparam storage {
    BackgroundColor #f1f5f9
    BorderColor #475569
}
 
skinparam cloud {
    BackgroundColor #e0f4fc
    BorderColor #00719A
}
 
cloud "PBX/SBC Traffic" as NET1
rectangle "Remote Sensor\nLocal Processing" as SENSOR1
storage "PCAP" as PCAP1
 
rectangle "Web GUI" as GUI
database "MySQL" as DB
 
NET1 -down-> SENSOR1 : capture
SENSOR1 -down-> PCAP1 : packets
SENSOR1 -right-> DB : CDR only
GUI -down-> DB : query
 
note right of SENSOR1 : Remote Site
note right of DB : Central Server
 
@enduml
</kroki>
 
==== 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 [[Sniffing_modes#Mirroring_sniffer|Mirroring Sniffer guide]].
 
<kroki lang="plantuml">
@startuml
title Software Packet Mirroring (SPOOF Mode)
 
skinparam backgroundColor white
skinparam defaultFontColor #1e293b
skinparam ArrowColor #475569
 
skinparam rectangle {
    BackgroundColor #e0f4fc
    BorderColor #00A7E3
    RoundCorner 8
}
 
skinparam database {
    BackgroundColor #fef3e2
    BorderColor #f78d1d
}
 
skinparam storage {
    BackgroundColor #f1f5f9
    BorderColor #475569
}
 
skinparam cloud {
    BackgroundColor #e0f4fc
    BorderColor #00719A
}
 
cloud "PBX/SBC Traffic" as NET1
rectangle "Sender Sensor\nMinimal footprint" as SENDER
 
rectangle "Receiver Sensor\nFull processing" as RECEIVER
rectangle "Web GUI" as GUI
database "MySQL" as DB
storage "PCAP" as PCAP
 
NET1 -down-> SENDER : capture
SENDER -right-> RECEIVER : compressed TCP
RECEIVER -down-> DB : CDR
RECEIVER -down-> PCAP : packets
GUI -down-> DB : query
 
note right of SENDER : Remote Site
note right of RECEIVER : Central Server
 
@enduml
</kroki>
 
== 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]
 
<kroki lang="plantuml">
@startuml
title Physical Network Tapping (SPAN/Port Mirroring)
 
skinparam backgroundColor white
skinparam defaultFontColor #1e293b
skinparam ArrowColor #475569
 
skinparam rectangle {
    BackgroundColor #e0f4fc
    BorderColor #00A7E3
    RoundCorner 8
}
 
skinparam database {
    BackgroundColor #fef3e2
    BorderColor #f78d1d
}
 
skinparam storage {
    BackgroundColor #f1f5f9
    BorderColor #475569
}
 
skinparam cloud {
    BackgroundColor #e0f4fc
    BorderColor #00719A
}
 
cloud "VoIP Traffic" as TRAFFIC
 
rectangle "Hardware PBX\nor SBC" as PBX
 
rectangle "Network Switch" as SWITCH
 
rectangle "VoIPmonitor Sensor" as SENSOR
 
database "MySQL" as DB
storage "PCAP" as PCAP
 
TRAFFIC -down-> SWITCH
SWITCH -down-> PBX : normal traffic
SWITCH -right-> SENSOR : SPAN port
SENSOR -down-> DB : CDR
SENSOR -down-> PCAP : packets
 
note right of SWITCH : Configure SPAN port\nto mirror VoIP traffic
 
@enduml
</kroki>
 
== 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

Latest revision as of 21:00, 11 December 2025

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
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Architecture&oldid=6070"