Development -> Planning -> OpenSIPS 3.0 Planning

OpenSIPS 3.0 philosophy

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.

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

Script Development aspects

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

Operational aspects

Several enhancements and new concepts are planned for OpenSIPS 3.0 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.0 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.0 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

Integration aspects

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

Vote your Favorite Features!

We are undergoing an OpenSIPS 3.0 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.0 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.0.