How to configure the SMPP Registered Delivery Field

What is the Registered Delivery Field?

The Registered Delivery field in SMPP is a 1-byte bitmask in PDUs like submit_sm and data_sm that controls delivery receipts and acknowledgments. It enables senders to track message delivery status through SMSC-generated receipts. Key functions include:

  • Requesting final delivery receipts (success/failure)
  • Enabling intermediate delivery notifications
  • Handling SME (Short Message Entity) acknowledgments

Field Structure and Bitmask

Defined in SMPP v3.4, the field uses the following bitmask structure:

Bit Description
0 SMSC Delivery Receipt (0 = disabled, 1 = enabled)
1 SME Originated Acknowledgment (0 = disabled, 1 = enabled)
2 Intermediate Notification (0 = disabled, 1 = enabled)
3-7 Reserved
Note: Many SMSCs only support bit 0 (SMSC receipts). Confirm capabilities with your provider.

Common Values

Value (Hex) Binary Description
0x00 00000000 No receipts requested
0x01 00000001 SMSC delivery receipt only
0x03 00000011 SMSC receipt + SME acknowledgment
0x05 00000101 SMSC receipt + intermediate notifications

Use Cases

1. Basic Delivery Receipts

registered_delivery: 0x01  // Request final delivery status

2. High-Reliability Messaging

registered_delivery: 0x05  // Receipt + intermediate notifications

3. Two-Way Communication

registered_delivery: 0x03  // Confirm both SMSC and SME delivery

Example SMPP PDUs

Example 1: No Receipts (0x00)

0000001D  // Command Length (29 bytes)
00000004  // Command ID (SubmitSM)
00000001  // Sequence Number
00        // Source TON
00        // Source NPI
736F7572636500  // Source Address ("source")
00        // Dest TON
00        // Dest NPI
36353433323100  // Destination Address ("654321")
00        // ESM Class
00        // Protocol ID
00        // Priority Flag
00        // Schedule Delivery Time
00        // Validity Period
00        // Registered Delivery (0x00: No receipts)
00        // Replace-if-Present
00        // Data Coding (DCS=0x00)
00        // SM Default Message ID
07        // SM Length (7 septets)
C8329BFD06DDDF72  // Payload ("Hello!")

Example 2: SMSC Delivery Receipt (0x01)

0000001D  // Command Length (29 bytes)
00000004  // Command ID (SubmitSM)
00000002  // Sequence Number
...
00        // Validity Period
01        // Registered Delivery (0x01: SMSC receipt)
00        // Replace-if-Present
...

Example 3: Intermediate Notifications (0x05)

0000001D  // Command Length (29 bytes)
00000004  // Command ID (SubmitSM)
00000003  // Sequence Number
...
05        // Registered Delivery (0x05: SMSC receipt + intermediates)
...

Delivery Receipt Format

SMSCs return receipts via deliver_sm PDUs with a payload formatted as: 

id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:STATUS err:EEE

Example receipt for a delivered message: 

id:1896384752 sub:001 dlvrd:001 submit date:2310151430 done date:2310151431 stat:DELIVRD err:000

Interactions with Other Fields

  • esm_class: Bit 6 (delivery receipt flag) must align with registered_delivery settings
  • validity_period: Determines how long the SMSC will attempt delivery before sending a failure receipt
  • message_id: Critical for correlating receipts with original messages

Common Pitfalls

  • Enabling receipts but not listening to deliver_sm PDUs
  • Assuming all SMSCs support SME acknowledgments (0x02)
  • Mismatching registered_delivery and esm_class flags
  • Ignoring SMSC rate limits for receipt generation
Billing Note:
Some providers charge extra for delivery receipts. Confirm pricing before enabling.

Conclusion

The Registered Delivery field is essential for tracking SMS delivery status in SMPP. While basic receipt handling (0x01) is widely supported, advanced features like intermediate notifications require SMSC-specific testing. Always implement robust receipt parsing and correlate messages using message_id. For detailed behavior, consult SMPP v3.4 Section 5.2.17 and your provider's documentation.

More information