Análisis de protocolos SMPP con Wireshark

Descripción

Entorno

Adobe Campaign Classic

Problema/Síntomas

Aprenda a analizar el tráfico de 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 el envío de estos SMS. El protocolo SMPP está documentado en la Especificación del Protocolo SMPP v3.4 disponible en Internet como documento PDF.

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

Dado que el protocolo SMPP contiene muchas partes dejadas a la interpretación del equipo de implementación, hay diferencias entre diferentes 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

Captura del tráfico de red sin Wireshark

Si no tiene acceso directo al equipo, puede ser necesario capturar usando 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. Esta es una línea de comandos de tcpdump de ejemplo 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 un análisis más detallado.

Manejo de cables

En este tema se supone que está familiarizado con los conceptos básicos de Wireshark: capturar paquetes, definir filtros simples, leer detalles de paquetes. Una breve introducción está disponible en howjuntos - Cómo usar Wireshark para capturar, filtrar y paquetes Inspect.

Para filtrar el tráfico SMPP en Wireshark, existen tres funciones 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, use la función de búsqueda con la siguiente configuración:
  
  

• Utilice la variable Seguir flujo TCP para aislar el flujo en el que está trabajando.
  
  Cierre la ventana de texto rojo/azul que aparece porque solo es útil para los protocolos de texto irrelevantes para el SMPP.

  

Protocolo SMPP
El protocolo funciona sobre TCP y es totalmente binario, lo que significa que se necesitan 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 remontará las PDU correctamente, por lo que es en su mayoría transparente para el usuario de Wireshark.

Este es un ejemplo de PDU que pasan por la red al enviar un MT y luego recibir un SR:

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 todos los comandos sean reconocidos por una PDU de respuesta:

BIND_TRANSMITTER es reconocido por BIND_TRANSMITTER_RESP, SUBMIT_SM es reconocido por 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 reconocimiento positivo (command_status = 0) o un error (ver 5.1.3 command_status, tabla 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 la conexión SMPP
La conexión SMPP comienza 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).

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 encuentra en el campo system_id .

En Campaign, debería ver un BIND_TRANSMITTER paquete al iniciar una transferencia MT y un BIND_RECEIVER paquete 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 la conexión TCP siempre la inicia Campaign, incluso en 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.

Recepción de MO
Cuando el receptor está vinculado, el SMS-C puede enviar MO en cualquier momento. El MO se envía mediante un DELIVER_SM PDU con bits de 2 a 5 de esm_clas s clear (a menudo, esm_class será simplemente 0).

La variable *DELIVER_SM* La PDU debe responderse rápidamente mediante una *DELIVER_SM_RESP* PDU con la misma *sequence_number*.

Envío de la MT
Para enviar una MT, el transmisor debe estar vinculado con éxito. 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 debería responder rápidamente con un 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 de SMS-C para ayudarle a 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 register_delivery (descrito en la sección 5.2.17 del pliego de condiciones) indica al SMS-C si se solicita un SR para este MT concreto. Si no recibe SR para un mensaje específico, compruebe que el campo esté correctamente configurado en la variable SUBMIT_SM PDU.

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

Una buena práctica es siempre ponerse en contacto con el socio de SMS-C en caso de problemas de codificación. Su socio de SMS tiene un conocimiento preciso de la codificación admitida y de las reglas especiales que pueden aplicarse debido a limitaciones en su plataforma técnica. Hagan que verifiquen lo que les envía y lo que le devuelven. Es la única ruta 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.

La variable data_coding indica la codificación que 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)
Los UDH (encabezados 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 los SMS concatenados (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 la UDH en la interfaz y proporciona información precisa.

En la captura de pantalla anterior, puede ver el encabezado de los datos del 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 calculada por Wireshark (3): el campo Short Message body es especialmente interesante ya que contiene el mensaje completo reensamblado por Wireshark.

Recepción de SR
Cuando el receptor está vinculado, el SMS-C puede enviar SR en cualquier momento. La SR se envía utilizando una PDU DELIVER_SM con bits 2-5 de esm_class configurado.

La variable DELIVER_SM La PDU debe responderse rápidamente mediante una DELIVER_SM_RESP PDU con la misma sequence_number. Para encontrar el MT que coincida con esta SR, busque un SUBMIT_SM_RESP con el mismo ID. Por ejemplo, este es el MT que coincide con el SR:

La SR solo se envía si la variable register_delivery se establece en MT.

Nota: El conector SMPP de Adobe Campaign Classic no gestiona los SR que llegan antes de la SUBMIT_SM_RESP paquete. 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 muy 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.

Debe solicitar directamente al socio de SMS-C una documentación de su propia implementación y comprobar que coincida con lo que 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 la variable SUBMIT_SM_RESP del MT correspondiente.
• Puede ignorar problemas en el campo de texto: Campaign ignora este campo porque no es útil, no es fiable e incluso puede ser completamente ilegible si el SMS se envió con otra codificación que el ASCII alfanumérico puro. Este es un comportamiento normal.
• Los nombres de campo no distinguen entre mayúsculas y minúsculas (por ejemplo, id: sub: Texto: también se puede señalar como ID: SUBB: texto:).
• La variable dlvrd generalmente, no es fiable, a menos que esté documentado por el socio de SMS-C.
• 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.
• La variable stat puede tener valores distintos a los definidos en el apéndice B. Utilice el sentido común y la documentación del socio de SMSC para comprender su significado.
• La variable err depende completamente del SMS-C, y la mayoría del tiempo está documentado por el socio de SMS-C. 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 seguir 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:

La implementación actual no controla la ventana y espera que el SMS-C remoto sea lo bastante rápido para gestionar la MT.