Revamping osmo-tetra

Harald Welte laforge at
Sun Dec 18 23:32:23 UTC 2016

Hi Jacek,

thanks for your quick answer.

On Sun, Dec 18, 2016 at 11:29:57PM +0100, Jacek Lipkowski wrote:
> Thanks for the invitation. I'd also like to see the code im mainline. The
> only reason for the fork was that it was far too ugly to send you patches :)

Well, I also didn't really pay any attention to osmo-tetra during recent
years, but I finally merged the gr3.7 branch and some of the smaller
fixes (etsi voice codec download script, etsi voice code 64bit,

> Yes, i have the energy. time is a bit of a problem, but i'm working on it :)

I know the feeling, no worries.

> The problem with my code is that it was written for a particular purpose
> (which was running telive), and is really really ugly. It would be better to
> agree on a nice standardised way to get data from osmo-tetra to external
> programs (not gsmtap, i want cooked data, not raw). 

The question is what kind of information you're relly looking for.

Parsing all the data in hand-crafted C code and then re-encoding it into
some other intermediary format doesn't really seem like a great idea,
unless you have an army of developers at hand who like to do that :)

The wireshark tetra dissector solved that problem by transcribing the
TETRA messages as ASN.1 with UPER encoding rules.  We could do something
similar and use asn1c to do an automatic "transcoding" to XER (XML
Encoding Rules) or simply pass the parsed C structures generated by
asn1c around.

Yes, XML is ugly.  But a generic, machine-parseable interpretation
is quite usefulU, and the number of signalling messages on a tetra
channel is quite low, i.e. the CPU overhead might not be that much of a
problem.  Unfortunately asn1c doesn't have JSER or GSER support,
otherwise that would have been my preference over XER.

but I digress.  Let's start with you explaining a bit (maybe with
example data) what kind of information you actually need.

Looking forward to working together.

- Harald Welte <laforge at> 
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

More information about the tetra mailing list