On Mon, 19 Dec 2016, Harald Welte wrote:
thanks for your quick answer.
now sorry for my late answer :)
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.
information that can be used by an external program without having to implement that which is already in osmo-tetra. this would be:
- signalling data (d-setup, d-sds etc) with the fields (SSI etc) in some easy to interpret format (xml is fine)
- binary data (voice frames, data frames etc), maybe along with a little bit of metadata
- "housekeeping data" that is internally generated, but is useful for the application (telive version, frame count, information if the decoder is currently picking up frames, error rates etc)
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 :)
you're right. on the other hand there is not that much pdu types which are interesting to me (d-setup, d-release etc), and if someone needs to implement yet another pdu, then he can easily do it.
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.
this looks like a *LOT* of work (at least to me). i'd start with what is already implemented.
btw i was also thinking about xml. unfortunately there will be overhead. currently you can run the code (gnuradio, qpsk decoder, my fork of osmo-tetra and telive) on a raspberry pi 3, and this can work for 2-3 channels simultaneously. i'm not sure this will still be possible with a full blown xml implementation, but we'll see.
any thoughts aout the interface to other applications? my fork just sends everything in udp packets (which can get lots/reordered etc). there must be a better way (tcp is not one of them). any ideas?
jacek