Skip to main content
La grammaire est à Déclarations TLV. Lisez cela d’abord si 1400 contre 0x1400 vous est nouveau. Cette page porte sur leur exploitation.

​
Un tag peut venir de quatre endroits

1

Le submit_sm du client

Extrait seulement si le registered.tlvs.submit du listener le déclare. Les tags non déclarés sont écartés, pas transmis.
2

Les defaultTlvs de son credential

Remplissent les tags que le message n’a pas portés.
3

L'estampille de la whitelist

En mode assign, remplit un tag qui manque au message. En mode replace, écrase ce que le client a envoyé — et cet écrasement est l’approbation.
4

Les default.tlvs.submit du vendor

Remplit tout ce qui est encore non défini au moment de l’envoi.
La priorité est message > credential > vendor. Les défauts ne font que combler des lacunes. La seule exception est l’estampille de whitelist en mode replace, qui est censée gagner.

​
Deux vérifications obligatoires, à des points différents

La vérification du vendor tourne après que registered.tlvs.submit a filtré. Exiger un tag qui n’est pas aussi enregistré ne peut jamais être satisfait — le gateway avertit de cet appariement au chargement, et il vaut la peine de lire le log après l’ajout d’un tag obligatoire.

​
Savoir ce qui manquera avant que cela n’arrive

Le rapport de couverture TLV du panneau de contrôle indique, par ligne approuvée, quels tags obligatoires rien ne fournira. Ce rapport est ce qui rend le mode d’estampillage par défaut (off) découvrable plutôt que simplement silencieux. Défaut à assign commencerait à écrire des TLV sur des paquets traversant des listeners qui n’en ont jamais écrit. Un changement silencieux de ce qui atteint un opérateur.

​
L’échec qui s’est réellement produit

Tous les paramètres ne sont pas lus par listener. Un qui ne l’est pas garde sa forme nue et lit un global que personne ne définit — donc il retourne son défaut codé quoi que vous configuriez.whitelist.tlvs.replace a été livré ainsi une fois. Il lisait false sur chaque listener quelle que soit sa configuration, donc les TLV d’un template approuvé n’étaient jamais estampillés en SMPP — silencieusement, parce que ne pas estampiller ressemble exactement à n’avoir rien à estampiller.Si un paramètre TLV par-listener semble ne rien faire, c’est la première chose à vérifier.

​
Le côté du client

Un client peut voir les TLV qu’il a envoyés sur ses propres messages, et peut proposer de nouvelles définitions de tags qu’un opérateur approuvera. Il ne voit jamais ce qu’un vendor a ajouté en aval. L’enregistrement d’appel conserve trois ensembles — reçus, envoyés, et ce que la whitelist a estampillé — de sorte qu’un litige sur ce qui a atteint l’opérateur ait une réponse plutôt que d’être argumenté.

​
Un cas travaillé : DLT indien

L’identifiant d’entité enregistrée appartient au credential, parce que c’est une propriété du client plutôt que d’un message :
L’id du template varie par message et est habituellement estampillé par la whitelist à l’approbation, ou fourni par le client :
Avec les deux obligatoires, un message qui ne résout ni l’un ni l’autre est refusé à l’entrée avec 0xC3 plutôt que rejeté par l’opérateur plus tard — ce qui est le but de vérifier tout court.