Message ID for SMS submission and delivery not the same

孤街浪徒 提交于 2019-12-06 05:53:21

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).

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.

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!