Bordeaux is a voice application server for modern IP telephony networks using modern C++ practices along with advances originally made in GNU Bayonne.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 

5.9 KiB

About Bordeaux

Bordeaux is a voice application server for IP telephony networks. Bordeaux began with GNU Bayonne and ideas I had for creating real-time non-blocking carrier scalable general purpose telephony servers using GNU/Linux. Many of the architectural advances made in GNU Bayonne were ahead of common practices back then, and some still remain so today. This is why I am introducing Bordeaux using modern software practices as a micro-services capable Bayonne replacement without support for legacy telephony networks.

Loadable driver modules are used to adopt Bordeaux to the needs of particular VoIP phone systems. A generic driver can be used with most SIP based phone services. There may be a driver made for H323 to use with GNU Gatekeeper, and a driver specifically for IMS carrier uses. Classic telephony hardware, which GNU Bayonne originally had extensive direct support for, will be used thru thru network enabled VoIP gateways such as Bristol instead.

Docker and Podman

Bordeaux is usable both stand-alone and in a container. The definition for building a bordeaux container is a multi-stage Dockerfile which also compiles Bordeaux directly from the current "HEAD" of your git checkout. There are special ``docker-xxx'' targets to produce a container automatically for you for each driver type supported. The Dockerfile automatically stages all development tools and dependencies as needed for you. You can build bordeaux and run it in a container with just git and docker (or podman) without requiring any development environment to be setup.

The primary goal of containerization was to make it easy to reliably build, test, and deploy Bordeaux services directly from oci containers, such as for use on MicroOS, Kubernetics, etc. One would in the future use an oci image produced here as an input, add your own voice and bordeaux scripts staged in another Dockerfile, and directly deploy as needed. Another goal is to make it easy for anyone to participate in Bordeaux development.

Because the Docker builds depend on a git checkout, the stand-alone tarballs do not have cmake/docker.cmake support. The stand-alone tarballs mostly are meant to feed traditional rpm and deb packaging services. If one wants to produce a docker image from a past release, you can simply checkout the associated git tag for that release and build your docker targets from that. Premade oci images for the latest release, build for various drivers, is also found at https://reg.gnutelephony.org.

Traditional Installation

Bordeaux requires eXosip2 version 5.1.2 or later and either openssl or libressl to build drivers for and run SIP based deployments. The OpenH323 stack will be used to build GNU Gakekeeper driver support. Bordeaux normally operates as a service and if the systemd support library is present at build time then support for the systemd notify socket may also be added.

When cmake is used to produce a Debug build Bordeaux can be executed directly for testing; no further install is required. The debug build uses the config file found in the test/ directory, and a test/custom.conf file can be added with configuration overrides for local developer testing. Testing scripts, prompts, and libexec telephony lambdas may also be placed in the test/ directory. The preferred cmake build type for live installation and running of debug builds is RelWithDebugInfo.

When installing a non-static build of Bordeaux, header files are installed. This allows drivers to be developed and compiled separately from Bordeaux itself. Unlike some, we export the posix symbol space of the Bordeaux server directly, rather than using an intermediary shared library to support plugins. This is something I started long ago with Bayonne. This means symbol references and supporting code is not PIC, as happens in a shared library.

Participation and Documentation

Basic documentation is found as markdown files. An installation guide for various GNU/Linux distributions and BSD systems may also be added. A scripting guide for Bordeaux's call processing language, and a guide for writing telephony lambdas will also be included. Developer documentation can be generated from source file headers using Doxygen. Bordeaux relevant documentation may also be found in other projects that may use it to provide voice application services.

A more complete overview of participation is provided in CONTRIBUTING.md. This project uses cmake, and c++17 for core server development. We use the ctest framework for unit testing and gcovr for coverage reports. Bordeaux can be built with gcc or clang and can be tested on just about any posix platform, including bsd systems and even potentially MacOS, not just GNU/Linux.

In addition to producing testable debug builds the project can also be built for running unit tests. This is enabled by default for debug builds. To produce coverage reports you can cmake a debug build with -DCOVERAGE_TYPE=gcov set. You can then use the make the "coverage" target and produce coverage reports with gcovr or lcov. The "lint" target will validate code using cppcheck.

The easiest way to begin participation is installing doxygen and graphviz, and then building the ``docgen'' target. This produces browsable code documentation and provides quick access to project resources, such as the issue tracker, project boards, pull requests, milestones, the project development wiki, etc. Finally, https://doc.gnutelephony.org/bordeaux offers documentation built from the latest release tag.

Support

Support is offered thru https://git.gnutelephony.org/bordeaux/issues. When entering a new support issue, please mark it part of the support project. I also have dyfet@jabber.org. Bordeaux packaging build support for some GNU/Linux distributions will be found on https://pkg.gnutelephony.org/bordeaux. I also have my own build infrastructure for Alpine using ProduceIt, and I publish apk binary packages thru https://public.tychosoft.com/alpine. In the future maybe other means of support will become possible.