VoIP Mailing List Archives

[tzafrir.cohen at xorco...]

What is dahdi.auto_assign_spans and why should you care?

In later versions the kernel module dahdi[Q] includes a new parameter:
auto_assign_spans. It defaults to 1, and if you set it to 0, DAHDI can
start behaving in strange and completely expected ways. Chances are the
default will be set to 1 in a future version. Here is why you'll want to
set it yourself.


Up until DAHDI 2.5, hardware drivers for DAHDI presented DAHDI with
spans[W]. The device would initialize the hardware, identify the spans
in it, and register them with the dahdi core. The dahdi core assigns
each span the first available span number and the first available series
of channel numbers.

If you have a single device, what you get here is expected. If you have
more than one device, you should make sure that they get detected in
the same order on each boot. One missing: your configuration is
completely botched. As a result, chan_dahdi has adapted to assume that
if any channel has the wrong signalling, it may be because a device is
missing (or got added) and we cannot trust other parts of the
configuration.


Much work has been done to fix this fundemental problem. Dahdi 2.6 added
the basic building blocks: When the hardware drivers register with DAHDI
they expose information about the complete device. This information is
available to userspace through sysfs[E]. If the module parameter
auto_assign_spans has the value 1 (the default), it all happens as
before (except now we call the operation "assignment" - spans are
assigned. And they can be unassigned and reassgined later).

But if auto_assign_spans is set to 0, the spans of the device will just
sit there and wait for the user to do something: you can ask dahdi to
either assign spans "automatically" (to the first available numbers,
just as before). But you can also ask DAHDI to give each span a specific
span number and a specific initial channel number. See [R] for the exact
details.

While doing that we noticed that setting a span to be either E1 or T1
has to be done before it is assigned (you can't change the number of
channels after a span is assigned). Thus a similar interface was added
to change the "span type".

Another important component are "udev events" - when a kernel object is
created (or destroyed), the kernel emits an event. udevd listens on
those events. With the proper udev rules, you can react to addition of
dahdi devices, spans or channels.


With those low-level tools in place, all we need are a few shell
scripts. You can find the full specification in [T]. You should note the
two new tools. Those tools provide a simple and clean interface to the
sysfs interface.

dahdi_span_assignments: can unassign spans (remove) assign spans
automatically (auto), or assign them according to the specifications in
/etc/dahdi/assigned-spans.conf (add). It also has the option
'dumpconfig' to print the current state in the same format used by its
configuration file assigned-spans.conf .

dahdi_span_types: similar for the span types attribute with
/etc/dahdi/span-types.conf .


HOWTO
-----
Set Up a New System
~~~~~~~~~~~~~~~~~~~
1. connect all the devices.

2. Run: dahdi_genconf

The configurations files are now ready (except, maybe, Asterisk's
chan_dahdi.conf and other configurations. This is beyond the scope of
this message[Y]). So basically just follow with the standard steps from
here:

The configuration was not ready when the spans were assigned. Thus we
cannot rely on the hooks to auto-configure them, and must do that
manually this time:

3. dahdi_cfg # or maybe the full /etc/init.d/dahdi start

4. asterisk -rx 'dahdi restart'


Remove a DAHDI device
~~~~~~~~~~~~~~~~~~~~~
[No need to change anything. The system will just work. dahdi_cfg run in
'/etc/init.d/dahdi start' will fail but we don't care as spans will be
configured in the udev hook. Channels will be missing in Asterisk but it
won't care as you set 'ignore_failed_channels']


Add Another DAHDI device
~~~~~~~~~~~~~~~~~~~~~~~~
1. Connect the device

2. dahdi_span_assignments auto

3. Run dahdi_genconf

or, if you want to avoid complete regeration:

3.1 Run dahdi_genconf assignedspans
# same as: dahdi_assigned_spans dumpconfig >/etc/dahdi/assigned-spans.conf

3.2 edit system.conf to match the new hardware .

Now your configuration is ready. See (3) and (4) above.


Reconnect a Device
~~~~~~~~~~~~~~~~~~
Quite common with USB devices. The equivalent is to rmmod the driver for
the device and re-modprobe it.

Again: just sit and wait for the device to re-appear in Asterisk.
nothing to do.


Replace a Broken Device
~~~~~~~~~~~~~~~~~~~~~~~
Ideally this would be the same as the above. However,
assigned-spans.conf may have a different hardware ID. You may choose to
have the devices specified by their location identifier (their
connector), but this may have unexpected result if the device is
reconnected on a different port.

So ideally you just edit the configuration file:

sed -i -e 's/old-identifier/new-identifier/' /etc/dahdi/assigned-spans.conf

and then connect the new device. But maybe you did not remember to do
this in advance, or you're not sure what the ID is without connecting
the new device.

In that case:

1. connect the new device.
2. either:
dahdi_span_assignments auto
dahdi_genconf span
or, if you have anything special thereand want keep it:
sed -i -e 's/old-identifier/new-identifier/' /etc/dahdi/assigned-spans.conf
dahdi_span_assignments add

The configuration is already in place, so everything should work from
here.


Change Span and Channel Numbers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Naturally you're not limited to the above scenarios. What if you just
feel like using different channel and span numbers? All you need is:

dahdi_assigned_spans remove
vi /etc/dahdi/assigned-spans.conf
dahdi_assigned_spans add
dahdi_genconf # likely to get run here, as you changed span and channel
# numbers.

But you do need a proper text editor. And see (3) and (4) above.


Example: if you have two devices. you want to reverse the order in which
they show.

The configuration file I have is:

####################################
# Device: [usb:000156] @
# /sys/devices/pci0000:00/0000:00:10.4/usb1/1-1/xbus-00/astribanks:xbus-00
usb:000156 1:1:1
usb:000156 2:2:32
usb:000156 3:3:63
usb:000156 4:4:94
usb:000156 5:5:125
usb:000156 6:6:133
usb:000156 7:7:141

# Device: [usb:INT05668] @
# /sys/devices/pci0000:00/0000:00:10.4/usb1/1-3/xbus-01/astribanks:xbus-01
usb:INT05668 1:8:149
usb:INT05668 2:9:152
usb:INT05668 3:10:155
usb:INT05668 4:11:158
usb:INT05668 5:12:161
usb:INT05668 6:13:164
usb:INT05668 7:14:167
usb:INT05668 8:15:170
######################################

As you can see here, this system has two devices, each with several
spans. The device usb:000156 has 7 spans, of which 4 are E1 ports (a
range of 31 numbers[U]) and the other three have only 8 ports. The other
device, identified as usb:INT05668, has eight spans of its own. Their
numbers start from 8, and the channel numbers start from 149. Spans are
are BRIs (3 channels per span).

The long list of channels of the E1 spans is annoying, and I'd like it
to appear after the BRI ports.

Here's the first shot: move the span numbers:

vi () { perl -pi -e 'if (/^usb:000156/) {s/[0-9]+):/":".($1+30).":"/e}' "$@"; }

This adds 30 to the span number of the first device. Thus they appear
first on lsdahdi. But the listing is Asterisk is by channel numbers.
Let's add 300 to its channel numbers:

vi () { perl -pi -e 'if (/^usb:000156/) {s/[0-9]+)$/":".($1+300)/e}' "$@"; }

And now let's have both:
vi () { perl -pi -e 'if (/^usb:000156/) {s/[0-9]+)$/":".($1+300)/e; s/[0-9]+):/":".($1+30).":"/e}' "$@"; }

Note that it's easy to change the span numberes, changing channel
numbers is slightly trickier: each span has to have the required number
of channels.

Get vi Back
^^^^^^^^^^^
1. run the above in a subshell. Or:

1.1. unset vi



[Q] Reminder: there is a kernel-level module called DAHDI, and Asterisk
module called chan_dahdi.

[W] A span is logical groups of channels: a single digital port, all the
analog ports on a card, or whatever. Spans and channels are identified
by their numbers.

[E] http://docs.tzafrir.org.il/dahdi-linux/#_devices_bus

[R] http://docs.tzafrir.org.il/dahdi-linux/#_span_assignments

[T] http://docs.tzafrir.org.il/dahdi-tools/#_implicit

[Y] There are interesting things you could do if it were possible to
configure Asterisk more dynamically.

[U] Note, however, The fact that a port has a range of 31 channels does
not necessarily mean it has to be E1. Maybe a smaller span uses that
range.

--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.cohen@xorcom.com
+972-50-7952406 mailto:tzafrir.cohen@xorcom.com
http://www.xorcom.com

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users