Monitoraggio del traffico VoIP con Homer ed OpenSIPS

Avendo l’esigenza di mantenere sotto controllo il traffico VoIP degli oltre 800 interni sotto la mia responsabilità, ho deciso di provare Homer, “100% Open-Source RTC Capture, Analysis and Monitoring“:

HOMER is part of the SIPCAPTURE stack: A robust, carrier-grade and modularVoIP and RTC Capture Framework for Analysis and Monitoring with native support for all major OSS Voice platforms and vendor-agnostic Capture agents.

Ho così predisposto una macchina con Debian 8 e, seguendo la procedura di installazione rapida descritta, ho lanciato l’homer-installer script come root direttamente dalla console.

Lo script installa tutta una serie di pacchetti, tra cui MySQL, Apache, PHP e Kamailio.

Al termine dell’installazione del sistema, “Congratulations! HOMER has been installed!“, con il browser accediamo alla GUI puntando sulla porta 80 del server, dove dovrebbe darvi il benvenuto il logo arancione con l’H bianca di Homer.

A questo punto eseguiamo l’accesso con le credenziali indicate (default: admin/test123 or test1234) ed accediamo alla GUI del nostro sistema di monitoraggio ed analisi del traffico VoIP.

Ovviamente, però, è necessario configurare degli agent di monitoraggio (HEP-EEP Agents) sui nostri server SIP. Il protocollo HEP/EEP “Encapsulation allows packet mirroring without altering the original IP datagram and header contents and provides flexible allocation of additional chunks containing additional arbitrary data and payloads.“. Praticamente installiamo sul nostro server VoIP una “spia” che “rimbalza” tutto il traffico in transito (o quello che vogliamo monitorare) al server Homer (ovvero, al server Kamailio…) che effettua un primo controllo e lo memorizza nel DBMS MySQL per permetterne l’analisi (una veloce occhiata alla configurazione di Kamailio rende bene l’idea).

PerOpenSIPS sono disponibili due moduli per monitoraggio, sip_capture e sip_trace. La differenza tra i due è sostanziale: il primo, sip_capture, permette di implementare un vero e proprio sistema di smistamento dei messaggi HEP/EEP agendo anche come proxy. Il secondo, sip_trace, più semplicemente reindirizza tutto il traffico da monitorare ad un server HEP/EEP (Homer, nel mio caso), per una analisi.

Nel file opensips.cfg aggiungiamo e configuriamo il modulo sip_trace.so:

### SIP Trace
loadmodule "siptrace.so"
modparam("siptrace", "duplicate_uri", "sip:[IP server Homer]:9060")
modparam("siptrace", "duplicate_with_hep", 1)
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_flag", "TRACE_FLAG")
modparam("siptrace", "trace_on", 1)
#HEPv2 == timestamp will be included to HEP header
modparam("siptrace", "hep_version", 2)

e poi definiamo, nel processo di routing, cosa monitorare. Personalmente, almeno come primo approccio, ho deciso di monitorare tutto e così il mio script di routing inizia così:

####### Routing Logic ########

# main request routing logic

route {
  setflag(TRACE_FLAG);
  sip_trace(); 
  [...]

Riavviamo il server OpenSIPS e verifichiamo, con uno strumento di monitoring di rete tcpdump/iptraf, che sul server Homer arrivi il traffico UDP di “monitoraggio” (giusto per scrupolo).  Se i dati arrivano correttamente alla porta dove è in ascolto Kamailio (dovrebbe essere la 9060), anche il nostro database MySQL dovrebbe iniziare a popolarsi. Ed anche la nostra GUI dovrebbe iniziare a mostrare i dati ricevuti:

Ammetto che questo passaggio mi ha causato qualche imprecazione, poiché non mi ero accorto che nella parte in alto a destra della pagina è possibile impostare il periodo di visualizzazione e l’auto refresh: assicuratevi, se non visualizzate alcunché, che l’intervallo di visualizzazione impostato sia corretto (last 24 hours è il mio preferito).

Potreste inoltre avere la necessità di configurare Homer con i dati relativi al server DBMS. Il pannello “System Admins” è abbastanza self-explanatory pertanto non credo necessiti di ulteriori considerazioni.

Arrivati a questo punto, possiamo configurare quanti giorni di dati vogliamo mantenere nel nostro database. Ogni giorno alle 03:30 il cron di sistema esegue lo script /opt/homer_rotate che esegue la rotazione delle tabelle MySQL dei dati memorizzati (sip_capture_call_%Y%m%d, sip_capture_registration_%Y%m%d, sip_capture_rest_%Y%m%d…): queste tabelle possono diventare molto grandi ed occupare velocemente tutto lo spazio disponibile, pertanto assicuratevi di impostare correttamente la data retention nel file /opt/rotation.ini.

L’analisi del traffico VoIP in tempo reale è uno strumento fondamentale per avere il pieno controllo del proprio sistema e della propria rete. Consente di analizzare e di risolvere eventuali problematiche connesse ad abusi e colli di bottiglia, oltre che a monitorare l’andamento del traffico durante le giornate lavorative ed avere lo strumento per reagire in caso di problemi o guasti.

Homer, per quanto poco lo abbia usato (e mi riservo di integrare questo mio articolo in futuro), mi sembra un buon prodotto. La GUI è veloce e reattiva anche davanti all’ingente mole di dati (in 3 giorni ho raccolto più di 7 GByte nel database). L’unica accortezza è dimensionare adeguatamente le partizioni del disco e/o la rotazione delle tabelle, poiché -come ho appena detto- i dati memorizzati occupano molto spazio: nel mio contesto (800 terminali VoIP) raccolgo circa 2 GByte di informazioni al giorno.