Skip to main content
C’est l’échec qui fait perdre le plus de temps, car un fournisseur qui refuse chaque message paraît parfaitement en bonne santé : les sessions sont en service, la file se vide, acceptsMessages() est vrai. Le message est accepté, routé, soumis, refusé, remis en file, puis abandonné à outSms.routing.maxAttempts — et l’abandon dit reason=maxAttempts, ce qui décrit le symptôme plutôt que la cause.

​
Où se trouve réellement la cause

message.submit.response, qui transporte le command_status du fournisseur :
La même valeur est sur la carte du fournisseur dans le panneau et sur /ops/health en tant que last_submit_error, avec submit_rejected qui les compte — donc une ligne qui refuse tout est visible sans lire un seul log.

​
Ce que signifient les codes courants

La passerelle porte la table complète, et écrit la phrase en anglais clair à côté de chaque code qu’elle reconnaît. Un code hors de cette table est journalisé comme vendor-specific, délibérément : les fournisseurs utilisent effectivement les leurs, et inventer un nom vous enverrait chercher une entrée de spec qui n’existe pas.

​
Le bloc 192–196 concerne toujours les TLVs

Si une ligne se met à tout refuser avec un de ces cinq, regardez les TLVs du message, pas le routage. Trois choses les fournissent, composées dans cet ordre :
1

Le default.tlvs.submit propre au fournisseur

outSms.instance.<name>.default.tlvs.submit
2

Le defaultTlvs du credential

Valeurs par client.
3

Le tampon de whitelist

Pour un en-tête d’expéditeur ou un template approuvé.
La cause la plus fréquente est la troisième. Rien d’approuvé signifie rien de tamponné, donc une ligne DLT reçoit un submit sans ID d’entité ni de template et le refuse. tlvCount=0 sur les lignes de trace le confirme. La deuxième plus fréquente est un défaut mal formé. Le format est <name>_<tag>=<value> — écrire PEID=1101778070000018542 au lieu de peid_0x1400=1101778070000018542 se parse en rien, et le TLV est ignoré avec seulement un WARN :
Un défaut mal formé est le plus difficile à voir de ces cas, parce que le réglage paraît appliqué. Il est présent dans la configuration, la passerelle a démarré proprement, et la seule preuve qu’il n’a rien fait est un WARN au chargement et un tlvCount plus bas que prévu.

​
Un fournisseur, bien plus de submits que ce que vous avez configuré

Si un fournisseur signale bien plus de submits rejetés que vous n’avez envoyé de messages, les deux plafonds de retry se composent : le budget de retry propre à un fournisseur est dépensé à l’intérieur d’une tentative de routage, et un refus renvoie le message au routeur, qui a son propre plafond de tentatives. Avec un seul fournisseur configuré, le re-routage le renvoie directement et dépense un nouveau budget.
Surveillez submit_rejected par rapport à submitted sur la carte du fournisseur. Un ratio bien au-dessus de un est ce compoundage, pas un problème de fournisseur — et il vaut la peine d’être détecté, car chacun de ces PDUs est du trafic que votre opérateur voit.

​
Voir aussi

TLVs en pratique

D’où vient un tag et ce qui surcharge quoi.

Files et tentatives

Plafonds de tentatives, backoff et coût d’une remise en file.