asterisk announce - Apr 2010 - DAHDI-Linux and DAHDI-Tools 2.3.0 Released

The Asterisk Development Team is pleased to announce the release of
DAHDI-Linux and DAHDI-Tools version 2.3.0.

DAHDI-Linux 2.3.0, DAHDI-Tools 2.3.0, and DAHDI-Linux-Complete are available
for immediate download at:
http://downloads.asterisk.org/pub/telephony/dahdi-linux
http://downloads.asterisk.org/pub/telephony/dahdi-tools
http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete

In addition to several bug fixes, the most significant changes from the 2.2.0
release are:

General DAHDI Changes:

* Static /dev/dahdi files are not generated at install time since udev is used
  on all the supported distributions.  build_tools/make_static_devs is
  available for those users who still need the static device files.

* UDEV_DIR can be set during build in order to override where the build will
  place the udev rules.

* dahdi_dummy is no longer built by default.  DAHDI will automatically use a
  kernel timer to provide timing if there isn't a physical span which is
  providing timing.

* Added support for 16 kbps software hdlc.

* Added support for software configurable BRI TE/NT mode and termination
  resistance.

* Support for additional error counts added to dahdi_spaninfo.  New counters
  include framing errors, coding violations, bit errors, and errored seconds.

New Drivers:

* dahdi_dynamic_ethmf included to support TDMoE Multi-Frame Devices from
  Redfone Communications.
  [http://www.thrallingpenguin.com/articles/tdmoe-mf.htm]

Updated Drivers:

* wctdm24xxp: Support for Digium Hx8 hybrid digital/analog cards.
  [http://www.digium.com/en/products/hybrid/]

* wcte12xp, wct4xxp: Added support for more fine grained maintenance modes.
  Among other things, it is possible to now place cards supported by these
  drivers into local loopback without the use of an external loopback plug.
  See dahdi_maint in dahdi-tools for more information.

* wct4xxp: Added support for Fifth Generation firmware which allows dual and
  quad span cards to function on systems which are unable to service the
  interrupt every millisecond in addition to support for revision 3.1 of the
  framer.

* wcb4xxp: Swyx 4xS0 SX2 QuadBri, HFC-4S Eval board, and several additional
  Junghanns cards added to the device table.

* wct4xxp, wcte12xp: Added losalarmdebounce, aisalarmdebounce, and
  yelalarmdebounce module parameters in order to configure alarm debounce
  times (specified in ms).
  
* wcte12xp: Added 'max_latency' module parameter.  VPM initialization
moved into
  start span and VPM is polled and reset if necessary.  This is to accommodate
  systems that experience interrupt latencies > 128ms.

* xpp: 'offhook' also applies to the PRI modules - no PCM passed if no
call.
  Udev rules updated for newer kernels / udev.

Changes to dahdi-tools:

* dahdi_maint: A new tool which allows the maintenance mode of spans that
  support the maintenance mode interface to be configured.  This includes
  setting various loopback modes and error injection.

* dahdi_tool: "loop" button was removed from the span page.  This will
soon be
  handled through the dahdi_maint utility.

* fxstest: now supports generating DTMF CID spills for testing.

* dahdi-perl: /proc/bus/usb no longer required for dahdi_hardware and such. Can
  use a dump generated by build_tools/dump_sys_state. Support loading firmware
  from 1163 (minimal firmware) devices.

For a full list of changes in these releases, please see the ChangeLogs at
http://svn.asterisk.org/svn/dahdi/linux/tags/2.3.0/ChangeLog and
http://svn.asterisk.org/svn/dahdi/tools/tags/2.3.0/ChangeLog

Issues found in these releases can be reported at http://issues.asterisk.org

Thank you for your continued support of Asterisk!

On Tue, 13 Apr 2010, Asterisk Development Team wrote:
> * Static /dev/dahdi files are not generated at install time since udev is
used
>  on all the supported distributions.  build_tools/make_static_devs is
>  available for those users who still need the static device files.
Please do not ever remove the static_devs script - I do not use udev and 
never will in my embedded systems. There's simply no need for it when your 
hardware never changes.

Gordon