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) |
NOTES
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.
schedule_delivery_time is not supported. Any submit_sm PDUs with a scheduled time are overridden and sent out for immediate delivery.
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 TLV
2. Matching MO messages using source_addr and destination_addr
Fig.2 - Matching using source_addr and destination_addr
Updated about 1 year ago