SMPP Protocol SUBMIT_SM / SUBMIT_SM_RESP

SMS Messages are submitted by the SMPP client (ESME) to the SMPP server (SMSC) via SUBMIT_SM. All submitted SMS are mandatory to be acknowledged by the SMPP server using SUBMIT_SM_RESP if there is nothing wrong on the submitted SMS.

A common misconception for those who are new to SMPP is that SUBMIT_SM_RESP is NOT a delivery report but an acknowledgement by the SMPP Server that it has received and accepted the SMS for delivery.

Let us inspect a SMPP SUBMIT_SM / SUBMIT_SM_RESP sequence to have a better understanding.

Run a trace on your SMPP client or SMPP Server

$tcpdump -i any -s0 -w /file/location/tosave.cap host IPofserverorclient

Open the saved trace file using wireshark and filter smpp

smpp

The first thing you will notice once you filter SMPP traffic are several packets of SMPP Enquire_link and SMPP Enquire_link_resp. These are mandatory packets sent by the SMPP client (SMPP Enquire_link) and acknowledgements of the SMPP Server (SMPP Enquire_link_resp). These are just like handshake messages or keep alive messages sent by the SMPP client to let the SMPP server know that it is alive and working. Failure by the SMPP client to send enquire_link will make the server think that there is no SMPP client connected and thus will disconnect the existing SMPP BIND.

Enquire link and its corresponding responses are identifiable by the Sequence #. This sequence id will be identical between an enquire_link and its matching enquire_link_resp packet. From the image above you can see that the sequence number is Sequence #: 1399

For a SMPP SUBMIT SM and SUBMIT_SM_RESP Pair, the Sequence # would also be the reference id. In the example below we made a filter based on the Sequence #: 13323

submit_sm

Now lets look into the SMPP SUBMIT_SM Packet

Operation: Submit_sm (0x00000004)
– This tells what kind of operation is being performed. Refer to the SMPP command set table (5.1.2.1) on the SMPP 3.4 Spec

Sequence #: 13323
– This is the reference id that will match the SUBMIT_SM_RESP. This is a useful reference if your troubleshooting SMS that are being submitted to the SMPP Server.

Type of number (originator): Alphanumeric (0x05)
– This value will depend on what kind of sender address is being used by the SMS message. In this example we are using an alphanumeric sender address. Section 5.2.5 of SMPP 3.4 Spec provides the list of TON values to be used.

Numbering plan indicator (originator): Unknown (0x00)
– This value will depend on what kind of sender address is being used by the SMS message. In this example we are using an alphanumeric sender address. Section 5.2.6 of SMPP 3.4 Spec provides the list of NPI values to be used.

Originator address: XXXXXX
– As the name Implies.

Type of number (recipient): International (0x01)
– This value will depend on what kind of recipient address is being used by the SMS message. In this example we are using an alphanumeric sender address. Section 5.2.5 of SMPP 3.4 Spec provides the list of TON values to be used.

Numbering plan indicator (recipient): ISDN (E163/E164) (0x01)
– This value will depend on what kind of recipient address is being used by the SMS message. In this example we are using an alphanumeric sender address. Section 5.2.6 of SMPP 3.4 Spec provides the list of NPI values to be used.

Recipient address: +8401234567899
– As the name Implies.

…. ..00 = Messaging mode: Default SMSC mode (0x00)
– This refers to the Messaging Mode as described on section 5.2.12 esm_class of SMPP 3.4 Spec. In simple laymans term this tells the SMPP Server (SMSC) how to handle the SMS.

..00 00.. = Message type: Default message type (0x00)
– This refers to the Message Type as described on section 5.2.12 esm_class of SMPP 3.4 Spec. In simple layman’s term, this tells the SMPP Server(SMSC) what is the type of SMS its receiving.

00.. …. = GSM features: No specific features selected (0x00)
– This refers to the Specific Features included no the SMS as described on section 5.2.12 esm_class of SMPP 3.4 Spec. In layman’s term, this tells the SMPP Server (SMSC) if the SMS message has a special feature included. E.g Reply Path. This is an SMS feature that when the hand phone receives the SMS and would reply to the same message, the handset will use the SMSC that delivered the SMS and not the SMSC locally configured on the phone.

Protocol id.: 0x00
Plain MO-MT messages have PID=0. If you want more details refer to GSM_03.40

Priority level: GSM: None ANSI-136: Bulk IS-95: Normal (0x00)
– This values signify the priority of the SMS message when trying to deliver. More details are described section 5.2.14 priority_flag of SMPP 3.4 Spec

Scheduled delivery time: Immediate delivery
– This would indicate if the SMS has a set scheduled delivery time. Section 7.1.1 Time Format of SMPP 3.4 Spec will give you an insight how to set this time. If set to 0x00, it means immediate delivery.

Validity period: SMSC default validity period
– This is used to set the expiry date of the SMS. When the SMS reaches the expiry date, the SMSC discards the delivery attempt and set it to expired. 0x00 means it will follow the SMPP Server’s default validity period.

…. ..01 = Delivery receipt: Delivery receipt requested (for success or failure) (0x01)
– This flag indicates if the SMS will require a delivery report from the SMPP Server. Setting this to 0x00 means no delivery report is being requested.

…. 00.. = Message type: No recipient SME acknowledgement requested (0x00)
_ This flag indicated is the SMPP client is requested for message acknowledgement upon the recipient by the SMPP Server. This is different from submit_sm_resp. This is like a delivery report but for received SMS messages.

…0 …. = Intermediate notif: No intermediate notification requested (0x00)
– This flag indicates if the SMS will require an intermiediate delivery report (e.g absent subscriber) from the SMPP Server.

…. …0 = Replace: Don’t replace (0x00)
– This flag indicates if the SMPP client wishes to replace a previously submitted non delivered SMS on the SMPP Server.

Data coding: 0x00
– I would probably skip the details on this part as i want to tackle this on a separate blog as this topic is complicated. However 0x00 here means the data coding scheme used on the SMS is GSM default alphabet.

Message
– This will be the actual message inside the SMS.

Now lets look into the SMPP SUBMIT_SM_RESP Packet

submit_sm_resp
Operation: Submit_sm – resp (0x80000004)
– This tells what kind of operation is being performed. Refer to the SMPP command set table (5.1.2.1) on the SMPP 3.4 Spec

Result: Ok (0x00000000)
– This would indicate how the SMPP Server received the SMS. If there is an error detected it would return the corresponding error type as indicated on 5.1.3 command_status SMPP 3.4 Spec.

Sequence #: 13323
– This is the reference id that will match the SUBMIT_SM. This is a useful reference if your troubleshooting SMS that are being submitted to the SMPP Server.

Message id.: 51380464967
– This would be the single most relevant information on a SUBMIT_SM_RESP packet. The message id is some sort of your reference number when the SMPP Server starts to send delivery reports (intermediate or final). You are going to match the message id against the delivery report’s message id.

FacebookTwitterGoogle+Share

Leave a Comment

Your email address will not be published. Required fields are marked *