Problemas con el protocolo SMPP. Envío de SMS mediante protocolo smpp, api para desarrolladores

SMPP (abreviatura: protocolo peer-to-peer de mensajes cortos) traducido del inglés significa "protocolo peer-to-peer de mensajes cortos" y le permite describir la interacción entre el servidor SMS y el cliente final. Este protocolo es uno de los más populares entre los proveedores de SMS, que lo utilizan para intercambiar mensajes de texto entre centros de SMS con igualdad de derechos. Para trabajar con el protocolo SMPP, es necesario tener un servidor constantemente encendido y un software adecuado compatible con la puerta de enlace SMS del proveedor.

• Admite varios formatos de texto y wap sms;
• Envío de textos largos;
• Mensajería bidireccional;
• Selección de velocidad de envío;
• Seleccionar el método de codificación;
• Extensibilidad;
• Reciba informes detallados.

El protocolo es indispensable para enviar periódicamente un gran volumen de mensajes a través de un canal fiable y de alta velocidad. Por tanto, el proveedor de SMS suele utilizar este protocolo para intercambiar mensajes SMS y USSD en sistemas VAS, para conectar varios sistemas externos, etc. Puede obtener más información sobre el protocolo SMPP y cómo se realiza el envío contactando a nuestros especialistas.

• Comandos admitidos
• Parámetros de envío de mensajes (SUBMIT_SM) vía SMPP
• Reglas para trabajar con conexión SMPP.
• Formato del recibo de entrega
• Códigos de error reservados del protocolo smpp
• Solicitud

La descripción del error se puede encontrar en la especificación SMPP 3.4.

Atención: Debe enviar una lista de direcciones IP desde las cuales podrá
conéctese antes de comenzar a utilizar SMPP.

Configuración de conexión mediante SMPP

• system_id - nombre de usuario del formulario XXXX.X registrado en el sistema
• contraseña - contraseña de usuario
• DIRECCIÓN -
• Puerto - 8056

Comandos SMPP compatibles

Los comandos no compatibles recibirán mensajes GENERIC_NAK con el código de error ESME_RINVCMDID.

Parámetros para enviar un mensaje (SUBMIT_SM) a través del protocolo smpp

Reglas para trabajar con conexión SMPP.

Cuando se establece una conexión, el cliente tiene 10 segundos para enviar el comando BIND_TRANSMITTER o BIND_TRANSCEIVER; de lo contrario, la conexión se cerrará.

El cliente debe responder a todos los paquetes recibidos a través de la puerta de enlace con un paquete de respuesta correspondiente dentro de 1 minuto; de lo contrario, la conexión se cerrará sin enviar UNBIND.

Obtener el estado de entrega del mensaje

Existen dos opciones para obtener el estado de entrega mediante el protocolo smpp (activo y pasivo). Se prefiere la opción pasiva.

La opción pasiva implica configurar el indicador de entrega registrada del paquete SUBMIT_SM.
Una vez que el mensaje alcance su estado final, el servidor enviará un paquete DELIVER_SM con un mensaje de recibo de entrega. El formato del mensaje del recibo de entrega se encuentra a continuación.

La opción activa proporciona un sondeo periódico del estado del mensaje enviando
CONSULTA_SM.

Formato del recibo de entrega

"id:IIIIIIIII sub:SSS dlvrd:DDD fecha de envío:AAMMDDhhmm fecha de finalización:AAMMDDhhmm
estadística:DDDDDDD error:E Texto: . . . . . . . . "

Códigos de error reservados para conexión smpp

Código	Descripción
0x0400 (1024)	Codificación no reconocida
0x0401 (1025)	El texto del mensaje es demasiado grande. La longitud máxima no debe exceder los 160
byte. 0x0402 (1026)	Error al registrar el mensaje para enviarlo. Cuando ocurre este error póngase en contacto con el soporte.
0x0403 (1027)	El texto del mensaje no fue revisado en busca de palabras y/o frases inapropiadas.
0x0404 (1028)	Remitente o destinatario en la lista negra
0x0453 (1107)	Había una restricción para enviar el mismo mensaje de texto al mismo número en un corto período de tiempo. Póngase en contacto con el soporte si desea desactivar o reducir el período.
0x043C (1084)	No hay tarifa disponible para el destino solicitado.
0x043F (1087)	La contraparte upstream no tiene una tarifa adecuada.
0x045A (1114)	Política de enrutamiento no encontrada.
0x0446 (1094)	Error de transporte. Si se produce este error, comuníquese con el servicio de atención al cliente. apoyo.
0x433 (1075)	No hay fondos suficientes en la cuenta.

26 de septiembre de 2011 a las 12:59

Problemas con el protocolo SMPP

• Armario

Es difícil encontrar algo perfecto en el mundo. El protocolo SMPP tampoco está exento de defectos. Describiré mis problemas con este protocolo. Espero que esto ayude a alguien a tomar las decisiones correctas.

Primero, el inconveniente más problemático: la pérdida de message_id cuando se interrumpe la conexión. Las operaciones de envío (submit_sm, etc.) para las que la respuesta no llegó a tiempo sufren esto. El protocolo no contiene medios integrados para recuperar identificadores perdidos. Como resultado, cuando llega el estado del mensaje, no hay nada a lo que adjuntarlo. Además, se desconoce si SMSC recibió este mensaje.
Si el intercambio se realiza en modo síncrono, sólo se perderá un mensaje. Pero si el trabajo se realiza en modo asíncrono, las pérdidas pueden ser importantes.

Este inconveniente del SMPP es quizás el único que recuerdo que no se puede solucionar utilizando el protocolo. El problema, por supuesto, se puede resolver, pero sin utilizar métodos estandarizados.

Las deficiencias restantes están relacionadas con problemas de implementación. Su solución suele consistir en llegar a un acuerdo entre el SMSC y el cliente SMPP y no va más allá de las especificaciones.

Segundo El fallo que realmente me molesta está relacionado con los informes de entrega de delivery_sm. En la versión 3.4 del protocolo no existe una definición estricta de cómo se debe transmitir la información de estado. Por un lado, existe una estructura TLV opcional en la que message_state y los parámetros relacionados se transmiten en un formato fuertemente tipado. Esta opción es buena, excepto que SMSC no podrá enviar comentarios extensos en esta estructura. Pero, repito, en ninguna parte se indica que este método sea obligatorio (DEBE). Pero en el apéndice del protocolo se da un ejemplo. Destaco: EJEMPLO. Ni siquiera una recomendación. Un ejemplo de cómo SMSC puede comunicar información de estado a través (¡¡Dios mío, a quién se le ocurrió eso!!!) el campo short_message. Aquellos. en forma de texto, abreviaturas extrañas, formatos salvajes, etc.
En general, se trata de una situación de elección de una de las opciones posibles (MAY). En mi opinión sobre la implementación de protocolos, elegir una de las opciones permitidas por el protocolo es prerrogativa de la parte que forma el paquete. En este caso con el paquete de informes es SMSC. Y el receptor está obligado a procesar correctamente cualquier paquete que cumpla con el protocolo. Pero la dura realidad dice que el que paga tiene razón. La gran mayoría de los clientes SMPP sólo entienden el campo short_message.
Gracias a Dios, esta mina (aplicación) fue eliminada de la especificación de la quinta versión del protocolo, pero busque clientes SMPP de la quinta versión.

Tercero La desventaja es la transmisión de mensajes largos. La especificación se refiere sutilmente a la realización técnica del estándar punto a punto del servicio de mensajes cortos." Es tan discreto que sólo notas el enlace cuando lo buscas específicamente. Este estándar está referenciado en la sección 1.4 Referencias de la especificación de la versión 3.4.
Pregunta: ¿Se supone que el protocolo debe utilizar el campo short_message solo de acuerdo con GSM 03.40? GSM 03.40 ofrece un texto de mensaje largo que se divide en una serie de sms concatenados, equipados con encabezados UDH. La especificación SMPP fomenta implícitamente el uso gratuito: la longitud del campo es de 254 octetos. Son dos sms en latín o casi cuatro sms en cirílico.
Leamos atentamente la especificación SMPP:

4.4.1 Sintaxis de “SUBMIT_SM”
“…Hasta 254 octetos de datos de usuario de mensajes cortos. El límite físico exacto para el tamaño del mensaje corto puede variar según la red subyacente… »

Aquellos. las restricciones las impone la red de transmisión (red subyacente). En nuestro caso, la red subyacente se describe en GSM 03.40. Por tanto, 140 bytes de datos. ¿Por qué un campo tan largo? El hecho es que se puede utilizar la codificación de 7 bits, entonces ya hay 160 caracteres. short_message es un campo de texto medido en octetos y no binario en bytes. Quizás los creadores estaban planeando otras opciones más sofisticadas.
Es comprensible que el desarrollador de un cliente SMPP quiera simplificar su tarea. Y no busca comunicarse con SMS concatenados por su parte. De acuerdo con el protocolo, SMSC PUEDE proporcionar dicho servicio a través del campo message_payload (dividir el mensaje en SMS de forma independiente, proporcionar encabezados) en la forma de su elección (no estandarizada). Pero según el protocolo, no está obligado a hacerlo. Sí, y esto se puede aplicar sin miedo sólo a mensajes de texto normales. Desde un punto de vista empresarial, la pregunta también es resbaladiza: ¿cómo cobrar por este tipo de mensajes? ¿Qué pasa si no todas las partes del mensaje tienen el estado de entregado?

Cuatro la desventaja está relacionada con el formato de hora relativa. ¿Con relación a qué se debe medir el tiempo indicado? Cuando no hay retrasos ni por parte del cliente ni del SMSC y hay buena comunicación entre ellos, las preguntas, por regla general, no surgen. Pero si aparece un retraso en algún lugar, entonces los puntos de referencia de tiempo del cliente y del SMSC divergen significativamente.
Para Schedule_delivery_time en la sección 5.2.15 se especifica:

"...hora relativa desde la hora actual del SMSC en la que el SMSC intentará entregar este mensaje..."

Pero esto no resuelve el problema de los diferentes puntos de referencia.

Literatura

• Especificación del protocolo punto a punto de mensajes cortos v3.4
• Realización Técnica del Servicio de Mensajes Cortos Punto a Punto"

El protocolo de intercambio está definido por la especificación SMPP versión 3.4.

La versión 1.0 es sólo para enviar mensajes y obtener el estado de entrega.

Actualmente no se admite la recepción de mensajes.

La descripción del error se puede encontrar en la especificación SMPP versión 3.4.

Para aumentar el nivel de seguridad al trabajar con el sistema, puede proporcionar una lista de direcciones IP desde las que se realizará la conexión.

Configuración de conexión

Comandos admitidos

• system_id: nombre de usuario registrado en el sistema.
• contraseña - contraseña de usuario SMS
• Dirección - sms.site
• Puerto - 9001

El servidor responderá a los comandos no admitidos con un mensaje GENERIC_NAK con el código de error ESME_RINVCMDID.

Parámetros de envío de mensajes (SUBMIT_SM)

Reglas para trabajar con conexión SMPP.

Cuando se establece una conexión, el cliente tiene 10 segundos para enviar el comando BIND_TRANSMITTER o BIND_TRANSCEIVER. De lo contrario, el servidor cerrará la conexión.

El cliente está obligado a responder a todos los paquetes enviados por el servidor con el paquete resp correspondiente en el plazo de 1 minuto. De lo contrario, el servidor cerrará la conexión sin enviar UNBIND.

Obtener el estado de entrega del mensaje

Hay dos opciones para obtener el estado de entrega (activo y pasivo). Se prefiere la opción pasiva.

La opción pasiva implica configurar el indicador de entrega registrada del paquete SUBMIT_SM. Una vez que el mensaje alcance su estado final, el servidor enviará un paquete DELIVER_SM con un mensaje de recibo de entrega. El formato del mensaje del recibo de entrega se encuentra a continuación.

La opción activa proporciona un sondeo periódico del estado del mensaje enviando QUERY_SM.

SMPP- un tipo común de protocolo utilizado para recibir y transmitir mensajes SMS y solicitudes USSD. Su peculiaridad es la conexión constante, lo que ofrece una ventaja muy importante: la conexión no se interrumpe y los SMS se envían a alta velocidad (hasta varias veces más que con otros métodos).

Entonces, al utilizar el protocolo smpp, obtienes las siguientes características:

1. Hay varios formatos disponibles, incluidos wap push sms;

2. Los mensajes enviados a través de smpp no ​​sólo pueden tener un formato corto;

4. canal SMS bidireccional;

5. ajuste de velocidad.

Como puede ver, el protocolo smpp ofrece una gran libertad de uso, pero, como cualquier herramienta, tiene sus propias características únicas relacionadas con la configuración y el funcionamiento real. Hablaremos de esto a continuación.

Características de trabajar con el protocolo.

Para que smpp funcione se requiere un servidor adaptado para trabajar con este protocolo y un software especial (cliente). Además, necesita una conexión estable y constante a la puerta de enlace del proveedor. Por eso, nos aseguramos de probar el equipo que tienen nuestros clientes: el servidor debe ser compatible con el envío de SMS de alta velocidad. De esta forma, inicialmente simplificamos la prestación de servicios de calidad.

Las API son adecuadas para sitios escritos en cualquier idioma, incluido PHP.

Los propios clientes pueden probar el funcionamiento del canal smpp configurado; para ello, se brindan todas las oportunidades incluso antes de comenzar a utilizar los servicios. Esto le permite comprender qué tan rápido se entregarán a los destinatarios los mensajes enviados a través del protocolo smpp.

El personal de servicio estará encantado de ayudarle a comprender todas las complejidades de trabajar con el protocolo smpp, la integración mediante php en su sitio web, ayudarle a conectar y probar todos los servicios y responder cualquier pregunta.

Parámetros de conexión

• system_id - nombre de usuario del formulario XXXX.X registrado en el sistema
• contraseña - contraseña de usuario
• DIRECCIÓN -
• Puerto - 8056

Comandos admitidos

	Descripción
BIND_TRANSMITTER	Conectar como TRANSMISOR
BIND_TRANSCEIVER	Conectar como TRANSCEPTOR
	enviar mensaje
	Solicitar estado del mensaje
	Envío de recibo de entrega por servidor
	Comprobando la conexión
	Comando incorrecto
	Cerrar

Si ingresa un comando incorrecto, recibirá una respuesta como GENERIC_NAK, cuyo texto contendrá el código de error ESME_RINVCMDID.

Parámetros para enviar mensajes SMS (SUBMIT_SM)

Reglas de conexión

El cliente tiene 10 segundos para establecer una conexión a través de la puerta de enlace smpp, durante los cuales se debe enviar uno de los comandos: BIND_TRANSCEIVER, BIND_TRANSMITTER. De lo contrario, se perderá la conexión.

Además, se producirá una interrupción si el cliente no responde a ningún paquete enviado por el servidor en un plazo máximo de un minuto con el paquete resp establecido por las reglas. Si se produce tal interrupción, no se envía UNBIND.

Sólo se permite una conexión smpp desde un único nombre de usuario a la vez. Todas las demás conexiones recibirán el error 0x00000005 ESME ya en estado enlazado. Sin embargo, si necesita realizar más de una conexión dentro de su cuenta, puede crear su propio usuario para cada una de estas conexiones.

En el caso de enviar Submit_sm, que está marcado con el indicador registrado_delivery, enviar el estado del SMS solo es posible al usuario que envió el mensaje.

Estado de entrega de SMS

Al trabajar con este protocolo, el estado de entrega puede ser pasivo (preferiblemente) o activo.

Para recibir un informe pasivo, debe enviar el paquete SUBMIT_SM con el indicador de entrega registrada previamente habilitado.

El texto del recibo de entrega en el paquete DELIVER_SM proviene del servidor cuando el SMS entra en la etapa final de distribución.

Cuando el informe está activo, el estado del SMS se comprueba periódicamente enviando QUERY_SM.

Formato del recibo de entrega

"id:IIIIIIIII sub:SSS dlvrd:DDD fecha de envío:AAMMDDhhmm fecha de finalización:AAMMDDhhmm
estadística:DDDDDDD error:E Texto: . . . . . . . . "

Códigos de error reservados

	Descripción
	Codificación no reconocida
	El texto del mensaje es demasiado grande. La longitud máxima no debe exceder los 160
0x0402 (1026)	Error al registrar el mensaje para enviarlo. Cuando ocurre este error póngase en contacto con el soporte.
	El texto del mensaje no fue revisado en busca de palabras y/o frases inapropiadas.
	Remitente o destinatario en la lista negra
	Había una restricción para enviar el mismo mensaje de texto al mismo número en un corto período de tiempo. Póngase en contacto con el soporte si desea desactivar o reducir el período.
	No hay tarifa disponible para el destino solicitado.
	La contraparte upstream no tiene una tarifa adecuada.
	Política de enrutamiento no encontrada.
	Error de transporte. Si se produce este error, comuníquese con el servicio de atención al cliente. Apoyo.
	No hay fondos suficientes en la cuenta.

La abreviatura SMPP significa protocolo peer-to-peer de mensajes cortos, un protocolo utilizado para transmitir SMS, USSD y otros tipos de mensajes, generalmente en sistemas VAS. Al final del artículo hay una lista de términos utilizados en el texto.

SMPP fue desarrollado por Aldiscon de Irlanda, que luego fue adquirida por Logica. En 1999, SMPP quedó bajo el control del SMPP Developers Forum, más tarde rebautizado como SMSForum. El protocolo se basa en el intercambio de PDU (unidades de datos de protocolo) transmitidas en el nivel del modelo 4 de la red OSI. El intercambio de paquetes puede ocurrir de forma sincrónica (después de enviar una solicitud, se suspende el intercambio adicional de paquetes hasta que se reciba una respuesta) o de forma asincrónica (las solicitudes se envían sin demora, las respuestas se procesan a medida que llegan). Hasta hace poco, la última especificación publicada fue SMPP 3.4, y la especificación SMPP 5.0 ha sido propiedad de Logica durante mucho tiempo, pero ahora también está disponible. Normalmente, este protocolo se utiliza en modo de conexión permanente, lo que puede aumentar significativamente la velocidad de transferencia, porque no es necesario establecer una conexión cada vez. La conexión puede ser iniciada por un usuario, llamado Entidad Externa de Mensajes Cortos (ESME) en la descripción del protocolo, o por un centro de SMS (SMSC).

Hay varios modos de conexión:

Modo “Transmisor” (transmisor): un modo solo para enviar mensajes a SMSC y recibir las respuestas correspondientes, sin recibir mensajes entrantes (paquetes DELIVER_SM);

Modo "Receptor" (receptor): en este modo todo es al revés, solo recibe mensajes entrantes y devuelve las respuestas correspondientes del cliente SMPP a SMSC, no se envían mensajes cortos a través de este modo (ENVIAR paquetes _SM);

Modo " Transceptor" - modo para enviar y recibir mensajes, proceso Se puede implementar de forma sincrónica o asincrónica.

Todos los datos del protocolo SMPP, como se mencionó anteriormente, están anidados en bloques llamados Unidades de datos de protocolo, que constan de un encabezado y un cuerpo.

El encabezado del paquete PDU contiene los siguientes campos:

longitud_comando: indica el número total de octetos contenidos en este paquete, incluido el campo de longitud.

comando _ id – identificador de comando (por ejemplo enviar _ sm,consulta _ sm, etc.). Y El ID del comando de respuesta es idéntico al ID del comando de solicitud correspondiente, pero con 31 bits configurados.

command_status: indica el éxito o el fracaso de la solicitud. Este campo sólo es significativo en el mensaje de respuesta y debe establecerse en NULL en los mensajes de solicitud.

secuencia _ número – en este El campo contiene un número de secuencia que permite asociar solicitudes y respuestas con fines de correlación. El uso de números de secuencia permite que los paquetes SMPP se intercambien de forma asincrónica.

El cuerpo de la PDU es opcional y es posible que no se incluya en todos los paquetes de PDU. La estructura del cuerpo se describe por separado en la especificación del protocolo, según el tipo de PDU.

También en el paquete PDU puede haber parámetros opcionales con un formato TLV común (etiqueta, longitud, valor). Estos parámetros proporcionan un mecanismo para la futura introducción de nuevos parámetros, según se definan en futuras versiones del protocolo SMPP. Los parámetros opcionales son campos que pueden incluirse opcionalmente en un mensaje SMPP, pueden incluirse en cualquier orden conveniente dentro de la sección Parámetros opcionales de la PDU transmitida y no necesariamente deben codificarse en el orden presentado en la especificación del protocolo.

Etiqueta: identificador de este parámetro de opción específico;

Longitud: especifica la longitud del campo Valor en octetos (esta longitud no incluye la longitud de los campos Etiqueta y Longitud). El campo del parámetro Longitud opcional siempre tendrá una longitud de 2 octetos;

Valor: este campo contiene los datos reales para este parámetro de opción.

Las áreas de aplicación de mensajes cortos en el mundo moderno son amplias; el protocolo SMPP es ideal para transmitir rápidamente una gran cantidad de mensajes, por ejemplo, para empresas con una gran base de clientes o para realizar votaciones por SMS en tiempo real, donde haya una gran base de clientes. un gran flujo de datos entrantes y salientes.

Puede encontrar una descripción más detallada del protocolo en la especificación en ruso aquí: SMPP_v3.4_rus.pdf

Conceptos básicos y abreviaturas.

SM (Mensaje corto): mensaje corto;

SMS (servicio de mensajes cortos): servicio de mensajes cortos, transferencias SM entre clientes de redes móviles, así como aplicaciones de clientes externos;

USSD (Datos de servicio suplementario no estructurados) es un servicio estándar en redes GSM que le permite organizar la interacción interactiva entre un suscriptor de la red y una aplicación de servicio en modo de transmisión de mensajes cortos;

MMS (Servicio de mensajería multimedia) es un sistema para transmitir mensajes multimedia (imágenes, melodías, videos) a través de redes celulares.

SMSC (Centro de servicio de mensajes cortos): centro de servicio de mensajes cortos: la base para el funcionamiento de SMS;

VAS (Servicios de Valor Agregado): servicios que generan ingresos adicionales;

ESME (Entidad externa de mensajes cortos): una aplicación cliente externa que implementa el protocolo SMPP y recibe o envía mensajes cortos;

HLR (registro de ubicación de inicio): una base de datos permanente de suscriptores conectados a la red móvil. El HLR proporciona la ruta de transmisión de SMS al destinatario del SM;

Octeto - 8 bits. En ruso, un octeto suele denominarse byte.