Feature #4254
closedintegrate mslookup mDNS client in an SMPP handler
100%
Description
Taking rhizomatica's smpp.py SMS handler as basis, integrate mslookup to send SMS to remote MSCs.
Updated by osmith over 4 years ago
There was some confusion about where this should actually be integrated (e.g. besides smpp.py, esme.py was also mentioned). So I've looked RCCN: https://github.com/Rhizomatica/rccn
This is my understanding:- smpp.py and esme.py:
- connect to OsmoMSC (OpenBSC) on the SMPP port 2775
- create a handler for incoming messages
- forward these messages in various ways (e.g. smpp.py forwards it to a remote instance of the HTTP server of rapi.py)
- rccn.py:
- chat() is called by freeswitch on incoming SMS
- it sends it via HTTP to a local instance of rapi.py to /chat and lets it process in the background
- rapi.py: /chat handler starts a new thread, calling receive from sms.py
- sms.py receive: filters messages, eventually calls send()
- sms.py send: HTTP posts to kannel/remote RAPI server OR sends it to local SMSC listener (-> OsmoMSC!)
For our DGSM/mslookup proof of concept, I will adjust the simple dialplan example we have already created (which resolves calls properly already) to do a simplified version of the rccn code patch towards OsmoMSC:
Freeswitch -> dialplan -> mslookup by msisdn, returns SMSC IP/port -> send the message via smpp to the received SMSC IP
Sending to SMSC can be done with python-smpplib, which RCCN is also using.
The bigger picture then looks like this:
MS A -> BTS A -> BSC A -> MSC A -> osmo-sip-connector A -> SIP server A -> dialplan A -> mslookup A (HLR B responds with MSC B IP/port) -> MSC B -> ... -> MS B
keith: please correct me if I have gotten something wrong.
Updated by osmith over 4 years ago
Turns out, that osmo-sip-connector does not support forwarding SMS to the SIP server. After talking to Neels, we decided to implement a simple SMPP handler like RCCN's smpp.py.
Updated by osmith over 4 years ago
- % Done changed from 0 to 80
Implemented a basic smpp handler, based on RCCN's esme.py: osmo-msc.git/contrib/esme_mslookup.py (branch osmith/dgsm).
This forwards (simple, non-multipart etc.) SMS from MSC A to MSC B, and uses osmo-mslookup-client to determine the IP and port of MSC B by the receiver's MSISDN.
I'm starting a thread for each incoming message, so the SMPP handler doesn't block until mslookup has answered.
Here is example output, with an extra 10 second sleep after doing the mslookup request:
$ contrib/esme_mslookup.py --sleep=10 [11:49:58] (MainThread) Connecting to 127.0.0.1:2775... [11:49:58] (MainThread) Connected to source SMSC (OSMPP@127.0.0.1:2775) [11:49:58] (MainThread) Waiting for SMS... [11:50:10] (ForwardSMSThread#0) Thread started [11:50:10] (ForwardSMSThread#0) mslookup: smpp.sms.100.msisdn 20191115115010729 DLMSLOOKUP ERROR received something that is not a valid mDNS answer, ignoring [11:50:11] (ForwardSMSThread#0) mslookup result: {"query": "smpp.sms.100.msisdn", "result": "ok", "v4": ["127.0.0.1", "2775"]} [11:50:11] (ForwardSMSThread#0) Sleeping for 10 seconds [11:50:16] (ForwardSMSThread#1) Thread started [11:50:16] (ForwardSMSThread#1) mslookup: smpp.sms.100.msisdn 20191115115016392 DLMSLOOKUP ERROR received something that is not a valid mDNS answer, ignoring [11:50:17] (ForwardSMSThread#1) mslookup result: {"query": "smpp.sms.100.msisdn", "result": "ok", "v4": ["127.0.0.1", "2775"]} [11:50:17] (ForwardSMSThread#1) Sleeping for 10 seconds [11:50:21] (ForwardSMSThread#0) Sleep done [11:50:21] (ForwardSMSThread#0) Connecting to 127.0.0.1:2775... [11:50:21] (ForwardSMSThread#0) Connected to destination SMSC (ISMPP@127.0.0.1:2775) [11:50:21] (ForwardSMSThread#0) Disconnecting... [11:50:21] (ForwardSMSThread#0) <smpplib.client.Client object at 0x7ff79022bfd0> is disconnecting in the bound state [11:50:21] (ForwardSMSThread#0) Thread is done [11:50:23] (ForwardSMSThread#2) Thread started [11:50:23] (ForwardSMSThread#2) mslookup: smpp.sms.100.msisdn 20191115115023684 DLMSLOOKUP ERROR received something that is not a valid mDNS answer, ignoring [11:50:24] (ForwardSMSThread#2) mslookup result: {"query": "smpp.sms.100.msisdn", "result": "ok", "v4": ["127.0.0.1", "2775"]} [11:50:24] (ForwardSMSThread#2) Sleeping for 10 seconds [11:50:27] (ForwardSMSThread#1) Sleep done [11:50:27] (ForwardSMSThread#1) Connecting to 127.0.0.1:2775... [11:50:27] (ForwardSMSThread#1) Connected to destination SMSC (ISMPP@127.0.0.1:2775) [11:50:27] (ForwardSMSThread#1) Disconnecting... [11:50:27] (ForwardSMSThread#1) <smpplib.client.Client object at 0x7ff79022bfd0> is disconnecting in the bound state [11:50:27] (ForwardSMSThread#1) Thread is done [11:50:34] (ForwardSMSThread#2) Sleep done [11:50:34] (ForwardSMSThread#2) Connecting to 127.0.0.1:2775... [11:50:34] (ForwardSMSThread#2) Connected to destination SMSC (ISMPP@127.0.0.1:2775) [11:50:34] (ForwardSMSThread#2) Disconnecting... [11:50:34] (ForwardSMSThread#2) <smpplib.client.Client object at 0x7ff79022bda0> is disconnecting in the bound state [11:50:34] (ForwardSMSThread#2) Thread is done
In my test setup, the message is arriving twice now at the receiving phone, I'll discuss with Neels what we do about that (might be fine, if used with "no smpp-first" option in osmo-msc.cfg?).
Updated by osmith over 4 years ago
osmith wrote:
In my test setup, the message is arriving twice now at the receiving phone, I'll discuss with Neels what we do about that (might be fine, if used with "no smpp-first" option in osmo-msc.cfg?).
This needs to be resolved, I'll look into it.
Updated by neels over 4 years ago
osmith wrote:
osmith wrote:
In my test setup, the message is arriving twice now at the receiving phone, I'll discuss with Neels what we do about that (might be fine, if used with "no smpp-first" option in osmo-msc.cfg?).
This needs to be resolved, I'll look into it.
The duplication is fixed by an osmo-msc patch I8c9b61dc05bda6f2b09cbc1890de1f2702f7abc8
IIUC SMS sent out to SMPP will now never be stored in the DB, which means any spooling becomes the task of the SMPP handler...
Updated by osmith over 4 years ago
- % Done changed from 80 to 90
Updated by osmith about 4 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100