Short Message Peer-to-Peer ( SMPP ) en la industria de las telecomunicaciones es un protocolo industrial estándar abierto 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 organizaciones de noticias) envíen mensajes, a menudo en masa, pero también puede utilizarse para el intercambio de 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 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 .
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 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 entregó formalmente SMPP al Foro de Desarrolladores de SMPP, posteriormente rebautizado como Foro SMS.
El SMS Forum se disolvió en 2007, con este anuncio: "El SMS Forum, una organización sin fines de lucro con la misión de desarrollar, fomentar y promover SMS (servicio de mensajes cortos) para el 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 regresó a Mavenir.
SMPP utiliza el modelo de operación cliente-servidor , a pesar de que el nombre incluye la palabra "peer-to-peer". El Centro de servicio de mensajes cortos (SMSC) generalmente actúa como un servidor, a la espera de conexiones de los ESMEs. Cuando SMPP se utiliza para el intercambio de SMS, el MC que envía normalmente actúa como un cliente.
El protocolo se basa en pares de PDU de solicitud/respuesta ( unidades de datos de protocolo o paquetes) intercambiadas a través de conexiones de capa 4 de OSI ( sesión TCP o X.25 SVC3). [5] El puerto conocido asignado por la IANA para SMPP cuando se opera sobre TCP es 2775, pero a menudo se utilizan múltiples números de puerto arbitrarios en entornos de mensajería.
Antes de intercambiar mensajes, 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 a sí mismo utilizando 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 sincrónico, 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; la cantidad de solicitudes no reconocidas se denomina ventana ; para obtener el mejor rendimiento, ambos lados que se comunican deben estar configurados con el mismo tamaño de ventana.
El estándar SMPP ha evolucionado con el tiempo. Las versiones más utilizadas de SMPP son:
La versión aplicable se pasa en el parámetro interface_version de un comando de enlace.
Las PDU de SMPP están codificadas en binario para lograr mayor eficiencia. Comienzan con un encabezado que puede ir seguido de un cuerpo:
Cada PDU comienza con un encabezado. El encabezado consta de 4 campos, cada uno con una longitud de 4 octetos:
command_lengthcommand_idcommand_statussequence_numberTodos 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).
Este es un ejemplo de codificación binaria de una PDU de 60 octetos con formato submission_sm . Los datos se muestran en valores de octetos hexadecimales como un volcado único, seguido de un desglose del encabezado y el cuerpo de esa PDU.
Esto se compara mejor con la definición de la PDU submission_sm de la especificación SMPP para comprender cómo la codificación coincide con la definición campo por campo.
Los desgloses de valores se muestran con decimales entre paréntesis y valores hexadecimales después. Cuando se ven 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 submission_sm de la especificación hará que todo esto sea más claro.
'longitud_de_comando', (60) ... 00 00 00 3C'id_comando', (4) ... 00 00 00 04'estado_del_comando', (0) ... 00 00 00 00'número_de_secuencia', (5) ... 00 00 00 05
'tipo_de_servicio', () ... 00'dirección_origen_ton', (2) ... 02' dirección_origen_npi ', (8) ... 08'dirección_origen', (555) ... 35 35 35 00'dirección_destino_ton', (1) ... 01' dirección_destino_npi ', (1) ... 01'dirección_destino', (555555555) ... 35 35 35 35 35 35 35 35 35 00'clase_esm', (0) ... 00'id_protocolo', (0) ... 00'bandera_de_prioridad', (0) ... 00'horario_de_entrega', (0) ... 00'periodo_validez', (0) ... 00'entrega registrada', (0) ... 00'reemplazar_si_hay_bandera_presente', (0) ... 00'codificación de datos', (3) ... 03'sm_default_msg_id', (0) ... 00'longitud_sm', (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 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). SMPP 3.3 data_coding copió exactamente los valores TP-DCS de GSM 03.38 , lo que lo hace adecuado solo para mensajes de alfabeto predeterminado GSM de 7 bits, UCS2 o binarios; SMPP 3.4 introdujo una nueva lista de valores 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 de 7 bits GSM, para SMPP 3.4 y superior el alfabeto predeterminado de 7 bits GSM 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 de 7 bits GSM, UTF-8 o incluso configurable por ESME. Al usar data_coding=0, ambas partes (ESME y SMSC) deben estar seguras 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 de 7 bits GSM, algunos centros de servicio de mensajes cortos requieren data_coding=0, otros, por ejemplo data_coding=241.
A pesar de su amplia aceptación, el SMPP tiene una serie de características problemáticas:
data_codingpara el alfabeto predeterminado de 7 bits GSMdata_coding=0submit_sm_respentre versiones de SMPPAunque el valor de data_coding en SMPP 3.3 se basa en GSM 03.38 , desde SMPP 3.4 no hay ningún valor de data_coding 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, en particular para conexiones SMPP a SMSC en redes móviles GSM. Además, es 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 entero (con el bit alto establecido en cero, como con ASCII).
Según SMPP 3.4 y 5.0, data_coding=0significa "Alfabeto predeterminado de SMSC". La codificación en cuestión depende del tipo de SMSC y de su configuración.
Una de las codificaciones del estándar CDMA C.R1001 es Shift-JIS, que se utiliza 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 utiliza para transmitir los mensajes en Shift-JIS en SMPP.
Cuando falla un submission_sm, el SMSC devuelve un mensaje submit_sm_respcon un valor distinto de cero de command_status y un message_id ″vacío″.
message_id field"si no está presente, este campo debe contener un único byte nulo". La longitud de la PDU es de al menos 17 octetos.SUBMIT_SM_RESPsección ″El submit_sm_respcuerpo de la PDU no se devuelve si el command_statuscampo contiene un valor distinto de cero″. Entonces, la longitud de la PDU es de 16 octetos.message_ides un parámetro obligatorio de la cadena de tipo C-Octeto 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 lograr la mejor compatibilidad, cualquier implementación de SMPP debe aceptar ambas variantes del negativo, 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 de PDU. Este era el comportamiento estándar que se exhibía en todos los SMSC de Aldiscon/Logica y también en la mayoría de los otros proveedores. Cuando el foro WAP estaba adoptando SMPP 3.4, se solicitaron varias aclaraciones sobre si se debía incluir un cuerpo con la respuesta NACK y se tomaron medidas para aclarar esto en varios lugares de la especificación, incluida la
submit_smsección y también en labind_transceiversección. Lo que se debería haber hecho era agregar la aclaración que finalmente agregamos en V5.0... que no se supone que se incluyan cuerpos en las respuestas de error. Algunos proveedores han sido muy tontos en sus implementaciones, incluyendo cuerpos enbind_transmitterrespuestas rechazadas pero no enbind_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 NACKsubmit_sm_respydeliver_sm_respPDU con 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 de la secuencia. La razón por la que puede necesitar esta capacidad para incluir lo que yo llamo cuerpos ficticios con solicitudes NACK es que el otro lado de la ecuación puede no poder o no querer 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 [ Esta cita necesita una cita ]
La única forma de pasar recibos de entrega en SMPP 3.3 es poner la 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 debe) utilizar 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 '\0' de terminación), la especificación SMPP 3.4 establece que el campo id 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:
message_idyreceipted_message_idmessage_idel parámetro como en el campo id del cuerpo del recibo de entregaSin embargo, la especificación SMPP 3.4 establece que el formato de recibo de entrega es específico del proveedor de SMSC y, por lo tanto, el formato incluido en la especificación es solo una posibilidad. Como se indicó anteriormente, al utilizar SMPP 3.4, receipted_message_idse message_statedeben utilizar TLV para transmitir el resultado de un mensaje.
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 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 sutilezas, cada implementación debe superar las pequeñas no conformidades con el estándar:
generic_nackwith command_status=3a cualquier comando SMPP no reconocido, pero no detenga la comunicación.command_lengthcampo de la PDU. Ningún campo de mensaje debe exceder el final de la PDU. Si un campo no está correctamente terminado, se lo debe tratar como truncado al final de la PDU y no debe afectar 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.
El protocolo SMPP está diseñado sobre un protocolo binario de texto claro que debe tenerse en cuenta si se utiliza para información potencialmente confidencial, como contraseñas de un solo uso, a través de SMS. Sin embargo, existen implementaciones de SMPP sobre SSL/TLS si es necesario. [7]