Skip to main content
Este es el fallo que hace perder más tiempo, porque un proveedor rechazando cada mensaje parece perfectamente saludable: las sesiones están activas, la cola se drena, acceptsMessages() es true. El mensaje se acepta, enruta, envía, rechaza, vuelve a encolar y se descarta en outSms.routing.maxAttempts. Y el descarte dice reason=maxAttempts, que describe el síntoma en lugar de la causa.

​
Dónde está realmente la causa

message.submit.response, que lleva el command_status del proveedor:
El mismo valor está en la tarjeta del proveedor en el panel y en /ops/health como last_submit_error, con submit_rejected contándolos. Así que una ruta rechazando todo es visible sin leer un log en absoluto.

​
Qué significan los códigos comunes

La pasarela lleva la tabla completa, y escribe la frase en inglés claro junto a cada código que reconoce. Un código fuera de ella se registra como vendor-specific, deliberadamente: los proveedores usan los suyos propios, e inventar un nombre te enviaría a buscar una entrada de especificación que no existe.

​
El bloque 192–196 siempre trata de TLVs

Si una ruta empieza a rechazar todo con uno de esos cinco, mira los TLVs del mensaje, no el enrutamiento. Tres cosas los suministran, componiendo en este orden:
1

El default.tlvs.submit del propio proveedor

outSms.instance.<name>.default.tlvs.submit
2

defaultTlvs de la credencial

Valores por cliente.
3

El sello del whitelist

Para una cabecera de remitente o plantilla aprobada.
La causa más común es la tercera. Nada aprobado significa nada sellado, así que una ruta DLT recibe un envío sin id de entidad o plantilla y lo rechaza. tlvCount=0 en las líneas de traza lo confirma. La segunda más común es un default mal formado. El formato es <name>_<tag>=<value>. Escribir PEID=1101778070000018542 en lugar de peid_0x1400=1101778070000018542 parsea a nada, y el TLV se descarta con solo un WARN:
Un default mal formado es el más difícil de estos de ver, porque el ajuste parece aplicado. Está presente en la configuración, la pasarela arrancó limpiamente, y la única evidencia de que no hizo nada es un WARN al cargar y un tlvCount que es más bajo de lo que esperas.

​
Un proveedor, muchos más envíos que los que configuraste

Si un proveedor reporta muchos más envíos rechazados que mensajes enviaste, los dos techos de reintento se componen: el presupuesto de reintentos del propio proveedor se gasta dentro de un intento de enrutamiento, y un rechazo devuelve el mensaje al router, que tiene su propio techo de intentos. Con un solo proveedor configurado, re-enrutar lo devuelve directamente y gasta un presupuesto nuevo.
Vigila submit_rejected contra submitted en la tarjeta del proveedor. Una ratio muy por encima de uno es esta composición, no un problema del proveedor. Y vale la pena capturarlo, porque cada uno de esos PDUs es tráfico que tu operador ve.

​
Relacionado

TLVs en la práctica

De dónde viene un tag y qué sobrescribe a qué.

Colas y reintentos

Techos de intentos, backoff y qué cuesta un requeue.