From openSIPS

Development: OpenSIPS 4.0 Planning

Development -> Planning -> OpenSIPS 4.0 Planning

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 is to address old limitations, deprecated designs or burning needs we accumulated across years. Concepts we had from day 1 (in SER at that time) are to be reworked; Also new concepts will be added, to align OpenSIPS with the challenges of the current days.

OpenSIPS 4.0 is all about re-vamping.

TCP 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 to be done within a single process (no TCP passing anymore) with multi-threading. Multiple threads are to do the reading and writing on the TCP cons. So the connections will be 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 will pass the messages to be written to this TCP process - it what is done right now for async write operations.
Advantages: the multi-threaded modules is much much lighter and faster in our days (comparing with 20 years ago). The overhead will be smaller. We can safely use libraries with multi-threading models (see below the openSSL rework).

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.
So this must change!!

StirShaken SSL rework

As the usage of the openSSL lib is quite limited, we plan to move the stirshaken module away from the openSSL support to a much lighter only for this module (like the BoringSSL lib). This will eliminate any negative impact of the openSSL twitches (needed by the SIP layer)

openSSL support rework

Thanks to the TCP rework and moving to a multi-threaded architecture (for TCP engine), there will be no need for the openSSL twitches (as openSSL natively supports multi-threading). This will solve a lot of problems when comes to using openSSL lib from different modules and processes.

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.

Versatility

Dynamic number of TM branches

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 - basically without having the maximum number of branches statically allocated into the transaction (as now), but to be able to dynamically allocate on-demand - for example, a transaction with 256 statically allocated branches consumes like 136KB memory....which is huge, considering the tens of thousands of transactions that can reside in memory at a given time.
The goal here is to allow a larger number of branches into a transaction, but without wasting memory (so with dynamic allocation)

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.

Monitoring

SIP message profiling

Or answering to the question "How was the SIP message handled, the steps and the time" - in a per-message manner, the profiling may be enabled. The profiling data will translate into a list of reports describing the execution of the the SIP message in OpenSIPS - time stamps, internal triggered APIs, executed script routes and functions, various relevant operations - each module may generate such relevant reports to be attached to the message. The profiling data may serve for pure profiling purposes or for troubleshooting both opensips performance or routing logic. The data may be collected via logs, via opensips-cli (runtime collecting) or via HTTP services (like Pyroscope )

Process/worker profiling

Or an realtime X-ray on OpenSIPS, to answer to the question What is my OpenSIPS doing, where is it stuck?? - in a per-process manner, the profiling will generate a list of reports 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 reports will cover events like the change of the processes state - idle (in IO reactor), running/executing or blocked into an I/O operation. Even more, when active, additional information like the nature of the processing will be attached - executing timer jobs, processing a SIP msg or running an async handler. The profiling data will be available via MI commands, either as detailed reports (for a fix time interval), or as aggregated statistics.

OpenTelemetry support

For the collected data, we already have support for OpenTelemetry, to push the profiling data to external observability tools/engines.

Integration

Integration and interoperability is a never ending challenge.

Proxy Protocol (HA proxy) support

Running OpenSIPS behind various NATs and firewalls raise legitimate questions about losing information about the originators of the TCP connections. In our-days security reality, where firewalls like Cloudflare are more and more used, we need a way to ensure proper access to the information about the real originator of the traffic (for IP based authentication for example).
PROXY protocol is a network protocol — developed and open-sourced by HAProxy Technologies — for preserving a client’s IP address when the client’s TCP connection passes through a proxy. Without such a mechanism, proxies loose this information because they act as a surrogate for the client, relaying messages to the server but replacing the client’s IP address with their own. This distorts the logs of upstream servers, as they incorrectly indicate that all traffic originated at the proxy.
OpenSIPS 4.0 is to support HAProxy on the TCP layer.

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.
The dialog module in OpenSIPS must take the job to act as a B2BUA for PRACK and UPDATES. For 1000rel, if on of the party does not support it, it will be OpenSIPS job to generate the PRACKs. For UPDATEs, if one of the parties does not support the method, OpenSIPS should try to convert to re-INVITE.
This will facilitate the interop between IMS-enabled system and IMS-ignorant (or older) systems.

WebSocket generic interface

WebSockets are gaining more and more traction when comes to defining interfaces between services. Most of AI services are using websockets based APIs. Or provisioning or control APIs are relying on websockets. See the Janus or Verto (FreeSWITCH) cases.
To avoid custom integration (and development) for each such case, the idea here is to define in OpenSIPS generic WebSocket connections - the interaction with the connection is to be done at script level - from script we send the date on the control channel; whatever is read from the control channel is to be available at script level. At script level you can use any tool/method to decode/unpack and interpret the data and furthermore, to integrate with any other SIP or non-SIP services OpenSIPS has to offer.
Of course, there is the challenge of the media/RTP channel here (where applicable) and how to deal with it.

Work Status

We try to update the list items with their development status, so you can have a clear view over the 4.0 progress. Nevertheless, we strongly recommend you to check the Feature list of 4.0.