MNCC and LCR

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.org
Mon Aug 10 15:10:31 UTC 2015


On Mon, Aug 10, 2015 at 12:24:17PM +0200, ☎ wrote:
> Having readily available protocol implementation as part of some
> library would make it a lot easier to implement. It'll also make
> protocol version tracking much simpler.

from my point of view there is nothing as a plain 'protocol
implementation', but you would basically have to invent portable/stable
data structures, associated APIs, etc.  Given that MNCC is not complex
but rather simply a way of encoding primitives that get shoved left and
right, I'm not sure what such 'yet another representation for the MNCC
primitives' would bring, except more code that needs to be written, and
that needs to be traversed.

>From my point of view, the header file is probably everything that you
would need to share.  From the very dispatch of the received primitives,
everything will be very much dependent on the actual MNCC handler (lcr,
freeswitch, etc.) who all have their own architecture, data structures,
etc.

The issue gets even more simplified by the fact that MNCC doesn't even
have a real/portable wire encoding (think of TLVs, ...) that's
independent of the 'structs' that we pass around over the socket.

Feel free to convince me otherwise, but at least so far I do not see how
that shared/common code would look like :)

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)



More information about the OpenBSC mailing list