app_header est un sender ID approuvé, comparé sans tenir compte de la casse, limité à un compte et un produit. Sur plusieurs marchés un sender ID commercial est un enregistrement plutôt qu’une chaîne que le client choisit. L’opérateur a approuvé ACMEIN pour une entreprise et s’attend à ce que le trafic qui le porte lui appartienne.
Approuvé n’est pas la même chose que livrable
Une approbation fait deux travaux, et ils échouent indépendamment. Elle décide si le message est mis en correspondance à ce gateway, et elle porte les TLV qui sont tamponnés sur le message à la sortie. Sous DLT, l’identifiant d’entité que l’opérateur exige. Le rapport de couverture TLV du panel existe exactement pour cela. Par ligne approuvée, il nomme quelles balises obligatoires ne seront fournies par rien, et pourquoi :C’est un rapport, jamais un garde-fou. Un login n’est pas lié à un listener et les règles de route choisissent le vendeur, donc rien ici ne peut être certain qu’un message donné atteint un listener donné. Refuser un enregistrement dessus bloquerait des configurations qui fonctionnent. Et chaque phrase qu’il produit dit qu’un client envoyant lui-même la balise rend la question inutile.
vendorDrops mérite d’être lu deux fois : une balise que le vendeur n’a pas enregistrée est jetée à la sortie, après que l’enregistrement d’appel l’ait déjà notée comme présente. L’enregistrement montre qu’elle est envoyée et le fil ne la porte pas. Voir TLV sur une connexion.
Portée : compte, produit, et optionnellement un login
Une ligne est par(account, product), avec un produit vide signifiant chaque produit. Une liste spécifique au produit est fusionnée par-dessus la liste tous produits du compte. Les deux sont unifiés, pas choisis entre.
system_id restreint davantage. NULL signifie chaque login du compte, ce que chaque ligne signifiait avant que la colonne existe. Un déploiement non touché correspond exactement comme avant et aucune rétro-remplissage n’a été nécessaire. Deux logins sur le même compte peuvent détenir le même sender ID.
Qui propose et qui approuve
1
Le client demande
Depuis le portail. Tout ce qu’un client écrit atterrit en
PENDING, avec sa propre note attachée. Sous DLT, sa référence d’enregistrement. Le gateway ne sert une ligne que quand elle est enabled et APPROVED, donc une demande est stockée, visible des deux côtés, et inerte.2
Un opérateur décide
Approuver ou refuser, sur la page du compte ou sur la liste inter-comptes. Un refus garde la ligne et porte une raison montrée au client. C’est pourquoi il n’y a pas de refus en masse, seulement d’approbation en masse.
3
Il entre en service au prochain sondage
Pas de reconnexion. Voir ci-dessous.
status et enabled sont des colonnes séparées faisant des travaux séparés. Approuver écrit status et enregistre le relecteur. Décocher écrit enabled = false et laisse status tranquille : retirer quelque chose n’est pas le désapprouver, et une ligne retirée remise en service ne devrait pas avoir besoin d’être approuvée à nouveau.
Un client lisant l’API voit le retrait, à partir du gateway 0.9.8. Parce que les deux colonnes sont séparées, l’API d’inscription rapportait auparavant une ligne retirée comme
APPROVED. Elle lit la décision d’approbation, et celle-ci n’avait pas changé. Un client qui la sondait pour décider depuis quoi envoyer se voyait dire que l’expéditeur était approuvé alors que le gateway refusait chacun de ses messages.Elle rapporte désormais un quatrième état, WITHDRAWN, donc l’API et l’écran du portail du client concordent entre eux et avec ce que le gateway fait réellement. Rien de votre côté n’a changé ; décocher écrit toujours une seule colonne.Les TLV qu’un client peut proposer mais pas définir
Les deux tables d’inscription portent deux colonnes TLV.
Sous
replace le tampon écrase ce que le client a affirmé, et cet écrasement est l’approbation. Un client qui pourrait écrire la colonne servie pourrait affirmer l’inscription de quelqu’un d’autre tout en envoyant un libellé approuvé, et l’enregistrement d’appel rapporterait alors la valeur qu’il a choisie comme approuvée. Ce comportement est fixé par un test, il ne dérivera donc pas.
Le bénéfice est pour le client : une proposition ne change rien de ce qui est servi, donc contrairement à une modification du sender ID elle ne suspend pas la ligne. Une inscription approuvée continue de fonctionner pendant qu’un opérateur considère la proposition. Accepter déplace la valeur et tamponne l’opérateur comme son propriétaire ; rejeter efface la demande et laisse tlvs exactement comme il était. Ni l’un ni l’autre ne touche status.
Ce que le panel refuse de stocker
64 est généreux plutôt que correct. SMPP plafonne
source_addr à 21 octets, donc tout ce qui dépasse ne peut pas être livré sur un bind. Mais refuser à 21 ici refuserait aussi les modifications de lignes déjà existantes, et « vous ne pouvez pas livrer ceci » est une décision différente de « vous ne pouvez pas enregistrer ceci ».Approuver n’exige pas de reconnexion
La whitelist est relue lors du sondage de configuration et chaque snapshot porte une génération. Une session SMPP bindée depuis des semaines récupère un sender ID nouvellement approuvé sans se reconnecter. Ce qui compte, parce que le client dont le trafic est refusé est généralement au téléphone pendant qu’on l’approuve.Templates de contenu
L’autre moitié de la même approbation, et la grammaire des espaces réservés.
Déployer le whitelisting
Rapporter avant d’appliquer, et les diagnostics sur
/ops/health.