Introduzione: La Storia si Ripete nell’Era dell’AI

Nel panorama tecnologico attuale, stiamo assistendo a un fenomeno inquietantemente familiare. Proprio come Google dominava Internet agli inizi degli anni 2000, oggi i giganti dell’intelligenza artificiale stanno replicando la stessa strategia anti-competitiva, eliminando sistematicamente l’innovazione delle startup attraverso l’integrazione nativa delle loro funzionalità.

Come i Big Player dell’AI Stanno Assorbendo la Concorrenza-  Il Caso OpenAI 2025 ed  Il Modello Google degli Anni 2000: Una Lezione di Storia

La Strategia dell’Acquisizione Forzata

All’alba di Internet, Google aveva sviluppato una strategia tanto efficace quanto spietata per mantenere la propria posizione dominante nel mercato. Il colosso di Mountain View identificava le applicazioni di maggior successo e presentava alle startup un ultimatum implicito: essere acquisite o essere eliminate dal mercato.

Un caso emblematico fu quello delle app anti-furto per smartphone. Queste applicazioni offrivano funzionalità premium come:

• Localizzazione GPS dei dispositivi rubati
• Blocco remoto del telefono
• Cancellazione dati a distanza
• Allarmi antifurto

Google acquisì queste aziende non tanto per il loro valore intrinseco, quanto per evitare una competizione diretta. L’alternativa era chiara: “Vendete a noi, o renderemo gratuita la vostra soluzione e vi metteremo fuori mercato.”

Il Pattern della Cannibalizzazione Tecnologica

Questo modello seguiva sempre lo stesso schema:

1. Identificazione: Google individuava mercati emergenti con alta trazione
2. Osservazione: Monitorava quali soluzioni ottenevano maggior successo
3. Ultimatum: Offriva acquisizioni vantaggiose alle startup leader
4. Eliminazione: In caso di rifiuto, integrava gratuitamente le funzionalità nei propri servizi

OpenAI: Il Nuovo Protagonista della Cannibalizzazione AI

Il Rilascio della Responses API: Un Game Changer

L’11 marzo 2025 ha segnato una data cruciale per l’ecosistema dell’intelligenza artificiale. OpenAI ha rilasciato la Responses API insieme a una serie di strumenti integrati che hanno cambiato radicalmente le dinamiche competitive del settore.

La nuova API include:

• Web Search: Ricerca web nativa con citazioni accurate
• File Search: Strumento di retrieval avanzato per documenti
• Computer Use: Controllo automatizzato di computer e macchine virtuali
• Agents SDK: Framework per l’orchestrazione di agenti AI

L’Impatto Immediato sul Mercato delle Startup AI

Con un colpo di spugna, centinaia di startup specializzate hanno visto evaporare il proprio vantaggio competitivo:

• Web scraping companies: Rese obsolete dalla web search nativa
• Servizi di ricerca intelligente: Superati dalla qualità della soluzione OpenAI
• Tool di automazione: Eclissati dalle funzionalità di computer use
• Piattaforme di document processing: Superate dal file search integrato

Il Paradosso dell’Adozione Silenziosa

Nonostante questi strumenti siano disponibili da oltre cinque mesi, molti sviluppatori continuano a utilizzare tool esterni come Tavily, SerpAPI, o Browserless. Il motivo principale risiede nel gap di integrazione con le piattaforme più popolari.

Le piattaforme no-code/low-code come Flowise e n8n non hanno ancora integrato nativamente questi strumenti di OpenAI, creando una situazione paradossale:

• La soluzione nativa esiste ed è superiore
• La community continua a usare alternative costose
• Il passaggio è inevitabile, ma ritardato dalle barriere tecniche

La Cannibalizzazione Sistematica dell’Innovazione AI

Le Quattro Fasi dell’Eliminazione Competitiva

Il pattern attuale replica esattamente quello di Google, ma in versione accelerata:

Fase 1 – Identificazione: Le startup AI identificano nicchie di mercato e sviluppano soluzioni innovative

Phase 2 – Osservazione: I giganti dell’AI monitorano costantemente quali soluzioni ottengono trazione e investimenti

Fase 3 – Integrazione: Sviluppano versioni native delle funzionalità più promettenti

Fase 4 – Eliminazione: Le startup vengono eliminate dal mercato o costrette a vendere sottocosto

Settori a Rischio nell’Ecosistema AI

Ogni verticale dell’intelligenza artificiale è potenzialmente a rischio:

• Analisi dati e business intelligence
• Generazione e ottimizzazione codice
• Traduzione e localizzazione
• Assistenti virtuali specializzati
• Computer vision e image processing
• Audio processing e speech-to-text

L’Illusione della Scelta nel Mercato AI

Concentrazione del Potere Decisionale

La conseguenza più grave di questo fenomeno non è meramente economica, ma sistemica. Quando pochi giganti controllano l’intera catena del valore dell’AI, l’innovazione si concentra nelle loro mani, limitando la diversità delle soluzioni disponibili.

Il Circolo Vizioso dell’Investimento

Questa dinamica crea un effetto domino devastante:

• Investitori diventano cauti nel finanziare startup in aree “a rischio integrazione”
• Imprenditori si orientano verso nicchie sempre più piccole
• Innovazione viene artificialmente limitata dalla paura dell’assimilazione
• Mercato perde diversità e soluzioni creative

Il Costo Nascosto del Progresso nell’AI

Rallentamento dell’Innovazione Disruptive

Quando le soluzioni più creative rischiano di non vedere mai la luce perché “troppo appetibili” per i giganti, il progresso tecnologico rallenta paradossalmente. Questo fenomeno è già osservabile in diversi settori:

• Ricerca semantica: Dominata da pochi player principali
• Generazione contenuti: Concentrata su OpenAI, Google, Anthropic
• Automazione business: Sempre più centralizzata

L’Esempio Storico di Google Search

Quando Google dominava completamente il settore della ricerca web, abbiamo assistito a un rallentamento dell’innovazione in quel campo per oltre un decennio. Solo l’emergere dell’AI conversazionale ha rimesso in discussione questo monopolio.

Strategie di Sopravvivenza per le Startup AI

Nicchie Ultra-Specializzate

Le startup che riescono a sopravvivere oggi puntano su:

• Verticali industriali specifici (healthcare, finance, legal)
• Soluzioni on-premise per aziende con esigenze di privacy
• Integrazioni proprietarie difficili da replicare
• Expertise dominio-specifico non facilmente automatizzabile

Il Vantaggio della Velocità di Implementazione

Alcune aziende stanno adottando strategie di “colpisci e scappa”:

• Sviluppo rapido di MVP
• Monetizzazione immediata
• Exit strategica prima dell’integrazione nativa
• Partnership con i giganti invece di competizione diretta

Implicazioni Future per l’Ecosistema AI

Previsioni per il 2025-2026

Basandosi sui trend attuali, possiamo aspettarci:

• Accelerazione dell’integrazione nativa di funzionalità AI
• Consolidamento ulteriore del mercato attorno a pochi player
• Scomparsa di molte startup non differenziate
• Emergere di nuove nicchie ultra-specializzate

Il Ruolo della Regolamentazione

L’intervento regolatorio diventa sempre più cruciale per:

• Garantire concorrenza leale nel mercato AI
• Proteggere l’innovazione delle startup
• Prevenire monopoli dannosi per i consumatori
• Assicurare diversità nelle soluzioni tecnologiche

Conclusioni: Una Riflessione Necessaria sull’AI

Il Bivio dell’Innovazione Tecnologica

Non si tratta di demonizzare il progresso tecnologico, ma di riconoscere che la concentrazione di potere nell’AI sta replicando e amplificando gli errori del passato. La velocità dell’evoluzione AI rende questo fenomeno ancora più pericoloso rispetto all’era Google.

Domande Aperte per il Futuro

Ci troviamo di fronte a questioni fondamentali:

• Stiamo assistendo all’alba di una nuova era tecnologica o alla costruzione di nuovi monopoli digitali?
• Come possiamo preservare l’innovazione in un ecosistema sempre più centralizzato?
• Qual è il ruolo della regolamentazione nel garantire una concorrenza sana?
• Come possono sopravvivere le startup in questo scenario?

L’Importanza della Consapevolezza

La risposta a queste domande potrebbe determinare non solo il futuro delle startup, ma l’evoluzione stessa dell’intelligenza artificiale. È fondamentale che sviluppatori, investitori e policymaker comprendano le dinamiche in atto per poter agire di conseguenza.

Come i Giganti dell’AI Stanno Eliminando la Concorrenza: L’Effetto OpenAI del 2025

L'articolo Come i Giganti dell’AI Stanno Eliminando la Concorrenza: L’Effetto OpenAI del 2025 sembra essere il primo su PC Backup.

Cosa Può Fare un Operatore Virtuale IA per i Tuoi Futuri Clienti?

L'articolo Rivoluziona il Servizio Clienti con l’IA: Come l’Operatore Telefonico Virtuale Realtime può Trasformare la Tua Attività (e Farti Trovare Online!) sembra essere il primo su PC Backup.

Il mercato dei centralini continua a crescere, ma gli utenti detestano ancora gli alberi fonici – il 15 % abbandona la chiamata già nell’IVR.

Invece integrando Asterisk con riconoscimento vocale neurale (ASR), sintesi vocale di ultima generazione (TTS) e un LLM per il “cervello” conversazionale, è possibile instradare le chiamate con linguaggio naturale, ridurre drasticamente i tempi di attesa e fornire informazioni h 24, migliorando sia l’esperienza cliente sia la percezione sulla qualità del servizio offerto.

Il mercato globale dei PBX passerà da 44,3 mld $ nel 2025 a oltre 124 mld $ nel 2035 .

Eppure il 15 % dei clienti abbandona la chiamata già nel menù vocale ,  infatti la rigidità dell’IVR è la prima causa di frustrazione .

Le attese lunghe danneggiano le statistiche e la percezione sulla qualità del servizio : Zendesk consiglia di rispondere entro 2-3 squilli e chiudere in ~6 minuti , mentre le aziende con IVR conversazionale riducono il tempo medio di gestione in modo significativo

La soluzione “Centralino Asterisk + AI + IVR conversazionale: addio ai menu telefonici e alle attese”

Centralino VoIP Asterisk con intelligenza artificiale, IVR conversazionale basato su Google Speech-to-Text e Azure Neural Text-to-Speech, LLM locale via Ollama, routing istantaneo, riduzione dei tempi di attesa, risposta h 24 fuori orario, eliminazione dei menu telefonici complessi, supporto multilingua, privacy GDPR perché tutto gira on-premise, scalabile su hardware standard

Costi medi per minuto (50 % riconoscimento + 50 % sintesi)

Riconoscimento: Google STT v2 standard = 0,016 $ al minuto audio Google Cloud

Sintesi: Azure Neural TTS = 15 € / 1 M caratteri ⇒ 0,000 015 € / car. Microsoft Azure

Con parlato medio 150 parole/min ≈ 750 caratteri/min Stack Overflow ⇒ 0,011 25 € / min

Scenario 50 % + 50 % (30 s audio da riconoscere + 375 car. da sintetizzare)

Riconoscimento: 0,016 € ÷ 2 = 0,008 $

Sintesi: 0,011 25 € ÷ 2 = 0,005 6 $

Costo totale ≈ 0,0136 € per minuto di chiamata (circa 1 cent €).

Nota: i primi 1 M caratteri Google TTS e 0,5 M caratteri Azure TTS/mese sono gratuiti, così come i primi 60 min Google STT v1; la fascia free abbassa ulteriormente il costo effettivo su volumi ridotti.

Con meno di 0,014 € al minuto puoi offrire un voicebot Asterisk-AI che lavora interamente on-prem, sfrutta Google ASR e Azure Neural TTS, e dialoga grazie a un LLM in locale su GPU consumer: una soluzione scalabile, conforme a GDPR e immediatamente competitiva rispetto agli IVR tradizionali.

Casi d’uso chiave

 Smistamento istantaneo delle chiamate

L’LLM riconosce richieste come “parlare con fatturazione” o “devo comunicare l’avvenuto pagamento” e collega direttamente l’interno corretto, annullando i salti di menu.

Risposte automatiche fuori orario

Fuori dagli orari di apertura, il bot consulta il knowledge-base e fornisce informazioni (es. orari, FAQ, status ordini) o propone un callback.

 Multicanale e omnicanale

Lo stesso core può alimentare chatbot web o WhatsApp; servizi come Amazon Lex mostrano già funzionalità di generative AI cross-channel .

L'articolo Centralino Asterisk + AI + IVR conversazionale: addio ai menu telefonici e alle attese sembra essere il primo su PC Backup.

Negli ultimi 15 anni ho realizzato soluzioni di comunicazione sempre più evolute. Negli ultimi 2 anni il trend sempre crescente è quello di sostituire l’operato umano di basso livello, con soluzioni altamente automatizzate. Le Realtime API di OpenAI hanno mostrato la qualità che si può ottenere in una conversazione con un chatbot, ma al tempo stesso han fatto capire che i costi di utilizzo, per soluzioni così “monolitiche”, sono ancora troppo elevate. I costi per una PMI od un call center sono nell’ordine di 0,34/0,40 centesimi di euro al minuto per canale, arrivando ad ottenere costi anche di qualche euro per singola conversazione.

Oggi vi mostro come integro Asterisk PBX , in locale (su hardware performante ) , con intelligenza artificiale, in modo personalizzato e sostenibile dal punto di vista dei costi, per piccole imprese e anche per call center di dimensioni ridotte.

Architettura  del Centralino Telefonico dotato di  Intelligenza Artificiale

1. Asterisk PBX
   Il cuore del centralino: gestisce le chiamate  creando due canali simultanei, in uno avviene la sintesi vocale del testo ricevuto dall’ Intelligenza Artificiale e nell’altro si registra in continuo il parlato dell’ Utente, che diventa di volta in volta, il nuovo input per l’AI. La riproduzione dell’audio  può essere interrotta (barge-in) senza perdere nulla .

2. Flowise
   Strumento open-source per costruire chatflows nel quale utilizzeremo (ma con possibilità di swap tra le molteplici tecnologie diponibili)

   • Document store  integrato e ChromaDB per il vector retrieval

   • Buffer di memoria persistente da usare durante comunicazioni successive  (l’identificativo chiamate è un’ottimo id per salvare le conversazioni pregresse)

   • Chiamata LLM (Groq o alternativa locale come Ollama) per generare la risposta

3. Google ASR
   Trascrive in tempo reale la voce dell’utente → testo.

4. Microsoft Speech API
   Converte in voce naturale la risposta testuale generata ed attraverso la funzionalità streaming inizia a riprodurre appena riceve i primi chunk di testo.

5. ChromaDB
   Archiviazione vettoriale delle knowledge base custom.

6. Groq LLM / Ollama
   Genera risposte intelligenti; su hardware locale elimina il costo per token.

Costi delle API (lingua italiana)

Conversione euro basata su cambio ≈ 1 $ = 0,92 €.

Esempi pratici

• Chiamata da 5 minuti

  • ASR: 5×€0,022 ≈ €0,11

  • TTS (neurale): 5×€0,015 ≈ €0,075

  • LLM cloud: ≈ €0,001
    Totale: ~€0,19 per chiamata

• 1 ora continua

  • ASR: 60×€0,022 ≈ €1,32

  • TTS: 60×€0,015 ≈ €0,90

  • LLM: ≈ €0,01
    Totale: ~€2,23/ora

Con un LLM locale (Ollama , a patto di avere abbastanza potenza di calcolo) azzerate anche l’ultimo centesimo: €2,22/ora solo per ASR+TTS.

Vantaggi per PMI e call center

• Personalizzazione totale: knowledge base cucita su misura, NLU/LLM addestrabili sui vostri dati, reportistica realizzata su richiesta.

• Scalabilità economica: paghi soltanto ciò che consumi, pochi centesimi a chiamata.

• Privacy e controllo: possibilità di “shiftare” l’LLM in locale, senza trasferire dati su cloud.(richiesta potenza di calcolo)

Se stai cercando un centralino AI potente e conveniente, questa architettura è la soluzione ideale per offrire un servizio avanzato senza sforare il budget.

Il prezzo vero che si paga è quel minimo di latenza (percettibile ma non tale da infastidire) che viene data da un sistema non speech to speech, chi cerca soluzioni del genere, ad ora, deve rivolgersi a soluzioni dal costo di utilizzo decisamente superiore.

Come soluzione per alleviare questa minima latenza, abbiamo realizzato un sistema che, in maniera del tutto trasparente, aggiunge al flusso audio inviato al chiamante, un lieve rumore di sottofondo che simula il brusio classico dell’ufficio in orario di lavoro. Questo piccolo accorgimento rende la brevissima attesa della risposta completamente naturale e rilassante.

L'articolo Centralino Telefonico AI – Intelligenza Artificiale – Economico per PMI e Call Center sembra essere il primo su PC Backup.

Integrazione Avanzata OpenAI ChatGPT e Asterisk PBX: Soluzioni Personalizzate

Da oltre sei mesi, ci dedichiamo all’integrazione tra le API OpenAI e Asterisk PBX. Questa combinazione ci permette di offrire soluzioni innovative e completamente adattate alle tue esigenze specifiche.

1. Personalizzazione al 100%

Ogni azienda è unica, e così devono essere le soluzioni che utilizza. Offriamo soluzioni completamente personalizzate, modellate sulle tue necessità e richieste specifiche. Dalla configurazione del centralino alle funzionalità avanzate, tutto è progettato per adattarsi perfettamente al tuo business.

2. Addestramento di Modelli ChatGPT Personalizzati

Con il nostro supporto, potrai fornire tutte le informazioni necessarie per addestrare modelli personalizzati di ChatGPT. Questo significa che il sistema sarà in grado di rispondere efficacemente alle domande specifiche dei tuoi clienti, migliorando la comunicazione e aumentando la soddisfazione del cliente.

3. Integrazione con Software Esistenti

Possiamo creare funzioni di interfacciamento con i tuoi programmi attuali, garantendo una perfetta integrazione tra il sistema ASTERISK PBX / ChatGPT e il software già in uso. Questo permette di ottimizzare i processi aziendali senza dover rinunciare agli strumenti a cui sei abituato.

Vantaggi dell’Integrazione tra OpenAI e Asterisk PBX

• Efficienza Operativa: Automatizza le risposte alle chiamate frequenti e riduci il carico di lavoro del tuo team.
• Migliore Esperienza Cliente: Offri risposte immediate e accurate, aumentando la soddisfazione del cliente.
• Scalabilità: Adatta facilmente il sistema man mano che la tua azienda cresce o cambiano le esigenze.
• Competitività: Sfrutta tecnologie all’avanguardia per distinguerti nel tuo settore.

Come Iniziare

1. Contatto Iniziale: Parlaci delle tue esigenze e obiettivi.
2. Analisi Personalizzata: Valutiamo insieme le soluzioni più adatte.
3. Implementazione: Configuriamo e integriamo il sistema secondo le tue specifiche.
4. Supporto Continuo: Ti accompagniamo in ogni fase, dall’addestramento dei modelli all’assistenza post-vendita.

Contattaci Oggi Stesso

Non perdere l’opportunità di rivoluzionare la comunicazione aziendale con una soluzione su misura.  per una consulenza gratuita e scopri come possiamo aiutarti a raggiungere nuovi livelli di efficienza e professionalità

L'articolo Integrazione Avanzata OpenAI ChatGPT e Asterisk PBX: Soluzioni Personalizzate sembra essere il primo su PC Backup.

Siamo stati contattati da un cliente, circa 4 mesi fa, il quale aveva l’esigenza di creare un voicebot per automatizzare fuori orario, il processo telefonico.

Inizialmente il cliente aveva ipotizzato di usare Dialogflow per creare un vero e propio bot telefonico (chatbot), per consentire ai propri clienti, di svolgere le normali operazioni anche al di fuori degli orari di apertura, sotto forma di interpretazione dell’intenzione del chiamante.

Diciamo che dopo i primi contatti, abbiamo capito che il discorso chatbot veniva a cadere, una buona parte della clientela che avrebbe telefonato era di nazionalità straniera, con una pronuncia quanto meno non impeccabile. Questa intuizione, gli unici tra quelli interpellati dal cliente, ci ha fatto guadagnare la commessa.

Abbiamo quindi optato per un sistema con un classico menù ivr con scelte da pad telefonico, e domande secche in cui si sarebbe utilizzato il GSR Google Speech Recognition.

Nel caso specifico al chiamante viene chiesto di pronunciare il nome della città in cui si sposterà, ed attraverso delle API, una volta validato il riconoscimento vocale attraverso un raffronto ad un database di città italiane esistenti, viene aggiornato un annuncio pubblicato sul sito di proprietà del cliente.

Naturalmente lo strumento ideale è Asterisk pbx, al quale si è aggiunto un server MRCP con connettore verso le APi Google DialogFlow (abbiamo optato per queste licenze poichè non escludiamo in futuro che il cliente possa utilizzarle, ed a parità di costo, DialogFlow utilizza comunque il motore di riconoscimento della voce GSR ).

Ad Asterisk pbx  abbiamo affiancato tutta una serie di script php e bash per poter, di volta in volta, ottimizzare il processo, nonchè ODBC per la connessione al database MySql delle città italiane.

Come sempre, per rendere più naturale il processo telefonico, utilizziamo Amazon Polly, per la creazione in tempo reale, di risposte personalizzate. Prendento i dati da variabili presenti in vari database e a cui da riferimeneto il numero telefonico del chiamante.

E.G attraverso l’identificativo chiamante CallerID, sappiamo se il cliente è già presente nel database e possiamo salutarlo per nome e cognome, prima di porgli le domande di rito.

Per il discorso pronuncia, monitoriamo costantemente e stocchiamo quello che DialogFlow riconosce del parlato, e nel caso ci siano “difetti” di pronuncia ripetuti (vedi la b argentina che viene pronunciata v, oppure la elle brasiliana che davanti ad una vocale quasi sparisce), andiamo ad aggiungere un record nel database dei paesi linkandolo con la pronuncia relativa ad un determinto ceppo linguistico.

E.G la città di Alba, pronunciata da una brasiliana, è stata rinosciuta da DialogFlow per 2 volte  come Auba.  Quindi abbiamo inserito Auba come fosse Alba.

Il sistema, vista la soddisfazione del cliente, adesso  viene utilizzato anche in orario di apertura, come prima scelta per il chiamante, che può comunque optare (in orario di ufficio) per l’operatore fisico. Questo ha consentito al cliente di spostare il 50% della forza lavoro verso mansioni con una produttività maggiore.

L’automazione del processo telefonico mediante l’utizzo  di Chatbot o voicebot per la creazione di un operatore telefonico virtuale, è ormai una realtà alla portata di tutti.

L'articolo Chatbot o voicebot per la creazione di un operatore telefonico virtuale sembra essere il primo su PC Backup.

Quando si immagina un Cluster, si è sempre portati a pensare ad  un sistema complesso, ingombrante, costoso e difficile da gestire. Ma un sistema di High Avaialability basico non deve per forza esserlo, anzi utilizzando Keepalived ed il protocollo VRRP si possono ottenere ottimi risultati con il minimo sforzo.

Keepalived è un sistema di routing software che rende disponibili le  strutture necessarie per ottenere un Sistema di  Load Balancing e/o High Availability ed ha alla sua base il protocollo VRRP ( Virtual Router Redundancy Protocol ) , un protocollo nato per gestire la ridondanza negli apparati di networking, ma che fornisce gli stessi servizi in un sistema server.

Il concetto principale di un sistema di HA rimane  sempre uno, il VIP (virtual Ip Addres), l’indirizzo  raggiungibile pubblicamente ed il protocollo VRRP si occuperà di determinare l’host “intestatario” di suddetto Ip, almeno fino a quando esso soddisferà i requisiti di eligibilità. In caso contrario, in cui l’host si dovesse “perdere”, VRRP fornirà il meccanismo per rilevare il server fault e trasferire la “proprietà” del VIP ad un host rimasto a disposizione del cluster, parimente configurato per fornire i servizi del cluster.

server1# ip -brief address show
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.122.101/24 192.168.122.200/24 fe80::5054:ff:fe82:d66e/64

server2# ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.122.102/24 fe80::5054:ff:fe04:2c5d/64
 Il VIP è sul server1, ma qualora interrompessimo il servizio keepalived su di esso

server1# systemctl stop keepalived

server1# ip -brief address show
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.122.101/24 fe80::5054:ff:fe82:d66e/64

Questo passerà automaticamente sul secondo nodo

server2# ip -brief address show
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.122.102/24 192.168.122.200/24 fe80::5054:ff:fe04:2c5d/64

Nel caso di un cluster Asterisk, DRBD  si occuperà della parte file di configurazione /storage e la replicazione Attiva / Passiva per la parte DB (MySQL).

In un sistema come Asterisk, fornire un sistema di Clustering realmente efficente, cioè con nessuna perdita di comunicazione, risulta molto complicato da ottenere. Il protocollo Sip per come implementa il servizio Registrar e Location non consente la gestione del fail-over in maniera trasparente. Con qualche artificio si può girarci intorno, ma nei casi “normali” uno o due minuti di downtime  sarà da tenere in conto, quanto meno per lasciare il tempo ai vari apparati di ri-registrarsi sulla nuova istanza del cluster.

L'articolo Keepalived per la gestione semplificata di Asterisk Cluster sembra essere il primo su PC Backup.

Nonostante l’ottima affidabilità riscontrata nel corso degli anni dei Server, di qualsiasi marca e a partire dalla fascia bassa del mercato, esiste la necessità, a volte, di mettere  in campo delle soluzioni necessarie per assicurare la continuità del servizio telefonico, riducendo quindi il periodo di down in caso di guasto fisico, la necessità quindi di creare un  Low Level Asterisk  e High Availability Cluster

La stessa affidabilità dei Server, non la abbiamo riscontrata invece negli Hard Disk, Sata o SAS che fossero, molto meglio gli SSD attualmente…e la vecchia tecnologia SCSI quando era disponibile.

La continuità del servizio o High Availability,è una caratteristica chiave di un sistema informatico di classe Server. come Asterisk PBX, la quale ha lo scopo di assicurare livelli di operatività che devono tendere, per quanto reso possibile dalle disponibilità economiche, al raggiungimento delle percentuali definite five-nine,cioè 99,999% di uptime.

Un sistema come Asterisk pbx, per funzionare ed offire ai suoi fruitori i servizi per cui è stato disegnato, consta di varie parti. Ciascuna di queste parti deve sottostare ad alcuni principi chiave per garantirne il funzionamento continuo.

• Eliminazione del single point of failure, quindi aggiungere ridondanza ai componenti
• Sistema efficace ed efficente di sovrapposizione e/o affiancamento dei sottosistemi
• Rilevazione tempestiva di malfunzionamenti.

Dal lato prettamente HW, del Server che ospiterà il nostro sistema Asterisk, per eliminare il Single Point of Failure dovremo ricorrere ad almeno 2 Server fisici (nodi del cluster), operanti , nel caso che prenderemo in questione, in modalità Attiva / Passiva, cioè col secondo nodo pronto ad entrare in funzione in caso di guasto del primo.

CentOS, il sistema operativo utilizzato di preferenza dagli sviluppatori di Asterisk, dispone di uno Stack che rende disponibile tutto il necessario per creare un semplice e funzionale Asterisk  e High Availability Cluster.

Si parla di Stack per intendere la presenza di più software e servizi, necessari, ciascuno, per sottendere ad un particolare aspetto della sua gestione.

Il Cluster Stack deve gestire essenzialmente due feature :

• La comunicazione tra i nodi ( i 2 o più Server) del cluster
• La gestione delle risorse che devono essere rese disponibili in cluster

Per gestire correttamente le comunicazioni, ciascun Server deve disporre di due schede di rete, dovendone riservare una per le comunicazioni relative alla gestione interna del Cluster, in special modo per rilevare il possibile down di un nodo.

Pacemaker, Corosync, Heartbeat e DRDB, sono gli strumenti software necessari a creare il nostro Cluster.

Pacemaker è quello che si definisce CRM o cluster resource manager ed è il livello più esterno dei layer che compongono il nostro stack, essendo quello che si occupa di garantire la continuità dei servizi del Cluster.

Corosync / Heartbeat rappresenta il layer di comunicazione tra i nodi del cluster, necessario per sapere se uno dei nodi diventa improvvisamente irragiungibile.

DRBD ( Distributed Replicated Block Device) è una soluzione di archiviazione replicata tra i nodi del cluster ed attraverso di esso, si potranno rendere disponibili lo stesso set di file di configurazione di Asterisk, log, cdr….

Una volta configurato, il dispositivo DRDB potra contenere una partizione od un set di cartelle, di modo che tutto quello che viene creato, modificato od eliminato al suo interno, dal nodo attivo del cluster passerà anche nel nodo passivo.

L'articolo Asterisk Cluster e High Availability sembra essere il primo su PC Backup.

Dopo anni di utilizzo di Asterisk come strumento per la realizzazione di centralini (pbx), arriva il momento in cui i progetti salgono di complessità. Vieni contattato da ditte che possiedono già un centralino, ma che per un motivo o per un altro, dovendo incrementare il traffico telefonico, si trovano ad avere problemi.Bassa qualità dell’audio, caduta della chiamata, irraggiungibilità del server.Ed è qui che diviene necessario integrare Asterisk e Kamailio sip proxy server.

La scelta, il più delle volte, riguarderà una ricalibrazione dell’hardware su cui si basava l’architettura della centrale telefonica, o della connettività (LAN o WAN), essendo, per troppo tempo, dato per assodato il binomio : Linux/Asterisk = risparmio.

Ci sono però delle realtà in cui l’hardware è già ben dimensionato, la connettività regge, ed il mero problema risulta l’effettiva capacità di Asterisk di gestire una mole di telefonate simultanee oltre qualche centinaio (500/700 per lo più).

Questo “problema” di performance di Asterisk è noto, ed è legato alla sua architettura, ma diciamo apertamente che viene ampiamente bilanciato dai suoi pregi.

In questo scenario, l’unica alternativa sarà quella di aggiungere 1 o più server per gestire la mole crescente di telefonate, abbinato ad un sistema di bilanciamento di carico (Load Balancing), ed è qui che entra in scena Kamailio.

Kamailio è un proxy server Open Source, dalle performance imbattibili,  che operando attraverso il protocollo SIP,  si occupa della parte definita di signalling. Quindi principalmente della registrazione (Registrar), della localizzazione della destinazione di una sessione ( la S di Sip), e della negoziazione dei parametri necessari per avviare la comunicazione multimediale (tipologia,codec….ecc..ecc..).

In uno scenario ideale, Kamailio si può occupare dell’autenticazione degli Endpoint SIP (telefoni Ip), dei carrier VoIP e del bilanciamento di carico tra le centrali Asterisk, mentre la parte definita dal protocollo RTP, cioè quella di scambio di contenuti multimediali (audio e/o video), viene lasciata completamente a carico dei Server Asterisk.

Kamailio è un software basato su moduli, all’arrivo di un pacchetto SIP ( ad esempio:  chiamata entrante da un carrier VoIp  ), il modulo TM (transaction module), una volta ispezionatolo deciderà in base a delle regole contenute nel suol file di configurazione (kamailio.cfg)  se inoltrarlo verso la destinazione (nel caso in questione dialplan di asterisk).

Nella sua rotta verso la destinazione, nel caso in cui sia configurato un sistema di bilanciamento di carico, il file di configurazione kamailio.cfg, attraverso il modulo dispatcher.so, deciderà su quali degli N server Asterisk far atterrare la chiamata.

L’integrazione tra Asterisk e Kamailio sip proxy server è ancora più interessante riguardo la possibilità di configurare in kamailio un sistema di ping dei server Asterisk, che attiveranno e disattiveranno le destinazioni del Load Balancer in caso di esito negativo del ping.

Così facendo, posto di avere un numero di istanze pbx non ridotte all’osso, si avrà anche un sistema di High Availability della parte associata al MEDIA della comunicazione, mentre per la parte Kamailio, nel caso, dovremo prevederne due istanze (modalità cluster).

Questo per non incappare nel cosidetto single point of failure, cioè la possibilità di non assicurare la continuità del servizio in caso di singolo guasto hardware (singolo server kamailio).

L'articolo Asterisk e Kamailio proxy server sembra essere il primo su PC Backup.