Disponibilidad no es entregabilidad: cómo medir tres capas de salud en una ruta A2P SMS

Una ruta disponible no siempre está operativamente sana

En operaciones A2P SMS, llamar “disponible” a una ruta puede ocultar tres preguntas diferentes. ¿La conexión técnica está operativa? ¿El sistema acepta los mensajes enviados? ¿Los mensajes generan un resultado de entrega que pueda interpretarse y reconciliarse? Una respuesta positiva a la primera pregunta no responde automáticamente a las otras dos.

Una sesión SMPP puede establecerse, responder a sus comprobaciones de enlace y mantenerse abierta mientras una ruta presenta rechazos de envío, acumulación de solicitudes pendientes, degradación de latencia o una caída de los DLR. Del mismo modo, un submit aceptado puede significar que el SMSC aceptó el mensaje por la conexión SMPP, no que el destinatario lo recibió.

La disponibilidad y entregabilidad de rutas A2P SMS debe evaluarse, por tanto, como un conjunto de señales relacionadas pero no equivalentes. Separarlas evita que una métrica favorable o desfavorable domine una decisión que requiere contexto.

• No use una sesión activa como sustituto de la entrega.
• No contabilice solicitudes aceptadas, encoladas o enviadas como mensajes entregados.
• No interprete la ausencia de un DLR como prueba automática de no entrega sin revisar el comportamiento acordado de la ruta y el proceso de reconciliación.
• Compare resultados entre poblaciones homogéneas; no mezcle pruebas sintéticas con tráfico de producción en un único porcentaje.

Las tres capas de medición

El modelo operativo más útil separa la salud de la ruta en tres capas. La primera es la disponibilidad técnica entre los sistemas que intercambian tráfico. La segunda es la aceptación de cada solicitud de envío. La tercera es el resultado posterior de entrega comunicado mediante los mecanismos disponibles.

Cada capa necesita sus propios identificadores, ventanas temporales, métricas y umbrales internos. También requiere una conclusión expresada con precisión: “conectividad confirmada”, “submit aceptado” o “DLR final recibido” describen hechos distintos y no deben sustituirse entre sí.

• Capa 1: disponibilidad técnica. Mide sesión, conectividad, respuestas y tiempos de respuesta.
• Capa 2: aceptación de tráfico. Mide respuestas a envíos, rechazos síncronos, solicitudes pendientes, colas y timeouts.
• Capa 3: resultado de entrega. Mide DLR, estados finales, estados intermedios cuando existan y latencia hasta el resultado.

Capa 1: disponibilidad técnica no es prueba de entrega

En SMPP, enquire_link y enquire_link_resp sirven para comprobar la confianza de la vía de comunicación y el funcionamiento de la conexión de aplicación entre el ESME y el SMSC. Son señales apropiadas para verificar si la sesión responde, detectar pérdidas de conectividad y medir el tiempo de respuesta de ese intercambio.

Estas señales no prueban que un mensaje se haya encaminado a una red móvil, que el destino sea alcanzable ni que el abonado haya recibido un SMS. El propio modelo SMPP reserva mecanismos distintos para solicitar y transportar los recibos de entrega.

La medición de conectividad debe registrar el ciclo de vida de la sesión y los eventos de mantenimiento, sin extrapolar esos resultados a la capa de entrega.

• Hora de establecimiento y cierre de sesión.
• Resultado de bind y errores de sesión.
• Envíos de enquire_link, respuestas recibidas, pérdidas y tiempo de respuesta.
• Reconexiones, duración de interrupciones y frecuencia de timeouts.
• Eventos separados por cuenta, enlace, ruta declarada cuando corresponda y ventana temporal.

Capa 2: qué demuestra la aceptación de tráfico

La aceptación responde a una pregunta más estrecha que la entrega: ¿el extremo receptor aceptó esta solicitud en este momento? En el flujo SMPP, una respuesta satisfactoria a una solicitud de envío puede acreditar la aceptación del mensaje por el SMSC a través de la conexión. El resultado eventual requiere seguimiento posterior, habitualmente mediante un Delivery Receipt solicitado para el mensaje.

En plataformas de mensajería basadas en API ocurre una distinción equivalente: una solicitud puede ser aceptada o encolada antes de que el mensaje se envíe a un carrier ascendente y antes de que exista una confirmación o un recibo de no entrega. Trate cada transición como una etapa, no como una garantía retrospectiva.

La capacidad tampoco debe inferirse solo de un bind abierto. SMPP no fija un máximo universal de operaciones pendientes; depende de la implementación del SMSC. Por eso, una ruta aparentemente disponible puede deteriorarse al aumentar las solicitudes concurrentes.

• Registre códigos de respuesta de submit y rechazos síncronos.
• Mida timeouts de respuesta y solicitudes pendientes o no confirmadas.
• Observe la evolución de colas y fallos de envío donde la interfaz exponga esos estados.
• Relacione cada envío con su identificador de mensaje, destino normalizado, remitente, contenido o clase de contenido, ruta y marca temporal.
• Evalúe la aceptación bajo una carga autorizada y controlada; una prueba aislada no caracteriza la capacidad sostenida.

Capa 3: DLR y los límites de la evidencia de entrega

Un SMSC Delivery Receipt es una señal que el SMSC genera al detectar el estado final de un mensaje registrado. En SMPP puede recibirse mediante deliver_sm o data_sm e incluye campos útiles para correlación e interpretación, como el identificador del mensaje recibido, message_state y, cuando esté presente, network_error_code.

Un DLR final es una evidencia más cercana al resultado de entrega que una respuesta de submit, pero sigue siendo una señal del ecosistema de mensajería, no una prueba universal e independiente de lectura, interacción o recepción verificada en el terminal. La semántica concreta y el alcance de las confirmaciones dependen de la red, del proveedor y de la implementación.

Los estados intermedios merecen un tratamiento separado. Pueden informar, por ejemplo, de un intento inicial fallido mientras el mensaje permanece retenido para nuevos intentos. Su soporte es específico de la implementación del SMSC y del proveedor; no asuma que todas las rutas los emitirán ni compare su ausencia como si fuera necesariamente un fallo.

• Conserve el identificador de envío y el identificador referenciado en el DLR para reconciliar eventos.
• Separe DLR finales de notificaciones intermedias.
• Mida el tiempo desde la aceptación hasta el DLR, además de la proporción de DLR recibidos dentro de una ventana definida internamente.
• Clasifique los estados según la documentación contractual y técnica de cada integración; no fuerce equivalencias entre vocabularios distintos.
• Describa “DLR de entrega recibido” sin transformarlo en “lectura confirmada” o “recepción independiente en el terminal”.

Diseñar pruebas sintéticas legítimas y controladas

Las pruebas sintéticas ayudan a detectar cambios de comportamiento antes de que afecten de forma amplia al tráfico, pero deben realizarse únicamente hacia destinos autorizados y con controles de cumplimiento. Su valor procede de mantener variables conocidas, no de intentar replicar toda la diversidad del tráfico comercial.

Utilice destinos de prueba bajo control o con autorización expresa. Normalice los números conforme a E.164 para reducir ambigüedades de formato y conservar una segmentación consistente por país o destino internacional. Mantenga un inventario de los destinos, la autorización aplicable, la ruta prevista, el remitente y el perfil de contenido usado.

Diseñe casos que permitan comparar una misma señal a lo largo del tiempo. Si cambia simultáneamente el destino, el remitente, el texto y la ruta, será difícil atribuir la causa de una variación.

• Defina un conjunto autorizado de destinos de prueba y revíselo periódicamente.
• Pruebe por separado conectividad, submit, correlación de DLR y tiempo hasta resultado.
• Mantenga textos legítimos, no engañosos y apropiados para las políticas aplicables.
• Varíe una dimensión cada vez: destino, operador, remitente, tipo de contenido o ruta declarada cuando corresponda.
• Registre versión del caso de prueba, hora, identificadores, respuestas síncronas, eventos asíncronos y observaciones.
• No convierta un resultado de prueba en una garantía para todos los destinos, remitentes o tipos de tráfico.

Complementar con producción sin mezclar poblaciones

El tráfico de producción ofrece cobertura real de destinos, remitentes y situaciones operativas que una prueba sintética no reproduce. Sin embargo, incorpora variabilidad: campañas, picos de OTP, cambios de contenido, diferencias de consentimiento, comportamiento de terminales y políticas aplicables. Por ello, sirve para observar patrones, pero exige segmentación antes de atribuir una causa a la ruta.

Mantenga los resultados sintéticos y los de producción como poblaciones distintas. Una caída simultánea en ambos grupos puede justificar una investigación prioritaria. Una desviación solo en producción puede requerir revisar primero cambios de mezcla, remitente, contenido o destino antes de concluir que hay una degradación de conectividad o de entrega.

El seguimiento debe conservar identificadores persistentes y reconciliar eventos asíncronos. Si falta un callback, la ausencia del evento no debe convertirse inmediatamente en una conclusión; cuando la interfaz disponible permita consultar el estado, úsela como parte del proceso de reconciliación.

• Etiquete cada registro como sintético o producción.
• Segmente producción por destino, operador cuando se conozca, tipo de tráfico, remitente, contenido o plantilla y ruta declarada cuando corresponda.
• No compare directamente un test a un único destino con una campaña multisegmento.
• Revise el estado de mensajes que queden sin resultado terminal dentro de la ventana operativa definida.
• Conserve evidencia de cambios de configuración, incidentes y ajustes de tráfico junto a las métricas.

Métricas y patrones que requieren atención

El cuadro de mando debe presentar series separadas por capa. Una única cifra de disponibilidad puede ocultar que el enlace está sano mientras los submit se rechazan, o que los submit se aceptan mientras disminuye la proporción de DLR finales observados.

Busque cambios frente a una línea base comparable, no solo valores absolutos aislados. La comparación tiene sentido cuando conserva el mismo grupo de destino, operador si está disponible, remitente, perfil de contenido, ruta declarada y franja temporal. Los cambios de mezcla pueden producir una señal aparente de degradación sin que la causa sea la conectividad.

Entre los patrones de interés se encuentran la conectividad estable con caída de DLR, el aumento de rechazos síncronos con sesiones sanas, el crecimiento de solicitudes pendientes, la ampliación de latencia de submit o de DLR y una concentración de resultados adversos en una sola combinación de destino, remitente o contenido.

• Conectividad: porcentaje de sesiones operativas, pérdidas de keepalive, reconexiones y latencia de respuesta.
• Aceptación: proporción de respuestas satisfactorias, rechazos por código, timeouts, pendientes y tiempo de respuesta al envío.
• Entrega: proporción de DLR final recibido, distribución de estados, tiempo hasta DLR y mensajes sin resultado reconciliado.
• Segmentación: destino en E.164, operador cuando esté disponible, remitente, tipo de tráfico, contenido o plantilla, ruta declarada y población de prueba o producción.
• Evidencia: identificadores correlacionables, marcas temporales, códigos de error disponibles y cambios operativos asociados.