VIDEOSMS SMPP Interface Manual v. 1.

VideoSMS

VIDEOSMS SMPP Interface Manual

How to interconnect your SMPP server
with MCTEL SMS gateway

Version: 1.2
Date: August 25, 2004

MONACO TELEMATIQUE MC-TEL

25, boulevard d'Italie, B.P. 225, MC 98004 MONACO Cedex
Phone: (+377) 9216 8888
Fax: (+377) 9216 8865
SMS technical support email: sms@mctel.net sales email: sales@mctel.fr
Web: http://www.mctel.net and http://www.smsfax.com

Monaco Telematique MCTEL 1 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Other documents
This manual is part of the VideoSMS documentation. VideoSMS is an integrated mobile
messaging and server solution allowing the sending of SMS and other message types (fax,
telex, email, voice), the checking of their successful transmission, the building of Premium
SMS applications with high value added contents.

Other manuals of the VideoSMS documentation include:

• the manuals of the client/server SMS interface and development tools:
o The HTTP/HTML Interface is described in the "VideoSMS HTTP/HTML
Interface Manual".
o The FTP/XML Interface is described in the "VideoSMS FTP/XML Interface
Manual".
o The VideoSMS Application Programming Interface is described in the
"VideoSMS Application Programming Interface Functions Manual" and in the
guide "How to develop with VideoSMS Interfaces and API".
• the VideoSMS/Gateway SMS server and messaging platform has its own complete
documentation set (installation, management, development tools).

Monaco Telematique MCTEL also supplies other messaging and network software:
• Fax gateways (VideoTelefax), telex gateways (Videotélex), pagers (VideoAlphaPage).
• Videotex servers (VideoNet) and gateways (VTX/Gate), multimedia servers
(EuroVemmi).
• Advanced firewall solutions (WebAccess).

Proprietary Information
The information contained in this document is the property of Monaco Telematique MCTEL
and may be the subject of patents pending or granted, and must not be copied or disclosed
without prior written permission.

Monaco Telematique MCTEL endeavours to ensure that the information in this document is
correct but does not accept liability for any error or omission.

The development of Monaco Telematique MCTEL products and services is continuous and
published information may not be up to date. It is recommended to check the latest manual
release with Monaco Telematique MCTEL or on http://www.smsfax.com

Document Revision
Rev Date By Detail
1.0 01-MAR-04 DM First release
1.1 15-MAY-04 DM Minor changes and improvements
1.2 25-AUG-04 DM, EL Individual manual for SMPP interface

Monaco Telematique MCTEL 2 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Contents

Other documents........................................................................................................................ 2
Proprietary Information............................................................................................................ 2
Document Revision.................................................................................................................... 2
Contents ..................................................................................................................................... 3
Introduction ............................................................................................................................... 5
Introduction .......................................................................................................................... 5
The SMPP Protocol.............................................................................................................. 5
Other SMS development tools............................................................................................. 6
SMPP Protocol ................................................................................................................... 7
HTTP/HTML Web Interface.............................................................................................. 7
The FTP/XML FPI (File Programming Interface)............................................................. 7
The SMS API (Application Programming Interface) ........................................................ 7
SMTP email Interface ........................................................................................................ 8
VIDEOSMS/PC Software .................................................................................................. 8
Glossary................................................................................................................................. 8
SMPP setup and validation..................................................................................................... 10
Prerequisites for SMPP interconnect ............................................................................... 10
Validation phase ................................................................................................................. 10
Using MCTEL SMPP Gateway .............................................................................................. 12
SMPP SMS Gateway configuration.................................................................................. 12
MCTEL SMSC architecture............................................................................................. 12
Firewall............................................................................................................................. 12
Supported versions and PDUs........................................................................................... 13
Supported TLV................................................................................................................... 14
Connecting to the MCTEL SMS SMPP Gateway........................................................... 15
TCP/IP connection ........................................................................................................... 15
X.25 connection ............................................................................................................... 16
SMPP binding..................................................................................................................... 16
Keep-alive............................................................................................................................ 16
Burst traffic and throttling................................................................................................ 17
Parameters for submit_sm PDU ....................................................................................... 17
Sending large size SMS ...................................................................................................... 19
Using character sets ........................................................................................................... 19
Specifying sender identification ........................................................................................ 20
Delivery Notification Format ............................................................................................ 20

Monaco Telematique MCTEL 3 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

ID...................................................................................................................................... 20
Status ................................................................................................................................ 20
Error ................................................................................................................................. 21
Status and error information TLV.................................................................................... 21
Unbinding............................................................................................................................ 21
SMS-MO management when Receiver/Transceiver not connected .............................. 21
Examples ............................................................................................................................. 22
Data security ....................................................................................................................... 22
Firewalls to access smppgateway.mctel.com................................................................... 22
User Authentication.......................................................................................................... 22
Data Encryption................................................................................................................ 22
Appendix 1: Example of SMPP requests................................................................................ 24
Appendix 2 – Error status listing ............................................................................................ 26
Appendix 3 – GSM default alphabet....................................................................................... 28
The 7 bits default GSM alphabet ...................................................................................... 28
GSM 7 bit default alphabet extension table ................................................................. 29
Converting ISO 8859-1 (International Reference Alphabet IRA) to GSM .................. 29

Monaco Telematique MCTEL 4 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Introduction

Introduction

Using MCTEL offer, integrating SMS features to any computer application or Web
service is very easy and could be setup almost immediately. Several methods could be used
to send the SMS (all documents could be downloaded from http://www.smsfax.com ):
• SMPP protocol between your server and MCTEL SMS gateway, described in this
document.
• FTP/XML file interface, described in the "VideoSMS FTP/XML Interface Manual".
• HTTP/HTML Web interface, documented in the "VideoSMS HTTP/HTML Interface
Manual".
• SMTP email interface.
• The VideoSMS Application Programming Interface (API), described in the
"VideoSMS Application Programming Interface Functions Manual".

This manual is destined to specialized readers having already a good knowledge of mobile
networks and SMS.

Please refer to other MCTEL documents for more general information about SMS.

Purpose

The purpose of this document is to guide MCTEL customers on the SMPP requirements
whilst connecting to the MCTEL SMPP gateways.

Scope

The scope of the document is to define how MCTEL SMPP implementation (offered by
VIDEOSMS/Gateway SMPP Interface) compare to the SMPP specifications (v. 3.3 to v.5.0).

The SMPP Protocol

SMPP stands for Short Message Peer to Peer. It is an open industry standard messaging
protocol, relatively easy to implement, allowing a SMS client system to connect to a SMS
Gateway (e.g. MCTEL gateway) to access mobile networks in order to send and receive SMS
messages to/from mobile recipients.

SMPP is widely used in the mobile telecommunications industry, several versions are
available, all supported by MCTEL software:
• SMPP version 3.3: "Short Message Peer to Peer (SMPP) Interface Specification",
v.3.3, 14-Jan-1996, Aldiscon Ltd (now Logica plc.).

Monaco Telematique MCTEL 5 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

• SMPP version 3.4: "Short Message Peer to Peer Protocol Specification", v3.4, 12-
Oct-1999, Issue 1.2, SMPP Developers Forum.
• SMPP version 5.0: "Short Message Peer to Peer Protocol Specification", version 5.0,
19-Feb-2003, SMS Forum.

All those specifications are available from http://smsforum.net/doc/public/Spec

MCTEL recommends using SMPP protocol in the following cases:

• you already have a SMPP interface linked to an operator and want to keep the existing
architecture.
• you have purchased a SMPP software from a well-known supplier (e.g. MCTEL).
• you intend to connect to several SMS gateways (such MCTEL gateway and other)
simultaneously and want to use a single standardized protocol for all of them.

Figure 1: Example of SMPP usage in a SMS network (reprinted from SMPP Specification v. 5.0)

Other SMS development tools

Several development tools are at your disposal to process SMS :

• the SMPP protocol described in this document. It requires you run a SMPP compatible
SMS server software on your host system.
• the FTP/XML file interface described in the "VideoSMS FTP/XML Interface Manual".
• the HTTP/HTML Web interface, documented in the "VideoSMS HTTP/HTML
Interface Manual".
• the SMTP email interface.
• The VideoSMS Application Programming Interface (API), described in the
"VideoSMS Application Programming Interface Functions Manual".

Monaco Telematique MCTEL 6 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

• the VideoSMS/PC Desktop SMS sender, with Outlook and Exel integration, is also
available.

SMPP Protocol

The SMPP protocol describe the interworking between a SMPP server and a SMPP gateway
in order to allow the SMPP server to send SMS-MT messages to mobile users through the
SMPP gateway and to receive SMS-MO incoming messages from mobile users.

Several SMPP versions exist (3.3, 3.4, 5.0) and are currently in operation.

HTTP/HTML Web Interface

This interface is very simple to use, either from a computer application or a Web service: a
simple HTTP GET or POST request with appropriate attributes to the MCTEL SMS Gateway
allows either to send a SMS message or to check its successful transmission. Please refer to
the "VideoSMS HTTP/HTML Interface Manual" for this interface specification.

The FTP/XML FPI (File Programming Interface)

This interface is well suited to the one-time bulk transmission of numerous SMS. Data
specifying the SMS to be transmitted are store in XML format text files, easy to create from
any computer application. The text files are transmitted by FTP to the VideoSMS FTP
gateway. Please refer to the "VideoSMS FTP/XML Interface Manual" for this interface
specification.

The SMS API (Application Programming Interface)

The VideoSMS Application Programming Interface includes functions to be linked with your
computer applications, complete documentation, include files, and examples. Releases are
available for each supported operating systems:
• Windows.
• Unix:
o Linux.
o HP HP-UX
o HP/Compaq/Digital True64 Unix.
o IBM AIX
o Sun Solaris
o Unix-SCO
• OpenVMS: Alpha, VAX or Itanium.

The VideoSMS Application Programming Interface is described in the "VideoSMS

Application Programming Interface Functions Manual" and in the guide "How to develop
with VideoSMS Interfaces and API".

Monaco Telematique MCTEL 7 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

SMTP email Interface

You could also send SMS directly by email using the VideoSMS STMP Gateway, from any
mail sender.

VIDEOSMS/PC Software

If you do not want to integrate SMS features in your computer application or Web service, but
simply use an easy to use PC application with Outlook integration to send SMS, you could
download and install the free VideoSMS/PC SMS Desktop sender from www.smsfax.com.

Glossary

• Alias : in several countries, on Premium SMS services, the user mobile number
(MSISDN) is masked by the operator and replaced by an unique alias number, in order
to avoid the creation of unauthorized mobile numbers databases for marketing
purposes byh the information provider.
• EMSE = External Short Message Entity: Network element sending and/or receiving
SMS by interworking (e.g. with SMPP) with mobile network SMS-C.
• Short code : abbreviated number (usually from 4 to 6 digits) allocated to a SMS
server running Premium SMS applications and allowing the user to send his/her
message to a short code easy to remember instead of a 10 digits full mobile number.
• OTA (Over the Air) : this technology is used to download binary data to a mobile
phone, for example : logos, ringtones, email or Wap configuration download by the
mobile operator, SIM card customization by mobile network operator.
• PDU: Protocol Data Unit: request or answer SMPP command block.
• Push-SMS : sending an unsolicited SMS-MT to a mobile user.
• SMS = Short Message Service : short text or binary message exchanged between two
mobile phones1 or a mobile phone and a computer application.
• SMS-C : SMS Service Center : is the SMS transmission platform run by the mobile
operator. It uses a specific protocol to exchange SMS messages between mobile
phones and the VIDEOSMS software (either installed on a customer system or run by
the Monaco Telematique shared host center). The SMS-C use a store and forward
technology allowing it to store a message until a given mobile phone becomes
reachable. Monaco Telematique VIDEOSMS software is able to interwork with any
SMS-C worldwide.
• SMS-MO (Mobile Originated) : SMS sent from a mobile phone.
• SMS-MT (Mobile Terminated) : SMS sent to a mobile phone.
• TLV: Tag/Length/Value, optional parameter for SMPP PDU.
• UDH = User Data Header: binary header at the beginning of the SMS User Data
field used to specify network or message options.
• UDHI = User Data Header Indicator: flag set to specify the SMS message include at
the beginning a valid UDH.
• WAP = Wireless Application Protocol

1
In numerous countries, it is also possible to send and receive SMS message from ordinary or advanced phones
connected to the switched telephonic network.

Monaco Telematique MCTEL 8 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Monaco Telematique MCTEL 9 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

SMPP setup and validation

Prerequisites for SMPP interconnect

The following prerequisites must be met before using SMPP protocol between your server
and MCTEL SMS Gateway:
• your server must have a SMPP-compliant SMS software server installed.
• you must be a MCTEL customer and have subscribed as a LA (Large Account). Only
corporate large accounts are allowed to connect using SMPP protocol.
• your SMPP software must be:
o either provided by a major manufacturer in the field (e.g. Logica, MCTEL, and
so on.).
o or already tested and operational over links to another SMS operator or first
checked by MCTEL over a temporary link to our test SMPP gateway.
• If your network is secured by a firewall, it must be configured to allow SMPP
outgoing calls to the SMPP SMS gateway of Monaco Telematique, on the SMPP port
supplied by MCTEL.
• MCTEL must also open the TCP/IP address of the calling system in our firewalls.

SMPP Request/Response
IIIIIIIIIIIIIIIIIII
IIIIIIIIIIIIIIIIIII
IIIIIIIIIIIIIIIIIII
IIIIIIIIIIIIIIIIIII
VAX 6240

IIIIIIIIIIIIIIIIIII
IIIIIIIIIIIIIIIIIII
IIIIIIIIIIIIIIIIIII
IIIIIIIIIIIIIIIIIII
IIIIIIIIIIIIIIIIIII

IIIIIIIIIIIIIIIIIII
IIIIIIIIIIIIIIIIIII
SMPP Indication/Confirm
IIIIIIIIIIIIIIIIIII
IIIIIIIIIIIIIIIIIII

Customer client MCTEL VIDEOSMS

SMPP application SMPP Gateway

Figure 2: MCTEL VideoSMS gateway communication using SMPP protocol

Validation phase

If your SMPP software has not been supplied by MCTEL or other well-known manufacturer
and validated in a running environment, you will have first to undergo a validation phase on
our test SMPP gateway before being allowed to connect to our live gateways, in order to
eliminate any obvious problem. The test SMPP gateway will allow you to send messages but
offer a lower throughput.

The following conditions are tested during the compliance test:

Monaco Telematique MCTEL 10 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

• the SMPP client software binds correctly to the gateway using either bind_transmitter
or bind_tranceiver.
• the client software issues a single bind attempt for a tranceiver or a couple of
transmitter/receiver (multiple binds not allowed).
• the client software manage correctly a disconnection from our SMPP server and will
automatic rebind when disconnected from our gateway in a timeframe < 5 mn.
• the enquire_link interval is set to 60 seconds (less than 90 seconds).
• correct management of SMPP sequence numbers.
• correct PDU formatting, PDU exchange and SMPP client sofware behavior for at least
the following PDU:
o bind/unbind.
o enquire_link/enquire_link_resp.
o submit_sm/submit_sm_resp.
o deliver_sm/deliver_sm_resp.

Those tests will be followed by a 1 week stability period of the application on the validation
SMPP Gateway.

If problem become apparent during this cycle, MCTEL may recommend that the application
be returned to the development phase.

Monaco Telematique MCTEL 11 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Using MCTEL SMPP Gateway

SMPP SMS Gateway configuration

MCTEL SMSC architecture

The connectivity to the MCTEL and international SMSCs is provided via the MCTEL Mobile
Gateway Access (MGA) which is responsible for loadsharing the messages and determining
the routing of the messages. The options available to connect to the SAG are via a fixed line,
an X.25 connection or the Internet (usually Internet is used). In normal operation, all SMS
gateways carry live traffic at any time.

Service Provider

SMPP Receiver PDU SMPP Transmitter PDU

Internet

F/W

MGA

SMSC1 SMSC2 SMSC3

The MGA consists of a pair of clustered servers, with a network of routers and switches thus
presenting a single IP address to the customers and allowing service resiliency in case of
failure.

Internet Access through Firewalls

For the Service Provider to be able to connect into the SMPP gateway, access for the Service
Provider’s server IP address must be set up in the MCTEL Firewall(s). The customer must
also configure its own firewall(s) in order to allow outgoing access to MCTEL SMPP server
address.

Monaco Telematique MCTEL 12 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

It is the responsibility of the Service Provider to notify MCTEL of any change in the public IP
address of the Service Provider server. At least one-week notice prior to the change must be
given to have guaranteed access after the switch over.

SMS Server
ru nn in g SMPP
ap p licat io n
Customer MCTEL SM SC
firewall firewall
Router Router
TCP/I P TCP/I P TCP/I P TCP/I P
Internet

Cu sto mer LAN

X.25 Access

The customer may also access MCTEL SMPP SMS Gateway through an X.25 line, providing
his SMPP software supports native X.25 links.

PC/Server
running SMPP
application
SMSC
X.25 interface X.25 Public X.25 X.25 X.25
network
X.25 X.25
modem modem

Supported versions and PDUs

When using the SMPP protocol, the customer computer application will communicate with
MCTEL SMPP SMS Gateway by exchanging SMPP PDU (Protocol Data Units) with the
requests to be processed.

Requests are available to perform various kind of operations:

• authentication
• sending and receiving SMS messages.
• retrieving detailed status of a SMS message previously submitted.

The table below lists the supported PDU for all supported SMPP versions. Supported PDU
are marked with a z, the PDUs that do not exist in a given SMPP version are filled with grey.

Monaco Telematique MCTEL 13 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

PDU 3.3 3.4 5.0 Comments

Client to server
bind_transmitter z z z
bind_receiver z z z
bind_transceived z z Use of bind_transceiver is recommended
(please note this PDU is not supported by
SMPP 3.3 protocol).
submit_sm z z z
submit_multi
enquire_link z z z Set the enquire_link interval to 60 seconds
deliver_sm_resp z z z
query_last_message This command is now obsolete
query_sm z z z
cancel_sm
replace_sm
data_sm
broadcast_sm and broadcast ancillary operations
alert_notification
unbind z z z
Server to client
bind_transmitter_resp z z z
bind_receiver_resp z z z
bind_transceiver_resp z z z
submit_sm_resp z z z
submit_multi_resp
enquire_link_resp z z z
deliver_sm z z z
query_sm_resp z z z
cancel_sm_resp
replace_sm_resp
data_sm_resp
broadcast_sm_resp and broadcast ancillary operations
generic_nack z z z

Supported TLV

The following optional TLV are supported (TLV mechanism have been introduced only from
SMPP 3.4, TLV must not be specified when using a lower SMPP version).

Monaco Telematique MCTEL 14 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

TLV Usage Comments

additional_status_info_text textual description of the
meaning of a response PDU
billing_identification contains the billing information
for this message
dest_addr_subunit
destination_port destination address port number
message_payload contains the user data to be
transmitted
message_state final message state for an
SMSC delivery receipt
network_error_code indicate the actual network
error code for a delivery failure
receipted_message_id ID of the message being
receipted in an SMSC delivery returned by the submit_sm_resp
receipt
sar_msg_ref_num used to specify concatenation
sar_total_segments information
sar_segment_seqnum
sc_interface_version specify the SMPP version
supported
source_port source application port number
user_message_reference private reference assigned by
sender application
used to convey detailed
information about errors
SMPP v. 5.0 only
mainly used to specify flash
messages
Use of message_payload is
mandatory when message size
exceed 254 octets
match the message identifier
PDU, also specified in the
delivery receipt text
Usually not needed as the
SMPP gateway will manage by
itself the message splitting and
concatenation and built
appropriate UDH
value and SMPP behavior
adjusted automatically to match
caller SMPP version

Connecting to the MCTEL SMS SMPP Gateway

TCP/IP connection

The client should open a SMPP link to the VIDEOSMS SMPP Gateway and wait for the
gateway response before issuing the SMPP bind_transmitter or bind_transceiver command.

The following address is used to connect to the gateway:

• smppgateway.mctel.fr

The calls should be made to the symbolic DNS name of the SMPP gateway
(smppgateway.mctel.fr) instead of its IP address because several systems offering load
balancing and fault tolerant configuration and used and because furthermore the IP address of
the gateways are subject to change without prior notice.

Monaco Telematique MCTEL 15 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Optionally, a Virtual Private Network (VPN) may be setup between your network and
MCTEL network in order to provide additional safety using data encryption.

X.25 connection

On request, the connection may also be performed over X.25 network for better performances
and additional data confidentiality.

SMPP binding

Only one Receiver/Transmitter pair or one Transceiver per SMPP account can be bound into
the SMPP MCTEL Gateway at any time. Multiple connections are not allowed. MCTEL
recommends you use when possible a single Transceiver connection instead of a pair of
Receiver/Transmitter connections.

The SMPP login on the gateway performed by the bind_transmitter or bind_transceived

command must use the username and password supplied to you by MCTEL. The addr_range
parameter must be set to NULL (x00).

The MCTEL SMPP Gateway simultaneously supports SMPP version 3.3, 3.4 and 5.0 and will
automatically exchange the corresponding PDU according the value of the interface_version
parameter in the bind operation:
• interface_version < 0x34: SMPP v. 3.3
• interface_version = 0x34: SMPP v. 3.4
• interface_version = 0x50: SMPP v. 5.0

The time-out for a connection request should be set to at least 30s. For other commands not
mentioned in this section, the time-out suggested is 10s.

If a connection request fails, it should be re-attempted every minute for five minutes and then
every five minutes thereafter. The failure to connect should be alarmed and if thought to be
due a fault with MCTEL’s infrastructure, it should reported through the agreed support
channels.

Keep-alive

Upon binding in the Receiver/Transmitter/Transceiver, the session should be kept alive and its
integrity monitored by sending enquire_link messages are regular intervals. The enquire_link
time should be set to 60 secondes. This means that enquire_link commands should be sent
after every 60 seconds on inactivity in the session (the SMPP Gateway timeout is set to 120
seconds by default and the client timer must be lower to take in account possible delays
during transmission over TCP/IP or X.25 networks).

If the enquire_link_resp response is not received within a certain period (we suggest 15s), the
connection should be assumed terminated and should be closed then reinitiated.

Monaco Telematique MCTEL 16 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Burst traffic and throttling

The MCTEL Gateway offers windowing (default window = 5) and each customer SMPP
client is throttled by default at 5 messages/second. That means the Service Provider must not
broadcast MT messages from its applications to different handsets with rates higher than 5
message/second. The effective rate may be lower depending on the speed and quality of the
link between MCTEL and the customer.

For some applications (ex: real time Premium voting applications), the SMS-MO and SMS-
MT throughput must be higher. In this case, the throttling value of the account could be
adjusted. A subscription extension must be purchased from MCTEL and also usually from the
network operator(s) onto the Premium shortcodes are connected.

Parameters for submit_sm PDU

The following parameters must be set for the submit_sm PDU, optional TLV could be
specified:

Parameter Value Comments

Mandatory Parameters
service_type =0
source_addr_ton Type of Number = 1
source_addr_npi
source_address Not needed. However, you could
specify either a numeric address
(source_addr_ton = 1 and
source_addr_npi = 1) or an alpha tag
of up to 11 alphanumeric characters
(source_addr_ton = 5 and
source_addr_npi = 0).
dest_addr_ton Type of Number:
• 1: International number: to be
used for all non-Premium
operation
• 2: only used for Premium
National aliased number
dest_addr_npi Numbering plan indicator = 1
destination_address Recipient mobile number in
international format (may also be a
fax number)
Do not use
0: Unknown or not specified
1: International numberic address
5: Alphanumeric
Not used
Transmission of such a customized
sender address is not warranted and
depends of the network and route
used. In some cases, the
specification of this information may
increase the SMS cost, as a more
expensive route may have to be
selected for SMS transmission in
order to ensure transmission of this
information.
Use always 1 as type for all non-
Premium Push-SMS operation,
where destination_address is
specified in international format.
Type 2 must be used for Premium
operations with aliased numbers.
Usually 1 (may be 4 for Telex)
Preceded by country code without +
or 00, for example 33612345678.
For Premium requests using aliased
number, specify the complete alias
number without country code.

Monaco Telematique MCTEL 17 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

esm_class The following bits may be Application is responsible for

positionned: building a valid UDH. In this case, it
• bit 6 (64): UDHI indicator: is prohibited to use TLV for
the message includes at the specification of the concatenation
beginning a User Data information or port numbers, all
Header built be the these informations are to be
application correctly encoded in the supplied
UDH.
protocol_id Type of message to send : The SMPP center has fax and telex
• 0 : SMS (default) capabilities (the LA account must
• 1 : Telex have access to those features
• 2: Fax (G3) enabled).
• 14: email
priority_flag =0 Not used
schedule_delivery_time Deferred delivery date/time for
deferred messages, format SMPP
time.
validity_period Message expiration date : the SMSC default validity period is
message will be discarded if the usually 3 days (72 hours)
delivery could not succeed before the
expiration date. Encoded as above
registered_delivery Delivery receipt : Usually set to 1
• 0: no SMSC delivery receipt
requested
• 1: SMSC delivery receipt
requested where final
delivery outcome is delivery
success or failure.
replace_if_present_flag = 0 Not used
data_coding Encoding alphabet: Usually 1
• 0: SMS
• 1: ISO 8859-1 (Iso Latin 1)
• 2: binary data
sm_default_msg_id =0 Not used
sm_length Length of short_message, up to 254 For messages larger than 254 octets,
octets. store the message content in the
message_payload TLV and set the
sm_length to 0.
short_message Content of the message :
• Text message, encoded
according selected character
set.
• Message with binary payload

The SMPP gateway will return a submit_sm_resp PDU with the unique systemwide
message_id of 32 hexadecimal characters assigned to the message (when SMPP 3.3 is used,
the message_id only contains 8 hexadecimal characters and is not unique systemwide but
customer specific).

The optional TLV are supported by the submit_sm command:

• dest_addr_subunit: for example, set to 1 to display the SMS in flash mode.
• dest_port and source_port are used for binary messages.

Monaco Telematique MCTEL 18 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

• the use of concatenation TLV is possible but not recommended as the SMPP gateway
manage the concatenation itself.

Sending large size SMS

A single text SMS message could not exceed 160 characters (80 when Unicode alphabet is
used for non-latin language), and a single binary SMS message could not exceed 140 bytes. It
is nevertheless possible to send bigger SMS messages: they will be automatically split into
several smaller messages and concatenated by the recipient mobile phone.

The SMPP gateway will automatically take charge of the SMS splitting and concatenation and
build the needed UDH including concatenation information: there is no need for the
application to split the message in several parts. A single SMS of large size will be supported
by the gateway, up to 254 characters may be transmitted in the short_message field, for larger
messages the data must be passed in the message_payload TLV (SMPP v. 3.4 minimum
needed).

Regarding SMS message size :

• A single SMS message may contain up to 160 alphanumeric characters encoded to
GSM format2. If the message size is greater, the message will be split in several parts
transmitted as separated SMS. The recipient mobile phone will automatically
concatenate the received parts in order to reconstitute the original complete message.
On most phones, up to 3 parts are supported, allowing a maximum message size of
469 characters (less than 160 x 4, because for concatenated messages, 7 header bytes
are used to store concatenation information).
• A binary SMS could contain up to 140 bytes. It is also to split a greater message to
transmit up to 384 bytes in 3 SMS messages.

Number of SMS Alphanumeric characters size Binary data size

messages
1 1 to 160 1 to 133
2 161 to 206 134 to 256
3 207 to 469 257 to 384
43 470 to 623 385 to 512

In order for an application to be able to send a large message, the easier way is to send to the
mobile a Wap Push SMS message enabling the recipient to automatically connect and display
a Wap page containing the data (provided the recipient subscription and phone are Wap
enabled).

Using character sets

2
If the SMS alphabet encoding used is Unicode, usually used for non-latin alphabets (arabic, japanese,
chineese), the size of a single SMS message could not exceed 70 Unicode characters.
3
Numerous phones does not support the sending of more than 3 concatenated messages. Except if the recipient
phone is known to support them, it is therefore not recommended to send messages of more than 469
alphanumeric characters 384 binary bytes.

Monaco Telematique MCTEL 19 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

• Try to use Ascii ISO 8859-1 (IsoLatin 1) characters also present in the GSM character
set. If you use ISO 8859-1 characters not existing in the GSM character set (for
example sparsely used accented characters), they will be replaced by their nearest
equivalent (e.g.: â by a) or if no equivalent cound be found by a '?'. The Appendix 2
shows the GSM character set along with the ISO 8859-1 to GSM translation.
• If needed, you could use Unicode alphabet to transmit non-latin characters (arabic,
russian, greek4, japanese, chineese, etc.). Using the Unicode alphabet will limit the
number of characters for a single SMS to 70 instead of 160.

Specifying sender identification

Depending on the country and mobile network operator of the recipient and your account
profile, the SMS you will send may bear your mobile phone identification number, your
company alphanumeric identifier, or may be sent from a generic SMS short id.

When the SMS is sent from a generic short id, you must include within the SMS text the
needed information allowing the recipient to understand whom has sent him a message.
Usually, this information is presented either at the beginning of the message (e.g.: MCTEL:
message body) or at the end of the message (e.g. send from MCTEL).

Delivery Notification Format

When requested, the delivery notifications regarding transmitted SMS are returned to the
Service Provider in a deliver_sm PDU with esm_class set to SMSC Delivery Receipt (bit 3 set
= 4).

The notification is stored in the deliver_sm short_message field. The SMPP protocol
specification states the format of the Delivery Receipt message is vendor specific. The layout
is explained in detail in this section.

“id:<ID> sub:nnn dlvrd:nnn submit date:<DDMMYYhhmmss> done date:

<DDMMYYhhmmss> stat:<status> err:<error> text:<text> ...”

ID

The "message id" returned by the submit_sm_resp PDU is encoded on 32 hexadecimal

characters (except in the case of SMPP v3.3 where the message id is encoded on 8
hexadecimal characters).

Status

The values for the <status> field are:

4
Instead of using Unicode character set for Greek messages, the best solution is usually to take advantage of the
Greek characters included in the GSM character set, however only uppercase characters will be available.

Monaco Telematique MCTEL 20 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

ENROUTE : Message en route to intended recipient (may have been received on

some networks that does not return always the delivery receipt).
DELIVRD : Message delivered to destination
RETRYIN : Message cannot be delivered – retrying
SCHEDLD : Message scheduled for delivery (e.g. delayed SMS)
UNDELIV : Message cannot be delivered and has been discarded. Refer to the
precise error cause for explanation.
EXPIRED : Message validity period expired – message deleted
DELETED : Message deleted
REJECTD : Message rejected by the gateway for network-specific reasons
UNKNOWN : Status unknown

Error

The error field encode on 5 digits the error cause, encoded as specified in Appendix 4.

Status and error information TLV

In order to offer a better interworking between SMPP systems, when SMPP v3.4 or more is
used, the message state and error code are also returned encoded in numeric format in the
message_state and network_error_code TLV that are included in the delivery report.

They are more easy to decode than the text notification described above. It remain usually
necessary to decode the text notification to extract the done date field when the mobile
reception timestamp is needed.

Unbinding

When the Service Provider wishes to disconnect the SMPP Receiver/Transmitter/Transceiver

for whatever reason, the SMPP unbind PDU must be issued conforming to SMPP
specifications. However in all cases the disconnection will be managed properly even if this
PDU is not issued (e.g. network link layer going down).

SMS-MO management when Receiver/Transceiver not connected

If a Mobile Originated message is sent to the Service Provider number (either short code or
long number) at a time when the Receiver is not bound into the SMPP Gateway, then the
message will be buffered by the SMSC and retried at certain intervals.

Especially when managing incoming SMS-MO requests, it is the nature of SMPP connections
to be connected at all times, in order to offer a good quality of service to the customer.
However, if a SMPP receiver is not connected all the messages will be buffered until either
SMS expiration time or Receiver/Transceiver connection.

Monaco Telematique MCTEL 21 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

All SMS-MO messages accepted by the SMSC will be stored for maximum 3 days, during
which time the SMSC will attempt to deliver the message. If it’s still not delivered after this
time the message will be expired and deleted. Depending on the error and expiration time
assigned to it, the message can expire before 3 days.

Examples

Refer to Annex 1.

Data security

Firewalls to access smppgateway.mctel.com

The customer firewall(s) must be configured to allow outgoing SMPP calls to the SMPP port
assigned to the customer by MCTEL.

If needed, configure your company firewall in order to allow outgoing requests to

smppgateway.mctel.com, on the SMPP port specified by MCTEL.

At account configuration, MCTEL will configure your TCP/IP address in MCTEL firewalls.

User Authentication

The standard user authentication use standard SMPP username/password mechanism:

• By default (see below), those identifiers are not encrypted.
• Additionally, we check TCP/IP caller address and only authorized addresses could
pass through our firewall to access our SMPP servers.
• If needed and for large corporate accounts, additional security mechanisms (HTTPS
encryption, Virtual Private Network (VPN) between customer computer and MCTEL
gateway) may be setup if needed.

Data Encryption

When TCP/IP network is used, data exchanged using SMPP are not encrypted.

When transmitting sensitive data, we recommend either:

• to setup a VPN (Virtual Private Network) or a VPN Tunnel with data encryption
between your network and MCTEL network.
• or to use X.25 as transport network.

Fault Finding

In the event of a connection or message sending problem, the following checks should be
done before calling for support:

Monaco Telematique MCTEL 22 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

• Is general internet access affected (or X.25 access if relevant)?

• Can the MCTEL IP address be “pinged” successfully?

MCTEL support will also require:

• Name of third party
• Name of service (or application) if third party has more than one connection
• Confirmation that no application or firewall changes have been made by the third
party that may have affected the service
• Nature of problems – e.g. persistent connections and disconnections, messages failing
to be submitted, messages failing to be delivered etc. - the more specific the better.

The application should also have the ability to sink and source test messages if required, in
order to facilitate fault finding and testing.

Monaco Telematique MCTEL 23 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Appendix 1: Example of SMPP requests

Here is some examples of SMPP requests.

Binding to MCTEL Gateway

bind_transceiver PDU

Sample PDU (Values are shown in Hex format):

00 00 00 2F 00 00 00 09 00 00 00 00 00 00 00 01 53 4D 50 50 33
54 45 53 54 00 73 65 63 72 65 74 30 38 00 53 55 42 4D 49 54 31
00 34 01 01 00
The 16-octet header would be decoded as follows:

00 00 00 2F => Command Length 0x0000002F

00 00 00 09 => Command ID 0x00000009 (bind_transceiver)
00 00 00 00 => Command Status 0x00000000
00 00 00 01 => Sequence Number 0x00000001

The remaining data represents the PDU body (which in this example relates to the
bind_transceiver PDU).
This is diagnosed as follows:
53 4D 50 50 33 54 45 53 54 00 system_id (“SMPP3TEST”)
73 65 63 72 65 74 30 38 00 password (“secret08”)
53 55 42 4D 49 54 31 00 system_type (“SUBMIT1”)
34 interface_version (0x34 “V3.4 compliant”)
01 addr_ton (0x01)
01 addr_npi (0x01)
00 addr_range (NULL)

bind_transceiver_resp PDU

In answer, the MCTEL SMPP returns a bind_transceiver PDU:

00 00 00 1E 80 00 00 09 00 00 00 00 00 00 00 01 53 4D 50 50 54
45 53 54 4D 43 54 45 4C 00

It can be broken down into the following sections:

Header:

00 00 00 1E => command_length
80 00 00 09 => command_id => TRANSCEIVER_RESP
00 00 00 00 => command_status (x0000000 = OK)
00 00 00 01 => sequence_number (the sequence number must
be identical to the value set for the operation)

Monaco Telematique MCTEL 24 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Body:
53 4D 50 50 54 45 53 54 4D 43 54 45 4C 00 => system_id =>
'SMPPTESTMCTEL'(server identifier)

Monaco Telematique MCTEL 25 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Appendix 2 – SMPP error codes listing

Status code Hex value Description

ESME_ROK 0x00000000 No Error.
Specified in a response PDU to indicate the
success of the corresponding request
ESME_RINVMSGLEN 0x00000001 Message Length is invalid.
short_message field or message_payload TLV
has an invalid length (usually too long for the given
MC or underlying network technology).
ESME_RINVCMDLEN 0x00000002 Command Length is invalid.
ESME_RINVCMDID 0x00000003 Invalid Command ID.
Command ID is not recognised, either because
the operation is not supported or unknown.
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.
ESME_RINVSRCADR 0x0000000A Invalid Source Address
ESME_RINVDSTADR 0x0000000B Invalid Destination Address.
ESME_RINVMSGID 0x0000000C Message ID is invalid.
ESME_RBINDFAIL 0x0000000D Bind Failed.
ESME_RINVPASWD 0x0000000E Invalid Password.
ESME_RINVSYSID 0x0000000F Invalid System ID.
ESME_RMSGQFUL 0x00000014 Message Queue Full.
ESME_RINVSERTYP 0x00000015 Invalid Service Type.
ESME_RINVSUBREP 0x00000042 Illegal submit w/replace request
ESME_RINVESMCLASS 0x00000043 Invalid esm_class field data.
ESME_RSUBMITFAIL 0x00000045 Generic failure error for submission operations
ESME_RINVSRCTON 0x00000048 Invalid Source address TON.
ESME_RINVSRCNPI 0x00000049 Invalid Source address NPI.
ESME_RINVDSTTON 0x00000050 Invalid Destination address TON.
ESME_RINVDSTNPI 0x00000051 Invalid Destination address NPI.
ESME_RINVSYSTYP 0x00000053 Invalid system_type field.
ESME_RINVREPFLAG 0x00000054 Invalid replace_if_present flag.
ESME_RTHROTTLED 0x00000058 Throttling error (ESME has exceeded allowed
message limits in a given timeframe).
ESME_RINVSCHED 0x00000061 Invalid Scheduled Delivery Time.
ESME_RINVEXPIRY 0x00000062 Invalid message validity period
ESME_RX_T_APPN 0x00000064 ESME Receiver Temporary App Error Code.
Rx or Trx ESME is unable to process a delivery
due to a temporary problem and is requesting that
the message be retried at some future point
ESME_RX_P_APPN 0x00000065 ESME Receiver Permanent App Error Code.
Rx or Trx ESME is unable to process a delivery
due to a permanent problem relating to the given
destination address and is requesting that the
message and all other messages queued to the
same destination should NOT be retried any
further
ESME_RX_R_APPN 0x00000066 ESME Receiver Reject Message Error Code.
Rx or Trx ESME is unable to process delivery due

Monaco Telematique MCTEL 26 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

to a problem relating to the given message and is

requesting that message is rejected and not
retried. This does not affect other messages
queued for the same ESME or destination
address.
ESME_RQUERYFAIL 0x00000067 query_sm request failed.
ESME_RINVTLVSTREAM 0x000000C0 Error decoding optional TLV
ESME_RTLVNOTALLWD 0x000000C1 TLV not allowed.
ESME_RINVTLVLEN 0x000000C2 Invalid Parameter Length.
ESME_RMISSINGTLV 0x000000C3 Expected TLV missing.
ESME_RINVTLVVAL 0x000000C4 Invalid TLV Value.
ESME_RUNKNOWNERR 0x000000FF Unknown Error.
ESME_RPROHIBITED 0x00000101 ESME Prohibited from using specified operation.
ESME_RINVDCS 0x00000104 Invalid Data Coding Scheme.
SMSNOCARRIER 0x00000400 No route to this destination
SMSQUOTAEXCEEDED 0x00000402 Maximum credit exceeded
SMSUSERIDLOCKED 0x00000410 User subaccount suspended
SMSCOMPANYLOCKED 0x00000411 Company account suspended

Monaco Telematique MCTEL 27 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Appendix 3 – GSM default alphabet

The 7 bits default GSM alphabet

The GSM 7 bits default character table is specified below: there is a base table (where each
characters is encoded on 1 byte) and an extension table where each character is encoded on 2
bytes (the escape code from base table and the extension table character, for example €
symbol). The ISO 8859-1 without GSM equivalent will be translated on the nearest equivalent
character or otherwise to a "?" character.

b7 0 0 0 0 1 1 1 1

b6 0 0 1 1 0 0 1 1

b5 0 1 0 1 0 1 0 1
b4 b3 b2 b1 0 1 2 3 4 5 6 7

0 0 0 0 0 @ ∆ SP 0 ¡ P ¿ p
0 0 0 1 1 £ _ ! 1 A Q a q

0 0 1 0 2 $ Φ " 2 B R b r

0 0 1 1 3 ¥ Γ # 3 C S c s

0 1 0 0 4 è Λ ¤ 4 D T d t

0 1 0 1 5 é Ω % 5 E U e u

0 1 1 0 6 ù Π & 6 F V f v

0 1 1 1 7 ì Ψ ' 7 G W g w

1 0 0 0 8 ò Σ ( 8 H X h x

1 0 0 1 9 Ç Θ ) 9 I Y i y

1 0 1 0 10 LF Ξ * : J Z j z

1 0 1 1 11 Ø 1) + ; K Ä k ä
1 1 0 0 12 ø Æ , < L Ö l ö

1 1 0 1 13 CR æ - = M Ñ m ñ

1 1 1 0 14 Å ß . > N Ü n ü

1 1 1 1 15 å É / ? O § o à
NOTE 1): This code is an escape code to the extension table specified next page.

Monaco Telematique MCTEL 28 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

GSM 7 bit default alphabet extension table

b7 0 0 0 0 1 1 1 1

b6 0 0 1 1 0 0 1 1

b5 0 1 0 1 0 1 0 1

b4 b3 b2 b1 0 1 2 3 4 5 6 7

0 0 0 0 0 |
0 0 0 1 1

0 0 1 0 2

0 0 1 1 3

0 1 0 0 4 ^

0 1 0 1 5 €
0 1 1 0 6

0 1 1 1 7

1 0 0 0 8 {

1 0 0 1 9 }

1 0 1 0 10 3)

1 0 1 1 11 1)

1 1 0 0 12 [
1 1 0 1 13 ~

1 1 1 0 14 ]

1 1 1 1 15 \
In the event that a mobile receives a code where a symbol is not represented in the above table then the mobile
shall display the character shown in the main GSM 7 bit default alphabet table in clause 6.2.1.

Converting ISO 8859-1 (International Reference Alphabet IRA) to

GSM

The HTTP/HTML Web interface allows to specify any text using the ISO 8859-1 (Iso Latin 1,
International Reference Alphabet) if another encoding alphabet has not been specified. In this
case, the VideoSMS gateway will perform the conversions described below if some characters
not included in the GSM alphabet are present in the SMS text string.

Monaco Telematique MCTEL 29 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Converting IRA (ISO 8859-1) to GSM

00 10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 F0
00 - - 20 30 00 50 - 70 - - - - 411 - 7F -
01 - - 21 31 41 51 61 71 - - 40 - 412 5D 6120 7D
02 - - 22 32 42 52 62 72 - - - - 413 4F12 6121 08
03 - - 23 33 43 53 63 73 - - 01 - 414 4F13 6122 6F29
04 - - 02 34 44 54 64 74 - - 24 - 5B 4F14 7B 6F30
05 - - 25 35 45 55 65 75 - - 03 - 0E 4F15 0F 6F31
06 - - 26 36 46 56 66 76 - - - - 1C 5C 1D 7C
07 - - 27 37 47 57 67 77 - - 5F - 09 - 0923 -
08 - - 28 38 48 58 68 78 - - - - 455 0B 04 0C
09 - - 29 39 49 59 69 79 - - - - 1F 5516 05 06
0A LF - 2A 3A 4A 5A 6A 7A - - - - 456 5517 6524 7532
0B - - 2B 3B 4B - 6B - - - - - 457 5518 6525 7533
0C - - 2C 3C 4C - 6C - - - - - 498 5E 07 7E
0D CR - 2D 3D 4D - 6D - - - - - 499 5919 6926 7934
0E - - 2E 3E 4E - 6E - - - - - 4910 - 6927 -
0F - - 2F 3F 4F 11 6F - - - - 60 4911 1E 6928 7935

1 :À A 2 :Á A 3 :Â A 4 :Ã A 5 :È E

6 :Ê E 7 :Ë E 8 :Ì I 9 :Í I 10 :Î I

11 :Ï I 12 :Ò O 13 :Ó O 14 :Ô O 15 :Õ O

16 :Ù U 17 :Ú U 18 :Û U 19 :Ý Y 20 :á a

21 :â a 22 :ã a 23 :ç Ç 24 :ê e 25 :ë e

26 :í i 27 :î i 28 :ï i 29 :ó o 30 :ô o

31 :õ _ o 32 :ú u 33 :û u 34 :ý y 35 :ÿ y

Monaco Telematique MCTEL 30 August 2004

VIDEOSMS SMPP Interface Manual v. 1.2

Appendix 4 – MCTEL error codes

The following MCTEL error codes may be returned by the SMPP interface, in the err: field of
the text delivery notification (returned by deliver_sm) and in the optional network_error_code
TLV.

Code Signification
00000 No error signalled
00001 Success
00002 Generic error code when a more specific error code is not available
00024 No route available to transmit this message to the specified country/operator
00036 User does not have enough unit balance on his account
00051 Invalid or unknown mobile number
00053 Call barred
00054 Mobile offline or outside coverage area
00055 Mobile network operator SMSC is down
00056 Target phone number is redlisted
00057 Target phone number is blacklisted (e.g. has send STOP request)
00058 Number ported by another operator
00065 Internal error
00068 Message has been deleted by an operator
00099 Other unspecified error
00100 The delivery failed, could not be accepted by mobile (e.g. SIM full)
00101 Mobile subscriber not equipped to receive SMS
00102 SMS has not been provisioned
00103 Error in subscriber mobile phone equipment
00104 Closed User Group reject
00105 The message has expired
00106 Reverse charging legitimation failure
00107 Invalid MSISDN number format for the specified country

Monaco Telematique MCTEL 31 August 2004