Introducing E1 / Abis support to osmo-mgw

Hi Philipp (and lurkers on this list), I've just pushed an update to the @laforge/trau@ branch of libosmo-abis, which contains the new code modules for E1 / TRAU usage, and also a small test program and test data. The test program takes a raw binary dump created from an E1 timeslot with TRAU frames captured of a BS-11 and converts that to RTP packets. You can feed those RTP packets into osmo-gapk to play them back. The audio is clear, there are just a few seconds of quiet at the beginning before anything is audible. The patches also add an "I460" mode to e1_input. So from the osmo-mgw side, I think we need to * link against libosmo-abis and call e1inp_init + e1inp_vty_init() * use existing VTY code to configure E1 line numbers / drivers / ports * call e1inp_ts_config_i460() on every timeslot we want to use (this should *not* happen on all timeslots, as some of them are used for signalling by the BSC) * call osmo_i460_subchan_add() / osmo_i460_subchan_del() for each i.460 sub-slot we want to use * build the processing chain like in libosmo-abis/contrib/trau2rtp/trau2rtp.c via i460 -> trau_sync -> osmo_trau_frame_decode_16k/osmo_trau_frame_decode_8k -> osmo_trau2rtp I believe this should be at a stage where it can be integrated into osmo-mgw. The API may not be 100% stable yet, but it shouldn't change completely. The main missing bits are: * allow selection of sync pattern in trau_sync.c (or auto-detect?) * handling of T-bits for alignment of air-interface timing with downlink TRAU frame timing I will next be hacking on a small tool that will speak the 'osmo-e1d' protocol but use binary capture files that are looped over and over again. This way you should be able to use libosmo-abis e1_input without any physical card and still get TRAU frame data. At a lower priority, I'd like to look into support for HRv1 and AMR TRAU frames on 16k sub-slots. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)