Nous avons récemment intégré une connexion SMPP vers l’infrastructure SMS OVH et nous rencontrons un comportement que nous aimerions clarifier concernant la réception des MO et des Delivery Receipts.
🔧 Configuration actuelle
Protocole : SMPP v3.4
Mode : bind_transceiver
Ports testés :
Port standard (non TLS)
Port sécurisé TLS (fonctionnel)
Enquire_link toutes les 10 secondes
Reconnexion automatique en cas de déconnexion
📤 Envoi
submit_sm fonctionne correctement
message_id bien retourné
registered_delivery = 1 activé
Encodage GSM 7-bit ou UCS-2 selon contenu
Aucun problème côté envoi.
📥 Réception
Nous écoutons les deliver_sm :
esm_class = 4 ou présence de receipted_message_id → traité comme Delivery Receipt
Sinon → traité comme SMS entrant (MO)
Nous répondons systématiquement par deliver_sm_resp (command_status = 0).
❓ Problème rencontré
Nous recevons :
Très peu (voire aucun) Delivery Receipts
Très peu (voire aucun) SMS entrants (MO)
Alors que :
Les SMS sont bien envoyés
registered_delivery = 1 est bien positionné
La session SMPP est stable
Le bind_transceiver est accepté
🔍 Questions
La réception des MO nécessite-t-elle une activation spécifique côté OVH ?
Les Delivery Receipts sont-ils activés par défaut ou doivent-ils être configurés sur le compte ?
Le routage des MO et DLR vers une session bind_transceiver nécessite-t-il une configuration particulière ?
Existe-t-il une différence de comportement entre bind_transceiver et bind_receiver + bind_transmitter séparés ?
Si certains d’entre vous utilisent SMPP avec OVH pour gérer MO + DLR, je serais preneur de vos retours d’expérience.
Je m'aperçois que votre demande très documentée n'a pas encore reçu de retour de la part de nos membres. Je me permets de vous solliciter pour savoir si ce défaut de réception des MO et des accusés de réception (DLR) via votre bind SMPP est toujours d'actualité ?
Si c'est le cas, votre configuration semble pourtant robuste. Pour aider la communauté à isoler le point de blocage, pourriez-vous préciser :
Si vous avez vérifié dans votre Espace Client OVHcloud (section SMS > Configuration) que le routage des réponses est bien configuré pour pointer vers votre interface SMPP ?
Si vous utilisez un expéditeur (Sender ID) personnalisé ? (Certains opérateurs filtrent les DLR/MO selon le type d'expéditeur utilisé).
Note technique : Chez OVHcloud, le mode bind_transceiver est bien supporté, mais il arrive parfois que la séparation en deux sessions distinctes (bind_transmitter et bind_receiver) stabilise la réception des flux entrants sur certaines piles logicielles.
j'ai le même soucis j'ai un ticket au support :
Compte SMPP qui accepte correctement bind_transceiver et bind_receiver sur sbg.smpp.ovh:2776.
Lorsqu’un destinataire répond à un SMS envoyé avec le shortcode 38082, le SMS entrant est comptabilisé dans le Manager, mais aucun deliver_sm n’est envoyé. À la place, le SMSC ferme lui-même la session TLS (close_notify, puis TCP FIN).
Le comportement est reproduit avec Kannel 1.4.5, client explicitement listé comme testé dans votre documentation, ainsi qu’avec un client SMPP Python indépendant. Une capture TCP confirme que le FIN est initié par 5.135.112.100.
Test Kannel 1.4.5, bind_transceiver :
ERROR: SMPP[ovh-diagnostic]: I/O error or other error. Re-connecting.
La capture TCP prise au même instant montre :
5.135.112.100:2776 > 51.75.XX.XX:35392 Flags [F.]
OVH initie donc la fermeture TCP. Aucun PDU deliver_sm n’a été reçu ou journalisé avant cette fermeture.
Test Kannel 1.4.5, bind_receiver :
type_name: bind_receiver_resp
command_status: 0 = 0x00000000
Puis :
ERROR: SMPP[ovh-receiver-diagnostic]: I/O error or other error. Re-connecting.
Et la capture TCP correspondante :
5.135.112.100:2776 > 51.75.XX.XXXX:34348 Flags [F.]
Là encore, le bind est accepté, aucun deliver_sm n’est reçu, puis OVH ferme la session TLS/TCP.
Ticket CS16424028 , ouvert le 02/08 , j'ai vu le souci en juillet mais j'ai cru qu'ils corrigeraient un bug pareille seul... car si on est en mode transiver on pert les SMS entrant, ok, mais du coup le transiver est fermé et les sms ne peuvent plus sortir, et alors la obligé de demander un code alphanumérique pour bloquer les réponses, et ils refusent la portabilité de vos codes alpha déjà validés sur vos autres comptes SMS, faut refaire un dossier... C'est fou.
Réponse que j'ai reçu le 06/08/26 sur le ticket :
De mon côté, j'ai bien identifié un dysfonctionnement qui fait l'objet d'une escalade en interne.Je vous invite à patienter le temps de sa résolution, en m'excusant pour la gêne occasionnée.
