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. Entrambi i punti di accesso sono equivalenti ed è compito del server del cliente bilanciare o andare in fallback a seguito di un fault

• 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