Register: Difference between revisions

From VoIPmonitor.org
(Add documentation about sip-register-state-compare-digest_ua for User-Agent change detection, clarify no native alert exists)
(Rewrite: konsolidace a vylepšení struktury)
 
Line 1: Line 1:
{{DISPLAYTITLE:SIP Register Monitoring}}
{{DISPLAYTITLE:SIP Registration Monitoring}}
[[Category:GUI manual]]
[[Category:GUI manual]]
[[Category:Configuration]]


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 <code>sip-register = yes</code> in <code>/etc/voipmonitor.conf</code>.
= SIP Registration Monitoring =


{{Warning|1=SIP registration monitoring is disabled by default. If you see no or incomplete registration data, first verify packets are reaching the sensor with <code>tcpdump</code> or <code>tshark</code>, then check the '''Settings -> Sensors -> # packet drops''' counter. For network traffic verification and Napatech hardware issues, see [[#Troubleshooting:_Missing_Registration_Data|Troubleshooting section below]].}}
The Register section in VoIPmonitor GUI tracks SIP REGISTER transactions across three views: '''Active''' (current registrations), '''Failed''' (unsuccessful attempts), and '''State''' (historical changes). This feature is '''disabled by default'''.


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.
== Quick Start ==


{{Note|1=If you need to record all register packets by the sniffer instance without creating capture rules in the GUI, use <code>sip-register-save-all=yes</code> in <code>/etc/voipmonitor.conf</code>.}}
{| class="wikitable"
|-
! Parameter !! Value !! Description
|-
| <code>sip-register</code> || <code>yes</code> || Enable registration tracking and DB storage
|-
| <code>sip-register-save-all</code> || <code>yes</code> || Save PCAP files for all registrations
|-
| <code>sip-register-state-timeout</code> || <code>600</code> || State snapshot interval (seconds)
|}


[[File:register-recording.png]]
<syntaxhighlight lang="ini">
 
# /etc/voipmonitor.conf - Basic setup
== Active Table ==
sip-register = yes
 
</syntaxhighlight>
The Active table shows currently registered users with these columns:
 
[[File:register-active.png]]
 
* '''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.
 
[[File:register-activesubstate.png]]
 
The picture below shows a detail area with a sub-grid containing related CDR for the user name.
 
[[File:register-activesubcdr.png]]
 
== 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.
 
[[File:register-failed.png]]
 
== 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 <code>sip-register-state-timeout</code> 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).
 
[[File:register-state.png]]


== Configuration in Distributed Architecture ==
{{Note|1=When <code>sip-register=no</code> (default), the Active tab still works using real-time data from the sniffer process. The error "Table 'voipmonitor.register' doesn't exist" is expected in this mode.}}


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


<kroki lang="mermaid">
Configuration depends on your <code>packetbuffer_sender</code> setting:
%%{init: {'flowchart': {'nodeSpacing': 15, 'rankSpacing': 40}}}%%
flowchart TD
    A[Check packetbuffer_sender] --> B{Value?}
    B -->|yes| C[Configure on Central Server]
    B -->|no or unset| D[Configure on Remote Sensor]
    C --> E[Raw packets sent to server]
    D --> F[Local processing on sensor]
</kroki>


{| class="wikitable"
{| class="wikitable"
|-
|-
! Mode !! Configuration Location !! Processing Location
! Mode !! Where to Configure
|-
|-
| '''<code>packetbuffer_sender = yes</code>''' (Packet Mirroring) || Central server || Central server processes raw packets from remote sensors
| <code>packetbuffer_sender = yes</code> || '''Central server''' only
|-
|-
| '''<code>packetbuffer_sender = no</code>''' (Local Processing) || Remote sensor || Each sensor processes packets locally before sending CDRs to central server
| <code>packetbuffer_sender = no</code> || Each '''remote sensor'''
|}
|}


=== Determining Configuration Location ===
== GUI Views ==
 
=== Active Table ===


;1. Check the <code>packetbuffer_sender</code> setting on your remote sensors:
Displays currently registered SIP users:
<syntaxhighlight lang="bash">
grep packetbuffer_sender /etc/voipmonitor.conf
</syntaxhighlight>


;2. If <code>packetbuffer_sender = yes</code>:
* Registration timestamp, username, realm
* Configure <code>sip-register = yes</code> on the '''central server's''' <code>/etc/voipmonitor.conf</code>
* Source/destination IP addresses
* Restart the voipmonitor service on the central server
* SIP headers (From, To, Contact)
* Expiration time and User-Agent
* Sub-grids: state changes, failed attempts, related CDRs
* PCAP download (if enabled)


;3. If <code>packetbuffer_sender = no</code> (or not set):
=== Failed Table ===
* Configure <code>sip-register = yes</code> on the '''remote sensor's''' <code>/etc/voipmonitor.conf</code>
* Restart the voipmonitor service on the remote sensor(s)


For detailed information on distributed architectures, see [[Sniffer_distributed_architecture]].
Shows unsuccessful registration attempts:


== How the Active Tab Retrieves Data ==
* Consecutive failures from the same device increment a counter (no duplicate rows)
* New entry created after >1 hour gap between attempts
* Red flag indicates failure status


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


* '''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 (<code>register</code>, <code>register_state</code>, <code>register_failed</code>) are '''not''' created or used. The Active tab will still function correctly and show live registration data.
Historical registration events (REGISTER, UNREGISTER, EXPIRE):


* '''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.
* Periodic snapshots at <code>sip-register-state-timeout</code> interval (default 600s)
* EXPIRE status: device missed renewal deadline by >5 seconds
* Used for graphing registration trends


== Displaying Multiple Registrations for the Same Account ==
== Advanced Configuration ==


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.
=== Multiple Registration Tracking ===


Add these lines to <code>/etc/voipmonitor.conf</code>:
Display separate entries when the same SIP account registers from different locations:


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# Enable independent display of multiple registrations for the same account
# Show each IP/port combination independently
sip-register-compare-sipcallerip = yes
sip-register-compare-sipcallerip = yes
sip-register-compare-sipcallerport = yes
sip-register-compare-sipcallerport = yes
sip-register-compare-sipcalledip = yes
sip-register-compare-sipcalledip = yes
sip-register-compare-sipcalledport = yes
sip-register-compare-sipcalledport = yes
# Optional: Track registration state changes separately by From domain
sip-register-state-compare-from_domain = yes
sip-register-state-compare-from_domain = yes
</syntaxhighlight>
</syntaxhighlight>


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.
=== User-Agent Change Detection ===


== Detecting User-Agent Changes for Fraud Detection ==
Track when a device's User-Agent changes (potential fraud indicator):
 
To detect when a device's User-Agent (UA) string changes between registrations (which can indicate fraud if credentials are stolen and used with a different softphone or attack tool), enable the following option:


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# Include User-Agent header in registration state comparison
# When enabled, creates a new register_state record when UA changes
# even if other registration details remain the same
sip-register-state-compare-digest_ua = yes
sip-register-state-compare-digest_ua = yes
</syntaxhighlight>
</syntaxhighlight>


{{Note|1=This option adds the SIP <code>User-Agent</code> string to the logic used to identify a device's unique fingerprinting. If the same SIP credentials register with a different UA (e.g., switching from a hardware phone to a softphone, or using a spoofed tool), the system flags this as a difference in registration state and creates a new record in the register state table.}}
{{Warning|1=This setting detects UA changes but does '''NOT''' trigger GUI alerts. For alerting, use '''GUI > Alerts > Anti Fraud''' with "Change REGISTER Country Alert" or custom SQL queries.}}


{{Warning|1=<strong>There is NO built-in alert for User-Agent changes in the GUI.</strong> The <code>sip-register-state-compare-digest_ua</code> option allows the system to <strong>detect</strong> UA changes by creating database records, but it does not trigger native email alerts.}}
== API Access ==


If you need alerting for registration-level fraud detection, use these alternative built-in anti-fraud alerts instead:
Query active registrations programmatically via the Manager API.


* <strong>Change REGISTER Country Alert</strong> - Detects when a device registers from a different country than expected (configured in <strong>GUI → Alerts → Anti Fraud</strong>)
=== Configuration ===
* <strong>Change CDR Country Alert</strong> - Detects IP country changes between calls


{{Tip|1=You can manually query the <code>register_state</code> table to detect User-Agent changes in your database. Look for multiple entries with the same digest credentials but different user_agent values.}}
<syntaxhighlight lang="ini">
# /etc/voipmonitor.conf
manager_ip = 127.0.0.1
manager_port = 5029
# Alternative: Unix socket
# manager_socket = /tmp/vm_manager_socket
</syntaxhighlight>


After modifying the configuration, restart the voipmonitor service:
=== Query Examples ===
 
'''TCP with filter:'''
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
systemctl restart voipmonitor
echo 'listregisters {"zip":"no","limit":30,"states":"OK","filter":{"digestusername":"user"},"sort_field":"calldate","sort_dir":"desc"}' | nc 127.0.0.1 5029
</syntaxhighlight>
</syntaxhighlight>


In distributed architectures, apply these settings to the same location where <code>sip-register = yes</code> is configured.
'''Unix socket:'''
 
== 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 <code>sip-register = yes</code> to <code>/etc/voipmonitor.conf</code> 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:
 
<kroki lang="mermaid">
%%{init: {'flowchart': {'nodeSpacing': 15, 'rankSpacing': 35}}}%%
flowchart TD
    A[Missing Registrations] --> B{tcpdump shows packets?}
    B -->|No| C[Check network mirroring]
    B -->|Yes| D{Packet drops in GUI?}
    D -->|Yes| E[Check sensor resources]
    D -->|No| F{Using Napatech?}
    F -->|Yes| G[Check Napatech config]
    F -->|No| H[Verify sip-register config]
    C --> I[[Sniffer_troubleshooting]]
    E --> I
    G --> J[[Napatech]]
</kroki>
 
=== Step 1: Verify Packets Are Reaching the Sensor ===
 
Run a packet capture directly on the sensor interface:
 
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Check for REGISTER packets
echo 'listregisters' | nc -U /tmp/vm_manager_socket
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
</syntaxhighlight>
</syntaxhighlight>


If no packets appear, the problem is with your network mirroring configuration. See [[Sniffer_troubleshooting]].
'''GUI API (auto-detects connection method):'''
 
=== Step 2: Check for Packet Drops ===
 
Navigate to '''Settings → Sensors''' in the GUI and check the '''# packet drops''' counter:
 
{| class="wikitable"
|-
! Packet Drops !! Meaning !! Action
|-
| 0 || Normal || No drop issues
|-
| Non-zero || Sensor is dropping packets || See [[Sniffer_troubleshooting#Check_Sensor_Statistics_in_GUI|Sensor Statistics]]
|}
 
=== Step 3: Napatech Hardware Issues ===
 
If using Napatech cards, standard capture tools may show no packets if interfaces are in DOWN state.
 
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Check interface status
php /var/www/html/php/run.php send_manager_cmd -s NULL -c 'listregisters'
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
</syntaxhighlight>
</syntaxhighlight>


See [[Napatech#Troubleshooting]] for detailed steps.
'''Key parameters:''' <code>filter</code> (digestusername, sipcallerip), <code>limit</code>, <code>sort_field</code>, <code>sort_dir</code>
 
== Slow Queries on register_state Table ==


If queries on the <code>register_state</code> table are slow when filtering by Username, Domain, or Number, this indicates missing indexes.
== Database Optimization ==


=== Symptoms ===
=== Create Indexes ===


* Queries with filters on Username, Domain, or Number time out
For slow queries on large datasets:
* 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:
 
<syntaxhighlight lang="sql">
SHOW INDEX FROM register_state;
</syntaxhighlight>
 
Create indexes on frequently queried columns:


<syntaxhighlight lang="sql">
<syntaxhighlight lang="sql">
Line 244: Line 141:
</syntaxhighlight>
</syntaxhighlight>


{{Warning|1=<code>CREATE INDEX</code> on large tables can be slow and may block writes. Schedule during maintenance windows.}}
=== Data Retention ===


=== Additional Optimization ===
Control storage with <code>cleandatabaseregister</code> parameter:


* Increase <code>innodb_buffer_pool_size</code> in MySQL configuration (see [[Scaling]])
<syntaxhighlight lang="ini">
* Configure <code>cleandatabaseregister = 7</code> in <code>/etc/voipmonitor.conf</code> to limit data retention (see [[Data_Cleaning]])
# /etc/voipmonitor.conf
cleandatabaseregister = 7  # Days to retain
</syntaxhighlight>


{{Note|1=For MySQL 5.6+ or MariaDB 10.1+, use online index creation: <code>CREATE INDEX digestusername ON register_state (digestusername) ALGORITHM=INPLACE, LOCK=NONE;</code>}}
=== Buffer Pool Sizing ===


=== Calculating innodb_buffer_pool_size for High-Volume Data ===
For high-volume environments (30M+ records/day):


For systems with high REGISTER volume (e.g., 30 million records per day):
<code>innodb_buffer_pool_size</code> = daily partition size x retention days


1. '''Calculate daily partition size:'''
''Example: 15GB daily x 7 days = 105GB minimum''
<syntaxhighlight lang="bash">
ls -lat /var/lib/mysql/voipmonitor | grep pYYMMDD | cut -d' ' -f 7 | paste -s -d+ - | bc
</syntaxhighlight>


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


3. '''Configure MySQL:'''
{| class="wikitable"
<syntaxhighlight lang="ini">
|-
[mysqld]
! Symptom !! Solution
innodb_buffer_pool_size = 128G
|-
</syntaxhighlight>
| No registrations appear || Verify packets: <code>tcpdump -i eth0 port 5060</code>
|-
| "Table doesn't exist" error || Normal when <code>sip-register=no</code>; Active tab still works
|-
| Missing data with Napatech || Check <code>ip link show napa0</code> and libpcap path
|-
| Packet drops || Check '''Settings > Sensors''' for drop counters
|}


4. '''Ensure sufficient RAM''' to accommodate the buffer pool plus OS and application overhead
{{Tip|Avoid large historical queries during peak traffic hours and partition maintenance windows (1:00-5:00 AM).}}


==== Query Timing Warnings ====
== See Also ==


* Avoid large range reports during peak traffic hours
* [[Anti-fraud]] - Registration country change alerts
* Avoid reports during the partition maintenance window (1:00 AM - 5:00 AM)
* [[Capture_rules]] - Per-registration PCAP rules
* Schedule large historical queries during off-peak hours
* [[Data_Cleaning]] - Database retention settings
* [[Sniffer_distributed_architecture]] - Central vs. distributed processing


== AI Summary for RAG ==
== AI Summary for RAG ==


'''Summary:''' The SIP Register section displays Active, Failed, and State tables for monitoring SIP registrations. Enable with <code>sip-register = yes</code> 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 <code>sip-register</code> on the central server if <code>packetbuffer_sender=yes</code>, or on remote sensors if <code>packetbuffer_sender=no</code>. By default, PCAP files are not saved for REGISTER messages; enable via capture rules or <code>sip-register-save-all=yes</code>. To display multiple registrations for the same account independently, enable comparison options: <code>sip-register-compare-sipcallerip</code>, <code>sip-register-compare-sipcallerport</code>, <code>sip-register-compare-sipcalledip</code>, <code>sip-register-compare-sipcalledport</code>, and <code>sip-register-state-compare-from_domain</code>. To detect User-Agent changes for fraud detection, enable <code>sip-register-state-compare-digest_ua = yes</code> - this creates new register_state records when UA changes but does NOT trigger native GUI alerts (no built-in alert for UA changes exists). Alternative fraud alerts for registration-level detection: Change REGISTER Country Alert and Change CDR Country Alert (configured in GUI → Alerts → Anti Fraud). 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 <code>innodb_buffer_pool_size</code> based on daily partition size × retention days.
'''Summary:''' VoIPmonitor SIP Register monitoring tracks registration events in three GUI tables: Active (current registrations with real-time data even when DB storage disabled), Failed (unsuccessful attempts with counter deduplication), and State (historical REGISTER/UNREGISTER/EXPIRE events). Enable with <code>sip-register=yes</code> in voipmonitor.conf. In distributed architecture, configure on central server if <code>packetbuffer_sender=yes</code>, otherwise on each remote sensor. PCAP files require <code>sip-register-save-all=yes</code>. Advanced options include multi-registration tracking (<code>sip-register-compare-*</code> parameters) and User-Agent change detection (<code>sip-register-state-compare-digest_ua=yes</code>) for fraud detection. API access via Manager port 5029 with <code>listregisters</code> command. Database optimization requires indexes on register_state table and proper <code>innodb_buffer_pool_size</code> sizing.


'''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, User-Agent, UA, sip-register-state-compare-digest_ua, fraud detection, Change REGISTER Country Alert, Change CDR Country Alert
'''Keywords:''' SIP register, registration monitoring, Active table, Failed table, State table, sip-register, sip-register-save-all, sip-register-state-timeout, sip-register-compare-sipcallerip, sip-register-compare-sipcallerport, sip-register-state-compare-digest_ua, User-Agent change, fraud detection, listregisters, Manager API, port 5029, cleandatabaseregister, register_state, distributed architecture, packetbuffer_sender


'''Key Questions:'''
'''Key Questions:'''
* How do I enable SIP registration monitoring in VoIPmonitor?
* How do I enable SIP registration monitoring in VoIPmonitor?
* Where do I configure sip-register in distributed architecture?
* Where should I configure sip-register in a distributed architecture?
* Why does the Active tab show "Table 'voipmonitor.register' doesn't exist"?
* How do I track the same SIP account registering from multiple locations?
* How to display multiple registrations for the same account separately?
* How do I detect User-Agent changes for fraud detection?
* Why are queries on register_state table so slow?
* How do I query active registrations via API?
* How to create indexes on register_state columns?
* What indexes should I create for register_state performance?
* How to calculate innodb_buffer_pool_size for high-volume REGISTER data?
* Why do I see "Table doesn't exist" error for register table?
* How to verify packets are reaching the sensor interface?
* How do I configure data retention for registration data?
* How to troubleshoot Napatech interfaces in DOWN state?
* How to detect User-Agent changes in SIP registrations?
* Does sip-register-state-compare-digest_ua trigger alerts?
* Is there a built-in alert for User-Agent changes?
* How do I detect fraud based on User-Agent changes?

Latest revision as of 16:48, 8 January 2026


SIP Registration Monitoring

The Register section in VoIPmonitor GUI tracks SIP REGISTER transactions across three views: Active (current registrations), Failed (unsuccessful attempts), and State (historical changes). This feature is disabled by default.

Quick Start

Parameter Value Description
sip-register yes Enable registration tracking and DB storage
sip-register-save-all yes Save PCAP files for all registrations
sip-register-state-timeout 600 State snapshot interval (seconds) 
# /etc/voipmonitor.conf - Basic setup
sip-register = yes

ℹ️ Note: When sip-register=no (default), the Active tab still works using real-time data from the sniffer process. The error "Table 'voipmonitor.register' doesn't exist" is expected in this mode.

Distributed Architecture

Configuration depends on your packetbuffer_sender setting:

Mode Where to Configure
packetbuffer_sender = yes Central server only
packetbuffer_sender = no Each remote sensor

GUI Views

Active Table

Displays currently registered SIP users:

  • Registration timestamp, username, realm
  • Source/destination IP addresses
  • SIP headers (From, To, Contact)
  • Expiration time and User-Agent
  • Sub-grids: state changes, failed attempts, related CDRs
  • PCAP download (if enabled)

Failed Table

Shows unsuccessful registration attempts:

  • Consecutive failures from the same device increment a counter (no duplicate rows)
  • New entry created after >1 hour gap between attempts
  • Red flag indicates failure status

State Table

Historical registration events (REGISTER, UNREGISTER, EXPIRE):

  • Periodic snapshots at sip-register-state-timeout interval (default 600s)
  • EXPIRE status: device missed renewal deadline by >5 seconds
  • Used for graphing registration trends

Advanced Configuration

Multiple Registration Tracking

Display separate entries when the same SIP account registers from different locations: 

# Show each IP/port combination independently
sip-register-compare-sipcallerip = yes
sip-register-compare-sipcallerport = yes
sip-register-compare-sipcalledip = yes
sip-register-compare-sipcalledport = yes
sip-register-state-compare-from_domain = yes

User-Agent Change Detection

Track when a device's User-Agent changes (potential fraud indicator): 

sip-register-state-compare-digest_ua = yes

⚠️ Warning: This setting detects UA changes but does NOT trigger GUI alerts. For alerting, use GUI > Alerts > Anti Fraud with "Change REGISTER Country Alert" or custom SQL queries.

API Access

Query active registrations programmatically via the Manager API.

Configuration

# /etc/voipmonitor.conf
manager_ip = 127.0.0.1
manager_port = 5029
# Alternative: Unix socket
# manager_socket = /tmp/vm_manager_socket

Query Examples

TCP with filter: 

echo 'listregisters {"zip":"no","limit":30,"states":"OK","filter":{"digestusername":"user"},"sort_field":"calldate","sort_dir":"desc"}' | nc 127.0.0.1 5029

Unix socket: 

echo 'listregisters' | nc -U /tmp/vm_manager_socket

GUI API (auto-detects connection method): 

php /var/www/html/php/run.php send_manager_cmd -s NULL -c 'listregisters'

Key parameters: filter (digestusername, sipcallerip), limit, sort_field, sort_dir

Database Optimization

Create Indexes

For slow queries on large datasets: 

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);

Data Retention

Control storage with cleandatabaseregister parameter: 

# /etc/voipmonitor.conf
cleandatabaseregister = 7  # Days to retain

Buffer Pool Sizing

For high-volume environments (30M+ records/day):

innodb_buffer_pool_size = daily partition size x retention days

Example: 15GB daily x 7 days = 105GB minimum

Troubleshooting

Symptom Solution
No registrations appear Verify packets: tcpdump -i eth0 port 5060
"Table doesn't exist" error Normal when sip-register=no; Active tab still works
Missing data with Napatech Check ip link show napa0 and libpcap path
Packet drops Check Settings > Sensors for drop counters

💡 Tip: Avoid large historical queries during peak traffic hours and partition maintenance windows (1:00-5:00 AM).

See Also

AI Summary for RAG

Summary: VoIPmonitor SIP Register monitoring tracks registration events in three GUI tables: Active (current registrations with real-time data even when DB storage disabled), Failed (unsuccessful attempts with counter deduplication), and State (historical REGISTER/UNREGISTER/EXPIRE events). Enable with sip-register=yes in voipmonitor.conf. In distributed architecture, configure on central server if packetbuffer_sender=yes, otherwise on each remote sensor. PCAP files require sip-register-save-all=yes. Advanced options include multi-registration tracking (sip-register-compare-* parameters) and User-Agent change detection (sip-register-state-compare-digest_ua=yes) for fraud detection. API access via Manager port 5029 with listregisters command. Database optimization requires indexes on register_state table and proper innodb_buffer_pool_size sizing.

Keywords: SIP register, registration monitoring, Active table, Failed table, State table, sip-register, sip-register-save-all, sip-register-state-timeout, sip-register-compare-sipcallerip, sip-register-compare-sipcallerport, sip-register-state-compare-digest_ua, User-Agent change, fraud detection, listregisters, Manager API, port 5029, cleandatabaseregister, register_state, distributed architecture, packetbuffer_sender

Key Questions:

  • How do I enable SIP registration monitoring in VoIPmonitor?
  • Where should I configure sip-register in a distributed architecture?
  • How do I track the same SIP account registering from multiple locations?
  • How do I detect User-Agent changes for fraud detection?
  • How do I query active registrations via API?
  • What indexes should I create for register_state performance?
  • Why do I see "Table doesn't exist" error for register table?
  • How do I configure data retention for registration data?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Register&oldid=10126"