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 [1] entre entidades externas de mensajería corta (ESME) y 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 de forma masiva, pero también se puede utilizar para el emparejamiento de SMS. SMPP puede transmitir mensajes cortos , incluidos EMS , notificaciones de correo de voz , transmisiones celulares , mensajes WAP , incluidos mensajes WAP Push (utilizados para entregar notificaciones MMS ), mensajes USSD y otros. Debido a su versatilidad y soporte para protocolos SMS no 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 .
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 utilizar el equipo 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 SMPP Developers Forum, más tarde rebautizado como The SMS Forum.
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) en beneficio de la industria inalámbrica global, se disolverá el 27 de julio. 2007." [4] Como parte de los términos de traspaso originales, la propiedad del SMPP volvió a Mavenir.
SMPP utiliza el modelo de operación cliente-servidor , a pesar de que el nombre dice "peer-to-peer". El Centro de Servicios de Mensajes Cortos (SMSC) suele actuar como servidor, a la espera de conexiones de las ESME. Cuando se utiliza SMPP para el emparejamiento 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 OSI de capa 4 ( sesión TCP o X.25 SVC3). [5] El puerto bien 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 cualquier mensaje, se debe enviar y confirmar un comando de vinculación. El comando de vinculación 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 de vinculación, la ESME se identifica usando 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 de vinculación 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 confirmadas 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.
El estándar SMPP ha evolucionado a lo largo del tiempo. Las versiones de SMPP más utilizadas son:
La versión aplicable se pasa en el parámetro interface_version de un comando de vinculación.
Las PDU SMPP están codificadas en binario para mayor eficiencia. Comienzan con un encabezado al que puede seguir un cuerpo:
Cada PDU comienza con un encabezado. El encabezado consta de 4 campos, cada uno de 4 octetos de longitud:
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 submit_sm de 60 octetos . Los datos se muestran en valores de octeto hexadecimal como un volcado único y seguido 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 la definición campo por campo.
Los desgloses de valores se muestran con decimales entre paréntesis y valores hexadecimales después. Cuando ve uno o varios octetos hexadecimales añadidos, 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 PDU submit_sm de la especificación aclarará todo esto.
'longitud_comando', (60) ... 00 00 00 3C'id_comando', (4) ... 00 00 00 04'estado_comando', (0) ... 00 00 00 00'número_secuencia', (5) ... 00 00 00 05
'tipo_servicio', () ... 00'fuente_addr_ton', (2) ... 02'source_addr_npi ' , (8) ... 08'dirección_fuente', (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'protocolo_id', (0) ... 00'bandera_prioridad', (0) ... 00'horario_entrega_hora', (0) ... 00'periodo_validez', (0) ... 00'entrega_registrada', (0) ... 00'reemplazar_si_presente_flag', (0) ... 00'codificación_datos', (3) ... 03'sm_default_msg_id', (0) ... 00'pequeña_longitud', (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 el 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 GSM predeterminados de 7 bits, UCS2 o binarios; SMPP 3.4 introdujo una nueva lista de valores de codificación de datos:
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 GSM predeterminado de 7 bits, para SMPP 3.4 y superiores el alfabeto GSM predeterminado de 7 bits no está en esta lista y data_coding=0puede diferir para varios centros de servicios de mensajes cortos ; puede ser ISO-8859-1 , ASCII , alfabeto predeterminado GSM de 7 bits, UTF-8 o incluso configurable por ESME. Al utilizar data_coding=0, ambas partes (ESME y SMSC) deben asegurarse de considerarlo la misma codificación. De lo contrario es mejor no usarlo data_coding=0. Puede resultar complicado utilizar el alfabeto GSM predeterminado de 7 bits; algunos centros de servicios de mensajes cortos lo 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 alfabeto predeterminado GSM de 7 bitsdata_coding=0submit_sm_respentre versiones de SMPPAunque 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 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. 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 puesto a cero, como en ASCII). ).
Según SMPP 3.4 y 5.0, data_coding=0significa "Alfabeto predeterminado de SMSC". La codificación real 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 el 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 Pictogram (data_coding=9) se usa para transportar el mensajes en Shift-JIS en SMPP.
Cuando falla submit_sm, el SMSC devuelve un submit_sm_respvalor distinto de cero de command_status y ″empty″ message_id.
message_id field″Si está ausente, este campo debe contener un único byte NULL″. 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 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 SMPP debe aceptar ambas variantes de negativo submit_sm_respindependientemente de la versión del estándar SMPP utilizado 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 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 estaba adoptando SMPP 3.4, se solicitaron varias aclaraciones sobre si un cuerpo debería incluirse con una 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 debería haberse hecho fue agregar la aclaración que finalmente agregamos en V5.0... de que se supone que los cuerpos no deben incluirse en las respuestas de error. Algunos proveedores han sido muy tontos en sus implementaciones, incluyendo organismos en lasbind_transmitterrespuestas rechazadas pero no enbind_transceiverlas respuestas, etc. La recomendación que haría a los proveedores... como se sugirió anteriormente... acepten ambas variantes. Pero también es aconsejable permitirse emitir NACKsubmit_sm_respydeliver_sm_respPDU con y sin cuerpo vacío. En el caso de estas dos PDU, ese cuerpo vacío se verá como un único octeto NULL al final de la secuencia. La razón por la que es posible que necesite esta capacidad para incluir lo que yo llamo cuerpos ficticios con solicitudes NACKed 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 colocar información en forma de texto en el short_messagecampo; sin embargo, el formato del texto se describe en el Apéndice B del SMPP 3.4, aunque el SMPP 3.4 puede (y debe) usar receipted_message_idTLV message_statepara este propósito. 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 '\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 octeto C (Decimal) de hasta 10 caracteres. Esto divide las implementaciones de SMPP en 2 grupos:
message_idyreceipted_message_idmessage_idparámetro como en el campo id del cuerpo del recibo de entregaSin 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 utiliza SMPP 3.4 receipted_message_idy message_statese deben 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 solidez de Internet : "Sea conservador en lo que envía, sea liberal en lo que acepta". Debe utilizar un conjunto mínimo de funciones 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:
generic_nackwith command_status=3a cualquier comando SMPP no reconocido, pero no detenga la comunicación.command_lengthcampo de las PDU. Cualquier campo de mensaje no 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 debería 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.
El protocolo SMPP está diseñado en 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]