About -> Available Versions -> 3.6.x Releases -> Release 3.6.0 Overview
OpenSIPS 3.6 philosophy
The 3.6 version enjoyed a special attention as (a) it will be an LTS release and (b) it will be the one ending the 3.x series. So, closing the circle with the 3.0 release which started the 3.x series, the 3.6 release focuses on 'operational improvement'. As a note, 3.0 was focused on DevOps.
The 'operational improvement' translates into introducing and enhancing in OpenSIPS features / capabilities that (1) improve and (2) simplify the operational activities when comes to running and managing OpenSIPS.
Operational enhancements
Dynamic Sockets
Up to 3.6 version, OpenSIPS supports only statically defined SIP sockets. IF you need to add more sockets, you need to restart. This is an inconvenient in certain service scenarios, like SBCs or Trunking ones. In such cases, new sockets may have to be added (due to interconnection needs), while restarting is not the best option (due to the high volume of traffic).
The new sockets management (or socket_mgm) module is introduced by OpenSIPS 3.6 in order to provide support for dynamic sockets. This module allows sockets to be provisioned via a database and refreshed by OpenSIPS at runtime, eliminating the need for service interruptions. Through this module, OpenSIPS offers a flexible and efficient way to manage sockets dynamically while maintaining service continuity.
A more detailed description of this new addition is in this blog post.
RTP.io
The new RTP.io module provides an integrated solution for handling RTP traffic within OpenSIPS, enabling RTP relaying and processing directly inside the OpenSIPS process. This eliminates the need for external processes such as RTPProxy, resulting in a more streamlined, efficient, and manageable system for certain use cases. This means the configuring and operation simplifies. Traditionally, OpenSIPS only handles signalling, offloading media operation to the external relay. However in some situations using external relay may be undesirable from system complexity point of view and others, so having an option to handle it internally may be useful.
Config variables
The new config module is designed to simplify runtime configuration management in OpenSIPS by introducing a dedicated $config(...) variable. This variable provides easy and direct access to configuration values from within the OpenSIPS script, significantly reducing scripting complexity.
A more detailed description of this new addition is in this blog post.
Enhanced REDIS support
The REDIS module now has support for column-oriented cacheDB operations, using Redis Stack Server features such as RedisJSON and RediSearch. This now allows cachedb_redis to be used as backend for the user location (usrloc) module, in both Federation and Full-Sharing modes of operation. The Redis server-side JSON support is auto-detected, with appropriate startup logs being displayed (zero-configuration).
AWS integration
The 3.6 version brings an even smoother integration with AWS environment, new AWS services are to be natively supported by OpenSIPS. Here we have the noSQL database DynamoDB and queuing service SQS.
More detailed descriptions of these new additions may be found in SQS blog post and DynamoDB blog post.
Janus integration
The new JANUS module is a OpenSIPS connector for the Janus websocket protocol. It can interact with one or more Janus servers either by issuing commands to them, or by receiving events from them.
This driver can be seen as a centralized Janus connection manager. It will connect to each Janus server, establish the connection handler ID and the clients can be transparent from the connection handler ID point of view, simply passing the desired Janus commands that they want to run.
Operational easiness
Unified branching support
OpenSIPS 3.6 comes with a major re-work of the SIP branching management (an critical asset for doing parallel forking). The first step was to unify the message and transaction branches, so you can correlate and control them before and after the SIP signalling. The next steps were to enhance the branch support to allow the addition of custom per-branch data - attributes and flags. And the final step was to add support for inter-branch data access - to be able to access data from other branches, to dynamically search for branches and interact with their data.
A more detailed description of this new addition is in this blog post.
Structured SDP manipulation
The ability to do fine but complex changes over the SDP at opensips.cfg level is as important as doing it for the SIP signaling. Such ability has been on our radar for quite some time now, as it was initially targeting the OpenSIPS 3.2 release. The OpenSIPS 3.6 release addresses these two main problems: (A) the need of pushing and merging changes over the SDP from different modules; and (B) lack of granular and structured access (read write) to the SDP.
Now, in OpenSIPS 3.6, we do solved these two problems – not only you do have fine-grained control over the SDP body, but also your SDP changes will become visible the moment you do them.
A more detailed description of this new addition is in this blog post.
All
There are many many other changes with this release, and you can read about all of them in this detailed listing.
Learn more about OpenSIPS 3.6 by joining and following the OpenSIPS Summit 2025.