How to enable milliseconds precision
This guide explains how to manage millisecond precision for timestamps in VoIPmonitor. While all new installations since 2025 have this feature enabled by default, this guide details how to enable it on older systems or disable it if needed.
Overview
VoIPmonitor can store and display all call-related timestamps (like `calldate` and `callend`) with either second or millisecond resolution. Millisecond precision is useful for granular analysis and troubleshooting of call timing issues.
- Modern Installations (2023+): Millisecond precision is enabled by default. You do not need to take any action.
- Older Installations: If your system was installed before this feature became the default, timestamps will be stored with second precision. This guide explains how to perform the necessary database migration.
The process for enabling this feature on an older system depends on whether your database already contains data.
Scenario A: For New or Empty Databases (Legacy Setups)
If you are setting up an older version of VoIPmonitor on a new, empty database, the process is a simple one-line configuration change.
- Step 1
- Edit voipmonitor.conf
- Add the following line to `/etc/voipmonitor.conf`:
time_precision_in_ms = yes
- Step 2
- Restart the Sniffer
- Restart the sensor service. On its first connection to the empty database, it will automatically create all tables with the correct `DATETIME(3)` and `DECIMAL` column types.
systemctl restart voipmonitor
Scenario B: For Existing Databases with Data (Legacy Setups)
If you have an existing, older database with call data, enabling millisecond precision requires altering numerous tables. This can be a very long and resource-intensive process, potentially taking hours or even days on databases with billions of records. It is strongly recommended to perform this during a planned maintenance window.
The process involves two steps: first enabling the setting in the configuration, and second, migrating the database schema.
Step 1: Enable the Setting in voipmonitor.conf
First, add the following line to `/etc/voipmonitor.conf`. This tells the sniffer to start using the new format once the database is ready.
time_precision_in_ms = yes
Do not restart the sniffer yet! The database schema must be updated first.
Step 2: Migrate the Database Schema
You can perform the migration either through the GUI (recommended) or manually via the command line.
Option 1: Using the GUI (Recommended)
The GUI provides a tool to manage schema upgrades safely.
- Log in to the VoIPmonitor web interface.
- Navigate to Tools -> System Status -> Check MySQL Schema.
- The tool will scan your database and list any required changes.
- Check the boxes for all tables that show the message: "missing support for time accuracy in milliseconds".
- Click the Start Upgrade / Run SQL button.
Warning: This process will lock tables as it modifies them and can make the GUI unresponsive until it is complete.
Option 2: Manual Migration (Advanced)
If you do not have GUI access, you can run the `ALTER TABLE` commands manually.
Important:
- Connect to your MySQL/MariaDB server using a command-line client.
- The following commands can take a very long time to execute on large tables.
- You only need to run the `ALTER` command for tables that actually exist in your database.
# Main CDR table ALTER TABLE cdr MODIFY COLUMN calldate DATETIME(3) NOT NULL, MODIFY COLUMN callend DATETIME(3) NOT NULL, MODIFY COLUMN duration DECIMAL(9,3) UNSIGNED DEFAULT NULL, MODIFY COLUMN connect_duration DECIMAL(9,3) UNSIGNED DEFAULT NULL, MODIFY COLUMN progress_time DECIMAL(9,3) UNSIGNED DEFAULT NULL, MODIFY COLUMN first_rtp_time DECIMAL(9,3) UNSIGNED DEFAULT NULL; # CDR extension tables ALTER TABLE cdr_next MODIFY COLUMN calldate DATETIME(3) NOT NULL; ALTER TABLE cdr_proxy MODIFY COLUMN calldate DATETIME(3) NOT NULL; # ... (and so on for all relevant tables)
- (A full list of all `ALTER` commands can be found in the original version of this document if needed.)*
Step 3: Restart Services
After the database migration is complete, you can safely restart the sniffer service.
systemctl restart voipmonitor
You may also need to log out and log back into the GUI to see the changes reflected in the CDR view.
Troubleshooting
Warning Code 1478: ROW_FORMAT=COMPRESSED requires innodb_file_format > Antelope
If you encounter this error while running the `ALTER TABLE` commands on an older MySQL/MariaDB server (e.g., MariaDB 5.5), it means your database is using an outdated file format.
- Solution
- Edit your `my.cnf` file and set the following parameters, then restart the MySQL service. This enables the modern "Barracuda" file format, which is required for page compression and other features.
# /etc/mysql/my.cnf [mysqld] sql_mode=NO_ENGINE_SUBSTITUTION innodb_file_format = barracuda
After restarting MySQL, you should be able to run the `ALTER TABLE` commands successfully.
AI Summary for RAG
Summary: This guide explains how to manage millisecond precision for timestamps in VoIPmonitor. It clarifies that all new installations (since 2023) have this feature enabled by default. For users with older installations, it provides two scenarios for enabling it. Scenario A is for new or empty databases, which only requires setting `time_precision_in_ms=yes` in `voipmonitor.conf`. Scenario B is a more complex guide for migrating existing databases with data, which involves first setting the configuration option and then updating the database schema. The guide presents two methods for the schema migration: using the built-in "Check MySQL Schema" tool in the GUI (recommended) or running a comprehensive list of `ALTER TABLE` commands manually, warning that this can be a very long process. Finally, a troubleshooting section addresses a common MySQL error (`Warning code 1478`) related to `innodb_file_format` on older database versions. Keywords: millisecond, precision, timestamp, calldate, datetime(3), database, schema, migration, alter table, `time_precision_in_ms`, Check MySQL Schema, existing data, new database, `innodb_file_format`, Barracuda, default setting Key Questions:
- Is millisecond precision enabled by default in new installations?
- How do I change timestamp precision from seconds to milliseconds on an old system?
- What does the `time_precision_in_ms` option do?
- How do I update my database schema to support milliseconds?
- My database is full, can I still enable millisecond precision?
- What `ALTER TABLE` commands are needed for millisecond timestamps?
- How to fix "Warning code 1478 InnoDB: ROW_FORMAT=COMPRESSED" during a schema upgrade?