Formato de informe de entrega SMPP

Los informes de entrega SMPP son enviados por el Servidor SMPP, al cliente SMPP después de que los mensajes de texto hayan sido entregados exitosamente al dispositivo móvil. El SMS original es enviado por el cliente SMPP usando una solicitud smpp submit_sm. Cuando el submit_sm es aceptado por el servidor SMPP, devuelve una respuesta submit_sm_resp, con un ID de referencia del SMS. El informe de entrega llega en una fecha posterior. Contiene la hora de entrega y el ID de referencia del SMS que identifica el mensaje. El documento a continuación explica el contenido de un PDU de informe de entrega SMPP y te proporciona un ejemplo de informe de entrega.

¿Cuál es el formato del informe de entrega SMPP?

Un informe de entrega SMPP se recibe como un mensaje de texto estándar. El texto del mensaje tiene un formato especial, que contiene varios campos sobre el SMS originalmente enviado. Estos campos pueden usarse para determinar el estado de la entrega del SMS.

Ejemplo de informe de entrega

Informe de entrega recibido. +44251234567->+0000000 'Entregado; Para: +44251234567; En: 2022-10-03 12:07:00; 
Ref: 636445148; id:636445148 sub:000 dlvrd:001 fecha de envío:2210031207 fecha de entrega:2210031207 
estado:ENTREGADO err: texto:'

Entrega exitosa reportada a admin@localhost. ID de tarea: cdfd66e1-880e-4ead-a559-7ca46d9ec669. 
Entregado; Para: +44251234567; En: 2022-10-03 12:07:00; Ref: 636445148; id:636445148 sub:000 dlvrd:001 
fecha de envío:2210031207 fecha de entrega:2210031207 estado:ENTREGADO err: texto:

Cómo recibir un informe de entrega SMPP

Para recibir un informe de entrega SMPP

  1. Conectar el cliente SMPP
  2. Vincular como transceptor
  3. Enviar el SMS usando el PDU submit_sm
  4. Registrar el ID del SMS de la respuesta submit_sm_resp
  5. Esperar a que el SMS llegue al móvil
  6. Recibir el PDU del informe de entrega del SMS
  7. Emparejar el ID del SMS con el mensaje enviado
  8. Registrar la marca de tiempo de entrega del SMS

Parámetros del informe de entrega SMPP

SMPP admite recibos / informes de entrega (DLRs) para mensajes SMS para que tu aplicación pueda determinar los resultados de la entrega.

La devolución de un recibo / informe de entrega de mensaje (DLR) depende del valor establecido en el campo registered_delivery del mensaje originalmente enviado desde el ESME al MC en una operación submit_sm. Esto puede configurarse para escenarios de no entrega y solo entrega que pueden resultar en circunstancias donde el recibo no será devuelto. Los recibos de entrega de mensajes se devuelven en las operaciones deliver_sm y data_sm.

Los siguientes campos son relevantes en las operaciones deliver_sm y data_sm cuando se usan para transmitir recibos de entrega.

  • dirección de origen (es decir, source_addr_ton, source_addr_npi, source_addr) - La dirección de origen se tomará de la dirección de destino del mensaje corto original, que generó el recibo de entrega. El recibo aparece como si emanara del destinatario del mensaje registrado original.
  • dirección de destino (es decir, dest_addr_ton, dest_addr_npi, destination_addr) - La dirección de destino se tomará de la dirección de origen del mensaje corto original, que generó el recibo de entrega. El recibo está dirigido al SME que originalmente envió el mensaje registrado.
  • esm_class - El bit 2 del esm_class se establece en 1 para indicar que el mensaje es un Recibo de Entrega MC. Si el bit 5 está establecido, entonces el mensaje es una Notificación Intermedia.
  • TLV message_state - Indica el estado final del mensaje original. Ver Estados del mensaje a continuación.
  • TLV network_error_code - Ver Códigos de error a continuación.
  • TLV receipted_message_id - ID del mensaje que fue devuelto al ESME por el MC en el PDU submit_sm_resp.

Recibo de Entrega MC

Este tipo de mensaje se utiliza para transportar un Recibo de Entrega MC. El MC, al detectar el estado final de un mensaje registrado, normalmente generaría un nuevo mensaje de recibo dirigido al originador del primer mensaje. El Recibo de Entrega MC se entrega luego al ESME en una operación deliver_sm o data_sm.

ESME-a-MC: Establecer los bits 0 y 1 en el campo registered_delivery de una operación submit_sm para solicitar un Recibo de Entrega MC.

Bit 1Bit 0Significado
00sin recibo
01recibo solicitado cuando el resultado final es éxito o fallo en la entrega
10recibo solicitado cuando el resultado final es fallo en la entrega
11recibo solicitado cuando el resultado final es éxito en la entrega (solo SMPP v5)

MC-a-ESME: El bit 2 en el campo esm_class de un deliver_sm indica que el recibo es un Recibo de Entrega MC.

Notificación Intermedia

Una notificación intermedia es una forma especial de mensaje que el MC puede enviar a un ESME para la entrega de un mensaje terminado en móvil. Proporciona un estado intermedio de un intento de entrega de mensaje.

Los usos típicos son informar el resultado de los intentos de entrega realizados durante el tiempo de vida de reintento del mensaje dentro del MC. Esto podría usarse para rastrear las diversas razones por las que un mensaje no se entrega a su destino y usar esto para perfilar la disponibilidad del suscriptor.

El soporte para la funcionalidad de Notificación Intermedia es específico de la implementación del MC y del Proveedor de Servicios MC y está fuera del alcance de esta especificación.

ESME-a-MC: Establecer el bit 4 en el campo registered_delivery de un PDU submit_sm para solicitar una Notificación Intermedia.

MC-a-ESME: El bit 5 en el campo esm_class de un deliver_sm indica que el recibo es una Notificación Intermedia.

Recibo en el campo short_message

Es probable que muchas API anteriores a la v3.4 y Centros de Mensajes que admiten la v3.3 tengan un medio para pasar información de recibo dentro del campo short_message. Esto se aplica a los Recibos de Entrega de MC y Notificaciones Intermedias. Los detalles del formato de esta información son específicos de la pasarela SMS y la plataforma SMSC, y están fuera del alcance de la especificación. Sin embargo, a continuación se muestra el enfoque que se suele tomar:

id:123A456B sub:1 dlvrd:1 submit date:1702281424 done date:1702281424 stat:DELIVRD err:0 text:


Los campos se especifican de la siguiente manera:

Campo Tamaño (octetos) Descripción
id Variable El ID del mensaje asignado por el SMSC cuando se envió originalmente.
sub 3 Número de mensajes cortos enviados originalmente. El valor puede estar rellenado con ceros a la izquierda.
dlvrd 3 Número de mensajes cortos entregados. El valor puede estar rellenado con ceros a la izquierda.
submit date 10

La hora y fecha en que se envió el mensaje corto. En el caso de un mensaje que ha sido reemplazado, esta es la fecha en que se reemplazó el mensaje original. El formato es el siguiente:

YYMMDDhhmm donde:
YY últimos dos dígitos del año (00-99) MM = mes (01-12)
DD día (01-31)
hh hora (00-23)
mm minuto (00-59)
done date 10 La hora y fecha en que el mensaje corto alcanzó su estado final. El formato es el mismo que para la fecha de envío.
stat 7 El estado final del mensaje. Consulta Estados del mensaje a continuación. El texto del estado puede estar abreviado.
err 3 Un código de error de la red o del SMSC para el mensaje. Consulta Códigos de error a continuación.
text 20 Campo no utilizado, el resultado estará en blanco.

Mejoras de Ozeki SMPP

Al implementar un gran número de conexiones SMPP, hemos encontrado los siguientes problemas en varias implementaciones:

Hallazgo 1:

El valor del campo ID en el informe de entrega (que llamamos Submit Reference en Ozeki) a menudo es diferente del ID que recibimos del proveedor de servicios SMS. La diferencia más común es que el ID original se devuelve como un número entero estándar y el ID en el informe de entrega se devuelve como un número hexadecimal. Esto también puede ocurrir al revés. Lo bueno es que, en esta situación, cuando se convierten de vuelta, los dos números coinciden, por lo que los informes de entrega pueden coincidir. Las implementaciones de SMS de Ozeki realizan varias comprobaciones y pueden manejar adecuadamente la situación descrita.

Hallazgo 2:

El valor de los campos de fecha a menudo viene en un formato no estándar. Ozeki actualmente analiza los campos de fecha utilizando los siguientes patrones. También puedes definir un patrón personalizado para el campo de fecha en el formulario de configuración del software.

  • "yyMMddHHmm",
  • "yyMMddHHmmss",
  • "dd-MMM-yyHH:mm",
  • "dd-MMM-yyHH:mm:ss",
  • "dd-MMM-yy HH:mm",
  • "dd-MMM-yy HH:mm:ss",
  • "yyyyMMddHHmmss",
  • "yyyyMMddHHmm",
  • personalizado

Estados del mensaje

La siguiente es una lista de estados permitidos para un mensaje corto. El MC devuelve el valor message_state al ESME como parte del PDU de respuesta query_sm_resp, query_broadcast_sm_resp o del recibo de entrega deliver_sm.

Los estados intermedios son estados que pueden cambiar. Los estados finales son estados que representan un estado de fin de vida para un mensaje.

Por ejemplo, un mensaje en reintento puede devolver un estado ENROUTE. En algún momento futuro, este mensaje expirará o será entregado. El estado progresará entonces a EXPIRED o DELIVERED. Por lo tanto, un mensaje en estado ENROUTE se considera en un estado intermedio.

Un mensaje en estado DELIVERED o EXPIRED no puede progresar a otro estado. Estos estados son, por lo tanto, estados finales.

Estado del Mensaje Valor Tipo
SCHEDULED 0 Intermedio
El mensaje está programado. La entrega aún no se ha iniciado. Un mensaje enviado con un tiempo de entrega programado puede devolver este estado al ser consultado. Este valor se añadió para SMPP v5.0. Los MC que admiten versiones anteriores de SMPP v3.3 y SMPP v3.4 probablemente devolverán ENROUTE para mensajes programados.
ENROUTE
o EN_ROUTE		 1 Intermedio
El mensaje está en estado en ruta. Este es un estado general utilizado para describir un mensaje como activo dentro del MC. El mensaje puede estar en reintento o enviado a una red móvil para su entrega al móvil.
DELIVERED 2 Final
El mensaje ha sido entregado al destino. El mensaje ha sido entregado al destino. No se realizarán más entregas.
EXPIRED 3 Final
El período de validez del mensaje ha expirado. El mensaje no ha podido ser entregado dentro de su período de validez y/o período de reintento. No se realizarán más intentos de entrega.
DELETED 4 Final
El mensaje ha sido eliminado. El mensaje ha sido cancelado o eliminado del MC. No se realizarán más intentos de entrega.
UNDELIVERABLE 5 Final
El mensaje es no entregable. El mensaje ha encontrado un error de entrega y se considera permanentemente no entregable. No se realizarán más intentos de entrega. Ciertos errores de red o internos del MC resultan en la no entrega permanente de un mensaje. Ejemplos de tales errores serían un suscriptor desconocido o un error de red que indicara que el móvil de destino dado no tiene servicio SMS o no puede soportar SMS.

Códigos de error en recibos de entrega SMPP

Los códigos de error devueltos en los recibos de entrega se utilizan para indicar cualquier situación de error encontrada al intentar entregar un mensaje. Los códigos de error son específicos de la pasarela SMS y la plataforma SMSC. Sin embargo, lo siguiente muestra un enfoque comúnmente adoptado:

Código	Significado
1	El número MT es desconocido en el HLR de la red MT
2	El número MT es desconocido en el HLR de la red MT
5	El número MT es desconocido en el MSC de la red MT
9	El número MT está clasificado como suscriptor ilegal en el MSC de la red MT
11	El HLR MT devuelve un error "Servicio no provisionado" en respuesta al SRI
12	El móvil MT está listado como un dispositivo ilegal en el MSC.
13	El cliente está bloqueado según el HLR MT para recibir SMS
15	El cliente MT es parte de un CUG que no puede recibir SMS
21	SMS no soportado en la red MT.
22	SMS no soportado en el MSC MT
31	El móvil MT está ocupado. El canal de control de señalización está en uso. 
	(Probablemente recibiendo otro SMS al mismo tiempo)
32	GPRS – Como arriba
34	Fallo del sistema en la red MT.
35	Faltan datos en el HLR o MSC MT
36	Valor de datos inesperado recibido en respuesta a un FSM o SRI
40	Capacidad de memoria excedida en el móvil MT
41	Error de protocolo en el móvil MT
42	El móvil MT no está equipado para soportar SMS
43	Tipo de mensaje corto "0" no soportado por el móvil MT.
44	La red MT no puede reemplazar el SMS en el móvil del cliente MT
45	Error de protocolo no especificado en el móvil MT
46	Clase de mensaje no soportada en el móvil MT
47	Error DCS (Esquema de codificación de datos) no especificado en el móvil MT
48	PDU de capa de transferencia no soportado por el móvil MT
49	Tarjeta SIM llena en el móvil MT
50	La SIM del móvil MT no puede almacenar el mensaje
51	Error en el móvil MT
52	Capacidad de memoria excedida en el móvil MT
53	SIM application toolkit ocupado en el móvil MS
54	Error de descarga de datos SIM en el móvil del cliente MT
55	Error no especificado en el móvil MS
60	Suscriptor ausente. Razón desconocida
61	Suscriptor ausente debido a móvil apagado
62	Suscriptor ausente debido a móvil sin cobertura/batería agotada
63	Suscriptor ausente debido a restricción de roaming/zona restringida
64	Suscriptor ausente debido a baja en el HLR
65	Suscriptor ausente debido a purgado en el VLR (apagado por 24+ horas)
66	Suscriptor ausente (GPRS) no puede ser localizado por el SGSN
67	Suscriptor ausente debido a GPRS desactivado
68	Suscriptor ausente debido a baja en el HLR (GPRS)
69	Suscriptor ausente debido a MS GPRS purgado en VLR
70	Suscriptor ausente debido a suscriptor no identificado en el MSC al que se envió el FSM.
71	Suscriptor ausente debido a suscriptor no identificado en el SGSN

Cómo probar informes de entrega SMPP

Puedes crear una configuración de simulador SMPP, para probar informes de entrega de SMS. En el simulador, la conexión de prueba puede devolver informes de entrega exitosa y fallida. Lo hará si configuras "Solicitud de informe de entrega" en la pestaña "Avanzado" del formulario de configuración de la conexión de prueba SMPP. Si tienes esta opción habilitada, se devolverá un informe de entrega por cada SMS enviado en una fecha aleatoria posterior con un estado aleatorio de entrega exitosa o fallida.

Preguntas frecuentes

¿Qué es un informe de entrega?

Al enviar un mensaje SMS, la confirmación de su llegada al teléfono del destinatario es crucial. El SMS emplea un sistema de confirmación en dos pasos para garantizar esto.

Al enviar tu mensaje al Centro de Servicio de Mensajes Cortos (SMSC) de la red móvil, recibes un "informe de envío del mensaje". Este informe indica que el SMSC ha aceptado tu mensaje para su entrega. También incluye un identificador único, a menudo llamado "referencia del mensaje" o "ID de devolución de llamada", que permite rastrear el mensaje dentro del sistema del SMSC.

Tras la aceptación, el mensaje se almacena en el SMSC hasta que la entrega sea posible. Esto podría retrasarse si el teléfono del destinatario está apagado, lo que podría extender la espera hasta días. Una vez que el teléfono del destinatario esté disponible, el mensaje se entrega. Cuando la entrega es exitosa, se envía un "informe de entrega" al remitente como un mensaje SMS separado.

Este SMS de confirmación contiene:

  • Número de teléfono del destinatario: Verifica que el destinatario previsto recibió el mensaje.
  • Referencia del mensaje (ID de devolución de llamada): Coincide con el identificador del informe de envío original, proporcionando un vínculo claro entre las dos etapas.
  • Marca de tiempo de entrega: Proporciona la hora exacta en que el mensaje llegó al teléfono del destinatario.
Es importante destacar que "informe de entrega" generalmente se refiere a este SMS de confirmación recibido por el remitente. No todas las redes móviles ofrecen informes de entrega, y algunas requieren activación por parte del usuario.

¿Puedo ajustar cuánto tiempo se almacena un mensaje en el SMSC?

Aunque los mensajes SMS ofrecen una forma conveniente de comunicarse, garantizar que un mensaje llegue a su destinatario rápidamente es crucial. Aquí es donde entra en juego el concepto del "período de validez".

El período de validez se refiere al tiempo que un mensaje SMS se almacena en el Centro de Servicio de Mensajes Cortos (SMSC) cuando el teléfono del destinatario no está disponible. Si el mensaje no se entrega después de que este período expire, se elimina automáticamente del SMSC, evitando una entrega tardía.

Beneficios de utilizar el período de validez:

  • Mensajes sensibles al tiempo: Imagina enviar un texto sobre un evento sensible al tiempo, como un programa de TV en vivo. Establecer un período de validez adecuado garantiza que el mensaje no se entregue después de que el evento haya terminado, volviéndolo irrelevante.
  • Eficiencia de la red: Al evitar intentos de entrega innecesarios a teléfonos no disponibles, el período de validez optimiza los recursos de la red.
Aunque algunas redes móviles ofrecen la opción de configurar directamente el período de validez para mensajes salientes, la configuración predeterminada suele ser el máximo de la red (normalmente una semana). Este valor puede ajustarse a través de las opciones del menú integrado del teléfono.

Es importante recordar que no todas las redes móviles ofrecen períodos de validez configurables por el usuario, y algunas pueden requerir activación por parte del usuario para los informes de entrega (confirmación de que el mensaje llegó al destinatario).

More information