About -> Available Versions -> 3.4.x Releases -> Release 3.4.0 Overview

OpenSIPS 3.4 philosophy

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 OpenSIPS 3.4 addressed 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 was a long overdue task that definitely needs to be addressed.

Testing

The testing, in vary ways, was an important component of the 3.4 release. This was a bit of an overdue topic for OpenSIPS, so here the decision to address it. The goal here was to ensure that OpenSIPs works correctly and performs as fast as expected. For each type of test (performance and conformity) we worked out the full spectrum, from having the right tools in place, up to the methodologies and mechanisms to ensure a continuous and automatic process of testing.

Conformity testing

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.
How did we address this? By creating SIPssert - this is a conformance testing framework that provides various instruments for building and running conformity tests for VoIP-based platforms. It provides a very simple but generic way of provisioning tests for various types of components and scenarios within a system, orchestrate their execution and provide easy means of troubleshooting in case of failure. Its goal is to ensure that OpenSIPS, as well as the other components within a VoIP system perform correctly as a whole by running a set of tests (consisting of all its steps: initialization/provisioning, running the components, testing and finally cleanup) and validating they behave properly.
There is here a very detailed introduction of the SIPssert testing engine, but also a documentation of the steps we did so far into using SIPssert for testing OpenSIPS.
We do expect here, with the contribution of the community, to build a quite large and covering set of tests for OpenSIPS.

Performance testing

The performance testing had two goals in mind :

1. get some benchmark numbers, as throughput
2. identify potential bottlenecks in the code

So we build a testing environment and start creating incremental testes with different configurations, while measuring the capacity (as calls per second) and collecting profiling data. The end results are that we do have now some numbers for the processing capacity of OpenSIPS, we do better understand the performance degradation due to configuration complexity and we do have a certainty that no skeletons are deep hidden in the OpenSIPS code. Not to mention a very important aspect of these tests - some bugs were found and fixed, and some code got optimized. A comprehensive description of the results, their interpretation and conclusions are described in a dedicated blog post.
The information on the testing setup, the configurations and scripts are all available, so anyone can use them in order to do his own testing.
What we plan here is to go even further with more scenarios to be benchmark'ed, like presence related features or how re-transmissions impacts the overall OpenSIPS performance.

B2B enhancements

The B2B capabilities in OpenSIPS got a more and more attention lately, so OpenSIPS 3.4 got some significant work in the area.

B2B bridging

The 3.4 released focused on addressing some flaws and limitations in the core B2B mechanisms, limitations that needed to be addressed. The number one was here to fix the way a SIP entity from an ongoing B2B session is re-bridged with a new participant. Previous version had issues with delayed ACK'ed leading to call dropping, or issues with no media during a call bridge ringing. Another issue that was addressed in 3.4 the limitation of the logic of the initial bridging in order to allow easy (as B2B logic level) handling of failover (if callee does not answer) - previously this is not supported, if initial callee did not answer, the whole call died.
The detailed explanation of the issues, along with the solutions to fix them, are covered by this blog post.

API driven SIP User-Agent

While OpenSIPS is mainly a SIP proxy, the SIP Back-2-Back capabilities have been supported for a while. But recently we felt the need for a “end user agent” support in OpenSIPS. Meaning the ability to create and control a Server / Client SIP User Agent, doing all the SIP magic (transactional and dialog level) transparently for you.
So OpenSIPS 3.4 now offers the ability to act as a mixed (SIP and non-SIP) back-to-back, with a User-Agent entity (server or client) on one side and some custom logic on the other side, API controlling what how the SIP side should behave.
This feature opens a lot of door for external integration of OpenSIPS or even for building external logic for Application Servers, while having OpenSIPS as the SIP stack.
More on how this work, with descriptions, scenarios being explained and schematics are presented by this blog post.

Logging

Somehow a last minute addition to OpenSIPS 3.4 is the enhancement on the OpenSIPS logging abilities. If so far we had text plain logging to syslog or stderr, the 3.4 brings in some radical changes :

• the produced logs may be consumed via vary "backend"s , like syslog, stderr, events and other in the future (like RMQ, Kafka, flatstore)
• the logs may be consumed by multiple backends in the same time, each backend having some verbosity filter (like to consume logs only above a certain log level)
• the logs may be formatted (whatever the backend/consumer is) as plain/text, json or CEE specific.

New core parameters were added to enable vary logging backends; also new MI commands allow you at runtime to mute/unmute a certain logging backend/consumer.
So setups like "send all longs to text/plain syslog, but ones with level above ERR to be sent in CEE format vai Kafka" are now possible. Alos json formatted logs to syslog? Not a problem.

Miscellaneous but important

More friendly flags for script functions

The ugly and unfriendly hexa flags were replaces with token based flags in CSV format. Functions like nat_uac_test() are now "readable - instead of nat_uac_test("7"), you have now nat_uac_test("private-contact,diff-ip-src-via,private-via") - nicer, isn't it?
Several function from nathelper, TM or b2b module got this kind of improvement.

Delay in deleting dialogs

This was a feature that have being asked for years - the ability of the dialog to keep in memory the terminated dialogs for a while, before trashing them. Why? There are cases where late in-dialog signalling happens, maybe cross BYE-ing or similar case - so, even if the dialog was terminated, OpenSIPS should still have the ability to pass the in-dialog requests between the parties - and if using topo-hiding with dialog, you cannot do this without still having the dialog data in memory .

SIP probing / pinging

The way the probing is done in the Dynamic Routing, Dispatcher and Load-Balancer modules was improved, so the large number of destinations to be probed will have 0 impact on the routing data (using or reloading it) - this is especially valid when talking about SIP over TCP, with delays and timeouts :(.

Route-reload re-work

Full re-engineering of how references (from outside the script) to script routes are kept by modules (modparams or function params) in order to solve some systemic issues of the existing reload_routes MI command. The new version is able to cope with any changes in the routes (their order, adding, removing, their content). This applies to the Timer Routes too which may be also fully altered.

Blacklists improvements

The blacklist support provided by core is now more flexible, to allow you, from script level, to dynamically manage the lists.

All

There are many many other changes with this release, and you can read about all of them in this detailed listing.