This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Holger,
On Tue, Feb 15, 2011 at 12:55:52PM +0100, Holger Hans Peter Freyther wrote:
> The question is still what we want to fuzz. The strong point of GSM 08.08 is
> that it is 'connection' based. We do have a connection (maybe over multiple
> lchan's) to a MS and GSM 08.08 is quite good at sending messages to the MS.
But we only have 08.08 support if you run osmo-bsc, at which point you loose
all the MM common procedures,etc. The requirement seems to be flexibility,
i.e. being able to use any or all of the bsc_hack features and configure
flexibly what you want.
Tobias and I have now discussed an alternative approach: Filtering. Something
similar to NF_QUEUE, where all incoming/outgoing RSL(RLL) messages are routed
through an external application first. The app can then simply allow them to
pass, filter them, modify or replace them with something completely different.
This has the advantage that you can benefit from the existing MM and CC state
machines in OpenBSC, but can simply modify individual messages or IEs inside
messages, without having to care about much else.
It would then be a per-subscriber property if messages from/to him are to
be relayed through that external filter app or not. The per-subscriber
property then propagates down into a per-lchan property.
Regards,
Harald.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)