resiprocate is a C++ SIP stack you compile from source

Nine components, from a core stack to a proxy and a TURN server

The repository is not one library but a set of them, and the layering is the first thing to understand. At the bottom sits the resip library, described as a full RFC3261 SIP stack. Above it is dum, the Dialog Usage Manager, a high level SIP library for creating SIP user agents, which deliberately carries no media stack. Then recon, a high level SIP user agent library that includes media stack integration. On top of these sit applications. rePro is a SIP proxy server. reTurn is a STUN and TURN server, and there is a matching reTurn client library. MOHParkServer is a SIP based music on hold server built with recon, and reConServer is a SIP based back to back user agent server with media, also using recon. Finally tfm is described as a SIP based SIP framework, which is the test framework the rest of the code is verified against. The people who benefit are engineers building a SIP element rather than an application: a proxy, a registrar, a gateway, a softswitch component or a TURN server. The people who should look elsewhere are those who want to place a call through an existing stack.

Choosing dum or recon decides whether media is your problem

The distinction between the two high level libraries is the single most consequential choice in this codebase, and it is easy to miss because both are described as high level SIP user agent libraries. dum has no media stack at all. recon includes media stack integration. That means a project that only needs signalling, for example a registration client, a presence watcher or a component that hands call setup to something else, can take dum and avoid pulling in media handling, and the project description states the no media stack property as a feature of dum rather than a limitation to work around. A project that needs to carry RTP itself, to bridge two calls, to run a music on hold server or to terminate and reoriginate media, needs recon, and the two server applications in the list, MOHParkServer and reConServer, are built on recon for exactly that reason. Choosing wrongly is expensive in one direction and cheap in the other. Starting from recon and never touching media means carrying the media stack for nothing. Starting from dum and then needing media means a port across a layer boundary in the middle of a project.

The Linux build is three commands and a long package list

Building in tree means running cmake and make from the directory holding the top level CMakeLists.txt file:

$ cmake .
$ make

The out of tree form is also documented, and it is the one to prefer if you keep several configurations side by side:

$ mkdir cmake_build # Or any other name
$ cd cmake_build
$ cmake ..
$ make

Unit tests then run through ctest, with a verbose variant listed as ctest -V. The README also notes that starting fresh means deleting the build directory or the CMakeCache.txt file. The heavier part of the setup is the package list. The default enabled configuration expects git, make, cmake, clang or g++, gperf, libssl-dev for TLS, libc-ares-dev, libasio-dev, libboost-all-dev, libdb++-dev, libsrtp2-dev, libgeoip-dev, libpopt-dev, libcppunit-dev, libqpid-proton-cpp12-dev and the media sample tools sox and xxd. That is a lot of system packages before a single line of your own code compiles, and the documentation is candid that some Linux packages are hard to track down.

Every optional integration is behind a CMake flag

The build system is designed so that anything not core can be turned off, and the flags are the way to negotiate with your distribution. The documentation shows that options are CMake cached variables, listable with cmake -LH and settable on the command line as in cmake -DWITH_C_ARES=true. The optional list is long and each entry names its own flag: default-libmysqlclient-dev under USE_MYSQL, libfmt-dev under USE_FMT, libgloox-dev under BUILD_ICHAT_GW, libgstreamermm-1.0-dev under USE_GSTREAMER, postgresql-server-dev-all under USE_POSTGRESQL, libradcli-dev under RESIP_HAVE_RADCLI, libsipxtapi-dev under USE_SIPXTAPI, libsnmp-dev under USE_NETSNMP, libpq-dev and libsoci-dev under USE_SOCI_POSTGRESQL, libtelepathy-qt5-dev under BUILD_TELEPATHY_CM, libwebsocketpp-dev under USE_KURENTO, and python3-cxx-dev with python3-dev under BUILD_PYTHON. Two defaults are called out with specific guidance. QPID Proton can be turned off with cmake -DBUILD_QPID_PROTON=OFF when you do not need what it provides. And Netxx, which the TFM test framework requires, is built from the copy in the contrib folder by default because the old libnetxx-dev package is no longer available on modern distributions; use cmake -DUSE_CONTRIB_NETXX=OFF to use a system copy instead, or cmake -DBUILD_TFM=OFF to drop the test framework entirely.

Windows builds go through Visual Studio or CMake from a prompt

The Windows path is documented in three variants, and they differ only in how the build is driven. The Visual Studio GUI route opens resiprocate.sln from the build folder and uses Build, then Build Solution, and unit tests are run by right clicking the RUN_TESTS project and building it. The command line route configures with cmake . -B _build, builds with cmake --build _build --config Debug --parallel, and runs tests from inside that directory with ctest --build-config Debug --output-on-failure. A third route opens the resiprocate folder with the Visual Studio Open Folder feature and uses the CMake GUI, where build settings live under Project, then CMake Settings for resip. Media support through sipXtapi needs extra flags, and the documentation is specific about the order of operations: configure with -DUSE_SIPXTAPI=ON, and if you want the sipXtapi projects inside the Visual Studio solution, add -DSIPXTAPI_PROJS_IN_VS_GUI=ON and build once before those projects are fetched from GitHub, then reload the solution and build again. The repository ships several solution files for different toolchain generations, including reSIProcate_16_0.sln, reSIProcate_17_0.sln, recon_16_0.sln and recon_17_0.sln, which is one sign of how much of this codebase predates the current CMake based workflow.

A C++11 floor and a CI pinned to older compilers

The documentation states that the minimum required C++ version is currently C++11, which is a useful floor to know but also a hint about the age of the code. The required package list notes that the resip CI uses clang-13, lld-13 and g++-10, and the only officially supported and tested configuration is the latest release of the compiler you choose. That combination, a C++11 minimum alongside CI running on compilers several major versions old, tells you this is a codebase that has to keep compiling on older toolchains, which matters if your distribution ships an older compiler by default. The tree reinforces the impression of a long-lived project rather than a new one. It includes deprecated/ and p2p/ directories, several Visual Studio solution files for different toolchain generations, an emacs/ directory and an eclipse-ellemtel-code-style.xml, a .clang-tidy configuration, an AUTHORS file, svn-authors.txt and svn-authors.ldif, and a RELEASE-PROCESS.txt. There is also an AUTHORS and COPYING set under the LICENSE.md file at the root, whose licence is not one GitHub can classify.

Releases, the licence file, and what to read before you commit

The project is not archived and the last push was on 2026-10-19, so work continues on the master branch. The release history is slower than the commit activity. resiprocate-1.14.0 was published on 2026-06-18, resiprocate-1.13.2 on 2025-05-14 and resiprocate-1.13.1 on 2025-01-16. The gap between 1.13.2 and 1.14.0 is more than a year, so an upgrade is a large jump rather than an incremental one, and the RELEASE-PROCESS.txt file at the repository root is where the mechanics of a release are described. On licensing, the file is LICENSE.md and it is a custom licence that GitHub cannot classify, which means you cannot infer the terms from a badge or a tag. For an organisation using this in a product, that file is the first document to read, not an afterthought, because a SIP stack gets linked into the server you ship. The practical sequence for an engineer evaluating this repository is therefore: read LICENSE.md, pick the layer you actually need between resip, dum and recon, install the packages that layer requires, and configure the build with the flags that match the features you are going to use rather than accepting every default.

Editorial conclusion

Adopt resiprocate when you are writing a SIP or TURN component that needs protocol level control, when you can install the Boost, Asio, OpenSSL and libdb++ dependency set and build with CMake, and when you have read LICENSE.md. Do not adopt it for a hosted calling product, for a small SIP client, or if you need a build that resolves with a couple of packages. Verify first that your toolchain meets the C++11 minimum, that the optional features you need have their libraries present, and that the licence terms in the LICENSE.md file match what your organisation can accept before you write code against the libraries.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. resiprocate/resiprocate on GitHub