Bug #3260
closedImplement libosmo-abis input for new E1 interface
100%
Description
The libosmo-abis input drivers (so far dahdi + misdn) need to be extended to access the USB (and/or UDP based) osmocom E1 interface.
http://git.osmocom.org/libosmo-abis/tree/src/input/dahdi.c can be used as an example.
The existing drivers expect to be able to- open individual file descriptors (/dev for dahdi, sockets for misdn) for each time-slot
- specify whether the want the raw bit-stream or expect the driver/hardware to do HDLC (de)framing within that timeslot
So it might make sense to have some other external process that offers this "one FD per timeslot" notion to libosmo-abis. This process would then be talking to the USB device (or exchainging UDP frames) with the E1 LIU, and do the timeslot de-mux + HDLC processing.
Another idea might be to actually integrate with DAHDI itself. This has the advantage that the E1 interface can be used with other software such as asterisk. But then, as DAHDI is an out-of-tree/mainline kernel patch, I think we'd rather keep independent of that and make sure that with our new E1 adapter, neither the Linux kernel nore DAHDI are a requirement, and we just need libusb or UDP sockets with no other dependencies.
Related issues
Updated by laforge almost 6 years ago
- Assignee set to laforge
laforge wrote:
So it might make sense to have some other external process that offers this "one FD per timeslot" notion to libosmo-abis. This process would then be talking to the USB device (or exchainging UDP frames) with the E1 LIU, and do the timeslot de-mux + HDLC processing.
actually, this is rather important. Only if we have individual, per-timeslot interfaces (such as fd/sockets), we can have OsmoBSC attach to the signaling timeslots but OsmoMGW attach to the traffic timeslots. So this is one important argument in favor of having an external process/damon handling E1.
The overall picture then looks like this:
Updated by laforge almost 5 years ago
- Related to Feature #3965: ICE40 based USB E1 adapter added
Updated by laforge over 4 years ago
- Related to Feature #2659: prepare osmo-mgw architecture for other endpoint types added
Updated by laforge about 4 years ago
- Status changed from New to Resolved
- Assignee changed from laforge to tnt
- % Done changed from 0 to 100
tnt actually did this already with his @osmo-e1d
project, including related client library and libosmo-abis integration.
- see https://git.osmocom.org/osmo-e1d/ for the current daemon code
- see https://git.osmocom.org/libosmo-abis/commit/?id=b559a5326371fa88dafd82d9fa6f9117442a6f70 and an entire series of commits following-up to it.