You need to download and install the latest version of Common C++,
ccscript, and ccaudio first before you compile Bayonne. All of the files
are available for Anonymous FTP access at: ftp://ftp.gnu.org.
The manifest of files to pull for a 'full install' are:
||The actual telephony server
||Additional French language voice prompts
||A C++ 'abstraction' library, needed to build the package bayonne The telephony server
||A C++ class framework for processing audio files, needed to build the package
||A state-event driven scripting engine
||Voicetronix hardware support API
Bayonne should compile and run under any modern GNU/Linux
distribution. Bayonne M5 and above should compile and work under elf
based FreeBSD distributions.
The most common reason for this is that the /etc/bayonne.conf file is
not acessible under the user id you have started Bayonne under
or the default value found in "driver=" under Bayonne is wrong. Bayonne
has internal defaults for many things, including the default ivr driver.
For GNU/Linux, this default is typically "phonedev", and this will crash
if the system you are using has no Quicknet cards attached.
You can start Bayonne with the -driver option to specify the correct
telephony driver module, or you can edit the bayonne.conf.
What are the driver names for supported hardware?
The "/dev/phone" devices are supported thru "phonedev". This supports
Quicknet and other future /dev/phone devices.
The Pika card requires the Pika MonteCarlo library to be installed, and is
The Voicetronix card uses the new Voicetronix libvpb2 unified API for
FreeBSD and GNU/Linux, and is called "vpb".
The Dialogic hardware support module is called "dialogic". It is designed
for both analog and digital telephony devices that are supported by the
standard Dialogic UNIX SDK. If you are using GNU/Linux, then you will
also need the LiS stream package to be installed.
The Aculab hardware support module is called "aculab", and requires the
call, switch, and voice aculab sdk's to be installed and the aculab kernel
modules to be running.
When you run "./configure", the configure script will locate and try to
identify which telephony API's you have on the development machine you are
using. Bayonne will then only build and install IVR modules for those
telephony API's that it is able to identify.
The API for all available machines you expect to deploy should be present
on your primary development machine when you build Bayonne. You do not
have to have actual telephony hardware present on the build machine where
you actually compile Bayonne, just the link libraries and header files.
If Bayonne fails to locate your API, you may still be able to build it by
going into the drivers subdirectory for your hardware and running
"make" there. Bayonne configure will at least build a makefiles for all
drivers, even the ones it does not find and chooses to skip.
You have to remove the "config.cache" before running ./configure if you
add a new telephony API. Otherwise it will use the cache'd value from the
last time it has been ran.
Dialogic and CT Access require streams support. Under GNU/Linux, this is
done with the LiS streams package. This package has a special libc
"PRELOAD" library. If you have not rebuilt your Bayonne server but have
installed Dialogic drivers, then the server image you have will not be
linked with the LiS libc. Just remove "bayonne" from the server
subdirectory and re-run "make".
You are one of those people who no doubt downloaded one of the pre-release
copies of Bayonne 0.4.4. Bayonne does not overwrite the existing
/etc/bayonne.conf if it finds one already in place, and the one from the
pre-release set was broken.
By default, I use "sysconfdir" to install the /etc files for
Bayonne. This defaults to /usr/local/etc! One must specify "-sysconfdir
/etc" when running configure. Starting with 0.5.0, I always install
Bayonne config files in /etc and no longer use sysconfdir.
You must upgrade to ccaudio 0.2.4 which fixes a bug in the Open
method. Alternately, you can change ownership of all files in aaprompts
to the effective user id Bayonne is running under.
You will need Common C++ 1.2.4, ccaudio 0.2.4, and ccscript 1.2.2 as
a bare minimum. You will also need Bayonne 0.5.0, and vpb2-2.0.2 to
use Voicetronix hardware.
Bayonne uses "native" FreeBSD threads as found in -lc_r. If you make the
mistake of loading the linux "pthreads" library as well, as I did, it will
only cause you confusion and grief. Most of the packages now have
conditional #undef's to undo what the linux pthread.h does since it's
typically included instead of pthread.h unless you build everything with a
Use "CXXFLAGS=/usr/local/include LDFLAGS=/usr/local/lib
./configure". This is done in all my "ports" Makefiles.
Yes there are. They are built under Mandrake 7.1, although the RPM src
files should generally rebuild under any Linux distribution. We do try to
work with different GNU/Linux distributors to gaurentee compatibility and
do not implicitly recommend or support any specific distribution.
Rebuilding the various components, Common C++, ccaudio, cscript, and
bayonne - under the RPM packaging system is streightforward.
Each .tar.gz file contains a '.spec' file within it, and so may be rebuilt thus:
rpm -a packagename-ver.patch.tar.gz
... where ver and patch are versioning and patchlevel informationnnumbers,
such as: bayonne-0.4.4.tar.gz
This will have RPM unpackage the tarball in its own temporary working
directory, locate the .spec file, and rebuild the package, producing a SRPM
and the varions RPMs. This also allows for a 'clean' build each time,
avoiding some of the inadvertent locale specific build issues of the
'./configure && make && make install' approach which is an alternative
approach. (This latter method cab find 'stale' configure script information
froma prior buildsession.)
The resulting RPM's may then be installed in the conventionalfashion:
rpm -Uvh /usr/src/redhat/RPMS/i386/bayonne-0.4.4-3.i386.rpm
The build and install sequence is somewhat order dependant. We have had
the best success using the following order:
For example, ccscript will not build cleanly with older versions of
CommonC++ present. Accordingly, one needs to upgrade ComonC++ first.
Note that some earlier versions of bayonne have dependencies on earlier
versions of ccscript. For example bayonne 0.4.3a depended on ccscript
1.1.2 - the conventional RPM dependency satisfaction methods apply - do a
multiple upgrade of cross dependant packages (as with the bayonne example
above, or do a three stage upgrade (remove the blocking packages; upgrade
the depentencey, install the later version of the blocking package.
No, not yet, though some are being contributed, and we hope to have them
The M5 release will be certified for use under BSD using the Voicetronix
API. It will be updated to support the new Quicknet FreeBSD driver when
that becomes available as well. M5 will also be placed into the FreeBSD
The current 0.4.4 release may already compile and operate correctly under
What is the dummy driver?
The dummy driver is there only to assure Bayonne will compile to
completion even if it fails to find ANY telephony API (see Q5). This
module is not functional though at a future date it might be made
usable for testing.
Currently Bayonne is internationalized and supports both English and
French. Other languages will be added as volunteers supply appropriate
Yes, Bayonne can have multiple language libraries loaded and provide
different languages for different telephone callers. Bayonne can also
change the default language anytime desired during a phone call.
We have used Bayonne under Debian GNU/Linux on 486 systems with as little
as 12 megs of ram.
Is it possible to "tune" or optimize Bayonne performance?
Yes, there are several ways to do this. Some are generic to the
"server" itself, and others are capabilities are telephony driver
specific. All these options are found in /etc/bayonne.conf.
First, threads can be given different priority levels. However, his
requires one to start Bayonne as "root" otherwise priority "boosts" above
the base user priority level do not occur.
Generally, you want to reduce the priority of generic threads like the
"scheduler", and increase the priority of things performing realtime or
near realtime services such as feeding audio. Thread priorities are found
globally in the "[threads]" portion of /etc/bayonne.conf and sometimes
also in individual telephony driver sections.
In addition to specifying priorities, one can specify threading
"policies" by selecting a specific scheduler. The "rr" scheduler
generally provides the best tradeoff for soft realtime
performance. Generally you want Bayonne realtime services to run at
higher priorities than anything else on the machine, most services to run
at the default user priority, and some to run at a lower priority.
Since Bayonne is threaded, some operating systems pre-allocate fixed size
stacks for use by each thread as it's created (FreeBSD is an example of
this). The [threads] section has a global default value that will be
applied, in xK quantity. Very often the default "minimum" of the
operating system is smaller than actually required, and so you can
establish a new global default here.
In addition, some sections of the Bayonne.conf file may contain local
"overrides" and alternate stack values. These could be used for services
that do not require the same stack value, especially if they can use a
smaller stack space and be better optimized.
There are a number of odd options in Bayonne that tune memory usage. The
most immediately obvious are the use of audio buffers for streaming audio
to/from DSP telephony devices. These are generally sized in "frames",
where a "frame" represents a buffer that is passed directly to the
DSP. The size of a single frame is telephony driver specific; for
example, it is 120ms of audio for a Pika card, and typically 30ms of audio
for a Quicknet card. Having "n" frames means potentially non
realtime/blocking disk activity can be decoupled from DSP activity and
provide a smoother audio experiance.
Finally, there is the "[memory]" section which tunes allocation of symbol
space. A seperate symbol table is allocated for each and every telephony
port, and it is done in "pages" which represent an allocation
quantity. Also, a default "size" for newly created symbols may be
specified, and this should always be smaller than the "page" size.
There is a "pages" entry under [threads]. If this is used, it both
represents a minimum number of additional 1K pages to pre-allocate for the
process, and disables all swapping for Bayonne. This assures that
realtime response is optimized since Bayonne will always be in active
memory in it's entirety. Swapping is generally not a problem except for
machines with very small ammounts of RAM where sometimes Bayonne pages may
be sacraficed by default and degrade performance.
The one step you must do is set the trunk group you are using ([trunks])
to "answer" on the second ring rather than the first ring. This will
delay answer long enough to process and validate cid information before
script execution. Using the "answer" statement alone to delay answering
is insufficent at least in some drivers. Also, not all drivers support
caller id, and some may not have this limitation at all.
Great - the essence of open source development is the contept that 'all
bugs are shallow, with enough interested eyes watching.'
Please take a moment, and make sure you are running the latestcode. Check
the Anon. FTP archive for current version numbers. If you are not, please
update, or ask your site administrator to update your software as
Once you are current, see if you can reproduce the bug again. Veryoften,
you are not the first person to encounter a bug, and it may already be
fixed. By running the latest production version, you do not version the
maintainers with stale duplicate reports.
If you _can_ still reproduce it, please either send an email, to
email@example.com. Or you can use the online bug reporting system found
Please understand that the maintainers of the software are volunteers, and
so prioritize their work to fix 'show stoppers' first, and add enhancements
The Bayonne project has an active mailing list, "bayonne-devel", which
is open to the public. If you wish to be involved, join the list by
sending a message with the body containing "subscribe" to