Feature #5430
closed
Added by laforge over 2 years ago.
Updated almost 2 years ago.
Description
In the "ISDN operator" scenario, where various users with real E1 equipment (and an icE1usb) connect to that internet-hosted ISDN operator, we will need a DAHDI driver for the TDMoIP protocol. This avoids having physical E1 lines on the operator side, where it is really not desired in this scenario.
There is already the
dynamic DAHDI code for ethernet/ip based E1 interfaces, which should be possible to extend. However, there are some key differences between the existing code and our requirements:
- DAHDI dynamic already defines a message format while the drivers (eth, ip, local) only provide transport of that pe-defined message format. We need our own custom message format
- DAHDI dynamic is pre-configured at kernel module load time. We need to be able to add/drop lines at runtime, and also change their IP addresses as the peer IP address changes (#5428)
- Subject changed from DADI driver for TDMoIP to DAHDI driver for TDMoIP
- % Done changed from 0 to 10
I've done some initial development in this direction, but progress is relatively slow.
- adding/dropping lines is done similar to dynamic spans, with dedicated CREATE/DESTROY ioctl's
- later we'll also add a MODIFY ioctl to update the remote peer port/ip
- transmitting packets from inside the kernel is relatively easy
- question is more which layer of abstraction to use. Right now I decided to go thorugh the entire sendmsg path via kernel_sendmsg() and not to directly submit related skbs.
- receiving is slightly more difficult
- going all the way through the socket would likely mean introducing a kernel thread
- using the udp tunnel framework provides a more convenient way
- Status changed from New to In Progress
- % Done changed from 10 to 80
first successful testing has been completed today in the following setup:
- dahdi-trunkdev creating a virtual E1 span in DAHDI
e1-prbs-gen opening the 30 user-visible TS of that span, writing [different] PRBS sequences to each timeslot and checking against the received ones- dahdi-trunkdev is muxing/demuxing the E1 frames from/to those per-timeslot devices into a character device for the trunk.
- a small test program is reading the E1 frames from the trunk device, and writing/looping them back to the same trunkdev
e1-prbs-gen reports no errors for 10+ minutes
- % Done changed from 80 to 90
my local testing (dahdi-trunkdev-e1d <-octoi-> e1d-trunkdev-dahdi) looked quite promising, and we have a first user configured for )dahdi-trunkdev-e1d <-octoi-> e1d-icE1usb)
Needs more testing.
We now have multiple users connected via dahdi-trunkdev: drdeke, @tmwawpl, @tnt and tom/sirtux. So far we have not seen any significant difference in performance between the virtual @dahdi-trunkdev and the initial "naive" cobination of icE40-cable-TE820.
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
Also available in: Atom
PDF
