Bug #4740
closedMSC stores an SMS in the database if the ESME is not bound
90%
Description
If I send an SMS with smpp-first, and a default route configured, but the esme is not bound, then osmo-msc stores the SMS in the database and we tell the sending phone that the message was "sent".
This IMO is incorrect as we will possibly then never deliver this message, depending on if it is for the local system or a remote system.
The behaviour previously (nitb) was to return GSM411_RP_CAUSE_MO_NET_OUT_OF_ORDER, forcing the sender phone to try sending again later, (when hopefully the system is in working order and the ESME is bound)
Related issues
Updated by keith over 3 years ago
- Related to Bug #2354: SMSC: Store&Forward not working for subscribed but unregistered MS added
Updated by keith over 3 years ago
I think this might have been introduced in the commits referencing the related issue. #2354
Updated by keith over 3 years ago
If we use the internal database to queue messages that are temporarily undeliverable due to the ESME not being available, then we would need to flag them as "outgoing" or some such, and have a mechanism to retry delivery via the ESME.
Updated by keith over 3 years ago
Updated by laforge over 3 years ago
I'm not entirely sure what the semantics for 'smpp-first' should be. I think that was
a feature introduced specifically for Rhizomatica?
In terms of normal SMPP routes, I would expect a SMS to never be stored
in a database if the route points to SMPP. Either the ESME is available
and the submission of the MO-SMS succeeeds, or the ESME is not available
and submission fails.
Updated by keith over 3 years ago
laforge wrote:
I'm not entirely sure what the semantics for 'smpp-first' should be. I think that was
a feature introduced specifically for Rhizomatica?
Not 100% sure, but I think that's correct. I also think that it's not really 'smpp-first', rather 'smpp-only', as in: - don't fall back to local delivery if for some reason the ESME says no - That would bypass accounting and control done in the ESME!
I also wonder do we need default-route and smpp-first?, is the later not implicit? - Then if you are operating a local network with only the local DB, then don't define an ESME at all?
In terms of normal SMPP routes, I would expect a SMS to never be stored
in a database if the route points to SMPP.
Unless we wanted to use the DB as a queue for an unreachable ESME situation. (I'm not saying we should, I'm not saying I even want that.)
Either the ESME is available
and the submission of the MO-SMS succeeeds, or the ESME is not available
and submission fails.
Right, and that's what this patch does. #4740-4
However, I guess there is scope here to clarify, in comments, or in code paths as to what is MO and what is MT and also what is MT but submitted via smpp, as opposed to MO->MT. I intend to do some work on that, but promises of vapour-patches aside, I don't see at this moment a reason not to go ahead with this one. I guess there should be a test case,
simple i suppose, "MO SMS submitted to smpp-first ESME while not connected should result in failure."
Updated by keith over 3 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 90
Patch is merged
