Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

I think this might have been introduced in the commits referencing the related issue. #2354

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.

Submitted https://gerrit.osmocom.org/#/c/osmo-msc/+/19935/

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."

Patch is merged