Mensaje corto punto a punto

Short Message Peer-to-Peer (SMPP) en la industria de las telecomunicaciones es un protocolo abierto 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 entre entidades externas de mensajes cortos (ESME), entidades de enrutamiento (RE) y SMSC.

SMPP se usa a menudo para permitir que terceros (p. ej., proveedores de servicios de valor agregado, como organizaciones de noticias) envíen mensajes, a menudo de forma masiva, pero también se puede usar para la interconexión de SMS. SMPP puede transmitir 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 compatibilidad con protocolos SMS no 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 luego fue adquirida por Logica (desde 2016, después de una serie de cambios de 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, más tarde renombrado como The SMS Forum y ahora disuelto. Como parte de los términos de traspaso originales, la propiedad de SMPP ahora ha regresado a Mavenir debido a la disolución de SMS Forum.

Hasta la fecha, el desarrollo de SMPP está suspendido y SMS Forum está disuelto. Desde el sitio web del foro de SMS:

31 de julio de 2007 - El Foro de SMS, organización sin ánimo de lucro con misión de desarrollar, fomentar y promover SMS (servicio de mensajes cortos) en beneficio de la industria inalámbrica mundial se disolverá para el 27 de julio de 2007.

Un comunicado de prensa, adjunto a la noticia, solía advertir que el sitio se suspenderá pronto. A pesar de esto, el sitio funcionaba en su mayor parte y las especificaciones se podían descargar (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, la ETSI incluyó el protocolo SMPP en el informe técnico TR 03.39.

Operación

Al contrario de su nombre, el SMPP utiliza el modelo de operación cliente-servidor. El Centro de servicio de mensajes cortos (SMSC) suele actuar como un servidor, a la espera de conexiones de las ESME. Cuando se usa SMPP para emparejamiento de SMS, el MC emisor generalmente actúa como un 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 OSI capa 4 (sesión TCP o X.25 SVC3). El puerto bien conocido asignado por la IANA para SMPP cuando se opera a través de TCP es 2775, pero a menudo se usan múltiples números de puerto arbitrarios en entornos de mensajería.

Antes de intercambiar cualquier mensaje, se debe enviar y reconocer 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. En el comando bind, 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 asíncrono, donde se pueden emitir múltiples solicitudes sin esperar y 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 de comunicación deben configurarse con el mismo tamaño de ventana.

Versiones

El estándar SMPP ha evolucionado a lo largo del tiempo. Las versiones más utilizadas de SMPP son:

• SMPP 3.3 la versión utilizada más antigua (a pesar de sus limitaciones, todavía es ampliamente utilizada); admite GSM solamente. Genera una respuesta inmediata para cada mensaje enviado.
• SMPP 3.4 añade parámetros opcionales de valor tag–length–valor (TLV), soporte de tecnologías SMS no GSM y soporte transceptor (conexiones individuales que pueden enviar y recibir mensajes). El intercambio de PDUs de solicitud y respuesta SMPP entre un transmisor de ESME y SMSC puede ocurrir de forma sincronizada o asincrónica.
• SMPP 5.0 es la última versión de SMPP; añade soporte para transmisión celular, control de flujo inteligente. A partir de 2019, no es ampliamente utilizado.

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

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 al que puede seguir un cuerpo:

Encabezado de 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 general del PDU en octets (incluido el campo command_length en sí mismo); debe ser ≥ 16 ya que cada PDU debe contener el encabezado de 16 octet

command_id

Identifica la operación SMPP (o comando). Si el bit más significativo es aclarado, esta es una operación de solicitud. De lo contrario es una respuesta.

command_status

Siempre tiene un valor de 0 en solicitudes; en respuestas lleva 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 asincrónica (utilizando 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 de octetos hexadecimales como un único volcado, seguidos de un encabezado y un desglose del cuerpo de esa PDU.

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

Los desgloses de valores se muestran con decimales entre paréntesis y 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 codificación de 1 o más octetos.

Nuevamente, leer la definición de la PDU de submit_sm de la especificación aclarará todo esto.

Encabezado de PDU

'command_length', (60)... 00 00 3C
'command_id', (4)... 00 00 04
'command_status', (0)... 00 00 00 00
'sequence_number', (5)... 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 00
'dest_addr_ton', (1)... 01
'dest_addr_npi', (1)... 01
'dest_addr', (555555555)... 35 35 35 35 35 35 35 35 00
Esm_class, (0)... 00
'protocol_id', (0)... 00
'priority_flag', (0)... 00
'schedule_entreguey_time', (0)... 00
'validity_period', (0)... 00
'registered_entreguey', (0)... 00
'replace_if_present_flag', (0)... 00
'data_coding', (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 en el campo short_message debe coincidir con la codificación de datos. 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). 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 GSM de 7 bits, UCS2 o mensajes binarios; SMPP 3.4 introdujo una nueva lista de valores de codificación de datos:

El significado de data_coding=4 o 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 GSM de 7 bits, para SMPP 3.4 y versiones posteriores, el alfabeto predeterminado GSM de 7 bits no se encuentra 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. Al usar data_coding=0, ambos lados (ESME y SMSC) deben asegurarse de que lo consideren 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, p. data_coding=241.

Extravagancias

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

• No data_coding para el alfabeto predeterminado GSM 7-bit
• No significado estandarizado data_coding=0
• Apoyo a la codificación Shift-JIS
• Incompatibilidad de submit_sm_resp entre versiones SMPP
• Uso de recibos SMPP 3.3 SMSC Entrega, especialmente el Mensaje Formato Id 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 hay ningún valor de codificación de datos para el alfabeto de 7 bits de GSM (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. Es aún más ambiguo si el alfabeto de 7 bits está empaquetado, como en GSM, lo que permite enviar 160 caracteres en 140 octetos, o si cada carácter de 7 bits ocupa un octeto completo (con el bit alto establecido en cero, como con ASCII).).

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 realmente es 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 especifican 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 Pictogram (data_coding=9) se usa 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 ″vacío″ message_id.

• SMPP 3.3 declara explícitamente sobre message_id field "Si ausente este campo debe contener un solo byte NULL." La longitud del PDU es al menos 17 octets.
• SMPP 3.4 contiene una nota desafortunada en el SUBMIT_SM_RESP sección ′ submit_sm_resp PDU El cuerpo no es devuelto si el command_status campo contiene un valor no cero. Luego la longitud del PDU es de 16 octets.
• SMPP 5.0 especifica que message_id es un parámetro obligatorio de la cadena C-Octet tipo submit_sm_resp Mensaje. De acuerdo con la sección 3.1.1 Ajustes NULL, "Una cadena NULL "" es codificada como 0x00′′. La longitud del PDU es al menos 17 octets.

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 utilizado para la comunicación.

La intención original de los escenarios de error era que ningún cuerpo sería devuelto en la respuesta de PDU. Este fue el comportamiento estándar expuesto en todos los SMSC Aldiscon/Logica y también en la mayoría de los otros proveedores. When SMPP 3.4 was being taken on by the WAP forum, several clarifications were requested on whether a body should be included with NACKed response and measures were taken to clarify this in several places in the specification including the submit_sm y también en la bind_transceiver sección. Lo que debería haber sido hecho era añadir la aclaración que eventualmente añadimos en V5.0. que los cuerpos no se supone que se incluyan en respuestas de error. Algunos proveedores han sido muy tontos en sus implementaciones, incluyendo cuerpos sobre rechazados bind_transmitter respuestas pero no bind_transceiver respuestas, etc. La recomendación que haría a los proveedores.. como se sugirió anteriormente. aceptar ambas variantes. Pero su también sabio para permitirse emitir NACKed submit_sm_resp y deliver_sm_resp PDUs con y sin cuerpo vacío. En el caso de estos dos PDU, ese cuerpo vacío se verá como un único octeto NULL al final de la corriente. La razón por la que usted puede necesitar esta capacidad para incluir lo que yo llamo cuerpos dummy con solicitudes NACKed es que el otro lado de la ecuación puede ser incapaz o no dispuesto a cambiar su implementación para tolerar el cuerpo desaparecido. (Trabajé en tres versiones de especificación SMPP en Aldiscon/Logica y diseñé la solución ESME para Openmind Networks)

—Cormac Long

ID de mensaje en SMPP 3.3 Recibos de entrega de SMSC

La única forma de pasar recibos de entrega en SMPP 3.3 es colocar 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) usar los TLV receipted_message_id y message_state para este fin. Mientras que SMPP 3.3 establece que el ID del mensaje es una cadena de octeto C (hexadecimal) de hasta 8 caracteres (más la terminación '