Avería de conectividad o degradación de ruta A2P SMS: cómo aislar la causa con evidencias

Conectividad, aceptación y entrega son señales distintas

Un incidente A2P SMS puede aparecer en distintos puntos del recorrido. La conexión puede fallar antes de enviar el mensaje; la plataforma o el SMSC pueden rechazarlo; el envío puede aceptarse sin que exista todavía un resultado final; o puede producirse un fallo después de la aceptación. Cada situación requiere evidencia diferente.

En SMPP, una respuesta satisfactoria a submit_sm indica que el SMSC aceptó el mensaje para su envío posterior. No confirma por sí sola que haya llegado al teléfono. Del mismo modo, ENQUIRE_LINK y ENQUIRE_LINK_RESP comprueban la conexión de aplicación entre ESME y SMSC, no la entrega a través de la red móvil.

• Conexión o sesión: comprueba si el cliente puede establecer y mantener la comunicación con la interfaz.
• Respuesta al envío: determina si la solicitud fue aceptada o rechazada y registra el motivo disponible.
• Resultado posterior: correlaciona los informes de estado con el mensaje original y verifica qué entidad los emitió.
• Recepción humana: no deduzcas que una persona leyó el SMS a partir de una respuesta de protocolo o un DLR.

Delimita el recorrido y conserva identificadores

Antes de cambiar rutas o configuración, dibuja el recorrido que realmente usa el tráfico: aplicación cliente, integración HTTP o sesión SMPP, plataforma, proveedor y destino móvil. Anota en qué punto se origina cada registro y quién genera cada respuesta. La funcionalidad interna de un Service Centre puede quedar fuera de lo que una interfaz o especificación permite observar; reconoce ese límite en el análisis.

Conserva marcas de tiempo y referencias suficientes para unir las etapas. En SMPP, registra el número de secuencia de la solicitud y respuesta, el identificador de mensaje devuelto y, si llega un recibo, su referencia al mensaje original. Para HTTP, conserva el identificador de solicitud disponible, la hora, el endpoint y la respuesta. No presupongas que identificadores de sistemas distintos son intercambiables.

• Registra hora de envío y zona horaria, destino en formato normalizado, remitente, tipo de tráfico y ruta seleccionada.
• Guarda código HTTP o estado SMPP, cuerpo o campos de error pertinentes y el identificador de correlación disponible.
• Añade la hora y el origen de cada callback o DLR, además de su referencia al mensaje.
• Protege los datos personales y limita el acceso a los registros según las políticas aplicables.

Comprueba primero la integración

Empieza por el lado que controlas. En HTTP, separa errores de transporte de respuestas HTTP y examina el código, el cuerpo y cualquier indicación de reintento. Un 503 significa que el servidor no puede atender temporalmente la solicitud; puede estar asociado, por ejemplo, con sobrecarga o mantenimiento, y Retry-After puede orientar sobre la espera. Un 429 significa que el servidor considera que se han enviado demasiadas solicitudes en un período; la respuesta también puede incluir Retry-After. Un 502 identifica un problema de gateway o proxy con una respuesta no válida del servidor upstream, pero no señala por sí solo qué componente originó el problema.

En SMPP, comprueba el estado de bind, desconexiones, tiempos de espera, respuestas a solicitudes y salud de la sesión. ESME_RTHROTTLED (0x58) indica que el ESME excedió los límites permitidos en esa interfaz. Es evidencia de limitación de tasa allí, no prueba de una degradación en una ruta de destino.

Revisa también la cola local, la confirmación de recepción de callbacks y la lógica de reintentos. SMPP no garantiza por sí mismo idempotencia. Si se produce un timeout, puede ser imposible saber solo con esa señal si el SMSC procesó la solicitud. Antes de reintentar, utiliza los mecanismos documentados de correlación y consulta de estado que estén disponibles, si los hay; no presupongas que siempre se puede determinar si la operación ya fue aceptada.

• Si fallan la conexión o el bind, investiga primero credenciales, configuración de sesión, conectividad y límites de la interfaz.
• Si recibes rechazos, agrúpalos por código y conserva las respuestas originales antes de modificar parámetros.
• Si aparecen 429 o ESME_RTHROTTLED, compara el volumen y la tasa de solicitudes con los límites acordados; no los etiquetes automáticamente como fallo de cobertura.
• Si hay 503 o 502, consulta al responsable del componente que respondió y aporta hora, identificador y respuesta observada.

Busca patrones por destino y atributos del tráfico

Una degradación de ruta se investiga buscando diferencias repetibles entre segmentos, no aislando un mensaje sin contexto. Compara destinos, operadores cuando la información sea fiable, remitentes, tipo de tráfico, ruta y ventana temporal. Mantén constantes los demás atributos relevantes siempre que sea posible: una comparación entre envíos distintos puede confundir el efecto de la ruta con cambios de destinatario, remitente, contenido o configuración.

Registra qué segmento falla y cuál actúa como comparación. Si una incidencia coincide con un operador de destino, eso constituye una pista para acotar; no basta para probar que la red de ese operador sea la causa. Valida que la muestra y los parámetros sean comparables y solicita evidencia adicional a las partes que controlan las etapas no visibles.

• Agrupa los casos por país o destino, operador conocido, remitente, tráfico OTP/transaccional/marketing, ruta y período.
• Compara tasas de aceptación, rechazo y estados finales por separado; no mezcles métricas con definiciones distintas.
• Verifica que los mensajes comparados tengan configuración equivalente y que las ventanas temporales sean coherentes.
• Anota cambios de configuración, volumen o comportamiento del cliente que coincidan con el inicio del problema.

Compara muestras controladas sin confundir correlación con causa

Selecciona muestras equivalentes y define de antemano qué señal vas a comparar: respuesta de envío, tiempo hasta una respuesta, llegada de un callback o estado reportado. Evita combinar en una sola cifra eventos que ocurren en etapas distintas. Una diferencia observada entre dos segmentos ayuda a formular hipótesis, pero no establece causalidad por sí misma.

Cuando sea seguro y esté autorizado, realiza comparaciones acotadas con tráfico legítimo y consentido. No cambies simultáneamente varias variables: si modificas ruta, remitente y configuración a la vez, será más difícil saber qué cambió el resultado. Coordina las pruebas con los responsables pertinentes y evita generar tráfico adicional innecesario.

• Define el grupo afectado, un grupo de comparación y el período antes de revisar resultados.
• Controla destino, remitente, tipo de mensaje, configuración y condiciones de envío relevantes.
• Separa las medidas de aceptación de las medidas de entrega y declara los datos faltantes.
• Repite la comparación en otra ventana si el volumen o la composición de la muestra pueden explicar la diferencia.

Interpreta los DLR según su origen y alcance

Un DLR es una señal cuyo significado depende de quién lo emite y de cómo está definido en la integración. En la especificación 3GPP, un informe del Service Centre confirma recepción por el centro, no necesariamente por el terminal; un informe emitido por la estación móvil confirma recepción por el terminal, no que el usuario haya leído el mensaje. Comprueba el origen del informe y el estado que representa antes de emplearlo como evidencia.

Un SMS-STATUS-REPORT informa sobre el estado del envío, pero no equivale automáticamente a una confirmación de recepción humana. También puede haber diferencias entre lo que una interfaz denomina «entregado» y el evento técnico que respalda ese estado. Si el emisor del DLR o su semántica no están claros, documenta esa incertidumbre y pide aclaración al proveedor.

• Correlaciona el informe con el identificador del mensaje original y conserva su marca de tiempo.
• Pregunta qué entidad genera el estado, qué evento confirma y qué estados de fallo puede representar.
• Distingue ausencia de DLR, demora del informe y estado de fallo; no los trates como equivalentes.
• No uses un DLR aislado para atribuir el problema a la red móvil, al proveedor o al terminal.

Árbol de decisión para aislar y escalar

Aplica el diagnóstico en orden, desde la primera etapa observable hasta el resultado posterior. Detén la investigación en la primera etapa cuya evidencia no esté disponible y solicita los registros necesarios; no saltes de un síntoma de integración a una conclusión sobre la red de destino.

Si el servicio está degradado, prioriza medidas seguras y reversibles: reduce o pausa el tráfico afectado cuando exista riesgo de duplicación, abuso o impacto operativo, y sigue el procedimiento acordado para cambiar de ruta. No des por supuesto que una ruta alternativa existe, ofrece el mismo comportamiento o está autorizada para ese tráfico.

• No hay conexión HTTP o bind SMPP: recopila tiempos, errores de transporte, estado de sesión y cambios recientes; escala al equipo responsable de conectividad o integración.
• Hay sesión, pero se rechaza el envío: agrupa códigos y respuestas. Comprueba formato y límites de interfaz; escala con ejemplos correlacionables.
• El envío fue aceptado, pero falta el resultado: verifica callbacks, tiempos de espera y significado del DLR. Solicita al proveedor el estado de la etapa posterior; la aceptación no prueba entrega.
• Los informes muestran fallos concentrados por segmento: valida muestras equivalentes y comparte el patrón con proveedor y partes de destino, sin declarar causa hasta contar con evidencia de esa etapa.
• Hay resultados contradictorios o identificadores que no correlacionan: pausa conclusiones, revisa relojes, referencias y duplicados, y reconstruye el recorrido con los registros originales.

Documenta evidencia, incertidumbres y acciones

Un buen informe permite que otro equipo reproduzca el razonamiento sin asumir la causa. Separa hechos observados, hipótesis y conclusiones; indica qué sistemas aportaron cada registro y qué parte del recorrido permanece fuera de observación. Adjunta una muestra pequeña y representativa con datos protegidos, no solo capturas agregadas sin identificadores.

Los estándares ofrecen límites y señales distintas para cada etapa: conexión, aceptación y reportes de estado. El diagnóstico debe reflejar esos límites y distinguir las observaciones verificables de las hipótesis que todavía requieren evidencia.

• Resume impacto, inicio y fin conocidos, segmentos afectados y no afectados, y cambios recientes.
• Incluye marcas de tiempo, identificadores, respuestas originales y definición de cada estado analizado.
• Etiqueta cada elemento como hecho, hipótesis, dato pendiente o acción tomada.
• Registra quién debe aportar la siguiente evidencia y cuándo se revisará el diagnóstico.