Sniffer distributed architecture: Difference between revisions

From VoIPmonitor.org
(Fix mismatched heading level)
(Consolidate page: remove duplicate diagrams, simplify structure, merge SIP probe section into Packet Mirroring)
Line 1: Line 1:
{{DISPLAYTITLE:Distributed Architecture: Client-Server and Mirroring Modes}}
{{DISPLAYTITLE:Distributed Architecture: Client-Server and Mirroring}}


This guide explains how to deploy multiple VoIPmonitor sensors in a distributed architecture.


=Distributed Architecture: Client-Server and Mirroring Modes=
== Overview ==


This guide explains how to deploy VoIPmonitor in distributed architectures using client-server mode, packet mirroring, and hybrid configurations.
VoIPmonitor supports three distributed deployment modes:


==Overview==
{| class="wikitable"
|-
! Mode !! What is sent !! Use case
|-
| '''Client-Server''' || CDRs (call records) || Multiple sites → central database
|-
| '''Packet Mirroring''' || Raw packets || Central analysis, SIP+RTP merging
|-
| '''Hybrid Chain''' || CDRs or packets || Multi-tier (workaround, not recommended)
|}


VoIPmonitor sniffers can be deployed in multiple architectural patterns:
== Client-Server Mode (Recommended) ==


* '''Standalone mode''': Single instance capturing and analyzing traffic
Multiple sensors send CDRs to a central server. This is the standard architecture for multi-site deployments.
* '''Client-Server mode''': Multiple clients sending CDRs to central server
* '''Mirroring mode''': Forwarding raw packets to another instance
* '''Hybrid mode''': Combining mirroring with client-server (workaround)


==== Architecture Diagrams (PlantUML) ====
<kroki lang="plantuml">
@startuml
skinparam shadowing false
skinparam defaultFontName Arial
skinparam rectangle {
  BorderColor #4A90E2
  BackgroundColor #FFFFFF
}


<kroki lang="plantuml">
rectangle "Sensor A" as A
  @startuml
rectangle "Sensor B" as B
  skinparam shadowing false
rectangle "Central Server" as S
  skinparam defaultFontName Arial
database "MySQL" as DB
  skinparam rectangle {
    BorderColor #4A90E2
    BackgroundColor #FFFFFF
    stereotypeFontColor #333333
  }


  title Multiple Clients → Single Server (Client-Server Mode)
A -down-> S : CDRs
B -down-> S : CDRs
S -right-> DB


  rectangle "Sensor A\n(client)" as A
note bottom of A : PCAPs stored locally
  rectangle "Sensor B\n(client)" as B
note bottom of B : PCAPs stored locally
  rectangle "Sensor C\n(client)" as C
@enduml
  rectangle "Central Server\n(server_bind)" as S
</kroki>


  A --> S : CDRs
=== Configuration ===
  B --> S : CDRs
  C --> S : CDRs


  note right of S
'''On each sensor (client):'''
    Stores all CDRs to MySQL
<syntaxhighlight lang="ini">
    PCAPs remain on sensors by default
  end note
 
  @enduml
</kroki>
 
<kroki lang="plantuml">
  @startuml
  skinparam shadowing false
  skinparam defaultFontName Arial
 
  title Packet Mirroring (Sensor A → Sensor B)
 
  rectangle "Sensor A\n(source capture)" as A
  rectangle "Sensor B\n(receiver / analysis)" as B
 
  A -[#black]-> B : mirrored packets\n(SIP, RTP, TCP, TLS)
 
  note right of B
    Analyzes mirrored traffic
    Can store CDRs and PCAPs
  end note
 
  @enduml
</kroki>
 
<kroki lang="plantuml">
  @startuml
  skinparam shadowing false
  skinparam defaultFontName Arial
 
  title Hybrid Chain (Mirror + Client)
 
  rectangle "Sensor A\nmirror_destination" as A
  rectangle "Sensor B\nmirror_bind +\nserver_destination" as B
  rectangle "Central Server C\nserver_bind" as C
 
  A -[#black]-> B : mirrored packets
  B -[#black]-> C : CDRs and/or packets
 
  note right of B
    Workaround only
    Not officially supported
  end note
 
  @enduml
</kroki>
 
==Standard Architectures==
 
===Multiple Clients to Single Server (Recommended)===
 
This is the standard and fully supported architecture for distributed deployments.
 
<kroki lang="plantuml">
  @startuml
  title Multiple Clients → Single Server
  rectangle "Sensor A\n(client)" as A
  rectangle "Sensor B\n(client)" as B
  rectangle "Sensor C\n(client)" as C
  rectangle "Central Server\n(server_bind)" as S
 
  A --> S : CDRs
  B --> S : CDRs
  C --> S : CDRs
  @enduml
</kroki>
 
'''Configuration:'''
 
On each client (A, B, C):
<syntaxhighlight lang="bash">
server_destination = central.server.ip
server_destination = central.server.ip
server_destination_port = 60024
server_destination_port = 60024
Line 117: Line 54:
</syntaxhighlight>
</syntaxhighlight>


On central server:
'''On central server:'''
<syntaxhighlight lang="bash">
<syntaxhighlight lang="ini">
server_bind = 0.0.0.0
server_bind = 0.0.0.0
server_bind_port = 60024
server_bind_port = 60024
Line 124: Line 61:
</syntaxhighlight>
</syntaxhighlight>


'''Important notes:'''
=== Data Storage ===
* All clients and the server must use the same <code>server_password</code>
 
* Clients do not store CDRs to MySQL (they only send to server)
* '''CDRs''': Stored in MySQL on central server only
* Server stores all CDRs to MySQL database
* '''PCAPs''': Stored on each sensor locally (GUI retrieves them via network)
* PCAP files are stored on clients by default
 
{{Note|All instances must use the same <code>server_password</code>.}}
 
== Packet Mirroring Mode ==


===Packet Mirroring===
One sensor forwards raw packets to another for analysis. Useful when you need central packet processing or when SIP and RTP are captured at different locations.


Mirror mode forwards raw network packets from one sniffer to another.
<kroki lang="plantuml">
@startuml
skinparam shadowing false
skinparam defaultFontName Arial
skinparam rectangle {
  BorderColor #4A90E2
  BackgroundColor #FFFFFF
}


<syntaxhighlight>
rectangle "Sensor A\n(source)" as A
Sensor A ──(packets)──→ Sensor B
rectangle "Sensor B\n(receiver)" as B
</syntaxhighlight>
database "MySQL" as DB


<kroki lang="plantuml">
A -right-> B : raw packets
  @startuml
B -down-> DB : CDRs
  title Packet Mirroring (A → B)
  rectangle "Sensor A\n(source)" as A
  rectangle "Sensor B\n(receiver)" as B


  A --> B : mirrored packets
note bottom of B : Analyzes packets\nStores PCAPs & CDRs
  @enduml
@enduml
</kroki>
</kroki>


'''Configuration:'''
=== Configuration ===


On source sensor A:
'''On source (Sensor A):'''
<syntaxhighlight lang="bash">
<syntaxhighlight lang="ini">
mirror_destination = sensor.b.ip
mirror_destination = sensor.b.ip
mirror_destination_port = 5090
mirror_destination_port = 5090
</syntaxhighlight>
</syntaxhighlight>


On receiving sensor B:
'''On receiver (Sensor B):'''
<syntaxhighlight lang="bash">
<syntaxhighlight lang="ini">
mirror_bind = 0.0.0.0
mirror_bind = 0.0.0.0
mirror_bind_port = 5090
mirror_bind_port = 5090
</syntaxhighlight>
</syntaxhighlight>


'''Use cases:'''
=== Use Case: SIP + RTP Merging ===
* Forwarding packets from appliances without VoIPmonitor
* Port mirroring / SPAN to VoIPmonitor instance
* Distributed packet capture with central analysis
 
===Forwarding from SIP Probe to Central Server===
 
This pattern is used when SIP signaling and RTP media are captured on separate machines. A SIP-only probe captures SIP packets and forwards them to a central server where RTP packets are also captured, allowing complete CDR generation.


<syntaxhighlight>
When SIP signaling and RTP media are captured on separate machines, a SIP probe can forward packets to a central server that captures RTP locally:
SIP Probe (only SIP) ──(SIP packets)──→ Central Server (SIP + RTP)
</syntaxhighlight>


<kroki lang="plantuml">
<kroki lang="plantuml">
  @startuml
@startuml
  title SIP Probe → Central Server
skinparam shadowing false
skinparam defaultFontName Arial


  rectangle "SIP Only Probe\n(packetbuffer_sender=yes)" as PROBE
rectangle "SIP Probe" as PROBE
  rectangle "Central Server\n(server_bind=yes)" as SERVER
rectangle "Central Server" as SERVER
cloud "RTP Traffic" as RTP


  PROBE --> SERVER : SIP packets
PROBE -right-> SERVER : SIP packets
RTP -down-> SERVER : RTP packets


  note right of PROBE
note bottom of SERVER : Merges SIP + RTP\ninto complete CDRs
    Captures SIP signaling only
@enduml
    Forwards packets via server_destination
</kroki>
  end note


  note right of SERVER
'''SIP Probe config:'''
    Receives SIP packets
<syntaxhighlight lang="ini">
    Captures RTP packets locally
    Merges SIP + RTP → Complete CDR
  end note
  @enduml
</kroki>
 
'''Use case:'''
* Environment where SIP servers and RTP engines are deployed on separate machines
* Need to merge SIP signaling from one location with RTP media from another
 
'''Configuration on SIP Probe (sending SIP packets):'''
 
Edit <code>/etc/voipmonitor.conf</code>:
<syntaxhighlight lang="bash">
# Enable packet forwarding mode
packetbuffer_sender = yes
packetbuffer_sender = yes
# Send to central server that will merge SIP with RTP
server_destination = central.server.ip
server_destination = central.server.ip
server_destination_port = 60024
server_destination_port = 60024
server_password = shared_secret
# Do NOT set server_bind, mysqlhost, or other server options
</syntaxhighlight>
</syntaxhighlight>


'''Configuration on Central Server (receiving SIP, capturing RTP):'''
'''Central Server config:'''
 
<syntaxhighlight lang="ini">
Edit <code>/etc/voipmonitor.conf</code>:
<syntaxhighlight lang="bash">
# Accept incoming packets from probes
server_bind = 0.0.0.0
server_bind = 0.0.0.0
server_bind_port = 60024
server_bind_port = 60024
server_password = shared_secret
# This server should also be capturing RTP locally
# Configure interface/port as usual
interface = eth0
interface = eth0
# ... other standard configuration
</syntaxhighlight>
</syntaxhighlight>


'''How it works:'''
The <code>packetbuffer_sender = yes</code> option sends raw packets instead of CDRs.
# SIP probe captures SIP signaling packets only
# SIP probe forwards raw packets to central server via <code>server_destination</code>
# <code>packetbuffer_sender = yes</code> enables packet forwarding (instead of analyzing locally and sending CDRs)
# Central server receives SIP packets and merges them with locally captured RTP packets
# Central server generates complete CDRs with both signaling and media information
 
'''Restart services:'''
<syntaxhighlight lang="bash">
# On SIP probe
systemctl restart voipmonitor


# On central server
== Hybrid Chain (Workaround) ==
systemctl restart voipmonitor
</syntaxhighlight>
 
{{Note|This pattern uses <code>packetbuffer_sender</code> with <code>server_destination</code>/</code>server_bind</code> (client-server mode), which is different from <code>packetbuffer_sender</code> with </code>mirror_destination</code>/</code>mirror_bind</code> (mirror mode).}}
 
==Hybrid Chain Configuration (Workaround)==
 
{{Warning|A single sniffer instance '''cannot''' operate in both client and server modes simultaneously using <code>server_bind</code> + <code>server_destination</code>. These options are mutually exclusive.}}
 
However, a '''workaround exists''' using mirroring combined with client mode:
 
<syntaxhighlight>
A (mirror) ──(packets)──→ B (mirror_bind + server_destination) ──(CDRs/packets)──→ C (server)
</syntaxhighlight>


<kroki lang="plantuml">
{{Warning|This configuration is '''not officially supported''' and may break in future releases. Use standard client-server mode when possible.}}
  @startuml
  title Hybrid Chain A → B → C
  rectangle "Sensor A\n(mirror_destination)" as A
  rectangle "Sensor B\n(mirror_bind +\nserver_destination)" as B
  rectangle "Server C\n(server_bind)" as C


  A --> B : packets
A single sniffer '''cannot''' use both <code>server_bind</code> and <code>server_destination</code> simultaneously. However, you can combine mirroring with client-server mode as a workaround:
  B --> C : CDRs / packets
  @enduml
</kroki>


===Scenario 1: CDR Forwarding===
<kroki lang="plantuml">
@startuml
skinparam shadowing false
skinparam defaultFontName Arial


In this configuration, the intermediate sniffer (B) analyzes packets and forwards only CDRs to the central server.
rectangle "Sensor A" as A
rectangle "Sensor B" as B
rectangle "Central Server C" as C


'''Sensor A (source):'''
A -right-> B : packets\n(mirror)
<syntaxhighlight lang="bash">
B -right-> C : CDRs or packets\n(client-server)
mirror_destination = sensor.b.ip
@enduml
mirror_destination_port = 5090
</kroki>
</syntaxhighlight>


'''Sensor B (intermediate):'''
'''Sensor A''' uses <code>mirror_destination</code> → '''Sensor B'''
<syntaxhighlight lang="bash">
mirror_bind = 0.0.0.0
mirror_bind_port = 5090
server_destination = central.server.ip
server_destination_port = 60024
packetbuffer_sender = no
</syntaxhighlight>


'''Central Server C:'''
'''Sensor B''' uses <code>mirror_bind</code> + <code>server_destination</code> → '''Server C'''
<syntaxhighlight lang="bash">
server_bind = 0.0.0.0
server_bind_port = 60024
</syntaxhighlight>


'''Result:'''
{| class="wikitable"
* B analyzes packets from A
|-
* B stores PCAP files locally
! Sensor B setting !! Result
* B sends only CDRs to C
|-
* C stores CDRs in MySQL and knows PCAPs are on B
| <code>packetbuffer_sender = no</code> || B analyzes packets, sends CDRs to C
|-
| <code>packetbuffer_sender = yes</code> || B forwards raw packets to C
|}


===Scenario 2: Packet Forwarding===
== Additional Configuration ==


The intermediate sniffer forwards raw packets instead of CDRs.
=== GUI Visibility ===


'''Sensor B (intermediate):'''
In client-server mode, only the central server appears in the GUI automatically. To make remote sensors visible (for charts, remote upgrades):
<syntaxhighlight lang="bash">
mirror_bind = 0.0.0.0
mirror_bind_port = 5090
server_destination = central.server.ip
server_destination_port = 60024
packetbuffer_sender = yes
</syntaxhighlight>


'''Result:'''
# Go to '''GUI → Settings → Sensors'''
* B forwards raw packets from A+B to C
# Add sensor manually with its <code>manager_ip:manager_port</code>
* C analyzes all packets and stores PCAP files
# Ensure <code>manager_aes_key</code> matches the GUI database
* C stores CDRs in MySQL


===Compression for Mirroring===
=== Compression ===


When using mirror mode, compression can reduce network bandwidth:
Reduce bandwidth for mirroring:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="ini">
packetbuffer_compress = yes
packetbuffer_compress = yes
packetbuffer_compress_ratio = 100
packetbuffer_compress_ratio = 100
max_buffer_mem = 2000
</syntaxhighlight>
Adjust <code>packetbuffer_compress_ratio</code> if CPU becomes a bottleneck.
==GUI Visibility==
'''Automatic visibility:'''
* Client-server mode: Only the central server appears in GUI
* Hybrid chain: Only the final server (C) and intermediate forwarder (B) appear
'''Manual sensor registration:'''
If you want sensor A to appear in GUI (for RRD charts, remote upgrades):
# Go to GUI → Settings → Sensors
# Add sensor A manually with its <code>manager_ip:manager_port</code>
# Ensure <code>manager_aes_key</code> and <code>manager_aes_iv</code> match GUI database values
==Performance Optimization==
===Client-Server Mode for Better Performance===
Switching from standalone to client-server architecture can significantly improve MySQL insert performance:
# '''Centralized writes''': Single server instance handles all MySQL inserts (reduces lock contention)
# '''Enable <code>mysql_enable_set_id</code>''': Let application handle ID auto-increment instead of MySQL
# '''Optimize MySQL configuration''': Tune <code>innodb_flush_log_at_trx_commit</code>, <code>innodb_io_capacity</code>, etc.
'''Migration steps:'''
# Configure server: Set <code>server_bind</code>, <code>server_bind_port</code>, <code>server_password</code>
# Initially set <code>mysql_enable_set_id = no</code> on server
# Migrate sniffers one by one: Set <code>server_destination</code>, remove <code>mysqlhost</code>
# After all sniffers migrated: Enable <code>mysql_enable_set_id = yes</code> on server and restart
==SRTP/DTLS Decryption in Mirror Mode==
When using mirror mode, ensure SSL/TLS decryption is configured correctly:
'''On source sniffer (with mirror_destination):'''
<syntaxhighlight lang="bash">
sipport = 5060,5061
</syntaxhighlight>
This ensures TCP packets (including TLS handshakes) are also mirrored.
'''On receiving sniffer (with mirror_bind):'''
Configure SSL decryption options here:
<syntaxhighlight lang="bash">
ssl_ipport = ...
ssl_sessionkey = ...
</syntaxhighlight>
</syntaxhighlight>


==Important Limitations==
=== SRTP/DTLS Decryption ===
 
{{Warning|The hybrid chain workaround is '''not officially supported''' and may not work in future sniffer releases.}}


'''Key limitations:'''
When mirroring encrypted traffic:
# <code>server_bind</code> and <code>server_destination</code> cannot coexist in one instance
# Hybrid chain architecture is unstable across sniffer versions
# No per-client authentication (same password for all clients)
# Recommended: Use standard multiple clients → single server architecture


==Future Enhancement (VS-1605)==
* '''Source sensor''': Include TLS ports in <code>sipport = 5060,5061</code>
 
* '''Receiver sensor''': Configure <code>ssl_ipport</code> and <code>ssl_sessionkey</code> for decryption
A future release may support native dual-mode operation with these new options:
 
<syntaxhighlight lang="bash">
# Server mode (receive connections)
server_bind = 0.0.0.0
server_bind_port = 60024
server_bind_password = receive_secret
 
# Client mode (send to upstream)
server_destination = upstream.ip
server_destination_port = 60025
server_destination_password = send_secret
 
# Enable both modes
server_dual_mode = yes
</syntaxhighlight>


This would enable clean multi-tier architectures without workarounds.
== Limitations ==


* <code>server_bind</code> and <code>server_destination</code> cannot coexist in one instance
* Hybrid chain is a workaround, not officially supported
* All clients share the same password (no per-client authentication)
* PCAP retrieval from remote sensors requires network connectivity to each sensor


== AI Summary for RAG ==
== AI Summary for RAG ==
'''Summary:''' This guide explains how to deploy VoIPmonitor in distributed architectures using standalone, client-server, packet mirroring, and hybrid chain topologies. It documents how multiple remote sensors can send data to a central server, how mirror mode forwards raw packets between sniffers, and how a workaround combines mirroring with client mode to build multi-tier chains. The article clarifies where CDRs and PCAPs are stored in each scenario, how sensors appear in the GUI, how to manually register sensors, and how to optimize MySQL and VoIPmonitor configuration when migrating to client-server mode for better performance. It also covers forwarding SIP packets from a SIP-only probe to a central server that merges them with RTP media, using `packetbuffer_sender=yes` with `server_destination`/`server_bind` to create complete CDRs. Additionally, the article covers SRTP/DTLS decryption in mirror mode, current limitations (such as lack of dual-mode server/client in one process), and a proposed future enhancement (VS-1605) that would enable clean multi-hop deployments without workarounds.
'''Summary:''' VoIPmonitor supports distributed deployments using client-server mode (sensors send CDRs to central server), packet mirroring mode (sensors forward raw packets), or hybrid chain (workaround combining both). In client-server mode, CDRs are stored centrally while PCAPs remain on each sensor. Packet mirroring is useful for central packet analysis or merging SIP signaling with RTP media captured at different locations using <code>packetbuffer_sender=yes</code>. The hybrid chain workaround uses <code>mirror_bind</code> + <code>server_destination</code> on an intermediate sensor but is not officially supported.
'''Keywords:''' distributed architecture, client-server mode, mirror mode, hybrid chain, remote sensor, CDR forwarding, packet mirroring, packetbuffer_sender, SIP probe forwarding, RTP media merging, server_destination, server_bind, compression, MySQL performance, SRTP, DTLS, GUI sensors, manager_ip, scalability, multi-site monitoring
'''Keywords:''' distributed architecture, client-server, mirror mode, server_destination, server_bind, mirror_destination, mirror_bind, packetbuffer_sender, SIP probe, RTP merging, hybrid chain, multi-site, central server, remote sensors
'''Key Questions:'''
'''Key Questions:'''
* How do I connect multiple VoIPmonitor sensors to a single central server using client-server mode?
* How do I connect multiple VoIPmonitor sensors to a central server?
* When should I use packet mirroring instead of sending only CDRs from remote sensors?
* What is the difference between client-server mode and packet mirroring?
* How are CDRs and PCAP files stored and accessed in client-server versus hybrid chain configurations?
* How do I merge SIP and RTP traffic captured on different machines?
* What are the limitations of combining <code>server_bind</code> and <code>server_destination</code> in a single sniffer instance?
* Can a single sniffer be both a server and a client?
* How can I optimize MySQL and VoIPmonitor settings when migrating from standalone to client-server architecture?
* Where are CDRs and PCAP files stored in distributed mode?
* How do I ensure that all sensors are visible in the GUI and correctly registered for remote management?
* How do I make remote sensors visible in the GUI?
* What are the current constraints and future plans (VS-1605) for native multi-tier VoIPmonitor deployments?
* How do I forward SIP packets from a probe to a central server when SIP signaling and RTP media are captured on separate machines?
* How do I configure `packetbuffer_sender=yes` with `server_destination` to merge SIP signaling from one location with RTP media from another?

Revision as of 14:19, 4 January 2026


This guide explains how to deploy multiple VoIPmonitor sensors in a distributed architecture.

Overview

VoIPmonitor supports three distributed deployment modes:

Mode What is sent Use case
Client-Server CDRs (call records) Multiple sites → central database
Packet Mirroring Raw packets Central analysis, SIP+RTP merging
Hybrid Chain CDRs or packets Multi-tier (workaround, not recommended)

Client-Server Mode (Recommended)

Multiple sensors send CDRs to a central server. This is the standard architecture for multi-site deployments.

Configuration

On each sensor (client): 

server_destination = central.server.ip
server_destination_port = 60024
server_password = shared_secret

On central server: 

server_bind = 0.0.0.0
server_bind_port = 60024
server_password = shared_secret

Data Storage

  • CDRs: Stored in MySQL on central server only
  • PCAPs: Stored on each sensor locally (GUI retrieves them via network)

ℹ️ Note: All instances must use the same server_password.

Packet Mirroring Mode

One sensor forwards raw packets to another for analysis. Useful when you need central packet processing or when SIP and RTP are captured at different locations.

Configuration

On source (Sensor A): 

mirror_destination = sensor.b.ip
mirror_destination_port = 5090

On receiver (Sensor B): 

mirror_bind = 0.0.0.0
mirror_bind_port = 5090

Use Case: SIP + RTP Merging

When SIP signaling and RTP media are captured on separate machines, a SIP probe can forward packets to a central server that captures RTP locally:

SIP Probe config: 

packetbuffer_sender = yes
server_destination = central.server.ip
server_destination_port = 60024

Central Server config: 

server_bind = 0.0.0.0
server_bind_port = 60024
interface = eth0

The packetbuffer_sender = yes option sends raw packets instead of CDRs.

Hybrid Chain (Workaround)

⚠️ Warning: This configuration is not officially supported and may break in future releases. Use standard client-server mode when possible.

A single sniffer cannot use both server_bind and server_destination simultaneously. However, you can combine mirroring with client-server mode as a workaround:

Sensor A uses mirror_destination → Sensor B

Sensor B uses mirror_bind + server_destination → Server C

Sensor B setting Result
packetbuffer_sender = no B analyzes packets, sends CDRs to C
packetbuffer_sender = yes B forwards raw packets to C

Additional Configuration

GUI Visibility

In client-server mode, only the central server appears in the GUI automatically. To make remote sensors visible (for charts, remote upgrades):

  1. Go to GUI → Settings → Sensors
  2. Add sensor manually with its manager_ip:manager_port
  3. Ensure manager_aes_key matches the GUI database

Compression

Reduce bandwidth for mirroring: 

packetbuffer_compress = yes
packetbuffer_compress_ratio = 100

SRTP/DTLS Decryption

When mirroring encrypted traffic:

  • Source sensor: Include TLS ports in sipport = 5060,5061
  • Receiver sensor: Configure ssl_ipport and ssl_sessionkey for decryption

Limitations

  • server_bind and server_destination cannot coexist in one instance
  • Hybrid chain is a workaround, not officially supported
  • All clients share the same password (no per-client authentication)
  • PCAP retrieval from remote sensors requires network connectivity to each sensor

AI Summary for RAG

Summary: VoIPmonitor supports distributed deployments using client-server mode (sensors send CDRs to central server), packet mirroring mode (sensors forward raw packets), or hybrid chain (workaround combining both). In client-server mode, CDRs are stored centrally while PCAPs remain on each sensor. Packet mirroring is useful for central packet analysis or merging SIP signaling with RTP media captured at different locations using packetbuffer_sender=yes. The hybrid chain workaround uses mirror_bind + server_destination on an intermediate sensor but is not officially supported. Keywords: distributed architecture, client-server, mirror mode, server_destination, server_bind, mirror_destination, mirror_bind, packetbuffer_sender, SIP probe, RTP merging, hybrid chain, multi-site, central server, remote sensors Key Questions:

  • How do I connect multiple VoIPmonitor sensors to a central server?
  • What is the difference between client-server mode and packet mirroring?
  • How do I merge SIP and RTP traffic captured on different machines?
  • Can a single sniffer be both a server and a client?
  • Where are CDRs and PCAP files stored in distributed mode?
  • How do I make remote sensors visible in the GUI?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Sniffer_distributed_architecture&oldid=6475"