SMPP Integration Document Guide

SMPP Partner Integration User Guide
eBrokerage Platform
Head Quarters office: Av. Infante Santo 2H-3rd Floor 1350-178 Lisboa Portugal
Tel: (351) 21 248 78 00 I Fax: (351) 21 248 78 99 I www.timwe.com
Version Control
Version
V0.1
Date
25-08-2011
Author
Jos Ribeiro
Changes
Initial Version.
V1.0
01-11-2011
Joo Rebelo
Further clarification on Manual
V2.0
25-01-2012
ngelo Costa
Changed logo
Table of Contents
Version Control........................................................................................................................................ 2
Table of Contents ................................................................................................................................... 3
Glossary ..................................................................................................................................................... 4
Introduction .............................................................................................................................................. 5
Overview ................................................................................................................................................ 5
1. SMPP Service ...................................................................................................................................... 6
Binding.................................................................................................................................................... 6
Submitting messages ....................................................................................................................... 6
SMPP Optional Parameters ............................................................................................................. 8
Receiving Messages........................................................................................................................... 8
TON and NPI......................................................................................................................................... 8
Receipts.................................................................................................................................................. 8
Error handling ...................................................................................................................................... 9
Standoff Policy ..................................................................................................................................... 9
2. SMPP Configuration ........................................................................................................................ 10
3. Acceptance Tests ............................................................................................................................ 13
SMPP Connectivity Tests ............................................................................................................... 13
SMPP Protocol Tests ........................................................................................................................ 13
Performance Tests ........................................................................................................................... 13
Resilience Tests................................................................................................................................. 13
Recording results .............................................................................................................................. 13
Stability Criteria ................................................................................................................................ 14
4. Advanced Topics .............................................................................................................................. 15
Message priorities ............................................................................................................................ 15
Send message algorithm ........................................................................................................... 15
Sending WAP Push messages ...................................................................................................... 15
Ports .................................................................................................................................................. 16
Binary SMS ..................................................................................................................................... 17
Convert to WBXML ....................................................................................................................... 18
Prepare the UDH ........................................................................................................................... 19

5. Troubleshooting ............................................................................................................................... 20
Further Reading ................................................................................................................................ 20
6. Feedback ............................................................................................................................................ 20
Appendix 1: Error Codes ................................................................................................................... 21
Glossary
Abreviation
Description
ESME
PDU
SMPP
SMSC
MO
MT
External Short Message Entity generally Connection Softwares customers system

Protocol Description Units
Short Message Peer to Peer
Short Message Service Centre generally the Connection Software systems
Mobile originated
Mobile Terminated
Introduction
This document provides the developers with instructions how to configure the short message peer-topeer protocol (SMPP) for use with SMPP API. The API can be used for sending SMS to Mobile
Subscribers, receiving SMS from Mobile subscribers and delivery notifications.
This document is divided in four main sections. In the first section we cover the SMPP protocol, with the
focus on the necessary methods needed in the integration.
On second, we explain how to configure the SMPP client in order to connect to our SMSC.
The third chapter cover the tests that will be done to consider the client connection stable to move to
production.
The focus of the fourth chapter his to cover some advanced topics, like message priority and wap push.
Overview
The short message peer-to-peer protocol (SMPP) is a telecommunications industry protocol for
exchanging SMS messages between SMS peer entities such as short message service centers. It is often
used to allow third parties (e.g. value-added service providers like news organizations) to submit
messages, often in bulk.
SMPP was originally designed by Aldiscon, a small Irish company that was later bought by Logica. In
1999, SMPP was formally handed over to the SMPP Developers Forum, later renamed as The SMS
Forum.
The protocol is based on pairs of request/response PDUs (protocol data units, or packets) exchanged
over OSI layer 4 (TCP/IP session or X.25 SVC3) connections. PDUs are binary encoded for efficiency. The
most commonly used versions of SMPP are v3.3, the most widely supported standard, and v3.4, which
adds transceiver support (single connections that can send and receive messages) and optional
parameters (also known as TLVs).
Data exchange may be synchronous where each peer must wait for a response for each PDU being sent
or asynchronous where receiving and transmitting go in independent threads with the use of buffers
and timers.
The latest version of SMPP is v5.0. TIMWE currently requires v3.4.
1. SMPP Service
The current API supports the following 3.4 SMPP version of Protocol Description Units (PDUs):
BIND_TRANCEIVER / BIND_TRANCEIVER_RESP
SUBMIT_SM / SUBMIT_SM_RESP
ENQUIRE_LINK / ENQUIRE_LINK_RESP
QUERY_SM / QUERY_SM_RESP
DELIVER_SM / DELIVER_SM_RESP
UNBIND / UNBIND_RESP
You must honor the unbind PDU by issuing an unbind_resp PDU before disconnecting.
You are also required to honor the enquire_link PDU by sending an enquire_link_resp PDU.
In the future we may support more PDUs types.
Binding
Partners should bind as Transceiver so that he can take new 2-way (MT & MO, Notif) services.
TIMWE will provide you the SMPP credentials to connect to SMPP server. In some cases, if justified, you
may request access to another server. In this case, you should bind to both servers as either one may be
taken off-line for maintenance. Binding to both will greatly enhance your service reliability.
Before providing SMPP credentials, TIMWE reserves the right of requiring a VPN establishment between
the 2 parties. This solution offers more security on data transfer, since it goes through a secure channel.
The following credentials should be used in all bind PDU's:
system_id your username;
Password your PIN;
system_type blank;
Submitting messages
To submit messages you need to be correctly connected to us.
ESME
SMSC
Network Connection
Open
bind_transceiver
bind_transceiver_resp
Bound_RX
submit_sm
submit_sm_resp
submit_sm
submit_sm_resp
deliver_sm
deliver_sm_resp
unbind
unbind_resp
Unbound
Connection Closed
Closed
Our SMSC default alphabet (data_coding=0x00) is the GSM 03.38 7-bit ASCII alphabet. To use other
alphabets you should set the data_coding to the correct character set.
We fully support the following character sets:
data_coding = 0x00 GSM 03.38 7-bit ASCII
data_coding = 0x08 UCS2 ISO/IEC 10646
We support the SMPP version 3.4 message_payload (tag ID 0x0424) optional parameter. This allows you
to send us messages that are longer than 160 characters. We will split long messages before passing
them to Network Operators.
The message ID is returned in the submit_sm_resp PDU as a number (long).
SMPP Optional Parameters

To extend the SMPP protocol with extra parameters, TLV parameters, also called optional parameters
were introduced in the SMPP protocol since version 3.4:
-
TLV Stands for Tag-Length-Value field;

TLVs are used to make the existing PDUs more efficient;
TLVs are used to enhance existing PDUs with new features;
TLVs are supported in SMPP version 3.4 and higher.
TIMWE requires the partner to send us some extra parameters, for that, the partner should use the TLV
parameters as explained in SMPP protocol. The extra parameters required by TIMWE are:
-
PRICEPOINT (0x1400)
PRODUCT (0x1401)
PARTNER ROLE ID (0x1402)
Receiving Messages
When TIMWE receives an MO from the operator to your short code, it will be forward to you in
DELIVER_SM PDU. In the case of your system is down, we will make retries to deliver it until the
message expires, usually for 24 hours.
TON and NPI

At the moment our SMPP server is not validating the TON and NPI parameter, and we are just
forwarding the received values from the operator on each MO.
We advise partners to check the forwarded parameters per each operator and use the exact same
values.
Receipts
To receive delivery receipts, you need to configure your SMPP client to request for it. On each message
sent you should set the field registered_delivery (as specified in section 4.6.1. of the SMPP Protocol
Specification v3.4). This will route all delivery receipts for messages sent on your account to your SMPP
Transceiver bind.
The format of delivery receipts is as given in Appendix B of the SMPP v3.4 specification.
The message ID in the delivery receipt is given as a number (long).
If your SMPP Transceiver bind is unavailable we will try to resend receipts for up to 24 hours.
Error handling
The SMPP API supports the SMPP command_status as specified in section 5.1.3 of the SMPP Protocol
Specification v3.4. You can also check the error list in Appendix 1.
Standoff Policy
Never try to retry submit_sm PDU's that have been refused for a genuine reason like
invalid number [ESME_RINVDSTADR (0x0000000B)] or
If your Bind or Submit PDU is refused and you wish to retry it, please adhere to our stand-off strategy.
You should wait for 30 seconds for each of a maximum of 3 attempts after which you should wait for 5
minutes before resending the PDU.
2. SMPP Configuration
Weve separated the configuration into two tables, one for Binding configuration and the second for
submit configuration. Both tables describes the parameters, its protocol default value and our required
configuration in bold.
Follows the Bind configuration properties:
Key
Used at
Possible Values
Defaul
t Value
51
SMPPversion
Bind
51 3.3
52 3.4
SMPPtimeout
Connect
Integer
10000
SMPPbindsystemtype
Bind
String
null
SMPPbindaddr-ton
Bind
SMPPbindaddr-npi
Bind
0 Unknown
1 International
2 National
3 Network
Specific
4 Subscriber
Number
5 Alphanumeric
6 - Abbreviated
0 Unknown
1 ISDN
3 Data
4 Telex
6 Land Mobile
8 National
9 Private
10 ERMES
14 Internet
18 WAP Client Id
10
Description
This parameter is used to indicate the version of
the SMPP protocol.
Our SMSC requires the use of SMPP v3.4.
Required value is 52 (0x34).
Timeout (in milliseconds) used when trying to
communicate with SMPP server.
The default value may be used.
The system_type parameter is used to categorize
the type of ESME that is binding to the SMSC.
Examples include VMS (voice mail system) and
OTA (over-the-air activation system).
Null can be used.
Indicates Type of Number of the ESME address.
See TON and NPI section for more details.
Numbering Plan Indicator for ESME address.

Follows the Submit configuration properties:
Key
Used at
Possible Values
Default
Value
SMPPsubmitservicetype
SMPPsubmitdest-addrton
Submit
String
null
Submit
SMPPsubmitdest-addrnpi
Submit
SMPPsubmitesm-class
Submit
0 Unknown
1 International
2 National
3 Network
Specific
4 Subscriber
Number
5 Alphanumeric
6 - Abbreviated
0 Unknown
1 ISDN
3 Data
4 Telex
6 Land Mobile
8 National
9 Private
10 ERMES
14 Internet
18 WAP Client Id
Integer
SMPPsubmitsourceaddr-ton
Submit
SMPPsubmitsource-
Submit
0 Unknown
1 International
2 National
3 Network
Specific
4 Subscriber
Number
5 Alphanumeric
6 - Abbreviated
0 Unknown
1 ISDN
3 Data
11
Description
The service_type parameter can be used to
indicate the SMS Application service associated
with the message.
Null can be used.
Destination Address TON. Type of Number for
destination.
Destination Address NPI. Numbering Plan

Indicator for destination.
The esm_class parameter is used to indicate

special message attributes associated with the
short message.
Supported values:
0: normal SMS
64: wap push SMS
Source Address TON. Type of Number for source
address.
Source Address NPI. Numbering Plan Indicator for

source address.
addr-npi
SMPPsubmitdatacoding
Submit
4 Telex
6 Land Mobile
8 National
9 Private
10 ERMES
14 Internet
18 WAP Client Id
Integer
Encoding of data according the SMPP 3.4

specification, section 5.2.19. Example data
encodings are SMSC Default Alphabet (0),
IA5/ASCII (1), Octet unspecified (2), Latin 1/ISO8859-1 (3), Cyrllic/ISO-8859-5 (6),
Latin/Hebrew/ISO-8859-8 (7).
Suported values:
0x00: GSM 03.38 7-bit ASCII

0x08: UCS2 ISO/IEC 10646
SMPPsubmitdatacharset
12
Submit
String
ISO8859
-1
Character set to use in conjunction with Data

Coding when converting from Unicode to output
format.
Use ISO8859-1 with coding 0
You can use any other charset with coding 8
3. Acceptance Tests
This test plan has been produced to validate the compliance of customers ESME with document
requirements for operational stability. Such compliance will normally be established prior to the
connection of such ESME to a live SMSC.
It is strongly recommended that the ESME maintains a Log file of detected errors & abnormal
conditions.
This test plan is split into 4 steps, where the first 2 of them are mandatory, and for the last two TIMWE
reserves the right of requesting for compliance from the partner:
SMPP Connectivity Tests

These tests will ensure that the ESME is able to send some SMPP primitives correctly to the SMSC IP and
port, using the previously provided ESME origin IP.
SMPP Protocol Tests

These tests will ensure that the ESME is able to send/receive all required SMPP primitives correctly
to/from the SMSC.
Performance Tests
These tests will ensure that both the ESME and SMSC are scalable enough to achieve the expected
volume.
These tests will be performed connecting to a dummy SMSC Test Program rather than a real SMSC.
Resilience Tests
These tests will ensure that the ESME behaves correctly during failure conditions on the link to the
SMSC, and operates correctly on the detection of error conditions.
These tests will ensure that the ESME can successfully switch to secondary SMSC in the event of the
primary SMSC being unavailable.
Recording results
All results from these tests should be documented at the time of testing and reviewed before the start
of the Stability Period. Any non-conformity should be fully resolved before entering the Stability Period.
13
Stability Criteria
This section gives the criteria which an ESME should fulfill to ensure stability of the applicationgenerated SMS traffic and hence the entire end-to-end system.
The ESME should first pass the SMPP Connectivity, SMPP Protocol, Performance and Resilience tests and
then enter a Stability Period. All ESME are expected to undergo the full Stability Period.
At the end of the agreed Stability Period the ESME should be verified against the Stability Criteria.
If the Stability Criteria are met then the system can be considered fit for use.
The Stability Criteria should always be tested.
Other tests in the above sections are only required for each individual operation that the ESME
involved actually intends to use.
14
4. Advanced Topics
Message priorities
TIMWE has a priority management system of SMS text messages in SMS Gateway. To use it properly, the
partner should know better the used algorithm.
Send message algorithm
In TIMWE SMS Gateway each of the users/short code has separate waiting queues. Messages that need
to be sent out will be forwarded into these waiting queues called Outbox. From the Outbox of a given
user, SMS text messages with same priority will be sent out on FCFS (First Come First Served) principle.
In some cases, the user may want to give a higher priority to a specific message (ex: user waiting for a
pin to insert on a web page). To achieve it, the user should increase the priority in message sent in SMPP
channel.
Sending WAP Push messages

WAP Push messages can be sent using the SMPP connection. The message has to be encoded as an eight
bit message. As a standard SMS can only contain 160 7-bit GSM characters, Concatenated SMS are used
to send long SMS which are bigger than 160 characters. Concatenation allows a sender to send more
than one SMS which then get stuck together automatically by the phone to appear as one message.
To indicate that the content contains a UDH, a flag on the SMS called the UDH Indicator (UDHI) must be
turned on. This tells the phone that it must separate the UDH from the rest of the content.
15
The phone separates the UDH by reading the first byte of the content. The number in this byte is the
length of the rest of UDH and is called the User Data Header Length (UDHL). The phone then knows how
many bytes make up the UDH and can separate it from the rest of the message.
A UDH is very useful because you can send "invisible text messages" to mobile application (where to
"mobile applications" I mean those running on mobile devices for example) or you can tell a device that
the message will contain special information. Its very similar to an XML file: you have to tell the parser
what you are sending, and the content following the prolog which will be handled by the parser itself.
There are two main kind of SMS systems one is Smart Messaging which is for NOKIA supported and sets
(include almost all brand except older version of Sony and Ericsson), and other one is EMS (Enhanced
messaging system), both have different type of content and UDH encoding , first with the common
between them.
1. Both have same algorithm to build UDH .
2. Data and UDH for both systems are only in hex i.e char having 0-9 or A-F.
3. Both have same Header for split messages i.e. concatenated messages,
for Nokia it goes like for each binary messages there is data and UDH part now Nokia identifies
coming binary message as ringtone, pic ,logo, etc because of port number present in its header,
lets consider full UDH of Nokia
As a practical example, say I want to create a UDH to send a WAP Push, where the standard destination
port for WAP pushes is 2948, the UDH will be:
06 05 04 0B 84 23 F0
Where:
06 means "read the following 6 bytes"

05 is the format for numbers, in this case hexadecimal numbers
04 will tell the UDH that each port is represented using 4 character
0B84 is the destination port, 2948 (decimal representation) or 0B84 (hexadecimal
representation)
23F0 is the source port, 9200 (decimal representation) or 23F0 (hexadecimal representation).
Note: Use a simple calculator to convert decimal numbers to hex; select "Dec", put 2948 in the
calculator, and then press the button "Hex". Any scientific calculator can do this and many operating
systems have a little "calc" application somewhere which can do this.
Ports
When you hit a URL in your browser such as http://www.timwe.com, you transparently call port 80 of a
web server, by convention. The connection will be initialized on port 80 and then switched to a higher
16
port to let other users access the same port of the web server. Port 80, as stated by IANA refers to the
HTTP protocol, this means that a server, which is able to understand HTTP protocol request, will be
awakened and will be ready to answer and process HTTP requests. The same happens with SMS
messages. You can send an SMS to a specific port of a phone and you will wake up a specific service on
that device. Now, just as not all the computers have standard services (such as a web server), also not all
mobile devices have services listening to ports. This is very "manufacturer related" stuff, so you will
need to check your phone what is enabled to accept.
Binary SMS
A "binary SMS" is an XML-formatted textual SMS which has been transformed with WBXML. WBXML is a
"tag transformer", this means that for each XML tag, a binary byte is associated. For example, the tag
<SI> is converted as the binary character
Easy answer: the result of a WBXML transformation is smaller in the number of generated bytes than
the verbose textual XML file itself.
Note: many tags are converted to bytes, but sometimes also contents (such as URL addresses) e.g the
URL http://www.timwe.com can be written in WBXML as 0Dtimwe.com , where "0D" stands for
http://www.
"0C" is more generic and stands for http:// so you can write the URL in two ways:
<span>0Dtimwe.com</span>
or
<span>0Cwww.timwe.com</span>
The first uses 9 chars (0D is one byte), the second 13 chars! I love WBXML :)
To be clear, by "WAP push" we do not mean a way to send SMS using WAP. What we mean is what is
technically known as SI (Service Indication). A Service Indication is a binary SMS sent to a dedicated port
on a device which informs the device that there is a URL waiting to be visited. The URL can be the
address of a ring-tone in a webserver, the address of a JAD file to install a J2ME application or a JPG or
simply a WAP page; its up to the "webmaster" of the webserver to put the contents on the web site,
and its up to the device to understand how to handle the content.
Note: When I say "web server" I mean both web and WAP server since most web servers can be
configured to deliver WAP content. By "OTA Configuration SMS" I mean a binary SMS which contains
APN details (but can contain more) also known as "Internet Access Configuration".
Note: There are special "Service Indication" messages which are normally called SL (Service Load) which
are similar to "SI". An SI asks the permission to the user before fetching the content over the network
connection, SL download contents automatically without asking permission to the user. "SL" is very
17
similar to MMS messages: the content is on a web server and the SMS tells the phone to download the
message.
First of all, we need to read some papers (alas) to read some specifications on how to write XML content
to be sent over SMS. A good start point could be the Nokias "Smart Messaging Specification 3.0.0"
which can be downloaded from www.forum.nokia.com and also more technical docs from the Open
Mobile Alliance (OMA) from www.openmobilealliance.org/tech/affiliates/wap/wapindex.html
If we want to send a J2ME application to a new phone, then we need to send a "Service Indication"
message, also known as "WAP push". This "SI" can be used to push an SMS that will be read as a link to
download something. Any content-type (image/jpeg, application/java-archive, ) is valid if the phone
can open it.
If you would like to know more details on which content-types are supported by each device you can
consult any available Device database.
We advise you to use the Device Atlas database. You can reach it at http://deviceatlas.com/.
Convert to WBXML
The XML there is pretty self-explanatory so I will do some customization directly.

<?xml version="1.0"?>
<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"
"http://www.wapforum.org/DTD/si.dtd">
<si>
<indication href=http://www.timwe.com si-id="6532">
Timwe is Fun !
</indication>
</si>
Hex code
02
05
6A
00
45
C6
0C
03
*687474703A2F2F68656C6D2E74656B6D6F622E636F6D2F70696D
18
Meaning
WBXML Version 1.2
SI 1.0 Public Identifier
Charset UTF-8
String table length = 0
<SI>
<indication>
href="http://
String starts
www.timwe.com
2F6E61747474613F267375623D313533333331303539
00
11
03
** 36353332
00
07
01
03
* 44657363617272656761206D61697320636F6E746575646F7321
00
01
01
String ends
si-id attribute
String starts
6532
String ends
Action attribute (signal - medium)
Ends of attributes, now the
content
String starts
Timwe is Fun !
String ends
</indication>
</SI>
* These are strings used to pass contents to the SI, each character in the string is converted to its hexadecimal representation.
** "6532" is to be considered a string of characters and not a number, so don't use the calculator to convert this number
Our body is, putting all the numbers together:

0045C60B03687474703A2F2F68656C6D2E74656B6D6F622E636F6D2F70696D2F6E61747474613
F267375623D3135333333313035390008010344657363617272656761206D61697320636F6E74
6575646F7321000101
Prepare the UDH
Preparing the UDH is pretty easy. Just start with "06 05 04" and then add the port numbers. WAP Push
messages uses "destination port" 2948 while source port is 9200. Convert decimal port numbers to
hexadecimal formats, so 2948 becomes 0B84 and 9200 becomes 23F0.
Magically, the UDH is: 06 05 04 0B 84 23 F0
19
5. Troubleshooting
The error codes are explained in the SMPP Error Codes table above.
Further Reading
More information or clarification can be obtained by contacting your TIMWEs account manager.
For more information on SMPP specification related subjects, visit http://smsforum.net.
6. Feedback
TIMWE is always interested in feedback from our users.
. For comments regarding TIMWE products, contact your account manager or reach us at
support@timwe.com.
. For comments regarding this technical document, contact your account manager or reach us at
micropay.support@timwe.com.
20
Appendix 1: Error Codes

If you receive an SMPP error, you can use this information to help you determine the source of the
error.
Error
ESME_ROK
ESME_RINVMSGLEN
ESME_RINVCMDLEN
ESME_RINVCMDID
ESME_RINVBNDSTS
ESME_RALYBND
ESME_RINVPRTFLG
ESME_RINVREGDLVFLG
ESME_RSYSERR
Reserved
ESME_RINVSRCADR
ESME_RINVDSTADR
ESME_RINVMSGID
ESME_RBINDFAIL
ESME_RINVPASWD
ESME_RINVSYSID
Reserved
ESME_RCANCELFAIL
Reserved
ESME_RREPLACEFAIL
ESME_RMSGQFUL
ESME_RINVSERTYP
Reserved
ESME_RINVNUMDESTS
ESME_RINVDLNAME
Reserved
ESME_RINVDESTFLAG
Reserved
ESME_RINVSUBREP
ESME_RINVESMCLASS
ESME_RCNTSUBDL
ESME_RSUBMITFAIL
Reserved
ESME_RINVSRCTON
ESME_RINVSRCNPI
21
Error Code
0x00000000
0x00000001
0x00000002
0x00000003
0x00000004
0x00000005
0x00000006
0x00000007
0x00000008
0x00000009
0x0000000A
0x0000000B
0x0000000C
0x0000000D
0x0000000E
0x0000000F
0x00000010
0x00000011
0x00000012
0x00000013
0x00000014
0x00000015
0x000000160x00000032
0x00000033
0x00000034
0x000000350x0000003F
0x00000040
0x00000041
0x00000042
0x00000043
0x00000044
0x00000045
0x000000460x00000047
0x00000048
0x00000049
Description
No Error
Message Length is invalid
Command Length is invalid
Invalid Command ID
Incorrect BIND Status for given command
ESME Already in Bound State
Invalid Priority Flag
Invalid Registered Delivery Flag
System Error
Reserved
Invalid Source Address
Invalid Dest Addr
Message ID is invalid
Bind Failed
Invalid Password
Invalid System ID
Reserved
Cancel SM Failed
Reserved
Replace SM Failed
Message Queue Full
Invalid Service Type
Reserved
Invalid number of destinations
Invalid Distribution List name
Reserved
Destination flag is invalid (submit_multi)
Reserved
Invalid submit with replace request (i.e.
submit_sm with replace_if_present_flag set)
Invalid esm_class field data
Cannot Submit to Distribution List
submit_sm or submit_multi failed
Reserved
Invalid Source address TON
Invalid Source address NPI
ESME_RINVDSTTON
Error
ESME_RINVDSTNPI
Reserved
ESME_RINVSYSTYP
ESME_RINVREPFLAG
ESME_RINVNUMMSGS
Reserved
ESME_RTHROTTLED
Reserved
ESME_RINVSCHED
ESME_RINVEXPIRY
ESME_RINVDFTMSGID
ESME_RX_T_APPN
ESME_RX_P_APPN
ESME_RX_R_APPN
ESME_RQUERYFAIL
Reserved
ESME_RINVOPTPARSTREAM
ESME_ROPTPARNOTALLWD
ESME_RINVPARLEN
ESME_RMISSINGOPTPARAM
ESME_RINVOPTPARAMVAL
Reserved
ESME_RDELIVERYFAILURE
ESME_RUNKNOWNERR
Reserved for SMPP extension
Reserved for SMSC vendor
specific errors
Reserved
22
0x00000050
Error Code
0x00000051
0x00000052
0x00000053
0x00000054
0x00000055
0x000000560x00000057
0x00000058
0x000000590x00000060
0x00000061
0x00000062
0x00000063
0x00000064
0x00000065
0x00000066
0x00000067
0x000000680x000000BF
0x000000C0
0x000000C1
0x000000C2
0x000000C3
0x000000C4
0x000000C50x000000FD
0x000000FE
0x000000FF
0x000001000x000003FF
0x000004000x000004FF
0x000005000xFFFFFFFF
Invalid Destination address TON

Description
Invalid Destination address NPI
Reserved
Invalid system_type field
Invalid replace_if_present flag
Invalid number of messages
Reserved
Throttling error (ESME has exceeded allowed
message limits)
Reserved
Invalid Scheduled Delivery Time
Invalid message validity period (Expiry time)
Predefined Message Invalid or Not Found
ESME Receiver Temporary App Error Code
ESME Receiver Permanent App Error Code
ESME Receiver Reject Message Error Code
query_sm request failed
Reserved
Error in the optional part of the PDU Body.
Optional Parameter not allowed
Invalid Parameter Length.
Expected Optional Parameter missing
Invalid Optional Parameter Value
Reserved
Delivery Failure (used for data_sm_resp)
Unknown Error
Reserved for SMPP extension
Reserved for SMSC vendor specific errors
Reserved

SMPP Integration Document Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SMPP Integration Document Guide

Uploaded by

Copyright:

Available Formats

SMPP Partner Integration User Guide

Further clarification on Manual

Prepare the UDH ........................................................................................................................... 19

External Short Message Entity generally Connection Softwares customers system

The message ID is returned in the submit_sm_resp PDU as a number (long).

SMPP Optional Parameters

TLV Stands for Tag-Length-Value field;

TON and NPI

Numbering Plan Indicator for ESME address.

Follows the Submit configuration properties:

Destination Address NPI. Numbering Plan

The esm_class parameter is used to indicate

Source Address NPI. Numbering Plan Indicator for

Encoding of data according the SMPP 3.4

0x00: GSM 03.38 7-bit ASCII

Character set to use in conjunction with Data

SMPP Connectivity Tests

SMPP Protocol Tests

Sending WAP Push messages

06 means "read the following 6 bytes"

The XML there is pretty self-explanatory so I will do some customization directly.

Our body is, putting all the numbers together:

Prepare the UDH

Appendix 1: Error Codes

Invalid Destination address TON

You might also like