ESME_RINVMSGID in SMPP
What is ESME_RINVMSGID?
ESME_RINVMSGID (Error Code: 0x0000000C) is an SMPP error indicating that the provided message ID is invalid or not recognized by the SMSC.
Possible Causes
- The
message_id
field in the request is missing or incorrectly formatted. - The message ID does not exist on the SMSC.
- The message ID has expired or been deleted from the SMSC's database.
- A previously used message ID was provided instead of a valid one.
- The message ID is not associated with the ESME (External Short Messaging Entity) making the request.
When Does It Happen?
This error occurs when sending an SMPP PDU (such as query_sm
or cancel_sm
) with an invalid or unrecognized message ID.
Example SMPP PDU Transaction
Incorrect query_sm
PDU (Invalid Message ID)
0000001D (Length) 00000003 (Command ID for query_sm) 00000000 (Command Status) 00000002 (Sequence Number) 00000000 (Service Type) 31323334 35363738 39300000 (Invalid Message ID: "1234567890")
Response PDU (query_sm_resp
) with ESME_RINVMSGID
00000010 (Length) 80000003 (Command ID for query_sm_resp) 0000000C (Command Status - ESME_RINVMSGID) 00000002 (Sequence Number)
Issue: The message ID provided ("1234567890") is either incorrect or not found in the SMSC database.
How to Solve It?
- Ensure the correct message ID is being used from a previous
submit_sm_resp
response. - Verify that the message ID has not expired or been removed from the SMSC.
- Check for any formatting errors in the
message_id
field (e.g., missing null terminator). - Confirm that the message ID belongs to the ESME making the request.
- Enable debugging logs to inspect the exact values being sent in the PDU.
If the issue persists, contact the SMSC provider to check the validity of the message ID.
Ozeki findings
Over the years we have found this error is commonly caused by incorrect SMPP implementation on the server side of some SMPP service providers. This error will likely happen if a phone number ends in 0.
Hint: Use our Free Online SMPP PDU Decoder tool to understand your SMPP PDU
The reason for this is that some SMPP service provider implementations don't parse the SMPP PDU as a series of bytes, but they parse it as a HEX string. In their implementation they find the 00 string termination sequence with the following code:
let nullIndex = input.indexOf('00', offset); if (nullIndex === -1) { // If no null terminator found, read to end or next field nullIndex = input.length; }
If a phone nubmer ends with 0, the hex representation of the phone number does not end with a double zero '00'. It ends with a tripple zero '000' like this:
333132383838353036333000 (+31288850630)
Notice the three zeros at the end.
So the above code will incorrectly calculate the string length because it detects the first occurance of 00.
This will result in an incorrect offset calculation which will render the rest of the decodeing process problematic. The most likely finding for them will be "invalid message id", because the 1 byte invalid offset will push the DCS byte into the Message ID field. The DCS is usuall 8, which is not valid for MSG ID.
To help them fix the error, here is the proper way to do this decoding:
for (let i = offset; i < input.length - 1; i += 2) { if (input.substr(i, 2) === '00') { nullIndex = i; break; } } if (nullIndex === -1) { // If no null terminator found, read to end nullIndex = input.length; }
But the best solution for such SMPP service provider would be to buy an Ozeki SMS Gateway license.