About |
About.Version-Overview-2-4-0 HistoryHide minor edits - Show changes to markup March 28, 2018, at 08:09 PM
by
- Changed lines 77-81 from:
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.\\ to:
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. Pinging LatencyStarting 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). \\ March 28, 2018, at 07:24 PM
by
- Deleted line 21:
The clustering engineChanged lines 23-28 from:
The OpenSIPS 2.4 clustering engine was completely reworked in order to address needs as:
For a detailed description of the clustering engine capabilities, please see the blog post. to:
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. March 28, 2018, at 07:18 PM
by
- Changed line 59 from:
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 [[https://blog.opensips.org/2018/03/27/clustering-presence-services-with-opensips-2-4/|original release post]|. to:
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. Changed lines 83-86 from:
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. to:
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. March 28, 2018, at 07:17 PM
by
- Changed lines 70-71 from:
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 [[https://blog.opensips.org/2018/01/17/how-to-script-advanced-freeswitch-integrations-with-opensips-2-4/|here]. to:
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. Changed line 85 from:
Find the full list of available load statistics (and their description) here. to:
March 28, 2018, at 07:16 PM
by
- Changed lines 38-42 from:
The module offers four pre-defined clustering modes that covers scenarios like:
to:
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.\\ Changed lines 59-64 from:
Several clustering scenarios are possible with the presence module:
More details on the presence clustering and how to implement the above scenarios are to be found in this [[https://blog.opensips.org/2018/03/27/clustering-presence-services-with-opensips-2-4/|original release post]. to:
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 [[https://blog.opensips.org/2018/03/27/clustering-presence-services-with-opensips-2-4/|original release post]|. Changed lines 64-66 from:
There is a long list of thinks that were added or improved in OpenSIPS 2.4, and sticking to the most relevant ones, we need to mention: to:
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 recordingSIPREC 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 IntegrationWe 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 [[https://blog.opensips.org/2018/01/17/how-to-script-advanced-freeswitch-integrations-with-opensips-2-4/|here]. JSON RPC supportThe 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 betterThere are two important enhancements into the RTPengine module in OpenSIPS 2.4:
Internal Load statisticsOpenSIPS 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. Find the full list of available load statistics (and their description) here. March 28, 2018, at 06:42 PM
by
- Changed lines 18-19 from:
to:
Changed lines 30-31 from:
to:
Changed lines 44-45 from:
to:
Changed lines 51-52 from:
to:
Changed lines 57-67 from:
to:
Clustering Presence ServicesBy 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:
More details on the presence clustering and how to implement the above scenarios are to be found in this [[https://blog.opensips.org/2018/03/27/clustering-presence-services-with-opensips-2-4/|original release post]. March 28, 2018, at 06:29 PM
by
- Deleted line 13:
For the OpenSIPS 2.4 we laid down a roadmap that addressed the clustering both from the clustering engine itself (the underlayer) and from the functionalities that will perform on top of the clustering layer, to share data and state, to synchronize and correlate. Changed lines 15-16 from:
This OpenSIPS 2.4 release is the star of OpenSIPS Summit in Amsterdam, May 2018 - beside presentations and workshops around the new cool things in this version, OpenSIPS 2.4 will also be the subject of several interactive demos on its clustering capabilities. to:
For the OpenSIPS 2.4 we laid down a roadmap that addressed the clustering both from the clustering engine itself (the underlayer) and from the functionalities that will perform on top of the clustering layer, to share data and state, to synchronize and correlate. Changed lines 21-29 from:
SIPCapture/Homer integrationFreeSWITCH integrationAs a powerful Class5 Engine, FreeSWITCH is the perfect complementary tool for OpenSIPS the restto:
The clustering engineBefore 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 needs as:
For a detailed description of the clustering engine capabilities, please see the blog post. Clustering User RegistrationsThis 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 four pre-defined clustering modes that covers scenarios like:
This topic is more in depth covered in this recent blog post. Anycast supportA 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 CallsIn 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. March 28, 2018, at 05:41 PM
by
- Changed lines 14-16 from:
to:
For the OpenSIPS 2.4 we laid down a roadmap that addressed the clustering both from the clustering engine itself (the underlayer) and from the functionalities that will perform on top of the clustering layer, to share data and state, to synchronize and correlate.
March 28, 2018, at 05:38 PM
by
- Changed line 8 from:
https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg?w=300&h=200 to:
https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg March 28, 2018, at 05:38 PM
by
- Changed line 8 from:
https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg?w=300&h=200 to:
https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg?w=300&h=200 Changed lines 29-30 from:
to:
And more on OpenSIPS 2.4There is a long list of thinks that were added or improved in OpenSIPS 2.4, and sticking to the most relevant ones, we need to mention: But the full list of goodies offered by OpenSIPS 2.4 (and a more technical one too), together with migration instructions, can be found on the OpenSIPS 2.4 release notes page. March 28, 2018, at 05:33 PM
by
- Changed lines 8-15 from:
http://www.gearitservices.com/Portals/0/SitePics/SystemIntegration.jpg
The OpenSIPS 2.4 version is built around the integration concept - the OpenSIPS ability to integrate and work together in all possible means with other projects, protocols, systems or concepts. to:
https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg?w=300&h=200 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:
Changed lines 20-23 from:
The integration with the SIPCapture engine was a hot topic again. The work in this area focused in adding two new concepts (both on OpenSIPS and SIPCapture sides) when comes to capturing:
to:
Changed line 25 from:
the restto:
the restMarch 16, 2017, at 06:49 PM
by
- Changed lines 13-19 from:
The success of this release - in terms of achieving its integration goal - was strongly weighted by the collaboration with the teams of the partner projects, like SIPCapture, FreeSWITCH or CGRates. A collaboration in terms of ideas, brainstorming, solutions and of course, work. A collaboration that Integrationto:
The success of this release - in terms of achieving its integration goal - was strongly weighted by the collaboration with the teams of the partner projects, like SIPCapture, FreeSWITCH or CGRates. A collaboration in terms of ideas, brainstorming, solutions and of course, work. A collaboration that resulted in solutions and benefits for all the involved communities. The best ofSIPCapture/Homer integrationThe integration with the SIPCapture engine was a hot topic again. The work in this area focused in adding two new concepts (both on OpenSIPS and SIPCapture sides) when comes to capturing:
FreeSWITCH integrationAs a powerful Class5 Engine, FreeSWITCH is the perfect complementary tool for OpenSIPS Added lines 29-30:
March 16, 2017, at 06:33 PM
by
- Added lines 1-25:
About -> Available Versions -> 2.4.x Releases -> Release 2.4.0 OverviewOpenSIPS 2.4 philosophy http://www.gearitservices.com/Portals/0/SitePics/SystemIntegration.jpg
The OpenSIPS 2.4 version is built around the integration concept - the OpenSIPS ability to integrate and work together in all possible means with other projects, protocols, systems or concepts. Integrationthe restMigration from 2.2.x to 2.4.0? |