When using SMSC Gateway in a "hub" mode (e.g. where messages are passed between SMPP connected peers) this presents issues relating to message IDs and DLR matching.
One of the solutions described is to use data_sm instead of submit_sm or deliver_sm as this always supports the exchange of message IDs. This requires the SMSC on both sides of the SMPP connection to support this.
Currently Restcomm SMSC only supports CLIENT (where outbound messages are delivered via submit_sm) and SERVER (where outbound messages are delivered via deliver_sm).
It would seem to be useful to support a "HUB" mode SMPP connection where outbound messages are sent using data_sm and message IDs are handled appropriately.
/kind feature
When using SMSC Gateway in a "hub" mode (e.g. where messages are passed between SMPP connected peers) this presents issues relating to message IDs and DLR matching.
The following web page explains it well: https://www.nowsms.com/sms-hubbing-considerations
One of the solutions described is to use data_sm instead of submit_sm or deliver_sm as this always supports the exchange of message IDs. This requires the SMSC on both sides of the SMPP connection to support this.
Currently Restcomm SMSC only supports CLIENT (where outbound messages are delivered via submit_sm) and SERVER (where outbound messages are delivered via deliver_sm).
It would seem to be useful to support a "HUB" mode SMPP connection where outbound messages are sent using data_sm and message IDs are handled appropriately.