Login | Register


Development -> Planning -> OpenSIPS 3.2 Planning

OpenSIPS 3.2 philosophy

Deploying and running distributed SIP services in various clouds becomes more of a default approach in our days. For this reason, the OpenSIPS 3.2 upcoming release will focus on increasing OpenSIPS's ability to integrate with cloud specific services / backends and it will bring more OpenSIPS capabilities to build distributed (multi PoP/location/DC/zone) SIP services. After all the two concepts, of distributed architecture and in-cloud support, are going hand in hand - the biggest advantage of running in clouds is to possibility to organically scale and distribute.

Clustering or Distributed Support

Starting with version 2.4 OpenSIPS has solid support for clustering, which enables the design and implementation of the distributed SIP services with OpenSIPS. Nevertheless, the clustering chapter is a large one, that needs to continuously evolve under the pressure of the requirements/demands coming from the real-word situations. For the OpenSIPS 3.2 we are targeting work on the actual clustering engine in OpenSIPS, but also on adding clustering support for more modules

Clustering engine

The plan is to improve the clustering support (or the BIN protocol) in order to secure and increase the management of the cluster:

  • TLS support for BIN protocol, to create secure in-cluster communication even in situation where the public Internet has to be used (VPNs or private networks are not an option)
  • better control/management over the cluster topology by being able to restrict the dynamic joining of new nodes (yes, that's it, to "lock" down the topology of the cluster) or to be able to remove nodes from the cluster (yup, to kick a node out).

Distributed Call Center

For the Call Center (or call queuing) module we plan to add clustering support and data replication for the call queue - this is extremely important for achieving High-Availability. In the same time, we are looking to add support for distributed call-center - a geo-distributed single call queue which gets calls via different OpenSIPS instances and which distributed agents connected to different OpenSIPS instances.

Clustering more modules

There are several modules which may require clustering support in order to be used in distributed deployments. There are modules that has to share data between all the OpenSIPS nodes in order to achieve a global understanding over the clustered service. Such modules are:

  • Quality Routing - to share the statistics on the quality of the gateways
  • Fraud Detection - to share the collected information on the calling patterns
  • Pike - to share and aggregate the information on the flooding sources
  • Statistics - to provide new scripting statistics (like to monitor the performance of a trunk/destination/user) that can be shared across all the nodes
  • Dialog Info - the share the BLF date inside a cluster mainly for High-Availability purposes.

Multi-level presence subscription

For aggregating the presence state in a distributed system, a multi-level subscription setup may be envisioned. This means a local Presence Server (use a partition of users are subscribing to) may subscribe further to a central/master Presence Server. This will considerably reduce the SUBSCRIBE / NOTIFY traffic and also it will offload the NOTIFY'cation effort on the central Presence Server.

RTP stream re-anchoring

As in distributed system you definitely use several media/RTP relays, in same location for load-balancing purposes or in different locations for distribution/short-path purposes. In both cases there is a need to migrate/re-anchor an ongoing call to a different RTP relay. This may needed for failover reasons or re-balancing/offloading purposes. We are looking to add this re-anchoring support in OpenSIPS, without any extra requirement from the actual media rely, by using SIP re-INVITE to re-negotiate the SDPs. This approach will work for RTPproxy, RTPengine, Mediaproxy.

In-Cloud Integration

For the in-cloud distributed system, it is a huge advantage to be able to make usage of different services or functionalities provided by the cloud itself. This means more integration capabilities for OpenSIPS 3.2


Apache Kafka is an open-source distributed event streaming platform used for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. A new Kafka backend is considered for the Event Interface


MQTT is an OASIS standard messaging protocol for the Internet of Things (IoT). It is designed as an extremely lightweight publish/subscribe messaging transport that is ideal for connecting remote devices with a small code footprint and minimal network bandwidth. A new MQTT backend is considered for the Event Interface


Prometheus is an engine for crouching statistics. We consider building a native Prometheus connector in OpenSIPS for the Statistics Interface.

AWS DynamoDB

Add support for Dynamo noSQL DB, from Amazon, to improve the experience when comes to running OpenSIPS in AWS cloud.

AWS System Manager (SSM)

The AWS SSM may be used as a centralized secret manager for handling various credentials to be used by OpenSIPS. For example you can use SSM in order to dynamically change (across multiple OpenSIPS instances) the used DB credentials .

AWS CloudWatch, SQS, SNS

Support for pushing or receiving events from the AWS specific event broker. This will be a new backend for the Event Interface.


A beats plugin for Logstash or ElasticSearch. This will allow OpenSIPS to push data directly into ElasticSearch.

Secure RTPEngine (NG protocol)

A secure version of the protocol used to communicate with the RTPengine - this will allow the integration of OpenSIPS with RTPengine even across open/public Internet.

Asterisk Integration

Similar to FreeSWITCH integration, the goal is to make OpenSIPS query Asterisk for load information in realtime, in order to adjust the dispatching and load-balancing processes.


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.

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.

TLS support

Explore the options of using GNUtls, LIBREtls or wolfSSL as alternatives to OpenSSL which proved to be a quite disruptive lib, incompatible with the multi-processing model in OpenSIPS.

MI from script

Explore options to allow the possibility to invoke MI commands from the OpenSIPS script.


While right now we can trace SIP traffic (and logs) via HEP and to DB, a syslog backend may be envisioned for simple tracing needs/scenarios.

Vote your Favorite Features!

We are undergoing an OpenSIPS 3.2 Feature Survey (due 11th January 2021), 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.2 release. Thank you!

Poll Results

Many thanks to all of you 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 with their development status, so you can have a clear view over the 3.2 progress. Nevertheless, we strongly recommend you to check the Feature list of 3.2.

Feature CodeFeature NameScore (1-5)Implementation Status
Misc-3TLS Support4.42done
Cluster-1Clustering Engine4.41done
Misc-2Structured SDP manipulation4.31no-go
Cluster-3Clustering more modules4.20done
Cloud-8Secure RTPEngine (NG protocol)4.18invalid*
Misc-5Tracing to log4.13done
Misc-1Script driven B2B3.95done
Cluster-5RTP stream re-anchoring3.91done
Misc-4MI from script3.81done
Cloud-9Asterisk Integration3.79no-go
Cluster-2Distributed Call Center3.30no-go
Cloud-6AWS CloudWatch, SQS, SNS2.92no-go
Cluster-4Multi-level presence subscription2.81no-go
Cloud-4AWS DynamoDB2.75no-go
Cloud-5AWS System Manager (SSM)2.62no-go

* There is no secure way to communicate in RTPEngine - the NG protocol is the actual protocol we are using, and it is basically BSON over TCP.

Page last modified on May 27, 2021, at 11:49 AM