Direct Routes and Hubbing in A2P SMS: How to Assess the Delivery Chain
A route label alone is not enough to assess an A2P connection. Learn how to document the stated topology, request evidence, and compare results using cautious criteria.
What “direct route” and “hubbing” mean
In commercial discussions, “direct route” is often presented as a connection with fewer intermediaries, while “hubbing” generally refers to traffic passing through one or more intermediaries. However, these labels do not have independently verifiable definitions in the documentation available here. Their meaning may depend on how each provider describes its own chain.
For that reason, do not compare routes solely by the name shown in a proposal, interface, or invoice. Ask the provider to explain what it means by each term and describe the stated topology for the destinations and traffic types you are interested in.
- Treat “direct,” “hub,” and similar terms as commercial claims until they are documented.
- Request a description for each destination or group of destinations; a general answer may not apply to all of them.
- Record the date and scope of each statement, since the chain may change.
What topology does not prove
A route described as direct does not guarantee better delivery. Nor can you conclude, without additional evidence, that the route is authorized for its intended use, covers all advertised destinations, or delivers every message. Similarly, the presence of an intermediary alone is not enough to conclude that quality is lower.
The stated topology is one dimension of assessment, not a substitute for operational evidence or contract review. Separate what the provider claims about the chain from what you can observe about performance and what has been agreed for the service.
- Do not turn a route label into a delivery guarantee.
- Check the stated scope, terms of use, and observed results separately.
- Do not infer authorization or regulatory compliance from the number of intermediaries alone.
Draw a basic map of the chain
Document the route as a sequence of functions, not as a list of brands. The map may include your originating system, the immediate provider, any intermediaries the provider identifies, the party said to manage termination, and the points where statuses are generated, transformed, or transmitted. If a segment is not disclosed, mark it as unconfirmed.
Ask the provider to identify the scope the map applies to: relevant destinations, senders, message types, and traffic conditions. Do not assume that a topology described for one case also covers another.
- Origin: the system or connection from which the message is handed to the provider.
- Stated intermediation: the entities or functions involved, to the extent they can be identified.
- Stated termination: the party the provider says manages delivery to the destination.
- Statuses: where DLRs or other available statuses are generated and the path by which they are transmitted.
- Gaps: any segment, condition, or definition that has not been confirmed.
Specific questions to document the route
Ask questions that allow for bounded, recordable answers. Instead of asking only whether a route is “direct,” ask the provider to explain what that claim means, which destinations it applies to, and what changes could affect it.
The documentation should make it possible to compare proposals without demanding commercial information the provider cannot disclose. If an identity cannot be shared, ask whether the intermediary’s function, the segment it covers, and the change-notification process can be described.
- What does “direct” or “hubbing” mean in this proposal, and which segment does it describe?
- Which destinations, senders, and traffic categories does the stated topology apply to?
- Which intermediaries or functions are involved, and what information cannot be disclosed?
- Who manages termination, and who originates or forwards the available statuses?
- What usage, format, sender, or content restrictions affect the route?
- How and when are changes to the topology, scope, or conditions communicated?
- What operational data can be provided to review incidents and discrepancies?
Compare claims with evidence
Verification requires combining sources, because no single observation necessarily reconstructs the entire chain. Keep the provider’s statement and compare it with event logs, results from controlled tests, and any independent observations available to you. Define the destination, sender, message type, and comparison period in advance to avoid mixing different conditions.
Testing should be legitimate, authorized, and designed to avoid harming recipients or generating unnecessary traffic. Record the criteria and incidents; do not extrapolate the result of a limited test to other destinations, periods, or message classes.
- Retain timestamps, message identifiers, and statuses as received, subject to applicable privacy and retention obligations.
- Compare equivalent tests by destination, sender, and permitted content.
- Separate provider acceptance logs, received DLRs, and any independent checks of receipt.
- Record failures, delays, missing statuses, and configuration changes; avoid reducing everything to a single rate.
- Repeat the review when there is a material discrepancy or a reported route change.
What DLRs and tests do—and do not—prove
A DLR is a status reported within the messaging chain. Its meaning depends on how it is generated and transmitted along the specific route. Therefore, a received status should not automatically be presented as independent proof that a person saw the message or that it appeared on the expected device.
Distinguish between message acceptance by a system, a delivery status reported by the chain, and receipt independently verified on the device. These events are not interchangeable. Tests can provide useful observations under the conditions tested, but they do not, on their own, establish the complete topology or predict future behavior.
- Ask what event each status represents and which entity originates it.
- Record whether the evidence is a provider response, a DLR, or an independent observation.
- Do not describe a DLR as confirmation of reading or human receipt.
- When reporting results, state the limitations of the sample and test conditions.
Verification limits and confidentiality
A provider may not disclose intermediary names for commercial or contractual reasons. This limitation does not, by itself, prove that the claim is false, but it reduces what you can verify. In that case, request a functional description, the scope of the claim, the applicable conditions, and a clear commitment to communicate changes.
Data may also be incomplete: logs may not cover every segment, statuses may not reach the customer, or tests may cover only a subset of destinations. Document these uncertainties. If they matter to your operations, agree on what additional evidence can be shared and what review will take place when incidents occur.
- Mark each item as confirmed, provider-stated, or unavailable.
- Do not present a partially documented chain as a verified end-to-end topology.
- Agree on channels, timeframes, and owners for investigating discrepancies, subject to the contract and available capabilities.
- Protect traffic and recipient data in accordance with applicable rules.
A matrix for comparing routes without relying on labels
A shared matrix helps compare alternatives using explicit criteria. You do not need to reduce them to a single score: a route may be transparent in one respect and supported by limited evidence in another. Define which requirements are essential for your use case and which uncertainties you can accept.
Adjust the criteria to the intended legitimate use, the contracted scope, and the evidence you can actually obtain. Do not present illustrative figures or sample results as current commercial data or guarantees.
- Transparency: Is the stated topology documented, and are its limits identified?
- Scope: Are the applicable destinations, senders, and traffic types specified?
- Observed quality: What comparable logs and tests are available, and what are their limitations?
- Statuses: Are the origin and meaning of available DLRs explained?
- Capacity and conditions: What has been agreed, and what restrictions apply?
- Change management: How are modifications communicated, and how are their effects reviewed?
- Residual risk: Which points remain unconfirmed, and what impact could they have?
Frequently asked questions
Does a direct route deliver better than a route using hubbing?
You cannot conclude that from the label alone. Compare the stated scope, conditions, and operational evidence for the destination and traffic you care about. A direct route does not guarantee better delivery.
Does a DLR confirm that the message reached the phone?
Not necessarily. A DLR is a status transmitted through the chain, and its meaning depends on how it is generated. Do not automatically equate it with verified receipt on the device or with the message being read.
What should I do if the provider does not disclose its intermediaries?
Ask the provider to define the claim’s scope, describe the functions and segments involved, state what information it cannot disclose, and explain how it will notify you of changes. If it cannot be verified, record that part as unconfirmed.
How should I respond to a discrepancy without interrupting legitimate traffic?
Keep the logs, identify the affected scope and period, and share the evidence with the provider through the agreed channel. Request a review of the statuses and stated topology before taking broad measures; any traffic changes should comply with your operational and contractual obligations.
Sources consulted
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA