[asterisk-dev] DAHDI and Asterisk

Joshua C. Colp jcolp at sangoma.com
Thu May 18 10:51:53 CDT 2023

On Thu, May 18, 2023 at 12:39 PM <asterisk at phreaknet.org> wrote:

> On 5/18/2023 11:09 AM, Joshua C. Colp wrote:
> > On Thu, May 18, 2023 at 12:05 PM <asterisk at phreaknet.org
> > <mailto:asterisk at phreaknet.org>> wrote:
> >
> >     Wanted to float a question here for the Asterisk core team, that has
> >     been discussed amongst several other Asterisk/DAHDI developers a bit.
> >
> >     As we all know, the DAHDI project has been neglected the past few
> >     years
> >     and it does not appear that there is any team at Sangoma that is
> >     actively working on it or cares about it. Sangoma has repeatedly
> >     failed
> >     to take responsibility for DAHDI and is not letting the community
> >     maintain it either, i.e. PRs are not being merged, build failures are
> >     not addressed. Numerous developers, myself included, have long been
> >     maintaining external patch sets[1] or forks[2] to address this.
> >
> >     At this point, it is unrealistic to expect the DAHDI project in its
> >     current form to ever really get back on track. Some distros I'm told
> >     have already abandoned Sangoma and now use the osmocom fork as their
> >     upstream for packages. Most people have been using these methods to
> >     build DAHDI, rather than using the Sangoma tarballs.
> >
> >     Merely maintaining patch sets or forks is not a long term
> >     solution. Many
> >     new Asterisk features require DAHDI changes, and thus require
> >     patches to
> >     be maintained for multiple projects. Even if the Asterisk side
> >     could be
> >     merged in fine, some changes may require or depend on a DAHDI
> >     change to
> >     work properly. Over time, patches begin to conflict with or step
> >     on each
> >     other. DAHDI does not live in a bubble and has impacts that ripple
> >     out
> >     to other things, like Asterisk.
> >
> >     Since DAHDI has no active maintainer currently, I wanted to float a
> >     couple ideas here to remedy the situation, in order of feasibility (I
> >     think):
> >
> >      1. Would it be possible for the DAHDI project to be moved to fall
> >     under
> >         the scope of the Asterisk project? e.g. similar to libpri. The
> >         Asterisk team would not need to actively do anything with it, but
> >         just merge changes into it as it does for libpri, for example
> >     (kind
> >         of like extended support). I think this would make the most sense
> >         because fundamentally, DAHDI is part of the Asterisk ecosystem.
> >         Asterisk has a dependence on DAHDI and so bringing that
> dependency
> >         in house makes sense since it eliminates friction. For
> >     example, this
> >         change[3] stalled solely because nobody is merging PRs into
> >         If the Asterisk team was able to merge DAHDI changes, problem
> >         solved, and then Asterisk changes aren't stalled because DAHDI is
> >         stalled.
> >
> >
> > No. This is not something that the Asterisk project or Asterisk team
> > will take on. We're trying to reduce the amount of responsibilities
> > (such as reducing the amount of infrastructure we maintain and manage)
> > we have to be able to focus on Asterisk itself, taking on new ones
> > particularly in areas we have no expertise in is not something we will
> > be doing.
> Understood.
> In this case, is there any possibility of accepting changes that have
> dependencies on DAHDI functionality that may not be present in the most
> recent Sangoma tarball, but exist in maintained versions of DAHDI? e.g.
> conditionally guarded if needed so that there aren't build issues,
> regardless of which version of DAHDI is used underneath. Such changes
> would be effective only when they actually exist and are supported by
> the underlying DAHDI version. Or is the Asterisk project restricted to
> using only the official Sangoma version, even though it's broken and
> stagnant?
> For example, this change[1] doesn't even have any build dependencies on
> DAHDI. It compiles and runs fine regardless. It will work if the
> underlying DAHDI change is present, and do nothing if it is not. Is that
> still a blocker on merging this? As Kevin said on the review, "Unless of
> course you're thinking the DAHDI changes may be not go in for a very
> long time, if at all and ppl will just manually apply patches
> themselves." People using this feature are going to do just that, so in
> practice there isn't a compatibility issue. Are there any circumstances
> under which patches like these may be merged?

This is uncharted territory so I would say yes they could be put up for
review and if reviewed merged, provided of course as you state it remains
backwards compatible.

Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20230518/35721ffd/attachment.html>

More information about the asterisk-dev mailing list