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.

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.

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.

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.

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. .

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.

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.

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 [[https://blog.opensips.org/2026/02/17/big-scale-sip-forking/|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 here is to create bond interfaces, groups of sockets to serve a logical destination (like "towards carriers" or "towards internal" or "towards customers") and contain a listing of real sockets with various protocols and AF's. OpenSIPS will automatically pick from the group the socket matching the final proto:ip:AF:port coordinates. A bond socket/interface can be used at script level as any other socket.

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

Right now the wolfSSL code in directly imported into the OpenSIPS code. Why ? more or less for the same reason as we needed the openSSL twitches. The wolfSSL needs special compiling flags in order to work in a multi-process environment. This means we are stuck to a certain verions, without easy way to update to latest releases of wolfSSL. Thanks to the TCP rework and moving to a multi-threaded architecture (for TCP engine), we will be able to dynamically link to the wolfssl library, without any special twitches. So, we will have access to the latest versions, on different distros.

https://blog.opensips.org/wp-content/uploads/2026/02/opensips-4.0-revamp-small.jpg

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.

The IMS Working group compiled a Scope Of Work, which helped in laying down the actual requirements. The group decision was to tackle, at this first stage, the CSCF components, together with its interfaces.
As results, this translated in work across several module along with the addition of new specialized modules.

AKA digest authentication

Present in the S-CSCF, the AKA authentication mechanism (RFC 3310) is implemented by the new AUTH_AKA module. Its complex interaction through the Cx/Dx Diameter interface is provided by the new AKA_AV_DIAMETER module, responsible for fetching and managing the authentication vectors required by AKA.

IPSEC support

Present in the P-CSCF

AAA support

Presence support

This work was undertaken by the IMS OpenSIPS Working Group (IMS OWG), a gathering of people with common inters in IMS, working together to draft, design and implement the IMS support in OpenSIPS.
The IMS Working group compiled a Scope Of Work, which helped in laying down the actual requirements. The group decision was to tackle, at this first stage, the CSCF components, together with its interfaces.

https://blogopensips.files.wordpress.com/2023/11/opensips-4.0-ims-dia.png

The IMS topic is a very large and complex one. And the goal here was to design and implement an IMS support that is truly able to provide solutions for the industry. So, a quite extensive stage of exploring, understanding and designing on the IMS ecosystem was required in a first stage.
This task was undertaken by the IMS OpenSIPS Working Group (IMS OWG), a gathering of people with common inters in IMS, working together to draft, design and implement the IMS support in OpenSIPS.

https://blogopensips.files.wordpress.com/2023/11/opensips-4.0-ims.jpg

Bits and pieces of the IMS (IP Multimedia Subsystem) topic were part of the previous OpenSIPS release, but this 4.0 fully focused on the IMS part. Considering the traction and need of IMS solutions, the implementation of a consistent and large IMS support in OpenSIPS was a mandatory step in order to answer to the needs of the industry.

The IMS topic is a large one, transcending the SIP protocol and the scope of OpenSIPS. So, the OpenSIPS 4.0 worked out the parts of the IMS ecosystem which are based or related to SIP, of course.

IMS

SQL operations

Launch Darkly

Message Queue

Various topics were addressed by the past releases, but most of the work with regards to each topic was mainly covered within a single release, so limited in terms of allocated resources (time and man-power). And some of these past topics are actually wider than what we managed to deliver. This is why the OpenSIPS 4.0 addressed the consolidation of various past topics, to complete or even expand them. But one of the most important sides of this consolidation process is the testing of OpenSIPS, from the performance and conformity perspective. This testing was a long overdue task that definitely needs to be addressed.

B2B enhancements

SIPssert testing engine

Performance and profiling testing

Logging

Miscellaneous but important

https://blogopensips.files.wordpress.com/2021/12/opensips-4.0-im.jpg The instant messaging is evolving and gaining more and more importance. This happens in both worlds of VoIP/ITSP and IMS/MNO/MVNOs - and the overlapping and mixing of these worlds in increasing each year. The OpenSIPS 4.0 is to address more, in depth, the topic of Instant Messaging, in the context of SIP. And this is done through two major perspectives: from the Unified Communication perspective, by aligning IM with the voice and presence capabilities in OpenSIPS, and from the IMS perspective, mainly as support/integration with RCS (Rich Communication Services).

Learn more from this blog post about the OpenSIPS 4.0's vision on Instant Messaging in the IMS and Unified Communication ecosystem

----

Messaging sessions or MSRP

Clustering engine

Unified communication

IMS

Status Report support

TCP boost

More Media relaying

Another new OpenSIPS module, that is able to manipulate calls/dialogs going through OpenSIPS, along with UAC/UAS dialogs (call originated or terminated into OpenSIPS), with the sole propose of mixing the RTP media between these multiple flows. The idea is to make possible the injection of streams of media from / to proxied calls, with the help of auxiliary calls initiated by OpenSIPS. Typical example is to play media within an existing call/dialog with nothing more than simple re-INVITEs - OpenSIPS will initial a new sip call to a media server, in order to get the RTP stream for the playback and it will push it into the proxied call by triggering in-dialog re-INVITEs.

As we already have for transactions, the dialog module will allow the script writer to set, in a per-dialog fashion, script routes to be triggered by various dialog events. Similar to t_on_failure(route), you can do dlg_on_timeout(route) to have a route called when the dialog lifetime is exceed. In the route, you may decide to extend the lifetime, to terminate the call or do any other logging. We can foresen dlg_on_answer(route), dlg_on_terminate(route)' (and more) triggers, which will give a better interaction and control over the ongoing calls.

For both RTProxy and RTPEngine, OpenSIPS will be able to report to the OpenSIPS script the DTMF events sampled from the passing RTP. This will make possible the implementation of simple IVRs and/or authentication via DTMF with nothing more than OpenSIPS and the media relay.

In Class 5 services, BLF is an important feature. Besides working out clustering support for BLF, an important task is reworking the BLF implementation to be call-branch aware, to be able to properly report the call events in parallel calling or call hunting scenarios.

Instead of using the XML scenario to drive the B2B logic (mixing between the calls), we want to use the OpenSIPS scripting for this purpose. This will eliminate all the limitations of the XML language (logic and action) and it will tremendously increase the level of integration of the B2B engine with the rest of the OpenSIPS functionalities. Shortly, more complex B2B logic will be possible, and also better integrated with the rest of OpenSIPS.

An important improvement of the B2B engine will be the addition of the B2B context, to help in correlating all the entities (UAC, UAS) part of a B2B session, to attach custom data to the entities and to exchange such data between the entities. This will help with Accounting and media relaying support for B2B, but also with building custom data sharing inside a B2B session (or between the sessions).

• distributed call-center or a geo-distributed single call queue which gets calls via different OpenSIPS instances and which distributed agents connected to different OpenSIPS instances.

Dealing with Robocalling and CLI spoofing becomes a must when building advanced calling solutions. The support for STIR/SHAKEN will be part of OpenSIPS 4.0, providing multiple usage models, in terms of how the certificates are to be handled during the verification process. Also a flexible approach (to the standards) will be able to cope with all the potential changes derived from the adoption process (of the standard by the providers).

Without actually using a Back2Back model, but simply operating with calls (dialogs, UACs or UASs), many complex class 5 calling (and call mixing) scenarios may be scripted.

A new OpenSIPS module, placed on top of dialog module, will allow remote control over the calls going through OpenSIPS. The module will expose a simplified set of commands (API like) for setting up new calls, for answering and terminating calls, for transferring or putting on-hold calls - all these without interacting with the end-devices, but triggering and handling the action only from the OpenSIPS (as proxy) level.

Another new OpenSIPS module, that is able to manipulate calls/dialogs going through OpenSIPS, along with UAC/UAS dialogs (call originated or terminated into OpenSIPS), with the sole propose of mixing the RTP media between these multiple flows. The idea is to make possible the injection or stream of media from / to proxied calls, with the help of auxiliary calls initiated by OpenSIPS. Typical example is to play media within an existing call/dialog with nothing more than simple re-INVITEs - OpenSIPS will initial a new sip call to a media server, in order to get the RTP stream for the playback and it will push it into the proxied call by triggering in-dialog re-INVITEs.

B2B engine

Improve the media

Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 4.0 release will focus on complex call crafting, basically on increasing OpenSIPS's ability to create and handle complex calling scenarios where multiple SIP calls are mixed and able to interact. Or shortly said, the 4.0 release will address the Class 5 specific calling features and how to control such calling features via APIs.

Dealing with Robocalling and CLI spoofing becomes a must when building advanced calling solutions. The support for STIR/SHAKEN will be part of OpenSIPS 4.0, providing multiple usage models, in therms of how the certificates are to be handled during the verification process. Also a flexible approach (to the standards) will be able to cope with all the potential changes derived from the adoption process (of the standard by the providers).

Push Notification (RFC8599)

The existing PN support will be improved and aligned to the requirements as per newly adopted RFC 8599. Besides the notification itself, we need to address some particularities in contact registration, derived from privacy concerns or device identification concerns.

noSQL adds-on

The DB layer needs a constant attention, so here is the plan for 4.0:

• add support for Dynamo noSQL DB, from Amazon, to improve the experience when comes to running OpenSIPS in AWS cloud.
• support for raw queries for Cassandra

https://blogopensips.files.wordpress.com/2019/12/opensips-4.0-crafting.jpg Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 4.0 release will focus on complex call crafting, basically on increasing OpenSIPS's ability to create and handle complex calling scenarios where multiple SIP calls are mixed and interacting. Or shortly said, the 4.0 release will address the Class 5 specific calling features and how to control such calling features via APIs.

As usual, all the OpenSIPS major releases are in depth presented during the OpenSIPS Summit yearly events. So, the 4.0 release is the star of OpenSIPS Summit in Amsterdam, May 2020.

Class 5 calling ingredients

Without actually using a Back2BAck model, but simply operating with calls (dialogs, UACs or UASs), many complex class 5 calling (and call mixing) scenarios may be scripted.

Calling API

A new OpenSIPS module, placed on top of dialog module, will allow remote control over the calls going through OpenSIPS. The module will expose an simplify set of command (API like) for setting up new calls, for answering and terminating calls, for transferring or putting on-hold calls - all these without interacting with the end-devices, but triggering and handling the action only from the OpenSIPS (as proxy) level.

Call mixing

Another new OpenSIPS module, that is able to manipulate calls/dialogs going through OpenSIPS, along with UAC/UAS dialogs (call originated or terminated into OpenSIPS), with the sole propose the mixing the RTP media between these multiple flows. The idea is to make possible the injection or stream of media from / to proxied calls, with the help of auxiliary calls initiated by OpenSIPS. Typical example is to play media within an existing call/dialog with nothing more than simple re-INVITEs - OpenSIPS will initial a new sip call to a media server, in order to get the RTP stream for the playback and it will push it into the proxied call by triggering in-dialog re-INVITEs.

Per-call hooks

As we already have for transactions, the dialog module will allow the script writer to set, in a per-dialog fashion, script routes to be triggered by various dialog events. Similar to t_on_failure(route), you can do dlg_on_timeout(route) to have a route called when the dialog lifetime is exceed. In the route, you may decide to prolong the lifetime, to terminate the call or do any other login. We can foreseen dlg_on_answer(route), dlg_on_terminate(route)' (and more) triggers, which will give a better interaction and control over the ongoing calls.

SDP topology hiding

Due to the specificity of class 5 scenarios, there is a real need to completely decouple the SDP's (not only from IP/port perspective) from the caller and callee side, like hiding the originator or overwriting the session name and version.

DTMF support

For both RTProxy and RTPEngine, OpenSIPS will be able to report to script the DTMF sampled from the passing RTP. This will make possible the implementation of simple IVRs or authentication via DTMF with nothing more than OpenSIPS and the media relay.

Extended BLF support

In Class 5 services, BLF is an important feature. Beside working out clustering support for BLF, an important task is reworking the BLF implementation to be call-branch aware, to be able to properly report the call events in parallel calling or call hunting scenarios.

Dialog module enhancements

We are looking at a good set of additions for the dialog module, like:

• improve the way of correlating multiple dialogs, and also to exchange data between calls (like accessing data specific to a call from a totally different call)
• sending in-dialog requests, crafted from script level
• better support for UAC or UAS like dialogs (not only proxy like)

Back-to-back support

The existing B2B implementation in OpenSIPS has some limitations, so we are looking to overcome via some major rework here.

Script driven B2B

Instead of using the XML scenario to drive the B2B logic (mixing between the calls), we want to use the OpenSIPS scripting for the purpose. This will eliminate all the limitation of the XML language (logic and action) and it will tremendously increase the level of integration of the B2B engine with the rest of the OpenSIPS functionalities. Shortly, more complex B2B logic will be possible, and also better integrated with the rest of OpenSIPS.

B2B clustering support

To be 100% production ready, an High-Availability support maybe available for the B2B engine. This will be achieved by adding clustering and replication support for the B2B calling.

B2B context

An important improvement of the B2B engine will be the addition of the B2B context, to help in correlating all the entities (UAC, UAS) part of a B2B session, to attach custom data to the entities and to exchange such data between the entities. This will help with Accounting and media relaying support for B2B, but also with building custom data sharing inside a B2B session (or between the sessions)

Call Center

For 4.0, we are looking at:

• adding clustering support and data replication for the call queue - this is extremely important for achieving High-Availability.
• more feature and metrics for managing the call queue
• distributed call-center or a goe-distributed single call queue which gets calls via different OpenSIPS instances and which distributed agents connected to different OpenSIPS instances.

Device Feature Key Synchronization (DFKS)

DFKS support is planned for OpenSIPS 4.0. This will help to keep feature settings in sync between multiple device and application servers, an essential need in a class 5 / PBX environment.

STIR/SHAKEN

https://blogopensips.files.wordpress.com/2018/12/opensips-4.0-icon.png For the upcoming OpenSIPS 4.0 release (and 3.x family) the main focus is on the devops concept. This translates into introducing and enhancing in OpenSIPS features / capabilities that (1) will increase the easiness when comes the writing / developing OpenSIPS scripts and (2) simplify the operational activities when comes to running and managing OpenSIPS.

This OpenSIPS 4.0 release is the star of OpenSIPS Summit in Amsterdam, April-May 2019 - beside presentations and workshops around the new cool things in this version, OpenSIPS 4.0 will also be the subject of several interactive demos on its new capabilities.

Script Development aspects

Generic Preprocessor Support

This feature adds full built-in pre-processing support for the OpenSIPS script. OpenSIPS 4.0 integrates various existing pre-processors within OpenSIPS. This simplify the scripting itself, the script portability across multiple servers and not to mention the entire deployment process of more complex platforms (where OpenSIPS is just a part of it). Even more, you will be able to use your preferred pre-processor and align OpenSIPS with the rest of your system (M4, Jinja, Embedded Ruby or others).
Read a full description of this feature here.

Module Functions Now Benefit From a New Parameter Interface

As a response to frequent mailing list complaints of wildly varying behaviors across different module functions (e.g. some accept integers/strings as inputs while others accept both integers/strings or variables holding such values), we've introduced an abstract layer which handles the parameter passing task for all module functions, effectively making all of them more powerful by globally allowing flexible input. An added benefit is that new OpenSIPS modules are now even faster to develop. See the new function calling conventions here.

Operational aspects

Routing Script Re-load

OpenSIPS 4.0 exposes the valuable ability of reloading the routes (not the module configuration) during runtime, with zero penalties and with zero loses as traffic. See the documentation of the MI "reload_routes" function.

Processes Auto-Scaling Support

This is the ability of OpenSIPS to scale up and down the number of processes at runtime. Basically OpenSIPS is able to automatically scale up (by forking new processes) according to the volume of traffic, or to scale down (terminating some worker processes) if the internal load is low. This means you do not have to worry if your estimation on the number for worker processes is correct or not (will my OpenSIPS hold to the traffic??) or to worry about planning restarts during the night (to manually resize the number of processes).
Read a full description of this feature here.

New OpenSIPS CLI (Command Line Interface) tool

Starting with OpenSIPS 4.0, the old opensipsctl tool becomes deprecated (as functionality and as software) and it is replaced by the new opensips-cli - a powerful Python3 application that allows you to interact in a smart way with OpenSIPS, to invoke advanced tools such as diagnose or tracer, as well as to perform DB provisioning. Read a full description of opensips-cli here.

Selectable Memory Allocator Support

This feature allows the internal memory manager to be selected at startup time. In OpenSIPS 4.0, the memory manager selection becomes a startup option, via command line arguments, allowing you to change it without any need to recompile or redeploy. Read a full description of this feature here.

Internal Memory Persistence during Restart

As there are several modules caching (in OpenSIPS internal memory, not in external no-sql cachers) large chunks of data, like Dynamic Routing, Dialplan, Dispatcher or Permissions, OpenSIPS 4.0 is able to avoid the date loading and caching penalty during a restart - this segments of the internal memory do "survive" during the restart. This dramatically reduces the time to restart of the entire service.
Read a full description of this feature here.

Unified Sharing Tags for Clustering

In 2.4, each module (with clustering support) is managing its own sharing tags completely isolated from other modules - this make the operating OpenSIPS a bit difficult sometime, as for a single switch from active to backup, you need to individually inform and change the tags in several modules, via several MI commands. In OpenSIPS 4.0 we have now the sharing tags managed by clusterer module itself and shared between multiple modules. So with a single MI command, changing a single sharing tag, you can control all the cluster-aware modules (like dialog timeouts, nathelper pinging, dispatcher pinging, etc) Read a full description of this feature here.

Integration aspects

MI Interaction Standardization

An extensive rework of the Management Interface in an attempt to standardize and speed up development of external applications which need to interact with OpenSIPS. The custom, JSON-based HTTP calls of OpenSIPS 2.X are now replaced with the JSON-RPC version 2 standard. The custom, line-oriented syntax was completely dropped. XMLRPC and mi_html (former mi_http) were kept backwards-compatible. Read a detailed description of the new interactions here

SMPP support

OpenSIPS 4.0 provides a new SMPP module that allows you to do bidirectional gatewaying between SIP and SMPP traffic - this is a powerful but flexible way to integrate with most of the SMS providers / gateways. Read a full description of this feature here.

RabbitMQ Consumer support

A new RabbitMQ consumer module which manages connections with one or more brokers, subscribes for events and exports them at OpenSIPS script level via the event interface.

But the full list of goodies offered by OpenSIPS 4.0 (and a more technical one too), together with migration instructions, can be found on the OpenSIPS 4.0 release notes page.

https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg?w=300&h=200 The OpenSIPS 4.0 version is built around the clustering concept - today’s VoIP world is getting more and more dynamic, services are moving into Clouds and more and more flexibility is needed for the application to fully exploit such environments. But let’s pin point the main reasons for going for a clustered approach:

• scaling up with the processing/traffic load
• geographical distribution
• redundancy and High-Availability

the rest

The success of this release - in terms of achieving its integration goal - was strongly weighted by the collaboration with the teams of the partner projects, like SIPCapture, FreeSWITCH or CGRates. A collaboration in terms of ideas, brainstorming, solutions and of course, work. A collaboration that resulted in solutions and benefits for all the involved communities.

The best of

SIPCapture/Homer integration

The integration with the SIPCapture engine was a hot topic again. The work in this area focused in adding two new concepts (both on OpenSIPS and SIPCapture sides) when comes to capturing:

• non-SIP tracing - if up to this point, all the tracing was SIP-centric, now you can capture and visualize more types of data. You can capture information from transport layer (TCP, TLS, WS, WSS), information on the REST queries you performed from OpenSIPS script, information about the MI commands and also the script logs. All this information will help you (from operational perspective) to have a global view over how your OpenSIPS is doing (and lot limited to the SIP level only) - in other words, monitoring and troubleshooting will became much easier.
• data correlation - now that you have so many types of data traced, it is vital to be able to correlate them - to know what were the TCP/TLS/WSS connections involved in a SIP call, to know which were the REST queries or logs triggered by a call handling. Such correlation concept gives a new dimension to the tracing concept - you can navigate and jump between different data types in order to understand the relation between them (like why a SIP call failed by looking at the data from the transport level)

FreeSWITCH integration

As a powerful Class5 Engine, FreeSWITCH is the perfect complementary tool for OpenSIPS

About -> Available Versions -> 4.0.x Releases -> Release 4.0.0 Overview

OpenSIPS 4.0 philosophy

http://www.gearitservices.com/Portals/0/SitePics/SystemIntegration.jpg The OpenSIPS 4.0 version is built around the integration concept - the OpenSIPS ability to integrate and work together in all possible means with other projects, protocols, systems or concepts.
Why is integration so important to end up being the main tag of a major release? Well, everybody in the VoIP world is operating VoIP platforms/systems – and these are more than SIP Engines (as OpenSIPS is). Indeed, the SIP Engine is the core and most important part of the platform, but to build something usable and useful, you need additional components into your platform like CDR/billing engines, monitoring and tracing tools, data backends, non-SIP trunking or more specialized SIP engines. Shortly you need your SIP Engine (OpenSIPS, of course) to be able to easily integrate with all these components.

The success of this release - in terms of achieving its integration goal - was strongly weighted by the collaboration with the teams of the partner projects, like SIPCapture, FreeSWITCH or CGRates. A collaboration in terms of ideas, brainstorming, solutions and of course, work. A collaboration that

Integration

the rest

Migration from 2.2.x to 4.0.0?