Solução de problemas de SMS troubleshooting-sms

O problema ocorreu em uma ou em várias contas

Nesse caso, você pode aplicar outros procedimentos de solução de problemas a cada conta individualmente. É melhor desabilitar outras contas ao diagnosticar uma conta para reduzir o tráfego de rede e o número de logs.

O problema não ocorreu quando apenas uma conta estava ativa a qualquer momento

Você tem um conflito entre contas. Como mencionado anteriormente, o Adobe Campaign trata as contas individualmente, mas o provedor pode tratá-las como uma única conta.

• Você está usando diferentes combinações de logon/senha em todas as suas contas.
  Você terá que entrar em contato com o provedor para diagnosticar possíveis conflitos referentes a ele.

• Algumas contas externas têm a mesma combinação de logon/senha.
  O provedor não tem como saber de qual conta externa o BIND PDU vem. Portanto, ele trata todas as conexões de várias contas como uma única. Ele pode ter roteado MO e SR aleatoriamente nas duas contas, causando problemas.
  Se o provedor der suporte a vários códigos curtos para a mesma combinação de logon/senha, você terá que perguntar a ele onde colocar esse código curto no BIND PDU. Observe que essa parte das informações deve ser colocada em BIND PDU, não em SUBMIT_SM, já que BIND PDU é o único local que permitirá o roteamento correto de MOs.
  Consulte a seção Informações em cada tipo de PDU acima para saber qual campo está disponível em BIND PDU. Normalmente, você adiciona o código curto a address_range, mas isso requer suporte especial do provedor. Entre em contato com ele para saber como espera rotear vários códigos curtos independentemente.
  O Adobe Campaign dá suporte à manipulação de vários códigos curtos na mesma conta externa.

Verifique se o conector foi alterado recentemente e por quem (verifique as Contas externas como um grupo).

select saccount, (sserver ||':'||sport) as serverPort, iextaccountid, CASE WHEN N0.iactive=1 THEN 'Yes' ELSE 'No' END as "(x) Enabled",

(select X1.sname from xtkoperator X1 where N0.icreatedbyid = X1.ioperatorid) as "Created By",

(select X1.sname from xtkoperator X1 where N0.imodifiedbyid = X1.ioperatorid) as "Last Modified By",

N0.slabel as "External Account", N0.tslastmodified as "LastModifiedDate"

from nmsextaccount N0 LEFT JOIN xtkoperator X0 ON (N0.icreatedbyid=X0.ioperatorid) order by 8 DESC LIMIT 50;

Verifique (no diretório /postupgrade) se o sistema foi atualizado e quando

Verifique se algum pacote que afeta o SMS pode ter sido atualizado recentemente (https://experienceleague.adobe.com/var/log/dpkg.log?lang=pt-BR).

Se o problema ocorrer em um ambiente mid-sourcing, verifique se a entrega e os logs amplos foram criados e atualizados corretamente no servidor mid-sourcing. Se não for o caso, não será um problema de SMS.

Se tudo funcionar no servidor intermediário e o SMS for enviado corretamente, mas a instância de marketing não for atualizada corretamente, talvez você tenha um problema de sincronização intermediária.

Se BIND PDU retornar um código diferente de zero command_status, peça mais informações ao provedor.

Verifique se a rede está configurada corretamente para que a conexão TCP possa ser estabelecida com o provedor.

Peça ao provedor que verifique se incluiu corretamente os IPs na lista de permissões da instância do Adobe Campaign.

Verifique as configurações de Conta externa. Pergunte ao provedor o valor dos campos.

Se a conexão for bem-sucedida, mas instável, verifique a seção Problema com conexões instáveis.

Se problemas de conexão forem difíceis de diagnosticar, uma captura de rede poderá fornecer informações. Verifique se a captura de rede é executada simultaneamente enquanto o problema ocorre para que ele seja analisado com eficiência. Você também deve observar a hora exata em que o problema ocorre.

A conexão dura menos de uma hora. As conexões do transmissor do Adobe Campaign Classic são uma exceção devido ao modo como o MTA do Adobe Campaign Classic funciona.

O provedor envia UNBIND PDUs.

enquire_link expira, no Adobe Campaign ou no provedor. Nesse caso, você pode ver ENQUIRE_LINK_RESP com um código de erro diferente de zero.

Há muitos BIND PDUs. Não deve haver mais do que alguns durante um dia, dependendo do número de conexões. Mais de 1 BIND PDU por hora deve gerar um alerta.

Conexões instáveis raramente são a causa principal. Muitas vezes, é o resultado de outro problema que aciona uma desconexão. Encontrar a causa raiz é a prioridade.

Ative rastreamentos SMPP detalhados. Você precisará deles para ver o que está acontecendo quando a conexão for reiniciada.

Se o provedor envia BIND PDUs, algo pode estar errado. Pergunte ao provedor por que UNBING é enviado.

Fazer uma captura de rede às vezes é a única maneira de ver como a conexão é fechada.

Se o provedor fechar as conexões enviando um TCP FIN ou umTCP RST packet, peça mais informações a ele.

Se o provedor fechar a conexão depois de enviar um erro limpo, comoDELIVER_SM_RESP, com um código de erro, ele deverá corrigir o conector. Caso contrário, isso impedirá que outros tipos de mensagens sejam transmitidas e acionará a limitação do MTA. Isso é especialmente importante no modo transceptor, em que o fechamento da conexão afeta tanto o MT quanto o SR.

Verifique se a conexão está estável. Uma conexão SMPP deve permanecer ativa por pelo menos uma hora continuamente, exceto para transmissores no Adobe Campaign Classic. Consulte a seção Problema com conexões instáveis.

Se o reinício do MTA fizer com que o envio do MT funcione novamente por um breve período, provavelmente você terá uma limitação devido a uma conexão instável. Consulte a seção Problema com conexões instáveis.

Verifique se o log amplo está presente e com o status e as datas corretas. Se não for o caso, poderá ser um problema de entrega ou de preparação de entrega.

Verifique se o MTA realmente processa a mensagem. Se não for o caso, talvez não seja um problema de SMS.

Verifique se o conector de SMS está associado ao equipamento do provedor. Solicite feedback ao provedor para garantir que todos os sistemas estejam se comunicando corretamente. Consulte BIND_TRANSMITTER e BIND_TRANSCEIVER PDUs para obter informações sobre o processo de associação. Talvez seja necessário ativar os rastreamentos SMPP para solucionar problemas corretamente.

Com os rastreamentos SMPP ativados, verifique se SUBMIT_SM PDU contém as informações certas.

Verifique se o provedor responde com um SUBMIT_SM_RESP PDU com um valor "OK" (código 0). Verifique se a PDU chega com um atraso razoável: qualquer tempo superior a 1 segundo deve ser discutido com o provedor. Geralmente, chega em menos de 100 ms.

Se todas essas etapas funcionarem, você poderá ter certeza de que o problema se refere ao provedor. Ele terá que solucionar problemas na respectiva plataforma.

Se isso funcionar, mas o tráfego for inconsistente, tente ajustar a janela de envio e diminuir o rendimento do MT. Você precisará trabalhar com o provedor para ajustar isso. O Adobe Campaign pode enviar mensagens muito rapidamente. Portanto, problemas de desempenho podem surgir no equipamento do provedor.

Se duplicatas forem enviadas com um intervalo de exatamente 60 segundos, provavelmente será um problema referente ao provedor, que não envia um SUBMIT_SM_RESP com rapidez suficiente.

Se há muitos BIND/UNBIND, você tem uma conexão instável. Consulte a seção Problema com conexões instáveis para obter soluções antes de tentar resolver problemas de mensagens duplicadas.

Você precisará de rastreamentos SMPP ativados para realizar qualquer tipo de solução de problemas de SR.

Verifique se DELIVER_SM PDU vem do provedor e se está corretamente formado.

Verifique se o Adobe Campaign responde com um DELIVER_SM_RESP PDU bem-sucedido em tempo hábil. No Adobe Campaign Classic, isso garante que o SR foi inserido na tabela providerMsgId para processamento posterior pelo processo de SMS.

Verifique o regex relacionado à extração de id e ao processamento de erros na Conta externa. Talvez seja necessário validá-los em relação ao conteúdo de DELIVER_SM PDU.

Verifique se os erros foram devidamente provisionados na tabela broadLogMsg.

Ativar rastreamentos SMPP durante testes. Se você não ativar o TLS, deverá fazer uma captura de rede ao solucionar problemas do MO para verificar se as PDUs contêm as informações corretas e estão formatadas adequadamente.

Ao capturar tráfego de rede ou analisar rastreamentos SMPP, capture toda a conversa com o MO e seu MT de resposta se uma resposta estiver configurada.

Se o MO (DELIVER_SM PDU) não aparece nos rastreamentos, o problema se refere ao provedor. Ele terá que solucionar problemas em sua plataforma.

Se DELIVER_SM PDU for exibido, verifique se ele foi confirmado pelo Adobe Campaign com um DELIVER_SM_RESP PDU bem-sucedido (código 0). Esse RESP garante que toda a lógica de processamento foi aplicada pelo Adobe Campaign (resposta automática e lista de permissão/bloqueio). Se esse não for o caso, procure uma mensagem de erro nos logs de processo do SMS.

Se as respostas automáticas estiverem ativadas, verifique se SUBMIT_SM foi enviado ao provedor. Caso contrário, você encontrará uma mensagem de erro nos logs de processo de SMS.

Se o SUBMIT_SM MT PDU que contém a resposta for encontrado nos rastreamentos, mas o SMS não chegar ao telefone celular, você terá que entrar em contato com o provedor para obter assistência na solução de problemas.

Verifique se o formato do número de telefone é exatamente o mesmo na tabela de quarentena e no log de entrega. Caso contrário, consulte esta seção se tiver problemas com o prefixo "+" do formato de número de telefone internacional.

Verifique os códigos curtos. Poderão correr exclusões se o código curto do destinatário for igual ao definido na conta externa ou se estiver vazio (vazio = qualquer código curto). Se apenas um código curto for usado para toda a instância do Adobe Campaign, será mais fácil deixar todos os campos de código curto vazios.

Ative as mensagens SMPP detalhadas quando o problema surgir. A maioria dos problemas de SMS é impossível de resolver sem isso.

Se o problema estiver relacionado ao tráfego de SMS, entre em contato primeiro com o provedor. A plataforma dele é mais adequada para o diagnóstico eficiente dos problemas de tráfego de SMS em tempo real.

Inclua uma descrição breve e concreta do problema.

Inclua uma descrição do resultado esperado.

Inclua o feedback do provedor.

Inclua logs e/ou capturas de rede relevantes. Ao fazer capturas, reproduza o problema durante a captura.

Se você incluir logs, rastreamentos ou capturas, aponte o local exato no arquivo quando o problema ocorrer.

Se você mencionar mensagens, PDUs ou logs, indique claramente a data e a hora para facilitar a localização.

Tente reproduzir o problema em um ambiente de teste. Se não tiver certeza sobre uma configuração, experimente-a no ambiente de teste e verifique o resultado com os rastreamentos SMPP. Geralmente, é melhor relatar problemas replicados em ambientes de teste do que problemas em ambientes de produção.

Inclua qualquer alteração ou ajuste feito na plataforma. Além disso, inclua qualquer alteração que o provedor possa ter feito.

Problemas de conexão, mas as mensagens detalhadas não mostram nenhum BIND_RESP PDU.

Desconexões inexplicáveis sem mensagem de erro, o comportamento normal do conector quando detecta um erro de protocolo de baixo nível.

O provedor reclama sobre o processo de desconexão/desassociação.

Problemas de codificação em campos TLV opcionais.

Há suspeita de que o tráfego esteja misturado entre conexões diferentes.

TLS ativado: por definição, o tráfego TLS é criptografado para que não possa ser capturado.

Problemas de desempenho: os logs contêm todas as informações necessárias para rastrear problemas de desempenho.

Problemas de tempo (retry timing, enquire_link duração, limite de rendimento etc.)

Análise e processamento SR: os registros detalhados dão muito mais contexto e uma apresentação melhor.

Processamento de MO (respostas automáticas, quarentena).

Erros que não envolvem o tráfego SMPP real: preparação de entrega, problemas da API do centro de mensagens, problemas de fluxo de trabalho etc.

Recebido no Celular:
A mensagem foi entregue com êxito ao dispositivo do usuário, com confirmação fornecida pela entrega Terminada por dispositivo móvel (MT) e um Relatório de status (SR).

Enviado:
A mensagem foi processada com êxito por meio da etapa Mobile Terminated (MT), mas um Relatório de Status (SR) confirmando a entrega para o dispositivo móvel ainda não foi recebido.

Enviado ao Provedor:
A mensagem foi enviada ao provedor usando o SUBMIT_SM command, mas nenhuma confirmação SUBMIT_SM_RESP foi recebida do provedor.

Pendente: a mensagem ainda não foi enviada para o agregador.

Levado em Conta pelo Provedor: a mensagem foi enviada ao agregador e o agregador confirmou a confirmação.

Enviado: o agregador confirmou que a mensagem foi enviada com êxito para a rede móvel do usuário sem nenhum erro imediato.

Recebido no Celular: o dispositivo móvel do usuário confirmou a confirmação e isso foi verificado pelo agregador.

Falha: a mensagem foi enviada ao agregador, que tentou entregar ao dispositivo móvel do usuário por um período definido (por exemplo, várias horas). A entrega falhou devido a problemas de rede, indisponibilidade do dispositivo do usuário ou outros motivos.