BRIStuff is a distribution for installing and / or patching Asterisk with several extra features written and maintained by Junghanns.NET Gmbh.

This document is written in AsciiDoc format, and should be readable as text as well. It is based on the original documentation from the bristuff package.

1. Compiling/installing

1.1. Short Version

wget http://updates.xorcom.com/astribank/bristuff/1.4/bristuff-current.tgz
tar xvzf bristuff-current.tgz
# change into the directory. May vary by between versions:
cd bristuff-0.4.0-test4
# Install prerequirements. At the moment only works on Debian and
# CentOS:
./prereq.sh install
# downloads, builds  and installs everything:
./install.sh
# Alternatively, use ./compile.sh to just repeat build phase.
# Two optional steps:
# 1. If you have not installed asterisk and Zaptel on that system yet
#    set it up:
./config.sh
# 2. Generate Zaptel configuration to match your system. If you have
#    an Astribank, connect it to your system first:
genzaptelconf -svdM
Note
If you have a CentOS 5 system and install a Xorcom Astribank, you also need fxload from http://updates.xorcom.com/astribank/fxload/ .
Note
If you have Trixbox: that won't install you kernel-devel. You may get an error from yum for the kerenl package. Get kernel-devel or kernel-smp-devel from http://updates.xorcom.com/astribank/trixbox/repo

1.2. Prerequirements

1.2.1. Kernel Source / "Headers"

1.2.2. Required Packages

This section needs some feedback. Specifically: names of packages.

1.2.3. prereq.sh

On several distributions (currently Debian and CentOS) the following script can show you what needs to be installed in order to build bristuff, or even install those packages on its own.

To show what needs doing:

./prereq.sh test

To go ahead an install those packages:

./prereq.sh install

1.2.4. Building

If you have all the pre-requirements, it should download, patch, build and install everything. But it will leave the system unconfigured.

This version is built with the OSLEC echo canceller. If you actually want to disable that you probably need to edit compile.sh . It is probably a bad idea to mix OSLEC installed from here an OSLEC installed from anywhere else independently.

2. System Setup

In this section we will try to give basic instructions on the setup of an Asterisk system with the BRIStuff patches. See the References section in the end for other sources of information, as this docuemtn can not serve as a complete Asterisk setup guide.

The install.sh script above will not set up a complete system. If you don't have have a system

This may be what you want if you have already configured Asterisk. If not, see the following section.

2.1. BRI Zaptel Setup

I would generally recommend you to use genzaptelconf for initial setup of your Zaptel hardware.

2.1.1. Tweaking genzaptelconf

genzaptelconf has a few command-line switches. It is also possible to affect it behavious through environment variables. But the most effectivce way to affect its behaviour is through the zaptel init configuration file.

genzaptelconf has two major modes: 1. Without the option -d, it will try to detect configuration from the currently-loaded modules. 2. With the option -d it will unload all loaded modules and probe to see which of them needs loading.

The zaptel init configuration file is either /etc/default/zaptel if it exists (typically on Debian / Ubuntu) or /etc/sysconfig/zaptel otherwise (typically used on Redhats, SUSE and some other distributions).

The syntax of that file is of a shell script: VAR=VALUE . It is also being read by the zaptel initialization script (/etc/init.d/zaptel). genzaptelconf sets many variables on its startup and they can be overriden by setting them in the zaptel init configuration file.

Any changes here will only apply when you re-run genzaptelconf.

A few select variables: - lc_country: the country to use. Default: us. The country to use for tonezones in zaptel.conf . Also may affect a number of settings where we found it useful to have country-dependent defaults. - context_lines: The context into which FXO channels (and BRI TE channels) will be directed. Default: from-pstn. - context_phones: The context into which FXS channels (and BRI NT channels) will be directed. Default: from-internal. - context_manual: If set to yes, genzaptelconf will not set contexts, as you probably know better. Default: unset.

This is just a small example. For a complete list, look at the begionning of genzaptelconf, up to the comment line "# read default configuration from /etc/default/zaptel".

2.1.2. Manual Zaptel Setup

Alternatively, you can use the sample zaptel.conf and zapata.conf files provided for various cards. Chances are you will need to edit them: Set your country name in zaptel.conf Set the proper groups, extension etc. in zapata.conf.conf .

For a Xorcom Astribank you'll need to dig in into xpp/README.Astribank to find example zaptel.conf, zapata.conf and minimal extensions.conf .

2.1.3. Manual Drivers Loading

The following section is added unmodified from the original document. I don't really agree with it, though.

Junghanns quadBRI:

cd qozap
modprobe zaptel
insmod qozap.o (for kernel 2.4)
insmod qozap.ko (for kernel 2.6)
ztcfg

Junghanns octoBRI:

cd qozap
modprobe zaptel
insmod qozap.o ports=X (kernel 2.4, for X see below)
insmod qozap.ko ports=X (kernel 2.6, for X see below)
ztcfg

Junghanns octoBRI Example:

Junghanns singleE1, doubleE1:

cd cwain
modprobe zaptel
insmod cwain.o (kernel 2.4)
insmod cwain.ko (kernel 2.6)

HFC-s:

cd zaphfc
make load   # for TE mode, or:
make loadNT # for NT mode

2.2. Kernel Module Parameters

Some zaptel modules have optional parameters. For instance, qozap has a parameter called ports as explained above. The following section explains how to get the loaded automatically when kernel 2.6 is used. For kernel 2.4, see the documentation for /etc/modules.conf .

The following configuration can be added to either /etc/modprobe.conf (if it exists) or to any file under /etc/modprobe.d .

options MODULENAME param=value

for example:

options qozap ports=3

If you want to add several options, you should do that in a single line, such as:

options xpp prefmaster=0 zap_autoreg=0

3. Special Build Options

Instead of simply running ./install.sh , there are some variations.

Only download and patch:

./download.sh

Only build and install:

./compile.sh

(./install.sh simply calls those two)

compile.sh accepts several options. Those options can be passed either as command-line parameters (install.sh will simply pass all options to compile.sh) or as environment variables. Any combination could be used. Command-line parameters override environment variables.

To build bristuff without any annoying requests in the middle to press Enter, set the variable BRISTUFF_CONFIRM to no:

BRISTUFF_CONFIRM=no ./install.sh

By default the script will add all 4 bristuff modules with Zaptel: cwain, qozap, zaphfc, ztgsm. This allows you to build just some of them (or maybe none at all). e.g:

./compile.sh -m 'qozap zaphfc'

By default, the script will build the following dirrectories, in the following order: zaptel, libpri, libgsmat, asterisk, asterisk-addons. Setting this allows you to select just part of them. For instance, to build just zaptel and asterisk:

./install.sh -t 'zaptel asterisk'

To build zaptel for a different kernel version (but still with sources in standard location) use the variable KVERS:

By default the script will clean every directory before running a build command. This guarantees a successful build, but at the cost of build time. With this option, a make clean will not be run automatically.

./compile.sh -t asterisk -c

To build zaptel for a different kernel version (but still with sources in standard location) use the variable KVERS:

KVERS=2.6.18-5-686 ./install.sh

To provide a custom kernel source tree set KSRC as well:

KVERS=2.6.18.Custom KSRC=/home/tzafrir/linux-2.6.18 ./install.sh

To install everything to a separate subtree, use the variable BRISTUFF_DESTDIR. It must be an absolute path, or else Zaptel modules installation would fail. This is generally only useful for testing:

BRISTUFF_DESTDIR=$PWD/tmp ./install.sh

Configures Asterisk with —enable-dev-mode . This allows some extra debug options and makes build warnings become errors by default.

3.1. Patching with Quilt

The single patches under patches/ have been replaced with subdirectories of patches that are managed with quilt. To avoid making quilt a build requirement, I have added a simple wrapper script, apply-patches.sh, that applies patches from a quilt directory. I have also provided a wrapper script to quilt: to list all the patches on asterisk, use:

./quilt.sh asterisk series

This runs quilt series for asterisk. If you encounter some conflicts with patches with a certain subdirectory, it is recommended to start from cratch and use quilt.sh instead of apply-patches.sh, as quilt is more robust and has bookkeeping of applied patches.

If you use ./download.sh -q or ./install.sh -q the patches will be applied with quilt (you should have it installed). This allows you to further tweak the patches using the above wrapper. Be sure to only edit patched files through quilt edit if you want to maintain the ability to apply and unapply patches.

3.2. live_ast

live_ast is a script that wraps starndard asterisk commands to allow you to run Asterisk from your build directory without fully installing it. This can help when testing a new version of Asterisk before actually installing it. There is nothing BRIStuff-specific about live_ast. Indeed it is included in its own bug report. However, I thought I might as well include it in this distribution. The current scripts do not build Asterisk with live_ast, however you can do that on your own. It is already copied to the asterisk directory, and the sample config file is already generated as asterisk/live/live.conf . For more information, see http://bugs.digium.com/11680.

For more information: