Comment configurer le champ Registered Delivery dans SMPP
Qu'est-ce que le champ Registered Delivery ?
Le champ Registered Delivery dans SMPP est un masque de bits de 1 octet dans les PDU comme submit_sm et data_sm qui contrôle
les accusés de réception et les notifications de livraison. Il permet aux expéditeurs de suivre l'état de livraison des messages via des reçus générés par le SMSC. Ses principales fonctions incluent :
- Demander des accusés de réception finaux (succès/échec)
- Activer les notifications de livraison intermédiaires
- Gérer les accusés de réception des SME (Short Message Entity)
Structure du champ et masque de bits
Défini dans SMPP v3.4, le champ utilise la structure de masque de bits suivante :
| Bit | Description |
|---|---|
| 0 | Reçu de livraison SMSC (0 = désactivé, 1 = activé) |
| 1 | Accusé de réception SME Origine (0 = désactivé, 1 = activé) |
| 2 | Notification intermédiaire (0 = désactivé, 1 = activé) |
| 3-7 | Réservé |
Valeurs courantes
| Valeur (Hex) | Binaire | Description |
|---|---|---|
| 0x00 | 00000000 | Aucun reçu demandé |
| 0x01 | 00000001 | Reçu de livraison SMSC uniquement |
| 0x03 | 00000011 | Reçu SMSC + accusé de réception SME |
| 0x05 | 00000101 | Reçu SMSC + notifications intermédiaires |
Cas d'utilisation
1. Accusés de réception basiques
registered_delivery: 0x01 // Demande le statut final de livraison
2. Messagerie haute fiabilité
registered_delivery: 0x05 // Reçu + notifications intermédiaires
3. Communication bidirectionnelle
registered_delivery: 0x03 // Confirme la livraison SMSC et SME
Exemples de PDU SMPP
Exemple 1 : Aucun reçu (0x00)
0000001D // Longueur de commande (29 octets)
00000004 // ID de commande (SubmitSM)
00000001 // Numéro de séquence
00 // TON source
00 // NPI source
736F7572636500 // Adresse source ("source")
00 // TON destination
00 // NPI destination
36353433323100 // Adresse destination ("654321")
00 // Classe ESM
00 // ID de protocole
00 // Indicateur de priorité
00 // Heure de livraison planifiée
00 // Période de validité
00 // Registered Delivery (0x00 : Aucun reçu)
00 // Remplacer si présent
00 // Codage des données (DCS=0x00)
00 // ID de message par défaut
07 // Longueur du message (7 septets)
C8329BFD06DDDF72 // Charge utile ("Hello!")
Exemple 2 : Reçu de livraison SMSC (0x01)
0000001D // Longueur de commande (29 octets)
00000004 // ID de commande (SubmitSM)
00000002 // Numéro de séquence
...
00 // Période de validité
01 // Registered Delivery (0x01 : Reçu SMSC)
00 // Remplacer si présent
...
Exemple 3 : Notifications intermédiaires (0x05)
0000001D // Longueur de commande (29 octets)
00000004 // ID de commande (SubmitSM)
00000003 // Numéro de séquence
...
05 // Registered Delivery (0x05 : Reçu SMSC + intermédiaires)
...
Format des accusés de réception
Les SMSC renvoient les reçus via des PDU deliver_sm avec une charge utile formatée comme suit :
id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:STATUS err:EEE
Exemple de reçu pour un message livré :
id:1896384752 sub:001 dlvrd:001 submit date:2310151430 done date:2310151431 stat:DELIVRD err:000
Interactions avec d'autres champs
- esm_class : Le bit 6 (indicateur de reçu de livraison) doit correspondre aux paramètres de registered_delivery
- validity_period : Détermine combien de temps le SMSC tentera la livraison avant d'envoyer un reçu d'échec
- message_id : Essentiel pour corréler les reçus avec les messages originaux
Pièges courants
- Activer les reçus mais ne pas écouter les PDU
deliver_sm - Supposer que tous les SMSC prennent en charge les accusés de réception SME (0x02)
- Incompatibilité entre les indicateurs
registered_deliveryetesm_class - Ignorer les limites de taux du SMSC pour la génération de reçus
Certains fournisseurs facturent des frais supplémentaires pour les accusés de réception. Confirmez les tarifs avant activation.
Conclusion
Le champ Registered Delivery est essentiel pour suivre le statut de livraison des SMS dans SMPP. Bien que la gestion basique des reçus (0x01) soit largement supportée,
les fonctionnalités avancées comme les notifications intermédiaires nécessitent des tests spécifiques au SMSC. Implémentez toujours un analyseur robuste des reçus et corrélez les messages
en utilisant message_id. Pour un comportement détaillé, consultez la section 5.2.17 de SMPP v3.4 et la documentation de votre fournisseur.