Fallback A2P SMS: When to Switch Routes and When to Stop Traffic to Investigate

A2P SMS fallback is a containment measure, not a delivery guarantee

A2P SMS fallback consists of controlled diversion of some or all traffic from a primary route to an alternative route when there are sufficient signs of degradation. Its purpose is to reduce operational impact while the cause of the issue is validated. It does not turn SMS into a channel with guaranteed delivery, nor does it remove the need to investigate the quality of the original route.

In SMPP, the response to submit_sm confirms the outcome of that protocol request. On successful submission, it returns an SMSC-assigned message_id. It does not confirm that the message reached the handset. To assess the subsequent outcome, the ESME may use a requested SMSC Delivery Receipt and, where supported by the SMSC, status query capabilities. Neither mechanism guarantees that an outcome will be received, complete, timely, or interpreted uniformly across integrations.

For this reason, a mature fallback policy must make two separate decisions: when it is reasonable to try another route, and when the observed behavior requires stopping or limiting traffic to preserve evidence and prevent further harm.

• Treat fallback as a reversible, limited action.
• Keep the investigation active even if alternative traffic appears to work.
• Do not use submit_sm acceptance as proof of delivery to the recipient.
• Do not interpret SMPP session recovery as full route recovery.

What can go wrong with poorly designed fallback

An automatic route switch can protect a critical operation, but it can also amplify an incident. The most delicate case occurs when the original message has been accepted by the SMSC, remains in progress, or its final status arrives late, and the system resends the same content through a second route. The recipient may receive two messages, two codes, or contradictory communications.

There is also a diagnostic risk. If the system diverts all traffic too early, degradation on the primary route can be hidden by aggregated results. Without control cohorts, correlatable logs, and scope limits, it becomes difficult to distinguish a connectivity failure, incorrect destination validation, a capacity constraint, or an issue localized to a particular destination or operator.

Cost and traceability matter as well. Every attempt must be linked to one sending intent and the route used. Without this correlation, it is not possible to determine whether there was a retry, duplicate, expiration, rejection, or delayed delivery of the first attempt.

• Duplicates caused by resending before the outcome of the initial attempt is known.
• Uncontrolled cost from multiplying attempts or opening global fallback.
• Loss of evidence when results from different routes are mixed.
• Persistent degradation hidden by diverting traffic without isolating the cause.
• Incorrect decisions when all destinations are grouped into a single indicator.

Classify traffic before defining retries

The same policy does not work for every legitimate message. Sensitivity to time, context, and duplication should be part of the decision. An OTP can lose value quickly, and a second send can confuse the user or invalidate an authentication flow. An urgent transactional notification may justify limited use of an alternative route, provided the application controls idempotency for the business event. A consented marketing campaign usually allows more caution: it is better to wait, reschedule, or investigate than to duplicate communications.

Classification must exist before the incident, not during it. Each sending intent should include at least a message type, a validity period, a retry policy, and an explicit rule on whether it allows a second route.

• OTP: short usefulness window; avoid blind resends and control the code lifecycle.
• Urgent transactional: apply fallback only if the business event supports idempotency and the duplicate risk is defined.
• Non-critical notification: prioritize observation, rescheduling, or deferred sending over immediate retry.
• Consented marketing: do not use urgency as a justification for multiplying messages; comply with the applicable contact policy.

Signals that may justify a route switch

Signals should be assessed in layers. Immediate protocol errors may require a different response from final delivery outcomes. SMPP defines command_status to communicate the success or failure of a request. Possible errors include system errors, message limits exceeded, and addressing validation issues. A destination TON or NPI error is not, by itself, evidence that the route is degraded: it may indicate a normalization or sending configuration issue.

Session availability must also be separated from delivery performance. A bind can be active while the route still has problems with submit_sm, DLR reception, or subsequent message processing. Likewise, a recovered session does not prove that final outcomes have returned to operationally acceptable levels.

A lack of DLRs can be a relevant signal only when interpreted against receipt configuration, the observation window, message type, and the known historical behavior of that integration. Intermediate notifications do not provide a portable basis for global fallback: their support is specific to the SMSC implementation.

• Repeated protocol errors affecting submit_sm or commands required for operation.
• Throttling or capacity limits that require reducing throughput before increasing routes.
• Address, TON, or NPI errors that should be isolated as a possible validation issue.
• Session loss or instability, distinguished from submission and delivery outcomes.
• Observed degradation in final statuses or latency, segmented by destination and route.
• Abnormal absence of DLRs, after verifying that they were requested and that the integration processes them correctly.

Do not confuse SMPP statuses with independent receipt on the handset

Status terminology must be handled precisely. ENROUTE means that the message is in progress; it is not delivery. DELIVERED is a distinct status within SMPP. ACCEPTED must not be interpreted as receipt on the handset either: the specification describes it as a message accepted after being manually read on behalf of the subscriber by customer service.

A DLR is valuable for operations and event correlation, but it should not be treated as independent and uniform proof across all providers. SMPP allows delivery receipt information to be inserted into short_message in an SMSC-provider-specific format. Error codes may also depend on the network or SMSC. Internal normalization should always preserve the original value alongside a documented operational classification.

The practical conclusion is simple: do not trigger a resend merely because a message remains ENROUTE, because the DLR has not yet arrived within an arbitrary window, or because a provider uses a text label that appears conclusive. Use rules based on context, validity period, incident pattern, and duplicate risk.

• submit_sm_resp: confirms the response to submission, not final delivery.
• ENROUTE: an in-progress status; do not trigger a resend based on this status alone.
• DELIVERED: a delivery status reported by the SMS ecosystem, not independent verification of human reading.
• ACCEPTED: does not mean receipt on the handset.
• EXPIRED, UNDELIVERABLE, REJECTED, and UNKNOWN: should be retained as distinct outcomes for analysis and decision-making.

Design segmented thresholds, not a single global switch

A global threshold combines populations that may behave differently. At a minimum, the policy should segment by destination normalized according to the applicable numbering plan. In the SMPP exchange, destination_addr, TON, and NPI are part of the technical context that should be recorded and validated. When available telemetry permits, add route, message type, sender, time window, and error class.

Thresholds should combine a minimum volume and a time window. A small variation with few observations should not trigger a mass switch. Likewise, degradation concentrated in one destination should not justify diverting unaffected countries or destinations. Define in advance which combination of signals triggers observation, limited fallback, containment, or investigation.

It is not prudent to set universal values for percentages, minutes, or retry counts without understanding the contractual, technical, and operational behavior of each integration. The right threshold is one that can be explained, tested, and reviewed using the available data.

• Require a minimum number of observations before assessing aggregate degradation.
• Measure within defined time windows and retain the time of every event.
• Segment by destination, route, message type, and, where relevant, sender and error class.
• Separate destination validation errors from route quality indicators.
• Document the exact reason that triggers every state transition.

Define an operational state machine

A fallback policy should be expressible as a state machine that an operator can audit. This reduces ambiguous decisions and prevents automation from moving directly from an isolated alert to mass diversion. The state machine does not replace SMPP statuses; it organizes the operational response to protocol signals, availability, and observed outcomes.

A practical model starts with the primary route under normal conditions, moves to observation when initial signals appear, uses limited fallback when there is sufficient evidence, and maintains an explicit containment and investigation phase for persistent incidents. Recovery requires gradual validation, not merely restored connectivity.

• Primary route: normal traffic and segmented monitoring.
• Observation: alert opened, data validated, no diversion or only minimal test scope.
• Limited fallback: diversion of a defined cohort, with an attempt budget and duplicate controls.
• Containment: reduction, pause, or isolation of affected traffic when risk exceeds the benefit of resending.
• Investigation: analysis of correlations, configuration, errors, and recent changes.
• Recovery: gradual return to the primary route after verifiable stability criteria are met.

Operational runbook for switching, containment, and recovery

The operational response should follow the defined states and retain enough evidence to explain every action. Before moving traffic, validate whether the observed signal reflects route degradation, a destination or configuration issue, a capacity limit, or incomplete receipt processing. Do not treat a missing or delayed DLR as conclusive without checking whether DLRs were requested and whether the integration is receiving and processing them.

When evidence supports a route test, freeze the affected cohort definition and divert only that limited cohort. Preserve a control cohort on the primary route where operationally appropriate, reduce throughput when throttling or capacity limits are observed, and apply the defined attempt budget and waiting window. If duplicate risk, configuration errors, or persistent degradation outweigh the benefit of diversion, contain the affected traffic by reducing, pausing, or isolating it.

Recovery should begin only after segmented evidence supports it. Restored bind connectivity alone is insufficient. Return traffic gradually while continuing to compare submission responses, final outcomes where available, receipt behavior, latency, error classes, and the scope of affected destinations.

• Open the incident and freeze the affected cohort definition.
• Validate destination normalization, TON, NPI, DLR request settings, DLR processing, and relevant configuration changes.
• Record the internal sending-intent ID, route, submit time, protocol response, SMSC message_id, DLR or supported query result, final state, error code, and configuration changes.
• Reduce throughput before expanding routing when throttling or capacity limits are present.
• Activate only the predefined limited fallback cohort, with duplicate controls and an attempt budget.
• Contain, pause, or isolate affected traffic when evidence is insufficient, duplicate risk is high, or degradation persists.
• Review recent configuration changes and correlate outcomes by destination, route, message type, sender, and error class.
• Restore traffic gradually only after stability is verified beyond session connectivity.