Les chiffres
Tirés des propres constantes de la passerelle, pas de la spécification en général :
Un message peut faire au plus 255 segments.
Le caractère qui double votre facture
Un seul caractère non GSM-7 force tout le message en UCS-2, et la capacité tombe de 160 à 70. Un message de 150 caractères qui coûtait un segment en coûte désormais trois. Les coupables habituels, tous invisibles quand vous regardez le texte :Vérifiez le prix avant d’envoyer
/secure/rate renvoie le nombre de segments sans rien envoyer :
submit_sm_count est le nombre de segments. Cela ne coûte rien, n’envoie rien et ne compte contre
aucune limite de débit. Il est donc raisonnable de l’appeler sur du contenu généré par les
utilisateurs avant de valider un envoi.
Régler l’encodage vous-même
coding correspond au data_coding SMPP et est passé à l’opérateur inchangé, il choisit donc
la manière dont le corps est encodé, pas seulement la manière dont il est compté.
Tout le reste dans 0–14 est accepté et décodé en UTF-8. 15 et au-dessus est un
400.
Ce qu’un client voit quand ça tourne mal
Un message découpé en segments arrive comme un unique message sur un combiné moderne, parce que l’en-tête de concaténation lui dit comment le réassembler. Deux modes d’échec valent la peine d’être connus :- Des segments arrivant dans le désordre ou incomplets apparaissent comme des messages séparés, souvent avec des fragments d’en-tête visibles. C’est un problème d’opérateur, pas d’encodage.
- Un long message partiellement livré est rapporté FAILED, pas partiellement livré. La résolution attend le dernier segment et rapporte la pire issue. C’est la réponse honnête, et cela abaisse les taux de livraison par rapport aux passerelles qui rapportent le premier segment.
Voir aussi
Concaténation
Comment les segments sont réassemblés, et ce que cela coûte.
Tarifer un message
Chaque champ de
/secure/rate.