GNU Bayonne 2 Installation Guide

David Sugar

GNU Telephony


(The text was slightly edited in 2017.)


1 Introduction

This guide was created to assist those trying to build and install the second edition of GNU Bayonne (to be referred to as GNU Bayonne 2) for the first time. GNU Bayonne 2 is a large and complex package, which can involve both hardware and software, as well as a number of additional software packages, each of which my need to be configured to successfully deploy a running server.

GNU Bayonne 2 itself is licensed as free software under the GNU General Public License. This means the source for this complete package is made available to the user, and the user is given specific rights to use and modify the sources provided – rights which are often denied in proprietary packages. GNU Bayonne itself depends on other parts of the GNU system, such as GNU Common C++ and GNU oSIP, which are also licensed as free software. This guide does not try to explain how to fully exercise these rights, but simply how to configure and install GNU Bayonne 2 as distributed through the GNU Project.

GNU Bayonne 2 is a fully portable server, which may be used under a large number of different 32 and 64 bit operating systems, and is not bound to any machine architecture. Hence, GNU Bayonne 2 may be used with machines that have Sparc, PowerPC, S/370 chips, or other architectures equally as well as on Intel-based commodity PC hardware. While GNU Bayonne 2 is very portable, this manual only tries to cover installation on POSIX operating systems, such as GNU/Linux, xBSD, Solaris, or MacOS X. The information here is not directly relevant to other platforms which GNU Bayonne 2 may also support, such as Microsoft Windows, QNX, or specialized realtime and embedded systems. Installation instructions specific to Microsoft Windows will be covered in a special guide which will accompany the GNU Telephony CAPE installer.

2 Building GNU Bayonne

While GNU Bayonne 2 is a very large and complex service, it is built and installed in a manner that is no different from other GNU packages. GNU Bayonne 2 uses a “configure” script that is generated from Autoconf and uses Automake to generate Makefiles. This section will cover the basics to get you started, while the remaining sections will help you in building GNU Bayonne 2, based on specific configurations and platforms.

2.1 Before you begin

GNU Bayonne 2 differs from most software packages and services one may deploy on GNU/Linux systems in one key respect: to be useful, it may require computer telephony hardware. This hardware can take many forms, and comes in different telephone voice line capacities, as well as support for many different types and forms of telephone circuit interconnection. Bayonne may also be used for simply testing a soundcard, and can be used without physical hardware as an IP telephony application server. Most commonly, we assume GNU Bayonne 2 will be used as a voice application server that sits behind an existing telephone switch, such as an enterprise PBX system or an IP voice gateway. However, GNU Bayonne 2 can also be connected and used with the public telephone network directly.

Given these wide ranges of uses, all of which may depend on specific hardware products, with their own characteristics and capabilities, you'll first have to decide how, and for what purpose, GNU Bayonne 2 will be used for. Then, if you are building a traditional wired telephony application server, you will have to choose which vendor's hardware will be used with it, based on the intended deployment and on the capability or suitability of the various computer telephony hardware products which GNU Bayonne 2 supports.

If you already know how you intend to use GNU Bayonne 2, and already have the optional computer telephony hardware that you plan to use, it is strongly suggested that you skip ahead to the subsection of this manual that describes your hardware before going through the next few sections. In the hardware section (4), you will find information on what steps must be done to configure and install the drivers and/or libraries that come with your given hardware. These steps must often be done BEFORE you begin installation of GNU Bayonne 2 itself.

If you have not selected your computer telephony hardware yet, check the different hardware sections. You will get a good idea of what products, from each vendor, are supported by GNU Bayonne 2 and might meet your needs. However, we do not recommend any one hardware solution from any specific vendor over comparable solutions from other vendors. There is neither product reviews nor comparisons in the hardware section, just information on known issues of compatibility, configuration, and installation.

Once you have installed your computer telephony hardware and/or support for IP voice protocol stacks, and have verified that it is functional, as outlined in the relevant sections, you should proceed to the following section on building the server.

2.2 Bayonne user and group

One of the first things you should do is create a “bayonne” user and group account. The bayonne user account is the user account that the Bayonne server will run under when started by “root”. This can be created as a system account using something like “adduser -r bayonne”. The bayonne group is used so that you can assign the device nodes of your computer telephony hardware under group permission with rw access under “bayonne”, and then assign individual user accounts you may wish to access your computer telephony cards under to the bayonne group.

You do not need a user or group named “bayonne” for this purpose; you could run Bayonne under the same group and user id that Apache uses, for example. The group and user that Bayonne runs under are set in the file /etc/bayonne/server.conf. This setting may be changed from its default of “bayonne”, or left blank, in which case the server, when started under root, will remain running under root. However, it is generally advised to remove root permission from Bayonne in case of possible security issues in the code.

The other reason to use a group assignment of “bayonne” and to associate user accounts with the group is that Bayonne creates control and data files that may be accessed under group “bayonne”. Hence, if you want to administer your running Bayonne server that is started by root, you can selectively enable other user accounts to do so by adding them to the bayonne group, rather than having to do a su or login to the bayonne user.

2.3 Building from released source packages

Before you can build and use GNU Bayonne 2, you must build and install GNU Common C++ 2, GNU ccAudio 2, and GNU ccScript 3. These packages are also part of the GNU system, and may be downloaded from or any GNU mirror site. If you are using the Bayonne SIP driver, you will also need GNU ccRTP, oSIP, and eXosip. The following table provides links to your nearest mirror site.

Package Download area
GNU Common C++ 2
GNU ccAudio 2
GNU ccScript 3
GNU Bayonne

2.3.1 GNU Common C++

The first package you should download and build is GNU Common C++ 2. The other packages will not build unless it is installed.

After downloading GNU Common C++, you can unpack it with:

  tar -zxvf commoncpp2-{VERSION}.tar.gz

Substitute VERSION with the version of your package.

To install GNU Common C++, enter the commoncpp2 directory you have unpacked to, and run the “configure” script. For GNU/Linux systems, this script can be run simply with ./configure. The default installation directory is /usr/local. If you wish to install GNU Common to /usr, then enter “./configure --prefix=/usr”. Once configure completes, simply run make install.

2.3.2 GNU ccScript 3 and ccAudio 2

Next, you should download the current versions of GNU ccScript 3 and GNU ccAudio 2 (ccscript3 and ccaudio2). Unpack each package as above (2.3.1), and run the configure script with the same options you selected when building GNU Common C++ 2 (if any). Then simply run make install.

2.3.3 Optional packages

If you are going to use SIP, then you should download the current version of GNU ccRTP. Unpack it as above, and run the configure script from the ccrtp directory with the same options you selected when building GNU Common C++ 2 (if any). Then simply run make install.

Depending on your platform and needs, it will be useful to pre-install a number of other packages. For GSM audio processing in ccAudio 2 and Bayonne, you will want to install libgsm and its dev package (typically “apt-get install libgsm1-dev” on Debian-based systems). For ODBC database connectivity in ccScript 3 and Bayonne, you will want to install unixODBC (typically “apt-get install unixodbc-dev” on Debian systems). To generate class documentation, you will want Doxygen installed. For creating Bayonne's PDF manuals you will need pdfLaTeX, as found in the teTeX extras package. [In 2017, this package is part of the normal TeX distribution (texlive-base in Debian).]

At this point, if you plan to use specific computer telephony hardware, then you should also have installed any device drivers, header files, and link libraries that were part of, or required by the computer telephony hardware you will be using. If you are using a CAPI-based computer telephony card under GNU/Linux, then your distribution may already include the CAPI library needed for building GNU Bayonne, and you need not have anything else installed. Many non-CAPI cards include link libraries and drivers that must be present for the card to work and to be controlled by external programs. Please follow the notes in the different hardware sections, based on your hardware, and make sure your hardware is working correctly before you download and install Bayonne.

2.3.4 GNU Bayonne

You may now download the current version of GNU Bayonne 2 (bayonne2). Unpack it as before, then enter the package directory and run the configure script. The Bayonne configure can be passed a number of options that control what features will be enabled or disabled. These can be used to tailor the server image for specific applications where only a selected set of GNU Bayonne's features and capabilities are required. How to tailor GNU Bayonne 2 is explained in section 2.4.

If you do not wish to tailor GNU Bayonne 2 – and in most cases it is unecessary to do so, then you can simply run the configure script as is with default options. The configure script will test to see what computer telephony support exists on your machine, and will then build GNU Bayonne with drivers for whatever computer telephony support it has found. You may then run make to compile GNU Bayonne 2. Before you perform make install, review the section on installing your new server (3).

It is important to make sure the libraries required for your computer telephony hardware are present first, because Bayonne's configure script automatically detects which computer telephony card libraries are present, and selects which computer telephony drivers GNU Bayonne 2 will be built with. If Bayonne is installed before your computer telephony hardware and libraries, then it will likely fail to use your hardware since it did not detect it at configure time. However, you can always re-run the configure script in the package to enable GNU Bayonne 2 to build drivers for your card if you change hardware or forget to install your hardware first.

2.4 Compile-time configure options

There are a number of compile-time options that can be selected by the configure script, and are part of both GNU Bayonne 2 and GNU Common C++. These options are specified through configure because they are options that must be selected before the package has been compiled, and cannot be altered except by re-compiling Bayonne. Many compile-time options relate to disabling specific features that you may choose not to use, and thereby result in a smaller executable image. Some compile-time options enable specific features or support, depending on which optional package is installed.

A number of options are offered in GNU Common C++ to reduce its memory footprint. If you only intend to use it with Bayonne, then these options disable features which Bayonne does not use, though other applications might. The most useful of these include the --without-compression option which removes libz support, the --without-ipv6 option which removes IPV6 socket support, the --without-libxml2 option which removes GNOME libxml2, and the --without-exceptions option which removes C++ exception-checking overhead.

GNU Bayonne 2 only uses libccgnu2 from GNU Common C++ 2. With an optimized build of GNU Common C++, and by selectively installing modules, it should be possible to deploy Bayonne on GNU/Debian systems with 8 megs of RAM or less. Future versions of GNU Common C++ may also offer an alternate “embedded” compile-time configure profile which will further reduce memory requirements by eliminating dependency on libstdc++.

Currently, Bayonne 2 is packaged with a special module which can be loaded to enable SunRPC support. As I found SunRPC is broken on some platforms, this is not enabled by default; you can access it with the --enable-sunrpc option in the Bayonne configure script. As the service is a runtime loadable plugin, and comes with a number of stand-alone binaries, in the future this may be made available as a separate package that will be named bayonnerpc.

GNU Bayonne 2 also offers the --disable-libexec option for its configure script. This option, when used, removes support from Bayonne to run external applications. This option is only recommended for systems with tight resource constraints, or when building servers for pre-bundled and dedicated applications.

Another option that is important is --with-voices=xxx. This can be used to select libraries from which languages will be installed. By default, a generic voice language system for English is installed. To get Russian and French added, for example, one would use “--with-voices="ru fr"”. Alternately, all of the languages found in a given distribution can be installed with --enable-voices.

An important configure and compile-time option is --disable-testing. This is used to disable support for build-directory execution testing, as well as other command-line features and options that would not be used in a dedicated production environment. The result is a smaller, simpler runtime production server.

Other compile-time options may be offered in the future. Most options are now configured at runtime by selecting which modules will be loaded into your Bayonne server.

2.5 Using pre-built packages

A few GNU/Linux distributions include pre-compiled and pre-packaged versions of GNU Bayonne. On these systems, all you may need to do is select the Bayonne package and install it. From that point, all dependencies will often be installed automatically for you. For example, in a Debian system, it may be possible to do an “apt-get install bayonne2”. I have considered making separate repositories supporting some distros I commonly use, but none have been set up as yet.

When installing pre-compiled copies of GNU Bayonne 2, these pre-built packages will only have support for whatever telephony hardware was available and detected on the machine that the package was originally built on. This may mean a pre-compiled Bayonne package will not work with your computer telephony hardware even if the hardware is listed as fully supported under Bayonne, simply because the machine used to build the pre-packaged distribution of GNU Bayonne 2 did not have the link libraries for your hardware installed on it.

A simple solution is to rebuild GNU Bayonne 2 on your local machine from the source package supplied by your GNU/Linux vendor after installing your computer telephony hardware. By building a new binary package from the source package, you will have a new binary package which should include support for your hardware. You can then install your newly generated binary package and have it maintained by your package management system.

GNU Bayonne 2 and each of its dependent packages also include their own .spec files, and you can use these to locally create RPM packages for your own production environment. This can be done by using the -tb option to have rpmbuild create a binary package from a .tar.gz. When you do this, or rebuild the GNU Bayonne 2 package as explained above, however, you are restricted to the compile-time configuration options that the packager originally defined. You can still modify these options in the Bayonne .spec file and build installable binary packages tailored for your environment.

2.6 Building from development sources

[This part was rewritten in 2017 to reflect changes that happened since 2005: the source code has moved from CVS to other version control systems (VCS), and the latest versions of Bayonne depend on uCommon instead of Common C++.]

The source code of each package is available on Savannah servers, in one or several repositories that are listed on the project's web page:

Package Project's web page
GNU [u]Common C++
GNU ccScript
GNU ccAudio 2
GNU Bayonne

You will find explanations on how to check out or clone a given repository by following the link to the “Source Code Manager” of the repository, in the “Development Tools” section of the project page.

As explained in section 2.3 (Building from released source packages), GNU Common C++ (or its successor uCommon) should be installed first, then GNU ccScript, GNU ccAudio 2 (and optionally GNU ccRTP, oSIP and eXosip), then finally GNU Bayonne.

The main difference with released packages is that you will have to generate the configure scripts by running a special command from the root of the working directory: ./reconfig for older versions, and ./ for recent ones. Then you can run ./configure, make, and finally make install.

With a local clone or checkout of the repository, you can update your installation through the version control system itself. For example, git pull from your bayonne directory will download the latest changes. You should then run ./, ./configure, and make install as you did originally. Of course, you should update the commoncpp directory first.

You can also use the VCS to create patches for GNU Bayonne 2 or any of its dependencies. For example, you can use git diff to create the patches you want to submit to the Bayonne mailing list <>. Don't forget to run git pull before you start each work session!

3 Installing Your New Server

When building Bayonne from source, somewhere between performing make (to compile Bayonne) and make install, there are a number of things you can do to determine that your newly compiled server is functional.

3.1 Testing your Bayonne drivers

After compiling your new server, you can immediately test it to see if it is functional without having to do any further configuration. Bayonne can execute directly from the working directory you are building from, using a special test mode. This test mode can also allow you to determine if your hardware or IP voice driver configuration is actually working and operates correctly with Bayonne, even before Bayonne itself has been installed for production use.

GNU Bayonne test mode is activated by passing the --test option when running the server. You can run the server and test applications delivered with GNU Bayonne without installing the server, using --test. There is also a server test directory (called tests) which contains test scripts you can run to test various driver features. You should cd to this directory and look at the various script files present here. They each contain comments which explain what they test and what you can expect when you run one.

To run a given test script with a driver, you can execute the shell script testit from this directory. To run the DTMF test script with the soundcard driver, for example, you would execute ./testit dtmf.scr. This basically runs “../server/bayonne --test soundcard dtmf.scr”. With the soundcard driver, the server will startup in test mode, and “wait” for an incoming call. This can be simulated by pressing the space bar. The soundcard driver is useful because you can use the keyboard to simulate DTMF input, and get a basic idea of server functionality very easily.

You can use test scripts to test any driver from this directory before installation. For example, to run the same test application for the dialogic driver, you can enter “../server/bayonne --test dialogic test.scr” from the tests directory. The server will start up in test mode and offer test.scr to the next incoming call received on your dialogic card.

Another useful option for testing the server from the build directory is --debug. You would normally use this in place of the --test option, as in, for example, “../server/bayonne --debug dialogic test.scr”. When used in debug mode, the server will fall into the GDB runtime debugger if it crashes. This can then be used to examine and debug the server.

3.2 Editing config files

Once Bayonne is installed, you will have to at minimum edit config files to indicate which driver you want the server to run when it is started. The simplest way to do this is to edit the /etc/sysconfig/bayonne file and set the DRIVER= line to specify the driver you are using. You may wish to set your default language and voice library settings in this file as well.

The actual location of the “bayonne” driver and base configuration file will vary based on your operating system and distribution. For example, on typical GNU/Linux systems that are based on the RedHat distribution, you find /etc/sysconfig/bayonne. This same file may be /etc/conf.d/bayonne on a typical Debian or Gentoo GNU/Linux system. On FreeBSD, this will be found as /etc/defaults/bayonne.conf. In addition, there is a directory, /etc/bayonne, which will hold all the configuration files used by the server after it is started.

The Bayonne server itself is normally run as a daemon process, and may be started from your system initialization scripts using the bayonne.init script. This script is supported under chkconfig, and “chkconfig bayonne on” will enable Bayonne services to run the next time your system is booted. You may also start the service immediately by invoking the startup script with the command “/etc/rc.d/init.d/bayonne.init start”.

Once you have the server installed and running, you will want to look at the administration guide. The admin guide includes information on how to schedule inbound calls with the scheduler file, and all of the many things found in the /etc/bayonne directory. That information is beyond the scope of this manual.

3.3 Installing on GNU/Linux

Generally Bayonne is most widely tested and deployed on GNU/Linux. If the target machine can compile GNU Bayonne 2, it will generally run fine. GNU Bayonne 2 is not dependent on kernels, glibc versions, or gcc. GNU Bayonne 2 uses threading extensively, but supports both older Linux pthread support and the new NPTL threading found in 2.6 kernels (and early Fedora releases) just as well. Any modern GNU/Linux distribution should work fine, as well as most older distributions, including Debian Woody, RedHat 6.x and later, etc.

What you will find if you choose to use H323 support, is that recent OpenH323 releases may only compile or work correctly on certain GNU/Linux distributions. Also, the distributions of OpenH323 included in many GNU/Linux distributions predate 12.1 and will often not build correctly with GNU Bayonne. When this happens, it is generally recommended that you do NOT install the pre-packaged version of OpenH323 that came with your GNU/Linux distribution, but rather build and install OpenH323 from a current release tarball found on

Similarly, many of the computer telephony cards supported under GNU/Linux either come with binary drivers, or drivers that only compile with specific kernel or glibc releases. These may also restrict your choice of distributions further.

GNU/Bayonne attempts to be compliant with FHS in the layout and use of system directories. This means if you know FHS or are using a LSB-compliant GNU/Linux distribution, then GNU Bayonne will by default install things consistent in locations generally consistent with LSB & FHS as other packages do.

GNU Bayonne is also aware of the split between Debian-based GNU/Linux distributions, and so-called “RedHat”-based ones. On the latter, GNU Bayonne installs its master system config file as /etc/sysconfig/bayonne, and its init script under /etc/rc.d/init.d. On a Debian-based system, the master system config file is found under /etc/conf.d/bayonne, and the init script is under /etc/init.d.

Generally, I have tested GNU Bayonne 2 GNU/Linux support on non-x86 hardware. GNU Bayonne 2 audio processing is endian-aware and it does compile on other common GNU/Linux target architectures such as PPC, S/390, etc. Availablility of computer telephony hardware usable on some of these targets may limit the ways GNU Bayonne 2 may be used on them, but for a pure IP voice server, any of these alternative platforms should prove workable and may offer some distinct advantages.

3.4 Installing on MacOS X

GNU Bayonne 2 works fine under recent versions of MacOS X. Many of the issues identified for GNU/Linux and BSD systems apply to Bayonne under OS X as well. However, the only driver fully usable at this time is the SIP driver. If more recent versions of openH323 can successfully compile under OS X, it may be possible to use the Bayonne H323 driver as well. The soundcard driver will not be usable until OS X audio support is fully completed in ccAudio2.

3.5 Installing on Free/Net/OpenBSD

Building and using GNU Bayonne 2 under BSD is no different than using a GNU/Linux distribution. GNU Bayonne 2 supports FreeBSD threads and re-entrant libraries and generally behaves best under newer versions of BSD distributions (FreeBSD 5.3, OpenBSD 3.6, NetBSD 2.0, or later) which fully support native threads and SMP. However, there are issues. First, there is a lack of supported computer telephony hardware available on FreeBSD. This limitation will largely restrict one to using SIP or H323. The OSS-testing sound driver plugin does also work on FreeBSD, although there are some quirks in its behavior on some BSD systems.

When building GNU Bayonne 2 on FreeBSD, many GNU/Linux-specific characteristics are retained, including the use of FHS file system layout. However, the GNU Bayonne 2 master config file is stored where expected for FreeBSD, i.e. under /etc/defaults/bayonne.conf. In the future we will offer a bayonnerc init script.

3.6 Installing on Solaris, AIX, HP/UX, etc.

In theory at least, GNU Bayonne 2 should be able to compile and install under Sun Solaris, and make use of Solaris threading. In fact, any Unix target supported by POSIX threads (pthread, with or without SunOS extensions) should be able to be used, including such systems as IBM AIX, HP/UX, etc. In the case of HP/UX, GNU Bayonne 2 will likely be compiled by the HP C++ compiler. In practice, none of these platforms have been tested by me directly, although there have been reports of people successfully building GNU Bayonne 2 under Solaris for use with the Solaris port of the QuickNet LTAPI driver. If you have success with these platforms, or have specific patches to offer to make them work, I would be interested in knowing about this. It may also be true that GNU Bayonne 2 might happen to compile and/or run under UnixWare, although no effort has been made to establish this and no effort will be made to support that platform.

3.7 Installing on Microsoft Windows

This would be covered in a separate manual to be included in the future with the CAPE installer.

3.8 Notes on SMP and multi-core systems

To support very large port densities under GNU Bayonne 2, it is generally recommended to use SMP systems. GNU Bayonne 2 is already fully threaded and optimized for SMP use, although it can be tuned further to optmize SMP performance. In particular, some drivers offer the option of setting the number of parallel dispatch threads, with the default being just “1”. These values should be increased in the appropriate config files for true SMP systems.

On many SMP-aware operating systems, memory allocation is still often singular, and this can lead to unnecessary lock delays. On AIX, this can be tuned by selecting multiple heaps, and this is the preferred method to use for GNU Bayonne 2 on that platform. Using a special SMP-optimized memory allocation library, such as “libhoard” is also recommended.

4 Hardware Support

When a GNU Bayonne 2 server is started, it will install support for a particular family of computer telephony hardware or IP telephony stack. This family is installed at runtime through a DSO plugin. When a driver for a given family of hardware is selected, this generally means that one or more computer telephony boards of that product family may be used.

Some GNU Bayonne 2 frameworks support multiple driver plugins and the use of multiple families of computer telephony cards in one running instance. This means you can, for example, install both SIP and Voicetronix hardware in the same machine, and have both running together in the same instance of the GNU Bayonne 2 framework. You may also be able to have different vendor cards on the same server if you start multiple instances of GNU Bayonne, with each instance started with a separate driver plugin. The default Bayonne application server only supports loading a single driver type into a running instance. Some alternative servers built on the framework will offer loading of multiple drivers to meet specific needs.

Many of the GNU Bayonne 2 drivers can not only support multiple boards of a given hardware family, but may also support mixing different types of boards from a given family of hardware together in a single running image. For example, one can use any combination of one or more supported analog and digital telephony cards from Intel/Dialogic with the Bayonne Intel/Dialogic driver in GNU Bayonne 2.

Some GNU Bayonne 2 driver plugins may only support one type of card installed in a given running instance of the server. The current GNU Bayonne 2 Voicetronix driver, for example, supports the use of either Voicetronix OpenSwitch12 or OpenLine4 cards, but not the use of both of these cards together in the same server. The exact limitations and range of hardware support are detailed in the subsection on each hardware family.

4.1 Using the OpenH323 driver

First, you will need to install a modern distribution of OpenH323. This may be found at A version of OpenH323 > 12.0 and PWLib >= 0.5 should work. Earlier versions will not. You can compile and install each of these packages with make install to the default directory, and Bayonne will be able to find and use your OpenH323 configuration. It may be able to use other kinds of installation configurations as well.

Because there is no reliable means to auto-detect which version of OpenH323 is installed, and the entire Bayonne build process will halt if an older and unsupported version is found, OpenH323 support and auto-detection is now disabled by default in the Bayonne configure script. You will need to use “./configure --enable-openh323” to explicitly activate it. Since various versions of OpenH323, source builds, and pre-packaged distros of OpenH323 all use different methods for locating and configuring installation paths for OpenH323 libraries and includes, the auto-detect code found in the configure script may not be sufficient; two extra configure options also exist: --with-pwlibdir=path, and --with-openh323dir=path.

If you do all these things, and all the prerequisites are met, GNU Bayonne should compile. When using the --enable-openh323 option during the “configure” process, you will want to look for the line: “checking for openh323 libraries... found. If this appears in the output of configure, then probably everything is fine.

While current OpenH323 support is built around the standard OpenH323 distribution, Bayonne 2 will soon migrate to use Opal. From Opal we will also adapt IAX2 and perhaps an alternate SIP driver.

4.2 Using the SIP driver

[The location of the source code was updated in 2017.]

oSIP2 and eXosip can be downloaded from and, respectively.

You can also retrieve the development sources from Savannah as explained under “Building from development sources”.

Next, go into the osip directory, and run the ./ command. This will build the configure script. Now you can run ./configure, followed by make install.

Once oSIP2 is installed, go into the exosip directory, and run ./ there. When you run configure, do so as “./configure --disable-josua”. Now you should be able to do a make install. Finally, go (back) to the bayonne directory, and perform the configure and build steps there (2.3.4).

4.3 Using Intel/Dialogic hardware

GNU Bayonne 2 has been tested successfully with both Analog and Digital span voice processing cards from Intel. One or more Intel/Dialogic cards may be placed in a given server and used directly. Intel/Dialogic cards of different types may also be mixed together.

When multiple cards are used in a GNU Bayonne 2 server, it is necessary to interconnect the SC-bus cables accross all of your cards. GNU Bayonne also requires sufficient voice processing resources to be available for all the ports you wish to accept calls on concurrently. Voice processing can be shared between different cards over the SC-bus directly.

GNU Bayonne 2 supports a single driver for Intel/Dialogic hardware based on Intel/Dialogic Global Call services. This driver supports both analog cards and single or multi-span T1/E1 cards used on PRI circuits, and provides support for DM3 voice cards as well as older lines of Intel/Dialogic hardware. This driver can work with older releases of Intel/Dialogic runtime systems, but it is recommended that the latest, 5.1 (SP1) be applied and used under GNU/Linux with GNU Bayonne 2.

The driver supports automatic detection of your Intel/Dialogic hardware, and requires minimal configuration options in GNU Bayonne 2 using a single [dialogic] section in /etc/bayonne/drivers.conf. You are required to install a Dialogic driver/SDK kit.

4.3.1 Know your hardware

The next section is meant to simplify the installation process for System Release 5.1 with Service Pack 1 (SP1) for GNU/Linux, with a separate section on DM3-based hardware. DM3-based cards can be used with the GNU Bayonne 2 Intel/Dialogic driver.

Before beginning the installation, it's crucially important to know what hardware you have and to verify that it's supported by this release. The list of supported hardware is in the Release Guide. Read it; know it. Furthermore, GNU Bayonne 2 requires that, whatever combination of hardware you use, sufficient voice resources are present. This means that if you use non-DSP span termination cards, you may need to also have SC-bus DSP resource cards in your system for a working configuration.

Basically, there are 2 different hardware families of Intel/Dialogic hardware – Springware and DM3. The Springware family has been around for a long time and includes everything from 2-port analog cards up through dual-span cards with 48 ports. The DM3 family begins at 48 ports per board and goes up from there.

The easiest way to tell the difference is to look at the model name on the card bracket sticker. All DM3 hardware will have a model name that starts with DM/ while Springware model names will start with plain D/ (or MSI/ for the MSI cards). For instance, a Springware card might have a model name of D/480JCT-2T1 while a DM3 card might have a model name like DM/V480A-2T1. You get the drift.

There is an excellent FAQ which describes how to install the Intel/Dialogic runtime for GNU/Linux already, and I will not repeat this here. The key point, however, is that the current release of their driver requires the LiS streams package, and Intel/Dialogic recommends using LiS 2.13.16. Moreover, the driver and SDK are only certified for use with either RedHat 7.2 GNU/Linux with the 2.4.9-13 (or greater) kernel update, or RedHat 7.3 GNU/Linux with the 2.4.18-5 (or greater) kernel update RPM.

My own experience with the Intel Dialogic SDK's have suggested that it is far better to actually use LiS 2.14.6 or later, which are more stable than the deprecated and unsupported 2.13 beta series for LiS. Also, it has been said that any GNU/Linux distribution that is somewhat similar to these RedHat releases may also work fine with a little extra work, including Debian (Woody?) and several Mandrake releases. However, you may try those at your own risk of a failed SDK install.

If you are installing DM3 hardware, please be aware that the configuration and installation of the SDK for this hardware requires some extra steps. In any case, if the installation is successful, you will be able to start your dialogic runtime environment by running “/etc/rc.d/init.d/dialogic start”. If you try this, you have the hardware installed, and it initially fails, sometimes it helps to simply reboot the machine after installing their SDK.

Assuming the startup completes normally, your next step is to test your Intel/Dialogic hardware and SDK configuration. This is important to do before you try configuring and using GNU Bayonne 2 if you are inexperienced with Intel/Dialogic hardware. Very often we find many questions come up on the mailing list that are not Bayonne issues at all, and which could have been resolved simply by doing these tests before trying to get Bayonne to work with your configuration.

4.3.2 Testing your system

The best/only way to test DM3 hardware is via the few DM3-capable demo programs that are included;
/usr/dialogic/demos/gc_demos/gc_basic_call_model, essentially.

You can run the test as follows:

  # cd /usr/dialogic/demos/gc_demos

  #  vi  gc_basic_call_model.cfg
     # Edit this file to reflect the boards/channels/protocols
     # to be tested. If you don't get this setup right, it
     # won't work!!

  # ./gc_basic_call_model

If you get an error from gc_Start(), reboot the system. There are some library dependencies that get resolved at boot time.

The software furnished for testing Springware hardware is much broader and is really dependent on your hardware. Specifically, analog vs. digital, ISDN vs. robbed-bit, etc. However, you can (and should, actually) use the afore-mentioned gc_basic_call_model program, which has the advantage of working with all hardware and all protocols.

Other programs are also available:

If you cannot get Bayonne to run with your Springware hardware, please, first test that your system is really working, that your carrier spans are really configured correctly, etc., and try these programs before requesting help on the Bayonne mailing list.

4.3.3 Driver options

In order to fully utilize all of GC, you'll need to download the latest protocol package. So, if you are using the GlobalCall driver, you may as well get that now. [In 2017, this package is obsolete. It used to be available from]

We assume that, at the time of GNU Bayonne 2 release, the Bayonne GlobalCall driver will support full auto-detection of Intel/Dialogic cards. However, you still need to specify the protocols that are being used by digital span cards as part of the [dialogic] section of /etc/bayonne/drivers.conf. To understand how this works, we should review how Intel/Dialogic names line protocols.

4.4 Using Voicetronix hardware

The Voicetronix driver supports two types of Analog DSP computer telephony cards (OpenLine4 and OpenSwitch12) made by Voicetronix ( Both cards use the same driver, which may be downloaded directly from the Voicetronix site.

Download the latest driver, something like vpb-driver-2.2.24.tar.gz. Untar it to a directory, such as, say, /usr/src/vpb. Enter the directory you have unpacked the driver in and perform a “make OSTYPE=linux”. This will build the Voicetronix card driver for your machine.

The first problem you will find is that the Voicetronix driver requires the Linux kernel sources to be installed on your machine. You must install these, and then perform a “make menuconfig” in your Linux source directory to ensure there is at least a default build configuration.

Assuming you do this, and then return to compile the Voicetronix driver again, you will find that, on at least some GNU/Linux distributions, it will still not compile. This is because most current 2.4-based systems assume that the kernel sources are referenced through /usr/src/linux-2.4, and the Voicetronix driver simply assumes /usr/src/linux. What I typically do is modify Voicetronix Makefile so that the kernel include path matches up correctly for current distributions. You can do this, or just create an extra symlink under /usr/src/linux.

Assuming you are able to compile the source, you should then perform a “make OSTYPE=linux install”. This will install the kernel driver modules, an include file, and a link library. Unfortunately, the vpb package chooses to install the vpb link library (libvpb.a) under /usr/local/lib, and the include file (vpbapi.h) under /usr/include. I suggest moving both either to /usr or to /usr/local, as Bayonne may fail to find or properly build Voicetronix support, depending on what prefix it is configured for, if these are mixed up this way.

Next, you will need to install the Voicetronix kernel modules. This can be done with the insmod command. If you have OpenLine4 cards, then you need only perform an “insmod vpb”. If you have the OpenSwitch12 card, you will also need to perform an “insmod vpbhp”. These drivers will be shown in the kernel, and you will need to find out what major device numbers they are using from /proc/devices.

Once you determine the major device numbers, you must create device nodes. If the vpb device is “254”, for example, you will create 4 device nodes: “mknod /dev/vpb0-3 c 254 0-3”. You should set the file permissions for these devices to enable the userid that you will run the Bayonne server under to access them. Ordinary user accounts can access and use Voicetronix hardware if you choose appropriate permissions to enable this. What I typically do is create a separate “bayonne” entry in /etc/groups, and selectively add specific user accounts to that group. You can then create your device nodes under the bayonne group and give that group rw privileges to the device. If you have an OpenSwitch12 card, you will also need to create a device node for /dev/vpbhp0 using the device's major number.

If you are using the VoiceTronix OpenSwitch series of cards, you will need to specify VPB_MODEL=V12PCI in your environment. The current driver will autodetect the number of ports and cards you have in your system, but it will not allow you to mix OpenSwitch and OpenLine cards in the same machine.

4.4.1 About the OpenSwitch12 card

The OpenSwitch12 card is a complete PBX on a single board. This allows you to directly plug analog telephone stations into the card and use them as internal extensions, as well as plug your incoming analog phone lines to it. The OpenSwitch12 is a full-length PCI card. Some tower cases now being made choose to extend drive bays down the entire length of the case. These cases will not accept a full length PCI card and you will not be able to fit an OpenSwitch12 card in them. As with all PBX cards, you need to follow the vendor's instructions to avoid damaging your phone service and your card. Specifically, we would not want to plug a trunk line into a station port.

Another issue you will find with the OpenSwitch12 card is that the card must operate on a separate and unshared IRQ vector. If you install your card and insert the vpbhb driver module, you will see in /proc/interrupts what IRQ your card is using. If it is using an IrQ that is not used by any other device, then, after inserting the driver, you will see the number of interrupts incrementing in /proc/interrupts each time you check it. If this is not happening, but the device is listed, along with any other device that also is using the same IRQ, then your card will simply not function.

The simplest way I found to get around this problem was to disable the serial ports, and then use the plug-and-play BIOS to force the PCI slots to use the IRQ range of the serial devices (IRQ 3 and 4). Most motherboard-based resources tend to start from IRQ 10, although other PCI cards will also do this to share IRQ's. Unfortunately, the OpenSwitch12 card does not share.

The card can be configured to operate either as a 12 port analog DSP telephony card, as a card with 4 telephone extensions and 8 phone lines, as a card with 8 telephone extensions and 4 phone lines, or as a card which supports plugging in analog telephones on all 12 ports. This use is configured by a set of onboard jumpers which are labeled on the card. Some of these configurations allow for failover, where, if the card is inactive or the server dies, the first 4 trunk ports are connected to the first 4 analog telephone stations. Here is the common jumper setting:

Standard setup:
JS1, 2, 5, 6 and H1-H16 are jumpered so that Bank A, 0..7 are set as station;
Fail-Over is enabled: H27-34 are jumpered.

Next you will need to make cables for your card. Each of the 3 RJ-45 ports on the back of the Voicetronix card supports 4 telephone lines.Take a look at the connectors on the back of the card. Since you probably have your card in your PC, here is some info on the connectors on the back (labeled on the circuit board J1, J2, and J3):

J1 is furthest from the PCI slot
J2 is in the middle
J3 is closest to the PCI slot

The Readme.OpenSwitch12 document describes the OS12 pinout in the “Port Wiring” section. There it is explained that physical connectors J1 and J2 are Bank A. Connector J3 is bank B. Bank A is always ports 0 through 7, and Bank B is always ports 8 through 11.

J1 = ports 0..3 of Bank A
J2 = ports 4..7 of Bank A
J3 = ports 8..11 of Bank B

Harken back to the jumpering section, and we can safely say that we have jumpered the four ports closest to the PCI slot to be trunk ports (the phone company lines get connected here.)

If the tab of an RJ45 is pointing down (you are looking at the conductor side), and the head is flush against your palm, pin 1 is biologically proximal to your wrist, and pin 8 is distal. That is, pin 8 is away from you.

4.5 CAPI4Linux and GNU Bayonne

4.6 Using soundcards

While soundcards are not actually “computer telephony” hardware, they can also be used with GNU Bayonne 2. This can be very useful since one can develop, debug, test, or even to some extent demonstrate common GNU Bayonne 2 applications without having computer telephony hardware physically installed on the machine you are using. This is particularly useful in larger development environments where not every hacker has a production server with what might be expensive computer telephony hardware sitting on their desk or available for their exclusive use. Support for using soundcards is built by default, and Bayonne can be started with the soundcard driver by passing the --test soundcard option to the bayonne command.

When GNU Bayonne 2 is used with a soundcard, it will always execute in the foreground rather than as a background daemon. The keyboard will act as a telephone keypad and can be used to simulate DTMF key interactions. The spacebar can be used to start the application you are demoing under the soundcard driver, and the “H” key can be used to simulate a caller hanging up. You can use CONTROL-C or “D” to shutdown Bayonne.

GNU Bayonne 2 uses /dev/dsp to operate the soundcard, and may not work correctly with some broken soundcards that only support fixed (44.1khz) sample rates. Otherwise, it should work on any GNU/Linux machine that one is able to get sound working on. Support exists for soundcard audio on Microsoft Windows as well. The OS X soundcard support is currently broken, but this is a ccAudio2 library issue.

4.7 Hardware quick reference

The following table summarizes the computer telephony hardware supported by GNU Bayonne, and the names of drivers used. These names are used during server startup when passed to the Bayonne server as “--test name” or “--load name”. They may also be entered in the /etc/sysconfig/bayonne file.

Name Driver Summary
capi20 Capi Driver Driver for CAPI-2.0-compliant BRI & PRI cards
globalcall Intel/Dialogic analog Span cards under GlobalCall driver
soundcard OSS Sound Driver Soundcard driver for testing
voicetronix Voicetronix Driver OL4 and OS12 telephony cards

5 Copyright

Copyright (C) 2005 David Sugar.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. The text of the license is available at