Development

Development.Opensips-3-2-Planning History

Hide minor edits - Show changes to output

May 27, 2021, at 11:49 AM by 109.99.227.30 -
Changed line 135 from:
|| Cluster-5 || RTP stream re-anchoring || 3.91 || %green%done%%% ||
to:
|| Cluster-5 || RTP stream re-anchoring || 3.91 || %green%done%% ||
May 27, 2021, at 11:49 AM by 109.99.227.30 -
Changed line 128 from:
|| Misc-3 || TLS Support || 4.42 || %orange%pending%% ||
to:
|| Misc-3 || TLS Support || 4.42 || %green%done%% ||
Changed lines 130-131 from:
|| Misc-2 || Structured SDP manipulation || 4.31 || %orange%pending%% ||
|| Cluster-3 || Clustering more modules || 4.20 || %orange%pending%% ||
to:
|| Misc-2 || Structured SDP manipulation || 4.31 || %red%no-go%% ||
|| Cluster-3 || Clustering more modules || 4.20 || %green%done%% ||
Changed lines 135-137 from:
|| Cluster-5 || RTP stream re-anchoring || 3.91 || %orange%pending%% ||
|| Misc-4 || MI from script || 3.81 || %orange%pending%% ||
|| Cloud-9 || Asterisk Integration || 3.79 || %orange%pending%% ||
to:
|| Cluster-5 || RTP stream re-anchoring || 3.91 || %green%done%%% ||
|| Misc-4 || MI from script || 3.81 || %green%done%% ||
|| Cloud-9 || Asterisk Integration || 3.79 || %red%no-go%% ||
Changed lines 139-143 from:
|| Cluster-2 || Distributed Call Center || 3.30 || %orange%pending%% ||
|| Cloud-7 || ElasticSearch || 3.18 || %orange%pending%% ||
|| Cloud-6 || AWS CloudWatch, SQS, SNS || 2.92 || %orange%pending%% ||
|| Cloud-2 || MQTT || 2.84 || %orange%pending%% ||
|| Cluster-4 || Multi-level presence subscription || 2.81 || %orange%pending%% ||
to:
|| Cluster-2 || Distributed Call Center || 3.30 || %red%no-go%% ||
|| Cloud-7 || ElasticSearch || 3.18 || %red%no-go%% ||
|| Cloud-6 || AWS CloudWatch, SQS, SNS || 2.92 || %red%no-go%% ||
|| Cloud-2 || MQTT || 2.84 || %red%no-go%% ||
|| Cluster-4 || Multi-level presence subscription || 2.81 || %red%no-go%% ||
Changed lines 145-146 from:
|| Cloud-4 || AWS DynamoDB || 2.75 || %orange%pending%% ||
|| Cloud-5 || AWS System Manager (SSM) || 2.62 || %orange%pending%% ||
to:
|| Cloud-4 || AWS DynamoDB || 2.75 || %red%no-go%% ||
|| Cloud-5 || AWS System Manager (SSM) || 2.62 || %red%no-go%% ||
May 24, 2021, at 12:42 PM by razvancrainea -
Changed line 133 from:
|| Misc-5 || Tracing to log || 4.13 || %orange%pending%% ||
to:
|| Misc-5 || Tracing to log || 4.13 || %green%done%% ||
May 21, 2021, at 12:10 PM by razvancrainea -
Changed lines 80-82 from:
%red%Update%% 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.

to:

Changed line 132 from:
|| Cloud-8 || Secure RTPEngine (NG protocol) || 4.18 || %red%invalid%% ||
to:
|| Cloud-8 || Secure RTPEngine (NG protocol) || 4.18 || %red%invalid%%'^*^' ||
Added lines 148-149:

'^*^' 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.
May 21, 2021, at 12:09 PM by razvancrainea -
Added line 80:
%red%Update%% 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.
May 21, 2021, at 12:07 PM by razvancrainea -
Changed line 132 from:
|| Cloud-8 || Secure RTPEngine (NG protocol) || 4.18 || %orange%pending%% ||
to:
|| Cloud-8 || Secure RTPEngine (NG protocol) || 4.18 || %red%invalid%% ||
April 23, 2021, at 05:43 PM by rvlad_patrascu -
Changed line 129 from:
|| Cluster-1 || Clustering Engine || 4.41 || %orange%pending%% ||
to:
|| Cluster-1 || Clustering Engine || 4.41 || %green%done%% ||
March 04, 2021, at 12:02 PM by rvlad_patrascu -
Changed line 144 from:
|| Cloud-1 || Kafka || 2.78 || %orange%pending%% ||
to:
|| Cloud-1 || Kafka || 2.78 || %green%done%% ||
February 24, 2021, at 04:45 PM by razvancrainea -
Changed line 138 from:
|| Cloud-3 || Prometheus || 3.78 || %orange%pending%% ||
to:
|| Cloud-3 || Prometheus || 3.78 || %green%done%% ||
January 12, 2021, at 05:35 PM by 86.121.186.239 -
Changed line 134 from:
|| Misc-1 || Script driven B2B || 3.95 || %orange%pending%% ||
to:
|| Misc-1 || Script driven B2B || 3.95 || %green%done%% ||
January 12, 2021, at 05:33 PM by 86.121.186.239 -
Added lines 116-149:


[[#poll-results]]
!!! 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 [[https://www.opensips.org/About/Version-3-2-0|Feature list]] of 3.2.

[[<<]]
||border=1
|| '''Feature Code''' || '''Feature Name''' || '''Score (1-5)''' || '''Implementation Status''' ||
|| Misc-3 || TLS Support || 4.42 || %orange%pending%% ||
|| Cluster-1 || Clustering Engine || 4.41 || %orange%pending%% ||
|| Misc-2 || Structured SDP manipulation || 4.31 || %orange%pending%% ||
|| Cluster-3 || Clustering more modules || 4.20 || %orange%pending%% ||
|| Cloud-8 || Secure RTPEngine (NG protocol) || 4.18 || %orange%pending%% ||
|| Misc-5 || Tracing to log || 4.13 || %orange%pending%% ||
|| Misc-1 || Script driven B2B || 3.95 || %orange%pending%% ||
|| Cluster-5 || RTP stream re-anchoring || 3.91 || %orange%pending%% ||
|| Misc-4 || MI from script || 3.81 || %orange%pending%% ||
|| Cloud-9 || Asterisk Integration || 3.79 || %orange%pending%% ||
|| Cloud-3 || Prometheus || 3.78 || %orange%pending%% ||
|| Cluster-2 || Distributed Call Center || 3.30 || %orange%pending%% ||
|| Cloud-7 || ElasticSearch || 3.18 || %orange%pending%% ||
|| Cloud-6 || AWS CloudWatch, SQS, SNS || 2.92 || %orange%pending%% ||
|| Cloud-2 || MQTT || 2.84 || %orange%pending%% ||
|| Cluster-4 || Multi-level presence subscription || 2.81 || %orange%pending%% ||
|| Cloud-1 || Kafka || 2.78 || %orange%pending%% ||
|| Cloud-4 || AWS DynamoDB || 2.75 || %orange%pending%% ||
|| Cloud-5 || AWS System Manager (SSM) || 2.62 || %orange%pending%% ||
||

[[<<]]
December 23, 2020, at 03:54 PM by 109.99.227.30 -
Changed line 114 from:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSde95VK-9v29HrXVY6CyNrtjNZsEuBK1eS7MkBMEm-GF83dNQ/viewform|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!
to:
We are undergoing an [[http://bit.ly/2WDmAlV|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!
December 23, 2020, at 03:38 PM by 109.99.227.30 -
Changed lines 9-11 from:
%rframe width=300px % https://blogopensips.files.wordpress.com/2019/12/opensips-3.2-crafting.jpg
Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 3.2 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.2 release will address the Class 5 specific calling features and how to control such calling features via APIs.
to:
%rframe width=300px % https://blogopensips.files.wordpress.com/2020/12/opensips-3.2-cloud.jpg
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.
\\
\\
\\
Changed lines 17-45 from:
[[#class5]]
!!! 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 [[Development.Media-Bridging-Feature|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)
to:
[[#distributed]]
!!! 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.

Changed lines 50-53 from:
[[#b2b]]
!!! Back-to-back support
The existing B2B implementation in OpenSIPS has some limitations, so we are looking to overcome via some major rework here.
to:
[[#integration]]
!!! 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

!!!! Kafka
[[https://kafka.apache.org/|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
[[https://mqtt.org/|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
[[https://prometheus.io/|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 [[https://aws.amazon.com/dynamodb/| 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.

!!!! ElasticSearch
A beats plugin for Logstash or [[https://www.elastic.co/|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.

----

!!! Miscellaneous

Changed lines 93-98 from:
!!!! 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).
to:

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


!!!! Tracing
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.
Changed lines 110-147 from:
[[#callcenter]]
!!! Call Center
For 3.2, 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.

----

[[#DFKS]]
!!! Device Feature Key Synchronization (DFKS)
[[http://community.polycom.com/polycom/attachments/polycom/VoIP/2234/1/DeviceFeatureKeySynchronizationFD.pdf|DFKS support]] is planned for OpenSIPS 3.2. 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]]
!!! STIR/SHAKEN
Dealing with Robocalling and CLI spoofing becomes a must when building advanced calling solutions. The [[https://www.slideshare.net/slideshow/embed_code/key/Ly9vOqcKuML5Nq|support for STIR/SHAKEN]] will be part of OpenSIPS 3.2, 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).

----

[[#PN]]
!!! Push Notification (RFC8599)
The existing PN support will be improved and aligned to the requirements as per newly adopted [[https://tools.ietf.org/html/rfc8599|RFC 8599]]. Besides the notification itself, we need to address some particularities in contact registration, derived from privacy concerns or device identification concerns.

----

[[#DB]]
!!! noSQL adds-on
The DB layer needs a constant attention, so here is the plan for 3.2:
* add support for [[https://aws.amazon.com/dynamodb/| Dynamo]] noSQL DB, from Amazon, to improve the experience when comes to running OpenSIPS in AWS cloud.
* support for raw queries for Cassandra

----



to:
Changed lines 114-146 from:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSde95VK-9v29HrXVY6CyNrtjNZsEuBK1eS7MkBMEm-GF83dNQ/viewform|OpenSIPS 3.2 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.2 release. Thank you!


[[#poll-results]]
!!! 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 [[https://www.opensips.org/About/Version-3-2-0|Feature list]] of 3.2.

[[<<]]
||border=1
|| '''Feature Code''' || '''Feature Name''' || '''Score (1-5)''' || '''Implementation Status''' ||
|| Class5-7 || Dialog module enhancements || 4.38 || %green%completed%% ||
|| Class5-1 || Calling API || 4.31 || %orange%ongoing%% ||
|| B2B-2 || Clustering support || 4.27 || %green%completed%% ||
|| Class5-3 || Per-call hooks || 4.02 || %orange%ongoing%% ||
|| Class5-5 || DTMF support || 3.96 || %green%completed%% ||
|| AF-3 || Push Notification (RFC8599) || 3.93 || %green%completed%% ||
|| B2B-1 || Script driven B2B || 3.84 || %red%no-go%% ||
|| AF-2 || STIR/SHAKEN || 3.80 || %green%completed%% ||
|| Class5-4 || SDP topology hiding || 3.76 || %red%no-go%% ||
|| Class5-2 || Media Exchange || 3.75 || %green%completed%% ||
|| CC-2 || Geo-distributed Call-Center || 3.58 || %red%no-go%% ||
|| B2B-3 || B2B Context || 3.52 || %green%completed%% ||
|| Class5-6 || Extended BLF support || 3.38 || %green%completed%% ||
|| CC-1 || Call Center clustering || 3.36 || %red%no-go%% ||
|| AF-1 || Device Feature Key Synchronization (DFKS) || 3.31 || %green%completed%% ||
|| DB-2 || Raw queries for Cassandra || 3.00 || %red%no-go%% ||
|| DB-1 || DynamoDB support || 2.64 || %red%no-go%% ||
||

[[<<]]
to:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSde95VK-9v29HrXVY6CyNrtjNZsEuBK1eS7MkBMEm-GF83dNQ/viewform|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!
May 25, 2020, at 02:33 PM by 109.99.227.30 -
Changed line 120 from:
|| B2B-1 || Script driven B2B || 3.84 || pending ||
to:
|| B2B-1 || Script driven B2B || 3.84 || %red%no-go%% ||
Changed line 122 from:
|| Class5-4 || SDP topology hiding || 3.76 || pending ||
to:
|| Class5-4 || SDP topology hiding || 3.76 || %red%no-go%% ||
May 14, 2020, at 10:30 AM by 109.98.32.84 -
Changed lines 10-12 from:
Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 3.2 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.2 release will address the Class 5 specific calling features and how to control such calling features via APIs.

As usual, all the OpenSIPS major releases are in depth presented during the '''OpenSIPS Summit''' yearly events. So, the 3.2 release is the star of [[http://www.opensips.org/events/Summit-2020Amsterdam/|OpenSIPS Summit in Amsterdam, May 2020]].
to:
Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 3.2 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.2 release will address the Class 5 specific calling features and how to control such calling features via APIs.
May 14, 2020, at 10:30 AM by 109.98.32.84 -
Changed line 119 from:
|| Class5-3 || Per-call hooks || 4.02 || p%orange%ongoing%% ||
to:
|| Class5-3 || Per-call hooks || 4.02 || %orange%ongoing%% ||
May 14, 2020, at 10:29 AM by 109.98.32.84 -
Changed line 119 from:
|| Class5-3 || Per-call hooks || 4.02 || pending ||
to:
|| Class5-3 || Per-call hooks || 4.02 || p%orange%ongoing%% ||
Changed line 127 from:
|| B2B-3 || B2B Context || 3.52 || %orange%ongoing%% ||
to:
|| B2B-3 || B2B Context || 3.52 || %green%completed%% ||
May 07, 2020, at 10:11 AM by liviu -
Changed line 121 from:
|| AF-3 || Push Notification (RFC8599) || 3.93 || %orange%ongoing%% ||
to:
|| AF-3 || Push Notification (RFC8599) || 3.93 || %green%completed%% ||
May 05, 2020, at 01:15 PM by 109.99.227.30 -
Changed line 131 from:
|| DB-2 || Raw queries for Cassandra || 3.00 || pending ||
to:
|| DB-2 || Raw queries for Cassandra || 3.00 || %red%no-go%% ||
May 05, 2020, at 01:15 PM by 109.99.227.30 -
Changed lines 116-118 from:
|| Class5-7 || Dialog module enhancements || 4.38 || pending ||
|| Class5-1 || Calling API || 4.31 || pending ||
|| B2B-2 || Clustering support || 4.27 || ongoing ||
to:
|| Class5-7 || Dialog module enhancements || 4.38 || %green%completed%% ||
|| Class5-1 || Calling API || 4.31 || %orange%ongoing%% ||
|| B2B-2 || Clustering support || 4.27 || %green%completed%% ||
Changed lines 120-121 from:
|| Class5-5 || DTMF support || 3.96 || done ||
|| AF-3 || Push Notification (RFC8599) || 3.93 || ongoing ||
to:
|| Class5-5 || DTMF support || 3.96 || %green%completed%% ||
|| AF-3 || Push Notification (RFC8599) || 3.93 || %orange%ongoing%% ||
Changed line 123 from:
|| AF-2 || STIR/SHAKEN || 3.80 || done ||
to:
|| AF-2 || STIR/SHAKEN || 3.80 || %green%completed%% ||
Changed lines 125-130 from:
|| Class5-2 || Media Exchange || 3.75 || done ||
|| CC-2 || Geo-distributed Call-Center || 3.58 || pending ||
|| B2B-3 || B2B Context || 3.52 || pending ||
|| Class5-6 || Extended BLF support || 3.38 || pending ||
|| CC-1 || Call Center clustering || 3.36 || pending ||
|| AF-1 || Device Feature Key Synchronization (DFKS) || 3.31 || done ||
to:
|| Class5-2 || Media Exchange || 3.75 || %green%completed%% ||
|| CC-2 || Geo-distributed Call-Center || 3.58 || %red%no-go%% ||
|| B2B-3 || B2B Context || 3.52 || %orange%ongoing%% ||
|| Class5-6 || Extended BLF support || 3.38 || %green%completed%% ||
|| CC-1 || Call Center clustering || 3.36 || %red%no-go%% ||
|| AF-1 || Device Feature Key Synchronization (DFKS) || 3.31 || %green%completed%% ||
Changed line 132 from:
|| DB-1 || DynamoDB support || 2.64 || pending ||
to:
|| DB-1 || DynamoDB support || 2.64 || %red%no-go%% ||
March 25, 2020, at 03:14 PM by razvancrainea -
Changed line 121 from:
|| AF-3 || Push Notification (RFC8599) || 3.93 || ongping ||
to:
|| AF-3 || Push Notification (RFC8599) || 3.93 || ongoing ||
March 25, 2020, at 03:14 PM by razvancrainea -
Changed lines 120-121 from:
|| Class5-5 || DTMF support || 3.96 || ongoing ||
|| AF-3 || Push Notification (RFC8599) || 3.93 || pending ||
to:
|| Class5-5 || DTMF support || 3.96 || done ||
|| AF-3 || Push Notification (RFC8599) || 3.93 || ongping ||
Changed line 125 from:
|| Class5-2 || Media Exchange || 3.75 || ongoing ||
to:
|| Class5-2 || Media Exchange || 3.75 || done ||
March 10, 2020, at 12:02 PM by razvancrainea -
Changed line 120 from:
|| Class5-5 || DTMF support || 3.96 || pending ||
to:
|| Class5-5 || DTMF support || 3.96 || ongoing ||
March 10, 2020, at 11:42 AM by razvancrainea -
Changed line 118 from:
|| B2B-2 || Clustering support || 4.27 || pending ||
to:
|| B2B-2 || Clustering support || 4.27 || ongoing ||
March 10, 2020, at 11:34 AM by razvancrainea -
Changed line 125 from:
|| Class5-2 || Media Bridging || 3.75 || ongoing ||
to:
|| Class5-2 || Media Exchange || 3.75 || ongoing ||
March 10, 2020, at 11:33 AM by razvancrainea -
Changed line 130 from:
|| AF-1 || Device Feature Key Synchronization (DFKS) || 3.31 || pending ||
to:
|| AF-1 || Device Feature Key Synchronization (DFKS) || 3.31 || done ||
February 06, 2020, at 12:53 PM by razvancrainea -
Changed lines 19-20 from:
Without actually using a Back2Back model, but simply operating with calls (dialogs, UACs or UASs), many complex class 5 calling (and call mixing) scenarios may be scripted.
to:
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.
Changed lines 24-25 from:
!!!! Call mixing
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.
to:
!!!! 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 [[Development.Media-Bridging-Feature|Media Bridging]] page.
February 06, 2020, at 12:51 PM by razvancrainea -
Changed line 123 from:
|| AF-2 || STIR/SHAKEN || 3.80 || pending ||
to:
|| AF-2 || STIR/SHAKEN || 3.80 || done ||
February 06, 2020, at 12:51 PM by razvancrainea -
Changed line 125 from:
|| Class5-2 || Call mixing || 3.75 || pending ||
to:
|| Class5-2 || Media Bridging || 3.75 || ongoing ||
January 14, 2020, at 06:33 PM by razvancrainea -
Added lines 106-135:
[[#poll-results]]
!!! 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 [[https://www.opensips.org/About/Version-3-2-0|Feature list]] of 3.2.

[[<<]]
||border=1
|| '''Feature Code''' || '''Feature Name''' || '''Score (1-5)''' || '''Implementation Status''' ||
|| Class5-7 || Dialog module enhancements || 4.38 || pending ||
|| Class5-1 || Calling API || 4.31 || pending ||
|| B2B-2 || Clustering support || 4.27 || pending ||
|| Class5-3 || Per-call hooks || 4.02 || pending ||
|| Class5-5 || DTMF support || 3.96 || pending ||
|| AF-3 || Push Notification (RFC8599) || 3.93 || pending ||
|| B2B-1 || Script driven B2B || 3.84 || pending ||
|| AF-2 || STIR/SHAKEN || 3.80 || pending ||
|| Class5-4 || SDP topology hiding || 3.76 || pending ||
|| Class5-2 || Call mixing || 3.75 || pending ||
|| CC-2 || Geo-distributed Call-Center || 3.58 || pending ||
|| B2B-3 || B2B Context || 3.52 || pending ||
|| Class5-6 || Extended BLF support || 3.38 || pending ||
|| CC-1 || Call Center clustering || 3.36 || pending ||
|| AF-1 || Device Feature Key Synchronization (DFKS) || 3.31 || pending ||
|| DB-2 || Raw queries for Cassandra || 3.00 || pending ||
|| DB-1 || DynamoDB support || 2.64 || pending ||
||

[[<<]]
December 19, 2019, at 07:50 PM by 109.99.227.30 -
Changed line 103 from:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSeFZ4KYa81LHO7xYyi1GfLklQK4IomXQNdfeu4KqYaT5peHLQ/viewform|OpenSIPS 3.2 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.2 release. Thank you!
to:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSde95VK-9v29HrXVY6CyNrtjNZsEuBK1eS7MkBMEm-GF83dNQ/viewform|OpenSIPS 3.2 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.2 release. Thank you!
December 19, 2019, at 07:39 PM by 109.99.227.30 -
Changed lines 9-15 from:
%rframe width=300px % https://blogopensips.files.wordpress.com/2018/12/opensips-3.0-icon.png
For the upcoming OpenSIPS 3.0 release (and 3.x family) the main focus is on the '''devops''' concept. This translates into introducing and enhancing in OpenSIPS features / capabilities that (1) will increase the easiness when comes the writing / developing OpenSIPS scripts and (2) simplify the operational activities when comes to running and managing OpenSIPS.


This OpenSIPS 3.0 release is the star of [[http://www.opensips.org/events/Summit-2019Amsterdam/ | OpenSIPS Summit in Amsterdam, April-May 2019 ]] - beside presentations and workshops around the new cool things in this version, OpenSIPS 3.0 will also be the subject of several interactive demos on its new capabilities.

to:
%rframe width=300px % https://blogopensips.files.wordpress.com/2019/12/opensips-3.2-crafting.jpg
Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 3.2 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.2 release will address the Class 5 specific calling features and how to control such calling features via APIs.

As usual, all the OpenSIPS major releases are in depth presented during the '''OpenSIPS Summit''' yearly events. So, the 3.2 release is the star of [[http://www.opensips.org/events/Summit-2020Amsterdam/|OpenSIPS Summit in Amsterdam, May 2020]].
Changed lines 16-27 from:
[[#development]]
!!! Script Development aspects

!!!! Generic Preprocessor Support

This feature adds full built-in pre-processing support for the OpenSIPS script. OpenSIPS 3.0 integrates various existing pre-processors within OpenSIPS. This simplify the scripting itself, the script portability across multiple servers and not to mention the entire deployment process of more complex platforms (where OpenSIPS is just a part of it). Even more, you will be able to use your preferred pre-processor and align OpenSIPS with the rest of your system (M4, Jinja, Embedded Ruby or others).\\
Read a full description of this feature [[https://blog.opensips.org/2019/03/05/generic-preprocessor-support-in-opensips-3-0/|here]].


!!!! Module Functions Now Benefit From a New Parameter Interface
As a response to frequent mailing list complaints of wildly varying behaviors across different module functions (e.g. some accept integers/strings as inputs while others accept both integers/strings or variables holding such values), we've introduced an abstract layer which handles the parameter passing task for all module functions, effectively making all of them more powerful by globally allowing flexible input. An added benefit is that new OpenSIPS modules are now even faster to develop. See the new function calling conventions [[https://www.opensips.org/Documentation/Script-Syntax-3-0#function-calling-conventions|here]].
to:
[[#class5]]
!!! 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 call mixing) 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 mixing
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.

!!!! 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)
Changed lines 46-79 from:
[[#operational]]
!!! Operational aspects

!!!! Routing Script Re-load

OpenSIPS 3.0 exposes the valuable ability of reloading the routes (not the module configuration) during runtime, with zero penalties and with zero loses as traffic.
See the documentation of the [[https://www.opensips.org/Documentation/Interface-CoreMI-3-0#toc8|MI "reload_routes" function]].

!!!! Processes Auto-Scaling Support

This is the ability of OpenSIPS to scale up and down the number of processes at runtime. Basically OpenSIPS is able to automatically scale up (by forking new processes) according to the volume of traffic, or to scale down (terminating some worker processes) if the internal load is low. This means you do not have to worry if your estimation on the number for worker processes is correct or not (will my OpenSIPS hold to the traffic??) or to worry about planning restarts during the night (to manually resize the number of processes).\\
Read a full description of this feature [[https://blog.opensips.org/2019/02/25/auto-process-scaling-a-cure-for-load-and-resources-concerns/|here]].

!!!! New OpenSIPS CLI (Command Line Interface) tool

Starting with OpenSIPS 3.0, the old ''opensipsctl'' tool becomes deprecated (as functionality and as software) and it is replaced by the new ''opensips-cli'' - a powerful Python3 application that allows you to interact in a smart way with OpenSIPS, to invoke advanced tools such as [[https://github.com/OpenSIPS/opensips-cli/blob/master/docs/modules/diagnose.md|diagnose]] or [[https://github.com/OpenSIPS/opensips-cli/blob/master/docs/modules/tracer.md|tracer]], as well as to perform DB provisioning.
Read a full description of ''opensips-cli'' [[https://blog.opensips.org/2019/03/13/new-opensips-cli-tool-for-the-new-management-interface-in-opensips-3-0/|here]].

!!!! Selectable Memory Allocator Support

This feature allows the internal memory manager to be selected at startup time. In OpenSIPS 3.0, the memory manager selection becomes a startup option, via command line arguments, allowing you to change it without any need to recompile or redeploy.
Read a full description of this feature [[https://blog.opensips.org/2019/03/21/containing-memory-related-issues-in-an-easy-way-with-opensips-3-0/|here]].

!!!! Internal Memory Persistence during Restart

As there are several modules caching (in OpenSIPS internal memory, not in external no-sql cachers) large chunks of data, like Dynamic Routing, Dialplan, Dispatcher or Permissions, OpenSIPS 3.0 is able to avoid the data loading and caching penalty during a restart - this segments of the internal memory do "survive" during the restart. This dramatically reduces the time to restart of the entire service. \\
Read a full description of this feature [[https://blog.opensips.org/2019/04/04/no-downtime-for-opensips-3-0-restarts/|here]].

!!!! Unified Sharing Tags for Clustering

In 2.4, each module (with clustering support) is managing its own sharing tags completely isolated from other modules - this make the operating OpenSIPS a bit difficult sometime, as for a single switch from active to backup, you need to individually inform and change the tags in several modules, via several MI commands. In OpenSIPS 3.0 we have now the sharing tags managed by clusterer module itself and shared between multiple modules. So with a single MI command, changing a single sharing tag, you can control all the cluster-aware modules (like dialog timeouts, nathelper pinging, dispatcher pinging, etc)
Read a full description of this feature [[https://blog.opensips.org/2019/03/07/achieving-service-redundancy-in-two-steps-with-unified-clustering-in-opensips-3-0/|here]].

to:

[[#b2b]]
!!! 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).
Changed lines 62-75 from:
[[#integration]]
!!! Integration aspects

!!!! MI Interaction Standardization
An extensive rework of the Management Interface in an attempt to standardize and speed up development of external applications which need to interact with OpenSIPS. The custom, JSON-based HTTP calls of OpenSIPS 2.X are now replaced with the JSON-RPC version 2 standard. The custom, line-oriented syntax was completely dropped. XMLRPC and mi_html (former mi_http) were kept backwards-compatible. Read a detailed description of the new interactions [[https://www.opensips.org/Documentation/Interface-MI-3-0#protocols|here]]

!!!! SMPP support

OpenSIPS 3.0 provides a [[https://opensips.org/html/docs/modules/3.0.x/proto_smpp.html|new SMPP module]] that allows you to do bidirectional gatewaying between SIP and SMPP traffic - this is a powerful but flexible way to integrate with most of the SMS providers / gateways.
Read a full description of this feature [[https://blog.opensips.org/2019/01/24/gateway-between-sip-and-smpp-messages/|here]].

!!!! RabbitMQ Consumer support

A new [[https://opensips.org/html/docs/modules/3.0.x/rabbitmq_consumer.html|RabbitMQ consumer module]] which manages connections with one or more brokers, subscribes for events and propagates them at OpenSIPS script level via the event interface.
to:
[[#callcenter]]
!!! Call Center
For 3.2, 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.

----

[[#DFKS]]
!!! Device Feature Key Synchronization (DFKS)
[[http://community.polycom.com/polycom/attachments/polycom/VoIP/2234/1/DeviceFeatureKeySynchronizationFD.pdf|DFKS support]] is planned for OpenSIPS 3.2. 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]]
!!! STIR/SHAKEN
Dealing with Robocalling and CLI spoofing becomes a must when building advanced calling solutions. The [[https://www.slideshare.net/slideshow/embed_code/key/Ly9vOqcKuML5Nq|support for STIR/SHAKEN]] will be part of OpenSIPS 3.2, 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).

----

[[#PN]]
!!! Push Notification (RFC8599)
The existing PN support will be improved and aligned to the requirements as per newly adopted [[https://tools.ietf.org/html/rfc8599|RFC 8599]]. Besides the notification itself, we need to address some particularities in contact registration, derived from privacy concerns or device identification concerns.

----

[[#DB]]
!!! noSQL adds-on
The DB layer needs a constant attention, so here is the plan for 3.2:
* add support for [[https://aws.amazon.com/dynamodb/| Dynamo]] noSQL DB, from Amazon, to improve the experience when comes to running OpenSIPS in AWS cloud.
* support for raw queries for Cassandra

----
December 19, 2019, at 07:37 PM by 109.99.227.30 -
Changed lines 9-13 from:
%rframe width=300px % https://blogopensips.files.wordpress.com/2018/12/opensips-3.2-icon.png
For the upcoming OpenSIPS 3.2 release (and 3.x family) the main focus is on the '''devops''' concept. This translates into introducing and enhancing in OpenSIPS features / capabilities that (1) will increase the easiness when comes the writing / developing OpenSIPS scripts and (2) simplify the operational activities when comes to running and managing OpenSIPS.

For the OpenSIPS 3.2 release, the following areas of development are considered:
to:
%rframe width=300px % https://blogopensips.files.wordpress.com/2018/12/opensips-3.0-icon.png
For the upcoming OpenSIPS 3.0 release (and 3.x family) the main focus is on the '''devops''' concept. This translates into introducing and enhancing in OpenSIPS features / capabilities that (1) will increase the easiness when comes the writing / developing OpenSIPS scripts and (2) simplify the operational activities when comes to running and managing OpenSIPS.


This OpenSIPS 3.0 release is the star of [[http://www.opensips.org/events/Summit-2019Amsterdam/ | OpenSIPS Summit in Amsterdam, April-May 2019 ]] - beside presentations and workshops around the new cool things in this version, OpenSIPS 3.0 will also be the subject of several interactive demos on its new capabilities.


----
Changed lines 21-36 from:
This is about improving the experience of the OpenSIPS script writer (developer), by enhancing and simplifying the OpenSIPS script:

* '''full pre-processing support''' - add full built-in pre-processing support for the OpenSIPS script. [[https://www.opensips.org/Development/Design-Opensips-Script-Preprocessing|The plan]] is to avoid "inventing" and "implementing" our own pre-processor, but to be able to integrate various existing pre-processors within OpenSIPS. This will simplify the scripting itself, the script portability across multiple servers and not to mention the entire deployment process of more complex platforms (where OpenSIPS is just a part of it). Even more, you will be able to use your preferred pre-processor and align OpenSIPS with the rest of your system (M4, Jinja, Embedded Ruby or others)

* '''script format changing''' - re-structure how the modules are loaded and their parameters defined in the script (as syntax). Even if from functionality or capabilities perspective nothing will changed, [[https://opensips.org/Development/Design-Opensips-Script-Rework|the new format]] will make the OpenSIPS script much easier to structure, so to automate the script building and deployment. Not to mention that the new format will be much cleaner and easier to follow by the script developers.

* '''full variable support''' - any kind of variables will be usable in the parameters of any script function. Extend the script interpreter, so the variable evaluations and the value validation will be transparently done by the interpreter for all the script function. This will increase the script flexibility as the variable usage will become more powerful.

* '''better naming for variables''' - expand the name of the existing variables from the short cryptic ones (like $rU , $Ri) to something (1) easier to understand (self explanatory) and (2) to indicate the scope of the variable, like, $msg.ruri, $msg.flags() or $msg.src_ip

* '''starting route per listener''' - instead of having a single 'route{}' to handle all the incoming requests, you can define different routes to be used for request received via different interfaces. This will simplify the script logic as you can to complete separation of traffic received on different interfaces, like having trigger different route for traffic received on the private interface and different route for traffic received on a public interface.

* '''standardize the format of complex parameters''' - there are many module parameters with a really complex format for their values, like the parameters describing the [[http://www.opensips.org/html/docs/modules/2.4.x/sql_cacher.html#param_cache_table|sql caching]] or the [[http://www.opensips.org/html/docs/modules/2.4.x/dialplan.html#param_partition|dialplan partitions]]. Right now each has its own way of packing/encoding the data, its own particularities when comes to parsing (like white spaces trimming or not), making everything confusing for the script writer. The new standard format will align all of them - a common, easy to remember and use format.

''Want to provide feedback? See [[https://www.opensips.org/Development/Opensips-3-2-Planning#feature-survey|below]]''
to:
!!!! Generic Preprocessor Support

This feature adds full built-in pre-processing support for the OpenSIPS script. OpenSIPS 3.0 integrates various existing pre-processors within OpenSIPS. This simplify the scripting itself, the script portability across multiple servers and not to mention the entire deployment process of more complex platforms (where OpenSIPS is just a part of it). Even more, you will be able to use your preferred pre-processor and align OpenSIPS with the rest of your system (M4, Jinja, Embedded Ruby or others).\\
Read a full description of this feature [[https://blog.opensips.org/2019/03/05/generic-preprocessor-support-in-opensips-3-0/|here]].


!!!! Module Functions Now Benefit From a New Parameter Interface
As a response to frequent mailing list complaints of wildly varying behaviors across different module functions (e.g. some accept integers/strings as inputs while others accept both integers/strings or variables holding such values), we've introduced an abstract layer which handles the parameter passing task for all module functions, effectively making all of them more powerful by globally allowing flexible input. An added benefit is that new OpenSIPS modules are now even faster to develop. See the new function calling conventions [[https://www.opensips.org/Documentation/Script-Syntax-3-0#function-calling-conventions|here]].

----
Changed lines 34-57 from:
Several enhancements and new concepts are planned for OpenSIPS 3.2 in order to help with operating OpenSIPS - making it simpler to run, to monitor, to troubleshoot and diagnose:

* '''auto-scaling''' - the ability of OpenSIPS to scale up and down the number of processes at runtime. So, your OpenSIPS will be able to automatically scale up (by forking new processes) according to the volume of traffic, or to scale down (terminating some worker processes) if the internal load is low. This means you do not have to worry if your estimation on the number for worker processes is correct or not (will my OpenSIPS hold to the traffic??) or to worry about planning restarts during the night (to manually resize the number of processes). This feature will also impact the resource consumption (as power or cloud resources) thanks to the automatic down-scaling under low traffic.

* '''runtime changing of module parameters''' - using the MI interface, you will be able to change during runtime the value of some module parameters. No more restarts if you want to change the a timeout value in TM or the NAT pinging interval.

* '''script reloading''' - once the script is restructured and easier to handle, the next step is to be able to reload (at runtime) the routing part of the script. This will provide a huge operational advantage as you do not have to restart your OpenSIPS each time you do changes in your routing logic. The work involved by this task is huge, so it may spread across more than one release.

* '''separate log level for xlog''' - instead of having the same parameter to control the log level for both code and script, a new log level parameter should be added to separately control the level for the script xlog()-ing. You can be more or less verbose with the script logs, without being polluted by the logs from the OpenSIPS code. So, you can easily focus on the logs you need.

* '''custom prefix for xlog''' - define your custom prefix (with variables too) to be used for all the xlog() in the script - for example printing all the time the Call-ID or the name of the route. New variable to report the name of the file, the name of current route and the line number will be added - this will make much easier to correlate your logs with your script.

* '''on startup memory manager selection''' - right now, the selection of the memory manager to use is a compile time option, making a bit difficult to change (from operational perspective) - especially when some memory debugging support is required. For the new version, the memory manager selection will be a startup option, allowing you to change it with any need to recompile / redeploy.

* '''unified sharing tags for clustering''' - in 2.4, each module (with clustering support) is managing its own sharing tags completely isolated from other modules - this make the operating OpenSIPS a bit difficult sometime, as for a single switch from active to backup, you need to individually inform and change the tags in several modules, via several MI commands. In 3.2 the plan is to have the sharing tags managed by clusterer module itself and shared between multiple modules. So with a single MI command, changing a single sharing tag, you can control all the cluster-aware modules (like dialog timeouts, nathelper pinging, dispatcher pinging, etc)

* '''tracing console''' - this is a new concept provided by the new 'opensipsctl' tool. With the tracing console you are able to see in realtime various information related to specifics call only. The information may be the OpenSIPS logs, SIP packets, script logs, rest queries, maybe DB queries. All the information is fetched from OpenSIPS, disregarding the log level configured in OpenSIPS. For selecting the calls to be viewed, IP based , caller based or called number based filters may be defined. The resulting trace may be exported/diverted too to a file (from the console).

* '''self diagnosis''' - this is also a new concept provided with the help of the new 'opensipsctl' tool. The self diagnosis logic will collect various information from a running OpenSIPS (via MI) in regards to thresholds, load information, statistics and logs in order to locate and indicate a potential problem or bottleneck. This will be your best friend when comes to operating OpenSIPS and trying to understand why things are not going as you expect.

* '''internal memory persistence during restart''' - there several modules caching (in OpenSIPS internal memory, not in external no-sql cachers) large chunks of data, like Dynamic Routing, Dialplan, Dispatcher or Permissions. To avoid the date loading and caching penalty during a restart, the plan for 3.2 is to have segments of the internal memory to "survive" during the restart. This will dramatically reduce the time to restart of the entire service.

''Want to provide feedback? See [[https://www.opensips.org/Development/Opensips-3-2-Planning#feature-survey|below]]''
to:
!!!! Routing Script Re-load

OpenSIPS 3.0 exposes the valuable ability of reloading the routes (not the module configuration) during runtime, with zero penalties and with zero loses as traffic.
See the documentation of the [[https://www.opensips.org/Documentation/Interface-CoreMI-3-0#toc8|MI "reload_routes" function]].

!!!! Processes Auto-Scaling Support

This is the ability of OpenSIPS to scale up and down the number of processes at runtime. Basically OpenSIPS is able to automatically scale up (by forking new processes) according to the volume of traffic, or to scale down (terminating some worker processes) if the internal load is low. This means you do not have to worry if your estimation on the number for worker processes is correct or not (will my OpenSIPS hold to the traffic??) or to worry about planning restarts during the night (to manually resize the number of processes).\\
Read a full description of this feature [[https://blog.opensips.org/2019/02/25/auto-process-scaling-a-cure-for-load-and-resources-concerns/|here]].

!!!! New OpenSIPS CLI (Command Line Interface) tool

Starting with OpenSIPS 3.0, the old ''opensipsctl'' tool becomes deprecated (as functionality and as software) and it is replaced by the new ''opensips-cli'' - a powerful Python3 application that allows you to interact in a smart way with OpenSIPS, to invoke advanced tools such as [[https://github.com/OpenSIPS/opensips-cli/blob/master/docs/modules/diagnose.md|diagnose]] or [[https://github.com/OpenSIPS/opensips-cli/blob/master/docs/modules/tracer.md|tracer]], as well as to perform DB provisioning.
Read a full description of ''opensips-cli'' [[https://blog.opensips.org/2019/03/13/new-opensips-cli-tool-for-the-new-management-interface-in-opensips-3-0/|here]].

!!!! Selectable Memory Allocator Support

This feature allows the internal memory manager to be selected at startup time. In OpenSIPS 3.0, the memory manager selection becomes a startup option, via command line arguments, allowing you to change it without any need to recompile or redeploy.
Read a full description of this feature [[https://blog.opensips.org/2019/03/21/containing-memory-related-issues-in-an-easy-way-with-opensips-3-0/|here]].

!!!! Internal Memory Persistence during Restart

As there are several modules caching (in OpenSIPS internal memory, not in external no-sql cachers) large chunks of data, like Dynamic Routing, Dialplan, Dispatcher or Permissions, OpenSIPS 3.0 is able to avoid the data loading and caching penalty during a restart - this segments of the internal memory do "survive" during the restart. This dramatically reduces the time to restart of the entire service. \\
Read a full description of this feature [[https://blog.opensips.org/2019/04/04/no-downtime-for-opensips-3-0-restarts/|here]].

!!!! Unified Sharing Tags for Clustering

In 2.4, each module (with clustering support) is managing its own sharing tags completely isolated from other modules - this make the operating OpenSIPS a bit difficult sometime, as for a single switch from active to backup, you need to individually inform and change the tags in several modules, via several MI commands. In OpenSIPS 3.0 we have now the sharing tags managed by clusterer module itself and shared between multiple modules. So with a single MI command, changing a single sharing tag, you can control all the cluster-aware modules (like dialog timeouts, nathelper pinging, dispatcher pinging, etc)
Read a full description of this feature [[https://blog.opensips.org/2019/03/07/achieving-service-redundancy-in-two-steps-with-unified-clustering-in-opensips-3-0/|here]].


----
Changed lines 70-77 from:
More integration capabilities are to be added to the 3.2 release :

* '''Management Interface rework''' - in the previous version, each MI backend is actually a mixing when comes to the used transport and the data encoding/syntax. For example, the MI_FIFO module uses a line oriented syntax via a stream file; the MI_XMLRPC modules uses XMLRPC via HTTP etc. To simplify the integration effort, the plan is to use a single standard encoding (a powerful and popular one) for the MI data and the MI backend modules will provide only the transport. The decision is to go with JSON-RPC. The new MI_FIFO module will receive JSON-RPC requests and send responses over a stream file, the current MI_JSON module will become only a HTTP backend and so on. The fact that the encoding is standard, will allow us to expose the MI interface back to the script - yes, that's right, you will be able to invoke MI commands directly from the OpenSIPS script, as the input and output will be a JSON encode string, so easy to handle from script. Who doesn't love JSON :) ?

* '''SMPP integration''' - a new module to act as a bidirectional gateway / translator between SIP (MESSAGE requests) and SMPP protocol. The SMPP protocol is widely used for SMS delivery, so such a build-in gateway capability will definitely simplify the overall architecture of the SIP-based services.

* '''RabbitMQ consumer''' - a new module to be able to act as a RabbitMQ consumer and deliver the consumed messages as events into the OpenSIPS script. OpenSIPS already has the ability to act as a RabbitMQ producer.
to:
!!!! MI Interaction Standardization
An extensive rework of the Management Interface in an attempt to standardize and speed up development of external applications which need to interact with OpenSIPS. The custom, JSON-based HTTP calls of OpenSIPS 2.X are now replaced with the JSON-RPC version 2 standard. The custom, line-oriented syntax was completely dropped. XMLRPC and mi_html (former mi_http) were kept backwards-compatible. Read a detailed description of the new interactions [[https://www.opensips.org/Documentation/Interface-MI-3-0#protocols|here]]

!!!! SMPP support

OpenSIPS 3.0 provides a [[https://opensips.org/html/docs/modules/3.0.x/proto_smpp.html|new SMPP module]] that allows you to do bidirectional gatewaying between SIP and SMPP traffic - this is a powerful but flexible way to integrate with most of the SMS providers / gateways.
Read a full description of this feature [[https://blog.opensips.org/2019/01/24/gateway-between-sip-and-smpp-messages/|here]].

!!!! RabbitMQ Consumer support

A new [[https://opensips.org/html/docs/modules/3.0.x/rabbitmq_consumer.html|RabbitMQ consumer module]] which manages connections with one or more brokers, subscribes for events and propagates them at OpenSIPS script level via the event interface.



Changed lines 88-121 from:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSeFZ4KYa81LHO7xYyi1GfLklQK4IomXQNdfeu4KqYaT5peHLQ/viewform|OpenSIPS 3.2 Feature Survey]] (due 6th January 2019), 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]]
!!! 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.2 progress. Nevertheless, we strongly recommend you to check the [[https://www.opensips.org/About/Version-3-2-0|Feature list]] of 3.2.

[[<<]]
||border=1
|| '''Feature Code''' || '''Feature Name''' || '''Score (1-5)''' || '''Implementation Status''' ||
|| OPS-3 || Script Reloading || 4.57 || in-progress ||
|| OPS-9 || Self-Diagnosis Tool || 4.26 || in-progress ||
|| OPS-1 || Auto-Scale the Number of Workers || 4.25 || '''[[https://blog.opensips.org/2019/02/25/auto-process-scaling-a-cure-for-load-and-resources-concerns/|completed]]''' ||
|| DEV-3 || Full Variable Support for Functions || 4.19 || in-progress ||
|| OPS-8 || Tracing/Traffic Filtering Console || 4.15 || in-progress ||
|| OPS-2 || Edit Module Params at Runtime || 4.10 || pending ||
|| OPS-10 || Persistent Shared Memory on Restart || 4.08 || '''[[https://blog.opensips.org/2019/04/04/no-downtime-for-opensips-3-2-restarts/|completed]]''' ||
|| DEV-5 || Route entry point per Listener || 3.80 || pending ||
|| ITG-1 || Management Interface Rework || 3.77 || '''[[https://blog.opensips.org/2019/03/13/new-opensips-cli-tool-for-the-new-management-interface-in-opensips-3-2/|completed]]''' ||
|| DEV-6 || Standard Format for Complex Modparams || 3.71 || pending ||
|| DEV-1 || Pluggable Preprocessor || 3.69 || '''[[https://blog.opensips.org/2019/03/05/generic-preprocessor-support-in-opensips-3-2/|completed]]''' ||
|| OPS-4 || Separate xlog() Logging Level || 3.68 || '''completed''' ||
|| ITG-3 || RabbitMQ Consumer Module || 3.65 || in-progress ||
|| OPS-5 || Custom xlog() Formatting Prefix || 3.58 || '''completed''' ||
|| OPS-6 || Selectable Memory Allocator || 3.48 || '''[[https://blog.opensips.org/2019/03/21/containing-memory-related-issues-in-an-easy-way-with-opensips-3-2/|completed]]''' ||
|| OPS-7 || Unified Sharing Tags || 3.41 || '''[[https://blog.opensips.org/2019/03/07/achieving-service-redundancy-in-two-steps-with-unified-clustering-in-opensips-3-2/|completed]]''' ||
|| ITG-2 || SMPP Integration || 3.36 || '''[[https://blog.opensips.org/2019/01/24/gateway-between-sip-and-smpp-messages/|completed]]''' ||
|| DEV-4 || Better Naming for Variables || 3.30 || pending ||
|| DEV-2 || Script Format Change || 3.20 || pending ||
||

[[<<]]
to:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSeFZ4KYa81LHO7xYyi1GfLklQK4IomXQNdfeu4KqYaT5peHLQ/viewform|OpenSIPS 3.2 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.2 release. Thank you!

April 11, 2019, at 01:20 PM by liviu -
Changed line 100 from:
|| OPS-6 || Selectable Memory Allocator || 3.48 || '''completed''' ||
to:
|| OPS-6 || Selectable Memory Allocator || 3.48 || '''[[https://blog.opensips.org/2019/03/21/containing-memory-related-issues-in-an-easy-way-with-opensips-3-2/|completed]]''' ||
April 05, 2019, at 03:26 PM by liviu -
Changed line 92 from:
|| OPS-10 || Persistent Shared Memory on Restart || 4.08 || in-progress ||
to:
|| OPS-10 || Persistent Shared Memory on Restart || 4.08 || '''[[https://blog.opensips.org/2019/04/04/no-downtime-for-opensips-3-2-restarts/|completed]]''' ||
April 05, 2019, at 03:25 PM by liviu -
Changed line 98 from:
|| ITG-3 || RabbitMQ Consumer Module || 3.65 || pending ||
to:
|| ITG-3 || RabbitMQ Consumer Module || 3.65 || in-progress ||
March 18, 2019, at 06:57 PM by 109.99.227.30 -
Added lines 81-82:
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 [[https://www.opensips.org/About/Version-3-2-0|Feature list]] of 3.2.
Changed lines 85-104 from:
|| '''Feature Code''' || '''Feature Name''' || '''Score (1-5)''' ||
|| OPS-3 || Script Reloading || 4.57
|| OPS-9 || Self-Diagnosis Tool || 4.26
|| OPS-1 || Auto-Scale the Number of Workers || 4.25
|| DEV-3 || Full Variable Support for Functions || 4.19
|| OPS-8 || Tracing/Traffic Filtering Console || 4.15
|| OPS-2 || Edit Module Params at Runtime || 4.10
|| OPS-10 || Persistent Shared Memory on Restart || 4.08
|| DEV-5 || Route entry point per Listener || 3.80
|| ITG-1 || Management Interface Rework || 3.77
|| DEV-6 || Standard Format for Complex Modparams || 3.71
|| DEV-1 || Pluggable Preprocessor || 3.69
|| OPS-4 || Separate xlog() Logging Level || 3.68
|| ITG-3 || RabbitMQ Consumer Module || 3.65
|| OPS-5 || Custom xlog() Formatting Prefix || 3.58
|| OPS-6 || Selectable Memory Allocator || 3.48
|| OPS-7 || Unified Sharing Tags || 3.41
|| ITG-2 || SMPP Integration || 3.36
|| DEV-4 || Better Naming for Variables || 3.30
|| DEV-2 || Script Format Change || 3.20
to:
|| '''Feature Code''' || '''Feature Name''' || '''Score (1-5)''' || '''Implementation Status''' ||
|| OPS-3 || Script Reloading || 4.57 || in-progress ||
|| OPS-9 || Self-Diagnosis Tool || 4.26 || in-progress ||
|| OPS-1 || Auto-Scale the Number of Workers || 4.25 || '''[[https://blog.opensips.org/2019/02/25/auto-process-scaling-a-cure-for-load-and-resources-concerns/|completed]]''' ||
|| DEV-3 || Full Variable Support for Functions || 4.19 || in-progress ||
|| OPS-8 || Tracing/Traffic Filtering Console || 4.15 || in-progress ||
|| OPS-2 || Edit Module Params at Runtime || 4.10 || pending ||
|| OPS-10 || Persistent Shared Memory on Restart || 4.08 || in-progress ||
|| DEV-5 || Route entry point per Listener || 3.80 || pending ||
|| ITG-1 || Management Interface Rework || 3.77 || '''[[https://blog.opensips.org/2019/03/13/new-opensips-cli-tool-for-the-new-management-interface-in-opensips-3-2/|completed]]''' ||
|| DEV-6 || Standard Format for Complex Modparams || 3.71 || pending ||
|| DEV-1 || Pluggable Preprocessor || 3.69 || '''[[https://blog.opensips.org/2019/03/05/generic-preprocessor-support-in-opensips-3-2/|completed]]''' ||
|| OPS-4 || Separate xlog() Logging Level || 3.68 || '''completed''' ||
|| ITG-3 || RabbitMQ Consumer Module || 3.65 || pending ||
|| OPS-5 || Custom xlog() Formatting Prefix || 3.58 || '''completed''' ||
|| OPS-6 || Selectable Memory Allocator || 3.48 || '''completed''' ||
|| OPS-7 || Unified Sharing Tags || 3.41 || '''[[https://blog.opensips.org/2019/03/07/achieving-service-redundancy-in-two-steps-with-unified-clustering-in-opensips-3-2/|completed]]''' ||
|| ITG-2 || SMPP Integration || 3.36 || '''[[https://blog.opensips.org/2019/01/24/gateway-between-sip-and-smpp-messages/|completed]]''' ||
|| DEV-4 || Better Naming for Variables || 3.30 || pending ||
|| DEV-2 || Script Format Change || 3.20 || pending ||
Changed line 106 from:
%blue%'''OpenSIPS 3.2 Feature Survey Results'''
to:
January 09, 2019, at 12:20 PM by liviu -
Changed lines 74-105 from:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSeFZ4KYa81LHO7xYyi1GfLklQK4IomXQNdfeu4KqYaT5peHLQ/viewform|OpenSIPS 3.2 Feature Survey]] (due 6th January 2019), 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!
to:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSeFZ4KYa81LHO7xYyi1GfLklQK4IomXQNdfeu4KqYaT5peHLQ/viewform|OpenSIPS 3.2 Feature Survey]] (due 6th January 2019), 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]]
!!! 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.

[[<<]]
||border=1
|| '''Feature Code''' || '''Feature Name''' || '''Score (1-5)''' ||
|| OPS-3 || Script Reloading || 4.57
|| OPS-9 || Self-Diagnosis Tool || 4.26
|| OPS-1 || Auto-Scale the Number of Workers || 4.25
|| DEV-3 || Full Variable Support for Functions || 4.19
|| OPS-8 || Tracing/Traffic Filtering Console || 4.15
|| OPS-2 || Edit Module Params at Runtime || 4.10
|| OPS-10 || Persistent Shared Memory on Restart || 4.08
|| DEV-5 || Route entry point per Listener || 3.80
|| ITG-1 || Management Interface Rework || 3.77
|| DEV-6 || Standard Format for Complex Modparams || 3.71
|| DEV-1 || Pluggable Preprocessor || 3.69
|| OPS-4 || Separate xlog() Logging Level || 3.68
|| ITG-3 || RabbitMQ Consumer Module || 3.65
|| OPS-5 || Custom xlog() Formatting Prefix || 3.58
|| OPS-6 || Selectable Memory Allocator || 3.48
|| OPS-7 || Unified Sharing Tags || 3.41
|| ITG-2 || SMPP Integration || 3.36
|| DEV-4 || Better Naming for Variables || 3.30
|| DEV-2 || Script Format Change || 3.20
||
%blue%'''OpenSIPS 3.2 Feature Survey Results'''
[[<<]]
December 13, 2018, at 05:08 PM by 109.99.227.30 -
Changed line 1 from:
!!!!! [[Development.Development|Development]] -> [[Development.Topics|Topics]] -> [[Development.Opensips-3-2-Planning|OpenSIPS 3.2 Planning]]
to:
!!!!! [[Development.Development|Development]] -> [[Development.Planning|Planning]] -> [[Development.Opensips-3-2-Planning|OpenSIPS 3.2 Planning]]
December 13, 2018, at 02:16 PM by liviu -
Changed lines 16-17 from:
''Want to provide feedback? See [[https://www.opensips.org/Development/Opensips-3-2-Planning#feature-survey|below]]''
to:
Added lines 31-32:
''Want to provide feedback? See [[https://www.opensips.org/Development/Opensips-3-2-Planning#feature-survey|below]]''
Changed lines 35-36 from:
''Want to provide feedback? See [[https://www.opensips.org/Development/Opensips-3-2-Planning#feature-survey|below]]''
to:
Added lines 58-59:
''Want to provide feedback? See [[https://www.opensips.org/Development/Opensips-3-2-Planning#feature-survey|below]]''
Deleted line 61:
''Want to provide feedback? See [[https://www.opensips.org/Development/Opensips-3-2-Planning#feature-survey|below]]''
December 13, 2018, at 02:15 PM by liviu -
Deleted line 15:
Deleted line 33:
Deleted line 59:
December 13, 2018, at 02:15 PM by liviu -
Added lines 17-18:
''Want to provide feedback? See [[https://www.opensips.org/Development/Opensips-3-2-Planning#feature-survey|below]]''
Added lines 36-37:
''Want to provide feedback? See [[https://www.opensips.org/Development/Opensips-3-2-Planning#feature-survey|below]]''
Added lines 63-64:
''Want to provide feedback? See [[https://www.opensips.org/Development/Opensips-3-2-Planning#feature-survey|below]]''
Added line 73:
[[#feature-survey]]
December 13, 2018, at 02:12 PM by liviu -
Changed line 69 from:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSeFZ4KYa81LHO7xYyi1GfLklQK4IomXQNdfeu4KqYaT5peHLQ/viewform|OpenSIPS 3.2 Feature Survey]], 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!
to:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSeFZ4KYa81LHO7xYyi1GfLklQK4IomXQNdfeu4KqYaT5peHLQ/viewform|OpenSIPS 3.2 Feature Survey]] (due 6th January 2019), 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!
December 13, 2018, at 02:09 PM by liviu -
Changed line 69 from:
We are undergoing an [[https://docs.google.com/forms/d/1MrEQS3vW0LJh-nrcntlddXc3FzGqlnI_7HsC4Vkn9LY|OpenSIPS 3.2 Feature Survey]], 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!
to:
We are undergoing an [[https://docs.google.com/forms/d/e/1FAIpQLSeFZ4KYa81LHO7xYyi1GfLklQK4IomXQNdfeu4KqYaT5peHLQ/viewform|OpenSIPS 3.2 Feature Survey]], 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!
December 13, 2018, at 02:06 PM by liviu -
Changed line 69 from:
We are undergoing an [[https://docs.google.com/forms/d/1MrEQS3vW0LJh-nrcntlddXc3FzGqlnI_7HsC4Vkn9LY|OpenSIPS 3.2 Feature Survey]], 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 release. Thank you!
to:
We are undergoing an [[https://docs.google.com/forms/d/1MrEQS3vW0LJh-nrcntlddXc3FzGqlnI_7HsC4Vkn9LY|OpenSIPS 3.2 Feature Survey]], 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!
December 13, 2018, at 02:05 PM by liviu -
Added line 6:
[[#philosophy]]
Added lines 66-69:

!!! Vote your Favorite Features!

We are undergoing an [[https://docs.google.com/forms/d/1MrEQS3vW0LJh-nrcntlddXc3FzGqlnI_7HsC4Vkn9LY|OpenSIPS 3.2 Feature Survey]], 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 release. Thank you!
December 13, 2018, at 12:57 PM by razvancrainea -
Changed line 64 from:
* '''RabbitMQ consumer''' - a new module to be able to act as a RMQ consumer and deliver the consumed messages as events into the OpenSIPS script. OpenSIPS already has the ability to act as a RMQ producer.
to:
* '''RabbitMQ consumer''' - a new module to be able to act as a RabbitMQ consumer and deliver the consumed messages as events into the OpenSIPS script. OpenSIPS already has the ability to act as a RabbitMQ producer.
December 13, 2018, at 12:56 PM by razvancrainea -
Changed line 24 from:
* '''better naming for variables''' - expand the name of the existing variables form the short cryptic ones (like $rU , $Ri) to something (1) easier to understand (self explanatory) and (2) to indicate the scope of the variable, like, $msg.ruri, $msg.flags() or $msg.src_ip
to:
* '''better naming for variables''' - expand the name of the existing variables from the short cryptic ones (like $rU , $Ri) to something (1) easier to understand (self explanatory) and (2) to indicate the scope of the variable, like, $msg.ruri, $msg.flags() or $msg.src_ip
December 13, 2018, at 11:50 AM by 109.99.227.30 -
Added line 13:
[[#development]]
Changed line 30 from:
to:
[[#operational]]
Added line 55:
[[#integration]]
December 12, 2018, at 07:35 PM by 109.99.227.30 -
Changed lines 13-14 from:
!!! "Dev" area
to:
!!! Script Development aspects
Changed lines 30-31 from:
!!! "Ops" area
to:
!!! Operational aspects
Changed line 54 from:
!!! Integration area
to:
!!! Integration aspects
December 12, 2018, at 07:34 PM by 109.99.227.30 -
Changed line 58 from:
* '''Management Interface rework''' - in the previous version, each MI backend is actually a mixing when comes to the used transport and the data encoding/syntax. For example, the MI_FIFO module uses a line oriented syntax via a stream file; the MI_XMLRPC modules uses XMLRPC via HTTP etc. To simplify the integration effort, the plan is to use a single standard encoding (a powerful and popular one) for the MI data and the MI backend modules will provide only the transport. The decision is to go with JSON-RPC. The new MI_FIFO module will receive JSON-RPC requests and send responses over a stream file, the current MI_JSON module will become only a HTTP backend and so on. The fact that the encoding is standard, will allow us to expose the MI interface back to the script - yes, that's right, to be able to invoke MI commands directly from the OpenSIPS script, as the input and output will be a JSON encode string, so easy to handle from script. Who doesn't love JSON :) ?
to:
* '''Management Interface rework''' - in the previous version, each MI backend is actually a mixing when comes to the used transport and the data encoding/syntax. For example, the MI_FIFO module uses a line oriented syntax via a stream file; the MI_XMLRPC modules uses XMLRPC via HTTP etc. To simplify the integration effort, the plan is to use a single standard encoding (a powerful and popular one) for the MI data and the MI backend modules will provide only the transport. The decision is to go with JSON-RPC. The new MI_FIFO module will receive JSON-RPC requests and send responses over a stream file, the current MI_JSON module will become only a HTTP backend and so on. The fact that the encoding is standard, will allow us to expose the MI interface back to the script - yes, that's right, you will be able to invoke MI commands directly from the OpenSIPS script, as the input and output will be a JSON encode string, so easy to handle from script. Who doesn't love JSON :) ?
December 12, 2018, at 07:21 PM by 109.99.227.30 -
Changed line 54 from:
!!! Integration
to:
!!! Integration area
December 12, 2018, at 07:07 PM by rvlad_patrascu -
Changed line 58 from:
* '''Management Interface rework''' - in the previous version, each MI backend is actually a mixing when comes to the used transport and the data encoding/syntax. Like FIFO is a line oriented syntax via a stream file; the JSONRPC is a JSON encoding via HTTP. To simplify the integration effort, the plan is to use a single standard encoding (a powerful and popular one) for the MI data and the MI backend module will provide only the transport. The decision is to go with JSON. The new FIFO module will do JSON over stream file; the JSON RPC will become HTTP backend and it will do JSON over HTTP, and so on. The fact that the encoding is standard, will allow us to expose the MI interface back to the script - yes, that's right, to be able to invoke MI commands directly from the OpenSIPS script, as the input and output will be a JSON encode string, so easy to handle from script. Who doesn't love JSON :) ?
to:
* '''Management Interface rework''' - in the previous version, each MI backend is actually a mixing when comes to the used transport and the data encoding/syntax. For example, the MI_FIFO module uses a line oriented syntax via a stream file; the MI_XMLRPC modules uses XMLRPC via HTTP etc. To simplify the integration effort, the plan is to use a single standard encoding (a powerful and popular one) for the MI data and the MI backend modules will provide only the transport. The decision is to go with JSON-RPC. The new MI_FIFO module will receive JSON-RPC requests and send responses over a stream file, the current MI_JSON module will become only a HTTP backend and so on. The fact that the encoding is standard, will allow us to expose the MI interface back to the script - yes, that's right, to be able to invoke MI commands directly from the OpenSIPS script, as the input and output will be a JSON encode string, so easy to handle from script. Who doesn't love JSON :) ?
December 12, 2018, at 07:04 PM by 109.99.227.30 -
Changed line 8 from:
%rframe width=300px % https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg
to:
%rframe width=300px % https://blogopensips.files.wordpress.com/2018/12/opensips-3.2-icon.png
December 12, 2018, at 06:58 PM by 109.99.227.30 -
Added lines 19-20:
* '''script format changing''' - re-structure how the modules are loaded and their parameters defined in the script (as syntax). Even if from functionality or capabilities perspective nothing will changed, [[https://opensips.org/Development/Design-Opensips-Script-Rework|the new format]] will make the OpenSIPS script much easier to structure, so to automate the script building and deployment. Not to mention that the new format will be much cleaner and easier to follow by the script developers.
Deleted lines 36-37:

* '''script format changing''' - re-structure how the modules are loaded and their parameters defined in the script (as syntax). Even if from functionality or capabilities perspective nothing will changed, [[https://opensips.org/Development/Design-Opensips-Script-Rework|the new format]] will make the OpenSIPS script much easier to structure, so to automate the script building and deployment. Not to mention that the new format will be much cleaner and easier to follow by the script developers.
December 12, 2018, at 06:28 PM by 109.99.227.30 -
Deleted line 3:
(:toc-float Table of Content:)
December 12, 2018, at 06:27 PM by liviu -
Changed line 37 from:
* '''script format changing''' - re-structure how the modules are loaded and their parameters defined in the script (as syntax). Even if from functionality or capabilities perspective nothing will changed, [[https://opensips.org/Development/Design-Opensips-Script-Rework|the newly format]] will make the OpenSIPS script much easier to structure, so to automate the script building and deployment. Not to mention that the new format will be much cleaner and easier to follow by the script developers.
to:
* '''script format changing''' - re-structure how the modules are loaded and their parameters defined in the script (as syntax). Even if from functionality or capabilities perspective nothing will changed, [[https://opensips.org/Development/Design-Opensips-Script-Rework|the new format]] will make the OpenSIPS script much easier to structure, so to automate the script building and deployment. Not to mention that the new format will be much cleaner and easier to follow by the script developers.
December 12, 2018, at 06:15 PM by 109.99.227.30 -
Added line 64:
December 12, 2018, at 06:14 PM by 109.99.227.30 -
Added lines 39-40:
* '''script reloading''' - once the script is restructured and easier to handle, the next step is to be able to reload (at runtime) the routing part of the script. This will provide a huge operational advantage as you do not have to restart your OpenSIPS each time you do changes in your routing logic. The work involved by this task is huge, so it may spread across more than one release.
Added lines 59-60:
* '''Management Interface rework''' - in the previous version, each MI backend is actually a mixing when comes to the used transport and the data encoding/syntax. Like FIFO is a line oriented syntax via a stream file; the JSONRPC is a JSON encoding via HTTP. To simplify the integration effort, the plan is to use a single standard encoding (a powerful and popular one) for the MI data and the MI backend module will provide only the transport. The decision is to go with JSON. The new FIFO module will do JSON over stream file; the JSON RPC will become HTTP backend and it will do JSON over HTTP, and so on. The fact that the encoding is standard, will allow us to expose the MI interface back to the script - yes, that's right, to be able to invoke MI commands directly from the OpenSIPS script, as the input and output will be a JSON encode string, so easy to handle from script. Who doesn't love JSON :) ?
Added line 64:
December 12, 2018, at 06:01 PM by 109.99.227.30 -
Changed lines 18-21 from:
* '''full pre-processing support''' - add full built-in pre-processing support for the OpenSIPS script. [[https://www.opensips.org/Development/Design-Opensips-Script-Preprocessing|The plan]] is to avoid "inventing" and "implementing" our own pre-processor, but to be able to integrate various existing pre-processors within OpenSIPS. This will simplify the scripting itself, the script portability across multiple servers and not to mention the entire deployment process of more complex platforms (where OpenSIPS is just a part of it).

* '''script
to:
* '''full pre-processing support''' - add full built-in pre-processing support for the OpenSIPS script. [[https://www.opensips.org/Development/Design-Opensips-Script-Preprocessing|The plan]] is to avoid "inventing" and "implementing" our own pre-processor, but to be able to integrate various existing pre-processors within OpenSIPS. This will simplify the scripting itself, the script portability across multiple servers and not to mention the entire deployment process of more complex platforms (where OpenSIPS is just a part of it). Even more, you will be able to use your preferred pre-processor and align OpenSIPS with the rest of your system (M4, Jinja, Embedded Ruby or others)
Added lines 22-23:
* '''better naming for variables''' - expand the name of the existing variables form the short cryptic ones (like $rU , $Ri) to something (1) easier to understand (self explanatory) and (2) to indicate the scope of the variable, like, $msg.ruri, $msg.flags() or $msg.src_ip
Changed lines 26-28 from:
to:
* '''standardize the format of complex parameters''' - there are many module parameters with a really complex format for their values, like the parameters describing the [[http://www.opensips.org/html/docs/modules/2.4.x/sql_cacher.html#param_cache_table|sql caching]] or the [[http://www.opensips.org/html/docs/modules/2.4.x/dialplan.html#param_partition|dialplan partitions]]. Right now each has its own way of packing/encoding the data, its own particularities when comes to parsing (like white spaces trimming or not), making everything confusing for the script writer. The new standard format will align all of them - a common, easy to remember and use format.

Changed lines 35-38 from:
* '''runtime changing of module parameters''' - using the MI intreface, you will be able to change during runtime the value of some module parameters. No more restarts if you want to change the a timeout value in TM or the NAT pinging interval.

* '''tracing console''' - this is a new concept provided by the new 'opensipsctl' tool. With the tracing console you are able to see in realtime various information related to specifics call only. The information may be the OpenSIPS logs, SIP packets, script logs, rest queries, maybe DB queries. All the information is fetched from OpenSIPS, disregarding the log level configured in OpenSIPS. For selecting the calls to be viewed, IP based , caller based or called number based filters may be defined. The resulting trace may be exported/diverted too to a file (from the console).
to:
* '''runtime changing of module parameters''' - using the MI interface, you will be able to change during runtime the value of some module parameters. No more restarts if you want to change the a timeout value in TM or the NAT pinging interval.

* '''script format changing''' - re-structure how the modules are loaded and their parameters defined in the script (as syntax). Even if from functionality or capabilities perspective nothing will changed, [[https://opensips.org/Development/Design-Opensips-Script-Rework|the newly format]] will make the OpenSIPS script much easier to structure, so to automate the script building and deployment. Not to mention that the new format will be much cleaner and easier to follow by the script developers.
Added lines 43-52:
* '''on startup memory manager selection''' - right now, the selection of the memory manager to use is a compile time option, making a bit difficult to change (from operational perspective) - especially when some memory debugging support is required. For the new version, the memory manager selection will be a startup option, allowing you to change it with any need to recompile / redeploy.

* '''unified sharing tags for clustering''' - in 2.4, each module (with clustering support) is managing its own sharing tags completely isolated from other modules - this make the operating OpenSIPS a bit difficult sometime, as for a single switch from active to backup, you need to individually inform and change the tags in several modules, via several MI commands. In 3.2 the plan is to have the sharing tags managed by clusterer module itself and shared between multiple modules. So with a single MI command, changing a single sharing tag, you can control all the cluster-aware modules (like dialog timeouts, nathelper pinging, dispatcher pinging, etc)

* '''tracing console''' - this is a new concept provided by the new 'opensipsctl' tool. With the tracing console you are able to see in realtime various information related to specifics call only. The information may be the OpenSIPS logs, SIP packets, script logs, rest queries, maybe DB queries. All the information is fetched from OpenSIPS, disregarding the log level configured in OpenSIPS. For selecting the calls to be viewed, IP based , caller based or called number based filters may be defined. The resulting trace may be exported/diverted too to a file (from the console).

* '''self diagnosis''' - this is also a new concept provided with the help of the new 'opensipsctl' tool. The self diagnosis logic will collect various information from a running OpenSIPS (via MI) in regards to thresholds, load information, statistics and logs in order to locate and indicate a potential problem or bottleneck. This will be your best friend when comes to operating OpenSIPS and trying to understand why things are not going as you expect.

* '''internal memory persistence during restart''' - there several modules caching (in OpenSIPS internal memory, not in external no-sql cachers) large chunks of data, like Dynamic Routing, Dialplan, Dispatcher or Permissions. To avoid the date loading and caching penalty during a restart, the plan for 3.2 is to have segments of the internal memory to "survive" during the restart. This will dramatically reduce the time to restart of the entire service.
Changed lines 57-60 from:
*
to:
* '''SMPP integration''' - a new module to act as a bidirectional gateway / translator between SIP (MESSAGE requests) and SMPP protocol. The SMPP protocol is widely used for SMS delivery, so such a build-in gateway capability will definitely simplify the overall architecture of the SIP-based services.

* '''RabbitMQ consumer''' - a new module to be able to act as a RMQ consumer and deliver the consumed messages as events into the OpenSIPS script. OpenSIPS already has the ability to act as a RMQ producer.
December 12, 2018, at 04:44 PM by 109.99.227.30 -
Added line 17:
Added lines 20-21:
* '''script
Changed line 45 from:
*
to:
*
December 12, 2018, at 01:56 PM by 109.99.227.30 -
Changed lines 28-30 from:
* '''auto-scaling''' - the ability of OpenSIPS to scale up and down the number of processes at runtime. So, your OpenSIPS will be able to automatically scale up (by forking new processes) according to the volume of traffic, or to scale down (terminating some worker processes) if the internal load is low. This means you do not have to worry if your estimation on the number for worker processes is correct or not (will my OpenSIPS hold to the traffic??) or to worry about planning restarts during the night (to manually resize the number of processes)
This feature will also impact the resource consumption (as power or cloud resources) thanks to the automatic down-scaling under low traffic.
to:
* '''auto-scaling''' - the ability of OpenSIPS to scale up and down the number of processes at runtime. So, your OpenSIPS will be able to automatically scale up (by forking new processes) according to the volume of traffic, or to scale down (terminating some worker processes) if the internal load is low. This means you do not have to worry if your estimation on the number for worker processes is correct or not (will my OpenSIPS hold to the traffic??) or to worry about planning restarts during the night (to manually resize the number of processes). This feature will also impact the resource consumption (as power or cloud resources) thanks to the automatic down-scaling under low traffic.
Changed line 42 from:
*
to:
*
December 12, 2018, at 01:56 PM by 109.99.227.30 -
Added lines 1-43:
!!!!! [[Development.Development|Development]] -> [[Development.Topics|Topics]] -> [[Development.Opensips-3-2-Planning|OpenSIPS 3.2 Planning]]
(:title OpenSIPS 3.2 Planning:)

(:toc-float Table of Content:)
----

!!! OpenSIPS 3.2 philosophy

%rframe width=300px % https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg
For the upcoming OpenSIPS 3.2 release (and 3.x family) the main focus is on the '''devops''' concept. This translates into introducing and enhancing in OpenSIPS features / capabilities that (1) will increase the easiness when comes the writing / developing OpenSIPS scripts and (2) simplify the operational activities when comes to running and managing OpenSIPS.

For the OpenSIPS 3.2 release, the following areas of development are considered:

!!! "Dev" area

This is about improving the experience of the OpenSIPS script writer (developer), by enhancing and simplifying the OpenSIPS script:
* '''full pre-processing support''' - add full built-in pre-processing support for the OpenSIPS script. [[https://www.opensips.org/Development/Design-Opensips-Script-Preprocessing|The plan]] is to avoid "inventing" and "implementing" our own pre-processor, but to be able to integrate various existing pre-processors within OpenSIPS. This will simplify the scripting itself, the script portability across multiple servers and not to mention the entire deployment process of more complex platforms (where OpenSIPS is just a part of it).

* '''full variable support''' - any kind of variables will be usable in the parameters of any script function. Extend the script interpreter, so the variable evaluations and the value validation will be transparently done by the interpreter for all the script function. This will increase the script flexibility as the variable usage will become more powerful.

* '''starting route per listener''' - instead of having a single 'route{}' to handle all the incoming requests, you can define different routes to be used for request received via different interfaces. This will simplify the script logic as you can to complete separation of traffic received on different interfaces, like having trigger different route for traffic received on the private interface and different route for traffic received on a public interface.


!!! "Ops" area

Several enhancements and new concepts are planned for OpenSIPS 3.2 in order to help with operating OpenSIPS - making it simpler to run, to monitor, to troubleshoot and diagnose:

* '''auto-scaling''' - the ability of OpenSIPS to scale up and down the number of processes at runtime. So, your OpenSIPS will be able to automatically scale up (by forking new processes) according to the volume of traffic, or to scale down (terminating some worker processes) if the internal load is low. This means you do not have to worry if your estimation on the number for worker processes is correct or not (will my OpenSIPS hold to the traffic??) or to worry about planning restarts during the night (to manually resize the number of processes)
This feature will also impact the resource consumption (as power or cloud resources) thanks to the automatic down-scaling under low traffic.

* '''runtime changing of module parameters''' - using the MI intreface, you will be able to change during runtime the value of some module parameters. No more restarts if you want to change the a timeout value in TM or the NAT pinging interval.

* '''tracing console''' - this is a new concept provided by the new 'opensipsctl' tool. With the tracing console you are able to see in realtime various information related to specifics call only. The information may be the OpenSIPS logs, SIP packets, script logs, rest queries, maybe DB queries. All the information is fetched from OpenSIPS, disregarding the log level configured in OpenSIPS. For selecting the calls to be viewed, IP based , caller based or called number based filters may be defined. The resulting trace may be exported/diverted too to a file (from the console).

* '''separate log level for xlog''' - instead of having the same parameter to control the log level for both code and script, a new log level parameter should be added to separately control the level for the script xlog()-ing. You can be more or less verbose with the script logs, without being polluted by the logs from the OpenSIPS code. So, you can easily focus on the logs you need.

* '''custom prefix for xlog''' - define your custom prefix (with variables too) to be used for all the xlog() in the script - for example printing all the time the Call-ID or the name of the route. New variable to report the name of the file, the name of current route and the line number will be added - this will make much easier to correlate your logs with your script.

!!! Integration

More integration capabilities are to be added to the 3.2 release :

*

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