Register

From VoIPmonitor.org


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

Registration Matching (SBC / Proxy Environments)

By default, VoIPmonitor identifies unique registrations primarily by the SIP Call-ID, From and To headers. It does not consider source/destination IP addresses or ports. This works well in simple topologies but causes problems when an SBC or SIP proxy sits in the signaling path.

Common scenario: 

Endpoint ──[Leg 1]──► SBC ──[Leg 2]──► PBX
  (public IP)        (rewrites headers)    (private IP)

The sniffer captures REGISTER packets on both legs. Because the SIP headers (Call-ID, From, To) may be identical or similar on both legs, VoIPmonitor merges them into a single registration entry by default. This results in:

  • Symptom: REGISTER packets visible in Live Sniffer but one leg missing from Active Registers
  • Cause: Registrations from both legs are being matched as one because IP/port differences are ignored

Solution: Enable IP/port-based matching so each leg is tracked independently: 

# /etc/voipmonitor.conf - Distinguish registrations by network path
sip-register-compare-sipcallerip = yes
sip-register-compare-sipcallerport = yes
sip-register-compare-sipcalledip = yes
sip-register-compare-sipcalledport = yes

ℹ️ Note: These options are also useful when the same SIP account registers from multiple devices or locations simultaneously. Without them, only one registration entry appears per account.

All matching parameters:

Parameter Default Description
sip-register-compare-sipcallerip no Consider source IP when matching registrations
sip-register-compare-sipcallerport no Consider source port when matching registrations
sip-register-compare-sipcalledip no Consider destination IP when matching registrations
sip-register-compare-sipcalledport no Consider destination port when matching registrations
sip-register-compare-to_domain yes Consider To header domain when matching
sip-register-state-compare-from_domain no Consider From header domain when matching
sip-register-state-compare-contact_num yes Consider Contact header number when matching
sip-register-state-compare-contact_domain yes Consider Contact header domain when matching
sip-register-state-compare-digest_realm no Consider SIP Authentication Realm when matching

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
Registers visible in Live Sniffer but missing from Active Registers Typically caused by SBC/proxy in the path — enable sip-register-compare-sipcallerip and sip-register-compare-sipcallerport (see Registration Matching above)
Same account shows only one entry despite multiple devices Enable IP/port compare options to track each device independently

💡 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=11239"