Bayonne FAQDavid Sugar
2001-04-13
Contents
What packages do I need to compile Bayonne?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:
What distributions do I need to compile Bayonne?Bayonne should compile and run under any modern GNU/Linux distribution. Bayonne M5 and above should compile and work under elf based FreeBSD distributions.
I just built bayonne, and when I start it I get a segfaultThe 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 called "pika". 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.
Why can't I get Bayonne to recognize my telephony hardware?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.
OK but it still fails to find my telephony api after I put it there!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.
Why won't my Dialogic (or CT Access) driver plugin start?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".
I keep getting a %{exec_prefix} error and the server diesYou 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.
Where is my /etc/bayonne.conf??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.
I always get an "unable to open" message when using the play command.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.
What packages do I need to compile Bayonne under FreeBSD?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.
What threads does Bayonne use under FreeBSD?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 -prefix=/usr.
I cannot get any of the packages to compile or configure under FreeBSDUse "CXXFLAGS=/usr/local/include LDFLAGS=/usr/local/lib ./configure". This is done in all my "ports" Makefiles.
Are there RPM's?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.
Are there Deb's?No, not yet, though some are being contributed, and we hope to have them for M4.
Can I use this with FreeBSD?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 ports collection.The current 0.4.4 release may already compile and operate correctly under FreeBSD.
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.
What languages does Bayonne support?Currently Bayonne is internationalized and supports both English and French. Other languages will be added as volunteers supply appropriate voice libraries.
Can bayonne be used for multiple languages?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.
What's the minimum hardware required for Bayonne?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.
How do I tune threads?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.
How do I tune stacks?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.
How do I tune memory usage?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.
How do I prevent swapping?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.
How do I get caller id to work!?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.
I think I found a bug!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 appropiate. 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 bayonne-bugs@gnu.org. Or you can use the online bug reporting system found at http://www.sourceforge.net/projects/bayonne. Please understand that the maintainers of the software are volunteers, and so prioritize their work to fix 'show stoppers' first, and add enhancements later.
Where can I get additional help or join inThe 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 bayonnne-devel-request@gnu.org.
|