Project

General

Profile

Bug #4740

MSC stores an SMS in the database if the ESME is not bound

Added by keith about 2 months ago. Updated 18 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
09/01/2020
Due date:
% Done:

90%

Resolution:
Spec Reference:

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

Related to OsmoMSC - Bug #2354: SMSC: Store&Forward not working for subscribed but unregistered MSResolved07/06/2017

History

#1 Updated by keith about 2 months ago

  • Related to Bug #2354: SMSC: Store&Forward not working for subscribed but unregistered MS added

#2 Updated by keith about 2 months ago

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

#3 Updated by keith about 2 months 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.

#5 Updated by laforge about 2 months 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.

#6 Updated by keith about 2 months 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."

#7 Updated by keith 18 days ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 90

Patch is merged

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)