SMPP Technical Specifications

Knowledge Base

SMPP Technical Specifications


Icons/System/eye-open Created with Sketch. 1971 Views 05.03.2025 Telecom / SMS / Time2Chat

Objective

Discover the technical specifications of the OVHcloud SMPP solution.

Glossary

  • PDU: Protocol Data Unit is the object/entity for exchanging requests and responses
  • SMPP: Short Message Peer to Peer Protocol
  • SMSC: Short Message Service Centre (server)
  • ESME: External Short Message Entity (client)
  • UDH: User Data Header
  • SM: Short Message
  • DLR: Delivery Receipt
  • PTT: Premium Tracking Technical is an error code communicated in the message of a DLR
  • MT: Mobile Terminated
  • MO: Mobile Originated

For more explanation of abbreviations, see page 10 of smpp.org's SMPP specifications.

Presentation

What is SMPP used for?

The SMPP (Short Message Peer-to-Peer) is a protocol for exchanging SMS messages to telecom operators and by content providers. It typically uses two TCP/IP connections, one for sending and one for receiving data.

What are the benefits of SMPP compared to the standard SMS offer

  • The protocol is standardised and can be integrated with many market tools
  • It provides high throughput with low latency

What is the typical use of sending an SMS by SMPP?

Client SMS sending application (ESME) has three means of communication with SMSC:

  • Transmitter: sending a message
  • Receive: receiving a message
  • Transceiver: sending and receiving a message

Find more information on the means of communication in the chapter List of PDUs.

Once a connection has been established between the ESME and an OVHcloud SMSC, a message can be sent and/or received.
Authentication of the connection to the SMSC is done with the system_id (identifier), the password and the IP address of your application.

The OVHcloud SMPP solution allows you to:

  • Send SMS messages with (or without) acknowledgement of receipt (DLR)
  • Receive a message sent from a mobile phone
SourceDestination
Sending an SMS (MT)- Shortcode (Metropolitan France and Belgium)
- Alphanumeric
- Virtual number*
International number in E.164 format
Send an SMS message authorising a reply- Shortcode (Metropolitan France)International number in E.164 format
Send an SMS message authorising a response with a MT/MO ratio of 1:1- Virtual number*Virtual number*
Receiving an SMS sent from a mobile (MO)- Mobile phone numberVirtual number*

Virtual number*: transactional channel only

Technical specifications

Protocols description

Bind Request

An ESME can connect in one of three modes: Transmitter, Receiver, Transceiver.
These connection requests are supported in accordance with the SMPP v3.4 protocol specification.

Bind Response

During the login process, the ESME makes a Bind Request providing the system_id (identifier) and its password.
This information, along with your application's IP, is used to authenticate the connection request.
A response is then sent by the SMSC with a status that defines whether authentication is successful or not.

PDU List

bind_transceiver and bind_transceiver_resp

This type of bind is used to initiate a two-way communication connection between the SMSC and the ESME (the fusion of the transmitter and receiver modes).

bind_transmitter and bind_transmitter_resp

This type of bind is used to initiate a connection that only allows ESME to communicate to the SMSC (sending SMS to a mobile). The SMSC sends responses associated with query PDUs on the same connection.

bind_receiver and bind_receiver_resp

This type of bind is used to initiate a connection that only allows communication from the SMSC to the ESME (sending acknowledgement (DLR) or messages sent from a mobile phone). ESME sends responses associated with query PDUs on the same connection.

unbind and unbind_resp

A request to close a connection that is initiated by the SMSC or ESME. The party receiving the request returns a response when it is ready to cut the connection.

OVHcloud SMSC unbinds the connections every 24h, the ESME must reconnect automatically.

outbind

Not supported

submit_sm and submit_sm_resp

The submit_sm is used by an ESME to submit an SMS to the SMSC for transmission to a mobile number.

Mandatory parameters:

Parameter nameRef. Spec 3.4Supported
service_type5.2.11No
source_addr_ton5.2.5Yes
source_addr_npi5.2.6Yes
source_addr5.2.8Yes
dest_addr_ton5.2.5Yes
dest_addr_npi5.2.6Yes
destination_addr5.2.9Yes
esm_class5.2.12Yes
protocol_id5.2.13No
priority_flag5.2.14No
schedule_delivery_time5.2.15Yes
validity_period5.2.16Yes
registered_delivery5.2.17Yes
replace_if_present_flag5.2.18No
data_coding5.2.19Yes
sm_default_msg_id5.2.20No
sm_length5.2.21Yes
short_message5.2.22Yes
  • source_addr can be an international number, an alphanumeric number or a shortcode number:
    • alphanumeric: those phone numbers are composed of letters and numbers (e.g. ovh123).
      • source_addr_ton = 5
      • source_addr_npi = 0
    • shortcode: those phone numbers contain between 3 and 8 numbers (e.g. 38069). The shortcode is only set to notify our service that we will have to use one, the real shortcode used to send the sms will be set by the telecom operator.
      • source_addr_ton = 3
      • source_addr_npi = 1
    • international: those phone numbers are composed of the country identifier and usual number without the first 0 (e.g. 33601020304).
      • source_addr_ton = 1
      • source_addr_npi = 1
  • destination_addr must be an international number (e.g. 33600000001).
    • dest_addr_ton = 1
    • dest_addr_npi = 1

Optional settings:

Parameter nameRef. Spec 3.4Supported
user_message_reference5.3.2.17No
source_port5.3.2.20No
source_addr_subunit5.3.2.2No
destination_port5.3.2.21No
dest_addr_subunit5.3.2.1Yes
sar_msg_ref_num5.3.2.22No
sar_total_segments5.3.2.23No
sar_segment_seqnum5.3.2.24No
more_messages_to_send5.3.2.34No
payload_type5.3.2.10No
message_payload5.3.2.32No
privacy_indicator5.3.2.14No
callback_num5.3.2.36No
callback_num_pres_ind5.3.2.37No
callback_num_atag5.3.2.38No
source_subaddress5.3.2.15No
dest_subaddress5.3.2.16No
user_response_code5.3.2.18No
display_time5.3.2.26No
sms_signal5.3.2.40No
ms_validity5.3.2.27No
ms_msg_wait_facilities5.3.2.13No
number_of_messages5.3.2.39No
alert_on_msg_delivery5.3.2.41No
language_indicator5.3.2.19No
its_reply_type5.3.2.42No
its_session_info5.3.2.43No
ussd_service_op5.3.2.44No

The submit_sm_resp is confirmation that the SMSC has received the submit_sm.
It contains a message_id which is the SMSC message identifier to link to the acknowledgement (DLR) sent later when the mobile phone received the SMS (provided that the DLR request is specified in the submit_sm).

deliver_sm and deliver_sm_resp

The deliver_sm is issued by the SMSC to send a DLR to the ESME if requested by the ESME in the submit_sm or for an incoming message (response to a shortcode or an SMS sent to your virtual number).

Mandatory parameters:

Parameter nameRef. Spec 3.4Supported
service_type5.2.11No
source_addr_ton5.2.5Yes
source_addr_npi5.2.6Yes
source_addr5.2.8Yes
dest_addr_ton5.2.5Yes
dest_addr_npi5.2.6Yes
destination_addr5.2.9Yes
esm_class5.2.12Yes
protocol_id5.2.13No
priority_flag5.2.14No
schedule_delivery_time5.2.15No
validity_period5.2.16No
registered_delivery5.2.17No
replace_if_present_flag5.2.18No
data_coding5.2.19Yes
sm_default_msg_id5.2.20No
sm_length5.2.21Yes
short_message5.2.22Yes

Optional settings:

Parameter nameRef. Spec 3.4Supported
receipted_message_id5.3.2.12Yes
user_message_reference5.3.2.17No
source_port5.3.2.20No
destination_port5.3.2.21No
sar_msg_ref_num5.3.2.22No
sar_total_segments5.3.2.23No
sar_segment_seqnum5.3.2.24No
user_response_code5.3.2.18No
privacy_indicator5.3.2.14No
payload_type5.3.2.10No
message_payload5.3.2.32No
callback_num5.3.2.36No
source_subaddress5.3.2.15No
dest_subaddress5.3.2.16No
language_indicator5.3.2.19No
its_session_info5.3.2.43No
network_error_code5.3.2.31No
message_state5.3.2.35No

OVHcloud-specific settings:

Parameter nameTag TLV (hex)Field typeSizeDescription
outgoing_id0x1401Null-terminated character string (\0)64 bytesOVHcloud internal ID used in the case of a DLR
incoming_id0x1402Null-terminated character string (\0)64 bytesOVHcloud internal ID used in the case of a MO

Our service will attempt to send the deliver_sm to ESME for up to 7 days.

Acknowledgement Error Codes (DLR)
Error code (PTT)Description
0No Error
1Internal Error
2Network Error
3Unreachable Destination
4Equipment Error
5Subscriber / Credit Related (e.g. Account or sender is invalid, Recipient number unreachable)
6Timeout
7Operator Related
8Parental Lock
9Undeliverable
10Account Credit (e.g. Not enough credit, Auto-recredit issue)
50Internal Error
51Internal Error
52Missing Template (e.g. US destination requires approved templates)
53Blacklisted (a STOP response sent by the recipient to block the sender)
54Forbidden destination
55Sender Temporarily Ratelimited (maximum sms sent exceeded during a short period)
100Invalid Destination Numbering Plan
101Invalid Content
102Invalid GSM7 Coding (e.g. error with packed/unpacked GSM7)
103Message too long for the number of allowed segments
254Pending
255Unknown Error
800Undeliverable
801Expired
802Deleted
803Rejected
804Unknown

PDU used by SMSC and ESME to check if a connection is still active.

It is recommended that you follow a 30-second interval between each request.

generic_nack

PDU returned by SMSC when a PDU is not supported or corrupted.

query_sm and query_sm_resp

Not supported.

cancel_sm and cancel_sm_resp

Not supported.

replace_sm and replace_sm_resp

Not supported.

alert_notification

Not supported.

submit_multi and submit_multi_resp

Not supported.

data_sm and data_sm_resp

Not supported.

Response PDU Statuses

Any response PDU (those ending with _resp) has a status. The SMPP specification provides a list of generic status (SMPP 3.4, 5.1.3 command_status) common to all SMSCs.

A specific range of statuses is reserved for SMSCs. These are the ones used by OVHcloud:

Error codeValueDescription
ESME_RBINDTHROTTLED0x00000400Too many bind authentication
ESME_RUNSDATACODING0x00000401Data Coding unsupported
ESME_RINVGSM7CODING0x00000402Short message GSM7 (GSM 03.38) encoding issues, contact support

Data Coding Scheme

The data coding is used by the submit_sm and the deliver_sm to encode the message.

List of supported data coding:

  • GSM 03.38 (GSM 7 bits)*
  • UCS2

GSM 03.38*: this encoding represents each character on a septet, but some SMPP clients represent it on a byte. Since the byte format is the most used, your SMPP account is configured on this format by default. If you experience encoding issues with your SMPP client, please contact OVHcloud support to have the format changed.

TLV

A TLV (Tag, Length, Value) can be used to enrich a PDU by adding optional information. Some are common and used by multiple SMSCs, and others may be more OVHcloud specific.

Identification system

System ID

SMPP connection identifier, it's generated with random characters.

Password

The password is generated and provided each time an SMPP account is created.

List of authorised IPs

A list of IPs is required to authorise the machine(s) to connect to the SMSC.

Connection type

  • Secure connection: encrypted connection with TLS 1.3 minimum.
  • Insecure connection: a connection that does not have TLS encryption for backward compatibility (all exchanges are in plain text and are therefore visible to third parties).

Sending limits

Connection per zone

By default, an SMPP account can have only one pair of Transmitter/Receiver or one Transceiver per zone.

Windowing

By default, an SMPP account is allowed to process up to 10 messages simultaneously.

Throughput

By default, an SMPP account is allowed to process up to 20 messages per second per connection.

Protocol version

The protocol version is 3.4.

List of SMPP customers tested by OVHcloud

  • Kannel 1.4.5

Go further

SMPP Technical Documentation

Managing an SMS SMPP account

Related articles