Interface informationtyntec’s two-way SMS, based on SMPP, is a service that enables you to send and receive SMS to and from all

operators listed on tyntec’s coverage list using the SMPP protocol. tyntec supports SMPP protocol version 3.4.

Authentication is done during the setup of the SMPP connection. After the initial authentication, the session

between your system and ours (i.e. the peers) is kept open and alive.

The following illustrates the workflow for sending and receiving SMS:

Outbound SMS (SMS-MT)

Send an SMS message from your own system to the tyntec platform, through the operator network and to the subscriber.

Inbound SMS (SMS-MO)

Receive an SMS message from the subscriber through the operator network and tyntec platform to your own system.

SMS Protocol: SMPP

SMPP session types

Supported SMPP operations

Transmitter session

Receiver session

Transceiver session

SMPP operation

bind_transmitter

bind_receiver

bind_transceiver

unbind

generic_nack

submit_sm

deliver_sm

enquire_link

Used for you to send SMPP requests to tyntec

Used by tyntec to send SMPP requests to you

Used in both the ways above

Initiator

You

You

You

You or tyntec

tyntec

You

tyntec

You and/or tyntec

Role

Establish a transmitter session

Establish a receiver session

Establish a transceiver session

Close a session

Negative answer to a faulty request, or if the service is

currently unavailable

Send an SMS. Works with transmitter and transceiver

sessions.

Provide a delivery receipt (DLR). Works with receiver

and transceiver sessions.

Check if a session is still working

Answered by the other party with

bind_transmitter_resp

bind_receiver_resp

bind_transceiver_resp

unbind_resp

N/A

submit_sm_resp (contains a unique message ID)

deliver_sm_resp (if the customer doesn’t answer

with this, tyntec will retry the deliver_sm)

tyntec sends an enquire_link through an open

session every 30 seconds. You should answer this

with an “enquire_link_resp”. If this doesn’t happen

for five times in a row, tyntec will terminate the

respective session.

tyntec answers with an enquire_link_resp to

any incoming enquire_link. If you don’t see the

enquire_link_response, the session is likely to be

dead.

Send SMS messages Connection steps

Step 1 - Setting up a session using a bind request

Step 2 - Acknowledge bind request

After entering the connectivity parameters provided by tyntec (IP, port, username, password) into the SMPP client,

a connection between your system and tyntec will be established using one of the bind operations described

above. If you want to be able to send Outbound SMS and to receive the DLRs, you need either one transceiver

session or one transmitter and one receiver session. The same bandwidth will be available to you no matter how

many sessions you establish.

After tyntec receives a bind request with the correct authentication parameters, a bind_resp will be issued and the

session is available for communication.

Step 3 – Submitting a message

Step 4 - Acknowledge submitted message

Step 5 – Submitting a delivery receipt (DLR), optional

Messages are submitted to tyntec using the submit_sm operation. The submit_sm operation and the PDU

are described in detail in the SMPP 3.4 documentation. Here are the most common parameters and their

recommended values:

• dest_addr_ton: 1

• dest_addr_npi: 1

• dest_addr: receiver number in international format, i.e. with leading “+” or “00” plus country code.

• Data_coding:

After tyntec received a correct submit_sm request, a submit_sm_resp will be issued. The submit_sm_resp contains

the message ID in the message_id parameter, which is a unique identifier for each message. It may vary in format

and length. The submission of the message to tyntec is finalized with the issuing of the submit_sm_resp. The

messages are stored in the tyntec SMSC and will be delivered to the receiver. If the initial delivery attempt is not

successful – e.g. the receiving mobile phone is turned off – further attempts of delivering the message will be

made. The message will be kept in the tyntec SMSC for up to 48 hours, after which it will expire.

Once a message reaches a final status (delivered, cannot be delivered, expired), tyntec creates a delivery receipt if

this is requested in the initial submit_sm. The DLR will be submitted to you via an existing receiver or transceiver

session using the deliver_sm operation. The delivery receipt itself is included in the text parameter of the deliver_

sm PDU.

The tyntec deliver_sm content of the source and destination parameters match the values of the original submit_

sm. This behaviour is different to the SMPP specification but commonly used. Upon request, tyntec can change

this behaviour to match the SMPP 3.4 specification.

The text in the deliver_sm will be in the following format:

Data coding Name Description

0

1

3

8

GSM7 aka SMSC Default

alphabet

ASCII aka IA5 (CCITT T.50)/

ASCII (ANSI X3-4)

Latin-1 aka ISO 8859-1

Unicode aka UCS2 aka

ISO/IEC-10646 aka

double-byte

European characters including French, Spanish and Nordic letters. Some Greek letters are also included, but

not every character is covered. Euro sign is covered.

European characters.

European characters including French, Spanish and Nordic letters. SMPP only: ISO 8859-15, which also covers

the Euro sign is supported, although it is displayed as a generic currency symbol on most handsets.

Everything. All European, Greek, Arabic, Chinese, Thai, Kanji and various special characters. Display on the

handset differs strongly and may depend on setting of the handset (example: Chinese characters may not be

displayed if the interface is set to European display). Note: a Unicode SMS may only contain 70 characters.

See also: http://www.unicode.org/charts/ or http://www.unicode/org/charts/PDF/Unicode-4.1/

“ id:<Tyntec‘s messageid> sub:001 dlvrd:001 submit date:YYMMDDhhmm donedate:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . .”

Step 6 – Acknowledge submitted DLR

Possible values for DDDDDDD:

• DELIVRD – message was successfully delivered

• UNDELIV – message could not be delivered, e.g. due to unknown number

• EXPIRED – message could not be delivered within validity period, maximum 48 hours

• REJECTD – message was rejected, e.g. because of incorrect format

Possible values for E:

001 or 013 - message was delivered, used with DDDDDDD = DELIVRD

002 – message was not delivered, used with DDDDDDD = UNDELIV

006 or 020 – message expired, used with DDDDDDD = EXPIRED

010 – message was rejected, used with DDDDDDD = REJECTD

012 - Message could not yet be delivered. tyntec is still retrying. This is used for intermediate DLRs.

You need to acknowledge the receipt of a deliver_sm with a deliver_sm_resp, otherwise tyntec will keep on

resending the deliver_sm.

Features

Feature Activation Functionality

Freely configurable

sender ID type

Swap sender and

receiver in the DLR

Extended DLR

TON/NPI settings

Protocol ID / Over

The Air (OTA)

GSM return codes

Intermediate DLRs

Dynamic sender ID

replacement

Geographic time

stamp

Concatenated SMS

Deferred delivery

Default

On request

On request

On request

Default

Default

Default

On request

On request

Default

Default

You can freely define the sender ID as alphanumeric, numeric or shortcode. An alphanumeric sender ID

can have up to 11 characters.

In the tyntec DLRs, the sender and receiver parameters are set to the same values as in the matching

message. If this feature is activated, the content is swapped, i.e. the sender parameter of the original

message becomes the receiver in the DLR and the other way round. The former behavior is common

practice in the industry, while the latter matches the SMPP 3.4 specifications.

If this feature is activated, the TON/NPI values are set in the deliver_sm PDU that delivers the DLR to you

(MT). The TON/NPI values match the ones you originally set in the submit_sm.

If this feature is activated, you can set TON/NPI for the originator. As an exception, tyntec will set the TON

to 5 for an alphanumeric originator. If the feature is not activated, tyntec will set the TON/NPI parameters

automatically based on the analysis of the originator.

This feature enables the setting of the protocol ID as per GSM 3.40 documentation. It is commonly used

for sending binary SMS.

The GSM return codes substitute the tyntec response codes with four-digit hexadecimal codes. This

feature gives more visibility on the non-delivery reason. A list of GSM return codes is available in the

Service section.

The intermediate DLR is sent to you if the first delivery attempt of an SMS fails. By reading the GSM return

code in it, you can identify the non-delivery reason. A message that cannot be delivered during the first

attempt will have a “BUFFERD” state.

This feature can replace the original sender ID with a random numeric one. It is particularly useful to

overcome certain sender ID restrictions.

This feature adapts the timestamp to the local time of the home network and not to the MSC. So, for

example, if the subscriber is roaming, the message will not show local time, but home network time.

The maximum length of an SMS is 160 characters in GSM-7, 140 in ASCII and 70 in Unicode (UCS-2). This

feature enables the transmission of messages over these lengths as a concatenation of several segments.

You must split the concatenated message into segments and use a specific User Data Header (UDH) as

described in the SMPP 3.4 documentation.

The SMS can be scheduled for future delivery.

Feature Activation Functionality

Validity setting

Number Portability

check

Clear DLR text

MCC/MNC and TTID

of recipient operator

Price in the DLR

Default

Default

On request

Default

Default

The default SMS validity is 48 hours. If the first attempt fails, tyntec will make several delivery attempts

during this timeframe. You can, however, set the validity to values lower than 48 hours.

Especially for One-Time Password, we recommend setting the validity to several minutes. This will make

the message expire when the content is no longer relevant and force more retries within a short time

frame after sending the message, hence increasing the chance of delivery.

tyntec checks if the recipient number is ported before each SMS delivery. The message is routed to the

true home network.

A standard DLR that we send to you contains the text of the original SMS. If preferred for security reasons,

you can use this feature to request the removal of the original SMS text from the DLR.

Identifies the receiving operator in the DLR by its MCC/MNC and TTID (tyntec operator ID). The TLV field

0x203 is populated with the MCC/MNC and the TLV field 0x1401 with the TTID. If the Swap sender and

receiver in the DLR feature is activated, then the TLV field 0x202 is populated with the MCC/MNC and the

TLV field 0x1400 with the TTID.

Shows the price applicable for the respective SMS. The TLV field 0x1402 contains the price, the field

0x1403 contains the currency (e.g. “EUR”) and the field 0x1404 contains the timestamp based on when the

price became effective in SMPP time format.

The following SMPP features are not supported:

• service_type: i.e. possibility of setting ‚Voice Mail Alerting‘

• replace_if_present_flag: for changing a ‚not yet delivered‘ message

• sm_default_msg_id: predefined messages of the SMSC

• priority_flag: prioritizing the delivery of SMS

After entering the connectivity parameters provided by tyntec (IP, port, username, password) into the SMPP client,

a connection between your system and tyntec will be established using one of the bind operations described

above. For receiving SMS from tyntec, a receiver or transceiver session is needed. The session needs to stay open

in order for us to be able to deliver the messages to you.

After tyntec receives a bind request with the correct authentication, a bind_resp will be issued and the session is

available for communication.

When tyntec receives a message on one of the inbound numbers assigned to you, it is relayed to your platform

using the deliver_sm operation. For details on the deliver_sm operation and the PDU, please refer to the SMPP 3.4

documentation.

After you receive a deliver_sm, you need to acknowldege the receipt by answering with a deliver_sm_resp.

Otherwise, we will resend the deliver_sm.

Receive SMS messages Connection steps

Step 1 - Setting up a session using a bind request

Step 2 – Acknowledge bind request

Step 3 – Receiving a message

Step 4 - Acknowledge received message

Feature Activation Functionality

Timestamp

Global Title of sending SMSC

TON/NPI

Default

Default

Default

Shows the actual time when the mobile subscriber sent the SMS.

Identifies the sending SMSC by its MCC/MNC.

tyntec passes through the TON/NPI values of the originator.

Features