From openSIPS

Development: OpenSIPS 3.4 Planning

Development -> Planning -> OpenSIPS 3.4 Planning

OpenSIPS 3.4 philosophy

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 upcoming OpenSIPS 3.4 wants to address 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 is a long overdue task that definitely needs to be addressed.

Testing

Testing is important to maintain the health of the code, in terms of functionality as well as performance. In other words, testing is needed to be sure OpenSIPs works correctly and performs as fast as expected. For each type of test (performance and conformity) we want to have in place tools, methodologies and mechanisms to ensure a continuous and automatic process of testing.

Performance testing

The last performance tests were done quite a long time ago. OpenSIPS as base code and module has dramatically evolved since then, so a re-evaluation is mandatory. It is important to know where we are in terms of performance (the throughput in various scenarios) as well as to understand the limitations of OpenSIPS. Part of these tests, for code profiling, will be done in order to identify potential bottlenecks and to work them out, as we aim to optimize the slowest parts. Here we target building an Ansible based test bed that can be quickly deployed in cloud (or any VMs) for performing stress tests based on some pre-defined SIPP scenarios.

Conformity testing

There are dozens of functionalities (registration, authentication, call routing, accounting, dialog, b2b and others), complex functionalities, which often inter-operate -- they may depend on each other. So even the smallest changes or extensions in one part of the code may impact unrelated functionalities in unexpected ways. The validation of the code and the detection of possible regressions must be done via a continuous testing of OpenSIPS. The testing is to be done at SIP level, by running various SIP flows on OpenSIPS, as a black box, and observing its behavior and output. The intention here is to build a framework (Docker based) that will allow the creation of any new SIP scenarios. The scenarios will involve various entities, like SIP UAs, DBs, provisioning tools, etc. New such entities (as Docker images) may be added at any time, further down the line. Important, this testing frame will allow the testing of an OpenSIPS instance (1) either running as entity in the testing platform, (2) either running external to the testing platform.

MSRP

IM chat group

The current IMC module is oldish, supporting only Page Mode for IM and only an IRC-based way of functioning. A refurbish of this module in order to (1) support Session Mode IM (MSRP) as well, (2) to provide a more flexible and modern way of managing the chat rooms (not IRC based) and (3) to provide an API to allow the integration of IM with WEB services.

MSRP reporting

Add support for requesting MSRP reports when OpenSIPS is acting as MSRP UA.

End-2-end encryption

Evaluate (and implement) support for e2e encryption of the MSRP traffic

Instant Message Disposition Notification

Evaluate (and implement) support for RFC 5438 - Instant Message Disposition Notification - for the MSRP traffic (delivery / read reports, typing events)

IMS

The IMS topic was part of several OpenSIPS releases (mainly from the Diameter support perspective). We still have to address couple of points before truly saying that OpenSIPS is IMS capable, like the IPSec support, SIP Outbound support (RFC 5626) and other small/medium items. Also the plan is to start drafting basic OpenSIPS cfg samples for the SIP network entities (P-CSCF, I-CSCF, S-CSCF) in IMS.

The SIP Back-2-Back

After the major change in the B2B support, when the XML control logic was replaced with a script driven logic, several improvements/fixes are still due here:

• re-work the re-bridging sequence to avoid delayed ACK due to long ringing on the new entity to be bridged. Also a non-late-SDP alternative should be provided here
• re-work the logic of the initial bridging to allow easy (as B2B logic level) handling of failover (if callee does not answer) - currently this is not supported, if initial callee does not answer, the whole call dies.
• rework the correlation between the B2B entities and b2b logic, to avoid the keep searching entities based on string keys (optimization)
• rework the B2B entities support to more relay on a proper TM and Dialog support - right now there is a big consistence missing in that area.

Miscellaneous

Structured SDP manipulation

Instead of using regexp-based changes over the SDP, we envision a structured way of accessing and modifying the SDP payload, by using easy variables. All the changes will be visible on the spot. This will allow multiple changes over the SDP, from script or modules, while keeping a single, consistent data set. For example, if you change an "a" line in the SDP from script level, the change will be visible to RTPengine. Furthermore, the new SDP from RTPengine will be visible (and changeable) at script level.

Federated usrloc: add support for SQL “metadata” DB

Given that there are so many scalable and popular SQL solutions nowadays (Redis Cluster, Percona PXC, YugaByte, etc.), one idea is to add support for the federated usrloc cluster to work with them.

With the current solution (originally designed in 2018), you most often end up maintaining an additional NoSQL cluster just for storing user location metadata, which although seems nice from a separation (microservices) point of view, the load on this cluster is not that high and it could very well work with just an extra database in your SQL cluster dedicated to this purpose.

GitHub#2908

AVPops re-work

As most of the strictly AVP related functions are obsolete (already doable in different ways via core functions), the module is to be converted to an SQL ops module. Whatever AVP specific functionalities are still present in avpops (only), are to be migrated into OpenSIPS core.

Dialog

Similar to the message / branch flags, the dialog flags needs to support names too. Something important here is to extend the dialog variables to also support numerical values (currently supporting only strings).

Vote your Favorite Features!

We are undergoing an OpenSIPS 3.4 Feature Survey (due 18th January 2023), and we would like to gather opinions on the currently chosen feature set, as well as any additional ideas you may have. Your feedback will help us prioritize the work that will go into the upcoming 3.4 release. Thank you!

Poll Results

Many thanks to everyone who voted for this poll! Please find the poll results below -- regarding the additional feature suggestions we received, we will go through them and pick the most popular / interesting ones in a future announcement.

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