Project

General

Profile

Actions

Bug #4268

open

duplicate SMS when SMPP handler sends back to the originating MSC

Added by neels over 4 years ago. Updated almost 4 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
-
Start date:
11/16/2019
Due date:
% Done:

60%

Spec Reference:

Description

When receiving an SMS from a phone, the SMS is added to the sms.db, then handled.
When receiving an SMS from SMPP, also, the SMS is added to the sms.db, then handled.
Now, if handling the SMS sends it to SMPP, that SMPP decides (mslookup) that it goes back to the same MSC, then the same SMS comes back and is added again.

When it is being delivered, the subscriber is connected, and hence SMS delivery is done immediately for both instances of the same SMS.
(IIUC this saves us an infinite MSC -> SMPP -> MSC -> SMPP loop)

possible solutions...?

- the SMPP handler must not send back to the same MSC, instead it must respond with "subscriber unknown" so that osmo-msc attempts to handle the SMS internally?
Detect if the mslookup IP:port for SMS delivery == the esme handler's msc's SMPP IP:port.
Breaks if more than one IP reaches the MSC's SMPP, e.g. osmo-msc listens on 0.0.0.0, the esme connects via 127.0.0.1 and mslookup responds with a public IP :/

- Somehow mark the SMS so that osmo-msc detects a round-trip SMS and avoids adding the same message to the db again?

- Somehow mark SMS differently, by config: if smpp-first is on, then SMS received via RAN must never go back to RAN, received via SMPP may be delivered to RAN...

- just before sending an SMS to SMPP, mark it in the DB as sent? (and if sending fails, undo that marking?)

we can't really generally skip adding SMS to the DB, because in both cases of incoming SMS we need to first queue it in the DB, for spooling and everything else...

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)