Skip to main content
Uma recusa é uma mensagem que o FireFlo declinou antes de rotear. Fica registrada em cdr_rejected, e é um bicho diferente de uma mensagem que roteou e falhou.
Ou, sem SQL, a lista Refused no painel de controle. Ela traz as mesmas linhas com a requisição que as produziu.

​
As razões

A coluna SMPP é o que o submit_sm_resp do cliente carregou; a coluna HTTP é o equivalente REST. Três dos quatro são códigos específicos do fornecedor na faixa 0x4xx, e não os SMPP padrão. 0xC3 é a exceção, sendo ESME_RMISSINGOPTPARAM da especificação. O cliente SMPP do cliente não vai ter nomes para os valores 0x4xx, então cite a palavra da razão, não o número. | filtered | Um filtro recusou | varia | Leia o filtro | | maxAttempts | Não é uma recusa. O roteamento desistiu | nada na hora do submit | Nada é entregue |

​
O que toda recusa tem em comum

Nada foi cobrado, ou a cobrança foi revertida. Uma recusa não custa nada ao cliente, e é por isso que é seguro ser rígido com elas. E por isso insufficientCredit não é um paradoxo.

​
A mais difícil de explicar

Uma recusa de conteúdo multipart acontece depois de todo segmento ter sido reconhecido.Em SMPP, o conteúdo é checado contra um template só depois de os segmentos serem remontados. Na hora do submit o body ainda é um fragmento, e "Your OTP is {#var#}, valid" não casa com nenhuma parte de uma mensagem de duas partes.Então o cliente do cliente viu um OK em cada segmento, e a mensagem foi então descartada, reembolsada e registrada. Não há erro que ele pudesse ter capturado, e o receipt é o único sinal.Esta é a forma normal para templates DLT em idiomas indianos, onde UCS-2 coloca 67 caracteres em um segmento. Então um template que funciona em inglês começa a falhar no momento em que o texto é traduzido.

​
Lendo um templateNotMatched

Quase sempre uma de quatro coisas, em ordem decrescente de com que frequência é de fato a causa:
Espaços em branco são normalizados antes do match, então sequências de espaços e quebras de linha não são o problema. Qualquer outra coisa — um ponto final a mais, uma palavra trocada, uma posição diferente de variável — é.O preview de template no painel mostra uma amostra de mensagem que o template aceita. Compare com o que o cliente de fato enviou, que está na linha de cdr_rejected.
Um nome de placeholder não reconhecido — {#VAR#}, {#otp#} — carrega como uma variável genérica em vez de ser descartado, e a linha é reportada em templates_degraded em /ops/health.Ainda faz match, mas muito mais frouxo do que o pretendido: {#var#} aceita qualquer coisa até o limite de tamanho. Se um template está aprovando mensagens que não deveria, olhe aqui primeiro.
smsg.whitelist.max.variable limita quanto texto um placeholder pode representar. Um template de "Your code is {#var#}" com um body de 900 caracteres é recusado mesmo com o texto casando.
O modo REPORT conta o que seria recusado sem recusar. whitelist_would_reject em /ops/health. Rodar uma conta nova em REPORT por um dia antes de fazer enforcement transforma essa classe inteira de incidente em um número que você lê com calma.

​
insufficientCredit em uma conta com dinheiro

Não é contradição, e é a surpresa mais comum na operação pré-paga. Crédito é reservado em blocos, não por mensagem. O bloco é max(smsg.balance.block.min, price × smsg.balance.block.min.messages). Vinte mensagens por padrão. Uma reserva tenta três degraus decrescentes: o bloco cheio, esse piso, depois a única mensagem que pediu. Assim o piso nunca deixa dinheiro parado. Uma conta gasta cada unidade que tem.
Uma recusa em uma conta com dinheiro restante geralmente é uma recarga em trânsito. Recargas são assíncronas, então uma mensagem chegando no meio de uma reserva pode ser recusada; a retentativa dá certo. Recusas persistentes com saldo saudável são outro problema. Verifique o ledger e reserved.

​
Relacionados

Whitelisting

Aprovando sender IDs e texto.

Crédito pré-pago

Blocos, reservas e a identidade do dinheiro.