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.
I have the same issue, I have a ticket with support:
SMPP account that correctly accepts bind_transceiver and bind_receiver on sbg.smpp.ovh:2776.
When a recipient replies to an SMS sent with shortcode 38082, the inbound SMS is counted in the Manager, but no deliver_sm is sent. Instead, the SMSC itself closes the TLS session (close_notify, then TCP FIN).
The behavior is reproduced with Kannel 1.4.5, a client explicitly listed as tested in your documentation, as well as with an independent Python SMPP client. A TCP capture confirms that the FIN is initiated by 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, opened on 02/08, I noticed the issue in July but I thought they would fix a bug like this on their own… because if we are in transceiver mode we lose incoming SMS, okay, but then the transceiver is closed and the SMS can no longer be sent out, so we are forced to request an alphanumeric code to block the replies, and they refuse the portability of your already validated alphanumeric codes on your other SMS accounts; you have to create a new file… It’s insane.
Response I received on 06/08/26 on the ticket:
On my side, I have identified a malfunction that is being escalated internally. I invite you to wait for its resolution, apologizing for the inconvenience caused.
