Skip to main content
Les deux directions — accusés de livraison sortants vers un dlr_url, et messages MO sortants vers un forward.mo.url — partagent un même mécanisme de livraison, et donc partagent ces règles.

​
Les deux règles qui décident de tout

Au budget par défaut, un endpoint injoignable occupe un thread virtuel pendant vingt minutes. Dix tentatives, deux minutes d’écart. Un client dont l’endpoint est en panne pendant une heure ne perd pas seulement des accusés — il retient des threads pendant toute l’heure, et chaque autre client dans le même état aussi.Si vous avez beaucoup de clients avec des endpoints peu fiables, abaissez le nombre de tentatives avant de relever le plafond de threads.

​
Un accusé n’arrive jamais

1

Un dlr_url a-t-il été fourni du tout ?

Via HTTP, il doit être présent et URL-encodé, et dlr doit valoir yes. Définir l’un sans l’autre ne fait rien.
2

L'endpoint est-il joignable depuis l'hôte de la passerelle ?

Pas depuis votre portable — depuis l’hôte ou le conteneur sur lequel tourne la passerelle. La politique de sortie, le split DNS et les sous-réseaux privés mordent tous ici.
3

Renvoie-t-il 200–399 ?

Un 401 derrière un proxy authentifiant est l’échec silencieux le plus fréquent. Idem pour un 302 vers une page de login, qui compte bien comme un succès et avale l’accusé.
4

La passerelle a-t-elle journalisé l'échec ?

Les échecs de transfert et les tentatives sont journalisés. Dix tentatives silencieuses signifient que l’endpoint a répondu.

​
Le piège des placeholders

Au format kannel, le callback est un GET nu avec placeholders substitués — rien n’est ajouté.
Une URL sans placeholders reçoit une requête ne transportant rien du tout — pas de corps, pas de query, pas d’identifiant. L’endpoint est appelé à l’heure prévue, renvoie 200, et le client en conclut que les accusés « fonctionnent mais sont vides ».C’est la plus courante des erreurs d’intégration des accusés, et rien dans le système ne la signale : un callback vide est indiscernable d’un callback correctement configuré qui n’a rien à transporter.

​
Les transferts MO n’arrivent jamais

Les callbacks MO sont en POST, et les mêmes règles 200–399 et tentatives s’appliquent.
  • forward.mo.url est défini sur le worker client SMPP qui reçoit le MO — pas sur le listener, et pas globalement.
  • forward.mo.format vaut JSON ou FORM.
  • L’URL peut porter des placeholders, URL-encodés avant remplacement :
Le détail complet des MO entrants nécessite print.mos = true temporairement. Traitez cette sortie comme sensible : elle contient le contenu du message et les deux adresses.

​
Des accusés qui arrivent mais disent la mauvaise chose

Pas un problème de livraison, et à écarter avant d’aller regarder le réseau :
  • request.dlrs est désactivé sur le fournisseur. Chaque message finit alors en EXPIRED à l’échéance, parce que rien ne signale de résultat. Le taux de livraison devient insignifiant plutôt que nul, ce qui est pire, car un zéro ressemble à un problème et un nombre insignifiant ressemble à une donnée.
  • Un accusé de niveau 1 n’est pas le résultat. ACCEPTD et BUFFRED arrivent tous deux en niveau 1 et un autre accusé suit. Un client qui traite le premier accusé comme final signalera à jamais la mauvaise chose.
  • Trois segments, trois accusés. conf.dlr.multipart vaut all par défaut, donc un client reçoit un accusé par submit_sm qu’il a envoyé. first ou last réduit cela à un seul.

​
Voir aussi

Accusés de livraison

La charge utile, les niveaux et comment corréler.

Qualité des accusés

Taux rapporté par rapport au taux de livraison.