Overview
The error "SMSC storage failure" and "ESME Receiver Reject Message Error Code" occurs when sending Arabic Telepin SMS messages. This issue is not due to the Arabic content but is related to message segment length exceeding the limit due to SAR headers. The RTR Operator Manual indicates that SAR headers consume 6 or 7 bytes, necessitating a message segment limit of 133 bytes to avoid rejection errors.
Information
Error Message: "SMSC storage failure" and "ESME Receiver Reject Message Error Code"
Cause: The issue arises from message segments exceeding the length limit due to SAR (Segmentation and Reassembly) headers, which consume 6 or 7 bytes, leaving less space for the actual message payload.
Resolution Steps:
-
Identify the Affected Messages:
- Review logs for messages with rejection errors.
- Check message segment lengths in the logs.
-
Adjust Message Segment Length:
- Limit each message segment to 133 bytes or less.
- Ensure that the application divides long messages into segments that account for SAR header size.
-
Verify Resolution:
- Send test messages with adjusted segment lengths.
- Confirm successful delivery without rejection errors.
Technical Details:
- GSM SMS standard allows 140 bytes per message segment.
- Concatenated messages using SMPP SAR fields require a User Data Header (UDH).
- UDH consumes 6 or 7 bytes, depending on encoding and segment handling.
- RTR may dynamically choose between 6 and 7 bytes, making 134-byte segments unreliable.
Important: Always cap message segments at 133 bytes to ensure compatibility across all scenarios.
Frequently Asked Questions
- How do I know if this error applies to my situation?
- You'll see rejection errors such as "SMSC storage failure" or "ESME Receiver Reject Message Error Code" when sending SMS messages, particularly with Arabic content.
- Why is the 133-byte limit recommended?
- The 133-byte limit accounts for the maximum possible SAR header size (6 or 7 bytes), ensuring message delivery without rejection errors.
- What if I see 134-byte segments being accepted?
- Some 134-byte segments may pass due to a 6-byte header scenario, but since the RTR may apply a 7-byte header, using 134 bytes risks rejection. It's safer to cap at 133 bytes.
- What should I do if the issue persists after adjusting segment lengths?
- Ensure all message segments are strictly capped at 133 bytes. If issues persist, review logs for any additional errors or contact support for further assistance.
Mohammed Amer
Comments