13 Jan
2017
13 Jan
'17
2:37 p.m.
On Mon, 19 Dec 2016, Harald Welte wrote:
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)
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. 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