Hi 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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)