OpenSIPS 4.x, the next evolution step

As already mentioned, the 3.6 major release will end the 3.x family of OpenSIPS releases. They stretch over 7 years of work, 7 major releases, each with its own philosophy.

The 3.x legacy

The 3.x OpenSIPS family addressed a large spectrum of topics.

The most representative was the DevOps area (3.0 and 3.6) bringing awesome features like script reload, auto-scaling, script pre-processing, dynamic sockets, structured SDP and many other.

The external integration was also a topic widely address in many of the 3.x releases – SMPP, RabbitMQ, Kafka, Prometheus, LaunchDarkly, SQS , DynamoDB and Janus integration are just some examples here.

The 3.1 release was a huge step forward when comes to advanced call handling, addressing the need of Class 5 support. This translated into enhancements in API area (the Call API), in RTP area (media_exchange, DTMF) and SIP level (B2B, BLF, DFKS, Call Center) .

The clustering and cloud support were the hop topics for 3.2, boosting the ability of OpenSIPS to form geo-distributed, synchronized clusters.

The 3.3 release revived a IM area in OpenSIPS – the MSRP support was added, with MSRP gateways and APIs, all perfected with the Contact Center enhancement.

Advanced testing – conformity and performance – was the goal of 3.4 release. Easy to said, but testing a crucial aspect of software development and it should not be ever neglected – a by-product of this release was the SIPssert testing frame.

Probably one of the most challenging releases was the 3.5, targeting IMS – as a first stage, the CSCF components, together with its interfaces.
As results, this translated in work across several modules along with the addition of new specialized modules.

The 4.x aspirations

Each release brings new philosophies, new features and modules. But there are points in OpenSIPS evolution marked by revolutionary changes, typically low level, under-the-hood changes – there are changes with high impact in OpenSIPS, on all levels, from performance, SIP layer, up to feature level.

Such turning points usually dictates a starting of a new OpenSIPS family. We had the async and network rework defining the 2.x family; the clustering and scripting rework were shaping the 3.x family. So, what will define the 4.x ?

We have some items on the to-do list. And the plan is to take the challenge to address these items in the 4.x family:

• rework the internal dispatching of incoming traffic over the OpenSIPS processes, to move from the current static mapping (we have UDP processes responsible for a single UDP socket, other TCP processes only for TCP traffic) to a more flexible, auto-balancing approach – were traffic may be read by dedicated processes, but the handling is to be dispatched to a single pool of worker processes. This approach will take better advantage of all processes, avoiding strange situation where some processes are overloaded and others are idle.
• remove the lumps support ( when comes to SIP changes) in favor of realtime applied changes. Currently the changes over the SIP messages are just recorded and applied only when sending out the message. This has the drawback of not being able to see your own changes during processing a SIP message – and it is not about the script level, but also at the module level – a module is not able to see changes performed by other module. With the Structured SDP rework in 3.6, we experimented the realtime changes over the SDP (in favor of lumps) and results were great. The idea is to extrapolate this approach over the SIP headers too
• enhance script variable engine – once the script reload was added, the historical systemic issues popped up. More or less, the variable support was not designed with the idea of dropping and parsing new variables (like during the script reload) – and this operation of parsing variable specification does leak memory 😦 . Also there is plenty of space for improvements when comes to data types of the variables, of working with arrays or more structured data type.
• OpenSIPS SDK – we have the OpenSIPS calling API, but we want to explore the idea of exposing via an SDK (library) the full scripting capabilities – basically, form your own application, using the OpenSIPS SDK, you can do the routing, with a similar experience as the current configuration file. Just outsource the routing to another application via an API-based SDK (to be available in different languages)

Ideas are many, we just need to take them one by one. And again, we are not talking about the features and enhancements defining a major release – these are to be decided from release to release- , but we are talking about new set of genes to shape the new 4.x releases.