Hispanopedia Wiki
Articulo de referencia

Mensajes cortos entre pares

El protocolo de mensajes cortos entre pares ( SMPP ) en la industria de las telecomunicaciones es un protocolo abierto y estándar de la industria diseñado para proporcionar una ...

Hispanopedia WikiContenido en espanolLectura gratuita

El protocolo de mensajes cortos entre pares ( SMPP ) en la industria de las telecomunicaciones es un protocolo abierto y estándar de la industria diseñado para proporcionar una interfaz de comunicación de datos flexible para la transferencia de datos de mensajes cortos [ 1 ] entre entidades de mensajería corta externas (ESME), entidades de enrutamiento (RE) y SMSC . [ 2 ]

SMPP se utiliza a menudo para permitir que terceros (por ejemplo, proveedores de servicios de valor añadido como medios de comunicación) envíen mensajes, generalmente de forma masiva, pero también puede utilizarse para el intercambio de SMS. SMPP puede transportar mensajes cortos , incluidos EMS , notificaciones de correo de voz , difusiones celulares , mensajes WAP ( incluidos los mensajes WAP Push , utilizados para enviar notificaciones MMS ), mensajes USSD y otros. Debido a su versatilidad y compatibilidad con protocolos SMS que no son GSM , como UMTS , IS-95 (CDMA), CDMA2000 , ANSI-136 (TDMA) e iDEN , SMPP es el protocolo más utilizado para el intercambio de mensajes cortos fuera de las redes SS7 .

Historia

SMPP (Short Message Peer-to-Peer) fue diseñado originalmente por Aldiscon , una pequeña empresa irlandesa que posteriormente fue adquirida por Logica (desde 2016, tras varios cambios, Mavenir ). El protocolo fue creado inicialmente por el desarrollador Ian J Chambers para probar la funcionalidad del SMSC sin utilizar equipos de prueba SS7 para enviar mensajes.

En 1995, el ETSI incluyó el protocolo SMPP en el informe técnico TR 03.39. [ 3 ]

En 1999, Logica cedió formalmente SMPP al SMPP Developers Forum, que más tarde pasó a llamarse The SMS Forum.

El Foro SMS se disolvió en 2007 con el siguiente anuncio: "El Foro SMS, una organización sin fines de lucro con la misión de desarrollar, fomentar y promover el SMS (servicio de mensajes cortos) en beneficio de la industria inalámbrica global, se disolverá el 27 de julio de 2007". [ 4 ] Como parte de los términos de transferencia originales, la propiedad de SMPP volvió a Mavenir.

Operación

SMPP utiliza el modelo de operación cliente-servidor , a pesar de la denominación "peer-to-peer" (de igual a igual). El Centro de Servicio de Mensajes Cortos (SMSC) suele actuar como servidor, esperando conexiones de los ESME. Cuando SMPP se utiliza para el intercambio de SMS, el MC emisor suele actuar como cliente.

El protocolo se basa en pares de PDU ( unidades de datos de protocolo o paquetes) de solicitud/respuesta intercambiadas a través de conexiones de la capa 4 del modelo OSI ( sesión TCP o X.25 SVC3). [ 5 ] El puerto conocido asignado por la IANA para SMPP cuando opera sobre TCP es el 2775, pero en entornos de mensajería se suelen utilizar varios números de puerto arbitrarios.

Antes de intercambiar cualquier mensaje, se debe enviar y confirmar un comando bind. El comando bind determina en qué dirección será posible enviar mensajes; bind_transmitter solo permite que el cliente envíe mensajes al servidor, bind_receiver significa que el cliente solo recibirá los mensajes, y bind_transceiver (introducido en SMPP 3.4) permite la transferencia de mensajes en ambas direcciones. [ 6 ] En el comando bind, el ESME se identifica mediante system_id, system_type y password; el campo address_range, diseñado para contener la dirección del ESME, generalmente se deja vacío. El comando bind contiene el parámetro interface_version para especificar qué versión del protocolo SMPP se utilizará.

El intercambio de mensajes puede ser síncrono, donde cada participante espera una respuesta por cada PDU que se envía, o asíncrono, donde se pueden emitir múltiples solicitudes sin esperar y ser confirmadas en un orden diferente por el otro participante; el número de solicitudes no confirmadas se denomina ventana ; para obtener el mejor rendimiento, ambas partes que se comunican deben estar configuradas con el mismo tamaño de ventana.

Versiones

El estándar SMPP ha evolucionado con el tiempo. Las versiones más utilizadas de SMPP son:

  • SMPP 3.3 es la versión más antigua en uso (a pesar de sus limitaciones, todavía se usa ampliamente); solo admite GSM . Genera una respuesta inmediata para cada mensaje enviado.
  • SMPP 3.4 añade parámetros opcionales de longitud de etiqueta y valor (TLV), compatibilidad con tecnologías SMS distintas de GSM y compatibilidad con transceptores (conexiones únicas que pueden enviar y recibir mensajes). El intercambio de PDU de solicitud y respuesta SMPP entre un transmisor ESME y un SMSC puede producirse de forma síncrona o asíncrona.
  • SMPP 5.0 es la última versión de SMPP; añade soporte para difusión celular y control de flujo inteligente. A partir de 2025.,No es de uso generalizado.

La versión aplicable se pasa en el parámetro interface_version de un comando bind.

Formato PDU (a partir de la versión 3.4)

Las PDU SMPP están codificadas en binario para mayor eficiencia. Comienzan con una cabecera a la que puede seguir un cuerpo:

Encabezado PDU

Cada PDU comienza con una cabecera. La cabecera consta de 4 campos, cada uno de los cuales tiene una longitud de 4 octetos:

command_length
La longitud total de la PDU en octetos (incluido el campo command_length) debe ser ≥ 16, ya que cada PDU debe contener un encabezado de 16 octetos.
command_id
Identifica la operación (o comando) SMPP. Si el bit más significativo está desactivado, se trata de una operación de solicitud. En caso contrario, es una respuesta.
command_status
Siempre tiene un valor de 0 en las solicitudes; en las respuestas contiene información sobre el resultado de la operación.
sequence_number
Se utiliza para correlacionar solicitudes y respuestas dentro de una sesión SMPP; permite la comunicación asíncrona (mediante un método de ventana deslizante ).

Todos los campos numéricos en SMPP utilizan el orden big-endian , lo que significa que el primer octeto es el byte más significativo (MSB).

Ejemplo

Este es un ejemplo de la codificación binaria de una PDU submit_sm de 60 octetos . Los datos se muestran en valores hexadecimales de octetos como un único volcado, seguido de un desglose del encabezado y el cuerpo de dicha PDU.

Esto se compara mejor con la definición de la PDU submit_sm de la especificación SMPP para comprender cómo la codificación coincide con la definición campo por campo.

El desglose de valores se muestra con los valores decimales entre paréntesis y los valores hexadecimales a continuación. Si ve uno o varios octetos hexadecimales añadidos, es porque el tamaño del campo especificado utiliza una codificación de uno o más octetos.

Una vez más, leer la definición de la PDU submit_sm en la especificación aclarará todo esto.

Encabezado PDU

'longitud_comando', (60) ... 00 00 00 3C 'command_id', (4) ... 00 00 00 04 'estado_comando', (0) ... 00 00 00 00 'número_de_secuencia', (5) ... 00 00 00 05

Cuerpo de la PDU

'service_type', () ... 00 'source_addr_ton', (2) ... 02 'source_addr_npi ' , (8) ... 08 'source_addr', (555) ... 35 35 35 00 'dest_addr_ton', (1) ... 01 'dest_addr_npi ' , (1) ... 01 'dest_addr', (555555555) ... 35 35 35 35 35 35 35 35 35 00 'esm_class', (0) ... 00 'protocol_id', (0) ... 00 'priority_flag', (0) ... 00 'horario_de_entrega_programado', (0) ... 00 'período_de_validez', (0) ... 00 'entrega_registrada', (0) ... 00 'reemplazar_si_está_presente_bandera', (0) ... 00 'data_coding', (3) ... 03 'sm_default_msg_id', (0) ... 00 'sm_length', (15) ... 0F 'mensaje_corto', (Hola Wikipedia) ... 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61

Tenga en cuenta que el texto en el campo short_message debe coincidir con el data_coding. Cuando data_coding es 8 (UCS2), el texto debe estar en UCS-2BE (o su extensión, UTF-16BE ). Cuando data_coding indica una codificación de 7 bits, cada septeto se almacena en un octeto separado en el campo short_message (con el bit más significativo establecido en 0). El data_coding de SMPP 3.3 copió exactamente los valores TP-DCS de GSM 03.38 , lo que lo hace adecuado solo para el alfabeto predeterminado de 7 bits de GSM, UCS2 o mensajes binarios; SMPP 3.4 introdujo una nueva lista de valores de data_coding:

El significado de data_coding=4o 8es el mismo que en SMPP 3.3. Otros valores en el rango 1-15 están reservados en SMPP 3.3. Desafortunadamente, a diferencia de SMPP 3.3, donde data_coding=0 era inequívocamente el alfabeto predeterminado GSM de 7 bits, para SMPP 3.4 y superior el alfabeto predeterminado GSM de 7 bits no está en esta lista y data_coding=0puede diferir para varios centros de servicio de mensajes cortos : puede ser ISO-8859-1 , ASCII , alfabeto predeterminado GSM de 7 bits, UTF-8 o incluso configurable por ESME. Al usar data_coding=0, ambas partes (ESME y SMSC) deben asegurarse de que lo consideran la misma codificación. De lo contrario, es mejor no usar data_coding=0. Puede ser complicado usar el alfabeto predeterminado GSM de 7 bits, algunos centros de servicio de mensajes cortos requieren data_coding=0, otros, por ejemplo data_coding=241.

Peculiaridades

A pesar de su amplia aceptación, el SMPP presenta una serie de características problemáticas:

  • No existe un valor estandarizado data_codingpara el alfabeto predeterminado de GSM.
  • No existe un significado estandarizado dedata_coding=0
  • Soporte poco claro para la codificación Shift-JIS
  • Incompatibilidad submit_sm_respentre versiones de SMPP
  • Uso de recibos de entrega de SMSC de SMPP 3.3, especialmente el formato de ID de mensaje en ellos

No existe un valor de codificación de datos estandarizado para el alfabeto predeterminado de GSM.

Aunque data_codinglos valores en SMPP 3.3 se basan en GSM 03.38 , desde SMPP 3.4 no existe un data_codingvalor estandarizado para el alfabeto predeterminado de GSM ( GSM 03.38 ). Además, resulta ambiguo si los caracteres de 7 bits se empaquetan, como en GSM, lo que permite enviar 160 caracteres en 140 octetos, o si cada carácter de 7 bits se codifica como un octeto completo (con el bit más significativo a cero, como en ASCII).

No existe un significado estandarizado para data_coding=0.

Según SMPP 3.4 y 5.0, el valor data_coding=0significa "Alfabeto predeterminado de SMSC". La codificación real depende del tipo de SMSC y su configuración.

Soporte poco claro para la codificación Shift-JIS

Una de las codificaciones del estándar CDMA C.R1001 es Shift-JIS, que se utiliza para el japonés. SMPP 3.4 y 5.0 especifican tres codificaciones para el japonés (JIS, ISO-2022-JP y JIS Kanji extendido), pero ninguna coincide con CDMA MSG_ENCODING 00101. Parece que la codificación de pictogramas (data_coding=9) se utiliza para transmitir los mensajes en Shift-JIS en SMPP.

Incompatibilidad de submit_sm_resp entre versiones de SMPP

Cuando falla un submit_sm, el SMSC devuelve un submit_sm_respvalor distinto de cero para command_status y un message_id "vacío".

  • SMPP 3.3 establece explícitamente que message_id field"Si no está presente, este campo debe contener un único byte NULL". La longitud de la PDU es de al menos 17 octetos.
  • SMPP 3.4 contiene una nota desafortunada en la SUBMIT_SM_RESPsección "El submit_sm_respcuerpo de la PDU no se devuelve si el command_statuscampo contiene un valor distinto de cero". En ese caso, la longitud de la PDU es de 16 octetos.
  • SMPP 5.0 simplemente especifica que message_ides un parámetro obligatorio del tipo cadena de octetos C del submit_sm_respmensaje. Según la sección 3.1.1 Configuración de NULL, "Una cadena NULL" se codifica como 0x00. La longitud de la PDU es de al menos 17 octetos.

Para una compatibilidad óptima, cualquier implementación de SMPP debería aceptar ambas variantes negativas, submit_sm_respindependientemente de la versión del estándar SMPP utilizada para la comunicación.

La intención original de los escenarios de error era que no se devolviera ningún cuerpo en la respuesta PDU. Este era el comportamiento estándar exhibido en todos los SMSC de Aldiscon/Logica y también en la mayoría de los demás proveedores. Cuando el foro WAP adoptó SMPP 3.4, se solicitaron varias aclaraciones sobre si se debía incluir un cuerpo con la respuesta NACKed y se tomaron medidas para aclarar esto en varios lugares de la especificación, incluyendo la submit_smsección y también en la bind_transceiversección. Lo que se debería haber hecho era agregar la aclaración que finalmente agregamos en V5.0... que los cuerpos no deben incluirse en las respuestas de error. Algunos proveedores han sido muy desacertados en sus implementaciones incluyendo cuerpos en bind_transmitterrespuestas rechazadas pero no en bind_transceiverrespuestas, etc. La recomendación que haría a los proveedores... como se sugirió anteriormente... es que acepten ambas variantes. Pero también es prudente permitirse emitir PDU NACKed submit_sm_respy deliver_sm_respcon y sin un cuerpo vacío. En el caso de estas dos PDU, ese cuerpo vacío se verá como un solo octeto NULL al final del flujo. La razón por la que podría necesitar esta capacidad de incluir lo que yo llamo cuerpos ficticios con solicitudes NACK es que la otra parte de la ecuación podría no ser capaz o no estar dispuesta a modificar su implementación para tolerar la ausencia del cuerpo. (Trabajé en tres versiones de la especificación SMPP en Aldiscon/Logica y diseñé la solución ESME para Openmind Networks).

— Cormac Long

Identificador de mensaje en SMPP 3.3 Recibos de entrega de SMSC

La única forma de pasar recibos de entrega en SMPP 3.3 es introducir información en formato de texto en el short_messagecampo; sin embargo, el formato del texto se describe en el Apéndice B de SMPP 3.4, aunque SMPP 3.4 puede (y debería) usar receipted_message_idTLV message_statepara este propósito. Mientras que SMPP 3.3 establece que el ID del mensaje es una cadena de octetos C (hexadecimal) de hasta 8 caracteres (más el carácter de terminación '\0'), la especificación SMPP 3.4 establece que el campo id en el formato del recibo de entrega es una cadena de octetos C (decimal) de hasta 10 caracteres. Esto divide las implementaciones de SMPP en 2 grupos:

  • Implementaciones que utilizan la representación decimal de un ID de mensaje entero en el campo id del cuerpo del recibo de entrega y la representación hexadecimal de un ID de mensaje entero en los campos message_idyreceipted_message_id
  • Implementaciones que utilizan el mismo número hexadecimal (o incluso la misma cadena arbitraria) tanto en el message_idparámetro como en el campo id del cuerpo del recibo de entrega.

Sin embargo, la especificación SMPP 3.4 indica que el formato del acuse de recibo depende del proveedor del SMSC, por lo que el formato incluido en la especificación es solo una posibilidad. Como se mencionó anteriormente, al usar SMPP 3.4, receipted_message_idse message_statedeben utilizar TLV para transmitir el resultado de un mensaje.

Extensibilidad, compatibilidad e interoperabilidad

Desde la introducción de los parámetros TLV en la versión 3.4, el SMPP puede considerarse un protocolo extensible . Para lograr el mayor grado posible de compatibilidad e interoperabilidad, cualquier implementación debe aplicar el principio de robustez de Internet : «Sea conservador en lo que envía, sea liberal en lo que recibe». Debe utilizar un conjunto mínimo de características necesarias para realizar una tarea. Y si el objetivo es la comunicación y no las discusiones, cada implementación debe superar las pequeñas desviaciones del estándar.

  • Responda con un " generic_nackwith command_status=3" a cualquier comando SMPP no reconocido, pero no detenga la comunicación.
  • Ignore cualquier parámetro TLV no reconocido, inesperado o no compatible.
  • Los límites de las PDU siempre vienen definidos por sus command_lengthcampos. Ningún campo de mensaje debe sobrepasar el final de la PDU. Si un campo no se completa correctamente, se considera truncado al final de la PDU y no afecta a las PDU posteriores.

La información aplicable a una versión de SMPP a menudo se puede encontrar en otra versión de SMPP, por ejemplo, en el caso de SMPP 3.4, que describe el único mecanismo de recibos de entrega en SMPP 3.3 descrito anteriormente.

Seguridad

El protocolo SMPP está diseñado sobre un protocolo binario de texto plano, lo cual debe tenerse en cuenta si se utiliza para información potencialmente sensible, como contraseñas de un solo uso enviadas por SMS. Sin embargo, existen implementaciones de SMPP sobre SSL/TLS si fuera necesario. [ 7 ]

Véase también

Referencias

  1. ↑ "GSM 03.40 Realización técnica del Servicio de Mensajes Cortos (SMS)" , 3GPP , 3 de diciembre de 2003
  2. ↑ "Especificación del protocolo de mensajes cortos entre pares v5.0" (PDF) .
  3. ↑ Friedhelm Hillebrand (2010). Servicio de mensajes cortos (SMS): La creación de la mensajería de texto global personal . Wiley . pág. 112. ISBN  978-0-470-68865-6.
  4. ↑ "Página principal del foro de SMS" . smsforum.net . Archivado del original el 22/12/2007.
  5. ↑ Neil Croft (2012). "Sobre análisis forense: Un ataque silencioso por SMS". 2012 Information Security for South Africa . IEEE . pp. 1–4 . doi : 10.1109/ISSA.2012.6320454 . ISBN  978-1-4673-2159-4ISSN 2330-9881 . S2CID 13448347 .​  
  6. ↑ A. Henry-Labordère; Vincent Jonack (2004). Interoperabilidad de SMS y MMS en redes móviles . Artech House . págs. 137–138 . ISBN  1-58053-890-8.
  7. ↑ "Protocolo seguro de mensajería corta entre pares" , Revista Internacional de Estudios de Comercio Electrónico, 2012
  • Especificación del protocolo de mensajes cortos punto a punto v3.3
  • Especificación del protocolo de mensajes cortos punto a punto v3.4
  • Especificación del protocolo de mensajes cortos punto a punto v5.0
  • Guía de implementación del protocolo SMPP v3.4 para GSM / UMTS
  • Guía de implementación de SMPP v3.4 para WAP
  • SMPP implementado en Java
  • SMPP Wireshark