Skip to main content
Esta é a falha que mais desperdiça tempo, porque um fornecedor recusando toda mensagem parece perfeitamente saudável: as sessões estão up, a fila drena, acceptsMessages() é true. A mensagem é aceita, roteada, submetida, recusada, re-enfileirada, e descartada em outSms.routing.maxAttempts. E o drop diz reason=maxAttempts, que descreve o sintoma e não a causa.

​
Onde a causa de fato está

message.submit.response, que carrega o command_status do fornecedor:
O mesmo valor está no card do fornecedor no painel e em /ops/health como last_submit_error, com submit_rejected contando. Então uma rota recusando tudo fica visível sem precisar ler um log.

​
O que os códigos comuns significam

O gateway carrega a tabela completa, e escreve a frase em inglês simples ao lado de todo código que reconhece. Um código fora dela loga como vendor-specific, de propósito: fornecedores usam os próprios, e inventar um nome mandaria você procurar uma entrada de spec que não existe.

​
O bloco 192–196 é sempre sobre TLVs

Se uma rota começa a recusar tudo com um destes cinco, olhe os TLVs da mensagem, não o roteamento. Três coisas os fornecem, compondo nesta ordem:
1

O default.tlvs.submit do próprio fornecedor

outSms.instance.<name>.default.tlvs.submit
2

Os defaultTlvs da credencial

Valores por cliente.
3

O carimbo do whitelist

Para um sender header ou template aprovado.
A causa mais comum é a terceira. Nada aprovado significa nada carimbado, então uma rota DLT recebe um submit sem entity ou template id e recusa. tlvCount=0 nas linhas de trace confirma. A segunda mais comum é um default malformado. O formato é <name>_<tag>=<value>. Escrever PEID=1101778070000018542 em vez de peid_0x1400=1101778070000018542 parseia para nada, e o TLV é descartado com apenas um WARN:
Um default malformado é o mais difícil desses de enxergar, porque a configuração parece aplicada. Está presente na configuração, o gateway subiu limpo, e a única evidência de que não fez nada é um WARN no carregamento e um tlvCount menor do que você esperava.

​
Um fornecedor, muito mais submits do que você configurou

Se um fornecedor reporta muito mais submits rejeitados do que mensagens enviadas, os dois tetos de retentativa estão se compondo: o orçamento de retentativas do fornecedor é gasto dentro de uma tentativa de roteamento, e uma recusa devolve a mensagem para o roteador, que tem seu próprio teto de tentativas. Com um único fornecedor configurado, re-rotear manda direto de volta e gasta um orçamento novo.
Observe submit_rejected contra submitted no card do fornecedor. Uma razão bem acima de um é essa composição, não um problema de fornecedor. E vale detectar, porque cada um desses PDUs é tráfego que sua carrier vê.

​
Relacionados

TLVs na prática

De onde vem uma tag e o que sobrescreve o quê.

Filas e retentativas

Tetos de tentativa, backoff e o que uma re-enfileirada custa.