A2P SMS Connectivity Failure or Route Degradation: How to Isolate the Cause with Evidence

Connectivity, acceptance, and delivery are different signals

An A2P SMS incident can occur at different points along the journey. The connection may fail before the message is submitted; the platform or SMSC may reject it; the submission may be accepted without a final outcome being available yet; or a failure may occur after acceptance. Each situation requires different evidence.

In SMPP, a successful submit_sm response indicates that the SMSC accepted the message for subsequent submission. It does not, by itself, confirm that the message reached the phone. Likewise, ENQUIRE_LINK and ENQUIRE_LINK_RESP check the application connection between the ESME and SMSC, not delivery through the mobile network.

• Connection or session: check whether the client can establish and maintain communication with the interface.
• Submission response: determine whether the request was accepted or rejected, and record any available reason.
• Subsequent outcome: correlate status reports with the original message and verify which entity issued them.
• Human receipt: do not infer that someone read the SMS from a protocol response or DLR.

Map the message path and preserve identifiers

Before changing routes or configuration, map the path the traffic actually takes: client application, HTTP integration or SMPP session, platform, provider, and mobile destination. Note where each record originates and who generates each response. The internal functionality of a Service Centre may fall outside what an interface or specification lets you observe; acknowledge that limit in your analysis.

Preserve timestamps and references that are sufficient to link the stages. In SMPP, record the request and response sequence number, the returned message ID, and, if a receipt arrives, its reference to the original message. For HTTP, retain the available request ID, time, endpoint, and response. Do not assume that identifiers from different systems are interchangeable.

• Record the submission time and time zone, normalized destination, sender, traffic type, and selected route.
• Save the HTTP code or SMPP status, relevant response body or error fields, and available correlation ID.
• Record the time and origin of each callback or DLR, along with its reference to the message.
• Protect personal data and restrict access to logs in accordance with applicable policies.

Check the integration first

Start with the part you control. For HTTP, distinguish transport errors from HTTP responses and inspect the code, body, and any retry guidance. A 503 means the server is temporarily unable to handle the request; it may, for example, be associated with overload or maintenance, and Retry-After can indicate how long to wait. A 429 means the server considers that too many requests have been sent in a period; the response may also include Retry-After. A 502 identifies a gateway or proxy problem involving an invalid response from the upstream server, but does not, by itself, identify which component caused the problem.

For SMPP, check bind status, disconnections, timeouts, responses to requests, and session health. ESME_RTHROTTLED (0x58) indicates that the ESME exceeded the limits allowed on that interface. This is evidence of rate limiting there, not proof of degradation on a destination route.

Also review the local queue, callback acknowledgments, and retry logic. SMPP does not guarantee idempotency by itself. If a timeout occurs, that signal alone may not reveal whether the SMSC processed the request. Before retrying, use documented correlation and status-query mechanisms that are available, if any; do not assume it is always possible to determine whether the operation was already accepted.

• If the connection or bind fails, first investigate credentials, session configuration, connectivity, and interface limits.
• If you receive rejections, group them by code and preserve the original responses before changing parameters.
• If 429 or ESME_RTHROTTLED responses appear, compare request volume and rate with the agreed limits; do not automatically label them as a coverage failure.
• For a 503 or 502, contact the team responsible for the responding component and provide the time, identifier, and observed response.

Look for patterns by destination and traffic attributes

Investigate route degradation by looking for repeatable differences between segments, rather than isolating a single message without context. Compare destinations, operators when the information is reliable, senders, traffic type, route, and time window. Keep other relevant attributes constant where possible: comparing different submissions can confound the effect of the route with changes to the recipient, sender, content, or configuration.

Record which segment fails and which serves as the comparison. If an incident coincides with a destination operator, that is a clue that can help narrow the investigation; it is not enough to prove that the operator’s network is the cause. Verify that the samples and parameters are comparable, and request additional evidence from the parties that control stages you cannot observe.

• Group cases by country or destination, known operator, sender, OTP/transactional/marketing traffic, route, and time period.
• Compare acceptance, rejection, and final-status rates separately; do not combine metrics with different definitions.
• Verify that the compared messages have equivalent configuration and that the time windows are consistent.
• Note configuration, volume, or client-behavior changes that coincide with the start of the problem.

Compare controlled samples without confusing correlation with cause

Select equivalent samples and decide in advance which signal you will compare: submission response, time until a response, callback arrival, or reported status. Avoid combining events from different stages into a single figure. An observed difference between two segments can help form hypotheses, but does not establish causation on its own.

When safe and authorized, run limited comparisons using legitimate, consented traffic. Do not change several variables at once: if you change the route, sender, and configuration together, it will be harder to determine what changed the outcome. Coordinate tests with the relevant teams and avoid generating unnecessary additional traffic.

• Define the affected group, a comparison group, and the time period before reviewing results.
• Control for relevant destination, sender, message type, configuration, and sending conditions.
• Separate acceptance measures from delivery measures, and disclose missing data.
• Repeat the comparison in another time window if sample volume or composition could explain the difference.

Interpret DLRs according to their source and scope

A DLR is a signal whose meaning depends on who issues it and how it is defined in the integration. In the 3GPP specification, a report from the Service Centre confirms receipt by the centre, not necessarily by the terminal; a report issued by the mobile station confirms receipt by the terminal, not that the user read the message. Check the report’s origin and the status it represents before using it as evidence.

An SMS-STATUS-REPORT provides information about the status of a submission, but is not automatically equivalent to confirmation of human receipt. There may also be differences between what an interface calls “delivered” and the technical event that supports that status. If the DLR issuer or its semantics are unclear, document that uncertainty and ask the provider for clarification.

• Correlate the report with the original message ID and preserve its timestamp.
• Ask which entity generates the status, which event it confirms, and which failure states it can represent.
• Distinguish a missing DLR, a delayed report, and a failure status; do not treat them as equivalent.
• Do not use an isolated DLR to attribute the issue to the mobile network, provider, or terminal.

Decision tree for isolation and escalation

Apply the diagnosis in order, from the first observable stage through to the subsequent outcome. Stop the investigation at the first stage for which evidence is unavailable and request the necessary records; do not jump from an integration symptom to a conclusion about the destination network.

If service is degraded, prioritize safe and reversible measures: reduce or pause affected traffic when there is a risk of duplication, abuse, or operational impact, and follow the agreed procedure for changing routes. Do not assume that an alternative route exists, offers the same behavior, or is authorized for that traffic.

• No HTTP connection or SMPP bind: collect timestamps, transport errors, session status, and recent changes; escalate to the team responsible for connectivity or integration.
• Session established, but submission rejected: group codes and responses. Check formatting and interface limits; escalate with examples that can be correlated.
• Submission accepted, but no outcome is available: check callbacks, timeouts, and DLR meaning. Ask the provider for the status of the subsequent stage; acceptance does not prove delivery.
• Reports show failures concentrated in a segment: validate equivalent samples and share the pattern with the provider and destination-side parties, without declaring a cause until there is evidence from that stage.
• Results conflict or identifiers do not correlate: suspend conclusions, check clocks, references, and duplicates, and reconstruct the path from the original records.

Document evidence, uncertainties, and actions

A good report lets another team reproduce the reasoning without assuming the cause. Separate observed facts, hypotheses, and conclusions; state which systems supplied each record and which parts of the journey remain unobserved. Attach a small, representative sample with data protected, not just aggregate screenshots without identifiers.

Standards provide different limits and signals for each stage: connection, acceptance, and status reports. The diagnosis should reflect those limits and distinguish verifiable observations from hypotheses that still require evidence.

• Summarize the known impact, start and end times, affected and unaffected segments, and recent changes.
• Include timestamps, identifiers, original responses, and the definition of each status analyzed.
• Label each item as a fact, hypothesis, outstanding data, or action taken.
• Record who needs to provide the next evidence and when the diagnosis will be reviewed.