Outbound Message Delivery Stages

A message’s lifecycle is representative of its travel from one SMS entity (SME) to another. An SME can be a mobile device or a messaging application and is responsible for initiating or receiving an SMS message.

After a message is sent, there are three basic phases at which its progress is confirmed:

1. Gateway Acknowledgment: A Transaction GUID (Globally Unique Identifier) has been generated and the outbound message is live in the Aerialink network.
2. Carrier Acknowledgment: The outbound message has reached the carrier SMSC successfully and it is being processed for delivery to the end-user.*
3. Handset Confirmation: The carrier has sent the outbound message to the end-user handset.

* Our Platform Portal Activity Report will reflect “success” in the delivery field if we have received a Carrier Acknowledgment. A “failed” status indicates that the message did not reach the SMSC.

Activity Report Status

The Activity Report in the Aerialink Platform portal displays the status of the message within the Aerialink network. Below are the statuses displayed in the report.

Outbound (MT) Statuses

Inbound (MO) Statuses

Carrier 10DLC Status & Error Codes

AT&T and T-Mobile provide SMPP status codes for failed 10DLC transactions, available with an HTTP endpoint setup.

When a ten-digit long code number attempts to send a message toward AT&T or T-Mobile but fails, the DLR details will not provide the carrier-level status details needed to determine why a submit was unsuccessful. AT&T and T-Mobile will instead forward their carrier-level SMPP response status codes to Aerialink, and we will forward these codes to a customer-provided HTTP endpoint for consumption and processing.

Status information will help you self-serve the troubleshooting of failed message submits without having to open a ticket with Aerialink support. For instance, the following scenarios would reflect a status error code:

• Brand exceeds daily outbound message limit per T-Mobile send cap
• Campaign exceeds allowed throughput rate
• Message rejected by carrier anti-spam filter
• Long code not properly registered to approved campaignID
• Mobile end-user opted out

Setup

These status codes are delivered via an HTTP endpoint for both SMPP and HTTP-connected accounts. You may submit a request for setup through the Aerialink Help Desk Portal. In the summary description field, please include “Request for 10DLC Error Code Endpoint,” and provide your webhook endpoint URL for each applicable account. Aerialink will configure the routing to forward any SMPP status code that isn’t a success to the endpoint in a JSON schema and we will provide you wit ha list of error codes and their description.

Example JSON for an MT toward T-Mobile wherein the Brand has exceeded their daily outbound transactions:

Error code 9802 - “Quota Error Exception”

{
connectionGUID: 'xxx03e74-f3dc-11e3-94de-02f2d79344c4',
  eventGUID: 'xxx791cb-de11-4602-8ef0-7bf698d40dde',
  eventType: 'smppStatusCode',
  eventDateTime: '2022-10-12T14:50:02.411Z',
  eventMessage: {
   transactionGUID:  'xxx791cb-de11-4602-8ef0-7bf698d40dde',
    smppStatusCode: 9802,
    detail: 'Received an SMPP Status Code that was not a success.'
  }
}

Delivery Receipt

Delivery receipts or “DLR” provide details about the success or failure of an outbound message, such as:

• The ID of the MT message. This is a positive 64 bit integer used to uniquely identify an SMS message as it passes through the Gateway.
• A date, giving the time at which the delivery event occurred.
• A delivery report type code giving an overview of the delivery status of the message.
• A detailed reason code, giving further information on the reason for the delivery report.

These details are provided to Aerialink by the carrier and passed to Aerialink customers unaltered.

However, there are additional factors to consider when reviewing a DLR:

• Not all carriers return DLR. Most carriers in the U.S. and Canada return DLR.
• Carriers who do return DLR may not always do so reliably. Returning DLR is a lower priority than message delivery, so DLR are not guaranteed. International carriers have been known to change this offering on occasion. Therefore, the lack of a DLR from a carrier may not indicate an issue. DLR are great for spot checking but should not be relied on for 1:1 delivery confirmation.

DLR for Concatenated Messages

Note that in the case of concatenated messages sent via the HTTP REST API, a multi-segment message will return only return a DLR for one of the message’s segments. Which segment is awarded the DLR is not consistent. This is common for wireless providers such as Verizon, who typically return only one DLR for a concatenated message.

DLR for MMS

Aerialink does support DLR for MMS messages, but keep in mind that MMS DLR - like all DLR - are at the discretion of the carrier. Not all carriers may support DLR for MMS, even if they support DLR for SMS.

10DLC Carrier DLR

A DLR for a 10DLC message indicates the message has reached the message hub successfully and is being processed for delivery to the handset. It is not a handset DLR, and is returned prior to the application of carrier anti-spam filters. Therefore, a positive DLR may be returned for messages blocked as spam.

In addition to 10DLC DLRs, your application may consume failed delivery status code in the form of the 10DLC Delivery Hub’s SMPP Responses.

Missing DLR

If you’ve requested a DLR and have not received one, this likely indicates that the carrier never sent one to Aerialink. While DLR are never 100% guaranteed by any carrier, failure to receive a DLR may indicate that the destination carrier does not support delivery receipts.

The following list is not exhaustive and may change at any time. These are the carriers who at this time do not support DLR:

• Pinger
• Enflick
• TextNow
• TextNow Wireless
• MetroPCS
• Royal St. Comm
• Onvoy Spectrum
• NSR
• Google (Grand Central)
• BWI
• Bandwidth

Requesting DLRs

Most DLRs must be requested at the time that your outbound (MT) message is submitted via API or the Send a Message function of the Aerialink Platform portal. The DLR will then be delivered in the form of an inbound (MO) message to the URL that you specify in your account configuration (and are also visible via the Activity Report in the Aerialink Platform).

If the request type is “solicited,” a request must be submitted to receive DLR. If “unsolicited,” DLR is returned automatically.

* Short Code MMS DLR not supported by Canadian carriers

DLR Fields Returned

Please note that the codes are separated by code type on the “sheet” (or tab) level within the spreadsheet. Ensure that you direct your attention to the appropriate tab when searching for the code.

TLV DLRs

Most major carriers will return the value of DLRs in the Message Text field as an inbound message. However, some carriers - most notably U.S. Cellular - return the DLR information in another way. U.S. Cellular returns their DLR data in the TLV tag, directly after the tag number 0x0427. Below are the possible TLV DLR values provided by U.S. Cellular.

Delivery Receipt Response Codes

For a breakdown of carrier-returned DLR error codes please see our DLR Response Codes Masterlist v.20240717.

Carrier Delivery Trace

Should there be a delivery-related concern, Aerialink can perform a manual trace to a carrier network requesting confirmation of the message’s end destination. Depending on carrier, this step can take anywhere from two to ten days.

Numbers API Lookup

The Aerialink Numbers API lookup is a query service which provides telephone number information useful for troubleshooting delivery issues. Some of the information provided includes:

• landline or mobile status
• number validity
• mobile carrier
• country

Aerialink customers concerned that messages are not reaching their destinations or are not doing so in a timely manner should initiate a support request. Aerialink can run special traces to a carrier via our connections to verify the message’s end location.

Device Information Detection

There are some creative ways to detect the phone type and model. Please inquire with an Aerialink Engineer who can explain how a small amount of coding on your side can provide you with some of this value added data.

Retry Period

If an SMS message cannot be delivered to its destination immediately for any reason, the carrier SMSC will invoke a retry procedure with which they may continue to attempt delivery over a period of time before the message is considered to have failed. If the recipient device is powered off, for example, the message will be kept in an operator’s retry scheme for the duration of their retry period (24, 48 or occasionally 72 hours depending on SMSC), after which point the message will expire.

Store and Forward

SMS is a store-and-forward technology, which means that when a message is sent, it is first stored in an SMSC before being forwarded to its end destination. This means that if the destination handset is unable to receive the message immediately, the message can be forwarded to its recipient at a later point in time.

Because of the nature of store-and-forward technology, the likelihood that a message can be completely lost is very minimal. In the instance that a message is dropped, there are usually internal notifications which are triggered so that action can be taken.