Hi! I'm just writiing this up as you mentioned that you were considering to look into implementing an external SMSC. This is great news, and of course you can do it whatever way you want to do it.
However, to put things a bit more into perspective and ensure that this
SMSC can also be used in a real GSM core network later on, I would like
to ask you to consider staying in line with how the
primitives/transacitions look like in a real GSM network.
The idea here is that with every new interface we introduce in
osmo-nitb, we should try ot move towards that of a real network. This
does't mean that it has to implement the actual detailed MAP/TCAP/SCCP
encoding as specified, but simply that they semantic of the
primitives/messages and their order and time of occurrence is the same.
>From the osmo-nitb "MSC" point of view, this means that the following
primitives have to be implemented:
* incoming MT-FORWARD-SM.req from external program
* positive/negative MT-FORWARD-SM.resp depending on success of transfer
* outgoing READY-FOR-SM.req in case a subscriber is coming online
and/or we get a SMMA
* outgoing MO-FORWARD-SM.req to external program
As osmo-nitb at the moment still includes the HLR (which I desparately
want to change), it probably should implement the procedures related to
SMS delivery:
* no need fro SRI-FOR-SM!
* incoming REPORT-SM-DELIVER-STATUS.req, noting down that the SMSC
has requested to be informed once a subscriber is back online
* outgoing ALERT-SERVICE-CENTRE.req to SMSC once the subscriber
really is back online.
Now the desing questions are:
* do you agree that we should align with those primitives?
* If yes,is it really worth coding a custom protocol for them, or should
we rather already use at least the MAP encoding, but ignore the
complex TCAP transaction state machines and SCCP routing? There's
already libosmo-asn1-map which should be able to parse and generate
the 'real world' data structures. The extra effort is probably
limited, and if the messages are then simly sent over a raw TCP (IPA)
connection, there is no SS7 complexity.
Please let me know what you think. If you think it is worth it, I can
think a bit more about the detailed message structure / interfaces,
given that I've spent my fair share of writing SCCP, TCAP and MAP code
over the last year or so...
Regards,
Harald
--
- Harald Welte <[email protected]> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
<<attachment: mt_sms_delayed.png>>
