Skip to main content
This is the failure that wastes the most time, because a vendor refusing every message looks perfectly healthy: the sessions are up, the queue drains, acceptsMessages() is true. The message is accepted, routed, submitted, refused, requeued, and dropped at outSms.routing.maxAttempts — and the drop says reason=maxAttempts, which describes the symptom rather than the cause.

​
Where the cause actually is

message.submit.response, which carries the vendor’s command_status:
The same value is on the vendor card in the panel and on /ops/health as last_submit_error, with submit_rejected counting them — so a lane refusing everything is visible without reading a log at all.

​
What the common codes mean

The gateway carries the full table, and writes the plain-English sentence beside every code it recognises. A code outside it logs as vendor-specific, deliberately: vendors do use their own, and inventing a name would send you looking for a spec entry that does not exist.

​
The 192–196 block is always about TLVs

If a lane starts refusing everything with one of those five, look at the message’s TLVs, not at routing. Three things supply them, composing in this order:
1

The vendor's own default.tlvs.submit

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

The credential's defaultTlvs

Per-customer values.
3

The whitelist stamp

For an approved sender header or template.
The commonest cause is the third. Nothing approved means nothing stamped, so a DLT lane receives a submit with no entity or template id and refuses it. tlvCount=0 on the trace lines confirms it. The second commonest is a malformed default. The format is <name>_<tag>=<value> — writing PEID=1101778070000018542 instead of peid_0x1400=1101778070000018542 parses to nothing, and the TLV is dropped with only a WARN:
A malformed default is the hardest of these to see, because the setting looks applied. It is present in the configuration, the gateway started cleanly, and the only evidence it did nothing is one WARN at load time and a tlvCount that is lower than you expect.

​
One vendor, many more submits than you configured

If a vendor reports far more rejected submits than you sent messages, the two retry ceilings are compounding: a vendor’s own retry budget is spent within one routing attempt, and a refusal returns the message to the router, which has its own attempt ceiling. With a single vendor configured, re-routing sends it straight back and spends a fresh budget.
Watch submit_rejected against submitted on the vendor card. A ratio well above one is this compounding, not a vendor problem — and it is worth catching, because every one of those PDUs is traffic your carrier sees.

TLVs in practice

Where a tag comes from and what overrides what.

Queues and retries

Attempt ceilings, backoff and what a requeue costs.