[asterisk-dev] pinned-spans DAHDI: plug&play start working...

[Oron Peled]

Hi,

Shaun Ruffell, Tzafrir Cohen and me worked in the recent monthes
to try and achieve reliable ordering of spans.

My original approach was a "dial-byname" scheme where the dialplan
and user-space configuration would use persistant device names
instead of span enumeration which may vary in run-time.

Shaun suggested another approach we later called "pinned-spans"
where the user may map the persistent device names into persistant
span numbers at the dahdi level. This way a user can "pin" a specific
device + local spans to specific span numbers and channel numbers.

We proudly present our first cut at the "pinned-spans" approach:
 * The dahdi-linux trunk was already updated (roughly r10270 - r10288)
   - The updates in README (r10288) gives basic documentation

 * The dahdi-tools additions are in (long, may wrap):
https://gitorious.org/~tzafrir/asterisk-tools/tzafrirs-dahdi-
tools/commits/pinned-spans

 * The tools update basically contains:
    - /usr/sbin/span-assignments with configuration file
      example /etc/dahdi/pinned-spans.conf
      (both documented inside, running span-assignments
       without arguments print a usage message)

    - /usr/sbin/span-types with configuration file example
      /etc/dahdi/span-types.conf
      (both documented inside, running span-types
       without arguments print a usage message)

    - An augmented dahdi_cfg which may be limited to work only
      on specific span and channel range (via new '-S' and '-C options)

    - An updated /etc/udev/rules.d/dahdi.rules which calls a
      new /usr/share/dahdi/handle_device script.
      This script runs: span-types, span-assignments and dahdi_cfg

     - The updated Makefile installs all these in their correct locations.

 * This means that with proper configuration we have a plug&play
   DAHDI and even if a dahdi device is removed/added, none
   of the existing cards are affected (same span numbers, same
   channel numbers, same configuration)

 * We still miss support in asterisk for skipping missing devices
   (it safe with pinned-spans, unlike with the old scheme)

WHAT WE WANT FROM YOU?
 * Most important -- test dahdi-linux trunk *WITHOUT* the new tools.
   This should present the same backward compatible behaviour as
   before. We want to make sure the updated kernel modules did not
   break existing interfaces (only added a new sysfs based ones)    

 * The next thing is to try the new tools. We specifically ask
   for "bike-shedding" in this. Are the configuration files
   generic enough? Are they comfortable? What about the scripts?

What's next (TL;DR) ?

During the work, we found out that "pinned-spans" and "dial-byname"
approaches are orthogonal and may complement each other:
 * The pinned-spans approach has a huge advantage in that no
   change is needed in dialplans and /etc/dahdi/system.conf files.

 * If a device is replaced with a compatible one, all that is
   needed is to maybe update a single mapping config file and
   it would magically appear instead of the old device.

 * As long as we keep linear sequence of spans and channels
   we may change anything we want without affecting existing
   spans/channels.

 * However, removal/addition of different devices may lead
   to a situation where we cannot linearize them and keep
   the old numbers. Sometimes this problem may be mitigated
   by leaving gaps in the span/channel numbers.

   Note: gaps are permitted and working, as long as both span
   numbers and channel numbers have the same sort order.

 * The "dial-byname" approach is not included in this work yet,
   but it was tested by me and works with/without "pinned-spans":
    - The kernel part simply adds dahdi_channel representation
      in sysfs (in addition to dahdi_device and dahdi_span which
      were added by us in this work)

    - The udev part, is a simple script to create symlinks in /dev/dahdi
      that map physical device names (and channels) to their
      correct device files.

    - The dahdi_cfg accepts new span/channel naming in addition to
      the current numeric naming

    - Asterisk does not need any further change, since we already
      restored its ability to open a device by device-file name...

    - With these additions, users (at their options) may write their
      configuration/dialplans using persistant naming and as a result
      have a plug&play system regardless of span/channel global
      numbering.

Good night everybody,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
Problems cannot be solved at the same level of awareness that
created them.
                 -- A. Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111028/a9ffda14/attachment-0001.htm>