About |
About.Version-Overview-3-0-0 HistoryHide minor edits - Show changes to markup April 17, 2019, at 08:40 AM
by
- Changed line 55 from:
As there are several modules caching (in OpenSIPS internal memory, not in external no-sql cachers) large chunks of data, like Dynamic Routing, Dialplan, Dispatcher or Permissions, OpenSIPS 3.0 is able to avoid the date loading and caching penalty during a restart - this segments of the internal memory do "survive" during the restart. This dramatically reduces the time to restart of the entire service. \\ to:
As there are several modules caching (in OpenSIPS internal memory, not in external no-sql cachers) large chunks of data, like Dynamic Routing, Dialplan, Dispatcher or Permissions, OpenSIPS 3.0 is able to avoid the data loading and caching penalty during a restart - this segments of the internal memory do "survive" during the restart. This dramatically reduces the time to restart of the entire service. \\ Changed line 79 from:
A new RabbitMQ consumer module which manages connections with one or more brokers, subscribes for events and exports them at OpenSIPS script level via the event interface. to:
A new RabbitMQ consumer module which manages connections with one or more brokers, subscribes for events and propagates them at OpenSIPS script level via the event interface. April 16, 2019, at 09:52 PM
by
- Changed line 5 from:
to:
Changed lines 8-31 from:
https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg?w=300&h=200 The OpenSIPS 3.0 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 ofSIPCapture/Homer integrationFreeSWITCH integrationAs a powerful Class5 Engine, FreeSWITCH is the perfect complementary tool for OpenSIPS the restMigration from 2.2.x to 3.0.0?to:
https://blogopensips.files.wordpress.com/2018/12/opensips-3.0-icon.png 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. This OpenSIPS 3.0 release is the star of OpenSIPS Summit in Amsterdam, April-May 2019 - beside presentations and workshops around the new cool things in this version, OpenSIPS 3.0 will also be the subject of several interactive demos on its new capabilities. Added lines 16-88:
Script Development aspectsGeneric Preprocessor SupportThis feature adds full built-in pre-processing support for the OpenSIPS script. OpenSIPS 3.0 integrates various existing pre-processors within OpenSIPS. This 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). Module Functions Now Benefit From a New Parameter InterfaceAs a response to frequent mailing list complaints of wildly varying behaviors across different module functions (e.g. some accept integers/strings as inputs while others accept both integers/strings or variables holding such values), we've introduced an abstract layer which handles the parameter passing task for all module functions, effectively making all of them more powerful by globally allowing flexible input. An added benefit is that new OpenSIPS modules are now even faster to develop. See the new function calling conventions here. Operational aspectsRouting Script Re-loadOpenSIPS 3.0 exposes the valuable ability of reloading the routes (not the module configuration) during runtime, with zero penalties and with zero loses as traffic. See the documentation of the MI "reload_routes" function. Processes Auto-Scaling SupportThis is the ability of OpenSIPS to scale up and down the number of processes at runtime. Basically OpenSIPS is 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). New OpenSIPS CLI (Command Line Interface) toolStarting with OpenSIPS 3.0, the old opensipsctl tool becomes deprecated (as functionality and as software) and it is replaced by the new opensips-cli - a powerful Python3 application that allows you to interact in a smart way with OpenSIPS, to invoke advanced tools such as diagnose or tracer, as well as to perform DB provisioning. Read a full description of opensips-cli here. Selectable Memory Allocator SupportThis feature allows the internal memory manager to be selected at startup time. In OpenSIPS 3.0, the memory manager selection becomes a startup option, via command line arguments, allowing you to change it without any need to recompile or redeploy. Read a full description of this feature here. Internal Memory Persistence during RestartAs there are several modules caching (in OpenSIPS internal memory, not in external no-sql cachers) large chunks of data, like Dynamic Routing, Dialplan, Dispatcher or Permissions, OpenSIPS 3.0 is able to avoid the date loading and caching penalty during a restart - this segments of the internal memory do "survive" during the restart. This dramatically reduces the time to restart of the entire service. Unified Sharing Tags for ClusteringIn 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 OpenSIPS 3.0 we have now 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) Read a full description of this feature here. Integration aspectsMI Interaction StandardizationAn extensive rework of the Management Interface in an attempt to standardize and speed up development of external applications which need to interact with OpenSIPS. The custom, JSON-based HTTP calls of OpenSIPS 2.X are now replaced with the JSON-RPC version 2 standard. The custom, line-oriented syntax was completely dropped. XMLRPC and mi_html (former mi_http) were kept backwards-compatible. Read a detailed description of the new interactions here SMPP supportOpenSIPS 3.0 provides a new SMPP module that allows you to do bidirectional gatewaying between SIP and SMPP traffic - this is a powerful but flexible way to integrate with most of the SMS providers / gateways. Read a full description of this feature here. RabbitMQ Consumer supportA new RabbitMQ consumer module which manages connections with one or more brokers, subscribes for events and exports them at OpenSIPS script level via the event interface.
But the full list of goodies offered by OpenSIPS 3.0 (and a more technical one too), together with migration instructions, can be found on the OpenSIPS 3.0 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 3.0 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 3.0 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 -> 3.0.x Releases -> Release 3.0.0 OverviewOpenSIPS 3.0 philosophy http://www.gearitservices.com/Portals/0/SitePics/SystemIntegration.jpg
The OpenSIPS 3.0 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 3.0.0? |