Sipcraft will be an enterprise class on-premise IP telephony system.
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.
David Sugar 0a13461fa1 Clean up event handling (#37) 2 days ago
cmake Limit jemalloc to release builds (#35) 3 weeks ago
db Project modernization work 2 months ago
server Clean up event handling (#37) 2 days ago
test Remove filesystem and plugins. 7 months ago
vendor Vendor fix for exosip2 epoll bug (#32) 4 weeks ago
.clang-tidy Resolve "Improve Quality" 4 months ago
.gitattributes Remove gitlab config files (#20) 2 months ago
.gitignore Clean ignore 4 months ago Prep next release (0.0.7) (#33) 3 weeks ago
CMakeLists.txt Clean up event handling (#37) 2 days ago Update primary docs for gitea (#22) 2 months ago
Doxyfile Resolve "Improve Quality" 4 months ago Initial checkin 9 months ago Update primary docs for gitea (#22) 2 months ago
TODO Initial checkin 9 months ago Resolve "Improve Quality" 4 months ago

About Sipcraft

Sipraft is an enterprise class on-premise office ip telephony system. The service would typically be used in conjunction with a telephony application server, a gateway or external VoIP provider, and also offer web integration services. Sipcraft can run on generic and lower end GNU/Linux servers, including the Raspberry Pi. Sipcraft and associated ip telephony services may also be provided in container images. My preferred installation target is Devuan GNU/Linux. A 3 digit local dialing plan and a maximum of 600 connected sip devices are supported by Sipcraft.

As an enterprise ip telephony server designed for wide integration, Sipcraft is commonly deployed with a dedicated Postgresql database server, a dedicated Bayonne application server, and a management console. A Rack based web integration service written in Ruby Sinatra will also be included. At minimum, access to a Postgresql database server will be required.

External web and integration services may also be used in place of the included one. These can then be tailored for the needs of specific markets. Sipcraft will also support facility automation as well as integrating a pa system, sip door entry systems, and sip enabled security cameras. Sipcraft will be able to register with external providers and gateways.

Sipcraft has no common code, but loosely relates to work on both gnu sipwitch and SipWitchQt. Like SipWitchQt, a backend database is used for configuration and management. The schema for this database may be part of a separate support package which can be adapted for different target market needs. A generic schema will be included using Ruby sequel to manage updates efficiently.


Basic documentation, including an architecture overview and roadmap, will be added as additional markdown files. An installation guide for various GNU/Linux distributions and BSD systems may also be added. User operation, server admin, and configuration should be similarly added here. Developer documentation can be generated from source file headers using Doxygen. Live documentation can also be made available over the web framework.


Sipcraft requires eXosip2 version 5.2.1 or later and either openssl or libressl to build and run. It also requires the Postgresql client libraries, 9.0 or later. If the systemd support library is present at build time then support for the systemd notify socket may also be added.

A typical "install" target is created to support local installation. This should include an example config file. A logrotate config can also be added. All running directories that may be required are either made by "install" or created when the service executes. Execution in daemon mode is performed by an init script or systemd unit file. The sipcraft.conf file (or custom.conf) should be edited for the postgres database that you will need to connect to.

Sipcraft will include a Ruby web integration service that can be optionally installed and started in daemon mode as well. The supporting database schema is managed thru Ruby Sequel, which can be executed to load the database and perform schema updates. Web service installation and database updates will be perform thru additional custom cmake targets.

When cmake is used to produce a Debug build this instance can be executed directly; 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 Sipcraft header files are also installed. This allows plugins to be compiled and separately developed for your Sipcraft server. Unlike some, we export the posix symbol space of the Sipcraft 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 This project uses cmake, and c++17 for core server development. We use the ctest framework for unit testing and gcovr for coverage reports. Sipcraft can be built with gcc or clang and can be tested on just about any posix platform, including bsd systems and even MacOS, not just GNU/Linux.

This project project can also be built for running unit tests using the cmake ctest framework. This is enabled by default for Debug builds. To produce code coverage reports you can cmake a debug build with -DCOVERAGE_TYPE=gcov set. You can then use the make the "coverage" target and produce reports with gcovr or lcov. The "lint" target validates code with cppcheck and rubocop.


Support is offered thru When entering a new support issue, please mark it part of the support project. I also have Sipcraft packaging build support for some GNU/Linux distributions will be found on In the future maybe other means of support will become possible.