Detailed information about the new feature request
1. What motivated the request:
In a clustered SMSC environment, where multiple SMSC are service requests, the
message_id returned in a submit_sm_resp may be duplicated across multiple SMSC.
This can cause confusion to 3rd party, who may be expecting completely unique
message_id.
Perhaps a configurable value can be prefix/suffix to the message_id before it
is returned. Keep in mind that the overall length of the message_id generated
by the system will need to be reduced by the length of the configurable value
so as to keep overall length within the spec. For our purposes a single
character is fine and would allow (A-Z,0-9) 36 unique smsc in a cluster. A dual
character would allow 36^2.
According to the SMPP 3.4 spec
submit_sm_resp has message_id which is a Variable length 65, C Octet String
This field contains the SMSC message ID of the submitted message. It may be
used at a later stage to query the status of a message, cancel or replace the
message.
5.2.23 message_id
The unique message identifier reference assigned by the SMSC to each submitted
short
message. It is an opaque value and is set according to SMSC implementation. It
is returned by the SMSC in the submit_sm_resp, submit_multi_resp,
deliver_sm_resp and data_sm_resp PDUs and may be used by the ESME in
subsequent SMPP operations relating to the short message, e.g. the ESME can use
the query_sm operation to query a previously submitted message using the SMSC
message_id as the message handle.
Original issue reported on code.google.com by wasimb...@gmail.com on 9 Dec 2012 at 7:40
Original issue reported on code.google.com by
wasimb...@gmail.comon 9 Dec 2012 at 7:40