From openSIPS

Development: OpenSIPS 3.1 Planning

Development -> Planning -> OpenSIPS 3.1 Planning

OpenSIPS 3.1 philosophy

Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 3.1 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 3.1 release will address the Class 5 specific calling features and how to control such calling features via APIs.

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 media bridging) 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 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.

Call media bridging

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. Details about implementation of this feature can be found in the Media Bridging page.

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

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

Extended BLF support

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.

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

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 3.1, 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 geo-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 3.1. 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

Dealing with Robocalling and CLI spoofing becomes a must when building advanced calling solutions. The support for STIR/SHAKEN will be part of OpenSIPS 3.1, 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).

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 3.1:

• 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

Vote your Favorite Features!

We are undergoing an OpenSIPS 3.1 Feature Survey (due 13th January 2020), 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.1 release. Thank you!

Poll Results

Thank you to everyone who voted! 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 with their development status, so you can have a clear view over the 3.0 progress. Nevertheless, we strongly recommend you to check the Feature list of 3.1.