Short Message Peer-to-Peer ( SMPP ) en la industria de las telecomunicaciones es un protocolo estándar de la industria abierto diseñado para proporcionar una interfaz de comunicación de datos flexible para la transferencia de datos de mensajes cortos [1] entre entidades externas de mensajería corta (ESMEs), entidades de enrutamiento (REs) y SMSC . [2]
SMPP se usa a menudo para permitir que terceros (por ejemplo , proveedores de servicios de valor agregado como organizaciones de noticias) envíen mensajes, a menudo en forma masiva, pero también se puede usar para peering SMS. SMPP puede transportar mensajes cortos, incluidos EMS , notificaciones de correo de voz , transmisiones celulares , mensajes WAP , incluidos mensajes WAP Push (utilizados para enviar notificaciones MMS ), mensajes USSD y otros. Debido a su versatilidad y soporte para protocolos SMS que no son GSM , como UMTS , IS-95 (CDMA), CDMA2000 , ANSI-136 (TDMA) e iDEN , SMPP es el protocolo más comúnmente 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 luego fue adquirida por Logica (desde 2016, después de una serie de cambios Mavenir ). El protocolo fue creado originalmente por un desarrollador, Ian J Chambers, para probar la funcionalidad del SMSC sin usar el equipo de prueba SS7 para enviar mensajes. En 1999, Logica entregó formalmente SMPP al SMPP Developers Forum, que luego se renombró como The SMS Forum y ahora se disolvió. Como parte de los términos de transferencia originales, la propiedad de SMPP ahora ha regresado a Mavenir debido a la disolución del Foro SMS.
Hasta la fecha, el desarrollo de SMPP está suspendido y SMS Forum se disuelve. Desde el sitio web de SMS Forum:
31 de julio de 2007 - El Foro SMS, una organización sin fines de lucro con la misión de desarrollar, fomentar y promover SMS (servicio de mensajes cortos) en beneficio de la industria inalámbrica global, se disolverá el 27 de julio de 2007.
Un comunicado de prensa, adjunto a la noticia, se utiliza para advertir que el sitio se suspenderá pronto. A pesar de esto, el sitio funcionaba en su mayor parte y se podían descargar las especificaciones (al 31 de enero de 2012). A partir del 12 de abril de 2021, el propietario del sitio web ha cambiado y las especificaciones solo se pueden descargar desde sitios espejo.
En 1995, el ETSI incluyó el protocolo SMPP en el informe técnico TR 03.39. [3]
Operación
Contrario a su nombre, el SMPP utiliza el modelo de operación cliente-servidor . El Centro de servicios de mensajes cortos (SMSC) generalmente actúa como un servidor, a la espera de las conexiones de los ESMEs. Cuando se utiliza SMPP para emparejamiento de SMS, el MC emisor suele actuar como cliente.
El protocolo se basa en pares de PDU de solicitud / respuesta ( unidades de datos de protocolo o paquetes) intercambiados a través de conexiones de capa 4 de OSI ( sesión TCP o X.25 SVC3). [4] El puerto conocido asignado por la IANA para SMPP cuando se opera sobre TCP es 2775, pero a menudo se utilizan varios números de puerto arbitrarios en entornos de mensajería.
Antes de intercambiar cualquier mensaje, se debe enviar y acusar recibo de un comando de vinculación. 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. [5] En el comando bind, el ESME se identifica mediante system_id, system_type y contraseña; el campo address_range diseñado para contener la dirección 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 par espera una respuesta para cada PDU que se envía, o asincrónico, donde se pueden emitir múltiples solicitudes sin esperar y ser reconocidas en un orden sesgado por el otro par; el número de solicitudes no reconocidas se denomina ventana ; para obtener el mejor rendimiento, ambos lados comunicantes deben configurarse con el mismo tamaño de ventana.
Versiones
El estándar SMPP ha evolucionado durante el tiempo. Las versiones de SMPP más utilizadas son:
- SMPP 3.3 la versión usada más antigua (a pesar de sus limitaciones, todavía se usa ampliamente); solo admite GSM . Genera una respuesta inmediata por cada mensaje enviado.
- SMPP 3.4 agrega parámetros opcionales de valor de longitud de etiqueta (TLV), compatibilidad con tecnologías SMS no GSM y compatibilidad con transceptor (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 ocurrir de forma sincrónica o asincrónica.
- SMPP 5.0 es la última versión de SMPP; agrega soporte para radiodifusión celular, control de flujo inteligente. A partir de 2019, no se usa ampliamente.
La versión aplicable se pasa en el parámetro interface_version de un comando bind.
Formato PDU (después de la versión 3.4)
Las PDU SMPP están codificadas en binario para mayor eficiencia. Comienzan con un encabezado que puede ir seguido de un cuerpo:
PDU SMPP | ||||
Encabezado de la PDU (obligatorio) | Cuerpo de la PDU (opcional) | |||
Longitud del comando | ID de comando | Estado del comando | Número de secuencia | Cuerpo de la PDU |
4 octetos | Longitud = (valor de longitud del comando - 4) octetos |
Encabezado de la PDU
Cada PDU comienza con un encabezado. El encabezado consta de 4 campos, cada uno de 4 octetos de longitud:
- command_length
- Es la longitud total de la PDU en octetos (incluido el propio campo command_length); debe ser ≥ 16 ya que cada PDU debe contener el encabezado de 16 octetos
- command_id
- Identifica la operación (o comando) SMPP. Si se borra el bit más significativo, se trata de una operación de solicitud. De lo contrario, es una respuesta.
- command_status
- Siempre tiene un valor de 0 en las solicitudes; en las respuestas lleva información sobre el resultado de la operación
- secuencia de números
- Se utiliza para correlacionar solicitudes y respuestas dentro de una sesión SMPP; permite la comunicación asíncrona (utilizando un método de ventana deslizante )
Todos los campos numéricos en SMPP usan 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 de octetos hexadecimales como un solo volcado y seguidos de un desglose del encabezado y el cuerpo de esa 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 el campo por definición de campo.
Los desgloses de valores se muestran con decimal entre paréntesis y los valores hexadecimales después de eso. Cuando vea uno o varios octetos hexadecimales adjuntos, esto se debe a que el tamaño de campo dado utiliza una codificación de 1 o más octetos.
Nuevamente, leer la definición de la PDU submit_sm de la especificación aclarará todo esto.
Encabezado de la PDU
'longitud_comando', (60) ... 00 00 00 3C'command_id', (4) ... 00 00 00 04'estado_comando', (0) ... 00 00 00 00'número_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'clase_esm', (0) ... 00'id_protocolo', (0) ... 00'bandera_prioridad', (0) ... 00'schedule_delivery_time', (0) ... 00'período_validez', (0) ... 00'entrega_registrada', (0) ... 00'replace_if_present_flag', (0) ... 00'codificación_datos', (3) ... 03'sm_default_msg_id', (0) ... 00'sm_length', (15) ... 0F'short_message', (Hola Wikipedia) ... 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61
Tenga en cuenta que el texto del campo short_message debe coincidir con 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 puesto a 0). La codificación de datos 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 GSM, UCS2 o mensajes binarios; SMPP 3.4 introdujo una nueva lista de valores de codificación de datos:
Codificación de datos | Significado |
---|---|
0 | Alfabeto predeterminado de SMSC (SMPP 3.4) / Específico de MC (SMPP 5.0) |
1 | IA5 ( CCITT T.50 ) / ASCII (ANSI X3.4) |
2 | Octeto no especificado (binario de 8 bits) |
3 | Latín 1 ( ISO-8859-1 ) |
4 | Octeto no especificado (binario de 8 bits) |
5 | JIS ( X 0208-1990 ) |
6 | Cirílico ( ISO-8859-5 ) |
7 | Latín / hebreo ( ISO-8859-8 ) |
8 | UCS2 ( ISO / IEC-10646 ) |
9 | Codificación de pictogramas |
10 | ISO-2022-JP (Códigos de música) |
11 | Reservado |
12 | Reservado |
13 | Kanji extendido JIS (X 0212-1990) |
14 | KS C 5601 |
15-191 | reservado |
192-207 | Control GSM MWI - ver GSM 03.38 |
208-223 | Control GSM MWI - ver GSM 03.38 |
224-239 | reservado |
240-255 | Control de clase de mensaje GSM - ver GSM 03.38 |
El significado de data_coding = 4 u 8 es 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 de 7 bits GSM, para SMPP 3.4 y superior, el alfabeto predeterminado de GSM de 7 bits falta en esta lista, y data_coding = 0 puede 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. Cuando se usa data_coding = 0 , ambos lados (ESME y SMSC) deben asegurarse de considerarlo como la misma codificación. De lo contrario, es mejor no utilizar data_coding = 0 . Puede resultar complicado utilizar el alfabeto predeterminado de 7 bits GSM, 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 tiene una serie de características problemáticas:
- Sin codificación de datos para el alfabeto predeterminado GSM de 7 bits
- Significado no estandarizado de data_coding = 0
- Soporte poco claro para la codificación Shift-JIS
- Incompatibilidad de submit_sm_resp entre versiones de SMPP
- Uso de recibos de entrega SMPP 3.3 SMSC, especialmente el formato de ID de mensaje en ellos
Sin codificación de datos para el alfabeto predeterminado GSM de 7 bits
Aunque el valor de codificación de datos en SMPP 3.3 se basa en GSM 03.38 , desde SMPP 3.4 no existe un valor de codificación de datos para el alfabeto GSM de 7 bits ( GSM 03.38 ). Sin embargo, es común que DCS = 0 indique el alfabeto GSM de 7 bits, particularmente para conexiones SMPP a SMSC en redes móviles GSM.
Significado no estandarizado de data_coding = 0
Según SMPP 3.4 y 5.0, data_coding = 0 significa ″ Alfabeto predeterminado de SMSC ″. La codificación que sea realmente depende del tipo de SMSC y su configuración.
Soporte poco claro para la codificación Shift-JIS
Una de las codificaciones en el estándar CDMA C.R1001 es Shift-JIS que se usa para japonés. SMPP 3.4 y 5.0 especifica tres codificaciones para japonés (JIS, ISO-2022-JP y Extended Kanji JIS), pero ninguna de ellas es idéntica a CDMA MSG_ENCODING 00101. Parece que la codificación de pictogramas (data_coding = 9) se utiliza para llevar la mensajes en Shift-JIS en SMPP.
Incompatibilidad de submit_sm_resp entre versiones de SMPP
Cuando un submit_sm falla, el SMSC devuelve un submit_sm_resp con un valor distinto de cero de command_status y un message_id ″ vacío ″.
- SMPP 3.3 establece explícitamente sobre el campo message_id ″ Si está ausente, este campo debe contener un solo byte NULL ″. La longitud de la PDU es de al menos 17 octetos.
- SMPP 3.4 contiene una nota desafortunada en la sección SUBMIT_SM_RESP ″ El cuerpo de la PDU submit_sm_resp no se devuelve si el campo command_status contiene un valor distinto de cero. ″ Entonces la longitud de la PDU es de 16 octetos.
- SMPP 5.0 solo especifica que message_id es un parámetro obligatorio del tipo C-Octet string del mensaje submit_sm_resp . De acuerdo con la sección 3.1.1 Configuración NULL, ″ Una cadena NULL ″ ″ se codifica como 0x00 ″. La longitud de la PDU es de al menos 17 octetos.
Para obtener la mejor compatibilidad, cualquier implementación de SMPP debe aceptar ambas variantes de submit_sm_resp negativo independientemente 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 de la PDU. Este fue el comportamiento estándar exhibido en todos los SMSC de Aldiscon / Logica y también en la mayoría de los otros proveedores. Cuando el foro WAP asumió SMPP 3.4, se solicitaron varias aclaraciones sobre si un organismo debería incluirse con la respuesta NACKed y se tomaron medidas para aclarar esto en varios lugares de la especificación, incluida la sección submit_sm y también en la sección bind_transceiver . Lo que debería haberse hecho fue agregar la aclaración que finalmente agregamos en la V5.0 ... que se supone que los cuerpos no deben incluirse en las respuestas de error. Algunos proveedores han sido muy tontos en sus implementaciones, incluidos los cuerpos en las respuestas de bind_transmitter rechazadas , pero no en las respuestas de bind_transceiver , etc. La recomendación que haría a los proveedores ... como se sugirió anteriormente ... acepte ambas variantes. Pero también es aconsejable permitirse emitir PDU submit_sm_resp y deliver_sm_resp NACKed con y sin un cuerpo vacío. En el caso de estas dos PDU, ese cuerpo vacío se verá como un solo octeto NULO al final del flujo. La razón por la que puede necesitar esta capacidad para incluir lo que yo llamo cuerpos ficticios con solicitudes NACKed es que el otro lado de la ecuación puede ser incapaz o no estar dispuesto a cambiar su implementación para tolerar el cuerpo faltante. (Trabajé en tres versiones de la especificación SMPP en Aldiscon / Logica y diseñé la solución ESME para Openmind Networks)
- Cormac Long
ID de mensaje en recibos de entrega SMPP 3.3 SMSC
La única forma de pasar recibos de entrega en SMPP 3.3 es poner información en forma de texto en el campo short_message ; sin embargo, el formato del texto se describe en el Apéndice B de SMPP 3.4, aunque SMPP 3.4 puede (y debe) utilizar los TLV de Receted_message_id y message_state para este propósito. Si bien SMPP 3.3 establece que el ID de mensaje es una cadena de octetos C (hexadecimal) de hasta 8 caracteres (más la terminación '\ 0'), la especificación SMPP 3.4 establece que el campo de identificación en el formato de 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_id y Receipted_message_id
- Implementaciones que usan el mismo número hexadecimal (o incluso la misma cadena arbitraria) tanto en el parámetro message_id como en el campo id del cuerpo del recibo de entrega
Sin embargo, la especificación SMPP 3.4 establece que el formato del recibo de entrega es específico del proveedor de SMSC y, por lo tanto, el formato incluido en la especificación es simplemente una posibilidad. Como se señaló anteriormente, cuando se usa SMPP 3.4 Receted_message_id y message_state, los TLV deben usarse para transmitir el resultado de un mensaje.
Extensibilidad, compatibilidad e interoperabilidad
Desde la introducción de los parámetros Tag-Length-Value (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 acepta ″. 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 objeciones, cada implementación debe superar las no conformidades menores con el estándar:
- Responda con un generic_nack con command_status = 3 a cualquier comando SMPP no reconocido, pero no detenga la comunicación.
- Ignore los parámetros de TLV no reconocidos, inesperados o no admitidos.
- Los límites de las PDU siempre vienen dados por el campo command_length de las PDU . Ningún campo de mensaje debe exceder el final de la PDU. Si un campo no está correctamente terminado, debe tratarse como truncado al final de la PDU y no debe afectar a otras PDU.
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 en un protocolo binario de texto sin cifrar que debe tenerse en cuenta si se usa para información potencialmente sensible, como contraseñas de un solo uso a través de SMS. Sin embargo, existen implementaciones de SMPP sobre SSL / TLS seguro si es necesario. [6]
Ver también
- Protocolo de computadora universal / Interfaz de máquina externa (UCP / EMI)
- Interfaz de computadora para distribución de mensajes (CIMD)
- Servicios de comunicación enriquecidos
Referencias
- ^ "GSM 03.40 Realización técnica del servicio de mensajes cortos (SMS)" , 3GPP , 2003-12-03
- ^ Especificación del protocolo peer-to-peer de mensajes cortos v5.0
- ^ Friedhelm Hillebrand (2010). Servicio de mensajes cortos (SMS): la creación de mensajes de texto globales personales . Wiley . pag. 112. ISBN 978-0-470-68865-6.
- ^ Neil Croft (2012). "Sobre la ciencia forense: un ataque SMS silencioso" . IEEE . doi : 10.1109 / ISSA.2012.6320454 . ISSN 2330-9881 . Cite journal requiere
|journal=
( ayuda ) - ^ A. Henry-Labordère; Vincent Jonack (2004). Interfuncionamiento de SMS y MMS en redes móviles . Casa Artech . págs. 137-138. ISBN 1-58053-890-8.
- ^ "Protocolo seguro de mensajes cortos de igual a igual" , Revista internacional de estudios de comercio electrónico, 2012
enlaces externos
- SMPP implementado en Java
- SMPP Wireshark