About -> Available Versions -> 3.3.x Releases -> Release 3.3.0 Overview
OpenSIPS 3.3 philosophy
The instant messaging is evolving and gaining more and more importance. This happens in both worlds of VoIP/ITSP and IMS/MNO/MVNOs - and the overlapping and mixing of these worlds in increasing each year. The OpenSIPS 3.3 is to address more, in depth, the topic of Instant Messaging, in the context of SIP. And this is done through two major perspectives: from the Unified Communication perspective, by aligning IM with the voice and presence capabilities in OpenSIPS, and from the IMS perspective, mainly as support/integration with RCS (Rich Communication Services).
Messaging sessions or MSRP
With 3.3 version the IM capabilities of OpenSIPS were dramatically enhanced by adding Session Mode for IM, or the Message Session Relay Protocol / MSRP (RFC 4975, RFC 4976). The huge advantage of Session Mode is the fact that you can have deal with IM in a more complex way, session based, or chats; and this enables more IM oriented services to be built, or unified with the audio/video/presence capabilities.
The new proto_msrp module is the foundation of the entire MSRP support in OpenSIPS. It implements the MSRP(S) support according to RFC 4975. The implementation provides a generic MSRP(S) stack covering the network operations (reading / writing MRSP(S) messages), the parsing of the MSRP messages and the managing of the MSRP transactions (request-reply and timeout). The module by itself cannot be used as it exposes no scripting or MI capabilities - it exposes only an internal API for other modules to build functionalities on top of it.
The new msrp_relay module implements an MSRP Relay according to RFC 4976. It is built on top of the proto_msrp and it is able to perform relaying/bridging of MSRP(S) traffic between multiple interfaces. The relay is an essential building block, similar to a RTP relay, from the perspective of the interconnections (network bridging in SBC) and of security (topology hiding and authentication).
Chat/MSRP User Agent
The new msrp_ua module bundles the SIP and MSRP capabilities required for implementing an chatting / IM session end point in OpenSIPS. Built on top of proto_msrp and b2b_entities, the module is able to initiate or receive SIP sessions with MSRP and send/receive chats via those sessions. The module may be used directly, via script and MI, to handle such SIP with MRSP sessions and get easy access to their content. Also the module provide an internal API so other modules may build more complex functionalities on top of it.
Once OpenSIPS 3.3 has this messaging capability converging to SIP, the idea of Unifying Communications, of supporting IM along voice and video, becomes technically doable. The SIP infrastructure is already in place, you just need to build the messaging related services.
To support SIP clients with Page Mode (SIP MESSAGE) as well, OpenSIPS 3.3 is able to act as a Gateway between SIP MESSAGE(or "Page Mode") and MSRP-based("Session Mode") Instant Messaging – in this way, such SIP clients (with MESSAGE only support) will be able to access all the advanced messaging services built on top of MSRP (like chats, Queuing, RCS, etc).
Contact Center (OmniChannel)
With 3.3 version, the Call Center module in OpenSIPS also support queuing and distributing Messaging Sessions via MSRP calls, turning the modules into actually a Contact Center as the agents are now able to handle both RTP/audio calls and (multiple) MSRP/chat calls, via the same flows, in the same time. See here more on agents RTP/MSRP support. For flexibility purposes, the module implements two different dispatching (to agents) policies, efficiency (loading agents) or balancing oriented - see the chat_dispatch_policy module parameter.
Once everything is concentrated around MSRP, the interconnection with IMS networks is possible via an OpenSIPS RCS gateway. Therefore any smart phone with RCS support (or within an IMS network) will be able to exchange MSRP traffic with external world.
At its core, RCS (Rich Communication Services) is a suite of specifications from OMA and GSMA aimed at replacing SMS messages with a richer messaging system equipped with added services such as group chat, message read receipts, file and file thumbnail transfers, download pausing and resuming, geo-location push, to name a few. And how to use OpenSIPS 3.3 in that context can be learned from this great blog post.
The OpenSIPS 3.3 version comes with support for generic Diameter requests. So, by using a JSON Array containing the required AVPs as input, script writers may now send generic Diameter requests from script and also fully define them in the "dictionary.opensips" file, covering any possible Diameter application.
Status Report support
A new framework and interface is now available in OpenSIPS 3.3, for managing and accessing the status (readiness) and logs of various OpenSIPS components (modules or parts of the core). See the description of the framework and of its ecosystem.
First of all, there were several improvements at the core level when comes to TCP handling / throughput - the idea here started from the huge differences (in terms of handling and performance) between TCP connection associated with SIP trunks (single connection tunneling a lot of traffic) versus end-point oriented connections (many connections with low traffic). So here is what OpenSIPS 3.3 comes with:
Also, the new tcp_mgm module (completely optional) was added to provides fine-grained control over the properties of each TCP connection taking place in OpenSIPS, using an SQL backend. See the module documentation and blog post for more info.
More on Media
This is a new b2b_sdp_demux module that is able to de-multiplex a multi-stream call to multiple downstream calls, each containing a different subset of the initial streams. See the module documentation for more details.
RTP relaying in B2B
The B2B modules in OpenSIPS provide the mechanisms to create complex SIP scenarios in B2B mode. In OpenSIPS 3.3, the rtp_relay module is B2B aware, providing the automatic support for RTP/media handling. So you do not have to be done at the script level, would require some complex logic to store information throughout the B2B context.
RTP relaying in Media Exchange
Media exchange features are now bound to the rtp_relay module, to provide more accurate signalling in SDP. Therefore, when using media exchange capabilities to inject media in a call, the participant will continue using the same IP of the RTP Relay, without using the Media Server IP, thus preserving the RTP topology hiding.
There are many many other changes with this release, and you can read about all of them in this detailed listing.