Fallback de SMS A2P: quando mudar de rota e quando interromper o tráfego para investigar

O fallback de SMS A2P é uma medida de contenção, não uma garantia de entrega

O fallback de SMS A2P consiste em desviar de forma controlada parte ou a totalidade do tráfego de uma rota principal para uma rota alternativa quando existem sinais suficientes de degradação. O seu objetivo é reduzir o impacto operacional enquanto se valida a causa do problema. Não transforma o SMS num canal com garantia de entrega nem elimina a necessidade de investigar a qualidade da rota original.

Em SMPP, a resposta a submit_sm confirma o resultado desse pedido de protocolo e normalmente devolve um message_id atribuído pelo SMSC. Não confirma que a mensagem chegou ao terminal. Para conhecer o resultado posterior, o ESME deve solicitar um SMSC Delivery Receipt ou consultar o estado quando essa operação estiver disponível.

Por isso, uma política de fallback madura deve decidir duas coisas em separado: quando é razoável testar outra rota e quando o comportamento observado exige interromper ou limitar o tráfego para preservar evidências e evitar danos adicionais.

• Trate o fallback como uma ação reversível e limitada.
• Mantenha a investigação ativa, mesmo que o tráfego alternativo pareça funcionar.
• Não use a aceitação de submit_sm como prova de entrega ao destinatário.
• Não interprete uma recuperação de sessão SMPP como recuperação completa da rota.

O que pode correr mal com um fallback mal concebido

Uma mudança automática de rota pode proteger uma operação crítica, mas também pode ampliar um incidente. O caso mais delicado surge quando a mensagem original foi aceite pelo SMSC, permanece em curso ou o seu estado final chega com atraso, e o sistema reenvia o mesmo conteúdo por uma segunda rota. O destinatário pode receber duas mensagens, dois códigos ou comunicações contraditórias.

Existe também um risco de diagnóstico. Se o sistema desviar todo o tráfego demasiado cedo, a degradação da rota principal pode ficar oculta por resultados agregados. Sem coortes de controlo, registos correlacionáveis e limites de alcance, torna-se difícil distinguir uma falha de conectividade, uma validação incorreta do destino, uma limitação de capacidade ou um problema localizado num destino ou operador.

O custo e a rastreabilidade também são importantes. Cada tentativa deve poder ser associada a uma única intenção de envio e à rota utilizada. Sem esta correlação, não é possível determinar se houve nova tentativa, duplicado, expiração, rejeição ou uma entrega tardia da primeira tentativa.

• Duplicados por reenviar antes de conhecer o resultado da tentativa inicial.
• Custo não controlado por multiplicar tentativas ou abrir fallback global.
• Perda de evidências quando se misturam resultados de rotas diferentes.
• Degradações persistentes ocultadas ao desviar tráfego sem isolar a causa.
• Decisões erradas se todos os destinos forem agrupados num único indicador.

Classifique o tráfego antes de definir novas tentativas

A mesma política não serve para todas as mensagens legítimas. A sensibilidade ao tempo, ao contexto e à duplicação deve fazer parte da decisão. Um OTP pode perder valor rapidamente e um segundo envio pode confundir o utilizador ou invalidar um fluxo de autenticação. Uma notificação transacional urgente pode justificar uma rota alternativa limitada, desde que a aplicação controle a idempotência do evento de negócio. Uma campanha de marketing com consentimento costuma permitir maior prudência: é preferível aguardar, reagendar ou investigar antes de duplicar comunicações.

A classificação deve existir antes do incidente, não durante o mesmo. Cada intenção de envio deve incluir, pelo menos, um tipo de mensagem, um prazo de validade, uma política de novas tentativas e uma regra explícita sobre se aceita ou não uma segunda rota.

• OTP: janela de utilidade curta; evite reenvios cegos e controle o ciclo de vida do código.
• Transacional urgente: aplique fallback apenas se o evento de negócio admitir idempotência e o risco de duplicado estiver definido.
• Notificação não crítica: priorize a observação, o reagendamento ou o envio diferido em vez da nova tentativa imediata.
• Marketing com consentimento: não use a urgência como justificação para multiplicar mensagens; respeite a política de contacto aplicável.

Sinais que podem justificar uma mudança de rota

Os sinais devem ser avaliados por camadas. Os erros imediatos de protocolo podem exigir uma reação diferente dos resultados finais de entrega. O SMPP define command_status para comunicar o sucesso ou a falha de um pedido. Entre os erros possíveis estão erros de sistema, limites de mensagens excedidos e validações de endereçamento. Um erro de TON ou NPI de destino não é, por si só, evidência de que a rota esteja degradada: pode indicar um problema de normalização ou de configuração do envio.

A disponibilidade da sessão também deve ser separada do desempenho de entrega. Um bind pode estar ativo e, ainda assim, a rota pode apresentar problemas em submit_sm, na receção de DLR ou no tratamento posterior da mensagem. Da mesma forma, a recuperação de uma sessão não demonstra que os resultados finais regressaram a níveis operacionais aceitáveis.

A ausência de DLR pode ser um sinal relevante apenas se for interpretada face à configuração de receipts, à janela de observação, ao tipo de mensagem e ao comportamento histórico conhecido dessa integração. As notificações intermédias não fornecem uma base portável para um fallback global: o seu suporte é específico da implementação do SMSC.

• Erros repetidos de protocolo que afetam submit_sm ou comandos necessários para operar.
• Throttling ou limites de capacidade que exigem reduzir o ritmo antes de aumentar as rotas.
• Erros de endereço, TON ou NPI que devem ser isolados como possível problema de validação.
• Perda ou instabilidade de sessão, diferenciada dos resultados de envio e entrega.
• Degradação observada nos estados finais ou na latência, segmentada por destino e rota.
• Ausência anómala de DLR, após verificar que foram solicitados e que a integração os processa corretamente.

Não confunda estados SMPP com receção independente no terminal

A nomenclatura dos estados deve ser tratada com precisão. ENROUTE significa que a mensagem está em curso; não é uma entrega. DELIVERED é um estado distinto dentro do SMPP. ACCEPTED também não deve ser interpretado como receção no terminal: a especificação descreve-o como uma mensagem aceite depois de ter sido lida manualmente em nome do assinante pelo apoio ao cliente.

Um DLR é valioso para operar e correlacionar eventos, mas não deve ser tratado como prova independente e uniforme em todos os fornecedores. O SMPP permite que a informação de um delivery receipt seja inserida em short_message com um formato específico do fornecedor de SMSC. Os códigos de erro também podem depender da rede ou do SMSC. A normalização interna deve preservar sempre o valor original juntamente com uma classificação operacional documentada.

A conclusão prática é simples: não ative um reenvio apenas porque uma mensagem continua ENROUTE, porque o DLR ainda não chegou dentro de uma janela arbitrária ou porque um fornecedor utiliza uma etiqueta textual que parece definitiva. Use regras baseadas em contexto, prazo de validade, padrão do incidente e risco de duplicação.

• submit_sm_resp: confirma a resposta ao submit, não a entrega final.
• ENROUTE: estado em curso; não inicie um reenvio com base apenas neste estado.
• DELIVERED: estado de entrega comunicado pelo ecossistema SMS, não uma verificação independente de leitura humana.
• ACCEPTED: não equivale à receção no terminal.
• EXPIRED, UNDELIVERABLE, REJECTED e UNKNOWN: devem ser preservados como resultados distintos para análise e decisão.

Conceba limites segmentados, não um único interruptor global

Um limite global mistura populações que podem comportar-se de forma diferente. A política deve segmentar, no mínimo, por destino normalizado de acordo com o plano de numeração aplicável. No intercâmbio SMPP, destination_addr, TON e NPI fazem parte do contexto técnico que convém registar e validar. Quando a telemetria disponível o permitir, acrescente rota, tipo de mensagem, remetente, janela horária e classe de erro.

Os limites devem combinar um volume mínimo e uma janela temporal. Uma pequena variação com poucas observações não deve provocar uma mudança massiva. Do mesmo modo, uma degradação concentrada num destino não deve justificar o desvio de países ou destinos não afetados. Defina antecipadamente que combinação de sinais gera observação, fallback limitado, contenção ou investigação.

Não é prudente definir valores universais de percentagem, minutos ou número de novas tentativas sem conhecer o comportamento contratual, técnico e operacional de cada integração. O limite correto é aquele que pode ser explicado, testado e revisto com os dados disponíveis.

• Exija um número mínimo de observações antes de avaliar uma degradação agregada.
• Meça em janelas temporais definidas e guarde a hora de cada evento.
• Segmente por destino, rota, tipo de mensagem e, quando relevante, remetente e classe de erro.
• Separe erros de validação de destino de indicadores de qualidade da rota.
• Documente o motivo exato que ativa cada transição de estado.

Defina uma máquina de estados operacional

Uma política de fallback deve poder ser expressa como uma máquina de estados que um operador consiga auditar. Isto reduz decisões ambíguas e evita que uma automatização passe diretamente de um alerta isolado para um desvio massivo. A máquina de estados não substitui os estados SMPP; organiza a resposta operacional perante sinais de protocolo, disponibilidade e resultados observados.

Um modelo prático começa com a rota principal em condições normais, passa para observação quando existem sinais iniciais, utiliza fallback limitado quando há evidência suficiente e mantém uma fase explícita de contenção e investigação para incidentes persistentes. A recuperação requer validação gradual, não apenas o regresso da conectividade.

• Rota principal: tráfego normal e monitorização segmentada.
• Observação: alerta aberto, validação de dados, sem desvio ou com um âmbito mínimo de teste.
• Fallback limitado: desvio de uma coorte definida, com orçamento de tentativas e controlos de duplicados.
• Contenção: redução, pausa ou isolamento do tráfego afetado quando o risco supera o benefício do reenvio.
• Investigação: análise de correlações, configuração, erros e alterações recentes.
• Recuperação: retorno gradual à rota principal após critérios verificáveis de estabilidade.

Controlos contra duplicados e novas tentativas sem contexto

O principal controlo contra duplicados consiste em separar a intenção de negócio da tentativa técnica. Atribua um identificador interno estável a cada intenção de envio e associe cada tentativa à rota, ao momento, ao conteúdo aplicável e ao message_id devolvido por cada SMSC. O SMPP também contempla user_message_reference como referência atribuída pelo ESME, mas a deduplicação entre rotas deve ser resolvida na lógica da aplicação, e não presumida a partir de um único campo de protocolo.

Antes de iniciar o fallback, verifique se a primeira tentativa tem um resultado final conhecido, se continua dentro do seu período de validade e se um segundo envio faria sentido para o utilizador. A janela de espera deve estar associada à validade da mensagem. O SMPP permite indicar validity_period e prevê que o SMSC descarte a mensagem ao expirar caso não tenha sido entregue.

A função replace_if_present_flag não resolve a deduplicação universal. Apenas solicita a substituição de uma mensagem pendente e depende da correspondência entre source address, destination address e service_type. Não deve ser assumido que funcionará entre fornecedores, SMSC ou rotas diferentes.

• Use um ID interno por intenção de envio e um ID por tentativa técnica.
• Guarde o message_id de cada SMSC sem o substituir por um identificador genérico.
• Aplique idempotência no evento de negócio, não apenas no transporte SMS.
• Defina uma janela de espera antes de considerar uma segunda tentativa.
• Não reenvie automaticamente mensagens cujo conteúdo possa ser inválido, contraditório ou sensível ao contexto.
• Não trate replace_if_present_flag como um mecanismo de deduplicação entre rotas.