SMPP (Short Message Peer-to-Peer)
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
[smpp-server]
enable=yes
default-service-type=sms
(…)
[listenerserver desired-name]
enable=yes
addr=10.0.0.1
port=2775
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
[general]
[self_signed]
domains=yourcompany-smsc01 (or whatever you entered as Common Name in certificate)
certificate=certificate.pem

In /etc/yate/smsc/ysmpp.conf
[listenerserver second-desired-name]
addr=10.0.0.1
port=2776
…
sslcontext=self_signed

Connecting clients authentication using /etc/yate/smsc/regfile.conf
[client1_system_id]
password=client1_password
[client2_system_id]
password=client2_password
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
[smpp-client]
clients=section-name,other-section,…
(…)
;starting section, whose name is ‘section-name’
[section-name]
enabled=true
server=10.1.1.1
port=2775
system_id=yatesmsc
system_password=myPWD1234!
With SSL

In /etc/yate/smsc/ysmpp.conf
;starting section, whose name is ‘with_ssl’
[with_ssl]
enabled=true
server=10.2.2.2
port=2776
system_id=yatesmsc-tls
system_password=myPWD5678!
sslmode=true
; system_id: string: Default system id used for authentication.
; Length 1-16.
;system_id=yate
; system_password: string: Default password used for authentication.
; Length 1-9.
;system_password=yate;
SMPP routes
…=smppserver/INBOUND_SYS_ID
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)
…=smppclient/OUTBOUND_SYS_ID
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
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:
[general]
; system_id from SMPP client connection for backup gateway
backup_smpp_gw=OUTBOUND_SYS_ID
; or
;backup_smpp_gw=smppclient/OUTBOUND_SYS_ID
; or
;backup_smpp_gw=smppserver/INBOUND_SYS_ID
; trust the SMPP GW enough to act on the permanent errors
;smppgw_trusted=true
; address to use in CDR if resolving SMPP GW name fails
;smppgw_address=foo.example.com:9000
Examples

rex-custom.conf example
[default]
;begin rules for template=route_sms_deliver
${sms_type}^status_report$=if ${submit_info}^HTTP=http://10.10.1.120/status?billid=${billid}&status=${sms_stat}
${module}smppserver=;retries=10
${module}smppclient=;retries=8
[default]
${module}smsc_map={
;if GT = +88229009 send it to http
^+\?88229009$=http
;if it cames from SMPP and GT is 88229002 send it to client1_system_id registered to smppserver
${submit_info}^SMPP={
^+\?88229002$=smppserver/client1_system_id
}
^+\?88229003$=smppserver/client2_system_id
^+\?8822=http
^+\?8822=http
.*=smsc_map
}=
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

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 9.2.3.15 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)