Sending and Receiving

Submitting Messages

The following default settings can be used for the submit_sm PDU:

Name

Recommended Value

service_type

Null

source_addr

Any series of ASCII characters terminated with a NULL character. (Up to a max of 20 characters).

source_addr_ton

0

source_addr_npi

0

destination_addr

A series of ASCII characters, each character representing a
decimal digit (0 - 9) and terminated with the NULL character. (Up to a max of 20 character).

dest_addr_ton

0

dest_addr_npi

0

data_coding

0

GSM 03.38 is default SMSC character set (Encoding)

📘

NOTE

Your SMPP account must be configured for access to mobile network operators to which you are attempting to terminate messages. If access has not be configured then the submit_sm PDU will be rejected with an ESME_RINVDSTADR response.

submit_sm PDUs with destination_addr fields that are not numeric will also be rejected with an ESME_RINVDSTADR response.

SMSC specific optional parameters (TLVs)

The following SMSC specific optional TLVs are provided:

TLV Tag Identifier

Character Limit

Description

0x1400

varchar(100)

Customer Reference. Can be used when generating reports using the control panel.

0x1401

varchar(100)

Cost Center Reference. Can be used when generating reports using the control panel.

Data Coding Schemes

The following data coding schemes are supported.

Data Coding Scheme (DCS)

Description

Max Length (Bytes)

0

GSM 03.38
This is SMSPortal's default data coding scheme.

160

8

Unicode / UCS-2

140

🚧

IMPORTANT

Only the above two encodings are supported. submit_sm PDUs that specify a different data_coding or that exceed the max length will be rejected.

Receiving Delivery Receipts and MO Messages

Please note that it is important to keep a TRX or RX bind connected to receive outstanding deliver_sm PDUs as soon as possible. Outstanding deliver_sm PDUs are kept for 12 hours or a maximum of 1 million outstanding PDUs is reached, after which the oldest deliver_sm PDUs will be discarded to make room for newer deliver_sm PDUs.

The esm_class field of the deliver_sm PDU can be used to determine if a mobile originated (MO) message is either a delivery receipt (DLR) or a default message. The third, fourth, fifth and sixth bit must be off for it to be a mobile originated message, i.e.xx0000xx where ‘x’ is an arbitrary bit value.

Delivery Receipts for submit_sm PDUs are only sent if the registered_delivery field of the submit_sm PDU is set to request the delivery receipt.

Delivery receipts are embedded either in the short message mandatory field (if less than 255 octets) or the message payload TLV field of the deliver_sm. The format of the delivery receipt is SMSC vendor specific. The following is a typical example of a delivery receipt.

“id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . .”

There are two methods that can be used to perform matching of original submit_sm PDUs to deliver_sm PDUs

1. Matching MO messages using user_message_reference TLV

To match a mobile originated deliver_sm to a submit_sm, set the user_message_reference TLV in the submit_sm PDU to an integer value. On receiving the deliver_sm PDU, the user message reference TLV will contain the original integral value provided by the submit_sm.

Figure 1 depicts a typical client and server interaction for a registered delivery submit_sm. It also shows the delivery of a mobile originated message. The interaction will vary based on bind types (TX, TRX, and RX). A deliver_sm message may not necessarily be received on the same bind or session. If there are outstanding deliver_sm messages and no applicable binds to send them to they will be delivered when binding with an applicable bind request (RX or TRX).

The account must be configured to achieve this type of matching (Please refer to the SMPP 3.4 specification. for more detail).

Fig.1 Matching using *user_message_reference* TLVFig.1 Matching using *user_message_reference* TLV

Fig.1 Matching using user_message_reference TLV

2. Matching MO messages using source_addr and destination_addr

Fig.2 - Matching using source_addr and destination_addrFig.2 - Matching using source_addr and destination_addr

Fig.2 - Matching using source_addr and destination_addr


Did this page help you?