duplicate SMS when SMPP handler sends back to the originating MSC
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)
- 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...
#1 Updated by neels about 1 year ago
- Status changed from New to In Progress
- Assignee set to neels
- % Done changed from 0 to 90
I have a fix for it: don't store in DB when delivering via SMPP.
I am not 100% sure about SMPP delivery error handling yet, it seems to me that we hand off responsibility to the ESME.
If there is an async response from the ESME we should probably tweak the patch so that if sms->smpp.ongoing is true, to immediately store a sent date to mark it sent, and if async error occurs remove that again...
#3 Updated by neels about 1 year ago
- % Done changed from 90 to 60
IIUC osmo-msc stores in the sms.db to asynchronously wait for the SMPP response, and finishes the entry when it is done.
So what apparently happens when the SMS comes back to the same osmo-msc: the recipient attaches, and then the entry
pending for the SMPP response is also sent, because it is still open.
But I haven't really understood that part of the code yet, also my point of view is that we don't need to work
too much with the sms queue but rather want to move to a separate SMSC entirely.
but it seems I need to revisit my osmo-msc patch there.