About -> Available Versions -> 4.0.x Releases -> Release 4.0.0 Overview
OpenSIPS 4.0 philosophy
The 4.0 version is a turning point in the OpenSIPS evolution. This is a standard release, opening the path for a new family of releases with bold aims to radically change and improve legacy concepts and code in OpenSIPS. Yes, 4.0 addresses old limitations, deprecated designs or burning needs we accumulated across years. Concepts we had from day 1 (in SER at that time) were reworked or removed; Also new concepts were added, to align OpenSIPS with the challenges of the current days.
OpenSIPS 4.0 is all about re-vamping.
TCP framework
This is probably one of the most important and challenging change brought by 4.0 release - abandoning the hulking and super-complex multi-process based TCP framework and migrating to a more slim, straight-forward multi-threaded oriented framework.
The TCP framework, as we know it (with a TCP Main process distributing connections across a bunch of TCP workers') suffered more or less no changes across its addition, more than 20 years ago. Due to the multi-process architecture, the TCP framework had to implement TCP connection "migration" and sharing across different processes.
This old approach showed its limitations. Due to the sharing constraints and also due to the overhead with passing conns back and forwarded between TCP Main and TCP workers. Even more, the balancing of the load over the workers is a bit constraint.
In OpenSIPS 4.0 we are coming up with a new approach, moving from a multi-process paradigm, to a multi-thread one. All the TCP work is done within a single process (no TCP passing anymore) with multi-threading. Multiple threads are reading and writing on the TCP cons. So the connections are managed by a single process. This process is dispatching the read messages to the OpenSIPS worker processes for SIP level handling. Also the OpenSIPS worker processes pass the messages to be written to this TCP process.
All the advantages and gains on this new approach are comprehensively described in this blog post.
TLS refreshing
The TLS support was from day 0 a real pain in the aXX. Mostly because of the multi-process model of the SIP layer. This required special memory managements (shared) and specific locking. The openSSL support drifted away from any multi-process support, requiring more and more twitches to make it work in OpenSIPS. These twitches impacted in a negative way also modules using openSSL in a single-process mode for encryption purpose only (like mysql, postgress, stirshaken, etc). Not to mention endless crashes due to dangling memory fragments, double free, mem leaking, etc.
All these are history, thanks to the new multi-threaded model of the TCP framework in 4.0 !!
StirShaken SSL rework
As the usage of the openSSL lib is quite limited, we migrated the stirshaken module away from the openSSL support to the WolfSSL library (dynamic compiling). For the OpenSSL lovers, we still have this option, but it's compile time, so you need to rebuild the module. By default, the builds will be against WolfSSL
openSSL support rework
Thanks to the TCP rework and moving to a multi-threaded architecture (for TCP engine), all the OpenSSL twitches were dropped - so OpenSIPS is fully compatible with the philosophy of the OpenSSL library. This translates into "no more crashes due to OpenSSL issues" (like due to SSL data sharing, conflicts between the OpenSSL library being differently initialized by different modules in OpenSIPS)
wolfSSL support update
For now, the wolfSSL code is still directly imported into the OpenSIPS code. More or less because the library is not widely available on the major distros. But with OpenSIPS 4.0 we update the wolfSSL code we have with the latest stable release of the wolfSSL project, bringing in all the fixes and improvements.
Versatility
Dynamic number of TM branches
This is yet another important change brought by 4.0 is the possibility to have high number of SIP branches, dynamically allocated.
From day 0, by design, the number of branches of a transaction (when doing forking to different destinations) was (a) limited to max 32 (extendable to 64) and (b) statically allocated within the transaction. These limitations translate into (a) limited number of call-hunting scenarios in Class V setups and (b) waist of memory. Real deployments showed us that 32 (even 64) branches are not enough when talking about cascading Hunt-Groups, combined with Push Notification and other Class V typical features.
So we need to be able to have more, but without wasting memory - and this is what 4.0 does - and to see how is done, check out this detailed blog post.
Bond network interfaces/sockets
Again something that exists from day 0 - for sending out a requests, you need to specify the exact interface you want to use - and if the destination is a FQDN, you have no idea if that will be translated into IPv4 or IPv6, into UDP or TCP....so you cannot force any socket/interface from script level as you do not know the details for the destination.
The solution brought by 4.0 is the bond socket, a fake socket acting as a group of real sockets - and to see how is done, check out this detailed blog post.
OpenSIPS Clusters with Bridge Replication
The OpenSIPS 4.0 release includes a new feature for the clusterer module dubbed “Cluster-Bridge Replication”. It mainly targets setups with multiple, geo-distributed data centers which make use of WAN links to exchange clustering data. Re-organizing the nodes into islands connected by bridges allows considerable bandwidth savings, especially if the WAN links are over public internet. At the time of writing, the only module benefiting from cluster-bridge replication is ratelimit, with its pipes replication.
To fully understand this feature, take a look at the blog post describing the need and advantages of this new clustering model.
Monitoring/Profiling
To better understand what is going on inside your OpenSIPS, as application or as SIP processor, a generic profiling support was added with OpenSIPS 4.0. This profiling framework allows multiple data producers and multiple data consumers. As data producers, we have right now the script interpreter, generating SIP message profiling (see below). And we also have the OpenSIPS itself, generating the process/worker profiling. As data consumers, we have the OpenTelemetry module, to push the profiling data to external observability tools/engines. And also we can consume profiling data via the Event Interface, by any external subscriber.
SIP message profiling
The executed script routes, with names and execution time, are reported in realtime via opentelemetry protocol. See the EE_PROFILING_SCRIPT event for accessing the info or the Opentelemetry module.
Process/worker profiling
Or the realtime X-ray on OpenSIPS 4.0 - in a per-process manner, the profiling generates a list of reports/events on the process activity. The idea is to give a better view on what the processes is doing (processing) in a time based manner. The events cover different processing levels - the IO reactor (idle or what kind of task is running), the SIP stack (executing the script or various TM, dialog, B2B or async callbacks), the extra processes (like MI dedicated processes, RTPproxy notification) and also the timer jobs (reporting where and what timer job is executed). The profiling data is now available via Events and controlled (general and per-process) via MI commands. See the 'profiling_proc' MI command for controlling the profiling and the E_PROFILING_PROC event for accessing the info.
OpenTelemetry support
For the collected data, we already have support for OpenTelemetry, to push the profiling data to external observability tools/engines.
Integration
Proxy Protocol
Starting with OpenSIPS 4.0, we introduced support for the Proxy Protocol, allowing OpenSIPS to transparently receive and forward the original client addressing information even when connections pass through intermediate proxies. The Proxy Protocol was originally developed by HAProxy Technologies for HAProxy, as a lightweight method for proxies and load balancers to forward the original client IP address and port to backend servers. To see how this works, check out this detailed blog post.
Prack + Update interoperability
With more and more IMS presence, the ability to deal at proxy level with PRACK and UPDATEs is a must. Both are end-2-end features, but for a trunking or SBC system connecting some end-users to IMS-enabled carriers will be impossible to stay passive - most of the end-users devices to not properly support PRACK and UPDATE, so it will make the proxying impossible.
So, in OpenSIPS 4.0, the dialog module in OpenSIPS takes the job to act as a B2BUA for PRACK and UPDATES, to facilitate the interop between IMS-enabled system and IMS-ignorant (or older) systems.
To see how this works, check out this detailed blog post.
AUTH_WEB3 support
OpenSIPS 4.0 comes with a new auth_web3 module to provide Web3-based authentication for OpenSIPS, enabling SIP authentication through blockchain technology and ENS (Ethereum Name Service) resolution.
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 4.0 by joining and following the OpenSIPS Summit 2026.