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
Capturando 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 línea de comandos tcpdump para capturar el puerto 12345 a outfile.pcap:
tcpdump -i any -w outfile.pcap tcp port 12345
A continuación, se puede abrir el archivo outfile.pcap en Wireshark para su posterior análisis.
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:
-
Use la herramienta 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 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:
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_RESP reconoce BIND_TRANSMITTER, SUBMIT_SM reconoce 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_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 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).
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 un paquete BIND_TRANSMITTER al iniciar una transferencia MT y un paquete BIND_RECEIVER 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. La MO se envía usando una PDU DELIVER_SM con los bits 2-5 de esm_clas s nítidas (a menudo, esm_class será simplemente 0).
Una PDU DELIVER_SM_RESP con el mismo sequence_number debe responder rápidamente la PDU DELIVER_SM.
Enviando 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.
La MT se envía en una PDU SUBMIT_SM. El SMS-C debería responder rápidamente con una PDU SUBMIT_SM_RESP: 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 PDU SUBMIT_SM.
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 campo data_coding le 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. Compruebe con el socio SMS-C 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:
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.
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 del conjunto esm_class.
Una PDU DELIVER_SM_RESP con el mismo sequence_number debe responder rápidamente la PDU DELIVER_SM. Para encontrar la MT que coincida con esta SR, busque SUBMIT_SM_RESP con la misma ID. Por ejemplo, esta es la MT que coincide con la SR:
Los SR solo se envían si el campo registered_delivery está establecido en la MT.
Nota: el conector SMPP de Adobe Campaign Classic no gestiona los SR que llegan antes del paquete SUBMIT_SM_RESP. 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.
Descifrando 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 identificador es el mismo que se envió 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 campo dlvrd no suele ser confiable, 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 campo stat puede tener otros valores que los definidos en el Apéndice B. Utilice el sentido común y la documentación del socio SMSC para comprender su significado.
- El campo err 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.
Varios 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:
La implementación actual no controla la ventana y espera que el SMS-C remoto sea lo suficientemente rápido para gestionar la MT.