Le SMPP v5.0 est rétrocompatible avec la v3.4 et ajoute la signalisation de contrôle de congestion, les opérations de diffusion (broadcast_sm et consorts), un état de message supplémentaire (SKIPPED) et des TLV additionnels. Malgré cela, la v3.4 reste l'interconnexion dominante car elle est universellement prise en charge ; la v5.0 ne s'emploie que là où les deux pairs l'implémentent.
bind_transceiverOuvrir et authentifier la sessionbind_transceiver_respSession acceptéesubmit_smEnvoyer un messagesubmit_sm_respAccepté, ID du message renvoyédeliver_smAccusé de réception ou message entrantdeliver_sm_respConfirméenquire_linkKeepalive en cas d'inactivité
Ce qu'ajoute la v5.0
La v5.0 est une révision incrémentale et rétrocompatible de la v3.4. Ses ajouts phares sont le contrôle de congestion (le SMSC annonce sa charge pour que les ESME ralentissent avant d'être throttlés), une famille d'opérations de diffusion de type cell-broadcast, un nouvel état de message SKIPPED, et des paramètres optionnels supplémentaires. Le format de PDU de base, le modèle de bind et submit_sm/deliver_sm restent inchangés, ce qui permet à un ESME v3.4 de dialoguer avec un SMSC v5.0.
| Zone | v3.4 | Ajout v5.0 |
|---|---|---|
| Contrôle de la congestion | Aucun (réagir à la limitation de débit) | congestion_state TLV — proactif |
| Diffusion | Non pris en charge | broadcast_sm / query_broadcast_sm / cancel_broadcast_sm |
| États des messages | 8 états | Ajoute SKIPPED (9) |
| Paramètres optionnels | Ensemble TLV v3.4 | TLV supplémentaires |
| interface_version | 0x34 | 0x50 |
Ce qui n'a pas changé
Les fondamentaux sont identiques : l'en-tête de 16 octets, l'encodage big-endian, les trois types de bind, les états de session, le maintien par enquire_link, les dispositions de champ de submit_sm/deliver_sm et la plage d'erreurs ESME_R* sont tous repris. Les TLV — introduits en v3.4 — restent le mécanisme d'extension. Cette continuité est délibérée : la v5.0 a été conçue pour que les intégrations v3.4 existantes continuent de fonctionner.
Quelle version utiliser
Utilisez la v3.4 sauf raison concrète d'employer la v5.0 et si les deux pairs la prennent en charge. La v3.4 est le choix par défaut sûr et universel pour l'interconnexion A2P. Optez pour la v5.0 lorsque vous avez spécifiquement besoin de sa signalisation de congestion ou de ses opérations de diffusion et que le fournisseur en confirme le support. Confirmez toujours la version négociée depuis le bind_resp (le TLV sc_interface_version) plutôt que de supposer qu'une fonction est disponible.
Questions fréquemment posées
Le SMPP v5.0 est-il rétrocompatible avec la v3.4 ?
Oui. La v5.0 préserve le format de PDU, le modèle de bind et les opérations de base de la v3.4, si bien qu'un ESME v3.4 et un SMSC v5.0 peuvent interopérer. La version est déclarée dans interface_version (0x34 vs 0x50).
Pourquoi le SMPP v3.4 reste-t-il la version la plus courante ?
Parce qu'elle est universellement implémentée et couvre entièrement les besoins de la messagerie A2P. Les ajouts de la v5.0 — contrôle de congestion, diffusion — sont utiles dans des scénarios précis mais pas requis pour le trafic MT/MO standard, si bien que la plupart des interconnexions sont restées en v3.4.
Quel est le principal avantage pratique de la v5.0 ?
Le contrôle de congestion proactif : le TLV congestion_state permet au SMSC d'annoncer sa charge pour qu'un ESME coopératif ralentisse avant d'atteindre des erreurs ESME_RTHROTTLED brutales, offrant un débit plus lisse sous pression.
Comment savoir quelle version une session a négociée ?
Lisez le TLV sc_interface_version renvoyé dans le bind_resp. Ne supposez pas que les fonctions v5.0 sont disponibles simplement parce que vous avez envoyé interface_version 0x50 — le SMSC rapporte ce qu'il prend réellement en charge.
Spécifications sources
Les normes publiées sur lesquelles repose cette page. S'ouvre dans un nouvel onglet.