Message ID for SMS submission and delivery not the same

Question

Is it correct that the Message ID returned as part of the SUBMIT_SM_RESP does not match the Message ID returned in the DELIVER_SM delivery receipt?

From reading the SMPP 3.4 spec 1.2 I thought it would, because the spec states in Appendix B for the delivery receipt:

The message ID allocated to the message by the SMSC when originally submitted.

but I'm finding for example the hex returned in the SUBMIT_SM_RESP to be

c81f136b00116d53000000000b68c86e01481101

whilst the decimal returned in the DELIVER_SM to be

14420265882147188051

and no amount of bit-fiddling shows any correlation between the two or parts thereof.

I initially thought it a bug on my part, but I then found in the obscure document Technical realization of the Short Message Service (SMS) Point-to-Point (PP) (GSM 03.40)

§9.2.1 The Short Message Identifier is not carried between entities and therefore a given message may have different SMIs at the MS and SC sides

and later

§9.3.1 ...therefore the Message Identifier at the SC/GMSC interface is not the same as at the visited MSC/MS interface

So, do I understand correctly the Message ID is useless for correlating submission and delivery of SMSs?

Answer 1

My problem turned out that I was converting from hex to decimal using a 32-bit method, whilst a 64-bit conversion on the first 16 characters of the returned value matches the delivery receipt. So it was my bug, but thanks to Wahid Sadik for confirming that the two are expected to match.

Answer 2

Short answer

No it's not correct.

The reason you are seeing this kind of mismatch is because of some implementation error in the SMSC you are connected to.

Read on for detail explanation.

Long answer

The excerpts from GSM 03.40 are correct, but it does not mean what you concluded. The following flow will help explain this.

Imagine the following connectivity (<> indicates a SMPP connectivity):

ESME#1 <> SMSC#1 <> ESME#2

Here are some of the events that will take place:

1. ESME#1 sends a submit_sm to SMSC#1 with delivery receipt request.

2. SMSC#1 sends back a submit_sm_resp, with a message_id=1000 (which is generated by SMSC#1).

3. SMSC#1 forwards the message via a deliver_sm to ESME#2.

4. ESME#2 sends back a deliver_sm_resp, with a message_id=2000 (which is generated by ESME#2).

   Note: Though SMPP 3.4 spec does not mention this, many implementations put a message_id to support delivery receipt.

5. SMSC#1 receives the deliver_sm_resp. Now it has to remember to match message_id=2000 from ESME#2 to it's message_id=1000.

6. Later on ESME#2 sends back submit_sm with a delivery receipt for message_id=2000 to SMSC#1.

7. SMSC#1 maps message_id=2000 from ESME#2 to it's message_id=2000.

8. SMSC#1 creates a deliver_sm for message_id=1000.

If SMSC#1 fails to remember to map the message_ids properly, it can send wrong message_id to ESME#1. That can create all sorts of confusions (like it did in your case).