Architettura
- Alessandro Rovetto
Il registratore viene fornito sia in modalità single-node che multi-node per ridondanza.
Single-Node
Il registratore è composto da 2 componenti logiche differenti:
Il registratore
Il portale riascolti
Registratore
La componente di registrazione è composta da OpenSIPS e Sems, raggiungibile dai server del cliente, in figura indicato come “Cliente N”, via protocollo SIP e RTP.
La registrazione prodotta da Sems viene salvata direttamente su un NAS così come viene generata, in formato non compresso e non cifrata, insieme al file di tags.
Portale Riascolti
Il portale riascolti è composto principalmente dall’applicativo CTReplay, che utilizza engine Node.js, raggiungibile via HTTP dal server del cliente.
CTReplay utilizza le seguenti risorse:
MongoDB (per salvare i dati di registrazione e le chiave di cifratura)
Redis (come sistema di cache)
NAS, per poter accedere alle registrazioni prodotte da Sems, convertirle in un formato compresso, cifrarle e poi riascoltarle o esportarle quando richiesto.
Multi-Node
L’architettura Multi-Node permette di ridondare le componenti del registratore per consentirne il funzionamento corretto anche in caso di fault di uno dei nodi presenti.
Le risorse ridondate sono le seguenti
OpenSIPS: è il frontend SIP del registratore. I due punti di accesso vengono esposti con un VIP creato tramite PCS. In caso di fault il VIP viene migrato da un server all’altro.
Sems: processo che genera effettivamente il file di registrazione. Viene bilanciato da OpenSIPS.
CTReplay: applicativo Node.js, è il frontend di accesso HTTP. I singoli nodi vengono bilanciati dall’nginx presente sul server del cliente.
MongoDB: presente con architettura replicaSet formata da 3 nodi, 2 effettivamente in replica tra di loro e il 3° nodo, che non contiene i dati, ha il ruolo di arbiter per evitare split-brain
Redis: in modalità Active/Passive