Horários de eventos A2P SMS: como reconciliar timestamps da plataforma, do fornecedor e dos DLRs
Um guia prático para registrar, comparar e auditar horários de eventos SMS sem confundir o recebimento de um DLR com uma confirmação independente de entrega ao terminal.
Por que os horários registrados podem ser diferentes
Um envio A2P pode gerar registros em vários sistemas: o aplicativo ou a plataforma de origem, o fornecedor que recebe a mensagem e os sistemas que emitem ou entregam um relatório de status. Cada registro pode corresponder a um momento diferente e usar uma fonte de relógio, um fuso horário ou um nível de precisão distintos.
Por isso, timestamps diferentes não provam, por si só, que há um erro. Para interpretá-los, primeiro é preciso saber qual evento cada campo pretende representar e qual sistema o gerou. A documentação disponível para este artigo não permite atribuir definições universais de timestamps ou DLRs a uma especificação específica; combine e documente essas semânticas com cada fornecedor.
- Não compare um horário de criação com um horário de recebimento como se descrevessem o mesmo evento.
- Registre o sistema de origem e o significado declarado de cada timestamp.
- Trate a precisão e a semântica de cada campo como propriedades a verificar, não a presumir.
Separe criação, envio, aceitação e recebimento do callback
Use nomes explícitos para os eventos. No mínimo, diferencie quando o registro ou a solicitação foi criado, quando a plataforma tentou enviá-lo, quando recebeu uma resposta de aceitação, qual horário de evento o fornecedor informa e quando o callback chegou ao seu sistema. Não presuma que «aceito» significa entregue ao terminal.
Mantenha separados o horário do evento informado pelo fornecedor e o horário em que a plataforma recebeu esse informe. O primeiro é uma declaração do sistema que emitiu o evento; o segundo documenta o recebimento local. Se o fornecedor não especificar o que seu timestamp representa, preserve-o como dado de origem sem reinterpretá-lo.
- Defina um dicionário de eventos com nome, sistema emissor e significado.
- Armazene separadamente o timestamp declarado pelo fornecedor e o timestamp local de recebimento.
- Não transforme estados de aceitação ou de recebimento de um informe em uma alegação de entrega ao dispositivo.
Normalize para comparar, mas preserve os dados originais
Para facilitar buscas e comparações entre sistemas, adote uma representação comum de horário, como UTC, e uma convenção inequívoca para serializá-lo. Antes de converter um valor, identifique seu fuso horário ou deslocamento. Se essa informação não estiver disponível, registre a ausência: não presuma que o horário corresponde ao fuso do servidor ou do operador.
A normalização não deve sobrescrever o valor recebido. Preserve o texto ou valor original, o fuso horário declarado, a fonte e o valor normalizado derivado. Assim, será possível revisar conversões, resolver discrepâncias e reconstruir o que cada sistema informou.
- Armazene o valor original sem alterações.
- Registre o fuso horário ou deslocamento; indique explicitamente quando for desconhecido.
- Armazene o valor normalizado em um campo separado e documente a regra de conversão.
- Não invente precisão: preserve a precisão disponível e indique quando ela for desconhecida.
Diferenças de relógio, precisão desigual, duplicatas e eventos fora de ordem
Um timestamp, por si só, não basta para diagnosticar um relógio dessincronizado. Compare os campos apenas quando conhecer seu significado e fuso horário, e registre as diferenças observadas como indícios, não como prova automática de sua causa. Se o sistema fornecer informações confiáveis sobre sincronização ou qualidade do relógio, armazene-as separadamente; não as deduza de uma sequência aparentemente estranha.
Os callbacks podem chegar depois de outros eventos ou se repetir. Projete a ingestão para preservar os eventos recebidos, reconhecer possíveis duplicatas por meio de identificadores estáveis quando existirem e manter o histórico de alterações. Se não houver um identificador adequado, não conclua que dois informes representam o mesmo evento apenas porque compartilham status e horário.
- Diferencie o horário declarado do evento e o horário de recebimento local.
- Registre a precisão declarada ou disponível; não acrescente frações de segundo que não existiam.
- Preserve eventos atrasados e fora de sequência, em vez de descartá-los por chegarem depois.
- Use identificadores de mensagem e de evento quando estiverem disponíveis e documente seus limites.
- Não remova duplicatas de forma irreversível: preserve evidências da deduplicação.
Regras de reconciliação: precedência sem falsa certeza
Não há aqui uma regra universal respaldada para ordenar todos os eventos A2P SMS por precedência temporal. Defina regras internas por tipo de evento e com base no contrato ou na documentação técnica do fornecedor. Uma resposta de aceitação, um evento de status informado pelo fornecedor e o recebimento do callback devem permanecer como fatos distintos.
Quando duas fontes divergirem, evite escolher um único horário como «o verdadeiro» sem justificativa documentada. Você pode estabelecer um horário de referência operacional para relatórios, mas preserve todas as observações e identifique o critério aplicado. Se o significado ou o fuso horário de um dado não estiver claro, marque a comparação como inconclusiva.
- Defina a precedência pela semântica do evento, não pelo nome genérico do campo.
- Registre a regra aplicada, sua versão e as fontes envolvidas.
- Separe o status calculado pela sua plataforma dos status recebidos de terceiros.
- Encaminhe discrepâncias não resolvidas em vez de transformá-las em confirmação de entrega.
Campos mínimos para um registro auditável
Um registro útil deve permitir reconstruir o que foi recebido, de quem e como foi interpretado. O esquema exato depende da integração, mas é recomendável separar os dados de correlação, os dados originais, os horários normalizados e as decisões de reconciliação.
Limite o acesso aos dados identificáveis e aplique as políticas de retenção e segurança pertinentes à sua organização. A auditabilidade não exige tratar dados pessoais além do necessário para correlacionar eventos e resolver problemas.
- Identificador interno da mensagem e, se houver, identificador atribuído pelo fornecedor.
- Tipo de evento e status tal como recebidos, sem perder o valor original.
- Sistema ou fornecedor de origem e versão ou referência da interface, quando disponível.
- Timestamp original, fuso horário ou deslocamento declarado e precisão disponível.
- Timestamp de recebimento local e timestamp normalizado, armazenados separadamente.
- Identificador do evento ou callback, se houver, e resultado da detecção de duplicatas.
- Regra de reconciliação aplicada, resultado, motivo e momento da decisão.
- Indicador de incerteza quando não for possível determinar o significado, o fuso horário ou a sequência.
Exemplo: DLR atrasado e status final incerto
Suponha que uma plataforma registre o envio e, mais tarde, receba uma resposta de aceitação. Depois, registra outra transição e, por fim, recebe um callback cujo timestamp declarado parece anterior ao horário de recebimento local. A diferença pode decorrer de atraso na transmissão, de critérios distintos para os timestamps, de um fuso horário desconhecido ou de relógios desalinhados; sem dados adicionais, não é possível escolher uma causa.
A prática prudente é preservar os dois horários, associar o callback à mensagem apenas com chaves de correlação adequadas e sinalizar a sequência para revisão se ela contrariar as regras documentadas. O callback comprova que a plataforma recebeu um informe com determinado conteúdo. Sem documentação que estabeleça sua semântica e seu alcance, ele não deve ser apresentado como verificação independente de que o terminal recebeu o SMS.
- Mantenha o timestamp declarado pelo DLR e o timestamp de recebimento em campos separados.
- Não reordene nem apague o histórico para fazê-lo parecer cronológico.
- Registre o status comunicado e qualquer incerteza sobre seu significado.
- Comunique o resultado como status informado pelo fornecedor, não como prova independente do terminal.
Testes periódicos e limites de um timestamp
Valide o fluxo com testes controlados e legítimos nas suas próprias integrações. Verifique se os valores originais são preservados, se a conversão de fuso horário pode ser reproduzida, se eventos atrasados não são perdidos e se duplicatas são identificadas sem apagar o histórico. Repita a revisão quando houver mudanças na interface, na configuração ou nas regras do fornecedor.
Um timestamp, por si só, não comprova quem recebeu a mensagem, se o relógio estava sincronizado, se o evento ocorreu exatamente naquele horário nem se o conteúdo foi exibido no terminal. As conclusões dependem da definição do evento, da fonte e das evidências técnicas disponíveis. Documente esses limites nos relatórios operacionais e de reconciliação.
- Teste timestamps com e sem fuso horário e verifique se os valores originais permanecem intactos.
- Inclua casos de callbacks atrasados, repetidos e fora de sequência.
- Compare a interpretação local com a documentação vigente de cada integração.
- Audite regularmente diferenças de horário e resultados de reconciliação, sem transformá-los em garantias de entrega.
Perguntas frequentes
Um DLR recebido confirma que o SMS chegou ao terminal?
O recebimento do callback confirma que seu sistema recebeu um informe. Seu significado depende da semântica documentada pela fonte e, por si só, não equivale a uma verificação independente de recebimento no terminal.
Devo armazenar todos os timestamps em UTC?
Você pode manter um campo normalizado em UTC para comparar sistemas, mas preserve também o valor original e o fuso horário ou deslocamento declarado. Se o fuso for desconhecido, registre isso em vez de presumir um valor.
Qual horário deve prevalecer quando a plataforma e o fornecedor divergem?
Não existe uma regra de precedência universal aplicável a todos os campos. Defina regras por tipo de evento e conforme a documentação da integração, preserve as duas observações e identifique as discrepâncias não resolvidas.
Como devo tratar um callback que chega fora de ordem ou duplicado?
Preserve-o com seu horário de recebimento e seu timestamp declarado. Use identificadores estáveis para detectar duplicatas quando existirem, mantenha o histórico e não descarte eventos apenas por terem chegado atrasados.
O que uma diferença entre dois timestamps demonstra?
Demonstra que os registros apresentam valores distintos; não identifica, por si só, a causa. Pode haver diferenças de semântica, fuso horário, precisão, atraso ou relógio. São necessários dados adicionais para determinar a causa.
Fontes consultadas
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA