SMS Troubleshooting troubleshooting-sms

The problem appeared on one or several accounts

In this case, you can apply other troubleshooting procedures on each account individually. It is best to disable other accounts while diagnosing an account to reduce network traffic and the number of logs.

The problem did not appear when only one account is active at any time

You have a conflict between accounts. As mentioned before, Adobe Campaign treats accounts individually, but the provider may treat them as a single account.

• You are using different login/password combinations between all your accounts.
  You will have to contact the provider to diagnose potential conflicts on their side.

• Some of the external accounts share the same login/password combination.
  The provider has no way to tell from which external account the BIND PDU is coming from, so they treat all connections from the multiple accounts as a single one. They might have routed MO and SR randomly over the two accounts, causing issues.
  If the provider supports multiple short codes for the same login/password combination, you will have to ask them where to put that short code in the BIND PDU. Note that this piece of information has to be put inside the BIND PDU, and not in SUBMIT_SM, since the BIND PDU is the only place that will allow routing MOs correctly.
  See the Information in each kind of PDU section above to know which field is available in the BIND PDU, usually you add the short code in address_range, but that requires special support from the provider. Contact them to know how they expect to route multiple short codes independently.
  Adobe Campaign supports handling multiple short codes on the same external account.

Investigate whether connector has been changed recently and by whom (check External Accounts as a group).

select saccount, (sserver ||':'||sport) as serverPort, iextaccountid, CASE WHEN N0.iactive=1 THEN 'Yes' ELSE 'No' END as "(x) Enabled",

(select X1.sname from xtkoperator X1 where N0.icreatedbyid = X1.ioperatorid) as "Created By",

(select X1.sname from xtkoperator X1 where N0.imodifiedbyid = X1.ioperatorid) as "Last Modified By",

N0.slabel as "External Account", N0.tslastmodified as "LastModifiedDate"

from nmsextaccount N0 LEFT JOIN xtkoperator X0 ON (N0.icreatedbyid=X0.ioperatorid) order by 8 DESC LIMIT 50;

Investigate (in /postupgrade directory) whether system was upgraded and when

Investigate whether any packages affecting SMS might have been upgraded recently (https://experienceleague.adobe.com/var/log/dpkg.log?lang=en).

If the problem happens on a mid-sourcing environment, make sure that the delivery and broad logs are properly created and updated on the mid-sourcing server. If that’s not the case, this is not an SMS issue.

If everything works on the mid server and SMS are properly sent, but the marketing instance is not properly updated, you might have a mid-synchronization issue.

If the BIND PDU returns a non-zero command_status code, ask the provider for more information.

Check that the network is properly configured so the TCP connection can be made to the provider.

Ask the provider to check that they properly added the IPs to the allowlist of the Adobe Campaign instance.

Check External account settings. Ask the provider the value of the fields.

If the connection is successful but unstable, check the Issue with unstable connections section.

If connection issues are difficult to diagnose, a network capture can provide information. Make sure that the network capture runs simultaneously while the problem appears for it can be analyzed efficiently. You should also note the exact time at which the problem appears.

The connection lasts for less than 1 hour. Adobe Campaign Classic transmitter connections are an exception due to the way the Adobe Campaign Classic MTA works.

The provider sends UNBIND PDUs.

enquire_link times out, either on the Adobe Campaign side or on the provider side. You might see ENQUIRE_LINK_RESP with a non-zero error code in that case.

There are a lot of BIND PDUs. There should not be more than a few during a day, depending on the number of connections. More than 1 BIND PDU per hour should be alerting.

Unstable connections are rarely the root cause, it’s often the result of another problem triggering a disconnect. Finding the root cause is the priority.

Enable verbose SMPP traces. You will need them to see what is happening when the connection restarts.

If the provider sends BIND PDUs, something might be wrong. Ask your provider why UNBING is sent.

Taking a network capture is sometimes the only way to see how the connection is closed.

If the provider closes the connections by sending either a TCP FIN or a TCP RST packet, ask your provider more information.

If the provider closes the connection after sending a clean error such as DELIVER_SM_RESP with an error code, they must fix their connector otherwise that will prevent other kinds of messages from being transmitted and will trigger MTA throttling. This is especially important in transceiver mode where closing the connection impacts both MT and SR.

Check that the connection is stable. An SMPP connection should stay up for at least 1 hour continuously except for transmitters on Adobe Campaign Classic. See the section Issue with unstable connections.

If restarting the MTA makes sending MT working again for a small period of time, you probably have throttling due to an unstable connection. See the section Issue with unstable connections.

Check that the broad log is present and in the correct status with the correct dates. If it’s not, this might be a delivery or delivery preparation issue.

Check that the MTA actually processes the message. If it’s not the case, this might not be a SMS issue.

Check that the SMS connector is actually bound with the provider’s equipment. Ask the provider for feedback to make sure all systems are communicating properly. See BIND_TRANSMITTER and BIND_TRANSCEIVER PDUs for information about the bind process. You may need to enable SMPP traces for proper troubleshooting.

With the SMPP traces enabled, check that the SUBMIT_SM PDU is containing the right information.

Check that the provider responds with a SUBMIT_SM_RESP PDU with a “OK” value (code 0). Make sure that the PDU arrives with a reasonable delay: anything longer than 1 second must be discussed with the provider, it usually arrives in less than 100ms.

If all these steps work, you can be confident that the problem is on the provider side. They will have to do the troubleshooting on their platform.

If it works but throughput is inconsistent, try adjusting the sending window and lowering the MT throughput. You will need to work with the provider to adjust that. Adobe Campaign can send messages very quickly so performance problems may arise on the provider’s equipment.

If you see duplicates sent exactly 60 seconds apart, it’s probably a problem on the provider side, they don’t send a SUBMIT_SM_RESP quickly enough.

If you see many BIND/UNBIND, you have an unstable connection. See theIssue with unstable connections section for solutions before attempting to solve duplicate messages issues.

You will need SMPP traces enabled to do any kind of SR troubleshooting.

Check that the DELIVER_SM PDU is coming from the provider and that it is well formed.

Check that Adobe Campaign replies with a successful DELIVER_SM_RESP PDU in a timely manner. On Adobe Campaign Classic, this guarantees that the SR has been inserted into the providerMsgId table for deferred processing by the SMS process.

Check regex related to id extraction and error processing in the External account. You may need to validate them against the content of the DELIVER_SM PDU.

Check that errors are properly provisioned in the broadLogMsg table.

Enable SMPP traces during tests. If you don’t enable TLS, you should do a network capture when troubleshooting MO to check that PDUs contain the correct information and are properly formatted.

When capturing network traffic or analyzing SMPP traces, be sure to capture the whole conversation with the MO and its reply MT if a reply is configured.

If the MO (DELIVER_SM PDU) doesn’t appear in the traces, the problem is on the provider side. They will have to do troubleshooting on their platform.

If the DELIVER_SM PDU appears, check that it’s acknowledged by Adobe Campaign with a successful DELIVER_SM_RESP PDU (code 0). This RESP guarantees that all the processing logic has been applied by Adobe Campaign (auto reply and allow/denylist). If it’s not the case, search for an error message in the SMS process logs.

If automatic replies are enabled, check that the SUBMIT_SM has been sent to the provider. If not, it’s guaranteed to find an error message in the SMS process logs.

If the SUBMIT_SM MT PDU containing the reply is found in the traces but the SMS does not arrive to the mobile phone, you will have to contact the provider for assistance on troubleshooting.

Check that the phone number format is exactly the same in the quarantine table and in the delivery log. If it’s not, refer to this section if you are having issues with the plus prefix of the international phone number format.

Check short codes. Exclusions can happen if the short code of the recipient is either the same as defined in the external account or if it’s empty (empty = any shortcode). If only one short code is used for the whole Adobe Campaign instance, it’s easier to leave all short code fields empty.

Enable verbose SMPP messages when the problem appears. Most SMS problems are impossible to solve without this.

If the problem is related to SMS traffic, contact the provider first. Their platform is best suited for efficient diagnosis of SMS traffic problems in real time.

Include a brief but factual description of the problem.

Include a description of the expected result.

Include the feedback from the provider.

Include relevant logs and/or network captures. When doing captures, make sure to reproduce the problem during the capture.

If you include logs, traces or captures, pinpoint the exact location in the file when the problem appears.

If you reference messages, PDUs or logs, clearly state their timestamp to make them easier to find.

Try to reproduce the problem on a test environment. If you are unsure about a setting, try it on the test environment and check the result with the SMPP traces. It’s usually better to report problems replicated on test environments than directly reporting problems on production environments.

Include any change or tweaks made on the platform. Also, include any change that the provider may have done on their side.

Connection issues, but the verbose messages don’t show any BIND_RESP PDU.

Unexplained disconnections with no error message, the usual behavior of the connector when it detects a low-level protocol error.

The provider complains about the unbind/disconnection process.

Encoding issues in optional TLV fields.

Traffic is suspected to be mixed between different connections.

TLS enabled: By definition, TLS traffic is encrypted so it cannot be captured.

Performance issues: Logs contain all the needed information to trace performance issues.

Timing issues (retry timing, enquire_link period, throughput capping,etc.)

SR parsing and processing: verbose logs give much more context and a better presentation.

MO processing (automatic replies, quarantine).

Errors not involving actual SMPP traffic: Delivery preparation, Message Center API issues, workflow issues, etc.

Received on Mobile:
The message has been successfully delivered to the user’s device, with confirmation provided by both the Mobile Terminated (MT) delivery and a Status Report (SR).

Sent:
The message was successfully processed through the Mobile Terminated (MT) step, but a Status Report (SR) confirming delivery to the mobile device has not yet been received.

Sent to the Provider:
The message was sent to the provider using the SUBMIT_SM command, but no SUBMIT_SM_RESP acknowledgment was received from the provider.

Pending: The message has not yet been sent to the aggregator.

Taken into Account by Provider: The message has been sent to the aggregator, and the aggregator has confirmed receipt.

Sent: The aggregator has confirmed that the message has been successfully pushed to the user’s mobile network without any immediate error.

Received on Mobile: The user’s mobile device has acknowledged receipt, and this has been verified by the aggregator.

Failed: The message was sent to the aggregator, which attempted delivery to the user’s mobile device for a defined period (e.g., several hours). Delivery ultimately failed due to network issues, user device unavailability, or other reasons.