SMPP stands for Short Message Peer to Peer protocol, SMPP technology is used to send and receive SMS (short message service) from and to most mobile device systems.

SMPP implementation of YateSMSC allows fast delivery of SMS messages, and has the following advantages:

The SMPP protocol is TCP/IP based

Users can send SMS to a simple shortcode

High throughput (up to 200 msgs/second)

An alphanumeric sender address can be assigned

You can use the SMPP for the following applications:

Transport SMS at affordable price on a secondary route

Sending Voicemail alerts/SMS notifications to mobile users

Information services: sending stock exchanges, traffic jam alerts or weather forecasts

Voting, process votes from mobile users

You can set up your YateSMSC as an SMPP server or as an SMPP client directly from YateMMI(link catre yatemmi). -> Equipment -> YateSMSC

Examples, configuration, and guidance used by Yate staff to set up YateSMSC as an SMPP server or as an SMPP client.

A new request was added to YateSMSC Configuration API to set the SMPP client/server easier.

SMPP Server

To act as a server you must add a listener under the [smpp-server] section.

Without SSL

In /etc/yate/smsc/ysmpp.conf

; server configuration

[listenerserver desired-name]

With SSL

Frist of all, please install yate-openssl packageurpmi yate-openssl

To act as a SSL server you must create and install a certificate

The sslcontext parameter tells SMPP which certificate to use from those defined in openssl.conf

To generate a self-signed passwordless certificate:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365
openssl rsa -in key.pem -out key-bare.pem
cat cert.pem key-bare.pem > /etc/yate/smsc/certificate.pem
chmod 600 /etc/yate/smsc/certificate.pem

When asked about Common Name enter yourcompany-smsc01 (or the hostname you wish)

In /etc/yate/smsc/openssl.conf


domains=yourcompany-smsc01 (or whatever you entered as Common Name in certificate)

In /etc/yate/smsc/ysmpp.conf

[listenerserver second-desired-name]

Connecting clients authentication using /etc/yate/smsc/regfile.conf



SMPP client

To act as a server you must add a client section under the [smpp-client] section.

Without SSL

In /etc/yate/smsc/ysmpp.conf

; client configuration that can be used with backup_smpp_gw set to system_id from yatesmsc.conf

;starting section, whose name is ‘section-name’

With SSL

In /etc/yate/smsc/ysmpp.conf

;starting section, whose name is ‘with_ssl’
; system_id: string: Default system id used for authentication.
; Length 1-16.

; system_password: string: Default password used for authentication.
; Length 1-9.

SMPP routes


For an inbound connection where INBOUND_SYS_ID is the [username] (section name) from regfile.conf

In case your system acts as a SMPP server / listener (usually SMSC side)


For an outbound connection where OUTBOUND_SYS_ID is the system_id from a client section in ysmpp.conf

In case your system acts as a SMPP client / connection initiator (usually ESME side)


Failover has currently just limited support for a backup SMPP connection if MAP routing fails.

Currently only MAP supports fallback and only over SMPP. (module smsc_map falls back to backup_smpp_gw)

In this case in yatesmsc.conf set at least backup_smpp_gw:


; system_id from SMPP client connection for backup gateway
; or
; or

; trust the SMPP GW enough to act on the permanent errors

; address to use in CDR if resolving SMPP GW name fails


rex-custom.conf example

;begin rules for template=route_sms_deliver
${sms_type}^status_report$=if ${submit_info}^HTTP=${billid}&status=${sms_stat}

;if GT = +88229009 send it to http
;if it cames from SMPP and GT is 88229002 send it to client1_system_id registered to smppserver

Coding Schemes

For an outbound connection where OUTBOUND_SYS_ID is the system_id from a client section in ysmpp.conf

In case your system acts as a SMPP client / connection initiator (usually ESME side)

0 (default) – can be configured:

  • on input for GSM7 packed with optional User Data Header or ASCII / UTF-8
  • on output same as above or Latin-1

1 – ASCII / UTF-8 (on input only)

3 – Latin-1 (on input only)

8 – UTF-16 (UCS-2)

16-255 – same as GSM DCS

YateSMSC SMPP error codes

YateSMSC places in SMPP variable network_error_code the following values:

0x00: 0000000 Short message received by the SME

0x22: 0100010 Temporary error
No response from SME. Sent for following MAP errors: absentSubscriber, absentsubscriberSM, unidentifiedSubscriber, memoryCapacityExceeded

0x25: 0100101 Temporary error
Error in SME. Sent for following MAP errors: equipmentProtocolError, subscriberBusyForMT-SMS, sm-DeliveryFailure, sc-Congestion

0x46: 1000110 Permanent error
SM Validity Period Expired

0x49: 1001001 Permanent error
SM does not exist. Sent for following MAP errors: unknownSubscriber, illegalSubscriber, illegalEquipment, callBarred, teleserviceNotProvisioned, subscriberNotSC-Subscriber, invalidSME-Address, equipmentNotSM-Equipped

These are standard TP-STATUS values as defined in TS 23.040 TP-Status (TP-ST)
YateSMSC does not send any reserved TP-STATUS over SMPP.

More detailed information about SMS failure errors can be found the SMSC CDRs by using the Message ID IE value from Submit-SM response or receipted_message_id from Deliver-SM.
In CDRs (call detail records) the non-mapped error can be found. A call detail record (CDR) is a data record produced by telecommunications equipment (e.g, phone) that documents the details of a text message or other telecommunications transactions (e.g., voice call, data access)