Checklist d'intégration SMPP

Choisissez le bon mode de bind selon le sens de votre trafic et confirmez la version de protocole négociée avant d'envoyer le moindre message.

• Confirmer la version SMPP — v3.4 pour la plupart des routes, v5.0 là où le fournisseur prend en charge l'état de congestion et les TLV enrichis.La v5.0 est rétrocompatible ; ne supposez pas les fonctionnalités disponibles tant que le bind_resp ne l'a pas confirmé.
• Choisir le bon type de bind par session.transmitter (MT uniquement), receiver (DLR/MO uniquement), ou transceiver (les deux sur une session). Préférez transceiver pour réduire de moitié le nombre de connexions là où le fournisseur le permet.
• Définir system_id, password, system_type et address_range exactement comme provisionnés.Un address_range mal renseigné bloque silencieusement le routage MO/DLR sur les binds receiver.
• Convenir par écrit avec le fournisseur du nombre de binds simultanés et du TPS par bind.Ouvrir plus de binds que provisionné est la cause la plus fréquente d'un compte throttlé ou coupé.
• Gérer explicitement les codes de statut du bind_resp — réessayer sur ESME_RALYBND et ralentir sur ESME_RBINDFAIL.Ne bouclez jamais en boucle serrée sur un bind échoué ; utilisez un backoff exponentiel avec jitter.

• Définir correctement source_addr_ton / source_addr_npi et dest_addr_ton / dest_addr_npi pour les sender ID alphanumériques vs numériques.Sender alphanumérique → TON 5 (alphanumeric) ; MSISDN international → TON 1, NPI 1.
• Choisir le bon data_coding : GSM 7 bits (0), 8 bits (4), ou UCS-2 (8) pour l'Unicode.Mélanger les encodages sans régler data_coding provoque du mojibake et une mauvaise segmentation.
• Implémenter la concaténation des messages longs via UDH ou les TLV optionnels SAR (sar_msg_ref_num, sar_total_segments, sar_segment_seqnum).Choisissez une méthode et restez-y cohérent ; certaines routes rejettent l'UDH, d'autres les TLV SAR.
• Demander les accusés de réception avec registered_delivery = 1 uniquement là où vous les exploitez.Demander des DLR que vous ne traitez pas gaspille du débit et peut déclencher des avertissements côté fournisseur.
• Respecter la sémantique de validity_period et schedule_delivery_time selon votre cas d'usage (OTP = validité courte).Les OTP de courte durée doivent porter une validity_period serrée afin que les messages périmés ne soient pas livrés en retard.

• message_payload — pour les charges utiles qui dépassent la limite du champ short_message.Ne remplissez pas à la fois short_message et message_payload ; les fournisseurs rejettent cela.
• TLV sar_* — concaténation standardisée sans octets UDH dans le corps.
• dest_addr_subunit / source_addr_subunit — là où la route l'exige pour le routage vers le téléphone.
• Ne transporter les métadonnées fournies par le client que dans des TLV approuvés par le fournisseur.Les TLV personnalisés hors de la plage convenue sont fréquemment supprimés ou provoquent des erreurs d'analyse en aval.

Les accusés de réception arrivent sous forme de PDU deliver_sm et constituent l'ossature de votre réconciliation et de votre reporting qualité.

• Analyser l'accusé depuis le champ short_message du deliver_sm : id, sub, dlvrd, date de soumission, date d'achèvement, stat, err.Le champ `stat` (DELIVRD, UNDELIV, EXPIRED, REJECTD, etc.) est votre statut final.
• Corréler les DLR à votre soumission via le format message_id du fournisseur, pas seulement le texte de l'accusé.Le message_id peut être renvoyé en hexadécimal dans le submit_resp mais en décimal dans le DLR — normalisez les deux.
• Traiter les accusés intermédiaires (non finaux) séparément des états finaux.Le bit 0x04 de l'esm_class marque un accusé de réception ; seules les valeurs `stat` finales doivent clore un message.
• Toujours renvoyer un deliver_sm_resp — un DLR non acquitté est renvoyé et peut bloquer la fenêtre.Répondez rapidement même si le traitement en aval est asynchrone.
• Faire correspondre les codes d'erreur des opérateurs à une taxonomie normalisée (abonné absent, téléphone occupé, bloqué comme spam, numéro invalide).Les codes d'erreur bruts varient selon la route ; une taxonomie normalisée rend la qualité comparable d'une route à l'autre.

• Envoyer enquire_link sur une minuterie d'inactivité (typiquement 30 à 60 s) et traiter un enquire_link_resp manquant comme une session morte.C'est le seul moyen fiable de détecter une connexion TCP à moitié ouverte.
• Implémenter la fenêtre SMPP : plafonner les PDU non acquittés en attente et suspendre les soumissions quand la fenêtre est pleine.Envoyer des submit_sm au-delà de la fenêtre sans discernement est ce qui déclenche ESME_RTHROTTLED.
• Ralentir sur ESME_RTHROTTLED (0x58) plutôt que réessayer immédiatement.Ajoutez du jitter pour que les tempêtes de reconnexion ne se synchronisent pas entre workers.
• Respecter unbind / unbind_resp pour un arrêt propre ; se reconnecter avec backoff sur les déconnexions inattendues.

• Utiliser SMPP sur TLS là où le fournisseur le propose ; désactiver les binds en clair en production.Le SMPP n'a pas de chiffrement natif — le TLS est le contrôle au niveau de la couche transport.
• Épingler ou valider la chaîne de certificats du serveur et imposer TLS 1.2 ou supérieur.Rejetez les certificats expirés ou auto-signés ; ne désactivez pas la vérification « pour que ça marche ».
• Restreindre les binds à des IP source autorisées des deux côtés.L'allow-listing d'IP est un contrôle opérateur standard et un moyen rapide de contenir les fuites d'identifiants.
• Faire tourner les identifiants SMPP sur un calendrier et les stocker dans un gestionnaire de secrets, jamais dans le code.

• Envoyer vers un MSISDN de test en direct sur chaque route cible et confirmer la réception sur le téléphone de bout en bout.
• Vérifier l'aller-retour du DLR pour les issues livré, non livré, expiré et rejeté.
• Tester les messages longs (multi-segments) et le contenu Unicode (UCS-2) sur chaque route.
• Effectuer un test de charge au TPS provisionné et confirmer un comportement propre au plafond de fenêtre/throttle.
• Simuler une connexion coupée en milieu de fenêtre et confirmer une reconnexion propre sans double soumission.L'idempotence en cas de réessai évite la double facturation et la livraison en double sur le téléphone.
• Confirmer le monitoring : état du bind, occupation de la fenêtre, latence submit/DLR, et taux de codes d'erreur, tous alertants.