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...