Dear all,
In this mail I would like to negotiate and discuss some details about further development of the Osmocom CNI, in particular the way of handling of SMS messages.
At this time, all SMS messages within the Osmocom CNI are terminated at OsmoMSC. There we have some basic routing configuration, either internal, or SMPP. This approach has some disadvantages, at least:
- MSC is not a proper place for terminating SMS messages, in commercial networks it's usually done by SMS Center;
- in case if a network based on the Osmocom CNI does contain multiple MSCs, one has to configure / update the SMS routing configuration for each MSC individually;
- one would have to use SMPP in order to deliver SMS messages to / from commercial networks, which in most cases "speak" either MAP, or DIAMETER, or even both, but not SMPP;
- using SMPP (as it's the only external interface available) involves the need to encode and decode complex SMS protocol, what is not desired in some situations.
This is why it was decided to rip the SMS routing out of OsmoMSC, and use generic (for Osmocom CNI) GSUP protocol as the transport. Please see OS#3587 for more details about "SMS over GSUP".
So, we actually need a separate process, let's call it "OsmoSMSC" in quotes for now, as I am not sure about the proper name. It should implement at least basic functionality of the SMS Center. Since we are using OsmoHLR as the main / central gateway in the Osmocom CNI for all GSUP communications, this to be discussed "OsmoSMSC" should basically be connected to OsmoHLR.
What I would like to discuss is how should we implement "OsmoSMSC"? I think there are two possible ways: either write it from scratch, or fork some existing project. Implementing from scratch would require much more efforts and time than forking an existing SMSC implementation, for sure.
I've recently discovered a project called Kannel - an Open Source WAP and SMS gateway written in C and distributed under the Kannel Software License, please see: https://www.kannel.org/index.shtml
What do I personally like:
- helpers for OTA configuration (e.g. WAP, MMS settings) messages; - written in C and using automake as the build system; - high performance (hundreds of messages per second); - 7-bit, 8-bit and Unicode message coding.
So we could fork this project as "OsmoSMSC", and extend in the following way:
- integrate generic Osmocom logging; - integrate VTY interface and generic configuration; - implement GSUP client from OsmoHLR.
I already started to read the source code and documentation. If anyone has any experience with Kannel, please share!
And finally, how should we name "OsmoSMSC"? :)
With best regards, Vadim Yanitskiy.
On Mon, Oct 08, 2018 at 07:50:43PM +0700, Vadim Yanitskiy wrote:
So we could fork this project as "OsmoSMSC",
Is there a hard reason to fork it? Couldn't we just contribute the GSUP connection to upstream and use that then?
I mean, it would be nice to have the same logging and config scheme as other osmo programs, but unless Kannel is completely non-maintained, I don't think that's worth considering a fork for...?
~N
On 08/10/18 13:50, Vadim Yanitskiy wrote:
If anyone has any experience with Kannel, please share!
Hi Vadim.
Rhizomatica still uses kannel fairly extensively in the "RCCN", although our plan is to remove it ASAP. It was chosen initially as a FOSS possibility to link the osmo-nitb SMPP interface to python.
We setup a kannel ESME that receives SMS and forwards them to a REST service listener (the python daemon) The python daemon then processes the message, (checks authorisation, routing) and forwards it to a kannel HTTP listener which forwards the message on to the SMPP side of the nitb.
Now, i haven't looked much at the code, although I did once take a look at something to see why multipart messages were getting messed up internally. The reason is that kannel concats multipart messages received by the kannel ESME and forwards them using the charset of the first message part, which may not be necessarily the same as any subsequent message part :((
Character set translation support seemed incomplete, and support for GSM 03.38 shift tables is totally absent! :((
Your mail prompts me to look at the kannel website, and I note that a new stable version is relatively recently released. So some work has been done, previous to that it seemed to be abandoned.
What I did spent quite a lot of time with in relation to kannel, was reading documentation (which I initially found somewhat inaccessible), testing configuration and general usage.
During this time, I got the impression that kannel is far from being a SMSC, but is a "WAP gateway" - rather a kind of bulk SMS processor, a HTTP gateway to submit (spammy) SMS, or for working with things like short code processing. I'm not aware of any Core Network SMS center type functionality within kannel. Kannel can connect to other SMSC but there's no SMSC as such within. IIRC there isn't even any non-volatile store and forward support. I think (again from memory) that there is some database storage but only for delivery reports. Maybe something has been added in the 2018 work.
I therefore have been working scantly on a python based ESME, using python-smpplib. I'm not a python programmer though so it's very much prototype work, and probably very bad python, but I'll publish something "soon" :-/
Also python-smpplib is not perfect, (mainly I think because of a lack of real world implementations based on it) and I got held up sometimes by having to fix things in python-smpplib. The maintainer is sometimes active, and sometimes quite absent. Pau did some work on python-smpplib for the osmo-gsm-tester (i think) and although he submitted some patches, I think there was some suggestion that it could do with a complete re-write.
I'd maybe consider forking and fixing python-smpplib, and writing an SMSC in python.
If one wanted to work on OsmoSMSC in C, there may be many things of use in the kannel code that could be of used (instead of the libsmpp in the case of SMPP), but I don't know if that's helping in terms of effort? Also, I think then that the resulting product would not really be "fork" of kannel, but rather a completely different product, so we'ld probably spend a lot of time stripping out what we don't want. Maybe that still makes sense?
There is also Holger's smalltalk SMSC, which I think was written to be an actual SMSC.
Keith.
.
-
Keith -
Neels Hofmeyr -
Vadim Yanitskiy