Development -> Planning -> OpenSIPS 3.6 Planning

OpenSIPS 3.6 philosophy

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:

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

Want to provide feedback? See below

OpenSIPS scripting

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

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

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!