Reviewed-on: gnutelephony/bristol#23 Co-authored-by: David Sugar <email@example.com> Co-committed-by: David Sugar <firstname.lastname@example.org>
|2 weeks ago|
|.gitlab/issue_templates||9 months ago|
|cmake||2 weeks ago|
|drivers/test||2 weeks ago|
|server||2 weeks ago|
|test||9 months ago|
|vendor||3 weeks ago|
|.clang-tidy||4 months ago|
|.gitattributes||4 months ago|
|.gitignore||4 months ago|
|.gitlab-ci.yml||8 months ago|
|CHANGELOG.md||3 weeks ago|
|CMakeLists.txt||2 weeks ago|
|CONTRIBUTING.md||4 months ago|
|Doxyfile||8 months ago|
|LICENSE.md||9 months ago|
|README.md||8 months ago|
|TODO||9 months ago|
|config.hpp.in||4 months ago|
Bristol makes legacy telephony networks available to IP telephony services thru the SIP protocol and RTP media sessions. Bristol 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
Modern iterations of Bayonne are now focused on providing application driven voice services on pure modern IP telephony networks, such as for use with SIP and H323 call servers. Bristol has inherited the mission of supporting generic telephony card drivers and providing gateway services between IP based telephony and the legacy analog and digital (ISDN, T1, etc) telephony world. Like with GNU Bayonne past, Bristol offers support for different telephony hardware thru loadable drivers.
Basic documentation, including an architecture overview, will be added as markdown files. An installation guide for various GNU/Linux distributions and BSD systems may also be added. A driver guide for building Bristol with support for various telephony hardware will also be provided. Developer documentation can be generated from source file headers using Doxygen.
Bristol requires eXosip2 version 5.1.2 or later and either openssl or libressl for SIP support. Bristol also may require various SDK's and/or driver kits from telephony card vendors to build specific drivers. The most generic GNU Bayonne hardware driver was Linux CAPI support, and this has been replaced with the mISDN stack. If the systemd support library is present at build time then support for the systemd notify socket may also be added.
When a cmake Debug build is produced, this 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. The preferred cmake build type for live installation and running of debug builds is RelWithDebugInfo.
When installing Bristol, header files are also installed. This allows drivers to be developed and compiled separately from Bristol itself. We export the symbol space of the Bristol 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.
A more complete overview of participation will be 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. Bristol can be built with gcc or clang and can be tested on any posix platform where suitable telephony drivers are supported.
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.
Support is offered thru our issue tracker using email@example.com. I also have firstname.lastname@example.org. Build support and packaging, especially for openSUSE and Debian GNU/Linux, is found on the openSUSE build service (https://build.opensuse.org/project/show/home:dyfet). In the future maybe other means of support will become possible.