Análisis del protocolo SMPP con Wireshark

Este artículo muestra cómo realizar análisis de protocolo SMPP con Wireshark para Adobe Campaign Classic.

Descripción description

Entorno

Adobe Campaign Classic (ACC)

Problema/Síntomas

Aprenda a analizar el tráfico SMPP mediante Wireshark.

La mayoría de los centros de servicio de mensajes cortos (SMS-C) de alto rendimiento son compatibles con la versión 3.4 del protocolo SMPP. Este protocolo permite enviar SMS y recibir información sobre su entrega. El protocolo SMPP está documentado en la Especificación del Protocolo SMPP v3.4 disponible en Internet como documento PDF.

Este artículo no sustituye a esta especificación: ofrece consejos prácticos sobre cómo interpretar la especificación del protocolo y hacerla coincidir con la pantalla de Wireshark para ayudar a solucionar los problemas entre Adobe Campaign y el socio SMS-C.

Dado que el protocolo SMPP contiene muchas partes que se dejan a la interpretación del equipo de implementación, existen diferencias entre los distintos SMS-C.

Cuando solucione problemas, póngase siempre en contacto con el socio SMS-C para obtener información o para que le ayude a revisar lo que obtiene. Si el SMS-C responde con un error, su socio SMS-C será la persona más indicada para explicarle el porqué. Si en lugar de conectarse a un SMS-C real está usando un simulador de SMPP, deberá usar el código fuente (o un depurador) para entender lo que ocurre.

Resolución resolution

Captura del tráfico de red sin Wireshark

Si no tiene acceso directo a la máquina, puede ser necesario capturar con herramientas de línea de comandos como tcpdump. Si ya conoce el puerto TCP de la conexión, ponga el filtro correcto para evitar capturar todo el tráfico. Este es un ejemplo de la línea de comandos tcpdump para capturar el puerto 12345 a  outfile.pcap:

tcpdump -i any -w outfile.pcap tcp port 12345

El archivo  outfile.pcap  se puede abrir en Wireshark para realizar un análisis más detallado.

Gestión de Wireshark

En este tema se da por hecho que está familiarizado con los conceptos básicos de Wireshark: captura de paquetes, definición de filtros simples y lectura de detalles de paquetes. Hay una breve introducción disponible en howtogeek - Cómo usar Wireshark para capturar, filtrar, y paquetes de Inspect.

Para filtrar el tráfico SMPP en Wireshark, hay tres características importantes:

  • Utilice un filtro de visualización en el puerto del SMS-C.

    Por ejemplo, si el SMS-C utiliza el puerto 10000, utilice el siguiente filtro:
    tcp.port == 10000

  • Para aislar los paquetes por número de teléfono o por contenido de texto, utilice la función de búsqueda con la siguiente configuración:

    smpp1

  • Utilice el Seguir flujo TCP para aislar la secuencia en la que está trabajando.

    Cierre la ventana de texto rojo/azul que aparece porque solo es útil para los protocolos de texto que no son relevantes para el SMPP.

    smpp2

Protocolo SMPP

El protocolo funciona a través de TCP y es totalmente binario, lo que significa que se requieren herramientas especiales como Wireshark (o un editor hexadecimal) para descifrar el contenido del flujo.

El flujo se compone de PDU independientes: cada PDU es un mensaje que contiene un comando, un estado, un número de secuencia y otra información basada en el comando.

Debido a la naturaleza de TCP como protocolo de flujo, un paquete TCP puede contener más de una PDU, y estas pueden abarcar dos o más paquetes TCP. Wireshark reensamblará las PDU correctamente, por lo que es mayormente transparente para el usuario de Wireshark.

Este es un ejemplo de las PDU que pasan por la red cuando se envía una MT y luego se recibe una SR:
smpp3
Nota: La lista de comandos estándar se encuentra en la sección 5.1.2.1 de la especificación SMPP (Conjunto de comandos SMPP).

Respuestas SMPP

El protocolo SMPP requiere que una PDU de respuesta reconozca todos los comandos:

BIND_TRANSMITTER es reconocido por  BIND_TRANSMITTER_RESPSUBMIT_SM  reconoce a  SUBMIT_SM_RESP, etc.

Hay un tiempo de espera para las respuestas que suele ser de 10, 30 o 60 segundos. La respuesta puede contener un acuse de recibo positivo (comando _status = 0) o un error (consulte 5.1.3  command_statustabla 5-2  en la especificación SMPP para la lista de errores estándar). La mayoría de las veces, estas respuestas son inmediatas y no se alcanza un tiempo de espera de respuesta.

Asegúrese de distinguir entre los errores de respuesta SMPP y los códigos de error SR: el mismo código de error puede significar cosas diferentes en el error de respuesta o en el campo de error SR. Cuando se informa de un código de error, hay que tener mucho cuidado con dónde se encuentra porque el significado del valor depende de su contexto.

Inicialización de conexión SMPP

La conexión SMPP se inicia conectándose mediante TCP. A continuación, se envía una operación BIND por campaña, reconocida por un RESP BIND. Estas operaciones se describen en la sección 4.1 de la especificación SMPP (operación BIND).

smpp4 La operación "bind" realiza la comprobación del inicio de sesión/contraseña e intercambia información sobre el nombre de la plataforma, la versión y otros campos descritos en la especificación.

Nota: El inicio de sesión se puede encontrar en el campo system_id.

En Campaign, debería ver una  BIND_TRANSMITTER  paquete al iniciar una transferencia MT y una  BIND_RECEIVER  packet cuando  nlsm s  déclencheur una conexión MO/SR.

Emisor, receptor y transceptor:  El conector SMPP para Campaign Classic funciona en modo transmisor/receptor por separado: hay dos conexiones TCP, una para transmitir MT y otra para recibir MO y SR. Tenga en cuenta que Campaign siempre inicia la conexión TCP, incluso para el modo receptor.

SMPP también proporciona un modo de transceptor, pero este modo no está implementado en el conector SMPP de Campaign Classic.

El conector SMPP usa múltiples conexiones en paralelo para transmitir la MT. Esto no se puede controlar debido a la forma en que está diseñado el conector.

Recibiendo MO
Cuando el receptor está vinculado, el SMS-C puede enviar MO en cualquier momento. El MO se envía mediante una  DELIVER_SM  PDU con los bits 2-5 de  esm_class s  claro (a menudo,  esm_class  será simplemente 0).

smpp5 El *DELIVER_SM* Una PDU debe responder rápidamente *DELIVER_SM_RESP* PDU con el mismo *número_secuencia*.

Envío de MT
Para enviar una MT, el transmisor debe estar vinculado correctamente. Antes de nada, compruebe que el proceso de vinculación se haya realizado con éxito.

El MT se envía en un  SUBMIT_SM  PDU. El SMS-C debe responder rápidamente con una  SUBMIT_SM_RESP  PDU: este paquete de respuesta es especial porque contiene el ID del mensaje en la base de datos del SMS-C (incluya siempre este ID cuando hable con el socio SMS-C para que pueda encontrar el mensaje más rápido). Este ID estará presente en el SR y es la única manera de hacer coincidir el MT con su correspondiente SR.

El campo  registered_delivery  (descrito en la sección 5.2.17 de la especificación) indica al SMS-C si se solicita una SR para esta MT en particular. Si no recibe SR para un mensaje específico, compruebe que el campo esté configurado correctamente en la  SUBMIT_SM  PDU.

smpp5

Codificación de MT

Precaución: La codificación de SMS es un tema complejo con muchas trampas y varias implementaciones.

Una buena práctica es ponerse siempre en contacto con el socio SMS-C en caso de problemas de codificación. Su socio SMS tiene un conocimiento preciso de la codificación admitida y de las reglas especiales que pueden aplicarse debido a las limitaciones en su plataforma técnica. Haz que comprueben lo que les envías y lo que te devuelven. Es el único camino hacia una interconexión exitosa y estable.

Los mensajes SMS utilizan una codificación especial de 7 bits, a menudo denominada codificación GSM7. Consulte Wikipedia GSM 03.38 (en inglés).

En el protocolo SMPP, el texto de GSM7 se expandirá a 8 bits por carácter para facilitar la resolución de problemas. El SMS-C lo empaquetará en 7 bits por carácter antes de enviarlo al dispositivo móvil. Esto significa que el campo de mensaje corto del SMS puede tener hasta 160 bytes de longitud en el marco SMPP, mientras que está limitado a 140 bytes cuando se envía en la red móvil (el bit más significativo simplemente se descarta).

En caso de problemas de codificación, hay que comprobar algunos aspectos importantes:

  • Primero, asegúrese de saber qué caracteres pertenecen a cada codificación. El GSM7 es tristemente célebre por su compatibilidad parcial con los signos diacríticos (acentos). Especialmente en francés, donde é y è son parte de GSM7, pero ê, â o ï no lo son. La situación mejora en el caso del español.
  • La C con cedilla (ç) solo está presente en mayúsculas en el alfabeto GSM7, pero algunos teléfonos la representan en minúsculas o en mayúsculas "inteligentes": la recomendación general es evitarla por completo y eliminar la cedilla (sigue siendo muy legible en francés) o cambiar a UCS-2.
  • No use ASCII en los SMS, a menos que el interlocutor del SMS-C lo solicite de manera explícita: esta codificación desperdicia espacio porque tiene caracteres de 8 bits y menos cobertura que el GSM7.
  • Latín-1 no siempre es compatible: compruebe la compatibilidad con su socio de SMS-C antes de intentar usar Latín-1.
  • El conector Adobe Campaign Classic no admite tablas de cambio de idioma nacional. Debe usar UCS-2 en su lugar.
  • UCS-2 y UTF-16 suelen mezclarse por teléfono. Esto es un problema para las personas que envían emoji y otros caracteres poco utilizados que no están presentes en UCS-2.
  • Wireshark no admite la codificación GSM7: los caracteres especiales se mostrarán incorrectamente. Si necesita comprobar si una cadena GSM7 está bien codificada, debe comparar los códigos hexadecimales con la tabla GSM7.

El  data_coding  Este campo indica qué codificación se utiliza. El único problema es que el valor 0 significa la codificación SMS-C por defecto en la especificación, pero en general significa GSM7. Consulte con el SMS-C  partner qué codificación está asociada a data_coding = 0 (Adobe Campaign solo admite GSM7 para data_coding  = 0).

El tamaño máximo de un mensaje depende de su codificación. Esta tabla resume toda la información relevante:

Codificación
data_coding
Tamaño del mensaje (caracteres)
Tamaño de la parte para SMS de varias partes
Caracteres disponibles
GSM7
0
160
152
Conjunto de caracteres básico GSM7 + extensión (los caracteres extendidos tienen 2 caracteres)
Latin-1
3
140
134
ISO-8859-1
UCS-2 UTF-16
8
70
67
Unicode (varía de un teléfono a otro)

Encabezado de datos de usuario (UDH)
UDH (encabezado de datos de usuario) son pequeñas cabeceras binarias que se añaden al texto de un SMS. Pueden activar funciones especiales como la concatenación de SMS, las tablas de cambio de idioma nacional, los logotipos/imágenes (raramente usados) o el envío WAP.

Como el UDH forma parte del campo de texto (campo SMPP short_message), acorta el tamaño efectivo de un SMS. Por ejemplo, un SMS UDH concatenado consumirá 6 bytes por parte del SMS (son 6 bytes reales de 8 bits, no caracteres de 7 bits), lo que solo deja espacio suficiente para 152 caracteres de 7 bits por parte del mensaje.

Wikipedia tiene buenos artículos sobre el encabezado de datos de usuario y el SMS concatenado (en inglés).

Para saber si un short_message contiene un UDH, compruebe los bits 6 y 7 de esm_class (véase la sección 5.2.12 de la especificación). Wireshark analiza el UDH en la interfaz y proporciona información precisa.

smpp7 En la captura de pantalla anterior, puede ver el encabezado de datos de usuario en el campo del mensaje (1), la información contenida en el UDH (2) y alguna información adicional que no pertenece al paquete pero que Wireshark calcula (3): el campo del cuerpo del mensaje corto es especialmente interesante ya que contiene el mensaje completo reensamblado por Wireshark.

Recibiendo SR
Cuando el receptor está vinculado, el SMS-C puede enviar SR en cualquier momento. El SR se envía usando una PDU DELIVER_SM con los bits 2-5 de  esm_class set.

smpp8

El  DELIVER_SM  Una PDU debe responder rápidamente  DELIVER_SM_RESP  PDU con el mismo  número_secuencia. Para encontrar la MT que coincida con esta SR, busque  SUBMIT_SM_RESP  con el mismo ID. Por ejemplo, esta es la MT que coincide con la SR:

smpp9

SR solo se envían si la variable  registered_delivery  El campo se establece en la MT.

Nota: El conector SMPP de Adobe Campaign Classic no gestiona los SR que llegan antes del  SUBMIT_SM_RESP  packet. La especificación no prohíbe este comportamiento de forma explícita, pero se considera un mal comportamiento (significaría que el mensaje se ha recibido antes de enviarse). Si se encuentra con este caso demasiado a menudo, pídale a su socio SMS-C que arregle su plataforma.

Descifrar el campo short_message de SR
El campo de texto de las PDU de SR tiene una codificación especial descrita en el apéndice B de la especificación del protocolo SMPP. Por desgracia, este formato solo es una recomendación que no forma parte del protocolo, aunque la mayoría de los SMS-C respetan más o menos este mismo formato.

Debería pedir directamente al socio SMS-C una documentación de su propia implementación y volver a comprobar si coincide con lo que se ve en Wireshark. La mayoría de las veces, los implementadores de SMS-C ni siquiera conocen su implementación y esto conduce a problemas y malentendidos. No dude en pedir ayuda al socio SMS-C si tiene alguna duda sobre este campo (en especial los códigos de error).

El formato básico es el siguiente:

id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:EEE
Text:........

Estas son las directrices generales para leer la línea anterior:

  • El ID es el mismo que se ha enviado en el  SUBMIT_SM_RESP del MT correspondiente.
  • Puede ignorar los problemas en el campo de texto: Campaign ignora este campo porque no es útil ni fiable y puede llegar a ser completamente ilegible si el SMS se envió con una codificación distinta a la ASCII alfanumérica pura. Este es un comportamiento normal.
  • Los nombres de campo no distinguen entre mayúsculas y minúsculas (por ejemplo, id: sub: Text: también se puede anotar como ID: SUB: text:).
  • El  dlvrd El campo no suele ser fiable, a menos que el socio SMS-C lo haya documentado.
  • Las fechas pueden tener cualquier zona horaria, lo que las hace prácticamente inútiles, o simplemente son erróneas porque el reloj del servidor remoto está desfasado.
  • El  estadísticas El campo puede tener valores distintos de los definidos en el apéndice B. Utilice el sentido común y la documentación del socio SMSC para comprender su significado.
  • El  error Este campo depende completamente del SMS-C, y la mayoría de las veces el socio SMS-C lo ha documentado. A menudo, el código 000 significa un éxito, mientras que cualquier otro código indica errores. El campo suele ser numérico, pero también puede ser hexadecimal.

Múltiples SR para la misma MT
Algunos SMS-C envían múltiples SR para la misma MT para rastrear la progresión de la MT en la red. Esto es generalmente inútil porque la mayoría de las veces el cliente solo quiere saber cuándo se recibió el mensaje (esto suele ser el último SR).

En caso de duda, solo trabaje con el último SR recibido del SMS-C para encontrar el estado de un mensaje.

Ventana SMPP
Dado que las operaciones y las respuestas son asíncronas, puede optimizar la velocidad de transferencia si envía varias PDU de operación antes de esperar las respuestas. El número de mensajes que no tienen respuesta se llama ventana.

Ejemplo de una transmisión con una ventana máxima de 4:
smpp10
La implementación actual no controla la ventana y espera que el SMS-C remoto sea lo suficientemente rápido para gestionar la MT.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f