Qual è la migliore architettura per l'integrazione CDR in un'applicazione basata su asterisco

Question

Iam sta sviluppando una piattaforma VOIP che consente agli utenti di effettuare 100 chiamate simultaneamente utilizzando il mio servizio.

Asterisk memorizza tutti i record dei dettagli delle chiamate nella tabella CDR. Mi piacerebbe sapere dove è il posto migliore per mantenere questo tavolo per la migliore architettura possibile del mio sistema.

Devo tenerlo nella casella Asterisk ed eseguire un cron per sincronizzarlo con il server del database O dovrei chiamare direttamente il server DB dalla casella asterisco e registrare tutti i dati direttamente sul database in remoto tramite Asterisk.

Tutti sentono che entrambe le architetture hanno i loro pro e contro. Vorrei l'aiuto di esperti per suggerirmi quale sarebbe il miglior percorso possibile per la scalabilità e la sostenibilità a lungo termine.

Answer 1

L'architettura migliore sarebbe utilizzare nodi distribuiti (Server), ad esempio PBX, server Web & Server DB in diversi nodi. PBX popolerà la tabella CDR (questo deve essere in un server DB) dopo ogni chiamata, è possibile recuperare questi record dal proprio server Web per i propri scopi di fatturazione dei report &.

Utilizzando Cron sincronizzare tabella DB non è raccomandato in quanto si mangia le risorse di sistema & larghezza di banda troppo (come questo cron verrà eseguito ogni volta che divorando la risorsa di sistema & sincronizzazione con Db causerà l'utilizzo di banda) Quindi, utilizzando sopra architettura definita è possibile risparmiare risorse di sistema che verranno utilizzate nella gestione di cron

in secondo luogo se si inserisce CDR nelle stesso nodo PBX farà risparmiare risorse di sistema a causa di cron, ma per la segnalazione & fatturazione è necessario recuperare i dati da questo nodo in modo non puoi salvare la larghezza di banda, questo schema ha un grosso svantaggio, dato che attualmente stai parlando di 100 chiamate contemporaneamente e se avessi 1000 o più ??

In questo caso è necessario utilizzare il clustering PBX in tal caso, sarà necessario un server DB centralizzato che verrà sincronizzato dai cluster PBX.

Quindi in tutti gli aspetti la mia architettura suggerita sarebbe perfettamente adatta alle vostre esigenze. Come si afferma nella domanda che è necessario solo 100s di chiamate simultanee è possibile utilizzare un singolo nodo per il DB & Web server, mentre PBx in altro nodo

Answer 2

Penso che se è possibile connettersi direttamente da Asterisk nel database di te dovrebbe usarlo. L'ho visto su alcune installazioni di Asterisk (incluso un call center abbastanza grande) e ha funzionato bene.

L'altra opzione che uso in cui non v'è alcun collegamento diretto da Asterisk al database, ma non c'è la connessione HTTPS per altri servizi, o in cui la struttura della tabella di fatturazione non è compatibile con le tabelle Asterisk in modo da utilizzare i file CSV CDR. Tale file viene inviato ogni pochi minuti al sistema CRM. Io uso cron e poco script Python. In questo modo posso adattarmi facilmente al formato CSV utilizzato dal sistema di fatturazione CRM.

Answer 3

L'utilizzo di un server di database separato per archiviare i CDR è l'opzione corretta per tutto tranne che per l'implementazione di un asterisco per hobby. Asterisk semplifica la selezione di un database di destinazione per i tuoi CDR e ha una miriade di diverse opzioni di database: MySQL, Postgresql. MSSQL ecc. L'implementazione del CDR Asterisk utilizza solo una singola tabella, quindi è in realtà un'integrazione molto semplice tra esso e il server del database.

Una cosa da essere MOLTO consapevole è che se il server del database o la connessione tra esso e il server Asterisk ha problemi, avrà un impatto sull'elaborazione delle chiamate.Se c'è un problema, Asterisk bloccherà mentre continua a provare a connettersi al database per scrivere i CDR. Mentre lo fa, non elaborerà altre chiamate. Probabilmente questo è il comportamento desiderato in quanto i CDR sono fondamentali per la fatturazione e non poterli registrare significa che qualsiasi chiamata potrebbe potenzialmente diventare libera. Come backup è anche possibile impostare la registrazione CDR su un file .csv sul server Asterisk come approccio per cintura e parentesi graffe.