Skip to main content
Ambas direcciones (acuses de recibo hacia una dlr_url y mensajes MO hacia una forward.mo.url) comparten un mecanismo de entrega, así que comparten estas reglas.

​
Las dos reglas que lo deciden todo

Con el presupuesto predeterminado, un endpoint inalcanzable ocupa un hilo virtual durante veinte minutos. Diez intentos, con dos minutos de separación. Un cliente cuyo endpoint está caído durante una hora no solo pierde acuses de recibo. Está reteniendo hilos durante toda la hora, y también lo hacen todos los demás clientes en el mismo estado.Si ejecutas muchos clientes con endpoints poco fiables, baja el número de reintentos antes de subir el techo de hilos.

​
Un acuse de recibo nunca llega

1

¿Se proporcionó dlr_url?

Sobre HTTP debe estar presente y URL-codificada, y dlr debe ser yes. Establecer uno sin el otro no hace nada.
2

¿El endpoint es alcanzable desde el host de la pasarela?

No desde tu portátil, desde el host o contenedor donde se ejecuta la pasarela. La política de egreso, split DNS y subredes privadas muerden aquí.
3

¿Devuelve 200–399?

Un 401 detrás de un proxy con autenticación es el fallo silencioso más común. También lo es un 302 a una página de login, que sí cuenta como éxito y se traga el acuse de recibo.
4

¿Registró la pasarela el fallo?

Los fallos de reenvío y los reintentos se registran. Diez intentos silenciosos significan que el endpoint respondió.

​
La trampa de los placeholders

En formato kannel, el callback es un GET simple con placeholders sustituidos. No se anexa nada.
Una URL sin placeholders recibe una petición que no lleva nada. Sin body, sin query, sin identificador. Se llama al endpoint en horario, devuelve 200, y el cliente concluye que los acuses de recibo “funcionan pero están vacíos”.Este es el error de integración de acuses de recibo más común, y nada en el sistema lo marca: un callback vacío es indistinguible de uno correctamente configurado que resulta no llevar datos.

​
Los reenvíos de MO nunca llegan

Los callbacks MO son POST, y aplican las mismas reglas de 200–399 y reintentos.
  • forward.mo.url se establece en el worker cliente SMPP que recibe el MO. No en el listener, ni globalmente.
  • forward.mo.format es JSON o FORM.
  • La URL puede llevar placeholders, URL-codificados antes de la sustitución:
El detalle completo del MO entrante requiere print.mos = true temporalmente. Trata esa salida como sensible: contiene contenido del mensaje y ambas direcciones.

​
Acuses que llegan pero dicen algo incorrecto

No es un problema de entrega, y vale la pena descartarlo antes de mirar la red:
  • request.dlrs está apagado en el proveedor. Todo mensaje entonces se resuelve como EXPIRED al vencimiento, porque nada reporta un resultado. La tasa de entrega se vuelve sin significado en lugar de cero. Lo cual es peor, ya que un cero parece un problema y un número sin significado parece datos.
  • Un acuse de nivel 1 no es el resultado. ACCEPTD y BUFFRED llegan ambos como nivel 1 y sigue otro acuse. Un cliente que trate el primer acuse como final reportará algo incorrecto para siempre.
  • Tres segmentos, tres acuses. conf.dlr.multipart es all por defecto, así que un cliente recibe un acuse por cada submit_sm que envió. first o last lo colapsa a uno.

​
Relacionado

Acuses de recibo

El payload, los niveles y cómo correlacionar.

Calidad de acuses

Tasa reportada frente a tasa de entrega.