SMSC与ESME间投递回执收发机制及SUBMIT_SM区分疑问

Great question—let’s break this down clearly because SMPP’s message flow can get tricky when mixing up message submissions vs. receipts.

1. How ESME Sends a Receipt for a Message Received from SMSC #

First, let’s clarify the standard flow here: when the SMSC sends a message to your ESME (using a DELIVER_SM PDU—this could be a mobile-originated message, a delivery receipt for a message you previously sent, or a third-party message), you don’t need to send a SUBMIT_SM to confirm receipt.

The correct, protocol-compliant way to acknowledge you’ve received the SMSC’s DELIVER_SM is to send back a DELIVER_SM_RESP PDU. This response must use the same sequence_number as the incoming DELIVER_SM—that’s how the SMSC maps your response to the exact message it sent. This acts as your "delivery receipt" for the SMSC’s outgoing message to you.

If your use case is different—say, your ESME is acting as a gateway and needs to send a delivery status report about a message you forwarded to a terminal back to the SMSC—then you would use SUBMIT_SM, but with specific flags to mark it as a receipt (more on that below).

2. How SMSC Distinguishes a Receipt from a Regular SUBMIT_SM #

If you do need to use SUBMIT_SM to send a delivery receipt (e.g., reporting that a message you received from the SMSC was successfully delivered to an end device), the SMSC relies on key parameters in the SUBMIT_SM PDU to tell it apart from a regular text message:

• esm_class: Set this to 0x04 (for SMPP v3.4/v5.0). This bitflag explicitly marks the PDU as a delivery receipt. Some older implementations might use 0x02, but 0x04 is the standard for status reports originating from an ESME.
• message_id: Populate this with the original message_id that the SMSC returned to you in the SUBMIT_SM_RESP (or DELIVER_SM if it was an incoming message you’re reporting on). This links your receipt directly to the original message the SMSC cares about.
• short_message: Format the content as a standard delivery receipt string (per SMPP specs), e.g.:

  id:XYZ789 sub:001 dlvrd:001 submit date:2403151430 done date:2403151432 stat:DELIVRD err:000 text:Test Msg
  

  This structured text lets the SMSC parse the exact delivery status, timestamps, and error codes.

SMSC systems are built to check these parameters first—if esm_class flags a receipt and the message_id matches a known message, it will process the SUBMIT_SM as a status update instead of queuing it as a new outbound message.

A quick recap: Use DELIVER_SM_RESP to confirm you’ve received an SMSC-sent message. Use SUBMIT_SM only when you need to proactively report delivery status of a message you handled, and mark it with the right esm_class and message_id to avoid confusion.

内容的提问来源于stack exchange，提问作者karthi keyan