Introducing Contributed Modules in OpenSIPS

Lately, we have been receiving more and more pull requests introducing new modules in OpenSIPS. This is definitely something we encourage, as these contributions bring new features, integrations, and fresh ideas, often coming directly from developers using OpenSIPS in production.

We would like to see even more of these modules becoming part of OpenSIPS, and make them available to the community as quickly as possible. However, integrating a new module also comes with the responsibility of maintaining it and providing support, something we believe can be shared with the community.

For this purpose, we have introduced a new category of modules, called Contributed Modules, allowing developers to contribute new functionality while remaining involved in its maintenance and support.

Why Contributed Modules?

The idea is simple: bring more modules into OpenSIPS, faster, with their development and maintenance driven by the community.

This should encourage a wider variety of contributions, including new integrations, alternative implementations, and ideas coming from real-world deployments, while the OpenSIPS core team continues to supervise their integration into the project.

The New modules-contrib/ Directory

For this purpose, we have introduced a new directory in the OpenSIPS source tree, called modules-contrib/, alongside the existing modules/ directory.

The difference between them is mainly related to their maintenance model:

• modules/ — regular OpenSIPS modules, maintained by the core development team.
• modules-contrib/ — contributed modules, maintained primarily by their authors and the community.

This does not mean that contributed modules are merged without any checks. The core team will still supervise their integration, making sure they follow the project’s licensing, documentation, and build requirements, and checking for obvious security or stability issues.

However, we will not necessarily perform a complete code review or functional validation. The authors and the community will remain responsible for fixing bugs, implementing new features, and providing support, while the core team’s involvement will be on a best-effort basis.

Note that this is not necessarily a permanent classification — a contributed module may eventually be moved to the regular modules/ directory, once it has been sufficiently tested, reviewed, and adopted by the community.

Building Contributed Modules

From a technical perspective, contributed modules are no different from regular OpenSIPS modules — they use the same APIs and are loaded and configured in exactly the same way.

The only difference is that they are not compiled by default. Instead, we have introduced a new Makefile target that explicitly builds them:

make modules-contrib

If you want to compile all the available modules, both regular and contributed, you can use:

make all-modules

To give a more concrete example, let’s consider the cachedb_perf module, recently proposed by a community contributor. It implements a high-performance, in-memory CacheDB backend, using a different approach for memory management and concurrency handling.

Such a module is a good candidate for the new modules-contrib/ directory, considering the complexity of its implementation and the effort required to properly review it.

Once integrated into this directory, it can be individually compiled and installed using:

make modules=modules-contrib/cachedb_perf modules-contrib
make modules=modules-contrib/cachedb_perf install-modules-all

Afterwards, using it is no different from using any other OpenSIPS module. For example, to use it as a CacheDB backend for topology hiding, we can simply configure:

loadmodule "cachedb_perf.so"
modparam("cachedb_perf", "cache_collections", "th=16")
modparam("cachedb_perf", "cachedb_url", "perf:///th")
loadmodule "topology_hiding.so"
modparam("topology_hiding", "th_state_url", "perf:///th")

And that’s it! From the OpenSIPS script perspective, there is no difference between a regular and a contributed module.

Packaging

Besides the build system, we have also updated the Debian and RPM packaging infrastructure to handle the new module collection.

Similarly to the regular modules, contributed modules are distributed in two types of packages:

• opensips-modules-contrib — contains all contributed modules that do not require additional external dependencies.
• opensips-module-contrib-<module> — individual packages for modules that depend on external libraries.

For example, once the packages are published in the repositories, installing all the dependency-free contributed modules on Debian/Ubuntu would simply require:

apt install opensips-modules-contrib

This way, contributed modules remain optional, and existing installations are not affected unless explicitly installing the new packages.

Conclusions

With the introduction of the modules-contrib/ directory, we hope to simplify the integration of new community modules into OpenSIPS, while keeping the review and maintenance effort manageable for the core team.

The new module collection is now part of the OpenSIPS source tree, and we encourage developers to take advantage of it by contributing new modules, testing existing ones, and helping maintain them.

We are looking forward to seeing what new functionality the community will bring to OpenSIPS!

Happy hacking!