SMPP Specifications

The SMPP specification defines how to exchange SMS messages with DIDWW using the Short Message Peer-to-Peer protocol. It is fully compliant with the SMPP v3.4 Specifications and supports both outbound messages sent from an External Short Messaging Entity (ESME) to an SMSC and inbound messages delivered from an SMSC to an ESME.

  • External Short Messaging Entity (ESME) is an external application that connects to a Short Message Service Center (SMSC) to engage in the sending and/or receiving SMS messages

  • Short Message Service Center (SMSC) is a network element in the mobile telephone network. Its purpose is to store, forward, convert and deliver SMS messages.


P2P and A2P Messaging

The SMPP protocol is used for both Person-to-Person (P2P) and Application-to-Person (A2P) messaging.

  • P2P - Low-volume, two-way exchange of SMS between end-users. Typically handled through either ESME or SMSC trunks, depending on direction.

  • A2P - High-volume SMS generated by applications and sent to subscribers. Usually sent over an ESME trunk, where your application connects directly to the SMSC.

Important

A2P traffic requires a registered A2P campaign sender ID.


Bind Parameters for SMPP ESME Trunks

When your application connects to the DIDWW SMSC (using an ESME trunk), it must perform a bind with the following parameters.

Parameter

Description

system_id

The System ID from the trunk’s Credentials.
Identifies your ESME during the bind request.

password

The Password from the trunk’s Credentials.
Used with the system_id for authentication.

system_type

Optional field set when creating the SMPP trunk.
Categorizes the bind (e.g., VMS for voicemail, OTA for over-the-air updates).

host

The SMPP server address.
Use the global endpoint 46.19.209.214 or a regional endpoint.

port

2775 (default SMPP port).

Important

  • For SMPP SMSC trunks, DIDWW performs the bind to your system automatically using the credentials you provide in the trunk settings.

  • Your SMSC must be configured to accept incoming bind_transmitter or bind_transceiver requests on the specified host/port, and validate them using the system_id and password you defined in the trunk.

  • Configure your firewall to allow inbound connections from DIDWW SMPP server global endpoint 46.19.209.214 and all other regional endpoints.


SMPP Message Flow

In SMPP, the SMS payload and control are exchanged using Protocol Data Units (PDUs). The key PDUs for message delivery are:

  • submit_sm — Sent by an ESME to submit an outbound SMS. It typically carries fields like source_addr, destination_addr, and the short_message text.

  • deliver_sm — Sent by an SMSC to deliver an inbound (MO) SMS to an ESME, or to return a delivery receipt (DLR). It may carry either message text or status information.

Message flow depends on the SMPP trunk type:

  • ESME – Your application binds as the ESME to DIDWW’s SMSC. You send SMS using submit_sm and receive inbound SMS or DLRs via deliver_sm.

  • SMSC – DIDWW binds as an ESME to your SMSC. DIDWW submits SMS with submit_sm, and your SMSC can send inbound messages or receipts with deliver_sm.

When creating an SMSC trunk, you can choose the SMPP connection mode:

  • Transmitter — The ESME (DIDWW) can only send outbound messages to your SMSC. Uses the TX (Transmitter) port, while the RX port is ignored.

  • Transceiver — The ESME (DIDWW) can both send and receive messages on the same bind session. Uses the Transceiver port (TX/RX combined).

Note

  • The SMS text is normally carried in the short_message field.

  • Concatenated messages use a User Data Header (UDH) within short_message to split and reassemble long SMS.

  • Delivery receipts (DLR) are also sent in deliver_sm and typically contain status information.

  • Each PDU requires an acknowledgement: submit_sm ↔ submit_sm_resp, deliver_sm ↔ deliver_sm_resp.


Data Coding Scheme (DCS)

The data_coding parameter, also known as DCS (Data Coding Scheme), specifies the character set for an SMS message. The encoding you use directly impacts how many characters can fit into a single SMS part.

DCS Value

Encoding

Max characters per SMS

0

GSM-7 (Default).

160

1

US-ASCII.

160

3

Latin1 (ISO-8859-1 ).

160

8

Unicode / UCS-2 (ISO/IEC-10646 ).

70

Note

  • GSM-7 is the standard encoding for most SMS.

  • UCS-2 is required for non-Latin scripts (e.g., Chinese, Arabic, Cyrillic) but reduces the per-SMS character limit.


Concatenated Messages

To overcome the 160-character limit of a single SMS, long texts are split into smaller fragments and reassembled at the recipient’s device. This creates a multi-part SMS, known as a concatenated message. A User Data Header (UDH) is added to each part, which slightly reduces the character capacity.

Note

  • Up to 255 parts can be combined to form one long message.

  • Each part is billed as a separate SMS.

Encoding

Bit Size

Max Chars
(Single SMS)

Max Chars
(per Part in Concatenated SMS)

GSM-7 & Latin-1/9

7-bit

160

153

UCS-2 (Unicode)

16-bit

70

67

Endpoints

Hostname

sms-out.didww.com

us.sms-out.didww.com

nyc.us.sms-out.didww.com

mia.us.sms-out.didww.com

lac.us.sms-out.didww.com

eu.sms-out.didww.com

sg.sms-out.didww.com