In this answer, I have shared my experience with SMPP. I have not used Talend ESB.
As per the SMPP 3.4 spec, sections 4.8, 5.2.28 and 6.1 provide description about the query_sm and query_sm_resp pdus. Here are some key points:
- query_sm
- Can only be requested by a ESME.
- Can be issued on a previously issued submit_sm, data_sm or submit_multi_sm pdu.
- source_addr, source_addr_ton, source_addr_npi sent and message_id received from the *_resp object are used on the query_sm pdu.
- qeury_sm_resp
- command_status can indicate the overall outcome of the query_sm pdu. Section 5.1.3 enlists all the values. You should check the API provider to know correct values to use.
- message_state indicates the state of the requested pdu. See section 5.2.28.
- error_code indicates error occurred in the network, if any. You should check the API provider to know correct values to use.
I would be curios to know what motivated you to use query_sm. query_sm pdus are rarely used in real life. At work, we process billions of SMS everyday from all major US carriers and we rarely get any query_sm.
Alternatives to query_sm would be "Delivery Receipt", yet not so much supported by most platforms. The immediate platform you are connected to can give you some info.
Hi Wahid, my motivation was the fact that we seem to not be receiving all of our delivery receipts when sending out messages to the carriers gateway. Out of about 2000 messages we received about only lets say 60% of their delivery statuses. We are wondering if it is possible to send a query_sm and receive the message id's current status. Is it possible to do this? What would we need to use to do this?
query_sm can fetch results from the SMSC your ESME is connected to. If the SMSC is working diligently, it can return correct result to the best of its knowledge. If the SMSC sending the actual SMS to the handset, you can rely on the result. If the SMSC is connected to some intermediate SMPP entity, it can forward the query_sm (I doubt any system will do this) to these platforms, and expect them to reply properly. Usually you do not know how this topology is set up and hence you can only hope that the query_sm_resp is a good one.
Delivery receipts can fetch results all way from handset. To do that, the receiving handset has to be willing to send back a confirmation. Also, all the connecting ESME/SMSC need to cooperate to forward the receipt results; systems can make up their own receipts prematurely. You are getting 60% of the delivery receipts. I can only guess few reasons for it - the destination numbers are wrong, the message was not delivered, or the receiving handset turned of delivery receipt. Can you check if you are getting the same delivery receipt results for the same dest number? It may give you some clue.
Hi Wahid, I have used wireshark to capture the packets. The header looks as follows. 883 98.372604000 10.0.0.2 192.168.0.1 SMPP 558 SMPP Deliver_sm, Deliver_sm, Deliver_sm. Also sorry by report I meant Deliver_sm sorry.
(1) As per SMPP 3.4, each SMPP PDU can contain only one deliver_sm. Period. (2) It is perfectly okay for a TCP packet to contain any number of SMPP PDU (even fraction of a PDU). Wireshark is possibly showing this. Any decent SMPP library should be able to return these SMPP PDU(s) separately. (3) How are you determining that these deliver_sm PDU(s) are duplicates?