SMPP ( Short Message Peer-to-Peer ) es una transmisión punto a punto de mensajes cortos . Es un protocolo abierto en la industria de las telecomunicaciones que está diseñado específicamente para proporcionar una interfaz flexible para la mensajería SMS entre plataformas de aplicaciones SMS ( ESME ), enrutadores (RE) y centros de servicio de mensajes cortos ( SMSC ). [una]
SMPP a menudo es utilizado por terceros, como proveedores de servicios de valor agregado, medios de comunicación, para enviar mensajes SMS , a menudo de forma masiva. Con este protocolo, puede enviar SMS , EMS , notificaciones de correo de voz, difusión celular , mensajes WAP , mensajes USSD , etc. Debido a su versatilidad, que consiste en soportar GSM , UMTS , IS-95 ( CDMA ), CDMA2000 , ANSI 136 ( TDMA ) y similares, SMPP es el protocolo de mensajes cortos más utilizado fuera de las redes SS7 ( SS7 ).
En noviembre de 1995, ETSI incluyó el protocolo SMPP en TR 03.39. [2]
SMPP utiliza un modelo de operación cliente-servidor. El Centro de mensajes ( SMSC ) normalmente actúa como un servidor, esperando una conexión de un cliente: ESME . Cuando se utiliza SMPP para el emparejamiento de SMS, el MC emisor suele actuar como cliente.
El protocolo se basa en el intercambio de pares de PDU de solicitud-respuesta (paquetes o unidades de datos de protocolo) en la 4.ª capa OSI ( sesiones TCP o X25 SVC3). [3] El conocido puerto asignado por la IANA a SMPP cuando se trabaja en TCP es 2775, pero a menudo se utilizan números de puerto arbitrarios.
Antes de intercambiar mensajes, se debe enviar y reconocer el comando de vinculación. El comando bind determina en qué dirección se pueden enviar los mensajes; bind_transmitter permite que el cliente solo envíe mensajes al servidor, bind_receiver significa que el cliente solo recibirá mensajes y bind_transceiver (introducido en SMPP 3.4 [4] ) permite que los mensajes se envíen en ambas direcciones. Al enviar un comando de vinculación, el ESME debe identificarse con los parámetros system_id, system_type y contraseña; address_range pretende indicar una dirección ESME, pero generalmente se pasa vacío. Además, en el comando de enlace está interface_version, que indica la versión del protocolo que se utilizará durante la sesión.
La mensajería puede ser síncrona, donde cada nodo espera una respuesta por PDU, o asíncrona, donde se pueden enviar múltiples solicitudes sin esperar una respuesta; el número de solicitudes no confirmadas se denomina "ventana"; para obtener la mejor experiencia, ambos lados deben tener configuraciones de tamaño de ventana idénticas.
En SMPP, las PDU se codifican en binario para lograr la máxima eficiencia. Comienzan con un encabezado de PDU, al que puede seguir un cuerpo de PDU.
| PDU SMPP | ||||
| Encabezado de PDU (obligatorio) | Cuerpo de PDU (opcional) | |||
| dominio longitud |
dominio IDENTIFICACIÓN |
dominio Estado |
Secuencia IDENTIFICACIÓN |
Cuerpo de la PDU |
| 4 octetos | Longitud = (Valor de longitud de comando - 4) octetos | |||
Cada PDU comienza con un encabezado. El encabezado consta de 4 campos, cada uno de los cuales tiene 4 octetos de longitud.
comando_longitud La longitud total de la PDU en octetos (incluido el propio comando de campo de longitud); el valor mínimo es 16, ya que cada PDU debe contener un encabezado de 16 octetos comando_id Especifica una operación SMPP (o comando) comando_status Establecer siempre en 0 en las consultas; la respuesta contiene 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; proporciona comunicación asíncrona (utilizando el método de "ventana deslizante")Todos los campos numéricos en SMPP se muestran en orden de mayor a menor ( big endian en inglés ), es decir, el primer octeto es el byte más significativo (MSB).
Este es un ejemplo de una PDU submit_sm de 60 octetos . Los datos se muestran en formato hexadecimal. El encabezado y el cuerpo de la PDU se presentan por separado y se dividen en campos de la PDU.
Se recomienda que este ejemplo se compare con la definición de la especificación SMPP de la PDU submit_sm para comprender cómo la codificación de cada campo se ajusta a la especificación.
Los valores para cada campo de PDU se muestran en forma decimal entre paréntesis y en forma hexadecimal después de ellos. Si un campo abarca más de un octeto, todos los octetos hexadecimales correspondientes se representan en una sola línea.
Nuevamente, lea la definición de submit_sm en la especificación SMPP para mayor claridad.
Tenga en cuenta que el formato del texto en el campo short_message debe coincidir con el valor del campo data_coding . Cuando data_coding se establece en 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 como un octeto separado en el campo short_message (con el bit más significativo establecido en 0). Los valores de codificación de datos en la versión 3.3 de SMPP duplican exactamente los valores de TP-DCS del estándar GSM 03.38, lo que hace que esta versión solo sea adecuada para el alfabeto de 7 bits GSM, UCS2 y mensajes binarios. SMPP 3.4 introdujo nuevos valores de codificación de datos :
| Codificación de datos | Sentido |
|---|---|
| 0 | Alfabeto predeterminado de SMSC (SMPP 3.4) / Específico de MC (SMPP 5.0) |
| una | IA5 (CCITT T.50)/ ASCII (ANSI X3.4) |
| 2 | Octeto no especificado (binario de 8 bits) |
| 3 | Latín 1 ( ISO-8859-1 ) |
| cuatro | Octeto no especificado (binario de 8 bits) |
| 5 | JIS (X0208-1990) |
| 6 | Cirílico ( ISO-8859-5 ) |
| 7 | Latín/Hebreo ( ISO-8859-8 ) |
| ocho | UCS2 (ISO/CEI-10646) |
| 9 | Codificación de pictogramas |
| diez | ISO-2022-JP (Códigos de música) |
| once | Reservado |
| 12 | Reservado |
| 13 | Kanji JIS extendido (X0212-1990) |
| catorce | 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 |
Los valores 4 y 8 para data_coding son los mismos para todas las versiones de SMPP. 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 identificaba de forma única el alfabeto GSM de 7 bits, para SMPP 3.4 y superior, el alfabeto GSM de 7 bits no está en esta lista, y data_coding = 0 puede diferir para diferentes SMSC ; esto puede ser ISO -8859-1 , ASCII , alfabeto GSM de 7 bits, UTF-8 o cualquier otra codificación predeterminada. Cuando se usa data_coding = 0, ambas partes (ESME y SMSC) deben asegurarse de que consideran que se trata de un puntero a la misma codificación. De lo contrario, es mejor no usar data_coding = 0. Esto puede dificultar el uso del alfabeto GSM de 7 bits, ya que algunos SMSC requieren data_coding = 0, otros, como data_coding = 241.
SMPP ha sido implementado en Java por el proyecto jSMPP . Se utiliza en Apache Camel y en varios otros proyectos populares de software de mensajería SMS gratuitos. Implementación alternativa de Java nmote-smpp . El proyecto python-SMPP proporciona SMPP para usuarios de Python . El proyecto PHP-SMPP proporciona SMPP para usuarios de PHP .
A pesar de su uso generalizado, SMPP tiene una serie de características problemáticas:
En SMPP 3.3, todos los valores de codificación de datos se tratan de acuerdo con GSM 03.38, pero desde SMPP 3.4 no hay ningún valor de codificación de datos para el alfabeto GSM de 7 bits.
De acuerdo con 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.
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 definen tres codificaciones para japonés (JIS, ISO-2022-JP y JIS Extended Kanji ), pero ninguna de ellas es idéntica a CDMA MSG_ENCODING 00101. Se supone que la codificación de pictogramas se usa para enviar mensajes Shift-JIS en SMPP ( codificación_datos =9).
La única forma de confirmar la entrega de un mensaje en SMPP 3.3 es a través del campo de texto short_message en la PDU deliver_sm . Sin embargo, el formato de este texto se describe en el Apéndice "B" de la especificación SMPP 3.4, aunque SMPP 3.4 puede (y debe) usar los campos de TLV para este propósito . SMPP 3.3 especifica que el identificador del mensaje es una cadena C de hasta 8 caracteres hexadecimales (más un '\0' final). Sin embargo, SMPP 3.4 especifica que un identificador dado en formato de cadena C puede contener hasta 10 caracteres decimales. Esto separa las implementaciones SMPP en 2 grupos:
Sin embargo, la especificación SMPP 3.4 establece que el formato de la PDU de confirmación de entrega depende del proveedor de SMSC. Por lo tanto, el formato descrito en la especificación es solo una de las opciones posibles. Como se indicó anteriormente, cuando se usa SMPP 3.4, los TLV de recibo_mensaje_id y mensaje_estado DEBEN usarse para confirmar la entrega de un mensaje .
| Protocolos TCP /IP básicos por capas del modelo OSI | |
|---|---|
| Físico | |
| canalizado | |
| la red | |
| Transporte | |
| sesión | |
| Representación | |
| Aplicado | |
| Otro aplicado | |
| Lista de puertos TCP y UDP | |