Project

General

Profile

Actions

Feature #5430

closed

DAHDI driver for TDMoIP

Added by laforge about 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
tdm-core
Target version:
-
Start date:
01/30/2022
Due date:
% Done:

100%


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)
Actions #1

Updated by laforge about 2 years ago

  • Subject changed from DADI driver for TDMoIP to DAHDI driver for TDMoIP
Actions #2

Updated by laforge almost 2 years ago

  • % 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
Actions #3

Updated by laforge almost 2 years ago

  • Status changed from New to In Progress
  • % Done changed from 10 to 80
Actions #4

Updated by laforge almost 2 years ago

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
Actions #6

Updated by laforge almost 2 years ago

  • % 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.

Actions #7

Updated by laforge almost 2 years ago

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.

Actions #8

Updated by laforge over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)