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 Neels,
On Mon, Nov 27, 2017 at 01:30:01PM +0100, Neels Hofmeyr wrote:
> On Fri, Nov 24, 2017 at 08:28:35PM +0100, Harald Welte wrote:
> > so e.g. A-bis RSL would first have to be implemented. The good part is
> > that it's actually super easy using the expressive syntax of the TITAN
> > "raw" codec. Basically you define the structure of the data in files
> > like http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_RR_Types.ttcn
> > and you don't have to write a single line for encoding/parsing :)
>
> So you write a "titan struct" and get the binary en/decoding from it, even with
> conditional presence and cross conditions and all. nice.
Correct. A partial RSL implementation can be seen at
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/RSL_Types.ttcn
My plan is to use this together with the A code for BSC level tests, so one can
perform some procedure/activity on both A-bis and A and test if the BSC does what's expected.
> Makes me think, could one use that in production code to parse/encode messages?
I wouldn't want to try, at least not on the kind of low-performance systems that
we normally work on.
> It's C after all, isn't it.
It's C++.
> I wonder what its C representation looks like,
You can simply compile a the TTCN module ("make compile") and you get the resulting
generated C++ code.
> whether it makes working with it any easier than the TLV code we're using.
I think our TLV dode is exceptionally comfortable for a very
low-overhead C-language approach. What is the difficulty? Of course it
only handles the TLV structure and not the content of any IE. But
that's because it is a TLV parser and not anything else...
--
- 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)