Development

Development.Opensips-3-4-Planning History

Hide minor edits - Show changes to markup

May 23, 2023, at 07:45 PM by razvancrainea -
Added lines 97-129:

Vote your Favorite Features!

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

Poll Results

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

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


Feature CodeFeature NameScore (1-5)Implementation Status
7SIP B2B Improvements4.16done
8SDP: Structured Manipulation4.08pending
1Performance Testing4.05in progress
2Conformity Testing4.05done
10SQL Backend for Federated User-Location3.79pending
6IMS: IPSec + SIP Outbound3.74in progress
9AVP-Ops Rework3.59pending
5MSRP E2E Encryption2.87pending
3IM Chat Group + API2.72pending
4MSRP Reporting + IMDN2.68done



May 17, 2023, at 03:35 PM by 109.99.227.30 -
Deleted lines 96-128:

Vote your Favorite Features!

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

Poll Results

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

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


Feature CodeFeature NameScore (1-5)Implementation Status
7SIP B2B Improvements4.16done
8SDP: Structured Manipulation4.08pending
1Performance Testing4.05in progress
2Conformity Testing4.05done
10SQL Backend for Federated User-Location3.79pending
6IMS: IPSec + SIP Outbound3.74in progress
9AVP-Ops Rework3.59pending
5MSRP E2E Encryption2.87pending
3IM Chat Group + API2.72pending
4MSRP Reporting + IMDN2.68done



April 12, 2023, at 03:17 PM by 109.99.227.30 -
Changed line 114 from:
7SIP B2B Improvements4.16pending
to:
7SIP B2B Improvements4.16done
Changed line 116 from:
1Performance Testing4.05pending
to:
1Performance Testing4.05in progress
Changed line 119 from:
6IMS: IPSec + SIP Outbound3.74pending
to:
6IMS: IPSec + SIP Outbound3.74in progress
Changed line 123 from:
4MSRP Reporting + IMDN2.68pending
to:
4MSRP Reporting + IMDN2.68done
April 05, 2023, at 12:55 AM by razvancrainea -
Changed line 117 from:
2Conformity Testing4.05pending
to:
2Conformity Testing4.05done
January 23, 2023, at 10:08 AM by liviu -
Changed lines 106-108 from:

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.3 progress. Nevertheless, we strongly recommend you to check the Feature list of 3.3.

to:

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

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

January 23, 2023, at 10:06 AM by liviu -
Changed lines 101-127 from:
to:

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.3 progress. Nevertheless, we strongly recommend you to check the Feature list of 3.3.


Feature CodeFeature NameScore (1-5)Implementation Status
7SIP B2B Improvements4.16pending
8SDP: Structured Manipulation4.08pending
1Performance Testing4.05pending
2Conformity Testing4.05pending
10SQL Backend for Federated User-Location3.79pending
6IMS: IPSec + SIP Outbound3.74pending
9AVP-Ops Rework3.59pending
5MSRP E2E Encryption2.87pending
3IM Chat Group + API2.72pending
4MSRP Reporting + IMDN2.68pending


December 21, 2022, at 05:42 PM by 109.98.45.173 -
Added lines 96-103:

Vote your Favorite Features!

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


December 21, 2022, at 04:54 PM by liviu -
Added lines 85-86:

GitHub#2908

December 21, 2022, at 04:54 PM by liviu -
Added lines 80-84:

Federated usrloc: add support for SQL “metadata” DB

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

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

December 21, 2022, at 04:06 PM by liviu -
Changed line 27 from:

There are dozens of functionalities (registration, authentication, call routing, accounting, dialog, b2b and others), complex functionalities, which is to inter-operate in most of the cases. So even the smallest changes or extensions in the code may impact the existing functionalities in unexpected ways.

to:

There are dozens of functionalities (registration, authentication, call routing, accounting, dialog, b2b and others), complex functionalities, which often inter-operate -- they may depend on each other. So even the smallest changes or extensions in one part of the code may impact unrelated functionalities in unexpected ways.

Changed line 29 from:

The intention here is to build a framework (docker based) that will allow the creation of any new SIP scenarios. The scenarios will involve various entities, like SIP UAs, DBs, provisioning tools, etc. Such new entities (as docker images) may be added at any time.

to:

The intention here is to build a framework (Docker based) that will allow the creation of any new SIP scenarios. The scenarios will involve various entities, like SIP UAs, DBs, provisioning tools, etc. New such entities (as Docker images) may be added at any time, further down the line.

December 21, 2022, at 04:03 PM by liviu -
Changed lines 9-12 from:

Various topic were addressed by the past releases, but most of the work with regards to each topic was mainly covered within one release, so limited in terms of allocated resources (time and men power). And some of these past topics are actually wider than what we managed to do. This is why the upcoming OpenSIPS 3.4 wants to address the consolidation of various past topics, to complete or expand even them. But one of the most important side of this consolidation process is the testing of OpenSIPS, from the performance and conformity perspective. This testing is a long overdue task that definitely needs to be addressed.

to:

Various topics were addressed by the past releases, but most of the work with regards to each topic was mainly covered within a single release, so limited in terms of allocated resources (time and man-power). And some of these past topics are actually wider than what we managed to deliver. This is why the upcoming OpenSIPS 3.4 wants to address the consolidation of various past topics, to complete or even expand them. But one of the most important sides of this consolidation process is the testing of OpenSIPS, from the performance and conformity perspective. This testing is a long overdue task that definitely needs to be addressed.

Changed line 18 from:

The testing is important to maintain the health of the code, in terms of functionality as well as performance. In other words, testing is needed to be sure OpenSIPs works correctly and performs as fast as expected.

to:

Testing is important to maintain the health of the code, in terms of functionality as well as performance. In other words, testing is needed to be sure OpenSIPs works correctly and performs as fast as expected.

Changed lines 22-23 from:

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

to:

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

December 21, 2022, at 03:57 PM by razvancrainea -
Changed lines 9-12 from:

Various topic were addressed by the past releases, but most of the work in regards to each topic was mainly covered within one release, so limited in terms of allocated resources (time and man power). And some of these past topic are actually wider than what we managed to do. This is why the upcoming OpenSIPS 3.4 what to address the consolidation of various past topics, to complete or expand them. But on of the most important side of this consolidation process is the testing of OpenSIPS, from the performance and conformity perspective. This testing is a long over due task that definitely needs to be addressed.

to:

Various topic were addressed by the past releases, but most of the work with regards to each topic was mainly covered within one release, so limited in terms of allocated resources (time and men power). And some of these past topics are actually wider than what we managed to do. This is why the upcoming OpenSIPS 3.4 wants to address the consolidation of various past topics, to complete or expand even them. But one of the most important side of this consolidation process is the testing of OpenSIPS, from the performance and conformity perspective. This testing is a long overdue task that definitely needs to be addressed.

Changed lines 18-20 from:

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

to:

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

Changed lines 22-25 from:

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

to:

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

Changed lines 27-28 from:

There are dozens of functionalities (registration, auth, call routing, accounting, dialog, b2b and others), complex functionalities, which is do inter-operate in most of the cases. So even the smallest changes or extensions in the code may impact the existing functionalities in unexpected ways. The validation of the code and the detection of possible regressions must be done via a continues testing of OpenSIPS. The testing is to be done at SIP level, by running various SIP flows on OpenSIPS, as a black box, and observing its behavior and output.

to:

There are dozens of functionalities (registration, authentication, call routing, accounting, dialog, b2b and others), complex functionalities, which is to inter-operate in most of the cases. So even the smallest changes or extensions in the code may impact the existing functionalities in unexpected ways. The validation of the code and the detection of possible regressions must be done via a continuous testing of OpenSIPS. The testing is to be done at SIP level, by running various SIP flows on OpenSIPS, as a black box, and observing its behavior and output.

Changed line 68 from:
  • re-work the re-bridging sequence to avoid delayed ACK due too long ringing on the new entity to be bridged. Also a non-late-SDP alternative should be provided here
to:
  • re-work the re-bridging sequence to avoid delayed ACK due to long ringing on the new entity to be bridged. Also a non-late-SDP alternative should be provided here
Changed line 82 from:

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

to:

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

December 21, 2022, at 03:47 PM by 109.99.227.30 -
Changed line 5 from:
to:

https://cdn.fcw.com/media/img/cd/2021/12/12/consolidate_puzzle/860x394.jpg

Changed lines 9-16 from:

https://blogopensips.files.wordpress.com/2021/12/opensips-3.4-im.jpg The instant messaging is evolving and gaining more and more importance. This happens in both worlds of VoIP/ITSP and IMS/MNO/MVNOs - and the overlapping and mixing of these worlds in increasing each year. The upcoming OpenSIPS 3.4 is to address more, in depth, the topic of Instant Messaging, in the context of SIP. And this is to be done through two major perspectives: from the Unified Communication perspective, by aligning IM with the voice and presence capabilities in OpenSIPS, and from the IMS perspective, mainly as support/integration with RCS (Rich Communication Services).

Learn more from this blog post about the OpenSIPS 3.4's vision on Instant Messaging in the IMS and Unified Communication ecosystem

to:

Various topic were addressed by the past releases, but most of the work in regards to each topic was mainly covered within one release, so limited in terms of allocated resources (time and man power). And some of these past topic are actually wider than what we managed to do. This is why the upcoming OpenSIPS 3.4 what to address the consolidation of various past topics, to complete or expand them. But on of the most important side of this consolidation process is the testing of OpenSIPS, from the performance and conformity perspective. This testing is a long over due task that definitely needs to be addressed.

Changed lines 15-31 from:

Unified Communication

The Instance Messaging support was part of OpenSIPS from the very beginning. Nevertheless, this was limited to the Page Mode (RFC 3428, or the MESSAGE method). With 3.4 version we are looking to enhance the IM capabilities of OpenSIPS by adding IM support for Session Mode, or the Message Session Relay Protocol / MSRP (RFC 4975, RFC 4976). The huge advantage of Session Mode is the fact that you can have deal with IM in a more complex way, session based, or chats; and this enables more IM oriented services to be built, or unified with the audio/video/presence capabilities.

MSRP relay support

The MSRP relaying (RFC 4976) for IM Session Mode is a must for a SIP Server/Proxy for handling MSRP related SIP session. Besides the ability of relaying MSRP traffic, the 3.4 must extend the SDP parsing support to properly handle the MSRP specific SDP extensions. This addition will enable the easy integration of web-based chat services with OpenSIPS (web sites using WSS and MSRP for chat sessions).

MSRP to MESSAGE gateway

As MSRP is not widely supported in the end-user devices, but MESSAGE method is, a way of doing IM translation from Page Mode (MESSAGE method) to Session Mode (MSRP) will be useful. Such a gateway may be used also middle layer for achieving SMS (SMPP) to RCS/MSRP conversion.

OmniChannel Queue (or Contact Center)

The current Call Center module in OpenSIPS supports only SIP calls (as work items in the queue). But with the planned MSRP support, the IM may be supported also. An IM chat, as an MSRP session, may be handled as a new type of work item in the queue. A unified queue (voice and IM) may deliver items (calls or IM sessions) to agents, in the same time. Of course, the queue distribution logic and the agents capabilities/profile will have to be extended in order to support the IM sessions as well.

IM chat group

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

to:

Testing

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

Performance testing

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

Conformity testing

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

Added lines 34-53:

MSRP

IM chat group

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

MSRP reporting

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

End-2-end encryption

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

Instant Message Disposition Notification

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


Changed lines 57-64 from:

OpenSIPS 3.2 made the first steps towards IMS by providing DIAMETER support. Another part of the broader IP Multimedia Subsystem (IMS), from the IM perspective is RCS. Rich Communication Services (RCS) a protocol between mobile telephone carriers and between phone and carrier, aiming to replace SMS messages. The RCS gains traction both on the MNO's side (more and more already migrated), as well as on the device's side (Android natively support RCS)

RCS / Chat

The Chat service (from RCS), for IM services, mainly relies on SIP and MSRP. In order for OpenSIPS 3.4 to properly implement RCS, several extensions for SIP and MSRP must be implemented/supported, to align to the GSMA specifications over RCC.07 - Rich Communication Suite - Advanced Communications Services and Client Specification, version 11.0. The RCS support in OpenSIPS will make possible scenarios like:

    SIP IM client (non-RCS)   <---SIP--->    OpenSIPS   <---RCS--->   IMS (third-party)   <----RCS--->   mobile device
to:

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

Added lines 62-74:

The SIP Back-2-Back

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

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

Changed lines 81-86 from:

SIP Outbound support

The RFC 5626 specification is mandatory for IMS systems and OpenSIPS should be fully supporting it.

Media Capabilities in B2B mode

The B2B modules in OpenSIPS provide the mechanisms to create complex SIP scenarios in B2B mode. However, they lack support for RTP/media handling, which, if had to be done at the script level, would require some complex logic to store information throughout the B2B context. These modules should rely on the existing RTP Relay interface to handle B2B media in a more easier fashion.

to:

AVPops re-work

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

Dialog

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

Deleted lines 88-121:

Vote your Favorite Features!

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

Poll Results

Many thanks to 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.4 progress. Nevertheless, we strongly recommend you to check the Feature list of 3.4.


Feature CodeFeature NameScore (1-5)Implementation Status
8Media Capabilities in B2B mode4.48done
6Structured SDP manipulation4.40no-go
7SIP Outbound support (RFC5626)4.20no-go
3OmniChannel Queue (or Contact Center)3.6done
1MSRP relay3.46done
1MSRP UA3.46done
4IM chat group (and API)3.4no-go
2MSRP to MESSAGE gateway3.27pending
5RCS/IM Chat3.24done



May 17, 2022, at 10:40 AM by 109.99.227.30 -
Changed line 86 from:
3OmniChannel Queue (or Contact Center)3.6pending
to:
3OmniChannel Queue (or Contact Center)3.6done
Added line 88:
1MSRP UA3.46done
May 13, 2022, at 11:45 AM by razvancrainea -
Changed line 83 from:
8Media Capabilities in B2B mode4.48in-progress
to:
8Media Capabilities in B2B mode4.48done
April 01, 2022, at 11:46 AM by liviu -
Changed line 90 from:
5RCS/IM Chat3.24in-progress
to:
5RCS/IM Chat3.24done
March 28, 2022, at 12:56 PM by 109.99.227.30 -
Changed lines 83-85 from:
8Media Capabilities in B2B mode4.48pending
6Structured SDP manipulation4.40pending
7SIP Outbound support (RFC5626)4.20pending
to:
8Media Capabilities in B2B mode4.48in-progress
6Structured SDP manipulation4.40no-go
7SIP Outbound support (RFC5626)4.20no-go
Changed lines 87-88 from:
1MSRP relay3.46pending
4IM chat group (and API)3.4pending
to:
1MSRP relay3.46done
4IM chat group (and API)3.4no-go
Changed line 90 from:
5RCS/IM Chat3.24pending
to:
5RCS/IM Chat3.24in-progress
February 07, 2022, at 05:37 PM by liviu -
Changed line 58 from:

RFC 5626 specification are mandatory for IMS systems and OpenSIPS should be fully supporting it.

to:

The RFC 5626 specification is mandatory for IMS systems and OpenSIPS should be fully supporting it.

January 21, 2022, at 09:09 AM by 109.99.227.30 -
Added lines 70-78:

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.4 progress. Nevertheless, we strongly recommend you to check the Feature list of 3.4.

January 21, 2022, at 09:07 AM by 109.99.227.30 -
Added lines 70-85:


Feature CodeFeature NameScore (1-5)Implementation Status
8Media Capabilities in B2B mode4.48pending
6Structured SDP manipulation4.40pending
7SIP Outbound support (RFC5626)4.20pending
3OmniChannel Queue (or Contact Center)3.6pending
1MSRP relay3.46pending
4IM chat group (and API)3.4pending
2MSRP to MESSAGE gateway3.27pending
5RCS/IM Chat3.24pending


January 21, 2022, at 08:58 AM by 109.99.227.30 -
Added line 11:

\\

January 21, 2022, at 08:57 AM by 109.99.227.30 -
Added line 12:

Learn more from this blog post about the OpenSIPS 3.4's vision on Instant Messaging in the IMS and Unified Communication ecosystem

December 23, 2021, at 01:58 PM by razvancrainea -
Added lines 57-59:

Media Capabilities in B2B mode

The B2B modules in OpenSIPS provide the mechanisms to create complex SIP scenarios in B2B mode. However, they lack support for RTP/media handling, which, if had to be done at the script level, would require some complex logic to store information throughout the B2B context. These modules should rely on the existing RTP Relay interface to handle B2B media in a more easier fashion.

December 23, 2021, at 01:51 PM by 109.98.32.238 -
Added lines 55-56:

SIP Outbound support

RFC 5626 specification are mandatory for IMS systems and OpenSIPS should be fully supporting it.

December 23, 2021, at 01:45 PM by 109.98.32.238 -
Changed line 62 from:

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

to:

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

December 23, 2021, at 01:37 PM by razvancrainea -
Changed line 10 from:

The instant messaging is evolving and gaining more and more importance. This happens in both worlds of VoIP/ITSP and IMS/M(V)NOs - and the overlapping and mixing of these worlds in increasing by each year. The upcoming OpenSIPS 3.4 is to address more, in depth, the topic of Instant Messaging, in the context of SIP. And this is to be done more two major perspectives: from the Unified Communication perspective, by aligning IM with the voice and presence capabilities in OpenSIPS, and from the IMS perspective, mainly as support/integration with RCS (Rich Communication Services).

to:

The instant messaging is evolving and gaining more and more importance. This happens in both worlds of VoIP/ITSP and IMS/MNO/MVNOs - and the overlapping and mixing of these worlds in increasing each year. The upcoming OpenSIPS 3.4 is to address more, in depth, the topic of Instant Messaging, in the context of SIP. And this is to be done through two major perspectives: from the Unified Communication perspective, by aligning IM with the voice and presence capabilities in OpenSIPS, and from the IMS perspective, mainly as support/integration with RCS (Rich Communication Services).

Changed lines 29-30 from:

The current Call Center module in OpenSIPS supports only SIP calls (as work items in the queue). But with the planned MSRP support, the IM may be supported also. An IM chat, as an MSRP session, may be handled as a new type of work item in the queue. A unified queue (voice and IM) may deliver items (calls or IM sessions) to agents, in the same time. OF course, the queue distribution logic and the agents capabilities/profile will have to be extended in order to support the IM sessions also.

to:

The current Call Center module in OpenSIPS supports only SIP calls (as work items in the queue). But with the planned MSRP support, the IM may be supported also. An IM chat, as an MSRP session, may be handled as a new type of work item in the queue. A unified queue (voice and IM) may deliver items (calls or IM sessions) to agents, in the same time. Of course, the queue distribution logic and the agents capabilities/profile will have to be extended in order to support the IM sessions as well.

Changed lines 32-33 from:

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

to:

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

Changed lines 39-40 from:

OpenSIPS 3.2 made the first steps towards IMS by providing the DIAMETER support. Another part of the broader IP Multimedia Subsystem (IMS), from the IM perspective is RCS. Rich Communication Services (RCS) a protocol between mobile telephone carriers and between phone and carrier, aiming at replacing SMS messages. The RCS gains traction both on the MNO's side (more and more already migrated), but also on the device's side (Android natively support RCS)

to:

OpenSIPS 3.2 made the first steps towards IMS by providing DIAMETER support. Another part of the broader IP Multimedia Subsystem (IMS), from the IM perspective is RCS. Rich Communication Services (RCS) a protocol between mobile telephone carriers and between phone and carrier, aiming to replace SMS messages. The RCS gains traction both on the MNO's side (more and more already migrated), as well as on the device's side (Android natively support RCS)

Changed line 53 from:

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.

to:

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.

December 23, 2021, at 01:31 PM by 109.98.32.238 -
Changed line 9 from:

https://blogopensips.files.wordpress.com/2021/12/opensips-3.4-im.jpg

to:

https://blogopensips.files.wordpress.com/2021/12/opensips-3.4-im.jpg

December 23, 2021, at 01:30 PM by 109.98.32.238 -
Changed line 9 from:

https://blogopensips.files.wordpress.com/2021/12/opensips-3.4-im.jpg

to:

https://blogopensips.files.wordpress.com/2021/12/opensips-3.4-im.jpg

December 23, 2021, at 01:30 PM by 109.98.32.238 -
Changed line 9 from:

https://blogopensips.files.wordpress.com/2021/12/opensips-3.4-im.jpg

to:

https://blogopensips.files.wordpress.com/2021/12/opensips-3.4-im.jpg

December 23, 2021, at 01:29 PM by 109.98.32.238 -
Changed line 62 from:

We are undergoing an OpenSIPS 3.4 Feature Survey (due 17th 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.4 release. Thank you!

to:

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

December 23, 2021, at 01:28 PM by 109.98.32.238 -
Changed line 9 from:

https://blogopensips.files.wordpress.com/2021/12/opensips-3.4-im.jpg

to:

https://blogopensips.files.wordpress.com/2021/12/opensips-3.4-im.jpg

December 23, 2021, at 01:27 PM by 109.98.32.238 -
Changed line 9 from:

https://blogopensips.files.wordpress.com/2020/12/opensips-3.4-cloud.jpg

to:

https://blogopensips.files.wordpress.com/2021/12/opensips-3.4-im.jpg

December 23, 2021, at 01:04 PM by 109.98.32.238 -
Changed line 10 from:

Deploying and running distributed SIP services in various clouds becomes more of a default approach in our days. For this reason, the OpenSIPS 3.4 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.

to:

The instant messaging is evolving and gaining more and more importance. This happens in both worlds of VoIP/ITSP and IMS/M(V)NOs - and the overlapping and mixing of these worlds in increasing by each year. The upcoming OpenSIPS 3.4 is to address more, in depth, the topic of Instant Messaging, in the context of SIP. And this is to be done more two major perspectives: from the Unified Communication perspective, by aligning IM with the voice and presence capabilities in OpenSIPS, and from the IMS perspective, mainly as support/integration with RCS (Rich Communication Services).

Changed lines 17-47 from:

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

to:

Unified Communication

The Instance Messaging support was part of OpenSIPS from the very beginning. Nevertheless, this was limited to the Page Mode (RFC 3428, or the MESSAGE method). With 3.4 version we are looking to enhance the IM capabilities of OpenSIPS by adding IM support for Session Mode, or the Message Session Relay Protocol / MSRP (RFC 4975, RFC 4976). The huge advantage of Session Mode is the fact that you can have deal with IM in a more complex way, session based, or chats; and this enables more IM oriented services to be built, or unified with the audio/video/presence capabilities.

MSRP relay support

The MSRP relaying (RFC 4976) for IM Session Mode is a must for a SIP Server/Proxy for handling MSRP related SIP session. Besides the ability of relaying MSRP traffic, the 3.4 must extend the SDP parsing support to properly handle the MSRP specific SDP extensions. This addition will enable the easy integration of web-based chat services with OpenSIPS (web sites using WSS and MSRP for chat sessions).

MSRP to MESSAGE gateway

As MSRP is not widely supported in the end-user devices, but MESSAGE method is, a way of doing IM translation from Page Mode (MESSAGE method) to Session Mode (MSRP) will be useful. Such a gateway may be used also middle layer for achieving SMS (SMPP) to RCS/MSRP conversion.

OmniChannel Queue (or Contact Center)

The current Call Center module in OpenSIPS supports only SIP calls (as work items in the queue). But with the planned MSRP support, the IM may be supported also. An IM chat, as an MSRP session, may be handled as a new type of work item in the queue. A unified queue (voice and IM) may deliver items (calls or IM sessions) to agents, in the same time. OF course, the queue distribution logic and the agents capabilities/profile will have to be extended in order to support the IM sessions also.

IM chat group

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

Changed lines 36-70 from:

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

Kafka

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

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

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

AWS DynamoDB

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

AWS System Manager (SSM)

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

AWS CloudWatch, SQS, SNS

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

ElasticSearch

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

Secure RTPEngine (NG protocol)

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

Asterisk Integration

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

to:

IMS

OpenSIPS 3.2 made the first steps towards IMS by providing the DIAMETER support. Another part of the broader IP Multimedia Subsystem (IMS), from the IM perspective is RCS. Rich Communication Services (RCS) a protocol between mobile telephone carriers and between phone and carrier, aiming at replacing SMS messages. The RCS gains traction both on the MNO's side (more and more already migrated), but also on the device's side (Android natively support RCS)

RCS / Chat

The Chat service (from RCS), for IM services, mainly relies on SIP and MSRP. In order for OpenSIPS 3.4 to properly implement RCS, several extensions for SIP and MSRP must be implemented/supported, to align to the GSMA specifications over RCC.07 - Rich Communication Suite - Advanced Communications Services and Client Specification, version 11.0. The RCS support in OpenSIPS will make possible scenarios like:

    SIP IM client (non-RCS)   <---SIP--->    OpenSIPS   <---RCS--->   IMS (third-party)   <----RCS--->   mobile device
Deleted lines 50-54:

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.

Changed lines 55-64 from:

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.

to:
Changed lines 62-99 from:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

Poll Results

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

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


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

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


to:

We are undergoing an OpenSIPS 3.4 Feature Survey (due 17th 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.4 release. Thank you!


May 27, 2021, at 11:49 AM by 109.99.227.30 -
Changed line 135 from:
Cluster-5RTP stream re-anchoring3.91done%
to:
Cluster-5RTP stream re-anchoring3.91done
May 27, 2021, at 11:49 AM by 109.99.227.30 -
Changed line 128 from:
Misc-3TLS Support4.42pending
to:
Misc-3TLS Support4.42done
Changed lines 130-131 from:
Misc-2Structured SDP manipulation4.31pending
Cluster-3Clustering more modules4.20pending
to:
Misc-2Structured SDP manipulation4.31no-go
Cluster-3Clustering more modules4.20done
Changed lines 135-137 from:
Cluster-5RTP stream re-anchoring3.91pending
Misc-4MI from script3.81pending
Cloud-9Asterisk Integration3.79pending
to:
Cluster-5RTP stream re-anchoring3.91done%
Misc-4MI from script3.81done
Cloud-9Asterisk Integration3.79no-go
Changed lines 139-143 from:
Cluster-2Distributed Call Center3.40pending
Cloud-7ElasticSearch3.18pending
Cloud-6AWS CloudWatch, SQS, SNS2.92pending
Cloud-2MQTT2.84pending
Cluster-4Multi-level presence subscription2.81pending
to:
Cluster-2Distributed Call Center3.40no-go
Cloud-7ElasticSearch3.18no-go
Cloud-6AWS CloudWatch, SQS, SNS2.92no-go
Cloud-2MQTT2.84no-go
Cluster-4Multi-level presence subscription2.81no-go
Changed lines 145-146 from:
Cloud-4AWS DynamoDB2.75pending
Cloud-5AWS System Manager (SSM)2.62pending
to:
Cloud-4AWS DynamoDB2.75no-go
Cloud-5AWS System Manager (SSM)2.62no-go
May 24, 2021, at 12:42 PM by razvancrainea -
Changed line 133 from:
Misc-5Tracing to log4.13pending
to:
Misc-5Tracing to log4.13done
May 21, 2021, at 12:10 PM by razvancrainea -
Changed lines 80-82 from:

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-8Secure RTPEngine (NG protocol)4.18invalid
to:
Cloud-8Secure RTPEngine (NG protocol)4.18invalid*
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:

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-8Secure RTPEngine (NG protocol)4.18pending
to:
Cloud-8Secure RTPEngine (NG protocol)4.18invalid
April 23, 2021, at 05:43 PM by rvlad_patrascu -
Changed line 129 from:
Cluster-1Clustering Engine4.41pending
to:
Cluster-1Clustering Engine4.41done
March 04, 2021, at 12:02 PM by rvlad_patrascu -
Changed line 144 from:
Cloud-1Kafka2.78pending
to:
Cloud-1Kafka2.78done
February 24, 2021, at 04:45 PM by razvancrainea -
Changed line 138 from:
Cloud-3Prometheus3.78pending
to:
Cloud-3Prometheus3.78done
January 12, 2021, at 05:35 PM by 86.121.186.239 -
Changed line 134 from:
Misc-1Script driven B2B3.95pending
to:
Misc-1Script driven B2B3.95done
January 12, 2021, at 05:33 PM by 86.121.186.239 -
Added lines 116-149:

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.4 progress. Nevertheless, we strongly recommend you to check the Feature list of 3.4.


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


December 23, 2020, at 03:54 PM by 109.99.227.30 -
Changed line 114 from:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

to:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

December 23, 2020, at 03:38 PM by 109.99.227.30 -
Changed lines 9-11 from:

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

to:

https://blogopensips.files.wordpress.com/2020/12/opensips-3.4-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.4 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:

Class 5 calling ingredients

Without actually using a Back2Back model, but simply operating with calls (dialogs, UACs or UASs), many complex class 5 calling (and media bridging) scenarios may be scripted.

Calling API

A new OpenSIPS module, placed on top of dialog module, will allow remote control over the calls going through OpenSIPS. The module will expose a simplified set of commands (API like) for setting up new calls, for answering and terminating calls, for transferring or putting on-hold calls - all these without interacting with the end-devices, but triggering and handling the action only from the OpenSIPS (as proxy) level.

Call media bridging

Another new OpenSIPS module, that is able to manipulate calls/dialogs going through OpenSIPS, along with UAC/UAS dialogs (call originated or terminated into OpenSIPS), with the sole propose of mixing the RTP media between these multiple flows. The idea is to make possible the injection of streams of media from / to proxied calls, with the help of auxiliary calls initiated by OpenSIPS. Typical example is to play media within an existing call/dialog with nothing more than simple re-INVITEs - OpenSIPS will initial a new sip call to a media server, in order to get the RTP stream for the playback and it will push it into the proxied call by triggering in-dialog re-INVITEs. Details about implementation of this feature can be found in the Media Bridging page.

Per-call hooks

As we already have for transactions, the dialog module will allow the script writer to set, in a per-dialog fashion, script routes to be triggered by various dialog events. Similar to t_on_failure(route), you can do dlg_on_timeout(route) to have a route called when the dialog lifetime is exceed. In the route, you may decide to extend the lifetime, to terminate the call or do any other logging. We can foresen dlg_on_answer(route), dlg_on_terminate(route)' (and more) triggers, which will give a better interaction and control over the ongoing calls.

SDP topology hiding

Due to the specificity of class 5 scenarios, there is a real need to completely decouple the SDP's (not only from IP/port perspective) from the caller and callee side, like hiding the originator or overwriting the session name and version.

DTMF support

For both RTProxy and RTPEngine, OpenSIPS will be able to report to the OpenSIPS script the DTMF events sampled from the passing RTP. This will make possible the implementation of simple IVRs and/or authentication via DTMF with nothing more than OpenSIPS and the media relay.

Extended BLF support

In Class 5 services, BLF is an important feature. Besides working out clustering support for BLF, an important task is reworking the BLF implementation to be call-branch aware, to be able to properly report the call events in parallel calling or call hunting scenarios.

Dialog module enhancements

We are looking at a good set of additions for the dialog module, like:

  • improve the way of correlating multiple dialogs, and also to exchange data between calls (like accessing data specific to a call from a totally different call)
  • sending in-dialog requests, crafted from script level
  • better support for UAC or UAS like dialogs (not only proxy like)
to:

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

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:

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

Kafka

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

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

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

AWS DynamoDB

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

AWS System Manager (SSM)

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

AWS CloudWatch, SQS, SNS

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

ElasticSearch

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

Secure RTPEngine (NG protocol)

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

Asterisk Integration

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


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:

Call Center

For 3.4, we are looking at:

  • adding clustering support and data replication for the call queue - this is extremely important for achieving High-Availability.
  • more feature and metrics for managing the call queue
  • distributed call-center or a geo-distributed single call queue which gets calls via different OpenSIPS instances and which distributed agents connected to different OpenSIPS instances.

Device Feature Key Synchronization (DFKS)

DFKS support is planned for OpenSIPS 3.4. This will help to keep feature settings in sync between multiple device and application servers, an essential need in a class 5 / PBX environment.


STIR/SHAKEN

Dealing with Robocalling and CLI spoofing becomes a must when building advanced calling solutions. The support for STIR/SHAKEN will be part of OpenSIPS 3.4, providing multiple usage models, in terms of how the certificates are to be handled during the verification process. Also a flexible approach (to the standards) will be able to cope with all the potential changes derived from the adoption process (of the standard by the providers).


Push Notification (RFC8599)

The existing PN support will be improved and aligned to the requirements as per newly adopted RFC 8599. Besides the notification itself, we need to address some particularities in contact registration, derived from privacy concerns or device identification concerns.


noSQL adds-on

The DB layer needs a constant attention, so here is the plan for 3.4:

  • add support for Dynamo noSQL DB, from Amazon, to improve the experience when comes to running OpenSIPS in AWS cloud.
  • support for raw queries for Cassandra

to:
Changed lines 114-146 from:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

Poll Results

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

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


Feature CodeFeature NameScore (1-5)Implementation Status
Class5-7Dialog module enhancements4.38completed
Class5-1Calling API4.31ongoing
B2B-2Clustering support4.27completed
Class5-3Per-call hooks4.02ongoing
Class5-5DTMF support3.96completed
AF-3Push Notification (RFC8599)3.93completed
B2B-1Script driven B2B3.84no-go
AF-2STIR/SHAKEN3.80completed
Class5-4SDP topology hiding3.76no-go
Class5-2Media Exchange3.75completed
CC-2Geo-distributed Call-Center3.58no-go
B2B-3B2B Context3.52completed
Class5-6Extended BLF support3.48completed
CC-1Call Center clustering3.46no-go
AF-1Device Feature Key Synchronization (DFKS)3.41completed
DB-2Raw queries for Cassandra3.00no-go
DB-1DynamoDB support2.64no-go


to:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

May 25, 2020, at 02:33 PM by 109.99.227.30 -
Changed line 120 from:
B2B-1Script driven B2B3.84pending
to:
B2B-1Script driven B2B3.84no-go
Changed line 122 from:
Class5-4SDP topology hiding3.76pending
to:
Class5-4SDP topology hiding3.76no-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.4 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.4 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.4 release is the star of 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.4 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.4 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-3Per-call hooks4.02pongoing
to:
Class5-3Per-call hooks4.02ongoing
May 14, 2020, at 10:29 AM by 109.98.32.84 -
Changed line 119 from:
Class5-3Per-call hooks4.02pending
to:
Class5-3Per-call hooks4.02pongoing
Changed line 127 from:
B2B-3B2B Context3.52ongoing
to:
B2B-3B2B Context3.52completed
May 07, 2020, at 10:11 AM by liviu -
Changed line 121 from:
AF-3Push Notification (RFC8599)3.93ongoing
to:
AF-3Push Notification (RFC8599)3.93completed
May 05, 2020, at 01:15 PM by 109.99.227.30 -
Changed line 131 from:
DB-2Raw queries for Cassandra3.00pending
to:
DB-2Raw queries for Cassandra3.00no-go
May 05, 2020, at 01:15 PM by 109.99.227.30 -
Changed lines 116-118 from:
Class5-7Dialog module enhancements4.38pending
Class5-1Calling API4.31pending
B2B-2Clustering support4.27ongoing
to:
Class5-7Dialog module enhancements4.38completed
Class5-1Calling API4.31ongoing
B2B-2Clustering support4.27completed
Changed lines 120-121 from:
Class5-5DTMF support3.96done
AF-3Push Notification (RFC8599)3.93ongoing
to:
Class5-5DTMF support3.96completed
AF-3Push Notification (RFC8599)3.93ongoing
Changed line 123 from:
AF-2STIR/SHAKEN3.80done
to:
AF-2STIR/SHAKEN3.80completed
Changed lines 125-130 from:
Class5-2Media Exchange3.75done
CC-2Geo-distributed Call-Center3.58pending
B2B-3B2B Context3.52pending
Class5-6Extended BLF support3.48pending
CC-1Call Center clustering3.46pending
AF-1Device Feature Key Synchronization (DFKS)3.41done
to:
Class5-2Media Exchange3.75completed
CC-2Geo-distributed Call-Center3.58no-go
B2B-3B2B Context3.52ongoing
Class5-6Extended BLF support3.48completed
CC-1Call Center clustering3.46no-go
AF-1Device Feature Key Synchronization (DFKS)3.41completed
Changed line 132 from:
DB-1DynamoDB support2.64pending
to:
DB-1DynamoDB support2.64no-go
March 25, 2020, at 03:14 PM by razvancrainea -
Changed line 121 from:
AF-3Push Notification (RFC8599)3.93ongping
to:
AF-3Push Notification (RFC8599)3.93ongoing
March 25, 2020, at 03:14 PM by razvancrainea -
Changed lines 120-121 from:
Class5-5DTMF support3.96ongoing
AF-3Push Notification (RFC8599)3.93pending
to:
Class5-5DTMF support3.96done
AF-3Push Notification (RFC8599)3.93ongping
Changed line 125 from:
Class5-2Media Exchange3.75ongoing
to:
Class5-2Media Exchange3.75done
March 10, 2020, at 12:02 PM by razvancrainea -
Changed line 120 from:
Class5-5DTMF support3.96pending
to:
Class5-5DTMF support3.96ongoing
March 10, 2020, at 11:42 AM by razvancrainea -
Changed line 118 from:
B2B-2Clustering support4.27pending
to:
B2B-2Clustering support4.27ongoing
March 10, 2020, at 11:34 AM by razvancrainea -
Changed line 125 from:
Class5-2Media Bridging3.75ongoing
to:
Class5-2Media Exchange3.75ongoing
March 10, 2020, at 11:33 AM by razvancrainea -
Changed line 130 from:
AF-1Device Feature Key Synchronization (DFKS)3.41pending
to:
AF-1Device Feature Key Synchronization (DFKS)3.41done
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 Media Bridging page.

February 06, 2020, at 12:51 PM by razvancrainea -
Changed line 123 from:
AF-2STIR/SHAKEN3.80pending
to:
AF-2STIR/SHAKEN3.80done
February 06, 2020, at 12:51 PM by razvancrainea -
Changed line 125 from:
Class5-2Call mixing3.75pending
to:
Class5-2Media Bridging3.75ongoing
January 14, 2020, at 06:33 PM by razvancrainea -
Added lines 106-135:

Poll Results

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

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


Feature CodeFeature NameScore (1-5)Implementation Status
Class5-7Dialog module enhancements4.38pending
Class5-1Calling API4.31pending
B2B-2Clustering support4.27pending
Class5-3Per-call hooks4.02pending
Class5-5DTMF support3.96pending
AF-3Push Notification (RFC8599)3.93pending
B2B-1Script driven B2B3.84pending
AF-2STIR/SHAKEN3.80pending
Class5-4SDP topology hiding3.76pending
Class5-2Call mixing3.75pending
CC-2Geo-distributed Call-Center3.58pending
B2B-3B2B Context3.52pending
Class5-6Extended BLF support3.48pending
CC-1Call Center clustering3.46pending
AF-1Device Feature Key Synchronization (DFKS)3.41pending
DB-2Raw queries for Cassandra3.00pending
DB-1DynamoDB support2.64pending


December 19, 2019, at 07:50 PM by 109.99.227.30 -
Changed line 103 from:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

to:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

December 19, 2019, at 07:39 PM by 109.99.227.30 -
Changed lines 9-15 from:

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

https://blogopensips.files.wordpress.com/2019/12/opensips-3.4-crafting.jpg Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 3.4 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.4 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.4 release is the star of OpenSIPS Summit in Amsterdam, May 2020.

Changed lines 16-27 from:

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

to:

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 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 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 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 diagnose or tracer, as well as to perform DB provisioning. Read a full description of opensips-cli 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 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 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 here.

to:

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

SMPP support

OpenSIPS 3.0 provides a 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 here.

RabbitMQ Consumer support

A new 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:

Call Center

For 3.4, we are looking at:

  • adding clustering support and data replication for the call queue - this is extremely important for achieving High-Availability.
  • more feature and metrics for managing the call queue
  • distributed call-center or a geo-distributed single call queue which gets calls via different OpenSIPS instances and which distributed agents connected to different OpenSIPS instances.

Device Feature Key Synchronization (DFKS)

DFKS support is planned for OpenSIPS 3.4. This will help to keep feature settings in sync between multiple device and application servers, an essential need in a class 5 / PBX environment.


STIR/SHAKEN

Dealing with Robocalling and CLI spoofing becomes a must when building advanced calling solutions. The support for STIR/SHAKEN will be part of OpenSIPS 3.4, providing multiple usage models, in terms of how the certificates are to be handled during the verification process. Also a flexible approach (to the standards) will be able to cope with all the potential changes derived from the adoption process (of the standard by the providers).


Push Notification (RFC8599)

The existing PN support will be improved and aligned to the requirements as per newly adopted RFC 8599. Besides the notification itself, we need to address some particularities in contact registration, derived from privacy concerns or device identification concerns.


noSQL adds-on

The DB layer needs a constant attention, so here is the plan for 3.4:

  • add support for Dynamo noSQL DB, from Amazon, to improve the experience when comes to running OpenSIPS in AWS cloud.
  • support for raw queries for Cassandra

December 19, 2019, at 07:37 PM by 109.99.227.30 -
Changed lines 9-13 from:

https://blogopensips.files.wordpress.com/2018/12/opensips-3.4-icon.png For the upcoming OpenSIPS 3.4 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.4 release, the following areas of development are considered:

to:

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 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. 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, 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 sql caching or the 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 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 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 here.


Changed lines 34-57 from:

Several enhancements and new concepts are planned for OpenSIPS 3.4 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.4 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.4 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 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 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 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 diagnose or tracer, as well as to perform DB provisioning. Read a full description of opensips-cli 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 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 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 here.


Changed lines 70-77 from:

More integration capabilities are to be added to the 3.4 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 here

SMPP support

OpenSIPS 3.0 provides a 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 here.

RabbitMQ Consumer support

A new 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 OpenSIPS 3.4 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.4 release. Thank you!

Poll Results

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

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


Feature CodeFeature NameScore (1-5)Implementation Status
OPS-3Script Reloading4.57in-progress
OPS-9Self-Diagnosis Tool4.26in-progress
OPS-1Auto-Scale the Number of Workers4.25completed
DEV-3Full Variable Support for Functions4.19in-progress
OPS-8Tracing/Traffic Filtering Console4.15in-progress
OPS-2Edit Module Params at Runtime4.10pending
OPS-10Persistent Shared Memory on Restart4.08completed
DEV-5Route entry point per Listener3.80pending
ITG-1Management Interface Rework3.77completed
DEV-6Standard Format for Complex Modparams3.71pending
DEV-1Pluggable Preprocessor3.69completed
OPS-4Separate xlog() Logging Level3.68completed
ITG-3RabbitMQ Consumer Module3.65in-progress
OPS-5Custom xlog() Formatting Prefix3.58completed
OPS-6Selectable Memory Allocator3.48completed
OPS-7Unified Sharing Tags3.41completed
ITG-2SMPP Integration3.46completed
DEV-4Better Naming for Variables3.40pending
DEV-2Script Format Change3.40pending


to:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

April 11, 2019, at 01:20 PM by liviu -
Changed line 100 from:
OPS-6Selectable Memory Allocator3.48completed
to:
OPS-6Selectable Memory Allocator3.48completed
April 05, 2019, at 03:26 PM by liviu -
Changed line 92 from:
OPS-10Persistent Shared Memory on Restart4.08in-progress
to:
OPS-10Persistent Shared Memory on Restart4.08completed
April 05, 2019, at 03:25 PM by liviu -
Changed line 98 from:
ITG-3RabbitMQ Consumer Module3.65pending
to:
ITG-3RabbitMQ Consumer Module3.65in-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.4 progress. Nevertheless, we strongly recommend you to check the Feature list of 3.4.

Changed lines 85-104 from:
Feature CodeFeature NameScore (1-5)
OPS-3Script Reloading4.57
OPS-9Self-Diagnosis Tool4.26
OPS-1Auto-Scale the Number of Workers4.25
DEV-3Full Variable Support for Functions4.19
OPS-8Tracing/Traffic Filtering Console4.15
OPS-2Edit Module Params at Runtime4.10
OPS-10Persistent Shared Memory on Restart4.08
DEV-5Route entry point per Listener3.80
ITG-1Management Interface Rework3.77
DEV-6Standard Format for Complex Modparams3.71
DEV-1Pluggable Preprocessor3.69
OPS-4Separate xlog() Logging Level3.68
ITG-3RabbitMQ Consumer Module3.65
OPS-5Custom xlog() Formatting Prefix3.58
OPS-6Selectable Memory Allocator3.48
OPS-7Unified Sharing Tags3.41
ITG-2SMPP Integration3.46
DEV-4Better Naming for Variables3.40
DEV-2Script Format Change3.40
to:
Feature CodeFeature NameScore (1-5)Implementation Status
OPS-3Script Reloading4.57in-progress
OPS-9Self-Diagnosis Tool4.26in-progress
OPS-1Auto-Scale the Number of Workers4.25completed
DEV-3Full Variable Support for Functions4.19in-progress
OPS-8Tracing/Traffic Filtering Console4.15in-progress
OPS-2Edit Module Params at Runtime4.10pending
OPS-10Persistent Shared Memory on Restart4.08in-progress
DEV-5Route entry point per Listener3.80pending
ITG-1Management Interface Rework3.77completed
DEV-6Standard Format for Complex Modparams3.71pending
DEV-1Pluggable Preprocessor3.69completed
OPS-4Separate xlog() Logging Level3.68completed
ITG-3RabbitMQ Consumer Module3.65pending
OPS-5Custom xlog() Formatting Prefix3.58completed
OPS-6Selectable Memory Allocator3.48completed
OPS-7Unified Sharing Tags3.41completed
ITG-2SMPP Integration3.46completed
DEV-4Better Naming for Variables3.40pending
DEV-2Script Format Change3.40pending
Changed line 106 from:

OpenSIPS 3.4 Feature Survey Results

to:
January 09, 2019, at 12:20 PM by liviu -
Changed lines 74-105 from:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

to:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

Poll Results

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


Feature CodeFeature NameScore (1-5)
OPS-3Script Reloading4.57
OPS-9Self-Diagnosis Tool4.26
OPS-1Auto-Scale the Number of Workers4.25
DEV-3Full Variable Support for Functions4.19
OPS-8Tracing/Traffic Filtering Console4.15
OPS-2Edit Module Params at Runtime4.10
OPS-10Persistent Shared Memory on Restart4.08
DEV-5Route entry point per Listener3.80
ITG-1Management Interface Rework3.77
DEV-6Standard Format for Complex Modparams3.71
DEV-1Pluggable Preprocessor3.69
OPS-4Separate xlog() Logging Level3.68
ITG-3RabbitMQ Consumer Module3.65
OPS-5Custom xlog() Formatting Prefix3.58
OPS-6Selectable Memory Allocator3.48
OPS-7Unified Sharing Tags3.41
ITG-2SMPP Integration3.46
DEV-4Better Naming for Variables3.40
DEV-2Script Format Change3.40

OpenSIPS 3.4 Feature Survey Results

December 13, 2018, at 05:08 PM by 109.99.227.30 -
Changed line 1 from:
to:
December 13, 2018, at 02:16 PM by liviu -
Changed lines 16-17 from:

Want to provide feedback? See below

to:
Added lines 31-32:

Want to provide feedback? See below

Changed lines 35-36 from:

Want to provide feedback? See below

to:
Added lines 58-59:

Want to provide feedback? See below

Deleted line 61:

Want to provide feedback? See 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 below

Added lines 36-37:

Want to provide feedback? See below

Added lines 63-64:

Want to provide feedback? See below

Added line 73:

December 13, 2018, at 02:12 PM by liviu -
Changed line 69 from:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

to:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

December 13, 2018, at 02:09 PM by liviu -
Changed line 69 from:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

to:

We are undergoing an OpenSIPS 3.4 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.4 release. Thank you!

December 13, 2018, at 02:06 PM by liviu -
Changed line 69 from:

We are undergoing an OpenSIPS 3.4 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 OpenSIPS 3.4 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.4 release. Thank you!

December 13, 2018, at 02:05 PM by liviu -
Added line 6:

Added lines 66-69:

Vote your Favorite Features!

We are undergoing an OpenSIPS 3.4 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:

Changed line 30 from:
to:

Added line 55:

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:

https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg

to:

https://blogopensips.files.wordpress.com/2018/12/opensips-3.4-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, 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, 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, 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, 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. 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. 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 sql caching or the 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, 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.4 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.4 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 -> Topics? -> OpenSIPS 3.4 Planning

(:title OpenSIPS 3.4 Planning:)

(:toc-float Table of Content:)


OpenSIPS 3.4 philosophy

https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg For the upcoming OpenSIPS 3.4 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.4 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. 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.4 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.4 release :


Page last modified on May 23, 2023, at 07:45 PM