Segmentos concatenados em SMS A2P: como validar a contagem real antes do envio

O que conta como segmento SMS e por que os caracteres não bastam

Um segmento é uma unidade de envio SMS. Se o texto não couber na carga útil disponível, pode ser dividido em várias partes concatenadas, que o terminal destinatário volta a reunir. Por isso, contar os caracteres visíveis não basta: o resultado depende da forma como são codificados e do espaço ocupado pelas informações técnicas que acompanham o texto.

A carga útil TP-UD pode conter apenas dados do utilizador ou incluir um cabeçalho. Quando há um cabeçalho, o seu comprimento também ocupa parte do espaço disponível. Na concatenação, esse cabeçalho identifica a mensagem e a posição de cada parte.

• Não confunda caracteres Unicode visíveis com unidades transmitidas.
• A contagem técnica de segmentos não determina, por si só, uma tarifa comercial.
• A capacidade efetiva depende da codificação e da modalidade de concatenação.

GSM 7-bit, caracteres de escape e Unicode

Em GSM 7-bit, os caracteres são representados por septetos. No entanto, nem todos os símbolos habitualmente descritos como caracteres consomem um único septeto: os da tabela de extensão são representados por uma sequência de escape e consomem dois. O cálculo deve contar unidades codificadas, não apenas posições no texto.

Se um carácter não estiver nas tabelas GSM aplicáveis, o emissor poderá ter de utilizar outra codificação, como UCS2. Esta representa cada carácter em unidades de 16 bits. Para emojis e outros caracteres fora do repertório GSM, é necessário verificar a codificação que o sistema realmente seleciona; não é prudente presumir que a mensagem permanecerá em GSM 7-bit.

As tabelas nacionais de idioma também podem afetar a escolha e o cálculo. A codificação efetiva depende do conteúdo, da configuração e da implementação do emissor ou da rota.

• Conte como dois septetos cada símbolo de GSM 7-bit que utilize escape.
• Verifique o comportamento do codificador perante acentos, símbolos, emojis e caracteres pouco habituais.
• Não presuma um valor predefinido de data_coding no SMPP: a especificação SMPP v3.4 indica que não existe um.

Como a concatenação afeta a capacidade

A concatenação reserva espaço para um cabeçalho de utilizador (UDH), que contém as informações necessárias para reconstruir a mensagem. O cabeçalho pode incluir uma referência comum, o número total de partes e o número de sequência. Em GSM 7-bit, também pode ser necessário preencher bits para alinhar o texto após o cabeçalho.

Como referência normativa, a 3GPP TS 23.040 especifica capacidades de 153 caracteres GSM 7-bit ou 67 caracteres UCS2 por segmento com o cabeçalho padrão de concatenação com referência de 8 bits. Para a variante com referência de 16 bits, especifica 152 e 66, respetivamente. São capacidades técnicas de referência, não uma garantia de que todas as plataformas ou rotas utilizem a mesma modalidade.

A especificação também exige que determinadas sequências não sejam divididas entre segmentos: os caracteres de escape GSM e os caracteres UCS2 devem permanecer completos. Por isso, uma divisão simples em blocos de caracteres pode produzir um cálculo incorreto.

• Confirme se a implementação utiliza uma referência de concatenação de 8 ou 16 bits.
• Não utilize os limites de referência como substituto da verificação do cabeçalho real.
• Distinga a segmentação técnica das regras de faturação acordadas com cada fornecedor.

Método reproduzível para calcular segmentos

Para que o cálculo possa ser repetido e auditado, baseie-o no texto exato que será enviado. Uma pré-visualização pode diferir do conteúdo transmitido devido a substituições, espaços, quebras de linha ou caracteres adicionados por um modelo.

Aplique este procedimento antes da entrada em produção e guarde o resultado do cálculo junto do pedido de envio.

• 1. Capture o texto final exato, depois de aplicar a personalização e as substituições.
• 2. Identifique a codificação e as tabelas efetivamente utilizadas pelo codificador; não as deduza apenas pelo aspeto do texto.
• 3. Se for GSM 7-bit, conte os septetos e contabilize como duas unidades os caracteres de extensão. Se for UCS2, conte as unidades de 16 bits de acordo com o codificador utilizado.
• 4. Determine a modalidade de concatenação e o espaço ocupado pelo cabeçalho. Considere o alinhamento de septetos, quando aplicável.
• 5. Calcule quantas partes são necessárias, respeitando a regra de não dividir as sequências de escape e os caracteres UCS2.
• 6. Guarde o resultado juntamente com uma versão ou hash do texto, a configuração do codificador e a carga útil preparada.

Casos de teste antes de alterar modelos ou codificadores

Teste tanto os limites como as mudanças de codificação. Uma mensagem curta pode passar a ter várias partes após a adição de um único carácter que force a utilização de outro esquema; um símbolo de extensão pode consumir dois septetos apesar de ocupar visualmente uma posição.

Utilize casos controlados e guarde o texto exato de cada teste. Não altere o conteúdo, a codificação e a modalidade de concatenação ao mesmo tempo, pois depois será difícil identificar a causa de uma diferença.

• Texto apenas com caracteres da tabela GSM predefinida.
• Texto que inclua caracteres da tabela de extensão.
• Texto com acentos, símbolos ou emojis para observar se a codificação muda.
• Mensagens próximas dos limites de uma e de várias partes, com a modalidade de referência efetivamente configurada.
• Alterações nas quebras de linha, nos espaços e nas variáveis do modelo que modifiquem o texto final.

Verifique o pedido aceite e os registos

O cálculo local deve ser comparado com o que foi enviado. Em SMPP, verifique o valor de data_coding, o conteúdo de short_message ou message_payload, conforme a implementação, e o cabeçalho UDH ou os parâmetros SAR utilizados. A especificação SMPP v3.4 define sar_msg_ref_num, sar_total_segments e sar_segment_seqnum para comunicar a referência, o total e a sequência; indica que os três parâmetros relacionados devem estar presentes para processar a referência SAR.

Uma resposta submit_sm_resp bem-sucedida confirma o resultado do pedido e pode devolver um message_id, mas o formato padrão não inclui um campo que confirme o número de segmentos aceites. Por conseguinte, a aceitação não substitui a comparação com os registos da plataforma ou do fornecedor.

Se o envio for feito por uma API HTTP, consulte a documentação dessa API para saber o que representa a resposta e se disponibiliza detalhes de segmentação. Não presuma que uma resposta de aceitação comunica a contagem técnica.

• Compare o texto ou o respetivo hash, a codificação, a UDH ou os parâmetros SAR e a resposta de envio.
• Associe o message_id aos registos posteriores, quando estiver disponível.
• Consulte a documentação da API, do fornecedor e da rota para interpretar os campos apresentados.
• Não confunda aceitação, DLR e confirmação independente de receção no terminal.

Investigue e concilie discrepâncias sem deduzir tarifas

Uma diferença entre o cálculo local e um registo externo pode dever-se à comparação de textos diferentes, à seleção de outra codificação, à utilização de outra modalidade de concatenação ou à aplicação de uma transformação pela plataforma. Também pode haver diferenças no dado comunicado por cada sistema. Comece por identificar o que foi enviado e que unidade cada parte está a registar.

Mantenha a contagem técnica de segmentos separada da conciliação comercial. As normas técnicas descrevem a codificação, a carga útil e a concatenação; não estabelecem a tarifa aplicável. Para qualquer valor, utilize as condições contratuais e os registos de faturação correspondentes.

• Guarde o texto exato ou o respetivo hash e a versão do modelo.
• Registe a codificação, data_coding, as unidades calculadas e a modalidade de concatenação.
• Guarde a UDH ou os parâmetros SAR, o resultado do envio e o message_id.
• Anote os segmentos comunicados por cada sistema, a sua origem e o intervalo de tempo.
• Investigue uma variável de cada vez e documente a conclusão antes de alterar a produção.

Lista de verificação e referências técnicas

Antes de ativar um modelo ou alterar o envio, confirme que o cálculo se baseia no texto final, que a codificação efetiva foi identificada e que a concatenação utilizada corresponde à configuração real. Repita o teste quando mudar o conteúdo, o codificador, a API, a sessão SMPP ou a rota.

Para os detalhes normativos, consulte a 3GPP TS 23.038, sobre alfabetos e codificação; a 3GPP TS 23.040, sobre a implementação técnica do SMS e os respetivos cabeçalhos; e o SMPP v3.4, sobre data_coding, respostas e parâmetros SAR.

• O texto de teste corresponde exatamente, byte a byte ou por hash, ao que foi enviado?
• Foram verificados o GSM 7-bit, os caracteres de escape e eventuais mudanças para UCS2?
• A modalidade de concatenação e o respetivo cabeçalho estão confirmados?
• O pedido, a resposta, o identificador e os registos relevantes foram guardados?
• A conciliação técnica permanece separada da interpretação das tarifas?