SMPP Integration Document Guide

1 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

SMPP Partner Integration User Guide eBrokerage Platform


Version Control

Version Date Author Changes

V0.1 25-08-2011 José Ribeiro Initial Version.

V1.0 01-11-2011 João 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 External Short Message Entity – generally Connection Software’s customer’s system PDU Protocol Description Units SMPP Short Message Peer to Peer SMSC Short Message Service Centre – generally the Connection Software systems

MO Mobile originated MT Mobile Terminated


Introduction

This document provides the developers with instructions how to configure the short message peer-to-

peer 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 (PDU’s):

• 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 PDU’s 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

bind_transceiverOpen

bind_transceiver_resp

Bound_RXsubmit_sm

submit_sm_respsubmit_sm

submit_sm_resp

deliver_smdeliver_sm_resp

unbindunbind_resp

UnboundConnection 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

We’ve 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 Default Value

Description

SMPP-version

Bind 51 – 3.3 52 – 3.4

51

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

SMPP-timeout

Connect Integer 10000 Timeout (in milliseconds) used when trying to communicate with SMPP server. The default value may be used.

SMPP-bind-system-type

Bind String null 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.

SMPP-bind-addr-ton

Bind 0 – Unknown 1 – International 2 – National 3 – Network Specific 4 – Subscriber Number 5 – Alphanumeric 6 - Abbreviated

0 Indicates Type of Number of the ESME address. See TON and NPI section for more details.

SMPP-bind-addr-npi

Bind 0 – Unknown 1 – ISDN 3 – Data 4 – Telex 6 – Land Mobile 8 – National 9 – Private 10 – ERMES 14 – Internet 18 – WAP Client Id

0 Numbering Plan Indicator for ESME address. See TON and NPI section for more details.


Follows the Submit configuration properties:

Key Used at Possible Values Default Value

Description

SMPP-submit-service-type

Submit String null The service_type parameter can be used to indicate the SMS Application service associated with the message. Null can be used.

SMPP-submit-dest-addr-ton

Submit 0 – Unknown 1 – International 2 – National 3 – Network Specific 4 – Subscriber Number 5 – Alphanumeric 6 - Abbreviated

1 Destination Address TON. Type of Number for destination. See TON and NPI section for more details.

SMPP-submit-dest-addr-npi

Submit 0 – Unknown 1 – ISDN 3 – Data 4 – Telex 6 – Land Mobile 8 – National 9 – Private 10 – ERMES 14 – Internet 18 – WAP Client Id

0 Destination Address NPI. Numbering Plan Indicator for destination. See TON and NPI section for more details.

SMPP-submit-esm-class

Submit Integer 0 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

SMPP-submit-source-addr-ton

Submit 0 – Unknown 1 – International 2 – National 3 – Network Specific 4 – Subscriber Number 5 – Alphanumeric 6 - Abbreviated

0 Source Address TON. Type of Number for source address. See TON and NPI section for more details.

SMPP-submit-source-

Submit 0 – Unknown 1 – ISDN 3 – Data

0 Source Address NPI. Numbering Plan Indicator for source address. See TON and NPI section for more details.


addr-npi 4 – Telex 6 – Land Mobile 8 – National 9 – Private 10 – ERMES 14 – Internet 18 – WAP Client Id

SMPP-submit-data-coding

Submit Integer 0 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/ISO-8859-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

SMPP-submit-data-charset

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 customer’s 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.


Stability Criteria

This section gives the criteria which an ESME should fulfill to ensure stability of the application-generated 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.


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.


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. It’s 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,

let’s 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


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; it’s up to the "webmaster" of the webserver to put the contents on the web site,

and it’s 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


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 Nokia’s "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 Meaning 02 WBXML Version 1.2 05 SI 1.0 Public Identifier 6A Charset UTF-8 00 String table length = 0 45 <SI> C6 <indication> 0C href="http:// 03 String starts *687474703A2F2F68656C6D2E74656B6D6F622E636F6D2F70696D www.timwe.com

http://www.forum.nokia.com/

http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html

http://deviceatlas.com/


2F6E61747474613F267375623D313533333331303539

00 String ends 11 si-id attribute 03 String starts ** 36353332 6532 00 String ends 07 Action attribute (signal - medium) 01 Ends of attributes, now the

content 03 String starts * 44657363617272656761206D61697320636F6E746575646F7321 Timwe is Fun ! 00 String ends 01 </indication> 01 </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


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 TIMWE´s 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

[email protected].

. For comments regarding this technical document, contact your account manager or reach us at

[email protected].

http://smsforum.net/

mailto:[email protected]


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 Error Code Description

ESME_ROK 0x00000000 No Error ESME_RINVMSGLEN 0x00000001 Message Length is invalid ESME_RINVCMDLEN 0x00000002 Command Length is invalid ESME_RINVCMDID 0x00000003 Invalid Command ID ESME_RINVBNDSTS 0x00000004 Incorrect BIND Status for given command ESME_RALYBND 0x00000005 ESME Already in Bound State ESME_RINVPRTFLG 0x00000006 Invalid Priority Flag ESME_RINVREGDLVFLG 0x00000007 Invalid Registered Delivery Flag ESME_RSYSERR 0x00000008 System Error Reserved 0x00000009 Reserved ESME_RINVSRCADR 0x0000000A Invalid Source Address ESME_RINVDSTADR 0x0000000B Invalid Dest Addr ESME_RINVMSGID 0x0000000C Message ID is invalid ESME_RBINDFAIL 0x0000000D Bind Failed ESME_RINVPASWD 0x0000000E Invalid Password ESME_RINVSYSID 0x0000000F Invalid System ID Reserved 0x00000010 Reserved ESME_RCANCELFAIL 0x00000011 Cancel SM Failed Reserved 0x00000012 Reserved ESME_RREPLACEFAIL 0x00000013 Replace SM Failed ESME_RMSGQFUL 0x00000014 Message Queue Full ESME_RINVSERTYP 0x00000015 Invalid Service Type Reserved 0x00000016-

0x00000032 Reserved

ESME_RINVNUMDESTS 0x00000033 Invalid number of destinations ESME_RINVDLNAME 0x00000034 Invalid Distribution List name Reserved 0x00000035-

0x0000003F Reserved

ESME_RINVDESTFLAG 0x00000040 Destination flag is invalid (submit_multi) Reserved 0x00000041 Reserved ESME_RINVSUBREP 0x00000042 Invalid ‘submit with replace’ request (i.e.

submit_sm with replace_if_present_flag set) ESME_RINVESMCLASS 0x00000043 Invalid esm_class field data ESME_RCNTSUBDL 0x00000044 Cannot Submit to Distribution List ESME_RSUBMITFAIL 0x00000045 submit_sm or submit_multi failed Reserved 0x00000046-

0x00000047 Reserved

ESME_RINVSRCTON 0x00000048 Invalid Source address TON ESME_RINVSRCNPI 0x00000049 Invalid Source address NPI


ESME_RINVDSTTON 0x00000050 Invalid Destination address TON Error Error Code Description ESME_RINVDSTNPI 0x00000051 Invalid Destination address NPI Reserved 0x00000052 Reserved ESME_RINVSYSTYP 0x00000053 Invalid system_type field ESME_RINVREPFLAG 0x00000054 Invalid replace_if_present flag ESME_RINVNUMMSGS 0x00000055 Invalid number of messages Reserved 0x00000056-

0x00000057 Reserved

ESME_RTHROTTLED 0x00000058 Throttling error (ESME has exceeded allowed message limits)

Reserved 0x00000059-0x00000060

Reserved

ESME_RINVSCHED 0x00000061 Invalid Scheduled Delivery Time ESME_RINVEXPIRY 0x00000062 Invalid message validity period (Expiry time) ESME_RINVDFTMSGID 0x00000063 Predefined Message Invalid or Not Found ESME_RX_T_APPN 0x00000064 ESME Receiver Temporary App Error Code ESME_RX_P_APPN 0x00000065 ESME Receiver Permanent App Error Code ESME_RX_R_APPN 0x00000066 ESME Receiver Reject Message Error Code ESME_RQUERYFAIL 0x00000067 query_sm request failed Reserved 0x00000068-

0x000000BF Reserved

ESME_RINVOPTPARSTREAM 0x000000C0 Error in the optional part of the PDU Body. ESME_ROPTPARNOTALLWD 0x000000C1 Optional Parameter not allowed ESME_RINVPARLEN 0x000000C2 Invalid Parameter Length. ESME_RMISSINGOPTPARAM 0x000000C3 Expected Optional Parameter missing ESME_RINVOPTPARAMVAL 0x000000C4 Invalid Optional Parameter Value Reserved 0x000000C5-

0x000000FD Reserved

ESME_RDELIVERYFAILURE 0x000000FE Delivery Failure (used for data_sm_resp) ESME_RUNKNOWNERR 0x000000FF Unknown Error Reserved for SMPP extension 0x00000100-

0x000003FF Reserved for SMPP extension

Reserved for SMSC vendor specific errors

0x00000400-0x000004FF

Reserved for SMSC vendor specific errors

Reserved 0x00000500-0xFFFFFFFF

Reserved

Documents

SMPP Integration Document Guide