Login | Register

About

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).

Learn more from this blog post about the OpenSIPS 3.3's vision on Instant Messaging in the IMS and Unified Communication ecosystem


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.

MSRP stack

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.

MSRP relay

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.


Unified communication

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.

MSRP gateway'ing

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.


IMS

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.

RCS support

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.

Diameter extensions

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.
This opens the possibility to generically interface with a Diameter service and run your own custom (or specific) Diameter requests / queries, which is very common on the IMS systems.


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.
Several module are already supporting the status and reporting interface, such as drouting, dispatcher, clusterer, dialplan, pike and SQL cacher.

The reporting part here brings a huge benefit as you can have a built-in history of what happened inside OpenSIPS in regards to certain resources. Like in `drouting`, you can see detailed reports on the reload operations or on the switching of the GW status - this may be a tremendous help in understanding and managing your OpenSIPS.

Also there is a new module to provide custom, script level defined, Status/Report identifiers, with the ability to publish status and reports for them. See the module documentation and also the description of the Status/Report framework.
More to read on this can be found in this great blog post on the topic.


TCP boost

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:

  • improve the TCP conns balancing over the TCP workers, to avoid over-loading of the TCP workers
  • a TCP connection may now perform read operations from different processes (which ever is available), not only from one.
  • added support for parallel handle of messages from the same TCP conn (reading is still sequential, of course).

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

SDP demux'ing

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.


All

There are many many other changes with this release, and you can read about all of them in this detailed listing.



Page last modified on May 30, 2022, at 10:04 AM