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:

You can use the SMPP for the following applications:

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.
Documentation for this request can be found here.

SMPP Server

Without SSL

; 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 package
urpmi yate-openssl

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

[general]

[self_signed]
domains=yourcompany-smsc01 (or whatever you entered as Common Name in certificate)
certificate=certificate.pem

[listenerserver second-desired-name]
addr=10.0.0.1
port=2776

sslcontext=self_signed

[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

; 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

;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

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

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

YateSMSC SMPP error codes

YateSMSC places in SMPP variable network_error_code the following values:

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)

Our solutions