# SMPP 3.4 vs SMPP 5.0: cosa è cambiato e quale versione utilizzare

> SMPP 3.4 (1999) è ancora il protocollo di interconnessione SMS utilizzato oggi in quasi tutte le connessioni A2P in produzione. SMPP 5.0 (2003) ha introdotto intestazioni Unicode-clean, supporto per broadcast e cell-broadcast e TLV per classi di messaggi più ricche, ma la maggior parte degli SMSC e degli aggregatori non è mai passata a questa versione. Se dovete scegliere oggi, utilizzate SMPP 3.4 su TLS a meno che la controparte non richieda espressamente SMPP 5.0.

- URL canonico: https://www.broadnet.me/it/answers/smpp-3-4-vs-5-0
- Lingua: it
- Ultima revisione: 2026-09-30
- Editore: BroadNet (https://www.broadnet.me)

## Perché la versione 3.4 ha vinto in termini di installazioni

SMPP 3.4 è stato rilasciato nello stesso momento in cui SMS A2P ha preso piede. Tutti i principali fornitori di SMSC hanno sviluppato implementazioni 3.4 solide e stabili. Il protocollo è compatto (circa 30 tipi di PDU, otto comandi che si inviano effettivamente), ben compreso e resiste a qualsiasi NAT e firewall. Ventisette anni dopo, la specifica SMPP 3.4 è ancora il protocollo di riferimento in ogni contratto di interconnessione A2P.

## Cosa ha aggiunto la versione 5.0

SMPP 5.0 ha risolto diverse problematiche: supporto nativo per message_payload in UTF-8, un registro service_type adeguato, broadcast_sm / query_broadcast_sm / cancel_broadcast_sm per la trasmissione broadcast delle celle, TLV di fatturazione opzionali e un controllo della congestione più rigoroso con congestion_state. Ha inoltre introdotto il concetto di message_state machines che l'SMSC può gestire per conto dell'ESME.

## Perché quasi nessuno usa la versione 5.0

Tre motivi. Primo, i fornitori di SMSC non sono stati pagati per l'aggiornamento: gli operatori avevano già stack 3.4 funzionanti. Secondo, il caso d'uso di trasmissione cellulare a cui era destinato lo standard 5.0 è stato indirizzato ai centri di trasmissione cellulare (CBC) dedicati, non agli SMSC. Terzo, i problemi risolti dallo standard 5.0 (gestione Unicode, TLV di fatturazione) vengono solitamente risolti a livello applicativo con TLV aggiuntivi rispetto allo standard 3.4. Il risultato: in BroadNet abbiamo un solo binding 5.0 in produzione. Abbiamo oltre 1.000 binding 3.4 attivi.

## Consigli pratici

Effettua il bind come transceiver tramite SMPP 3.4, con TLS sulla porta fornita con il tuo account. Utilizza submit_sm con TLV message_payload per i messaggi lunghi (invece della concatenazione UDH) quando l'SMSC ricevente lo supporta. Negozia enquire_link ogni 30 secondi e disconnettiti correttamente. Se il tuo aggregatore impone SMPP 5.0, chiedi il motivo: non offre alcun vantaggio in termini di deliverability sulle rotte A2P commerciali.

## SMPP 3.4 e SMPP 5.0 in sintesi

|  | SMPP 3.4 | SMPP 5.0 |
|---|---|---|
| Rilascio | 1999 | 2003 |
| Base installata in produzione | Quasi tutti i bind A2P | Raro — poco diffuso |
| Intestazione Unicode nativa | No | Sì |
| Supporto Cell Broadcast | No | Sì |
| controllo della congestione | Di base | Segnalazione congestion_state |
| Vantaggio in termini di consegna | Riferimento | Nessuno sulle rotte A2P commerciali |
| Consigliato oggi | Sì — transceiver su TLS | Solo se richiesto dalla controparte |

## Domande frequenti

### Dovrei utilizzare SMPP 5.0 per una nuova integrazione?

Quasi mai. Utilizza SMPP 3.4 su TLS a meno che una controparte specifica non richieda la versione 5.0. La base installata, gli strumenti e il supporto degli operatori si basano tutti sulla versione 3.4, e la 5.0 non offre alcun vantaggio in termini di deliverability sulle rotte A2P commerciali.

### Il protocollo SMPP 5.0 garantisce una migliore trasmissione dei messaggi rispetto alla versione 3.4?

No. La deliverability dipende dal percorso dell'operatore, non dalla versione SMPP. Le funzionalità migliorate dalla versione 5.0 (intestazioni Unicode, TLV di fatturazione) sono generalmente gestite a livello applicativo, al di sopra della versione 3.4.

### Come faccio a inviare messaggi in arabo o emoji tramite SMPP 3.4?

Imposta data_coding su UCS-2 (0x08) oppure trasporta il corpo in un TLV message_payload. La versione 3.4 gestisce correttamente i contenuti Unicode; non è necessaria la versione 5.0.

### Quale tipo di binding e quale porta devo utilizzare?

Il binding del transceiver su TLS è lo standard per A2P: invia submit_sm e riceve DLR su un unico socket. BroadNet offre connessioni SMPP 3.4; host, porta e credenziali sono forniti con l'accesso di prova.

## Correlati

- [Che cos'è SMPP?](https://www.broadnet.me/it/answers/what-is-smpp)
- [REST vs SMPP](https://www.broadnet.me/it/compare/sms-api-vs-smpp)
- [Codifica GSM-7 vs UCS-2](https://www.broadnet.me/it/answers/what-is-encoding-gsm-7-ucs-2)
- [Tutte le risposte](https://www.broadnet.me/it/answers)
- [Come funziona il protocollo SMPP?](https://www.broadnet.me/it/answers/smpp-protocol)
- [Che cos'è SMPP?](https://www.broadnet.me/it/answers/what-is-smpp)
- [TLS 1.3 nella messaggistica: cosa è cambiato e perché è importante per SMPP](https://www.broadnet.me/it/answers/tls-1-3-in-messaging)
- [SMPP integration](https://www.broadnet.me/it/developers/smpp)
- [SMPP error-code lookup](https://www.broadnet.me/it/tools/smpp-error-codes)
- [SMS API](https://www.broadnet.me/it/products/sms-api)