This topic is more in depth covered in this recent blog post.

• non-SIP tracing - if up to this point, all the tracing was SIP-centric, now you can capture and visualize more types of data. You can capture information from transport layer (TCP, TLS, WS, WSS), information on the REST queries you performed from OpenSIPS script, information about the MI commands and also the script logs. All this information will help you (from operational perspective) to have a global view over how your OpenSIPS is doing (and lot limited to the SIP level only) - in other words, monitoring and troubleshooting will become much easier.
• data correlation - now that you have so many types of traced data, it is vital to be able to correlate them - to know what were the TCP/TLS/WSS connections involved in a SIP call, to know which were the REST queries or logs triggered by some call handling. The correlation concept gives a new dimension to tracing - you can navigate and jump between different data types in order to understand the relation between them (e.g. why a SIP call failed by looking at the data from the transport level)

• Mid-Registrar capability - or how an OpenSIPS frontend can offload and help FreeSWITCH with REGISTER traffic processing. While still having FreeSWITCH as main registrar, OpenSIPS can prolong the registration sessions or can aggregate all the registration for the same AOR/subscriber. More details on these capabilities are provided in this excellent blog post and tutorial

• new XML aware holder to be used from the OpenSIPS script. Similar to the $json variable, OpenSIPS 2.3 brings the $xml variable that gives you an easy way to work with XML data at script level- see more here.

• an improved REST client that now also supports HTTP PUT requests. Also, the client is now more efficient as well, as it is using an internal pool of connections.

\\

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.
This OpenSIPS 2.3 release is the star of OpenSIPS Summit in Amsterdam, May 2017 - beside presentations and workshops around the new cool things in this version, OpenSIPS 2.3 will also reach its maturity / General Availability during this event.

And more on OpenSIPS 2.3

But the full list of goodies offered by OpenSIPS 2.3 (and a more technical one too), together with migration instructions, can be found on the OpenSIPS 2.3 release notes page.

http://opensips.org/pub/images/SystemIntegration.jpg

• an improved multi-leg accounting to ensure a reliable and simple to use accounting for SIP multi-leg calls. The old hackish usage of AVP variables was dropped and replaced by dedicated variables like $acc_leg - see more here.
• an enhanced media integration when comes to RTPproxy and RTPengine media relays for more exposer of the capabilities offered by the new versions of these engine (recording, Music On Hold , and more)
• an improved REST client that now supports PUT HTTP mechanism too. Also, the client is now more efficient also, as it is using an internal pool of connections.

\\

But the full list of goodies offered by OpenSIPS 2.3 (and a more technical one too) can be found on the [[About.Version-2-3-0|

---

The Headlines of OpenSIPS 2.3

• Mid-Registrar capability - or how an OpenSIPS frontend can offload and help FreeSWITCH when comes the REGISTER traffic processing. While still having FreeSWITCH as main registrar, OpenSIPS can prolong the registration sessions or can aggregate all the registration for the same AOR/subscriber. More details on these capabilities are provided in this excellent blog post and tutorial

---

And more on OpenSIPS 2.3

There is a long list of thinks that were added or improved in OpenSIPS 2.3, and sticking to the most relevant ones, we need to mention:

• new RAbbitMQ support for pushing directly from OpenSIPS script RMQ messages, in a flexible and custom way ; you have full control over when to do it, what information is to be filled in the message and how the message will be structured - see more here.
• new XML aware variables to be used from the OpenSIPS script. Similar to the $json variables, OpenSIPS 2.3 brings the $xml variables that gives you an easy way to work with XML data at script level- see more here.
• an extended async support at script level by the addition of the launch() directive to allow you to spin-off extra processings (without holding or blocking the current execution). This is a very useful tool when you want to push some heavy I/O operation from script, but without the need to wait for them.
• an improved multi-leg accounting to ensure a reliable and simple to use accounting for SIP multi-leg calls. The old hackish usage of AVP variables was dropped and replaced by dedicated variables like $acc_leg -

A detailed blog post covers the problems related to SIP-I and how OpenSIPS 2.3 is addressing them, in order to be able to terminate to your SIP end-points the traffic originated via SIP-I trunks.

Event-based Routing

Event-based Routing

The Event-based Routing engine is a new tool that allows you to implement more complex SIP scenarios by mixing multiple and various elements (calls, registrations, RTP events, B2B sessions) that are involved and correlated at different moments in time. And some examples of such scenarios:

• Push Notification (call and registration correlation)
• Call Pickup (2 calls correlation)
• DMTF/IVR call driving (call and RTP correlation)

The EBR engine is the way of performing SIP routing based on events (generated by the Event Interface). And this is a new mechanism provided by OpenSIPS 2.3 to address the complex processing problems. More details on EBR engine and how to use it for implementing a Push-Notification scenario may be found in this original release post.

SIP without billing is like a dinner without a good wine. While OpenSIPS does a great job for SIP, it often needs a billing partner to work with. CGRates is an open-source rating engine used for carrier-grade, multi-tenant, real-time billing. It is able to do both postpaid and prepaid rating for multiple concurrent sessions with different balance units (eg: Monetary, SMS, Internet Traffic). CGRateS can also export accurate CDRs in various formats.\\

SIP-I integration

Or how to do SIP-I to SIP translation or ISUP inspection. The SS7 interconnections are always painful. Both as cost and technical difficulty/complexity. So, as a more accessible alternative, the carriers started to offer SIP interconnection via SIP-I (SIP Infrastructure). SIP-I or SIP Infrastructure (define by ITU) is very similar to SIP-T or SIP for Telephones (defined by IEFT).
A detailed blog post covers the problems related to SIP-I and how OpenSIPS 2.3 is addressing them, in order to be able to terminate to your SIP end-points the traffic originated via SIP-I trunks.

CGRates Billing integration

SIP without billing is like a dinner without a good wine. While OpenSIPS does a great job for SIP, it often needs a billing partner to work with. CGRates is an open-source rating engine used for carrier-grade, multi-tenant, real-time billing. It is able to do both postpaid and prepaid rating for multiple concurrent sessions with different balance units (eg: Monetary, SMS, Internet Traffic). CGRateS can also export accurate CDRs in various formats.
Even if a very primitive and rudimentary integration with CGRates was possible with the older OpenSIPS versions, now, with OpenSIPS 2.3, thanks to the CGRates team, there is a built-in integration support available - this exposes all the powerful billing capabilities of CGRates, with a very simple and efficient usage from OpenSIPS side , as it is shown in this blog post.

As a powerful Class5 Engine, FreeSWITCH is the perfect complementary tool for OpenSIPS. Based on the collaboration with the FreeSWITCH team, several integration capabilities found their way in OpenSIPS 2.3:

• Mid-Registrar capability - or how an OpenSIPS frontend can offload and help FreeSWITCH when comes the REGISTER traffic processing. While still having FreeSWITCH as main registrar, OpenSIPS can prolong the registration sessions or can aggregate all the registration for the same AOR/subscriber. More details on this capabilities are provided in this excellent blog post
• FreeSWITCH-driven load balancing - or how OpenSIPS can get load feedback from FreeSWITCH in order to do accurate load-balancing over a cluster of FreeSWITCH servers. The capacity of FreeSWITCH may be affected by traffic not visible to OpenSIPS or by other applications running on the same machine - so, OpenSIPS by itself (as in the previous versions) cannot have a realistic view over the FreeSWITCH load. Again, how this integration works, what are the benefits and how to do it, is covered by this blog post.

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 of

SIPCapture/Homer integration

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:

• non-SIP tracing - if up to this point, all the tracing was SIP-centric, now you can capture and visualize more types of data. You can capture information from transport layer (TCP, TLS, WS, WSS), information on the REST queries you performed from OpenSIPS script, information about the MI commands and also the script logs. All this information will help you (from operational perspective) to have a global view over how your OpenSIPS is doing (and lot limited to the SIP level only) - in other words, monitoring and troubleshooting will became much easier.
• data correlation - now that you have so many types of data traced, it is vital to be able to correlate them - to know what were the TCP/TLS/WSS connections involved in a SIP call, to know which were the REST queries or logs triggered by a call handling. Such correlation concept gives a new dimension to the tracing concept - you can navigate and jump between different data types in order to understand the relation between them (like why a SIP call failed by looking at the data from the transport level)

FreeSWITCH integration

As a powerful Class5 Engine, FreeSWITCH is the perfect complementary tool for OpenSIPS

About -> Available Versions -> 2.3.x Releases -> Release 2.3.0 Overview

OpenSIPS 2.3 philosophy

http://www.gearitservices.com/Portals/0/SitePics/SystemIntegration.jpg The OpenSIPS 2.3 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.
Why is integration so important to end up being the main tag of a major release? Well, everybody in the VoIP world is operating VoIP platforms/systems – and these are more than SIP Engines (as OpenSIPS is). Indeed, the SIP Engine is the core and most important part of the platform, but to build something usable and useful, you need additional components into your platform like CDR/billing engines, monitoring and tracing tools, data backends, non-SIP trunking or more specialized SIP engines. Shortly you need your SIP Engine (OpenSIPS, of course) to be able to easily integrate with all these components.

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

Integration

the rest

Migration from 2.2.x to 2.3.0