On Sat, Feb 20, 2016 at 07:54:11PM +0100, Holger Freyther wrote:
go left, pick up compiler-error
smpp_openbsc.c: In function 'deliver_to_esme':
smpp_openbsc.c:536: error: 'struct gsm_subscriber_connection' has no member named
'lchan'
smpp_openbsc.c:537: error: 'struct gsm_subscriber_connection' has no member named
'lchan'
Argh, my own build excludes SMPP for some reason, so I didn't catch that one
with my "guaranteed to catch all" method.
Anyway:
this is an interesting case. We want to annotate the
SMPP message with extra values of from where the SMS came from. This is possible in the
osmo-nitb and should probably remain possible. Do you see a way to make this work?
I haven't really investigated at all about plugging osmo-bsc back to osmo-cscn
with an A-interface, because the focus is so far firmly on IuCS.
Worst case we could introduce a "vendor specific" DTAP message sent to the MSC,
possibly a feature enabled by a vendor specific BSSMAP message sent by the MSC
fist?? (wildly guessing)
But I'll start off by enabling SMPP in my build ... :/
I am really late with this but as part of the bsc_api,
I envisioned that we
would have a msc_subscriber_connection if we ever split things up :}
Not that late really, I looked at bsc_api briefly but saw that it wasn't
helping for IuCS, so I postponed dissecting the (numerous) details of it
to another day. It should come naturally when the A-interface is created.
But in fact my foggy vision so far is that the struct bsc_api will not
actually survive, since the A-interface rx, like IuCS rx, will call
functions directly instead of keeping a struct of function pointers...
IMHO A clearly structured header file would do a nicer job at highlighting
the MSC<->BSC entry points. I am also presuming that we will drop
osmo-nitb as such and replace it with "please run osmo-bsc plugged into
osmo-cscn", BTW.
Thoughts welcome.
~Neels