SMSC vs gateway SMS vs server SMPP: cosa fa davvero ciascuno

Chieda a tre fornitori che cosa vendono e potrebbe sentirsi rispondere “un SMSC”, “un gateway SMS” e “un server SMPP” per quello che sembra lo stesso prodotto. I termini non sono intercambiabili, e la confusione costa denaro: c’è chi compra un server SMPP convinto che raggiungerà i telefoni, o mette a budget “un SMSC” quando ciò che gli serve è un gateway e due contratti con operatori. Questa guida risolve la questione SMSC vs gateway SMS vs server SMPP con definizioni semplici, mostra come i tre si collegano nel percorso reale di un messaggio e si chiude indicando quali di essi Lei deve davvero gestire.

SMSC vs gateway SMS vs server SMPP in un paragrafo

Un SMSC vive all’interno della rete di un operatore mobile e consegna i messaggi di testo ai telefoni. Un gateway SMS vive fuori dalla rete, riceve i messaggi da applicazioni e clienti, li instrada verso la connessione giusta con l’operatore e raccoglie le ricevute di consegna. Un server SMPP è un componente di un gateway che permette ad altri sistemi di collegarsi al gateway tramite il protocollo SMPP, nello stesso modo in cui il gateway si collega agli operatori. Gli operatori gestiscono gli SMSC. Le aziende che inviano o rivendono messaggi gestiscono gateway. I gateway che servono clienti tecnici gestiscono anche server SMPP.

Tutto ciò che segue è quel paragrafo, con i dettagli completati.

SMSC: il sistema di memorizzazione e inoltro dell’operatore

Lo Short Message Service Centre è la parte della rete mobile responsabile degli SMS. Quando un telefono invia un messaggio, questo arriva all’SMSC dell’operatore del mittente; l’SMSC lo memorizza, cerca dove si trova il telefono del destinatario e lo inoltra, ritentando se il telefono è spento o fuori copertura. Questo comportamento di memorizzazione e inoltro (“store and forward”) è il motivo per cui un messaggio arriva quando si riaccende il telefono, ed è l’SMSC a svolgerlo.

Ne derivano tre conseguenze. L’SMSC dialoga con i telefoni attraverso il nucleo di segnalazione della rete (SS7, oppure Diameter nei core più recenti), che è un rapporto di telecomunicazioni, non un protocollo internet. L’SMSC appartiene all’operatore, e ogni operatore ha il proprio; non esiste un SMSC globale. E l’SMSC è l’unico elemento di questo articolo in grado di portare un messaggio su un telefono. Tutto il resto è un modo per far arrivare un messaggio a un SMSC.

Le aziende raggiungono un SMSC in uno di due modi: tramite un aggregatore che dispone già di connessioni verso molti operatori, oppure direttamente, con un contratto e un bind SMPP fornito dall’operatore. In entrambi i casi l’azienda è cliente dell’SMSC, non il suo gestore. I prodotti presentati come “SMSC per le aziende” sono gateway che accettano bind SMPP; da soli non consegnano ai telefoni.

Gateway SMS: instradamento, registro e cruscotto

Un gateway SMS è il sistema che un’azienda gestisce per inviare messaggi su larga scala e, se rivende, per permettere ai propri clienti di inviare. Il lavoro del gateway è tutto ciò che sta tra “un messaggio è stato inviato” e “ecco la ricevuta”:

• Accettare i messaggi da una console web, da un’API HTTP, da un caricamento di file o da un bind SMPP.
• Convalidarli: regole sul sender ID, codifica, lunghezza, saldo del cliente.
• Instradarli: scegliere quale connessione con un operatore o quale aggregatore trasporta questo messaggio verso questa destinazione, in base a prezzo, qualità o contratto.
• Consegnarli sulla connessione scelta, di solito via SMPP verso un operatore o un aggregatore, a volte via HTTP verso un fornitore, rispettando la frequenza e la finestra della connessione.
• Raccogliere le ricevute e abbinarle ai messaggi, così che “consegnato”, “fallito” o “scaduto” arrivi al cliente e al registro.
• Fatturare: addebitare il cliente per ogni messaggio, registrare il costo della rotta e mostrare il margine.
• Produrre report per il cliente e per chi gestisce il gateway.

Il gateway può essere un singolo motore (Kannel è quello open source più noto; gestisce bind, code e ricevute e nulla al di sopra) oppure una piattaforma completa in cui il motore è un livello sotto un portale, una tabella di instradamento, tre modelli di fatturazione e uno stack di reportistica. La pagina della piattaforma disegna quello stack completo di Smppcube in un solo diagramma: NGINX, la console PHP e la pipeline Node.js, le code Redis, MySQL come sistema di registrazione, MongoDB per gli archivi, Elasticsearch per la ricerca e, alla base, Kannel che dialoga con gli SMSC. Tutto questo insieme è “il gateway SMS”. Kannel da solo è il motore di consegna.

Un gateway porta con sé anche le parti del business che non hanno nulla a che vedere con i protocolli: account cliente, listini per destinazione, saldi prepagati e postpagati, fatture, portali per i rivenditori e il margine per rotta che decide se l’attività guadagna. Sono queste parti a rendere l’acquisto di un gateway una decisione diversa dallo scaricare un motore.

Server SMPP: la porta a cui si collegano i Suoi clienti

SMPP, il protocollo su cui gli operatori si sono standardizzati, è un protocollo client-server. Quando il Suo gateway fa un bind verso un operatore, il lato dell’operatore è il server SMPP e il Suo è il client. Quando i Suoi clienti vogliono fare un bind verso di Lei via SMPP, il server deve essere Lei. Quel componente è il server SMPP: resta in ascolto su una porta (la 2775 per convenzione), autentica i bind con system_id e password, accetta i pacchetti submit_sm, restituisce gli ID dei messaggi, applica il throughput previsto per ciascun account e rimanda le ricevute di consegna lungo la sessione.

In altre parole, è un’ulteriore via d’ingresso nel gateway. I messaggi che arrivano tramite il server SMPP entrano nella stessa coda, nella stessa tabella di instradamento e nello stesso registro dei messaggi provenienti dall’API HTTP e dalla console; la guida SMPP vs HTTP spiega perché una piattaforma ha bisogno di entrambi e in che cosa differiscono nella pratica. Ciò che un server SMPP non è, invece, è una rotta verso i telefoni: è una porta d’ingresso, non d’uscita. Un’azienda che deve solo inviare non ne ha mai bisogno. Un’azienda che vuole come clienti banche, fornitori di OTP e altri aggregatori ne ha bisogno il giorno in cui il primo di loro lo chiede.

Come si collegano i tre nel percorso reale di un messaggio

Metta insieme i tre, e un messaggio che va dal cliente di un rivenditore a un telefono segue questo percorso:

1. Il cliente invia il messaggio al gateway del rivenditore, tramite la console web, l’API HTTP o un bind verso il server SMPP del rivenditore.
2. Il gateway lo convalida, scala l’importo dal saldo del cliente e sceglie una rotta per la destinazione.
3. Il motore del gateway lo invia tramite un bind SMPP (o una chiamata HTTP) a un aggregatore o direttamente all’operatore di destinazione.
4. L’SMSC dell’operatore memorizza il messaggio, trova il telefono e lo consegna.
5. L’SMSC restituisce una ricevuta di consegna lungo la stessa catena; il gateway la abbina al messaggio, chiude la contabilizzazione nel registro e la inoltra al cliente (come deliver_sm sul suo bind SMPP o come webhook sulla sua API).

Due osservazioni. Primo: il server SMPP del rivenditore e l’SMSC dell’operatore non dialogano mai tra loro; il gateway in mezzo parla SMPP come client verso monte e come server verso valle, ed è per questo che i termini si confondono. Secondo: lo stesso gateway può essere cliente di più SMSC e aggregatori contemporaneamente, e su questo si fonda l’intero instradamento: il messaggio prende la connessione più economica, migliore o prevista dal contratto per quella destinazione.

Chi gestisce cosa

	SMSC	Gateway SMS	Server SMPP
Dove si trova	All’interno della rete core di un operatore mobile	Su un server controllato dall’azienda (o in affitto come SaaS)	All’interno del gateway, come uno dei suoi punti di ingresso
Chi lo gestisce	Operatori mobili	Imprese, rivenditori, aggregatori, piattaforme CPaaS	Gateway che servono clienti tecnici
Dialoga con	Telefoni (via SS7/Diameter) e gateway collegati	SMSC, aggregatori, fornitori HTTP a monte; clienti a valle	Clienti che si collegano via SMPP
Raggiunge un telefono da solo	Sì	Solo tramite un SMSC	No
Esempi	Sistemi propri degli operatori	Kannel (motore); piattaforme complete come Smppcube	Integrato in una piattaforma, o aggiunto sopra un motore

La nota “in affitto come SaaS” nella colonna del gateway indica l’altra confusione frequente: anche un pannello SMS ospitato è un gateway, uno che gestisce qualcun altro e a cui Lei accede come tenant. La guida al gateway self-hosted offre il confronto onesto tra gestirne uno in proprio e affittare un posto su quello di altri.

Quale di essi deve gestire Lei

Se invia messaggi da una sola applicazione (OTP, avvisi, notifiche) e non ha clienti propri, non Le serve nessuno dei tre. L’API HTTP di un aggregatore è un gateway di cui Lei è cliente; la Sua unica decisione riguarda il fornitore da scegliere.

Se rivende messaggistica, gestisce campagne per conto di altri o gestisce la messaggistica di molti team interni, Le serve un gateway. In affitto o self-hosted è la domanda successiva, e dipende da dati, margine e vincolo al fornitore più che dalla tecnologia; una licenza a pagamento unico come quella di Smppcube sul Suo server è l’estremo self-hosted di questa scelta.

Se tra i Suoi clienti c’è chiunque abbia una libreria client SMPP (banche, fornitori di OTP, piattaforme di marketing, altri aggregatori), il Suo gateway ha bisogno di un server SMPP. Alcune piattaforme lo includono; con un motore di base deve aggiungerlo Lei.

Non Le serve un SMSC. Non può gestirne uno senza essere un operatore, e non ne ha bisogno: l’SMSC di ogni operatore è raggiungibile tramite un bind o un aggregatore. La versione pratica di “ci serve un SMSC” è quasi sempre “ci serve un gateway con un server SMPP e due o tre contratti con operatori”, un problema molto più piccolo e molto più economico.

Nessuno al di fuori di un operatore gestisce un SMSC. Ciò che le aziende gestiscono è un gateway, e ciò a cui si collegano i clienti tecnici è il server SMPP del gateway. Chiarito il vocabolario, l’elenco di ciò che occorre acquistare si definisce da sé.

Una nota sui nomi usati dai fornitori

Poiché nel marketing i termini si sovrappongono, legga l’elenco delle funzionalità anziché l’etichetta. Un prodotto chiamato “software SMSC” che elenca bind SMPP, instradamento e fatturazione è un gateway. Un “server SMPP” che elenca account cliente, listini e un portale è un gateway con un punto di ingresso SMPP. Un “gateway SMS” che è solo un endpoint REST senza tabella di instradamento è l’API di un singolo fornitore. Nessuno di questi è un acquisto sbagliato; il punto è sapere che cosa fa prima di confrontare i prezzi, e verificare, qualunque cosa scelga, che risieda su un server che Lei può raggiungere e che conservi registri che può esportare.