# Che cos’è SMPP? Il protocollo di sessione per gli SMS SMPP è il protocollo con cui una piattaforma scambia messaggi brevi con un centro messaggi tramite una sessione persistente. Un bind dichiara la direzione, la sessione prevede una finestra di throughput e le ricevute di consegna tornano come PDU. Non è un’API a richiesta e risposta. - SMPP è una sessione persistente con una direzione di bind dichiarata. - Un bind prevede un’assegnazione di throughput e una finestra di richieste in sospeso. - Un PDU ha un’intestazione di 16 byte e un corpo specifico del comando. - Le ricevute di consegna arrivano in modo asincrono sulla sessione; vanno abbinate tramite l’ID del messaggio. ## Una sessione, non una chiamata SMPP mantiene aperta una connessione tra la piattaforma del cliente e un centro messaggi. La piattaforma si autentica una sola volta, dichiara che cosa intende fare e poi invia messaggi e riceve eventi sulla stessa sessione. Il centro messaggi non attende una nuova richiesta per inviare una ricevuta o un messaggio in entrata: invia un PDU quando ha qualcosa da segnalare. Questa forma si adatta a un flusso costante. L’overhead per messaggio è ridotto perché lo stato della sessione è già stabilito e il canale delle ricevute è già aperto. Significa anche che il client gestisce uno stato che un client HTTP non gestisce: stato del bind, finestra delle richieste in corso, tempi di keep-alive e comportamento di riconnessione. ## I bind dichiarano una direzione Un bind è la sessione autenticata più una direzione. Un bind transmitter invia messaggi. Un bind receiver riceve messaggi originati dal mobile e ricevute. Un bind transceiver svolge entrambe le funzioni su una sola sessione. Il provider rilascia le credenziali per ciascun bind e può limitare il numero di bind che è possibile aprire. Si scala aggiungendo bind, non spingendo un bind oltre la sua assegnazione. Un bind prevede un’assegnazione di throughput e una finestra di richieste in sospeso. Se il picco richiede di più, conviene chiedere un altro bind e distribuire il traffico. Un singolo bind spinto oltre la sua finestra produce throttling, timeout e nuovi tentativi che sembrano un guasto di rete ma hanno origine nel client. ### Bind, invio, ricevuta La sessione si apre una volta; ogni invio riceve una risposta con un ID del messaggio; la ricevuta arriva più tardi sulla stessa sessione. Alt: Una sequenza dall’applicazione a una richiesta di bind, al centro messaggi, a una risposta all’invio e a una ricevuta di consegna. L’applicazione apre un bind e il centro messaggi risponde. L’applicazione invia un messaggio breve con submit_sm e riceve submit_sm_resp con un ID del messaggio. Più tardi, il centro messaggi invia un PDU deliver_sm che contiene la ricevuta di consegna. L’applicazione ne conferma la ricezione con deliver_sm_resp. Un unbind chiude la sessione al termine del lavoro. | Item | Value | Note | | --- | --- | --- | | Primo stato · 1 | Applicazione (ESME) | | | Primo stato · 2 | bind_transceiver | Aprire la sessione | | Primo stato · 3 | SMSC | | | Primo stato · 4 | submit_sm_resp | Accettato per la consegna | | Primo stato · 5 | Ricevuta di consegna | | Source: smpp.org: sessioni SMPP e operazioni sui PDU (https://smpp.org/) ## La finestra è il contratto La finestra è il numero di richieste che il client può avere in sospeso prima di attendere le risposte. Non è un suggerimento. Se si inviano più richieste di quante la finestra ne consenta, il centro messaggi applica il throttling; se si continua a ripetere allo stesso ritmo, la coda cresce. Occorre leggere il codice di risposta di ogni invio, rallentare in caso di throttling e lasciare svuotare la finestra prima del picco successivo. Il traffico di keep-alive mantiene aperta la sessione. Un client che non invia mai enquire_link può restare su una connessione interrotta finché il primo invio non fallisce. Un client che si riconnette subito dopo ogni interruzione può sovraccaricare il provider. Conviene usare un backoff, limitare la frequenza di riconnessione e generare un avviso quando il bind resta fuori servizio più a lungo di quanto il traffico possa tollerare. ### Un PDU, campo per campo L’intestazione è fissa; il corpo dipende dal comando. Un submit_sm contiene indirizzi, codifica e un flag di ricevuta. Alt: Un PDU submit_sm decodificato con lunghezza del comando, ID del comando, stato, numero di sequenza e campi del corpo. Ogni PDU inizia con una lunghezza del comando di quattro byte, un ID del comando di quattro byte, uno stato del comando di quattro byte e un numero di sequenza di quattro byte. Segue il corpo. Per submit_sm contiene gli indirizzi di origine e di destinazione, il messaggio breve, la codifica dei dati e il flag di consegna registrata. I parametri opzionali viaggiano come campi tag-length-value. | Item | Value | Note | | --- | --- | --- | | command_length | 53 | | | command_id | 0x00000004 | | | command_status | 0x00000000 | | | sequence_number | 1 | | | service_type | | | | source_addr_ton | 1 | | | source_addr_npi | 1 | | | source_addr | 12345 | | | dest_addr_ton | 1 | | | dest_addr_npi | 1 | | | destination_addr | 15551234567 | | | esm_class | 0x00 | | | protocol_id | 0x00 | | | priority_flag | 0 | | | schedule_delivery_time | | | | validity_period | | | | registered_delivery | 0x01 | | | replace_if_present_flag | 0x00 | | | data_coding | 0x00 | | | sm_default_msg_id | 0x00 | | | sm_length | 4 | | | short_message | 54657374 | | | Testo | Test | | Source: Specifica SMPP v3.4, intestazione PDU e submit_sm (https://smpp.org/SMPP_v3_4_Issue1_2.pdf) ## Una giornata nella vita di un messaggio Il client apre un bind transceiver e legge la risposta al bind. Invia un messaggio e memorizza l’ID del messaggio contenuto nella risposta. Il centro messaggi instrada il messaggio verso la rete di destinazione. Alcuni minuti dopo arriva un PDU deliver_sm con la ricevuta: l’ID del messaggio originale, uno stato e spesso un codice di rete. Il client conferma la ricezione della ricevuta e riconcilia lo stato con il proprio record. Ogni passaggio ha una propria modalità di errore. Un bind può essere rifiutato per credenziali errate o per una versione dell’interfaccia non corretta. Un invio può essere sottoposto a throttling, rifiutato, oppure accettato e poi fallire nella ricevuta. Una ricevuta può arrivare dopo la scadenza del codice. Il client va progettato per memorizzare l’ID del messaggio, accettare una ricevuta tardiva e lasciare che lo stato dell’applicazione resti la fonte di riferimento per ciò che l’utente ha fatto. Il decodificatore viene eseguito nel browser; la ricevuta incollata resta lì. [Open the tool](/it/tools/smpp-decoder/?src=learn-what-is-smpp&scenario=dlr-example&sample=id%3A0123456789+sub%3A001+dlvrd%3A001+submit+date%3A2610181200+done+date%3A2610181201+stat%3ADELIVRD+err%3A000+text%3AYour+code+is+123456) ### Decodificare una ricevuta prima di analizzare una rotta Incollare una ricevuta di consegna nel [decodificatore SMPP e DLR](/it/tools/smpp-decoder/) e leggerne i campi. Verificare l’ID del messaggio, lo stato, la data di completamento e il codice di errore. Se lo stato non è DELIVRD, il codice di errore, letto in base alla tabella dei codici del provider, può indicare se il messaggio è stato rifiutato dal numero, dal terminale o dalla rete. Farlo prima di chiedere al provider di cambiare la rotta. ## Ricevute e debug Una ricevuta è asincrona. Arriva sulla sessione come PDU deliver_sm e il suo formato dipende dal centro messaggi. Le implementazioni più recenti riportano lo stato in un campo tag-length-value message_state. Quelle meno recenti inseriscono una ricevuta testuale nel campo del messaggio breve, con coppie chiave-valore come id, stat ed err. Conviene analizzare entrambi i formati anziché presumerne uno. L’abbinamento va fatto tramite l’ID del messaggio, non in base all’ordine di arrivo. Due messaggi inviati a un secondo di distanza possono tornare in ordine inverso, e una ripetizione può produrre un duplicato. Memorizzare l’ID al momento dell’invio, aggiornare il record all’arrivo della ricevuta e ignorare una seconda ricevuta per lo stesso ID, a meno che il suo stato non sia più recente. La [guida alla connessione](/it/resources/guides/smpp-http-connection/) trasforma questi principi in una sequenza operativa. ### Check what you learned **Perché un secondo bind è più utile di una frequenza di ripetizione più alta?** Un bind prevede una sola finestra. Aggiungere un bind aggiunge capacità; ripetere su una finestra piena aggiunge coda e ritardo. **Da dove proviene l’ID del messaggio?** Lo restituisce il centro messaggi in submit_sm_resp. Va memorizzato per abbinare la ricevuta successiva tramite quell’ID. **Che cosa dimostra una ricevuta di avvenuta consegna?** Che la rete ha accettato il messaggio e lo ha consegnato sul percorso verso il terminale. Non dimostra che una persona lo abbia letto. ## FAQ **Serve SMPP per iniziare?** No. HTTP si integra in un pomeriggio; SMPP diventa conveniente quando un volume costante giustifica una sessione. **Che cos’è un bind?** Una sessione persistente con una direzione dichiarata: transmitter, receiver o transceiver. Prevede un’assegnazione di throughput e resta aperta grazie agli scambi di keep-alive. **Che cos’è un PDU?** Protocol Data Unit: il messaggio binario che SMPP scambia. Ogni PDU ha un’intestazione di 16 byte e un corpo specifico del comando. **È possibile usare SMPP sulla rete Internet pubblica?** Spesso sì, con TLS e un elenco di IP autorizzati, ma conviene chiederlo al provider. Alcune implementazioni usano invece una connessione privata. **Come vengono gestiti i messaggi lunghi?** Come segmenti concatenati con un user data header, oppure come TLV message payload che la rete segmenta. Verificare il risultato sul terminale. ## Sources - [smpp.org: sessioni SMPP, operazioni di bind e ricevute di consegna](https://smpp.org/) — Accessed: 2026-10-19 - [Specifica SMPP v3.4, Issue 1.2](https://smpp.org/SMPP_v3_4_Issue1_2.pdf) — Accessed: 2026-10-19 - [3GPP TS 23.040: realizzazione tecnica del servizio SMS (Short Message Service)](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19 Updated: 2026-10-19