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.
Documentation for this request can be found here.
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 package
- urpmi 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
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
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
- 0x25: 0100101 Temporary errorError in SME. Sent for following MAP errors: equipmentProtocolError, subscriberBusyForMT-SMS, sm-DeliveryFailure, sc-Congestion
- 0x46: 1000110 Permanent errorSM Validity Period Expired
- 0x49: 1001001 Permanent errorSM 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)