Protocolo SMPP. Problemas con el protocolo SMPP. Reglas para trabajar con conexión SMPP.

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 qué adjuntarlo. Además, se desconoce si esto fue aceptado. mensaje SMS DO.
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 del campo short_message (¡¡Dios mío, a quién se le ocurrió eso!!!) Aquellos. V forma de texto, abreviaturas extrañas, formatos salvajes, etc.
En general, esta es una situación en la que se elige uno de opciones posibles(PUEDE). 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 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 tiene razón el que paga. 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 desventaja - transmisión mensajes largos. La especificación se refiere sutilmente a la realización técnica del Mensaje corto Servicio Punto a Punto." 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? Ofertas GSM 03.40 texto largo Los mensajes se dividen en una serie de SMS concatenados, equipados con encabezados UDH. La especificación SMPP fomenta implícitamente uso gratuito- longitud del campo 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 de forma autónoma en SMS, proporcionar encabezados) en una 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 los ordinarios. mensajes de texto. 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. Relativo que medir tiempo especificado? Cuando no hay retrasos ni en el cliente ni en SMSC y entre ellos buena conexion, 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 a partir de la hora actual del SMSC en la que el SMSC intentará entregar este mensaje..."

Pero el problema diferentes puntos Esto no resuelve la cuenta regresiva.

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"

Existe tal clase de servicios en la red,
que dan a los usuarios la oportunidad
llamar a cualquier función enviando SMS a
numeros especiales y recibir respuestas también en
SMS Por ejemplo, puedes registrarte
casilla de correo electrónico para la que puede configurar
reenvío jabón entrante a tu teléfono.
Podrás recibir noticias en tiempo real y
participar en chats. Posible vía SMS
encarga imágenes y melodías para tu
móviles. Finalmente puedes participar en
votación. Algunos OpSoS
apoyar dicho servicio cuando para cada
no paga por los SMS enviados por el usuario
sólo a OpSoSu, sino también al propietario del servicio,
al pagar por los servicios, con mayor frecuencia
virtual. Cuando usamos el teléfono, no
Adjuntamos el gasto de dinero que lo acompaña.
el mismo valor que cuando se usa WebMoney
o al realizar pagos a través de SberBank.
Las capacidades de SMS ofrecen un amplio margen para
comercio electrónico. Mucha gente se siente atraída por
la tentadora perspectiva de conseguir pulmones
dinero cuando solo estás mirando
proceso y cuentas dinero, pero funcionan para
sus scripts en el servidor. no me pongo metas
crear una guía para un nuevo tipo de "negocio"
para una persona." En este artículo
solo diré lado técnico problemas
Procesamiento automatizado de SMS.

Diferentes enfoques

Dependiendo de las tareas asignadas y de
cantidad de dinero disponible que puedes elegir
una de las siguientes soluciones:

• Sólo puedes enviar SMS a través de formularios
  en los sitios web de OpSoSov o en algunos
  portales. Es gratis. es posible
  implementar el envío de SMS desde tu portal,
  pero para la implementación servicio pago, de
  que los usuarios esperan una fiabilidad especial,
  no es serio. Ya se ha escrito mucho sobre ellos,
  así que no me centraré en ellos,
  especialmente porque todos están actualmente
  están protegidos por la prueba de Turing, por lo que esto
  El método no está disponible actualmente.
• Puertas de enlace http a SMS especiales para aplicaciones empresariales.
  Pagas y te dan la oportunidad de hacer solicitudes http
  envía SMS desde tus scripts a cualquier
  punto del mundo, y también recibir SMS,
  enviado a números especiales. Entonces
  es muy fácil hacer un portal con un formulario SMS o
  notificación de nuevas cartas.
• El protocolo SMPP permite no sólo
  recibir y transmitir SMS, pero también recibir
  notificaciones de entrega enviadas
  mensajes, así como cancelar y reemplazar
  mensajes. Se le asigna un número o
  toda la gama números, lo obtienes todo
  mensajes que le llegan y
  enviar mensajes desde cualquier número.
  Posible notificación de recibido.
  mensajes: el centro de SMS está conectado a
  IP y puerto preespecificados y
  te envía mensajes.

En este artículo hablaré sobre SMPP como un
un método avanzado para trabajar con puertas de enlace SMS.

Con este protocolo podrás recibir
y enviar SMS a través de los llamados centros de SMS.
Los centros de SMS son puertas de enlace entre Internet
Y redes celulares. Para trabajar con esto
protocolo hay soluciones listas para usar,
por ejemplo Net::SMPP en Perl. Descripción del protocolo y
enlaces a productos de software se puede encontrar
en www.smpp.org.
Última versión protocolo en ese momento
escribir un artículo - 3.4. También puedes descargar allí.
programa para probar el software del cliente - SMPP
Herramienta de prueba de cliente (SCTT). Aún no he comprado acceso
centro de SMS real, necesitas probarlo de alguna manera
sus programas. El único inconveniente es que SCTT
escrito para Linux, por lo que debes
Juegue con Virtual PC o codifique inmediatamente en Linux.

Descripción del protocolo

La conexión se puede iniciar de la siguiente manera:
usuario nombrado en la descripción
Protocolo de entidad externa de mensajes cortos (ESME) y centro de SMS
(SMSC). Tenga en cuenta que debido a esta posibilidad
sería un error llamarlo centro de SMS
servidor, ya que puede ser
cliente. La primera opción se utiliza como
generalmente al enviar mensajes, y el segundo
al recibirlo, aunque nadie prohíbe
enviar mensajes a través de conexión,
instalado por el centro de SMS y recibir a través de
una conexión establecida por usted mismo. Todo
los datos en el protocolo SMPP están anidados en bloques,
llamadas Unidades de datos de protocolo (PDU), que tienen
encabezado que indica el tamaño del bloque y
código de operación.

Formato de encabezado de PDU:

Longitud DWORD: la longitud de todo el bloque, incluido
título
Comando DWORD
Estado DWORD: 0 en solicitudes y código de error y respuestas
DWORD SequenceNumber: número de secuencia.

El número de serie en la respuesta debe
igual al número de la solicitud.

Todos los números en SMPP están codificados para que el más alto
byte a la izquierda. Para esto puedes usar
función htonl(). Todas las PDU se dividen en solicitudes y
respuestas. En los códigos de solicitud, el bit más significativo es
cero, aproximadamente una respuesta. Para cada solicitud
la respuesta debería llegar, excepto
notificaciones sobre mensajes recibidos. Adiós
Si no se recibe respuesta, se considera la operación.
inconcluso. Si no hay respuesta
antes de que se pierda la conexión, el participante, ya sea SMSC
o ESME, deberá repetir la solicitud. Protocolo
asincrónico, es decir el remitente de la solicitud puede
enviar otra solicitud sin esperar
respuesta, y las respuestas pueden seguir en cualquier momento
secuencias. Todas las operaciones también
se dividen en los que se pueden utilizar
ESME que pueden ser utilizadas por SMSC y aquellas
que puede ser utilizado por ambos
fiestas. La conexión puede estar en
los siguientes estados:

— Abierto (aún no autenticado)
- Transferir
- Recepción
— Recepción y transmisión
- Cerrado

En el estado "Abierto", es decir, inmediatamente después
estableciendo una conexión TCP ESME que desee
enviar SMS, debe enviar una solicitud a bind_transmitter.
Para recibir - bind_receiver. Para ambas acciones
inmediatamente - bind_transceiver. Esta solicitud envía
inicio de sesión y contraseña. Si se establece la conexión
SMSC, primero debe enviar una solicitud de salida de enlace
y pase el nombre de usuario y la contraseña en él, porque en
En esta situación, ya necesitas sus derechos de acceso.
controlar. Por ejemplo, te mostraré cómo plancharlo.
comando bind_transmitter:

Título:
Longitud de DWORD
Comando DWORD = BIND_TRANSMITTER
Estado DWORD = 0
Número de secuencia DWORD

Datos:
Iniciar sesión en línea
Contraseña de cadena
Tipo de sistema de cadena (por ejemplo, WWW o correo)
Versión del protocolo BYTE = 0x34
BYTE addr_ton (tipo de número), 0 = predeterminado
BYTE addr_npi (Plan numérico), 0 = predeterminado
Cadena Rango de números, cadena vacía,
si el propio proveedor sabe qué números tenemos
nosotros servimos

Las cadenas son ASCIIZ, es decir, terminadas en nulo.

La mayoría de los parámetros de esta solicitud.
pueden ser ceros o lineas vacias. EN
la respuesta a tal solicitud llegará
que, además del encabezado, contendrá el SystemId del centro de SMS,
y el campo Estado será cero si tiene éxito. Si
Se establece una conexión de transmisión, entonces
tenemos derecho a enviar solicitudes submit_sm, y si
Se establece la conexión para la recepción, entonces necesita
esperar solicitudes de delivery_sm que contengan textos
mensajes recibidos y procesarlos.
Habiendo completado el trabajo, enviamos el mensaje de desvinculación y
desconectar.

La mayoría de las consultas tienen un montón
parámetros sobre los cuales no se puede particularmente
tomar un baño de vapor y anularlos. Así que a pesar de
una cantidad impresionante de documentación,
un sencillo contestador automático de SMS basado en
que puedes construir algunos
sistema de ayuda, lo tengo
con un volumen de sólo 25 kB de texto en C++, y una prueba de
SCTT demostró que todo funciona y así sigue siendo.
simplemente compre acceso a SMSC :).

A quién conectarse

Mensajes a través del protocolo SMPP para ti
Muchos OpSoS aceptan clientes, por lo que
sin referencias específicas. Busque información sobre
sitio web del OpSoS que prefieras
trabajar. Además, tu propio centro de SMS,
ejecutándose en el protocolo SMPP, proporciona

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 le da a uno muy ventaja importante- la conexión no se interrumpe y los SMS se envían con alta velocidad(hasta varias veces mayor que con otros métodos).

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

1. disponible varios formatos, incluidos wap push sms;

2. Los mensajes enviados a través de smpp no ​​solo pueden ser formato corto;

4. canal SMS bidireccional;

5. ajuste de velocidad.

Como puedes ver, el protocolo smpp da una gran libertad de uso, pero, como toda herramienta, tiene su propia características únicas relacionados con la configuración y el trabajo real. Hablaremos de esto a continuación.

Características de trabajar con el protocolo.

Para que smpp funcione es necesario un servidor adaptado para trabajar con este protocolo, y especial software(cliente). Además, necesita una conexión estable y constante a la puerta de enlace del proveedor. Por lo tanto, estamos en obligatorio Probamos los equipos que tienen nuestros clientes: el servidor debe ser compatible con alta velocidad. enviando SMS. 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. establecido por las reglas paquete resp. 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 va a etapa final correos.

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
	Demasiado texto grande mensajes. 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 tarifa asequible para la dirección solicitada.
	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.

Uno de los protocolos de SMS es smpp. Describe el proceso de interacción entre el destinatario del mensaje, es decir, el cliente smpp y el servidor SMS, utilizando sistema especial transferencia de datos.

Utilizando smpp como base para el envío de mensajes podrás:

• utilizar varios formatos de texto, así como Wap Push SMS;
• enviar no solo mensajes de texto cortos, sino también largos;
• recibir informes detallados sobre SMS entregados y retrasados;
• intercambiar mensajes en formato bidireccional;
• seleccione la velocidad de envío.

De este modo, protocolo smpp tiene grandes oportunidades, que, sin embargo, están asociados a algunas características de uso e instalación, que consideraremos.

Características de trabajar con smpp

Para trabajar con este protocolo es necesario contar con el software adecuado y un servidor capaz de interactuar con smpp. En este caso, el equipo debe estar constantemente conectado al gateway de la empresa proveedora. Con el fin de enviando smpp Los SMS se realizaron de forma rápida y sin demoras, todos los clientes de nuestra empresa se someten a una prueba de compatibilidad de equipos. Esto le permite deshacerse de muchas dificultades técnicas en la etapa inicial.

Además, antes de utilizar el protocolo para envíos de correo, los usuarios pueden probar el envío de SMS SMPP para determinar velocidad deseada entrega.

Los especialistas siempre están dispuestos a brindarle consejos sobre cómo utilizar, conectar y probar el servicio, lo que simplificará su tarea.

Conexión mediante protocolo 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

El servidor responderá a los comandos no admitidos con un mensaje 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, 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

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.
Después de 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.

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 a nivel modelo de red 4 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 por mucho tiempo era propiedad de Logica, pero ahora también está disponible. Normalmente este protocolo se utiliza en modo conexión permanente, lo que le permite aumentar significativamente la velocidad de transmisión, 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 entrada futura de nuevos parámetros, según se determine en futuras versiones. protocolo SMPP. Los parámetros opcionales son campos que se pueden incluir opcionalmente en un mensaje SMPP; se pueden incluir 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.

Áreas de aplicación de mensajes cortos en mundo moderno son geniales, el protocolo SMPP es ideal para transferencia rápida una gran cantidad de mensajes, por ejemplo para empresas que tienen base grande clientes o para realizar votaciones por SMS en tiempo real, donde existe un gran flujo de datos entrantes y salientes.

Más descripción detallada Puede encontrar el 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 servicios suplementarios no estructurados)- servicio estándar V Redes GSM, que le permite organizar la interacción interactiva entre un suscriptor de la red y una aplicación de servicio en el modo de transmisión de mensajes cortos;

MMS (Servicio de mensajería multimedia) es un sistema de transmisión mensajes multimedia(imágenes, melodías, videos) en 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 añadido): servicios que aportan ingresos adicionales;

ESME (Entidad Externa de Mensaje Corto) - Externa aplicación cliente, implementando el protocolo SMPP, recibiendo o enviando mensajes cortos;

HLR (registro de ubicación de inicio): base de datos permanente de suscriptores conectados a 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.