|
|
| Line 1: |
Line 1: |
| {{DISPLAYTITLE:Database Replication using a Dedicated Sniffer Instance}} | | {{DISPLAYTITLE:Active Calls (Real-time Monitoring)}} |
| [[Category:GUI manual]] | | [[Category:GUI manual]] |
|
| |
|
| This guide explains how to use a dedicated VoIPmonitor sensor instance to perform real-time replication of the CDR database to a secondary MySQL/MariaDB server. This provides a native, application-level method for creating backups or read-only replicas. | | This page describes the Active Calls view, which provides real-time monitoring of ongoing calls in the VoIPmonitor GUI. |
|
| |
|
| == Overview & Use Case == | | == Overview == |
| VoIPmonitor offers multiple built-in mechanisms to replicate or synchronize Call Detail Records (CDRs) between instances. These methods enable datacenter failover, disaster recovery, hot-standby setups, and centralized reporting.
| |
|
| |
|
| === Available Synchronization Methods ===
| | The Active Calls view displays current calls in real time and allows you to listen to G.711 calls live (requires sniffer version 7 or newer). The view refreshes automatically according to the configured refresh interval (default: 2 seconds). |
|
| |
|
| There are three primary approaches for synchronizing CDRs between VoIPmonitor instances:
| | === Communication with Sniffer === |
|
| |
|
| ;1. Database Backup Mode (Read-Only Replica)
| | Live call data is fetched from the VoIPmonitor sniffer instance through the manager TCP port 5029. If calls are not displayed, verify that the web server can reach this port: |
| :Use a dedicated sniffer instance to read from the primary database and write to a secondary database. This creates a one-way, read-only replica. This method is ideal for online GUI migration, hot-standby setups, or centralized reporting.
| |
|
| |
|
| ;2. Master-Master Database Replication
| | <kroki lang="mermaid"> |
| :Configure MySQL/MariaDB in a bidirectional replication topology. Both instances can write CDRs, and changes automatically propagate between them. This provides full high-availability with automatic failover and read load balancing. See [[Mysql_master-master_replication_hints|Master-Master Replication]] for detailed setup.
| | flowchart LR |
| | | subgraph GUI["Web GUI"] |
| ;3. Dual Write Method
| | Browser["Browser"] |
| :Configure the active sniffer to write CDRs simultaneously to both a local and a remote database. This provides real-time synchronization without requiring MySQL replication setup. '''Note:''' This method only synchronizes CDRs; it does not synchronize GUI settings (users, sensors, capture rules, etc.).
| | PHP["PHP Backend"] |
| | | end |
| This article primarily covers '''Method 1 (Database Backup Mode)'''. Method 2 is covered in the [[Mysql_master-master_replication_hints|Master-Master Replication]] guide. Method 3 is described below.
| | subgraph Sniffer["VoIPmonitor Sniffer"] |
| | | Manager["Manager API<br/>Port 5029"] |
| The database backup mode method is particularly useful for:
| | Capture["Packet Capture"] |
| * '''Online GUI Migration''': Migrating the GUI database from an old server to a new server with minimal or no downtime. The sensor replicates CDR data incrementally while users continue using the old GUI. Once replication completes, you can switch users to the new GUI without service interruption.
| | end |
| * Creating a read-only replica database for reporting or analysis without impacting the performance of the primary database.
| | Browser -->|HTTP/HTTPS| PHP |
| * Setting up a hot-standby database for disaster recovery.
| | PHP -->|TCP 5029| Manager |
| * Consolidating data from multiple, smaller VoIPmonitor databases into one central database.
| | Manager -->|Active Call Data| PHP |
| | | Capture -->|Live Data| Manager |
| The process incrementally syncs data starting from a specified date, ensuring that the destination database stays up-to-date in near real-time.
| |
| | |
| === Architecture Overview ===
| |
| | |
| <kroki lang="plantuml"> | |
| @startuml
| |
| skinparam shadowing false
| |
| skinparam defaultFontName Arial
| |
| skinparam rectangle {
| |
| BorderColor #4A90E2
| |
| BackgroundColor #FFFFFF
| |
| }
| |
| | |
| rectangle "OLD Server" as OLD {
| |
| rectangle "VoIPmonitor\nSniffer" as SNIFF
| |
| database "MySQL\n(Source DB)" as SRC_DB
| |
| }
| |
| | |
| rectangle "NEW Server" as NEW {
| |
| rectangle "Migration\nInstance" as MIG
| |
| database "MySQL\n(Destination DB)" as DST_DB
| |
| }
| |
| | |
| SNIFF -down-> SRC_DB : writes CDRs
| |
| MIG -left-> SRC_DB : reads CDRs\n(database_backup_from_*)
| |
| MIG -down-> DST_DB : writes CDRs\n(mysql*)
| |
| | |
| note bottom of MIG
| |
| Migration instance runs with:
| |
| - No packet capture (interface disabled)
| |
| - Different managerport (5030)
| |
| - database_backup_from_date = 2024-01-01
| |
| end note
| |
| @enduml
| |
| </kroki> | | </kroki> |
|
| |
| == Online GUI Migration Workflow ==
| |
| When migrating the GUI to a new server, you have two primary methods:
| |
|
| |
| === Method 1: Dump/Restore (With Downtime) ===
| |
| If a service interruption is acceptable:
| |
| # Stop the sniffer on the old server
| |
| # Perform a database dump:
| |
| #:<syntaxhighlight lang="bash">mysqldump -u root -p voipmonitor > backup.sql</syntaxhighlight>
| |
| # Transfer and restore on new server:
| |
| #:<syntaxhighlight lang="bash">mysql -u root -p voipmonitor < backup.sql</syntaxhighlight>
| |
| # Repoint the GUI to the new database
| |
| # Install and configure the new GUI instance
| |
|
| |
| This method is simple but requires downtime and may take hours for terabyte-sized databases.
| |
|
| |
| === Method 2: Online Migration (Minimal/No Downtime) ===
| |
| Using the sensor's database backup mode:
| |
| # Install VoIPmonitor GUI on the new server with a fresh empty database
| |
| # On the old GUI: Go to '''Tools → Backup & Restore → Backup configuration TABLES''' and download the backup file
| |
| # On the new GUI: Go to '''Tools → Backup & Restore → Restore configuration tables''' and upload the backup file
| |
| #:'''IMPORTANT:''' Complete this step BEFORE starting the migration instance
| |
| # Create a <code>voipmonitor-migrate.conf</code> file by copying the old <code>voipmonitor.conf</code> and adding migration options (see Configuration section below)
| |
| # Configure and run the migration instance in "database backup mode" on the new server
| |
| # The sensor connects to the old database and replicates CDR data incrementally
| |
| # Once replication catches up, switch users to the new GUI
| |
| # Stop migration instance and decommission the old server
| |
|
| |
| For assistance with this method, provide remote SSH access to both the old and new hosts to the support team.
| |
|
| |
| == Comparison: Dump/Restore vs Online Migration ==
| |
|
| |
| {| class="wikitable"
| |
| |-
| |
| ! Aspect !! Dump/Restore !! Online Migration
| |
| |-
| |
| | '''Downtime''' || Required (hours for large DBs) || Minimal/None
| |
| |-
| |
| | '''Complexity''' || Low - Manual SQL dump || Medium - Sensor configuration
| |
| |-
| |
| | '''Data Loss Risk''' || Moderate (if dump fails) || Low - Incremental sync
| |
| |-
| |
| | '''Best For''' || Small databases || Large databases, zero-downtime requirements
| |
| |}
| |
|
| |
| == Configuration ==
| |
| To set up database replication, you will run a new, dedicated VoIPmonitor sensor instance on the server that hosts your '''secondary (destination)''' database. This instance requires its own <code>voipmonitor.conf</code> file.
| |
|
| |
| === Creating the Migration Configuration File ===
| |
|
| |
| The migration configuration file should be named consistently to avoid confusion (e.g., <code>voipmonitor-migrate.conf</code>).
| |
|
| |
| '''Important:''' Start with a copy of the existing configuration. The easiest way to create this configuration is to copy the existing <code>voipmonitor.conf</code> from the old server and add the migration-specific options. This ensures all existing settings are preserved.
| |
|
| |
|
| <syntaxhighlight lang="bash"> | | <syntaxhighlight lang="bash"> |
| # On the NEW server, copy the old config:
| | telnet localhost 5029 |
| scp root@old-server:/etc/voipmonitor.conf /etc/voipmonitor-migrate.conf
| |
| </syntaxhighlight> | | </syntaxhighlight> |
|
| |
|
| Then edit <code>/etc/voipmonitor-migrate.conf</code> to modify the critical settings for migration mode.
| | === Direct URL Access === |
|
| |
|
| === Required Modifications ===
| | You can open the Active Calls view directly using this URL format: |
|
| |
|
| If you plan to run the migration instance while the original sniffer continues to capture traffic (zero-downtime migration), you '''MUST''' make the following changes to avoid conflicts:
| | <syntaxhighlight lang="text"> |
| | http://your-server/admin.php?activecalls=1 |
| | </syntaxhighlight> |
|
| |
|
| <syntaxhighlight lang="ini">
| | == Filtering Calls == |
| # --- 1. CRITICAL: Change managerport to avoid conflicts ---
| |
| # The original sniffer typically uses managerport = 5029
| |
| managerport = 5030
| |
|
| |
|
| # --- 2. CRITICAL: Disable all packet capture bindings ---
| | The filter box adapts to the type of input provided. Calls can be filtered by: |
| # These prevent the migration instance from competing for network interfaces
| |
| # Comment out or delete ALL interface/bind options:
| |
| # interface = eth0 # DISABLE - do not capture packets
| |
| # interface = eth1 # DISABLE - do not capture packets
| |
| # interface = any # DISABLE - do not capture packets
| |
|
| |
|
| # --- 3. Destination Database (where to write data) ---
| | * National or international (via combo box) |
| # Update to point to the NEW server's local database
| | * Sensor |
| mysqlhost = 127.0.0.1
| | * IP address or IP prefix |
| mysqldb = voipmonitor
| | * Phone number or prefix |
| mysqlusername = root
| | * Call-ID |
| mysqlpassword = new_db_password
| |
| cdr_partition = yes
| |
|
| |
|
| # --- 4. Source Database (where to read data from) ---
| | === Filter Syntax Examples === |
| # These parameters are ADDED to enable replication from the old database
| |
| database_backup_from_mysqlhost = 192.168.0.1
| |
| database_backup_from_mysqldb = voipmonitor
| |
| database_backup_from_mysqlusername = root
| |
| database_backup_from_mysqlpassword = old_db_password
| |
| | |
| # --- 5. Replication Control ---
| |
| # Choose the date from which replication should begin
| |
| database_backup_from_date = 2024-01-01
| |
| | |
| # Performance tuning for replication speed
| |
| database_backup_insert_threads = 3
| |
| database_backup_pause = 3
| |
| | |
| # Performance Impact Explanation:
| |
| # - database_backup_pause: Higher values (e.g., 10-60 seconds) create MORE pause between batches,
| |
| # resulting in LOWER load on the SOURCE database. Use high values if the source database
| |
| # is also handling live traffic and cannot withstand additional replication load.
| |
| # - database_backup_insert_threads: Higher values use MORE threads for inserting data,
| |
| # resulting in HIGHER load on both source and destination databases. Lower values (1-2)
| |
| # are gentler on the system but replication is slower.
| |
| | |
| # --- 6. Optional: Migrate Static Data ---
| |
| # Set to 'yes' if migrating static data and you want to write NEW data to the new database.
| |
| # This is useful when you want the new server to continue accepting data after migration.
| |
| database_backup_desc_dir = yes
| |
| </syntaxhighlight>
| |
| | |
| {{Note|<code>database_backup_desc_dir = yes</code> is an optional parameter that should be used when migrating static data (historical CDRs) and you plan to write new data to the destination database. This tells the migration instance to write both migrated data AND future new data to the destination database.}}
| |
| | |
| === Configuration Parameters Reference ===
| |
|
| |
|
| {| class="wikitable" | | {| class="wikitable" |
| |- | | |- |
| ! Parameter !! Description | | ! Input !! Description |
| |-
| |
| | <code>managerport</code> || TCP port for the sensor's manager API. Must be different from the production sniffer (default: 5029).
| |
| |-
| |
| | <code>interface</code> || Network interface(s) to capture. Must be disabled/commented out for migration instance.
| |
| |-
| |
| | <code>mysqlhost</code> || IP/hostname of the '''destination''' database (new server).
| |
| |- | | |- |
| | <code>database_backup_from_mysqlhost</code> || IP/hostname of the '''source''' database (old server). | | | <code>192.168.%</code> || Filters calls with source or destination IP starting with 192.168.x.x |
| |- | | |- |
| | <code>database_backup_from_date</code> || Start date for incremental sync (format: YYYY-MM-DD). | | | <code>00</code> || Filters calls where the number starts with 00 |
| |- | | |- |
| | <code>database_backup_insert_threads</code> || Number of parallel threads for inserting data (default: 1). Higher values = higher load on both source and destination databases. Lower values (1-2) = gentler on the system but slower replication. | | | <code>abc123</code> || Searches for exact Call-ID match |
| |- | | |- |
| | <code>database_backup_pause</code> || Pause in seconds between sync batches (default: 0). Higher values = lower load on the SOURCE database. Use high values (10-60 seconds) if the source database handles live traffic. | | | <code>%abc123%</code> || Searches for Call-ID containing "abc123" (substring match) |
| |} | | |} |
|
| |
|
| === Why These Changes Are Required ===
| | Note: By default, Call-ID search matches the full Call-ID string. To search for a substring, add the <code>%</code> wildcard character to the start and/or end of the search string. |
|
| |
|
| ;'''managerport'''
| | == Bottom Graphs == |
| :VoIPmonitor uses this port for internal communication and GUI connectivity. If both instances use the same port, they will conflict.
| |
|
| |
|
| ;'''interface options'''
| | The bottom section of the Active Calls view displays graphs showing the top callers grouped by: |
| :The migration instance should NOT capture packets - its only purpose is database replication. Disabling packet capture prevents:
| | * Caller IP address |
| :* CPU competition with the production sniffer | | * Called IP address |
| :* Duplicate packets being processed by both instances
| |
| :* Network interface conflicts
| |
|
| |
|
| === GUI Configuration Backup ===
| | [[File:activecalls.png]] |
|
| |
|
| Before starting the migration instance, you must migrate the GUI configuration tables (users, sensors, capture rules, alerts). This is done via the GUI's '''Tools → Backup & Restore''' feature.
| | == Customizing Column Visibility == |
|
| |
|
| '''IMPORTANT:''' Complete this step BEFORE starting the migration instance. See [[Backup_and_restore_GUI_tables|Backup and restore GUI tables]] for detailed instructions.
| | The Active Calls view allows you to show or hide columns based on your preferences. This is useful when: |
|
| |
|
| == Running the Replication Instance ==
| | * You want to reduce visual clutter and focus on specific information |
| | | * Certain columns contain data that is causing performance issues (e.g., parsing errors in the Proxy column) |
| Once your configuration file is ready, you can start the sensor in this special mode.
| | * Your display has limited screen space |
| | |
| === Manual Test Run ===
| |
| It is highly recommended to first run the process manually to ensure all settings are correct and there are no connection errors.
| |
| | |
| <syntaxhighlight lang="bash">
| |
| voipmonitor --config-file /etc/voipmonitor-migrate.conf -k -v 1
| |
| </syntaxhighlight>
| |
|
| |
|
| ;Command-line options:
| | To hide or show columns: |
| * <code>-k</code>: Prevents the process from forking into the background (keeps it in foreground).
| |
| * <code>-v 1</code>: Sets verbosity to level 1, which will show status information.
| |
|
| |
|
| Watch the output for any database connection errors or other warnings. A successful start will show messages indicating CDR data is being read from the source and written to the destination.
| | # Locate the column header area at the top of the table |
| | # Click on the column visibility icon (typically a column or grid icon) or look for a "Show columns" dropdown menu |
| | # Uncheck columns you want to hide, check columns you want to show |
| | # The view will update immediately with your selection |
|
| |
|
| === Running as a Service ===
| | Your column visibility preferences are stored in the GUI configuration (saved in the MySQL <code>custom_config</code> table) and persist across sessions. |
| To run the migration instance permanently as a background service, you will need to create a separate <code>systemd</code> or <code>init.d</code> service file for it. This process is covered in the [[Multiple_sniffer_instancies|Multiple Sniffer Instances]] guide. The key is to ensure the new service unit file uses the <code>-c /etc/voipmonitor-migrate.conf</code> argument to load your specific configuration.
| |
|
| |
|
| Example <code>systemd</code> unit file (<code>/etc/systemd/system/voipmonitor-migrate.service</code>):
| | === Troubleshooting Performance Issues === |
|
| |
|
| <syntaxhighlight lang="ini">
| | If the Active Calls view becomes unresponsive or slow, particularly when displaying certain columns like "Proxy": |
| [Unit]
| |
| Description=VoIPmonitor Database Migration Instance
| |
| After=network.target mysql.service
| |
|
| |
|
| [Service]
| | ;Temporary workaround: |
| Type=simple
| | :Hide the problematic column using the column visibility method above. |
| ExecStart=/usr/local/sbin/voipmonitor -c /etc/voipmonitor-migrate.conf
| |
| Restart=on-failure
| |
|
| |
|
| [Install]
| | ;If the GUI is completely unresponsive: |
| WantedBy=multi-user.target
| | :* Connect directly to the GUI database |
| </syntaxhighlight> | | :* Check the <code>custom_config</code> table for column visibility settings |
| | :* Clear or modify the relevant configuration entries |
| | :* Contact support with SSH access to the GUI host for investigation |
|
| |
|
| Enable and start:
| | ;Information to provide for support: |
| <syntaxhighlight lang="bash"> | | :* A SIP PCAP dump of a problematic call (to identify data causing parsing errors) |
| systemctl daemon-reload
| | :* A mysqldump of the <code>voipmonitor.custom_config</code> table (to review current column configuration) |
| systemctl enable voipmonitor-migrate
| |
| systemctl start voipmonitor-migrate
| |
| </syntaxhighlight> | |
|
| |
|
| == Dual Write Method (Real-Time Synchronization) == | | == Programmatic Access to Active Calls == |
|
| |
|
| The dual write method is a simpler alternative to MySQL replication for synchronizing CDRs between two active VoIPmonitor instances. Instead of configuring database replication at the MySQL level, you configure the sniffer to write each CDR to both a local (primary) and a remote (secondary) database simultaneously.
| | In addition to viewing active calls in the GUI, you can programmatically retrieve active call data for automation and integration purposes. |
|
| |
|
| === Overview === | | === GUI API (Recommended for Centralized Systems) === |
|
| |
|
| In this setup, the sniffer writes each CDR record to two databases:
| | The VoIPmonitor GUI provides a web API endpoint <code>listActiveCalls</code> that retrieves active calls from all connected sensors/probes. This is the preferred method for centralized monitoring environments. |
| * '''Primary Database''' (local): The main database for the instance
| |
| * '''Secondary Database''' (remote): The secondary instance's database
| |
|
| |
|
| This provides real-time synchronization without the complexity of MySQL replication configuration.
| | *Method:* HTTP POST or GET to <code>/php/api.php?task=listActiveCalls</code> |
| | *Documentation:* [[WEB_API#listActiveCalls]] |
|
| |
|
| === Use Cases ===
| | Example: |
| | | <syntaxhighlight lang="bash"> |
| * '''Active-Active Datacenter Deployment''': Two separate datacenters both capturing traffic, with each sniffer writing to the other's database
| | curl -X POST 'http://yourserver/php/api.php?task=listActiveCalls&user=USER&password=PASSWORD¶ms={"sensorId":"1"}' |
| * '''Real-time Backup''': Every CDR is immediately backed up to a remote database
| |
| * '''Centralized Reporting''': Multiple sniffers write to a central reporting database
| |
| | |
| === Configuration ===
| |
| | |
| To enable dual write mode, add the secondary database connection parameters to your <code>voipmonitor.conf</code>:
| |
| | |
| <syntaxhighlight lang="ini"> | |
| # Primary Database Connection (Local)
| |
| mysqlhost = 127.0.0.1
| |
| mysqldb = voipmonitor
| |
| mysqlusername = root
| |
| mysqlpassword = primary_password
| |
| | |
| # Secondary Database Connection (Remote) - These parameters enable dual write
| |
| mysql2host = 192.168.1.100
| |
| mysql2db = voipmonitor
| |
| mysql2username = root
| |
| mysql2password = secondary_password
| |
| </syntaxhighlight> | | </syntaxhighlight> |
|
| |
|
| === Important Notes === | | === Sniffer Manager API (For Individual Sensors) === |
| | |
| ;'''GUI Settings Not Synchronized'''
| |
| :The dual write method only replicates CDR data. GUI configuration tables (users, sensors, capture rules, alerts) are NOT synchronized. You must manually configure these on each instance.
| |
| | |
| ;'''Write Performance Impact'''
| |
| :Writing to two databases adds overhead. Ensure your network can handle the additional database traffic. Consider using a dedicated database server for the secondary if performance becomes an issue.
| |
| | |
| ;'''Connection Failure Handling'''
| |
| :If the secondary database becomes unreachable, the sniffer will log connection errors but continue writing to the primary database. CDRs written during the outage will NOT be retroactively synced.
| |
| | |
| ;'''Suitable for Simple Scenarios'''
| |
| :For complex high-availability requirements with bidirectional write support, consider [[Mysql_master-master_replication_hints|Master-Master replication]] instead.
| |
| | |
| === Comparison: Dual Write vs Master-Master Replication ===
| |
| | |
| {| class="wikitable"
| |
| |-
| |
| ! Aspect !! Dual Write Method !! Master-Master Replication
| |
| |-
| |
| | '''Configuration Complexity''' || Low - Add mysql2* parameters || Medium - MySQL replication setup
| |
| |-
| |
| | '''Bidirectional Sync''' || No - A writes to B (one-way) || Yes - A and B sync with each other
| |
| |-
| |
| | '''GUI Settings Sync''' || No || Yes (via MySQL replication)
| |
| |-
| |
| | '''Automatic Failover''' || No || Yes (with load balancer)
| |
| |-
| |
| | '''Best For''' || Simple one-way backup || Full high-availability setup
| |
| |}
| |
|
| |
|
| == Migrating PCAP (Packet Capture) Files ==
| | For direct access to a single sensor instance, use the sniffer service's manager API on port 5029. The <code>listcalls</code> command retrieves active call data from the specific sensor. |
| The database migration process described above migrates only the '''CDR (Call Detail Records)'''. It does not migrate PCAP files. You must migrate PCAP files separately.
| |
|
| |
|
| === Using rsync to Copy PCAPs ===
| | *Method:* TCP connection to port 5029 |
| | | *Documentation:* [[Encryption_in_manager_api_customer#How_to_use_the_API_-_examples|Manager API]] |
| Use <code>rsync</code> over SSH to copy the <code>spooldir</code> (default: <code>/var/spool/voipmonitor</code>) from the old server to the new server.
| |
|
| |
|
| | Example: |
| <syntaxhighlight lang="bash"> | | <syntaxhighlight lang="bash"> |
| # Run on NEW SERVER pulling from OLD
| | echo 'listcalls' | nc localhost 5029 |
| rsync -avz root@old-server:/var/spool/voipmonitor/ /var/spool/voipmonitor/
| |
| </syntaxhighlight> | | </syntaxhighlight> |
|
| |
|
| ;<code>-a</code>: Archive mode (preserves permissions, times, symbolic links)
| | The manager API supports filtering by caller number, called number, IP addresses, and other criteria. See the [[Encryption_in_manager_api_customer#Example_with_filter_used|Manager API documentation]] for advanced filtering examples. |
| ;<code>-v</code>: Verbose output
| |
| ;<code>-z</code>: Compress during transfer (saves bandwidth)
| |
| | |
| === Timezone Considerations (CRITICAL) ===
| |
| | |
| ;'''OS Timezone Must Match'''
| |
| :If you are copying PCAP files from an old probe to a new probe that will continue capturing, ensure both systems have the <strong>same OS timezone</strong> configured.
| |
| | |
| PCAP file paths are based on directory structure: <code>spooldir/YYYY-MM-DD/HH/MM/</code>. The directory structure uses the system's local timezone. If the old probe was in timezone A and the new probe is in timezone B, the new probe will create PCAP files in different directory paths than the old files. This can cause the GUI to fail to find or link historical PCAPs.
| |
| | |
| The database stores relative paths, so as long as the directory structure is preserved and the timezone remains the same, the GUI will correctly reference the old PCAPs.
| |
| | |
| To check/set timezone:
| |
| <syntaxhighlight lang="bash">
| |
| # Check current timezone | |
| timedatectl
| |
| | |
| # Set timezone (example for Europe/Prague)
| |
| timedatectl set-timezone Europe/Prague
| |
| </syntaxhighlight>
| |
|
| |
|
| === Architecture-Specific Considerations === | | === Choosing the Right Method === |
|
| |
|
| ;'''Client-Server Mode with Local Processing'''
| | *Use the GUI <code>listActiveCalls</code> API when:* |
| :In the new architecture where probes store their own PCAPs (<code>packetbuffer_sender=no</code>), you have these options:
| | * You have multiple sensors/probes and need centralized access |
| :* Keep the PCAPs on the OLD probe hardware if it is becoming one of the new probes
| | * You want to query all connected sensors from a single endpoint |
| :* Archive historical PCAPs to external storage
| | * You are building external integrations that need filtered results |
| :* Copy to the new probe '''only if timezone matches'''
| |
|
| |
|
| ;'''Centralized PCAP Storage'''
| | *Use the sniffer manager API when:* |
| :If you are centralizing PCAPs (<code>packetbuffer_sender=yes</code>), copy all old PCAPs to the Central Server's spool directory. Ensure the central server's OS timezone matches all probes' timezones.
| | * You need direct access to a specific sensor instance |
| | * You are running scripts locally on the sensor host |
| | * You require low-latency queries without GUI involvement |
|
| |
|
| == AI Summary for RAG == | | == AI Summary for RAG == |
| '''Summary:''' This article describes three methods for synchronizing VoIPmonitor databases between instances: (1) Database Backup Mode - using a dedicated sensor in "database backup mode" to perform application-level replication for read-only replicas (described in detail here), (2) Master-Master Database Replication - bidirectional MySQL/MariaDB replication for full high-availability (covered in [[Mysql_master-master_replication_hints|Master-Master Replication]]), and (3) Dual Write Method - configuring the sniffer to write CDRs simultaneously to local and remote databases using mysql2* parameters. The article primarily covers Method 1 with configuration details for setting up destination (mysqlhost) and source (database_backup_from_mysqlhost) databases, including database_backup_from_date for sync control. To control database load during replication, use database_backup_pause (higher values = lower load on source database) and database_backup_insert_threads (higher values = higher load on both databases). PCAP files must be migrated separately using rsync, with critical attention to timezone matching between servers. | | '''Summary:''' Active Calls provides real-time monitoring of ongoing VoIP calls with live listening capability for G.711 codec. Calls are fetched via manager port 5029 and can be filtered by IP, number, sensor, or Call-ID. Column visibility can be customized and settings persist in the database. Programmatic access is available through two methods: the GUI's listActiveCalls API for centralized monitoring of multiple sensors, and the sniffer's manager API (listcalls command) for direct sensor access. |
|
| |
|
| '''Keywords:''' database replication, backup, mysql backup, mariadb replication, replica, read-only, standby, disaster recovery, GUI migration, migrate database, online migration, zero downtime, database_backup_from_date, database_backup_from_mysqlhost, voipmonitor.conf, high availability, PCAP migration, spooldir, rsync, timezone, packetbuffer_sender, client-server mode, centralized storage, dual write, mysql2host, master-master replication, synchronize, datacenter, performance tuning, database_backup_pause, database_backup_insert_threads, performance impact, load control | | '''Keywords:''' active calls, real-time monitoring, live calls, manager port 5029, call filter, column visibility, custom_config, G.711 listening, listActiveCalls API, programmatic access, automation, manager API, listcalls command |
|
| |
|
| '''Key Questions:''' | | '''Key Questions:''' |
| * How can I synchronize CDRs between two VoIPmonitor instances? | | * How do I view active/live calls in VoIPmonitor? |
| * What methods are available for database replication in VoIPmonitor? | | * Why are active calls not showing in the GUI? |
| * What is the difference between database backup mode, dual write, and master-master replication?
| | * How do I filter calls by IP address or phone number? |
| * How can I migrate the GUI database with minimal downtime?
| | * How do I hide or show columns in the Active Calls view? |
| * What is the difference between dump/restore and online migration?
| | * What port is used for fetching live call data? |
| * How can I create a real-time backup of my VoIPmonitor database? | | * How can I programmatically check if a call to a specific phone number is currently active? |
| * How do I configure dual write mode (mysql2*)? | | * What is the difference between listActiveCalls API and the sniffer's manager API? |
| * What configuration is needed to mirror the VoIPmonitor database? | | * How do I retrieve active calls from all connected sensors? |
| * Can I use VoIPmonitor to create a read-only replica for reporting?
| | * How do I query active calls from a single sensor directly? |
| * How does database_backup_from_date work? | |
| * How do I migrate PCAP files to a new server?
| |
| * Why is timezone matching important when migrating PCAP files? | |
| * How can I use rsync to copy VoIPmonitor spooldir? | |
| * How can I control the database load during replication? | |
| * What is database_backup_pause and how does it affect performance?
| |
| * What is database_backup_insert_threads and how does it affect performance?
| |
