Restricciones de rutas A2P SMS: cómo documentarlas para evitar envíos no admitidos y decisiones de enrutamiento opacas

Por qué las restricciones de ruta deben ser datos operativos

Una restricción de ruta A2P SMS es una condición que determina si un mensaje concreto puede enviarse por una ruta determinada. Puede depender del destino de terminación, del operador cuando aplique, del tipo de tráfico, del remitente, del contenido, de un registro previo, de la capacidad disponible o de una condición comercial.

Estas condiciones suelen quedar repartidas entre contratos, correos, portales de proveedores, tickets y conocimiento informal de una persona del equipo. Ese modelo es difícil de auditar y propenso a errores: una ruta puede estar técnicamente disponible, pero no admitir un determinado destino, un Sender ID, tráfico promocional, enlaces o una pauta de volumen.

La matriz de restricciones no sustituye al contrato, a la regulación aplicable ni a la confirmación del proveedor. Su función es convertir información dispersa en reglas consultables, trazables y accionables antes de aceptar, enrutar o escalar tráfico.

• Trate cada restricción como una regla con alcance explícito, no como una nota genérica.
• Modele el destino de terminación de forma concreta; no infiera requisitos solo a partir del país de origen del remitente.
• Use la numeración internacional normalizada como campo de validación del destino, según la recomendación ITU-T E.164 para el plan público internacional de numeración.
• Mantenga separadas las restricciones técnicas del SMS, las condiciones comerciales de una ruta y los requisitos regulatorios o de red.

Una ruta disponible no equivale a una ruta apta

La disponibilidad de conectividad no demuestra que una ruta sea apta para todo el tráfico. Una misma ruta puede aceptar una conexión HTTP o SMPP y, sin embargo, restringir remitentes, requerir preregistro, admitir solo determinados casos de uso o aplicar límites de capacidad distintos según cuenta, remitente o canal.

La decisión correcta no es preguntar únicamente si existe una ruta hacia un país. Debe formularse como una evaluación de compatibilidad: ¿este destino, este remitente, este caso de uso, este contenido y este patrón de envío están admitidos por esta ruta en la fecha de la decisión?

Este enfoque evita una conclusión especialmente arriesgada: interpretar una condición comercial o una afirmación de disponibilidad como garantía técnica de entrega. Incluso cuando un envío se acepta para procesamiento, el resultado puede depender de elementos fuera del control de una sola parte de la cadena de mensajería.

• Destino: país y, cuando la evidencia lo requiera, red u operador de terminación.
• Tráfico: OTP o 2FA, notificación de cuenta, alerta de fraude, atención al cliente, marketing consentido u otra categoría controlada.
• Remitente: alfanumérico, número, código corto u otro tipo permitido por el destino y la ruta.
• Contenido: idioma, codificación, enlaces, acortadores, plantillas, palabras de baja y elementos de marca.
• Patrón de envío: volumen, tasa, recurrencia, ventana de validez y necesidad de respuesta.
• Condiciones de alta: preregistro, aprobación, campaña, consentimiento y pruebas exigidas.

Las categorías mínimas de una tabla de restricciones

Una tabla útil debe permitir que operaciones, compras, cumplimiento e ingeniería respondan a la misma pregunta con los mismos campos. No basta con una columna de “permitido” o “no permitido”, porque esa respuesta carece de contexto y no explica qué condición la cambia.

La granularidad debe ser suficiente para evitar reglas excesivamente genéricas por país. Si una condición solo se ha confirmado para un operador, una red o un tipo de remitente, la ficha debe reflejar ese límite en lugar de extenderlo a todo el destino.

La conectividad debe registrarse solo cuando afecte a la aceptación operativa del tráfico y exista evidencia específica para la ruta o proveedor correspondiente. La disponibilidad de HTTP o SMPP no confirma por sí sola que un tipo de tráfico sea admisible. BulkSMSMarket describe conectividad HTTP y SMPP en su sección para desarrolladores.

HLR Lookup puede utilizarse como una señal técnica de red dentro de una decisión operativa, pero no prueba consentimiento, identidad, titularidad del número ni entrega garantizada. Las comprobaciones internas de BulkSMSMarket son evidencia operativa acotada: sus pruebas diarias observan entrega, consistencia de DLR, latencia, disponibilidad y comportamiento de remitente o contenido en rutas, destinos y operadores, sin validar el cumplimiento ni ofrecer garantías comerciales.

Antes de adquirir o vender capacidad A2P, conviene contrastar el alcance de cada restricción, la evidencia disponible y su vigencia. Las reglas precisas y actualizadas reducen ambigüedad en la gestión responsable de capacidad.

• Identificador de regla: código único y estable para referencias en tickets, controles y cambios.
• Destino: país, prefijo o patrón de numeración aplicable y formato esperado.
• Operador o red: obligatorio solo cuando la condición esté comprobada a ese nivel.
• Ruta o relación comercial: identificador interno de la ruta y alcance de la condición.
• Tipo de tráfico: valor controlado, no etiqueta libre.
• Tipo y valor de remitente: clase de remitente, restricciones de longitud o formato y capacidad de respuesta cuando proceda.
• Contenido: requisitos de plantillas, enlaces, dominios, acortadores, idiomas o categorías no admitidas.
• Conectividad: protocolo, parámetros o limitaciones de integración que afecten a la aceptación operativa del tráfico, cuando estén documentados para la ruta específica.

Declarado, verificado y pendiente de confirmación

La calidad de una matriz depende tanto de lo que registra como de cómo expresa la certeza. Una regla declarada por un proveedor, un requisito confirmado por documentación oficial y una condición observada en una prueba no tienen el mismo valor probatorio.

Use estados de evidencia explícitos. Esto evita que un equipo transforme una afirmación comercial en un hecho comprobado, o que una observación técnica limitada se convierta en una regla universal. El estado debe acompañar a cada restricción, no quedar en una nota general de la ruta.

• Declarada: condición comunicada por la contraparte, pendiente de validación independiente o de evidencia documental suficiente.
• Verificada: condición respaldada por una fuente primaria, una aprobación documentada, una cláusula aplicable o evidencia operativa con alcance definido.
• Pendiente de confirmación: información incompleta, contradictoria, vencida o no aplicable con claridad al caso de uso.
• No aplicable: la condición se evaluó y no corresponde al alcance de esa ficha; debe incluir justificación.
• Retirada o reemplazada: regla histórica que no debe usarse para nuevas decisiones, conservada para auditoría.

Sender ID, preregistro y capacidad de respuesta

El remitente debe documentarse como un objeto sujeto a reglas, no como un texto que se inserta al final del flujo. La ficha debe indicar qué tipo de remitente se utilizará, si está permitido en el destino, si necesita registro previo y qué evidencia demuestra su estado.

Los Sender ID alfanuméricos merecen una atención específica. Se usan para mensajería unidireccional y no deben tratarse como un canal de respuesta. La documentación de Twilio indica que los Sender ID alfanuméricos no están disponibles para destinos en Estados Unidos ni Canadá; esta condición corresponde al proveedor documentado y no debe extrapolarse automáticamente a otras rutas o proveedores.

Cuando haya preregistro, registre el identificador de la solicitud o campaña, el estado, la fecha de aprobación, la entidad aprobadora, la fecha de vencimiento si existe y los mensajes o dominios cubiertos. Un remitente activo o registrado no demuestra por sí solo que todo el tráfico asociado sea admisible.

• Nombre o valor del remitente solicitado y valor efectivamente aprobado.
• Tipo de remitente y si admite mensajes entrantes o respuestas.
• Requisito de preregistro por destino y estado del expediente.
• Marca, caso de uso, muestras de mensajes, enlaces y palabras clave cuando sean parte del proceso aplicable.
• Fecha de alta, vigencia, renovación y responsable de revisar el estado.
• Restricciones entre el remitente y una campaña, un dominio, un tipo de tráfico o una ruta concreta.

Clasifique el tráfico antes de aplicar reglas

La categoría de tráfico no debe ser un campo libre como “transaccional” sin definición. Una clasificación controlada permite aplicar restricciones coherentes y detectar cuando un flujo mixto requiere revisión adicional.

En el contexto de campañas A2P de Estados Unidos, las categorías documentadas incluyen 2FA, notificaciones de cuenta, atención al cliente, alertas de fraude, marketing y campañas mixtas. La clasificación exacta aplicable dependerá del destino, del marco de registro y de la ruta; por ello, la matriz debe conservar el catálogo empleado y su fuente.

Para tráfico recurrente, la documentación debe separar el mecanismo de alta, el mecanismo de baja y la asistencia. En la guía de The Campaign Registry, el opt-in es obligatorio para casi todos los tipos de campaña, y los elementos de opt-out y HELP tienen requisitos propios. En Estados Unidos, las solicitudes de revocación de consentimiento sujetas a TCPA deben tratarse como eventos operativos: la FCC exige atenderlas en un plazo razonable que no supere diez días laborables desde su recepción.

• OTP o 2FA: defina el evento que genera el código, la vigencia esperada y el remitente autorizado.
• Alertas transaccionales: describa el evento de cuenta, pedido, seguridad o servicio que activa el mensaje.
• Marketing consentido: documente el flujo de consentimiento, la frecuencia, el mensaje de alta, la baja y la ayuda cuando correspondan.
• Atención al cliente: delimite si existe conversación, qué remitente se usa y qué contenido está permitido.
• Tráfico no admitido: use una categoría explícita para prohibiciones confirmadas; no lo deje como una excepción implícita.
• Tráfico mixto: requiera revisión humana si combina finalidades o si la clasificación no está clara.

Contenido, enlaces y mecanismos de baja

El contenido debe evaluarse como texto final renderizado. Las variables de personalización pueden introducir caracteres, enlaces o longitud adicional que no estaban en la plantilla base. Validar solo la plantilla incompleta puede producir una clasificación de codificación errónea o incumplir una condición de ruta.

Documente por separado las restricciones de contenido verificadas para cada destino o campaña: plantillas exigidas, mensajes de muestra aprobados, dominios, enlaces, acortadores, marcas y palabras clave. Si no existe evidencia suficiente sobre una categoría, marque la condición como pendiente de confirmación y no la convierta en una prohibición o permiso universal.

Una DLR con estado de entrega no valida el contenido, el consentimiento, el preregistro ni la adecuación de una campaña. Es un estado de entrega reportado por la cadena de mensajería; la conformidad necesita sus propias evidencias.

• Guarde las muestras aprobadas junto con la versión de la campaña o del remitente.
• Registre dominios y enlaces permitidos cuando el marco aplicable los requiera.
• No presuponga que un acortador está permitido por el hecho de que otro enlace haya sido aceptado.
• Para campañas recurrentes, relacione las instrucciones de baja y ayuda con la evidencia del flujo de alta.
• Registre las solicitudes de baja recibidas, su fecha de recepción, el sistema responsable y la fecha de ejecución.
• Distinga una DLR presentada por un proveedor de la recepción verificada de forma independiente en el terminal; no son equivalentes.

Límites técnicos: documentar sin prometer entrega

Los límites técnicos son necesarios para decidir si un mensaje puede procesarse como se espera, pero no deben expresarse como garantías de entrega. La realización técnica del SMS se rige por especificaciones como 3GPP TS 23.040, que permanece bajo control de cambios, mientras que los límites efectivos de una plataforma o ruta pueden añadir condiciones propias.

Como referencia técnica documentada por Twilio, un SMS GSM-7 admite 160 caracteres en un segmento y UCS-2 admite 70. En mensajes concatenados, las referencias son 153 caracteres GSM-7 y 67 UCS-2 por segmento. Un solo carácter fuera del conjunto GSM-7 puede hacer que el mensaje completo pase a UCS-2 y cambie el número de segmentos.

La tasa de envío, la capacidad y el tiempo de cola también requieren contexto. Un límite de TPS o MPS debe incluir alcance, fecha de comprobación y condición aplicable, porque puede depender de cuenta, remitente y canal. Superar el límite puede provocar cola. La ventana de validez debe registrarse igualmente: una cola puede expirar antes si se establece un Validity Period menor. En la plataforma documentada por Twilio, los mensajes no pueden permanecer en cola más de diez horas.

• Codificación esperada: GSM-7, UCS-2 u otra condición documentada por la plataforma.
• Longitud y segmentación calculadas sobre el texto final renderizado.
• Política de concatenación y tratamiento de mensajes multipartes.
• TPS o MPS: valor, unidad, alcance, fuente, fecha y comportamiento al superar el umbral.
• Ventana de validez: valor solicitado, límite admitido y consecuencia de expiración.
• DLR: estados disponibles, origen del recibo y limitaciones de interpretación.