Register

The SIP Register section shows three tables - Active registered SIP users, Failed registrations, and State changes in SIP registrations. These tables are populated once you enable sip-register = yes in /etc/voipmonitor.conf.

❗ Important: SIP registration monitoring is disabled by default. If you see no or incomplete registration data, first verify packets are reaching the sensor with tcpdump or tshark, then check the Settings -> Sensors -> # packet drops counter. For network traffic verification and Napatech hardware issues, see Troubleshooting section below.

By default, PCAP files are not saved for SIP register messages (it can easily overload the file system). If you need to record SIP messages, you can control this in capture rules main section. In all three sections, there are gray/red small circles which indicate if SIP messages are being recorded to PCAP file so it can be retrieved by clicking on the PCAP link. Clicking on the circle enables/disables recording. In the dialog window you can adjust values and set auto remove for the rule at a specific date.

ℹ️ Note: If you need to record all register packets by the sniffer instance without creating capture rules in the GUI, use sip-register-save-all=yes in /etc/voipmonitor.conf.

Active Table

The Active table shows currently registered users with these columns:

• ID/sensor id - Internal unique ID and sensor id (if enabled)
• datetime - Registration creation time
• User name / realm - Username and realm from REGISTER message
• Source IP / Destination IP
• From / To / Contact - Values from SIP headers
• Expires at - Date when the registration expires
• User agent
• Commands - Download PCAP

The picture below shows a detail area with a sub-grid containing state changes and failed registrations for the user name. This provides quick filters for a particular active user where you can quickly see their history. Once the SIP registration expires, the history is no longer in the Active table. Each expired registration is stored in the State table.

The picture below shows a detail area with a sub-grid containing related CDR for the user name.

Failed Table

The Failed table shows failed SIP registrations. If a device fails to register continuously, the counter column increases instead of creating a new row. If there is a one-hour gap between two failed registrations from the same user, a new row will be created.

State Table

The State table retains registration history where REGISTER, UNREGISTER and EXPIRE events are saved. In each state row, you can click on detail [+] to show all related SIP register messages for the selected user.

The same state is periodically saved for graphing purposes. The default interval is 600 seconds. It can be changed with the sip-register-state-timeout option in the sensor config.

If the device does not resend registration in time (register expires + 5 seconds), the last state will be EXPIRE (with red flag).

Configuration in Distributed Architecture

In distributed/client-server deployments, the location where you must enable sip-register = yes depends on your packetbuffer_sender configuration:

Mode	Configuration Location	Processing Location
packetbuffer_sender = yes (Packet Mirroring)	Central server	Central server processes raw packets from remote sensors
packetbuffer_sender = no (Local Processing)	Remote sensor	Each sensor processes packets locally before sending CDRs to central server

Determining Configuration Location

1. Check the packetbuffer_sender setting on your remote sensors

grep packetbuffer_sender /etc/voipmonitor.conf

2. If packetbuffer_sender = yes

• Configure sip-register = yes on the central server's /etc/voipmonitor.conf
• Restart the voipmonitor service on the central server

3. If packetbuffer_sender = no (or not set)

• Configure sip-register = yes on the remote sensor's /etc/voipmonitor.conf
• Restart the voipmonitor service on the remote sensor(s)

For detailed information on distributed architectures, see Sniffer_distributed_architecture.

How the Active Tab Retrieves Data

The Active table in the GUI displays registration data in two different ways, depending on whether the sip-register feature is enabled:

• When sip-register is disabled (default): The GUI retrieves active registration data directly from the running sniffer processes in real-time. The sniffer maintains an in-memory list of currently registered SIP devices. In this configuration, the database tables (register, register_state, register_failed) are not created or used. The Active tab will still function correctly and show live registration data.

• When sip-register = yes: Registration data is stored in database tables for persistent storage and historical reporting. The GUI can then query these tables to display both current and historical registration information.

Displaying Multiple Registrations for the Same Account

By default, multiple registrations for the same SIP account from different IP addresses or ports may be displayed as a single aggregated record. To view all registrations separately, enable comparison options in the sniffer configuration.

Add these lines to /etc/voipmonitor.conf:

# Enable independent display of multiple registrations for the same account
sip-register-compare-sipcallerip = yes
sip-register-compare-sipcallerport = yes
sip-register-compare-sipcalledip = yes
sip-register-compare-sipcalledport = yes

# Optional: Track registration state changes separately by From domain
sip-register-state-compare-from_domain = yes

These settings create separate registration entries when the source IP, source port, destination IP, destination port, or From domain differ. This allows you to see each registration instance independently rather than merged into a single record.

After modifying the configuration, restart the voipmonitor service:

systemctl restart voipmonitor

In distributed architectures, apply these settings to the same location where sip-register = yes is configured.

Error: Table 'voipmonitor.register' doesn't exist

If you see the error message "Table 'voipmonitor.register' doesn't exist" when viewing the Active tab, this is expected behavior when the sip-register feature is disabled.

The error appears if the GUI attempts to query the database table for historical information while the feature is disabled. However, the Active tab will still display live registration data retrieved directly from the sniffer processes.

No action is required. If you want to enable persistent storage of registration history, add sip-register = yes to /etc/voipmonitor.conf and restart the sniffer.

Troubleshooting: Missing Registration Data

If SIP registration information is missing from the GUI even though traffic is present on your network, follow these troubleshooting steps:

Step 1: Verify Packets Are Reaching the Sensor

Run a packet capture directly on the sensor interface:

# Check for REGISTER packets
tcpdump -i eth0 -s 0 -c 10 "port 5060 and udp"

# Or use tshark for more detailed analysis
tshark -i eth0 -Y "sip.Method == REGISTER" -c 10

If no packets appear, the problem is with your network mirroring configuration. See Sniffer_troubleshooting.

Step 2: Check for Packet Drops

Navigate to Settings → Sensors in the GUI and check the # packet drops counter:

Packet Drops	Meaning	Action
0	Normal	No drop issues
Non-zero	Sensor is dropping packets	See Sensor Statistics

Step 3: Napatech Hardware Issues

If using Napatech cards, standard capture tools may show no packets if interfaces are in DOWN state.

# Check interface status
ip link show napa0

# Verify voipmonitor is using Napatech libpcap
ldd /usr/local/sbin/voipmonitor | grep pcap
# Should show: /opt/napatech3/lib/libpcap.so.1

See Napatech#Troubleshooting for detailed steps.

Slow Queries on register_state Table

If queries on the register_state table are slow when filtering by Username, Domain, or Number, this indicates missing indexes.

Symptoms

• Queries with filters on Username, Domain, or Number time out
• GUI Register State tab is unresponsive when applying filters
• MySQL shows high CPU usage from register_state queries

Solution: Create Missing Indexes

First, verify which indexes exist:

SHOW INDEX FROM register_state;

Create indexes on frequently queried columns:

CREATE INDEX digestusername ON register_state (digestusername);
CREATE INDEX digest_from_number ON register_state (digest_from_number);
CREATE INDEX digest_to_number ON register_state (digest_to_number);
CREATE INDEX digest_to_domain ON register_state (digest_to_domain);
CREATE INDEX digest_realm ON register_state (digest_realm);

⚠️ Warning: CREATE INDEX on large tables can be slow and may block writes. Schedule during maintenance windows.

Additional Optimization

• Increase innodb_buffer_pool_size in MySQL configuration (see Scaling)
• Configure cleandatabaseregister = 7 in /etc/voipmonitor.conf to limit data retention (see Data_Cleaning)

ℹ️ Note: For MySQL 5.6+ or MariaDB 10.1+, use online index creation: CREATE INDEX digestusername ON register_state (digestusername) ALGORITHM=INPLACE, LOCK=NONE;

Calculating innodb_buffer_pool_size for High-Volume Data

For systems with high REGISTER volume (e.g., 30 million records per day):

1. Calculate daily partition size:

ls -lat /var/lib/mysql/voipmonitor | grep pYYMMDD | cut -d' ' -f 7 | paste -s -d+ - | bc

2. Multiply by days needed: If each day is 15GB and you need 7 days: 15GB × 7 = 105GB minimum buffer pool

3. Configure MySQL:

[mysqld]
innodb_buffer_pool_size = 128G

4. Ensure sufficient RAM to accommodate the buffer pool plus OS and application overhead

Query Timing Warnings

• Avoid large range reports during peak traffic hours
• Avoid reports during the partition maintenance window (1:00 AM - 5:00 AM)
• Schedule large historical queries during off-peak hours

AI Summary for RAG

Summary: The SIP Register section displays Active, Failed, and State tables for monitoring SIP registrations. Enable with sip-register = yes in voipmonitor.conf for persistent database storage; the Active tab works in real-time even when disabled (data retrieved directly from sniffer process). In distributed architectures, configure sip-register on the central server if packetbuffer_sender=yes, or on remote sensors if packetbuffer_sender=no. By default, PCAP files are not saved for REGISTER messages; enable via capture rules or sip-register-save-all=yes. To display multiple registrations for the same account independently, enable comparison options: sip-register-compare-sipcallerip, sip-register-compare-sipcallerport, sip-register-compare-sipcalledip, sip-register-compare-sipcalledport, and sip-register-state-compare-from_domain. For slow queries on register_state table, create indexes on digestusername, digest_from_number, digest_to_number, digest_to_domain, digest_realm. For high-volume environments, calculate required innodb_buffer_pool_size based on daily partition size × retention days.

Keywords: SIP Register, Active, Failed, State, sip-register, packetbuffer_sender, distributed architecture, multiple registrations, sip-register-compare-sipcallerip, register_state, slow query, index, digestusername, innodb_buffer_pool_size, cleandatabaseregister, PCAP recording, sip-register-save-all, Napatech, packet drops

Key Questions:

• How do I enable SIP registration monitoring in VoIPmonitor?
• Where do I configure sip-register in distributed architecture?
• Why does the Active tab show "Table 'voipmonitor.register' doesn't exist"?
• How to display multiple registrations for the same account separately?
• Why are queries on register_state table so slow?
• How to create indexes on register_state columns?
• How to calculate innodb_buffer_pool_size for high-volume REGISTER data?
• How to verify packets are reaching the sensor interface?
• How to troubleshoot Napatech interfaces in DOWN state?