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

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.

We are undergoing an OpenSIPS 3.6 Feature Survey (due 14th January 2025), 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.6 release. Thank you!

We are undergoing an OpenSIPS 3.6 Feature Survey (due 6th January 2025), 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.6 release. Thank you!

Want to provide feedback? See below

Vote your Favorite Features!

We are undergoing an OpenSIPS 3.6 Feature Survey (due 6th January 2025), 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.6 release. Thank you!

• enhanced REDIS support - add support for Redis Cluster and Redis Stack. With these new extensions, the usrloc federation with Redis backend will become possible (thanks to JSON support in Redis Stack Server). Also the script developers may now query against a Redis Cluster and benefit from data sharding.

• unified branching support - right now, in OpenSIPS, we have two similar branch concepts : (1) the branches as holders for the destinations where a SIP request is to be parallel forked; this support is provided by the OpenSIPS core and again, it is pre-signaling/relaying. And (2) the branches from the TM module for the ongoing transactional branches, where the request was sent out; this is TM provided and is post-sginaling/relaying. Even if the two "branch" concepts have almost a similar data structure, they are not correlated at all. Even more, they are indexed in different ways, so impossible to know which "destination branch" resulted in which "TM branch" (after relaying). Also you cannot do cross branch data access (from one branch to check the info belonging to another branch). The work here aims to unify the two concepts, into a single consistent concept, with continuity between before and after the relaying, with more flexible data access.
• 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.

• SIP message profiling - in a per-message manner, the profiling may be enabled. The profiling data will translate into a list of reports describing the execution of the the SIP message in OpenSIPS - time stamps, internal triggered APIs, executed script routes and functions, various relevant operations - each module may generate such relevant reports to be attached to the message. The profiling data may serve for pure profiling purposes or for troubleshooting both opensips performance or routing logic. The data may be collected via logs, via opensips-cli (runtime collecting) or via HTTP services (like Pyroscope )
• process profiling - in a per-process manner, the profiling will generate a list of reports on the process activity. The idea is to give a better view on what the processes is doing (processing) in a time based manner. The reports will cover events like the change of the processes state - idle (in IO reactor), running/executing or blocked into an I/O operation. Even more, when active, additional information like the nature of the processing will be attached - executing timer jobs, processing a SIP msg or running an async handler. The profiling data will be available via MI commands, either as detailed reports (for a fix time interval), or as aggregated statistics.
• async tracing - the handling of traced data must be asynchronously done. If it comes to storing the trace into DB or to sending the trace via HEP, such operation must be done in async way, in order to have 0 impact over the actual SIP traffic processing. If the tracing/capturing sub-service miss-behave, it must not affect the OpenSIPS overall performance.
• RTP.io - integrated rtpproxy in OpenSIPS. The rtpproxy engine may run as a process, part of OpenSIPS - so an embedded rtp relay. This means the configuring and operation simplifies. Traditionally, OpenSIPS only handles signalling, offloading media operation to the external relay. However in some situations using external relay may be undesirable from system complexity point of view and others, so having an option to handle it internally may be useful.
• dynamic sockets - to this point, OpenSIPS supports only statically defined SIP sockets. IF you need to add more sockets, you need to restart. This is an inconvenient in certain service scenarios, like SBCs or Trunking ones. In such cases, new sockets may have to be added (due to interconnection needs), while restarting is not the best option (due to the high volume of traffic). The dynamic sockets are to be provisioned via database and refresh by OpenSIPS at runtime. Such operation will impact not only the networking side (creating new listeners) but also the pool of workers (new sockets may require new processes to handle the traffic)
• config variables - this will provide database driven configuration options for OpenSIPS. This is an enhanced version of the existing, script implemented support - this new version will provide $config() variables, with caching (from DB) and refreshing options - while all the provisioning of these config options will be done via databases. The caching will support auto-refresh and forced-refresh options.
• AWS integration - for an even smoother integration of OpenSIPS with AWS environment, new AWS services are to be natively supported by OpenSIPS. Here we have the noSQL database DynamoDB and queuing service SQS.
• MSRP over WSS - The MSRP protocol currently support TCP and TLS. Considering the expansion of the RTC area, namely the websocket based services, adding WS(S) transport for MSRP is considered. This will allow implementing MSRP based services into web based SIP clients.

The 3.6 version needs a special attention as (a) it will be an LTS release and (b) it will be the one ending the 3.x series. So, closing the circle with the 3.0 release which started the 3.x series, the 3.6 release will be focused on 'operational improvement'. As a note, 3.0 was focused on DevOps.

The 'operational improvement' translates into introducing and enhancing in OpenSIPS features / capabilities that (1) improve and (2) simplify the operational activities when comes to running and managing OpenSIPS.

Operational aspects

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

• msg backtracing - reports on the msg script execution, steps, timing -> to be sent to profiling server or to logs/troubleshooting (cli ?)
• proc backtracing - idle/run/IO ; asyn,timer,msg, ; etc...
• async HEP
• config variables - replacement for https://blog.opensips.org/2024/10/17/implementing-opensips-realtime-controls-via-control-panel-9-3-5/
• AWS integration - DynamoDB and SQS
• MSRP over WSS
• RTP.io
• dynamic listeners

OpenSIPS scripting

This is about improving the experience of the OpenSIPS script writer (developer), by enhancing and simplifying the OpenSIPS script:

• TM branching -
• SDP manipulation -

• Digest AKA V1 V2 support

To facilitate this exchange of information and ideas between all the IMS-interested parties, we considered adding a new mechanism into the OpenSIPS project, namely the Working Groups - a gathering of people to focus and discuss on a specific topic.\\

The first to be created is the IMS OpenSIPS Working Group (IMS OWG) - the resource here is a dedicated mailing list where people with interest in IMS may join and contribute to the drafting, designing and implementation of the IMS support in OpenSIPS. Of course, anyone is welcome, the list is a self-subscription list. The group will share a GitHUB WIKI resources also. \\

As said, the IMS topic is a very large and complex one. Secondly, one goal here is to design and implement an IMS support that is truly able to provide solutions for the industry. So, a quite extensive stage of exploring, understanding and designing on the IMS ecosystem will be required in a first stage.
In order to guarantee a successful approach, multiple parties must be involved in this stage. Parties coming from the developers side, from the integrator side and, of course, from the solution provider side - shortly, the parties actually using (or planning to use) IMS - must be involved here and contribute to drafting and producing a realistic IMS support to answer the industry needs.

To facilitate this exchange of information and ideas between all the IMS-interested parties, we considered adding a new mechanism into the OpenSIPS project, namely the Working Groups - a gathering of people to focus and discuss on a specific topic.\\

The first to be created is the IMS OpenSIPS Working Group (IMS WG) - the resource here is a dedicated mailing list where people with interest in IMS may join and contribute to the drafting, designing and implementation of the IMS support in OpenSIPS. Of course, anyone is welcome, the list is a self-subscription list. The group will share a GitHUB WIKI resources also. \\

As said, the IMS topic is a vast one and the IMS OpenSIPS Working Group will have the task of exploring and identifying the requirements for OpenSIPS 3.6. Still, we need a starting point, and here we consider for sure the Control Layer, mainly the CSCF with all its components. Again, we are not drawing any borders / limits, just considering some starting points for further discussions.\\

Getting a bit in details, we have a starting wish list for the IMS work, but the actual points to be targeted by the OpenSIPS 3.6 implementation will take shape (and get published) once the IMS OpenSIPS Working Group will produce its requirements.

Bits and pieces of the IMS (IP Multimedia Subsystem) topic were part of the previous OpenSIPS release, but 3.6 aims to fully focus on the IMS part. Considering the traction and need of IMS solutions, we see the implementation of a consistent and large IMS support in OpenSIPS as a mandatory step in order to answer to the needs of the industry.

The IMS topic is a large one, transcending the SIP protocol and the scope of OpenSIPS. So, the OpenSIPS 3.6 will identify and work out the parts of the IMS ecosystem which are based or related to SIP, of course.

To facilitate this exchange of information and idea between all the IMS-interested parties, we considered adding a new mechanism into the OpenSIPS project, namely the Working Groups - a gathering of people to focus and discus on a specific topic.\\

The IMS OpenSIPS WG will shortly start its activity by building a set of requirements for the IMS support in OpenSIPS.

The first to be created is the IMS OpenSIPS Working Group (IMS WG) - the resource here is a dedicated mailing list where people with inters in IMS may join and contribute to the drafting, designing and implementation of the IMS support in OpenSIPS. Of course, anyone is welcome, the list is a self-subscription list. The group will share a GitHUB WIKI resource also. \\

As said, the IMS topic is a wast one and the IMS OpenSIPS Working Group will have the task of exploring and identifying the requirements for OpenSIPS 3.6. Still, we need a starting point, and here we consider for sure the Control Layer, mainly the CSCF with all its components. Again, we are note drawing any borders / limits, just consider some starting points for the further discussions.\\

Getting a bit in details, we have wish-list for the IMS work (again, as starting points), but the actual points to be targeted by the OpenSIPS 3.6 implementation will take shape (and get published) once the IMS OpenSIPS Working Group will produce its requirements.

Some points

• HTTP 2.0 support

As said, the IMS topic is a wast one and the IMS Working Group (IMS WG) will have the task of exploring and identifying the requirements for OpenSIPS 3.6. Still, we need a starting point, and here we consider for sure the Control Layer, mainly the CSCF with all its components. Again, we are note drawing any borders / limits, just consider some starting points for the further discussions.\\

As said, the IMS topic is a wast one and the IMS Working Group (IMS WG) will have the task of exploring and identifying the requirements for OpenSIPS 3.6. Still, we need a starting point, and here we consider for sure the Control Layer, mainly the CSCF with all its components. Again, we are note drawing an\\y borders / limits, just consider some starting points for the further discussions.
Getting a bit in details, we have wish-list for the IMS work (again, as starting points), but the actual points to be targeted by the OpenSIPS 3.6 implementation will take shape (and get published) once the IMS Working Group (IMS WG) will produce its requirements.

https://blogopensips.files.wordpress.com/2023/11/opensips-3.6-ims.jpg

https://blogopensips.files.wordpress.com/2023/11/opensips-3.6-ims-dia.png

CSCF points

• DIAMETER enhancement to be able to read and write raw data into AVPs
• DIAMETER full server side support, to be able to receive and handle at any time an incoming request
• Digest AHA V1 V2 support
• IPSec support for SIP traffic
• IMS related presence events (like "reg")
• HTTPs support

RCS points

• enhanced support for more mimes/content-types
• chat support
• (secure) web socket support for MSRP

The IMS Working Group

To facilitate this exchange of informatin and idea between all the IMS-interested parties, we considered adding a new mechanism into the OpenSIPS project, namely the Working Groups - a gathering of people to focus and discus on a specific topic.

The first to be created is the IMS Working Group (IMS WG) - the resource here is a dedicated mailing list where people with inters in IMS may join and contribute to the drafting, designing and implementation of the IMS support in OpenSIPS. Of course, anyone is welcome, the list is a self-subscription list. The group will share a GitHUB WIKI resource also.

The IMS OpenSIPS WG will shortly starts its activity by building a set of requirements for the IMS support in OpenSIPS.

Starting point

https://blogopensips.files.wordpress.com/2023/11/opensips-3.6-ims-dia.png

As said, the IMS topic is a wast one and the IMS Working Group (IMS WG) will have the task of exploring and identifying the requirements for OpenSIPS 3.6. Still, we need a starting point, and here we consider for sure the Control Layer, mainly the CSCF with all its components. Again, we are note drawing any borders / limits, just consider some starting points for the further discussions.

https://blogopensips.files.wordpress.com/2023/11/opensips-3.6-ims.jpg

Bits and pieces of the IMS (IP Multimedia Subsystem) topic were part of the previous OpenSIPS release, but 3.6 aims to totally focus on the IMS part. Considering the traction and need of IMS solutions, we see the implementation of a consistent and large IMS support in OpenSIPS as a mandatory step in order to answer to the needs of the industry.

The IMS topic is a large one, transcending the SIP protocol and the scope of OpenSIPS. So, the OpenSIPS 3.6 will identify and work out the parts of the IMS ecosystem which are based or related to SIP of course.

Strategy

As said, the IMS topic is a very large and complex one. Secondly, one goal here it to design and implement an IMS support that is truly able to provide solutions for the industry. So, a quite extensive stage of exploring, understanding and designing on the IMS ecosystem will be required in a first stage.
In order to guarantee a successful approach, multiple parties must be involved into this stage. Parties coming from the developers side, from the integrator side and of course from the solution provider side - shortly, the parties actually using (or planning to use) IMS - must be involved here and contributed to drafting and solution a realistic IMS support to answer to the industry needs.

Area of interest

Testing

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

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.

Vote your Favorite Features!

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

GitHub#2908

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.

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

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

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.6 wants to address the consolidation of various past topics, to complete or even expand them. But one of the most important sides of this consolidation process is the testing of OpenSIPS, from the performance and conformity perspective. This testing is a long overdue task that definitely needs to be addressed.

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

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.

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

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.

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.

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.

• 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

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.

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

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

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.

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)

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

The SIP Back-2-Back

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

• re-work the re-bridging sequence to avoid delayed ACK due 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.

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

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

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

\\

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

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.

SIP Outbound support

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

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

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

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.

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.

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)

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.

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

https://blogopensips.files.wordpress.com/2020/12/opensips-3.6-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.6 upcoming release will focus on increasing OpenSIPS's ability to integrate with cloud specific services / backends and it will bring more OpenSIPS capabilities to build distributed (multi PoP/location/DC/zone) SIP services. After all the two concepts, of distributed architecture and in-cloud support, are going hand in hand - the biggest advantage of running in clouds is to possibility to organically scale and distribute.

Clustering or Distributed Support

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

Clustering engine

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

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

Distributed Call Center

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

Clustering more modules

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

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

Multi-level presence subscription

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

RTP stream re-anchoring

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

In-Cloud Integration

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

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

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.

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

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

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.

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.

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

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

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

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)

Back-to-back support

The existing B2B implementation in OpenSIPS has some limitations, so we are looking to overcome via some major rework here.

Script driven B2B

Instead of using the XML scenario to drive the B2B logic (mixing between the calls), we want to use the OpenSIPS scripting for this purpose. This will eliminate all the limitations of the XML language (logic and action) and it will tremendously increase the level of integration of the B2B engine with the rest of the OpenSIPS functionalities. Shortly, more complex B2B logic will be possible, and also better integrated with the rest of OpenSIPS.

B2B clustering support

To be 100% production ready, an High-Availability support maybe available for the B2B engine. This will be achieved by adding clustering and replication support for the B2B calling.

B2B context

An important improvement of the B2B engine will be the addition of the B2B context, to help in correlating all the entities (UAC, UAS) part of a B2B session, to attach custom data to the entities and to exchange such data between the entities. This will help with Accounting and media relaying support for B2B, but also with building custom data sharing inside a B2B session (or between the sessions).

Call Center

For 3.6, 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.6. 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.6, 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.6:

• 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

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.

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.

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.

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.

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

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

We are undergoing an OpenSIPS 3.6 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.6 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.

OpenSIPS 3.6 Feature Survey Results

Development -> Planning -> OpenSIPS 3.6 Planning

Want to provide feedback? See below

Want to provide feedback? See below

Want to provide feedback? See below

Want to provide feedback? See below

Want to provide feedback? See below

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

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

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

Vote your Favorite Features!

We are undergoing an OpenSIPS 3.6 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!

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

• 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

Script Development aspects

Operational aspects

Integration aspects

• 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 :) ?

Integration area

• 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 :) ?

https://blogopensips.files.wordpress.com/2018/12/opensips-3.6-icon.png

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

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

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

• 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 :) ?

• 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)

• 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

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

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

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

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

• '''script

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

Development -> Topics? -> OpenSIPS 3.6 Planning

(:title OpenSIPS 3.6 Planning:)

(:toc-float Table of Content:)

OpenSIPS 3.6 philosophy

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