Segmentos concatenados en A2P SMS: cómo validar el recuento real antes de enviar tráfico

Qué cuenta como segmento SMS y por qué los caracteres no bastan

Un segmento es una unidad de envío SMS. Si el texto no cabe en la carga útil disponible, puede dividirse en varias partes concatenadas que el terminal destinatario reensambla. Por eso, contar los caracteres visibles no basta: el resultado depende de cómo se codifican y de cuánto espacio consume la información técnica que acompaña al texto.

La carga útil TP-UD puede contener solo datos de usuario o incluir una cabecera. Cuando hay cabecera, su longitud también ocupa parte del espacio disponible. En la concatenación, esa cabecera identifica el mensaje y la posición de cada parte.

• No confunda caracteres Unicode visibles con unidades transmitidas.
• El recuento técnico de segmentos no determina por sí mismo una tarifa comercial.
• La capacidad efectiva depende de la codificación y de la modalidad de concatenación.

GSM 7-bit, caracteres de escape y Unicode

En GSM 7-bit, los caracteres se representan mediante septetos. Sin embargo, no todos los símbolos que suelen describirse como caracteres consumen un solo septeto: los de la tabla de extensión se representan mediante una secuencia de escape y consumen dos. El cálculo debe contar unidades codificadas, no solo posiciones de texto.

Si un carácter no está en las tablas GSM aplicables, el emisor puede tener que utilizar otra codificación, como UCS2. Esta representa cada carácter en unidades de 16 bits. Emojis y otros caracteres fuera del repertorio GSM requieren comprobar la codificación que el sistema realmente selecciona; no es prudente asumir que el mensaje permanecerá en GSM 7-bit.

Las tablas nacionales de idioma también pueden afectar la elección y el cálculo. La codificación efectiva depende del contenido, la configuración y la implementación del emisor o la ruta.

• Cuenta como dos septetos cada símbolo de GSM 7-bit que use escape.
• Comprueba el comportamiento del codificador ante acentos, símbolos, emojis y caracteres no habituales.
• No presupongas un valor predeterminado de data_coding en SMPP: la especificación SMPP v3.4 indica que no existe uno.

Cómo afecta la concatenación a la capacidad

La concatenación reserva espacio para una cabecera de usuario (UDH), que contiene información necesaria para reconstruir el mensaje. La cabecera puede incluir una referencia común, el número total de partes y el número de secuencia. En GSM 7-bit, también puede requerirse relleno de bits para alinear el texto después de la cabecera.

Como referencia normativa, 3GPP TS 23.040 especifica capacidades de 153 caracteres GSM 7-bit o 67 caracteres UCS2 por segmento con la cabecera estándar de concatenación con referencia de 8 bits. Para la variante con referencia de 16 bits, especifica 152 y 66, respectivamente. Son capacidades técnicas de referencia, no una garantía de que todas las plataformas o rutas empleen la misma modalidad.

La especificación también requiere que determinadas secuencias no se partan entre segmentos: los caracteres de escape GSM y los caracteres UCS2 deben permanecer completos. Por ello, un reparto simple por bloques de caracteres puede producir un cálculo incorrecto.

• Confirma si la implementación utiliza una referencia de concatenación de 8 o 16 bits.
• No uses los límites de referencia como sustituto de verificar la cabecera real.
• Distingue la segmentación técnica de las reglas de facturación acordadas con cada proveedor.

Método reproducible para calcular segmentos

Para que el cálculo se pueda repetir y auditar, fíjalo sobre el texto exacto que se enviará. Una vista previa puede diferir del contenido transmitido por sustituciones, espacios, saltos de línea o caracteres añadidos por una plantilla.

Aplica este procedimiento antes de producción y conserva la salida del cálculo junto a la solicitud de envío.

• 1. Captura el texto final exacto, después de aplicar personalización y sustituciones.
• 2. Identifica la codificación y las tablas efectivas que utiliza el codificador; no las deduzcas solo por el aspecto del texto.
• 3. Si es GSM 7-bit, cuenta septetos y contabiliza como dos unidades los caracteres de extensión. Si es UCS2, cuenta las unidades de 16 bits según el codificador utilizado.
• 4. Determina la modalidad de concatenación y el espacio ocupado por la cabecera. Considera la alineación de septetos cuando corresponda.
• 5. Calcula cuántas partes hacen falta, respetando que las secuencias de escape y los caracteres UCS2 no se dividan.
• 6. Guarda el resultado junto con una versión o hash del texto, la configuración del codificador y el payload preparado.

Casos de prueba antes de cambiar plantillas o codificadores

Prueba tanto los límites como los cambios de codificación. Un mensaje corto puede pasar a varias partes al añadir un solo carácter que fuerce otro esquema; un símbolo de extensión puede consumir dos septetos aunque visualmente ocupe una posición.

Usa casos controlados y conserva el texto exacto de cada prueba. No cambies a la vez el contenido, la codificación y la modalidad de concatenación, porque después será difícil localizar la causa de una diferencia.

• Texto solo con caracteres de la tabla GSM predeterminada.
• Texto que incluya caracteres de la tabla de extensión.
• Texto con acentos, símbolos o emojis para observar si cambia la codificación.
• Mensajes cerca de los límites de una y varias partes, con la modalidad de referencia realmente configurada.
• Cambios de saltos de línea, espacios y variables de plantilla que alteren el texto final.

Verifica la solicitud aceptada y los registros

El cálculo local debe contrastarse con lo que se envió. En SMPP, revisa el valor de data_coding, el contenido de short_message o message_payload según la implementación, y la cabecera UDH o los parámetros SAR utilizados. La especificación SMPP v3.4 define sar_msg_ref_num, sar_total_segments y sar_segment_seqnum para comunicar referencia, total y secuencia; indica que los tres parámetros relacionados deben estar presentes para procesar la referencia SAR.

Una respuesta submit_sm_resp satisfactoria confirma el resultado de la solicitud y puede devolver un message_id, pero el formato estándar no incluye un campo que confirme el número de segmentos aceptados. Por tanto, la aceptación no sustituye la comparación con los registros de la plataforma o del proveedor.

Si se envía mediante una API HTTP, consulta la documentación de esa API para saber qué representa su respuesta y si expone detalles de segmentación. No des por hecho que una respuesta de aceptación comunica el recuento técnico.

• Compara el texto o su hash, la codificación, la UDH o los parámetros SAR y la respuesta de envío.
• Relaciona el message_id con los registros posteriores cuando esté disponible.
• Consulta la documentación de la API, del proveedor y de la ruta para interpretar los campos reportados.
• No confundas aceptación, DLR y confirmación independiente de recepción en el terminal.

Investiga y concilia discrepancias sin inferir tarifas

Una diferencia entre el cálculo local y un registro externo puede deberse a que se comparan textos distintos, se seleccionó otra codificación, se usó otra modalidad de concatenación o la plataforma aplica una transformación. También puede haber diferencias en qué dato informa cada sistema. Aísla primero qué se envió y qué unidad está registrando cada parte.

Mantén separado el recuento técnico de segmentos de la conciliación comercial. Las normas técnicas describen codificación, carga útil y concatenación; no establecen la tarifa aplicable. Para cualquier importe, utiliza las condiciones contractuales y los registros de facturación correspondientes.

• Conserva el texto exacto o su hash y la versión de la plantilla.
• Registra codificación, data_coding, unidades calculadas y modalidad de concatenación.
• Guarda la UDH o los parámetros SAR, el resultado de envío y el message_id.
• Anota los segmentos que reporta cada sistema, su origen y el intervalo temporal.
• Investiga primero una sola variable cada vez y documenta la conclusión antes de modificar producción.

Lista de comprobación y referencias técnicas

Antes de habilitar una plantilla o modificar el envío, confirma que el cálculo se basa en el texto final, que la codificación efectiva está identificada y que la concatenación utilizada coincide con la configuración real. Repite la prueba cuando cambie el contenido, el codificador, la API, la sesión SMPP o la ruta.

Para los detalles normativos, consulta 3GPP TS 23.038, sobre alfabetos y codificación; 3GPP TS 23.040, sobre la realización técnica del SMS y sus cabeceras; y SMPP v3.4, sobre data_coding, respuestas y parámetros SAR.

• ¿El texto de prueba coincide byte a byte o por hash con el enviado?
• ¿Se ha comprobado GSM 7-bit, caracteres de escape y posibles cambios a UCS2?
• ¿Está confirmada la modalidad de concatenación y su cabecera?
• ¿Se conservan solicitud, respuesta, identificador y registros pertinentes?
• ¿La conciliación técnica se mantiene separada de la interpretación de tarifas?