About -> Available Versions -> 2.4.x Releases -> Release 2.4.0 Overview
OpenSIPS 2.4 philosophy
The OpenSIPS 2.4 version is built around the clustering concept - today’s VoIP world is getting more and more dynamic, services are moving into Clouds and more and more flexibility is needed for the application to fully exploit such environments. But let’s pin point the main reasons for going for a clustered approach:
The best of
Before even thinking of building clustering support for high level services like User Location, Dialog Tracking or SIP Presence, it is mandatory to have in place a powerful and flexible clustering engine. Such an engine will become the reliable foundation for approaching more complex clustering scenarios. The OpenSIPS 2.4 clustering engine was completely reworked in order to address more needs at topology layer (more dynamic), at capabilities layer (more flexible) and at application layer (as full data sync’ing and action partitioning support). For a detailed description of the clustering engine capabilities, please see the blog post.
Clustering User Registrations
This is a very complex topic as it exceeds the simple concept of data sharing. By the nature of the data (the user registrations), you may have different constraints on how data is roaming in a cluster – registrations may be tied to a node due network constraints.
The module offers pre-defined clustering modes that covers scenarios like active-backup High Availability, multi-active Load Balancing, geo-distributed federation and data partitioning for scaling.
A common Anycast setup is to assign the anycast IPs to the nodes at the edge of your platform, facing the clients. This setup ensures that all three features (load balancing, geo-distribution and high-availability) are provided for your customers’ inbound calls. To be able to build a fully-flavored anycast support (addressing both redundancy and balancing), it requires OpenSIPS to replicate/share transaction state across the nodes in the cluster (nodes sharing the same anycast IP).
Clustering Ongoing Calls
In order to fully cluster the dialog (ongoing calls) you need more the simple data replication. First you need full data sharing - that means the ability to bulk replicate the entire data set, at any moment, between the nodes. A freshly started node will get synchronized (in terms of ongoing calls) in no time, being ready to handle traffic on the spot.
Clustering Presence Services
By using the clustering engine, the presence module provides new ways of distributing and correlating the presence data:
Several clustering scenarios are possible with the presence module, to address High Availability, Load Balancing and Geo-distribution. More details on the presence clustering and how to implement the above scenarios are to be found in this original release post.
And more on OpenSIPS 2.4
There is a long list of things that were added or improved in OpenSIPS 2.4, but sticking to the most relevant ones, we need to mention some.
SIPREC based call recording
SIPREC is an IETF standard that describes how to do call recording to an external recorder. It contains specifications about how to send both call metadata and RTP streams to the recorder in a send-only mode, without any impact on the ongoing call.The SIPREC module in OpenSIPS implements this protocol, offering the ability to do call recording for any call that is proxied through it. Being a standard, it can be used to integrate OpenSIPS with any call recorder that implements the protocol, like the Oreka OSS recorder. See more here.
Scripting Advanced FreeSWITCH Integration
We wanted to go beyond a simple load balancing driven integration, and actually offer to the OpenSIPS script writer the power to work with bi-directional, generic communication primitives between OpenSIPS and the FreeSWITCH ESL: (a) subscribe to generic FreeSWITCH events via DB, MI or modparam, (b) catch and manipulate FreeSWITCH event information within an event_route and (c) run a FreeSWITCH ESL command on any FreeSWITCH node, from any route. All the details can be found here.
JSON RPC support
The new EVENT_JSONRPC module in OpenSIPS 2.4 implements a transport protocol for the OpenSIPS Event Interface. Using this module, you can notify applications about OpenSIPS internal events using the JSON-RPC protocol.
RTPEngine gets better
There are two important enhancements into the RTPengine module in OpenSIPS 2.4:
Internal Load statistics
OpenSIPS 2.4 comes with a complete re-design of the statistics that gives information about the OpenSIPS internal load. The load is defined as percentage of time spent in doing processing versus total time. Following the model of "top", there are three load values, calculated over different periods of time : (a) realtime, (b) last minute and (c) last 10 minutes. The load can be accessed per process, per OpenSIPS core (covering only core/SIP processes) and per entire OpenSIPS (covering all processes, core and modules). See the full list here.
Starting with OpenSIPS 2.3, using the nathelper module, you could keep track of the send pings and detect the disconnected and points. Taking a step further, the OpenSIPS 2.4 can calculate the ping latency and use this information in multiple ways. For example it can fire an event whenever the latency variation exceeded a given threshold ; or you instruct lookup(location) to skip contact having the latency above a given threshold or to order the contacts based on their latency (versus Q or time ordering).