About -> Available Versions -> 3.1.x Releases -> Release 3.1.0 Overview
OpenSIPS 3.1 philosophy
Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The 3.1 release focused on complex call crafting, basically on increasing OpenSIPS's ability to create and handle complex calling scenarios where multiple SIP calls are mixed and able to interact. Or shortly said, the 3.1 release addresses the Class 5 specific calling features and how to control such calling features via APIs.
The "Call API" is a new standalone component added to the OpenSIPS ecosystem to offer an API for controlling the calls going via OpenSIPS. By using an WebSocket based protocol, this GO based API is able to start, terminate, mute/unmute and transfer the calls hosted on OpenSIPS. Note that this API is not to be used as a SIP-end point, but as a call controller. The offered API is bidirectional - while the API accepts the call control commands, the API is also feeding back with events about the call progress or status.
This is a new module that provides means to manipulate the RTP streams of the ongoing proxy'ed calls in OpenSIPS. The module is able to inject or to copy the RTP of such proxy'ed calls/dialogs by exchanging its SDP bodies (and RTP streams) with some new UAC calls created (by the module) towards a media server. Using this new module one can inject/playback announcements or music on hold during an ongoing call, or listening a conversation of two different participants.
For both RTProxy and RTPEngine, OpenSIPS is able to report to the script level the DTMF events sampled from the passing RTP. This make possible the implementation of simple IVRs and/or authentication via DTMF with nothing more than OpenSIPS and the media relay. Combined with other functionalities such as media exchange or Back-2-Back, you can even do some cool DTMF driven calls scenarios.
In order to allow a better grip and control over the calls in OpenSIPS, the 'dialog' module comes with two important enhancements. First is about the inter-dialog data exchange, to be able to exchange data between various ongoing dialog. The second is about providing new dialog triggers, to allow a better call monitoring and control directly from the script level.
The module enables the handling of the "as-feature-event" event package (as defined by Broadsoft's Device Feature Key Synchronization protocol) by the presence module. This can be used to synchronize the status of features such as Do Not Disturb and different forwarding types between a SIP phone and a SIP server.
The B2B engine is on the verge of some dramatic long term changes and 3.1 includes the first, very important ones. First of all it is critical to have clustering/replication support in order to address High-Availability or distribution scenarios. Another change was the implementation of the "b2b context", a new mechanism to allow, from the script level, the attaching of custom data to a B2B session. This helps in correlating all the entities (UAC, UAS) part of a B2B session, to share and exchange such data between the entities.
BLF extended support
In Class 5 services, BLF is an important feature, so there was a major rework of the module in OpenSIPS 3.1. The target was to 'properly support the call forking scenarios (like call redirects or call hunts), to correctly report all the involved parties in the call and how they (may) change during the call setup. Now the 'pua_dialoginfo' module is able now to get access to the transaction information (not only to the dialog information as before) in order to get accurate information about the call setup.
Call Center enhancements
Starting with version 3.1, the Call Center got several improvements to make easier the integration of the module with different external tools for the agent side, to overall improve the agent capabilities and experience in an OpenSIPS based solution. Extensions as call dissuading, enhanced wrapup time, pre-call agent announcement and agent triggered events are just couple of the 3.1 additions.
Push Notification support
The SIP Push Notification support was improved and aligned to the requirements as per newly adopted RFC 8599. In the same time, several particularities were addressed (mainly regarding the contact registration) such as privacy concerns or device identification concerns.
STIR & SHAKEN
This module adds support for implementing STIR/SHAKEN (RFC 8224, RFC 8588) Authentication and Verification services in OpenSIPS. A more comprehensive description is available on the OpenSIPS blog, while the technical details are available in the module's readme.
Quality Based Routing
This is a new module which keeps track of the signaling quality of each outbound gateway at runtime and dynamically alters the gateway ordering in order to ensure an optimal quality for your platform's PSTN termination signaling! (documentation) (blog)
Call Rating support
The rate_cacher module provides a means of caching and real-time querying of the ratesheets assigned to your clients and / or vendors. It also allows for real-time cost-based routing and cost-based filtering. What the module is able to do, how to provision and use it, all are nicely described in this blog post.
The module implements authentication over JSON Web Tokens. In some cases ( ie. WebRTC ) the user authenticates on another layer ( other than SIP ), so it makes no sense to double-authenticate it on the SIP layer. Thus, the SIP client will simply present the JWT auth token it received from the server, and pass it on to OpenSIPS which will use that for authentication purposes. For more, see the module documentation.
But the full list of goodies offered by OpenSIPS 3.1 (and a more technical one too), together with migration instructions, can be found on the OpenSIPS 3.1 release notes page.