SMPP v5.0 è retrocompatibile con la v3.4 e aggiunge la segnalazione di controllo della congestione, le operazioni di messaggistica broadcast (broadcast_sm e affini), uno stato del messaggio aggiuntivo (SKIPPED) e ulteriori TLV. Nonostante ciò, la v3.4 resta l'interconnessione dominante perché è supportata universalmente; la v5.0 si usa solo quando entrambi i peer la implementano.
bind_transceiverAprire e autenticare la sessionebind_transceiver_respSessione accettatasubmit_smInviare un messaggiosubmit_sm_respAccettato, ID messaggio restituitodeliver_smRicevuta di consegna o messaggio in entratadeliver_sm_respConfermatoenquire_linkKeepalive durante l'inattività
Cosa aggiunge la v5.0
La v5.0 è una revisione incrementale e retrocompatibile della v3.4. Le sue aggiunte principali sono il controllo della congestione (l'SMSC segnala il carico affinché gli ESME rallentino prima di essere throttled), una famiglia di operazioni di broadcast per la messaggistica in stile cell-broadcast, un nuovo stato del messaggio SKIPPED e parametri opzionali aggiuntivi. Il formato di base della PDU, il modello di bind e submit_sm/deliver_sm restano invariati, ed è per questo che un ESME v3.4 può dialogare con un SMSC v5.0.
| Area | v3.4 | Aggiunta v5.0 |
|---|---|---|
| Controllo della congestione | Nessuno (reagire al throttling) | congestion_state TLV — proattivo |
| Broadcast | Non supportato | broadcast_sm / query_broadcast_sm / cancel_broadcast_sm |
| Stati del messaggio | 8 stati | Aggiunge SKIPPED (9) |
| Parametri opzionali | Set TLV v3.4 | TLV aggiuntivi |
| interface_version | 0x34 | 0x50 |
Cosa è rimasto invariato
I fondamenti sono identici: l'header di 16 byte, la codifica big-endian, i tre tipi di bind, gli stati della sessione, il keepalive enquire_link, i layout dei campi di submit_sm/deliver_sm e l'intervallo di errori ESME_R* si mantengono tutti. I TLV — introdotti nella v3.4 — restano il meccanismo di estensione. Questa continuità è deliberata: la v5.0 è stata progettata affinché le integrazioni v3.4 esistenti continuassero a funzionare.
Quale versione usare
Usate la v3.4 a meno che non abbiate un motivo concreto per usare la v5.0 e che entrambi i peer la supportino. La v3.4 è l'impostazione predefinita sicura e universale per l'interconnessione A2P. Ricorrete alla v5.0 quando vi serve specificamente la sua segnalazione di congestione o le operazioni di broadcast e il provider ne conferma il supporto. Verificate sempre la versione negoziata dal bind_resp (il TLV sc_interface_version) anziché presumere la disponibilità di una funzionalità.
Domande frequenti
SMPP v5.0 è retrocompatibile con la v3.4?
Sì. La v5.0 preserva il formato della PDU, il modello di bind e le operazioni di base della v3.4, quindi un ESME v3.4 e un SMSC v5.0 possono interoperare. La versione è dichiarata in interface_version (0x34 vs 0x50).
Perché la v3.4 di SMPP è ancora la versione più comune?
Perché è implementata universalmente e copre completamente le esigenze della messaggistica A2P. Le aggiunte della v5.0 — controllo della congestione, broadcast — sono utili in scenari specifici ma non necessarie per il normale traffico MT/MO, quindi la maggior parte delle interconnessioni è rimasta alla v3.4.
Qual è il principale vantaggio pratico della v5.0?
Il controllo proattivo della congestione: il TLV congestion_state permette all'SMSC di segnalare il proprio carico affinché un ESME cooperativo rallenti prima di incorrere in errori ESME_RTHROTTLED severi, offrendo un throughput più uniforme sotto pressione.
Come faccio a sapere quale versione ha negoziato una sessione?
Leggete il TLV sc_interface_version restituito nel bind_resp. Non presumete che le funzionalità della v5.0 siano disponibili solo perché avete inviato interface_version 0x50 — l'SMSC riporta ciò che supporta effettivamente.
Specifiche della fonte
Gli standard pubblicati su cui si basa questa pagina. Si apre in una nuova scheda.