This document explains the SMS protocol and how the external account settings impact the protocol or the behavior of the connector.

Through this document, all references to details about the protocol, field names and values refer to the SMPP 3.4 specification.

The document applies to Adobe Campaign Standard and Adobe Campaign Classic (Extended generic SMPP) unless specified otherwise. If an option is also available on the old v6 connector (Generic SMPP), it is indicated how it behaves.

When this document states Adobe Campaign Classic, it also means Campaign v6 and v7 since these versions work the same for SMS.

Description of the SMPP protocol

Both Adobe Campaign Classic and Standard support the SMPP protocol version 3.4. This is a widespread protocol that allows sending SMS to a provider (SMSC) and receiving SMS as well as receipts.

Three kinds of SMS

When sending mass SMS through an SMS provider, you will encounter three different kinds of SMS:

  • SMS MT (Mobile Terminated): an SMS that is emitted by Campaign towards mobile phones.
  • SMS MO (Mobile Originated): an SMS that is sent by a mobile to Campaign.
  • SMS SR (Status Report) or DR or DLR (Delivery Receipt): a return receipt sent by the mobile to Campaign indicating that the SMS has been received successfully. Campaign may also receive SR indicating that the message could not be delivered, often with a description of the error.

Please distinguish between acknowledgments and SR: a SR is a kind of SMS that is sent through the network end-to-end, whereas an acknowledgement is only a confirmation that one transfer has been successful.

Both acknowledgements and SR can trigger errors, distinguishing between the two will help troubleshooting.

Information carried by an SMS

An SMS carries more information than text. Here a list of what you can expect to find in an SMS:

  • The text, which is limited to 140 bytes, which means between 70 and 160 characters depending on the encoding. See SMS text encoding below for details and limitations.
  • A recipient address, sometimes called ADC or MSISDN. That's the number of the mobile that will receive the SMS.
  • A sender address, that can be called oADC or sometimes sender id. That can be a phone number (in day to day use), a short code (when sent through a provider) or a name (this is an optional feature, in that case you cannot reply to the SMS).
  • A flag to indicate if the message is a flash message. A flash message is a pop-up that is not stored in memory.
  • A flag to indicate whether a SR is expected or not.
  • A validity date, after which no network equipment is allowed to retry (not always present or respected).
  • A data_coding field, which indicates the encoding of the text.

Network aspect of the SMPP protocol

The SMPP protocol establishes permanent TCP connections from Campaign to the SMSC. TCP connections are always initiated by Campaign, even to receive messages.

SMPP opens 1 or 2 TCP connections, depending on its mode. All connections are always initiated by Campaign.

The SMPP protocol can work in two modes:

  • Transmitter+receiver (often abbreviated TX+RX): two separate TCP connections are used for transmitting and receiving messages.
  • Transceiver (abbreviated TRX): a single TCP connection is used for transmitting and receiving messages.


Adobe Campaign Classic (both the old and the extended SMPP connector) and earlier versions of Campaign only support the separated TX+RX mode. This limitation is due to the technical architecture.

The SMPP protocol description is applicable for all versions of Campaign since this is a standard protocol.

SMPP transmission units ("packets") are called PDUs: a PDU contains a command, a status, a sequence number and data.

Each PDU must be acknowledged by an SMPP RESP PDU (synchronous response). Requests may be pipelined: the sender can send many commands without waiting for RESP, the number of requests that may be pipelined at any time is called the window. RESP PDU may arrive in any order, unrelated to the order of their corresponding initiator PDU.

In the separated transmitter+receiver mode, the connection used depends on the kind of message transmitted. The transmitter connection is used for MT, and the receiver connection is used for MO and SR. Requests and responses for each kind of message are sent over the same TCP connection.

For example, when sending an MT, the transmitter connection is used and the RESP that acknowledges the MT is also sent through the transmitter channel. When you receive an MO (or an SR), the receiver connection is used to receive the MO and to send the RESP that acknowledges the MO.


In Adobe Campaign Classic, to link SR with their corresponding MT, an ID is returned by the SMSC with the SUBMIT_SM_RESP and DELIVER_SM steps. The identifier is stored in the providerId field of the nms::providerMsgId table and this is linked to broadLogId and deliveryId. This matching operation is done by the SMS process when writing to the database.

In Adobe Campaign Standard, MT↔SR reconciliation is native to the MTA, so there is no dedicated SMS process.

Security aspects

The only widespread authentication mechanism is the login/password fields passed during the bind phase.

The protocol itself is not encrypted. IP whitelisting, VPN and IPsec are the most used security measures. This is typically handled by the hosting service or external network components.

Adobe Campaign Standard and Adobe Classic now support SMPP over TLS. Its TLS implementation is not 100% conformant due to limitations in the underlying framework, but for most providers this doesn't matter (the provider may encounter a warning when the connection is closed). It should be noted that certificates are required for proper security: while the SMPP connector allows bypassing certificate checks, it should only be used for testing because TLS without certificates does not provide any security at all.

Information in each kind of PDU

Each kind of PDU has distinct fields that carry different pieces of information. These PDU are detailed in the SMPP 3.4 specification, but this document gives an overview of useful fields of most used PDUs.

Each section below describes both the PDU and its synchronous response (*_RESP PDU). All PDUs must be acknowledged by a corresponding RESP, this is a mandatory part of the specification.

PDUs can have optional fields. Only the most common fields are described here. Refer to the SMPP specification and the documentation of the provider for more extensive information.


This PDU is used to initiate a connection to the SMSC. Transmitter, Receiver and Transceiver modes only change the kind of SMS allowed to be transferred over this connection, specifically:

Mode Kinds of SMS allowed
Transmitter MT
Receiver MO + ST
Transceiver MT + MO + SR

Notable fields in a BIND_* PDU:

  • system_id: Login used for authentication. Set in the external account, available in all versions.
  • password: Password used for authentication. Set in the external account, available in all versions.
  • system_type: Required to be set at a specific value for some providers. Set in the external account, available in all versions. Often distinguishes between different types of contracts / channels / countries / ...
  • addr_ton and addr_npi: Required by some providers. Set by the "Bind TON" and "Bind NPI" settings in the external account (Adobe Campaign Classic Extended SMPP and Adobe Campaign Standard only).
  • address_range: Required by some providers. Its meaning can vary. Most of the time, this is a list of shortcodes allowed on this connection. Set in the external account (Adobe Campaign Classic Extended SMPP and Adobe Campaign Standard only).

BIND_*_RESP has no specific field, it confirms whether the connection was successful or not.


This PDU must be sent by the system before disconnecting. It must wait the matching UNBIND_RESP PDU before closing the connection.

Conforming SMSC must not close the connection, the TCP connection is controlled by the Campaign connector.


This PDU sends a MT to the SMSC. Its response PDU gives the ID of the MT.

Notable fields in a SUBMIT_SM PDU:

  • service_type: Required by some providers, its meaning can vary. Set in the delivery properties (all versions).
  • source_addr_ton and source_addr_npi: indicates what kind of source address is transmitted. The meaning of these fields is standardized, but since some providers use it differently, you should ask the provider for its correct value. Set in the external account (all versions).
  • source_addr: The source address / oADC of the MT. Will be displayed on the mobile phone. Set in the external account and the delivery, the value in the delivery takes precedence over the value of the external account (all versions).
  • dest_addr_ton and dest_addr_npi: indicates what kind of destination address is transmitted (e.g. local or international format). The meaning of these fields is standardized, but since some providers use it differently, you should ask the provider for its correct value. Set in the external account (all versions).
  • destination_addr: The recipient address (its phone number or MSISDN).
  • esm_class: Used to tell if UDH is used or not in the text field. Enabled automatically by the connector for split SMS if the message_payload mode is not used. Available in all versions.
  • priority_flag: Priority of this message over others. This is tied to the priority of the delivery itself in Campaign (all versions).
  • validity_period: Timestamp after which no retry should be attempted. Set in the delivery in Campaign (all versions).
  • registered_delivery: Tells whether a SR is requested or not. Campaign always sets this flag except for automatic replies. For multipart messages, the flag is only set for the first part. All versions have the same behavior.
  • data_coding: Indicates the encoding used in the text field. See SMS text encoding section in this document for more information (varies depending on the version).
  • short_message: The text of the message. If UDH is used, this also contains the header.

Campaign supports these optional fields:

  • dest_addr_subunit: Used to specify the target of the SMS: flash, mobile or SIM card. Set in the delivery properties (all versions).
  • message_payload: When enabled in the external account, long messages will be sent in a single PDU and the text will be transmitted in this field rather than the short_message field (Adobe Campaign Classic Extended SMPP and Adobe Campaign Standard only).


This PDU will contain the ID of the MT. This is useful to match it with incoming SR.


Many providers transmit the MT ID in hexadecimal. Make sure that you set the "ID format in MT acknowledgement" setting correctly in the external account.


This PDU is sent by the SMSC to Campaign. It contains either a MO or a SR.

Most fields have the same meaning as their SUBMIT_SM counterpart. Here is the list of useful fields:

  • source_addr: The source address of the MO/SR. Usually this is a phone number.
  • destination_addr: The short code that received the MO or the SR.
  • esm_class: Used to tell if the PDU is a MO or a SR.
  • short_message: The text of the message. For SR, this contains data described in the Appendix B of the SMPP protocol specification. See SMPP error management: Appendix B for more details.

Campaign is able to read message ID in the receipted_message_id optional field with some configuration tuning (Adobe Campaign Classic Extended SMPP and Adobe Campaign Standard only).


This PDU does not carry any significant information besides acknowledging or not SR and MO.

This PDU is only used to check that the connection is live. Its frequency should be set according to the provider's needs.

The default 60 seconds should match most configurations set in the external account in the backport and the Adobe Campaign Standard connector. The old v6 connector is configured in serverConf and defaults to 25 seconds.


This PDU acknowledges that the connection is live.

Multipart SMS (long SMS)

Multipart SMS, or long SMS, are SMS that are sent in multiple parts. Due to technical limitations in the mobile network protocol, a SMS cannot be larger than 140 bytes or it will need to be split. See the SMS text encoding section below to learn more on the number of characters that can fit in a SMS.

Each part of a long message is an individual SMS. These parts travel independently on the network and are assembled by the receiving mobile phone. To handle retries and connectivity problems, Adobe Campaign sends these parts in reverse order and requests a SR only on the first part of the message, the last sent. Since the mobile phone only displays a message when its first part is received, retries on additional parts won't produce duplicates on the mobile phone.

There are 2 ways to send long SMS:

  • UDH: the default and recommended way to send long messages. This protocol is the one used by mobile phones themselves. This means that Adobe Campaign has the most control over the message generation, making it capable to compute exactly how many parts were sent and how they were split.
  • message_payload: the way to send the whole long message in a single SUBMIT_SM PDU. The provider will have to split it, which means that it is impossible for Adobe Campaign to know exactly how many parts have been sent. Some providers require this mode, we advise you to only use it if they don't support UDH.

See the description of the esm_classshort_message and message_payload fields of the SUBMIT_SM PDU above for more details about the protocol and formats.

SMPP external account parameters

Each implementation of the SMPP protocol has many variations. To improve compatibility and adaptability, many settings are available to change the behavior of the SMPP connector. This section describes every parameter and its effects on the connector.


General parameters and routing

Limit MTA instances for this account

Since 19.2 it is possible to set a limit to the number of MTA instances allowed to connect to the SMPP provider. When checked, you can specify how many MTAs can be used at most.

This option allows finer control over the number of connections (see Simultaneous connections below).

If you set a value higher than the number of running MTAs, all MTAs will run as normal: this option is only a limit and cannot spawn additional MTAs.

Connection settings

SMPP connection mode

Set the connection in transceiver mode or in separated transmitter+receiver mode. When you switch to separated transmitter+receiver mode, settings in the SMPP connection mode section apply to the transmitter and settings in the Receiver connection settings section apply to the receiver connection (only if you checked the Use different parameters for the receiver checkbox).

Applies only to Adobe Campaign Standard. Both Adobe Campaign Classic connectors only support separated transmitter+receiver due to architectural limitations.

SMSC implementation name

Sets the name of the SMSC implementation. It should be set to the name of your provider. Contact the administrator or the deliverability team to know what to put in this field. The role of this field is described in the SMPP error management section below.

Applies to Adobe Campaign Classic Extended SMPP and Adobe Campaign Standard.


The DNS name or IP address of the server to connect to.

In the old v6 connector you can add a comma-separated list of IPs to connect to multiple servers in parallel.

Adobe Campaign Standard and the v6 backport only allows one address. This may be subject to change in the future.


The TCP port to connect to.

Applicable to all versions.


The login of the connection. Passed in the system_id field of the BIND PDU.

Applicable to all versions.


Password of the SMPP connection. Passed in the password field of the BIND PDU.

Applicable to all versions.

System type

Value passed in the system_type field of the BIND PDU. Some providers need a specific value here.

Applicable to all versions.

Simultaneous connections

Number of connections per SMS thread and per MTA process.


The Adobe Campaign Classic Generic SMPP connector does not control the number of simultaneous connections. Connections are created depending on many uncontrollable parameters.

The number of MTA process is determined by the TechOps deployment (usually there are 2 MTAs and 1 thread). The number of threads can be changed in the config-instance.xml file.

The Adobe Campaign Classic Extended SMPP connector can control the number of connections per MTA child. To control the global limit of connections, you will have to limit the number of MTA child processes, which often means having a dedicated mid-sourcing platform for SMS.

Total connections formula for Adobe Campaign Standard:

  • Total connections = Simultaneous connections * number of threads * number of MTAs

Simultaneous connections is set in the external account, number of threads is set in the config-instance.xml file and number of MTAs can be limited in the external account since Adobe Campaign Standard 19.2.

Total connections formula for the Adobe Campaign Classic Extended SMPP connector:

  • Total connections = Simultaneous connections * number of MTA child processes * number of MTAs

In Adobe Campaign Classic, the SMS process also opens connections. It spawns only one process/one thread. Since you can only have one SMS process per instance, it means that the Simultaneous connections setting is directly the number of connections opened by the SMS process.


If you set up automatic replies, the SMS process will open transmitter/receiver pairs, increasing the number of transmitter connections, but if you did not set up any automatic reply, it will open only receiver connections.


Enable TLS over SMPP

Use TLS to connect to the provider. The connection will be encrypted.

Only available in Adobe Campaign Standard since 18.6 and Adobe Campaign Classic since 19.1.

Enable verbose SMPP traces in the log file

This setting dumps all SMPP traffic in log files. It's often required to adjust parameters during initial setup. This must be enabled when troubleshooting the connector and compared to the traffic seen by the provider.

In Adobe Campaign Classic, log output is in the MTA log for MT-related traffic and in the SMS log for MO and SR-related traffic.

Receiver connection setting

This section is only visible in separated transmitter+receiver mode (see above). Available only in the Adobe Campaign Classic Extended SMPP connector and the Adobe Campaign Standard connector.

Use different parameters for the receiver

When the box is unchecked, the same settings are used for transmitter and receiver.

When the box is checked, settings in the Connection settings section will apply to the transmitter and settings in the Receiver connection settings will apply to the receiver.

Receiver server, port, account, password, system type

These settings apply to the receiver when in transmitter+receiver mode. They work like the transmitter part, see above for more details.

SMPP channel settings

Authorize character transliteration

Transliteration is the process of finding equivalent characters to missing ones. For example, the French "ê" (e with circumflex accent) character is missing from GSM encoding, but it can be replaced by "e" without impairing readability too much.

When this box is unchecked, text encoding will fail if it cannot encode the string exactly as-is.

When this box is checked, text encoding will try to convert the string to an approximate version instead of failing.

See the Define a specific mapping of encodings setting for a more general explanation of the encoding process.

Available for the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

The Adobe Campaign Classic Generic SMPP connector always provides character transliteration.

Store incoming MO in the database

When enabled, incoming MO will be stored in the inSMS table of the database. This table can be queried using the query activity of any workflow.

Available in Adobe Campaign Standard since version 18.1.

Adobe Campaign Classic always stores all MOs in the inSMS database so this option is not available.

Enable Real-time KPI updates during SR processing

When enabled, KPIs will be updated in real-time on the main delivery page when receiving error SR.

The drawback can be low performance because of the database contention it generates. If disabled, statistics are updated by the syncfromexec workflow, normally running every 20 minutes.

Available in Adobe Campaign Standard since version 18.2.

Adobe Campaign Classic has an entirely different mechanism for KPIs so this option is not available.

Source number

Defines the default source address for messages. This setting only applies if the source number has been left empty in the delivery.

By default, the source number field is not passed, so the provider will substitute it for the short code.

This enables the sender address / oADC override feature.

Applicable to all versions.

Short code

Indicates the main short code of the account. If multiple short codes are used for this account or if the short code is unknown, leave this field empty.

Specifying short code is helpful for 2 features:

  • The preview will display the short code if no source number is provided. It will reflect the real behavior on the mobile phone.
  • The additional action setting of the auto reply feature (described below) only sends to quarantine the user for a specific short code. This is to respect current laws in USA and France for which this feature has been developed.

Available only for the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

Source TON/NPI, Destination TON/NPI

TON (Type Of Number) and NPI (Numbering Plan Indicator) are described in section 5.2.5 of the SMPP 3.4 specification. These values should be set to the provider's needs.

They are transmitted as-is in source_addr_tonsource_addr_npidest_addr_ton and dest_addr_npi fields of the SUBMIT_SM PDU.

Applicable to all versions.

Service type

This field is transmitted as-is in the service_type field of the SUBMIT_SM PDU. Set this to the provider's needs.

Applicable to all versions.

Throughput and timeouts

These settings control all the timing aspects of the SMPP channel. Some providers require very precise control of the message rate, window and retry timings. These settings should be set to values that match the capacity of the provider and the conditions indicated in their contract.

Settings in this section are not applicable to the Adobe Campaign Classic Generic SMPP connector. It is always sent quickly.

Sending window

The window is the number of SUBMIT_SM PDUs that can be sent without waiting for a matching SUBMIT_SM_RESP.

Example of a transmission with a maximum window of 4:


The window helps increasing throughput when the network link has a high latency.

If the window is too big, you may send more duplicate messages in case of connection problems (rare case). Also, most providers have a very strict limit for the window and refuse messages that go over the limit.

Applicable to the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard. The old Adobe Campaign Classic Generic SMPP connector does not control its window.

Max MT throughput

Maximum number of MT per second and per connection. This setting is strictly enforced, the MTA will never push messages faster than this limit. It is useful for providers that require precise throttling.

To know the total throughput limit, multiply this number by the total number of connections (see the formula above).

0 means no limit, the MTA will send MT as fast as possible.

Applicable to the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard. The old Adobe Campaign Classic Generic SMPP connector does not control its throughput.

Time before reconnection

When the TCP connection is lost, the connector will wait this number of seconds before trying to make a connection.

Applicable to the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

Expiration period of the MT

This is the timeout between SUBMIT_SM and its matching SUBMIT_SM_RESP. If the RESP is not received on time, the message will be considered as failed and global retry policy of the MTA will apply.

Applicable to the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

Bind timeout

Timeout between the TCP connect attempt and the BIND_*_RESP reply. When it times out, the connection is closed by the Campaign connector and it will wait Time before reconnection before trying again.

Applicable to the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

enquire_link period

enquire_link is a special kind of PDU sent to keep the connection alive. This period is in seconds. The campaign connector only sends enquire_link when the connection is idle in order to conserve bandwidth. If no RESP is received after twice this period, the connection will be considered dead and a reconnection process will be triggered.

Applicable to the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

The old Adobe Campaign Classic Generic SMPP connector can be configured by a setting in the serverConf file.

SMSC specifics

These settings are advanced settings that enable to adapt the Campaign connector to most SMPP implementation peculiarities.

Define a specific mapping of encodings

Please see the SMS text encoding section below for details about text encoding.

This setting allows you to define a custom encoding mapping, different from the specification. You will be able to declare a list of encodings, along with their data_coding value.

The MTA will try to encode using the first encoding in the list; if it fails, it will try to use the next encoding on the list, etc... If no encoding can be used to encode the message, an error will happen. Once the encoding is found, the MTA will create the SUBMIT_SM PDU with the encoded text and the data_coding field set with the value specified in the table.

The order of items in the table is important: encodings are tries from top to bottom. You should put the cheapest or most recommended encoding at the top of the list, then followed by more and more expensive (or less desirable) encodings.

Please note that UCS-2 will never fail as it can encode all characters supported in Campaign and that the maximum length of an UCS-2 SMS is much smaller (70 characters only).

You can also use this setting to force a specific encoding to be always used by declaring only 1 line in the mapping table.

The default mapping used when the checkbox is not checked is equivalent to the following table:

data_coding Encoding
9 UCS-2

This means that the MTA will try to encode the message in GSM. If it succeeds it will send it with data_coding set to 0.

If the message cannot be encoded in GSM, it will be encoded in UCS-2 and will set data_coding to 8.

This dynamic mapping is only available in the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

The old Adobe Campaign Classic Generic SMPP connector uses a fixed mapping:

data_coding Encoding
3 ISO-8859-1
6 ISO-8859-5
7 ISO-8859-8
8 UTF-16BE

Enable message_payload

When unchecked, long SMS will be split by the MTA and sent in multiple SUBMIT_SM PDUs with UDH. The message will be recomposed by the mobile phone following UDH data.

When checked, long SMS will be sent in one SUBMIT_SM PDU, putting the text in the message_payload optional field (see the SMPP specification for details about this).

If this feature is enabled, Campaign will be unable to count SMS parts individually: all messages will be counted as sent in one part.

Only selectable in the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

The old v6 connector uses both methods depending on the provider. The old "Generic SMPP" setting uses UDH (no message_payload).

Send the full phone number

When this checkbox is not checked, only digits of the phone number are sent to the provider (destination_addr field of the SUBMIT_SM field). This is the default behavior since the international number indicator (usually a + prefix) is replaced by TON and NPI fields in SMPP.

When the checkbox is checked, the phone number is sent as-is, with no preprocessing (and potential spaces, + prefix or pound/hash/star signs).

Applicable to the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

The old Adobe Campaign Classic Generic SMPP connector removes the prefix and spaces automatically.

Skip TLS certificate check

When TLS is enabled, skip all certificate checks. When checked, the connection is not secure anymore, so it must not be enabled in production.

It may be useful for debugging or test purposes.


TON (Type Of Number) and NPI (Numbering Plan Indicator) (described in section 5.2.5 of the SMPP 3.4 specification). These values should be set to whatever the provider needs.

They are transmitted as-is in addr_ton and addr_npi fields of the BIND PDU.

Only available in the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

Address range

Sent as-is in the address_range field of the BIND PDU. This value should be set to whatever the provider needs.

Only available in the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

Extraction regex of the ID in the SR

SR format is not strictly enforced by the SMPP protocol specification. It is only a recommendation described in Appendix B of the specification. Because of this, some SMPP implementers format this field differently, so Campaign needs a way to extract the correct field.

By default, it captures up to 10 alphanumeric characters after "id:".

The regex must have exactly one capture parenthesis. The regex format is PCRE.

Only available in the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

Regex applied to determine successful/error status

When messages with an unknown stat/err field combination are encountered, these regexes are applied on the stat field to determine whether the SR was a success or an error. SR with stat values that don't match any of these regexes are ignored.

By default, stat values that begin with DELIV (e.g. DELIVRD in the Appendix B) will be considered as successfully delivered and all stat values that match errors (e.g. REJECTED, UNDELIV, ...) are considered errors.

Only available in the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

ID format in MT acknowledgement

This indicates the format of the ID returned in the message_id field of the SUBMIT_SM_RESP PDU.

  • Do not modify: The ID is stored as-is in the database, as ASCII-encoded text. No pre-processing nor filtering occurs.
  • Decimal number: The ID is expected to be a decimal number in ASCII form. Leading and trailing spaces and leading zeroes are removed when this setting is used.
  • Hexadecimal number: The ID is expected to be a hexadecimal number in ASCII form, with no leading 0x nor trailing h. The ID is then converted to a decimal number before being stored in the database.
  • Hexadecimal string: The ID is expected to be an ASCII-encoded text that is itself a string of bytes encoded as hexadecimal. For example, in the PDU you will find 0x34 0x31 0x34 0x32 0x34 0x33, which translates to ASCII "414243"; then this string is decoded as a hexadecimal string of bytes, and you obtain "ABC" as a result: you will store the ID "ABC" in the database.

Only available in the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

ID format in SR

This indicates the format of the ID captured by the Extraction regex of the ID in the SR. Values have the same meaning and the same behavior as the format in MT above.

Only available in the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

SR ID or error code in optional field

If checked, the content of optional fields will be appended to the text processed by regexes above. The text will have the format "0xTAG:VALUE", 0xTAG being the 4-digit hexadecimal value of the tag in upper case (e.g. 0x002E).

For example, you might want to capture the ID in the receipted_message_id field. For this, enable this checkbox and the following text will be added to the status:


In this example, 0x001E is the tag of the optional field and the UUID is the value of the field.

In order to capture this value, you may now set the following regex in the Extraction regex of the ID in the SR field:



You can only capture optional fields that have text (ASCII/UTF-8) values. Specifically, binary fields cannot be captured reliably with the current regex system.

Only available in the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

SR ID or error code in text field

If checked, the Text: field will be kept during processing of the status text of the SR.

This is useful if the provider places important data in this field like the ID or the status. Usually this field can be safely discarded since it may contain text with a non-ASCII encoding and disrupt regex processing.

Only available in the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

Service ID tag

Allows to add a custom TLV. This field sets the tag portion. The value can be customized per delivery in the "Service or program ID" value in the advanced parameters of the delivery.

This setting only allows adding one TLV option per message.

Only available in the Adobe Campaign Classic Extended SMPP connector and Adobe Campaign Standard.

Automatic reply sent to the MO

This feature allows to quickly reply text to MO and handle per-short code sending to quarantine.

The Keyword and Short code columns define conditions to trigger the auto reply. If both fields match, the MO is send and the additional action is triggered. To specify a wildcard, you should leave the field empty. Keyword matches against the first alphanumeric word in the MO text, ignoring punctuation and leading spaces. It means that the Keyword field cannot contain spaces and must be a single word.

Also, the Keyword setting is a prefix. e.g. if you specify "AD", it will match "AD", "ADAPT" and "ADOBE". If you have multiple keywords with a common prefix, you need to pay attention to the order since keywords are processed from top to bottom.

The Answer column is the text to reply. No personalization is available in this field. If you leave this field empty, no message will be replied but the additional action will be triggered anyway.

The Additional action column provides an extra action to do when both keyword and short code match. Currently, you can send to quarantine or remove from quarantine the recipient; none will only reply the text. The action is triggered even if you don't specify an answer. Sending to quarantine occurs only for the specified short code, not for the whole profile (this is the minimum legal requirement of most countries).

All entries in the table are processed in the specified order, until one rule matches. If multiple rules match a MO, only the topmost rule will be applied.


In ACC, in a hybrid architecture, applying auto-reply for the new extended SMPP connector requires to add write access for the mid operator on the external account folder.

The old Adobe Campaign Classic Generic SMPP connector has an automatic reply feature, but it does not send to quarantine. The feature works differently. Please refer to the Campaign Classic documentation for more information.

SMS delivery template parameters

Some parameters may be set per delivery template.

From field

This field is optional. It allows overriding sender address (oADC). The content of this field is placed in the source_addr field of the SUBMIT_SM PDU.

The field is limited to 21 characters by the SMPP specification, but some providers may allow longer values. Note also that very strict restrictions may be applied in some countries (length, content, allowed characters, ...).

Delivery parameters

Maximum number of SMS per message

This setting only works if the Message payload setting is disabled (for more information on this, refer to Campaign Standard documentation). If the message requires more SMS than this value, an error will be triggered.

The SMS protocol limits SMS to 255 parts, but some mobile phones have trouble putting together long messages with more than 10 parts or so (the limit depends on the exact model). We advise you not to go over 5 parts per message.

Also applies for Adobe Campaign Classic (all versions, all connectors).

Transmission mode

This field indicates the kind of SMS you wish to transfer: normal or flash messages, storing on the mobile or the SIM card.

This setting is transmitted in the dest_addr_subunit optional field in the SUBMIT_SM PDU.

  • Unspecified sends no optional field in the PDU
  • Flash sets the value to 1. It sends a flash message that pops up on the mobile and is not stored in memory.
  • Normal sets the value to 0. It sends a normal message.
  • Save on mobile sets the value to 2. It tells the phone to store the SMS in internal memory.
  • Save on terminal sets the value to 3. It tells the phone to store the SMS in the SIM card.

Values are different for Adobe Campaign Classic. Please check Adobe Campaign Classic documentation for more information.

Validity period

The validity period is transmitted in the validity_period field of the SUBMIT_SM PDU. The date is always formatted as an absolute UTC time format (the date field will end with "00+").

Validity period is also applicable for Adobe Campaign Classic (all versions, all connectors).

SMS text encoding

You should always contact the SMSC provider in case of encoding problems. Only the SMSC providers have precise knowledge of the encoding they support and special rules that may apply due to limitations in their technical platform. Make them check what you send them and what they send back to you, it is the only path to a successful and stable interconnection.

SMS messages use a special 7 bits encoding, often called the GSM7 encoding.

In the SMPP protocol, GSM7 text will be expanded to 8 bits per character for easier troubleshooting. The SMSC will pack it into 7 bits per character before it is sent to the mobile. This means that the short_message field of the SMS may be up to 160 bytes long in the SMPP frame whereas it is limited to 140 bytes when sent on the mobile network (the most significant bit is simply discarded).

In case of encoding problems, here are some important things to check:

  • First, make sure that you know which characters belong to which encoding. GSM7 does not fully support diacritical marks (accents). Especially in French, where é and è are part of GSM7, but êâ or ï are not. The same applies to Spanish.
  • The C with cedilla (ç) is present only in upper case in the GSM7 alphabet, but some phones render it in lower case or "smart" case: the general recommendation is to completely avoid it and remove the cedilla or switch to UCS-2.
  • Do not use ASCII in SMS unless explicitly requested by the SMSC provider: This encoding wastes space because it has 8-bit characters and less coverage than GSM7.
  • Latin-1 is not always supported. Check the compatibility with your SMSC provider before attempting to use Latin-1.
  • National language shift tables are not supported by the Adobe Campaign connector. You must use UCS-2 or other data_coding instead.
  • UCS-2 and UTF-16 are often mixed by phones. This is a problem for people sending emojis and other rarely used characters not present in UCS-2.
  • Most phones don't have font glyphs for all UCS-2 characters. Smartphones tend to be able to display rare characters rather easily, but feature phones generally have limited support to what's useful in the native tongue of the country they were bought in. If you want to use emoji or ASCII-art of some sort, test it on a wide variety of phones before sending. Campaign preview does not simulate missing glyphs and will display whatever symbols are available on the web browser displaying the preview.

The data_coding field tells you which encoding is used. A major problem is that the value 0 means default SMSC encoding in the specification, in general it means GSM7, but that's not always the case. Check with the SMSC partner which encoding is associated with data_coding = 0 (Adobe Campaign only supports GSM7 for data_coding = 0). Other data_coding values tend to follow the specification, but the only way to be sure is to check with the SMSC provider.

The maximum size of a message depends on its encoding. This table sums up all the relevant information:

Encoding Usual data_coding Message size (characters) Part size for multipart SMS Available characters





GSM7 basic character set + extension
(extended characters take 2 characters)










Unicode (varies from phone to phone)

Troubleshooting encoding issues

Encoding issues are frequent in SMS. Here are a few basic steps that you can perform.

Step 1: Get in touch with the provider

Contact you provider to see with what's wrong with your SMS. Your provider should be able to tell you if the problem is on their side or in Adobe Campaign. If the problem is coming from Adobe Campaign, they should be able to tell you exactly what field is incorrect.

Step 2: Know what's in your message

Unicode allows many variants for look-alike characters that Campaign cannot handle them all.

The most common source of problems is copy-paste from a word processor, this changes usual characters to typographically-correct versions: spaces changed to non-breaking spaces, double quotes changed to opening and closing quotes, minus signs changed to various kinds of hyphens, etc.

Don't copy-paste your message when testing, always type it directly in the interface.

Don't be afraid of hexadecimal. Hexadecimal has a very distinct quality: you can tell the difference between similar characters. A lower-case L, a upper-case I, O, 0, all different types of quotes, non-latin encodings or even different types of spaces can all look the same (or even not being displayed at all). Hexadecimal shows everything and helps to compare things.

To convert unicode to hexadecimal, you can use online tools such as Type in your text in the first box, make sure there is no PII such as phone numbers, and click "Convert". You will see the hexadecimal values at the bottom (UTF-32 zone).

When opening tickets about encoding problems, whether with the provider or the Adobe Campaign support, always include a hexadecimal version of what you type and what you see.

Step 3: Know what you should send

Determine the encoding you expect to be used and search online for its character table. Check that the characters you intend to send are actually available in the target code page. Check that the data_coding field is correct and matches what you and the provider expect.

Step 4: Know what you actually sent

You will need the debug output of the connector in order to see exactly what bytes you send to the provider. Encoding problems appear in SUBMIT_SM PDUs, so be sure to capture them. Send very distinct messages that are easy to find in the log.

Don't hesitate to send different kinds of special characters when testing. For example, GSM7 encoding has extended characters that are very distinct in their hexadecimal form, this makes them easy to spot since they don't appear in any other encoding.

SMPP error management: Appendix B

The SMPP protocol defines standard synchronous errors in RESP PDUs, but it does not define error codes for SR. Each provider uses their own error codes with their meaning.

A recommendation is made in the Appendix B section of the SMPP protocol specification, but this does not list the actual error codes nor their meaning.

To adapt to error management, the broad log message system of Campaign has been leveraged to properly provision errors and their severity (hard, soft, ...).

As mentioned above, there are 2 different kinds of errors: synchronous replies in the SUBMIT_SM_RESP that happen immediately after the message was sent to the SMSC and receipts that may come much later when the mobile received the message or when the message timed out. In that case the error is found in a SR.

When a SR is received, status and error can be found in its short_message field (example for Appendix B conforming implementations). Be careful, the short_messagefield of the PDU is often called the text field because it contains text in MT; but in case of SR, it contains technical information plus a sub-field named Text (which is practically useless BTW except for some troubleshooting). These 2 fields are different and short_message actually contains the Text field and other information.

The old Adobe Campaign Classic connectors (all of them except Extended SMPP) use a hardcoded behavior that depends on the selected provider. Generic SMPP only distinguishes between success and error, with no detail. Delivery log may contain some information which is not guaranteed.

Format of SR text field described by Appendix B

The specification recommends using this format for the SR text field. It is a list of subfields, space-separated with a colon to separate the field name and its value. Field names are case insensitive.

Example of a SR text field matching exactly the Appendix B recommendation:

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

The id field is the ID received in the SUBMIT_SM_RESP PDU (the acknowledge of the MT).

sub and dlvrd are supposed to count the amount of delivered parts and delivered messages, but this rarely works and is not used by Campaign since the broad log system is superior and gives better, more integrated information.

submit date and done date fields are indicative timestamps of when the MT was sent and when the SR was sent by the mobile. Expect some problems with time zones or even wrong timestamps given by mobiles with incorrect date set.

The stat field is important: it tells the status of the message. The only important status are DELIVRDUNDELIV and REJECTD. DELIVRD indicates a success, the other two indicate an error. Other values are possible, but they are usually intermediate notifications (e.g. the MT reached the mobile carrier, but not the mobile phone): these intermediate notifications are ignored by Campaign.

The err field contains the provider-specific error code. The provider has to give a table of possible error codes along with their meaning to be able to interpret this value.

Finally, the text field usually contains the beginning of the text of the MT. This is ignored by Campaign and some providers don't transmit it to avoid PII leakage and useless network bandwidth consumption. The only advantage is during troubleshooting: you may spot the SR matching a test MT more easily by reading this field.

Example of how a SR is processed in Adobe Campaign Standard

This shows a concrete example of how the MTA processes a SR. This example shows the case of an implementation following exactly the Appendix B recommendation, default values in the external account, and a successful SMS MT.

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

First, the id extraction regex is applied to extract the ID and reconcile it with the corresponding MT.

Then, the status extraction regex and error code extraction regex are applied to extract these fields and they are appended to the string.

The broad log message is constructed with this information, and the original unaltered string is appended for reference:

SR ExampleProvider DELIVRD 000|MESSAGE=id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

Then, the message is normalized, removing the MESSAGE part to be able to match multiple messages with the same stat and err codes.

SR ExampleProvider DELIVRD 000|#MESSAGE#

If the message is not already provisioned in the broad log message table, a new entry will be created, using the whole message as "firstText" and the normalized message. Then, the connector uses the success and error regex to determine if it was a success or a failure:

  • If it matches the success regex, it will be considered as a success.
  • If it matches the error regex, the message is qualified as an error.
  • If none of these two regex match, the SR is ignored (it may be an intermediate notification, which is not handled by Campaign).

By default, all errors are provisioned as hard errors. This means that soft errors must be provisioned by hand to enable retries.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Twitter™ and Facebook posts are not covered under the terms of Creative Commons.

Legal Notices   |   Online Privacy Policy