Segments des SMS A2P concaténés : comment vérifier le nombre réel avant l’envoi du trafic

Ce qui compte comme segment SMS et pourquoi les caractères ne suffisent pas

Un segment est une unité d’envoi SMS. Si le texte ne tient pas dans la charge utile disponible, il peut être divisé en plusieurs parties concaténées que le terminal destinataire réassemble. Il ne suffit donc pas de compter les caractères visibles : le résultat dépend de leur encodage et de l’espace occupé par les informations techniques qui accompagnent le texte.

La charge utile TP-UD peut contenir uniquement des données utilisateur ou inclure un en-tête. Lorsqu’il y a un en-tête, sa longueur réduit également l’espace disponible. Dans le cas de la concaténation, cet en-tête identifie le message et la position de chaque partie.

• Ne confondez pas les caractères Unicode visibles avec les unités transmises.
• Le nombre technique de segments ne détermine pas, à lui seul, un tarif commercial.
• La capacité effective dépend de l’encodage et du mode de concaténation.

GSM 7-bit, caractères d’échappement et Unicode

En GSM 7-bit, les caractères sont représentés par des septets. Toutefois, tous les symboles que l’on décrit généralement comme des caractères ne consomment pas un seul septet : ceux de la table d’extension sont représentés par une séquence d’échappement et en consomment deux. Le calcul doit porter sur les unités encodées, pas uniquement sur le nombre de caractères du texte.

Si un caractère ne figure pas dans les tables GSM applicables, l’émetteur peut devoir recourir à un autre encodage, comme UCS2. Celui-ci représente chaque caractère en unités de 16 bits. Pour les emojis et autres caractères hors du répertoire GSM, vérifiez l’encodage réellement sélectionné par le système ; il est imprudent de supposer que le message restera en GSM 7-bit.

Les tables de langue nationales peuvent également influer sur le choix de l’encodage et sur le calcul. L’encodage effectif dépend du contenu, de la configuration et de l’implémentation de l’émetteur ou de la route.

• Comptez deux septets pour chaque symbole GSM 7-bit utilisant un caractère d’échappement.
• Vérifiez le comportement de l’encodeur avec les accents, les symboles, les emojis et les caractères inhabituels.
• Ne supposez pas de valeur par défaut pour data_coding dans SMPP : la spécification SMPP v3.4 indique qu’il n’y en a pas.

Comment la concaténation influe sur la capacité

La concaténation réserve de l’espace pour un en-tête de données utilisateur (UDH), qui contient les informations nécessaires à la reconstitution du message. L’en-tête peut inclure une référence commune, le nombre total de parties et le numéro de séquence. En GSM 7-bit, un bourrage de bits peut également être nécessaire pour aligner le texte après l’en-tête.

À titre de référence normative, la norme 3GPP TS 23.040 spécifie une capacité de 153 caractères GSM 7-bit ou de 67 caractères UCS2 par segment avec l’en-tête standard de concaténation à référence sur 8 bits. Pour la variante à référence sur 16 bits, elle spécifie respectivement 152 et 66 caractères. Il s’agit de capacités techniques de référence, et non d’une garantie que toutes les plateformes ou routes utilisent le même mode.

La spécification exige également que certaines séquences ne soient pas scindées entre les segments : les caractères d’échappement GSM et les caractères UCS2 doivent rester entiers. Un simple découpage en blocs de caractères peut donc produire un calcul erroné.

• Vérifiez si l’implémentation utilise une référence de concaténation sur 8 ou 16 bits.
• Ne remplacez pas la vérification de l’en-tête réel par des limites de référence.
• Distinguez la segmentation technique des règles de facturation convenues avec chaque fournisseur.

Méthode reproductible pour calculer les segments

Pour que le calcul puisse être reproduit et audité, basez-le sur le texte exact qui sera envoyé. Un aperçu peut différer du contenu transmis en raison de substitutions, d’espaces, de sauts de ligne ou de caractères ajoutés par un modèle.

Suivez cette procédure avant la mise en production et conservez le résultat du calcul avec la demande d’envoi.

• 1. Récupérez le texte final exact après personnalisation et substitutions.
• 2. Identifiez l’encodage et les tables effectivement utilisés par l’encodeur ; ne les déduisez pas de la seule apparence du texte.
• 3. En GSM 7-bit, comptez les septets et comptez pour deux unités les caractères d’extension. En UCS2, comptez les unités de 16 bits selon l’encodeur utilisé.
• 4. Déterminez le mode de concaténation et l’espace occupé par l’en-tête. Tenez compte de l’alignement des septets, le cas échéant.
• 5. Calculez le nombre de parties nécessaires en veillant à ne pas scinder les séquences d’échappement ni les caractères UCS2.
• 6. Enregistrez le résultat avec une version ou une empreinte du texte, la configuration de l’encodeur et la charge utile préparée.

Cas de test avant de modifier des modèles ou des encodeurs

Testez à la fois les limites et les changements d’encodage. Un message court peut passer à plusieurs parties après l’ajout d’un seul caractère qui impose un autre schéma ; un symbole d’extension peut consommer deux septets même s’il n’occupe qu’une position visuelle.

Utilisez des cas contrôlés et conservez le texte exact de chaque test. Ne modifiez pas en même temps le contenu, l’encodage et le mode de concaténation : il serait ensuite difficile d’identifier la cause d’un écart.

• Texte composé uniquement de caractères de la table GSM par défaut.
• Texte comprenant des caractères de la table d’extension.
• Texte avec des accents, des symboles ou des emojis pour observer si l’encodage change.
• Messages proches des limites d’une ou de plusieurs parties, avec le mode de référence réellement configuré.
• Modifications des sauts de ligne, des espaces et des variables de modèle qui changent le texte final.

Vérifiez la demande acceptée et les journaux

Le calcul local doit être comparé à ce qui a été envoyé. Avec SMPP, vérifiez la valeur de data_coding, le contenu de short_message ou de message_payload selon l’implémentation, ainsi que l’en-tête UDH ou les paramètres SAR utilisés. La spécification SMPP v3.4 définit sar_msg_ref_num, sar_total_segments et sar_segment_seqnum pour communiquer la référence, le nombre total et la séquence ; elle indique que les trois paramètres associés doivent être présents pour traiter la référence SAR.

Une réponse submit_sm_resp réussie confirme le résultat de la demande et peut renvoyer un message_id, mais le format standard ne comporte pas de champ confirmant le nombre de segments acceptés. L’acceptation ne remplace donc pas la comparaison avec les journaux de la plateforme ou du fournisseur.

Si l’envoi passe par une API HTTP, consultez la documentation de cette API pour savoir ce que représente sa réponse et si elle fournit des détails sur la segmentation. Ne partez pas du principe qu’une réponse d’acceptation indique le nombre technique de segments.

• Comparez le texte ou son empreinte, l’encodage, l’UDH ou les paramètres SAR et la réponse d’envoi.
• Associez le message_id aux journaux ultérieurs lorsqu’il est disponible.
• Consultez la documentation de l’API, du fournisseur et de la route pour interpréter les champs renvoyés.
• Ne confondez pas l’acceptation, le DLR et une confirmation indépendante de réception sur le terminal.

Examiner et rapprocher les écarts sans en déduire de tarifs

Un écart entre le calcul local et un journal externe peut s’expliquer par une comparaison de textes différents, le choix d’un autre encodage, l’utilisation d’un autre mode de concaténation ou une transformation effectuée par la plateforme. Les systèmes peuvent également ne pas rapporter la même donnée. Commencez par isoler ce qui a été envoyé et l’unité comptabilisée par chaque partie.

Distinguez le nombre technique de segments du rapprochement commercial. Les normes techniques décrivent l’encodage, la charge utile et la concaténation ; elles ne définissent pas le tarif applicable. Pour tout montant, référez-vous aux conditions contractuelles et aux registres de facturation correspondants.

• Conservez le texte exact ou son empreinte et la version du modèle.
• Enregistrez l’encodage, data_coding, les unités calculées et le mode de concaténation.
• Conservez l’UDH ou les paramètres SAR, le résultat de l’envoi et le message_id.
• Notez les segments rapportés par chaque système, leur origine et l’intervalle de temps.
• Commencez par examiner une seule variable à la fois et consignez la conclusion avant toute modification en production.

Liste de contrôle et références techniques

Avant d’activer un modèle ou de modifier l’envoi, vérifiez que le calcul porte sur le texte final, que l’encodage effectif est identifié et que le mode de concaténation correspond à la configuration réelle. Recommencez les tests lorsque le contenu, l’encodeur, l’API, la session SMPP ou la route change.

Pour les détails normatifs, consultez la 3GPP TS 23.038, sur les alphabets et l’encodage ; la 3GPP TS 23.040, sur la réalisation technique du SMS et ses en-têtes ; et SMPP v3.4, sur data_coding, les réponses et les paramètres SAR.

• Le texte de test correspond-il exactement, octet par octet ou par empreinte, au texte envoyé ?
• GSM 7-bit, les caractères d’échappement et les éventuels passages à UCS2 ont-ils été vérifiés ?
• Le mode de concaténation et son en-tête sont-ils confirmés ?
• La demande, la réponse, l’identifiant et les journaux pertinents sont-ils conservés ?
• Le rapprochement technique est-il bien séparé de l’interprétation des tarifs ?