Simulador de sesión SMPP.

Cómo se ejecuta realmente una sesión SMPP

1. 1 · Encuadernar. Tu aplicación abre una conexión TCP con el SMSC y envía el comando bind_transceiver con un system_id y una contraseña. Hasta que el SMSC responda con command_status 0, no se aceptará nada más.
2. 2 · Enviar. Cada mensaje es una PDU submit_sm. La respuesta proporciona un message_id; esto es una aceptación, no una entrega.
3. 3 · Recibo. Si usted solicitó uno, el SMSC posteriormente envía un deliver_sm que contiene esm_class 0x04 y un cuerpo de recibo que hace referencia a ese message_id.
4. 4 · Mantenerse con vida. enquire_link se ejecuta cada 30-60 segundos, demuestra que el socket sigue operativo. Si no lo ejecuta, el SMSC lo desconectará.
5. 5 · Desenganchar. Cierra la llamada de forma educada para que el operador no lo considere una desconexión anormal.

Preguntas que hacen los ingenieros

¿Este simulador envía un SMS real?

No. En esta página no se abre ninguna conexión ni se envía ningún mensaje. Cada PDU y cada respuesta SMSC se calcula en su navegador a partir de los valores que usted introduce, por lo que las mismas entradas siempre generan la misma transcripción. Es una herramienta de aprendizaje del protocolo, no una herramienta de envío.

¿Qué es un bind en SMPP ?

Un enlace es el protocolo de enlace de sesión entre un ESME (tu aplicación) y el SMSC (el centro de mensajes del operador). `bind_transmitter` solo puede enviar, `bind_receiver` solo puede recibir, y `bind_transceiver` realiza ambas funciones a través de una única conexión, que es la que utilizan la mayoría de las integraciones. No se acepta ningún otro mensaje en la sesión hasta que el enlace se complete correctamente.

¿Qué hace registered_delivery?

Al establecer registered_delivery en 1, se le pide al SMSC que confirme el resultado final. Dicha confirmación llega posteriormente como una PDU deliver_sm independiente que contiene esm_class 0x04 (la confirmación de entrega), el cual hace referencia al message_id que se le proporcionó en submit_sm_resp. Sin esta confirmación, solo se sabe que el SMSC aceptó el mensaje, no que un terminal lo recibió.

¿Por qué mi mensaje se divide en varios segmentos?

Un único PDU SMS transporta 160 caracteres en el alfabeto GSM-7 o 70 en UCS-2. Los textos más largos se concatenan: cada parte cede 6 octetos a una cabecera de datos de usuario para que el terminal pueda recombinarlos, lo que resulta en 153 o 67 caracteres por segmento. Un carácter árabe o un emoji obliga a convertir todo el mensaje a UCS-2, por lo que un mensaje árabe de 100 caracteres requiere dos segmentos.

¿Cuál es la diferencia entre submit_sm_resp y una confirmación de entrega?

submit_sm_resp es síncrono e indica únicamente que el SMSC aceptó la PDU y le asignó un message_id. La confirmación de entrega llega de forma asíncrona, a menudo segundos o minutos después, e informa del resultado real: DELIVRD, UNDELIV, EXPIRED o REJECTD. Considerar submit_sm_resp como prueba de entrega es el error más común en una primera integración SMPP.

¿Qué es una ventana SMPP y por qué limita mi rendimiento?

La ventana determina cuántas PDU se pueden enviar pero no se han confirmado en un enlace en cualquier momento. Dado que SMPP es asíncrono, no se espera a que finalice cada submit_sm_resp antes de enviar la siguiente; sin embargo, la ventana limita el avance de la comunicación. Si se deja en el valor predeterminado de 1, el enlace se degrada a solicitud/respuesta y el rendimiento se reduce a un mensaje por viaje de ida y vuelta, independientemente de la tasa acordada por el operador.