Development -> Planning -> OpenSIPS 3.3 Planning

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 upcoming OpenSIPS 3.3 is to address more, in depth, the topic of Instant Messaging, in the context of SIP. And this is to be 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

Unified Communication

The Instance Messaging support was part of OpenSIPS from the very beginning. Nevertheless, this was limited to the Page Mode (RFC 3428, or the MESSAGE method). With 3.3 version we are looking to enhance the IM capabilities of OpenSIPS by adding IM support for Session Mode, 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 relay support

The MSRP relaying (RFC 4976) for IM Session Mode is a must for a SIP Server/Proxy for handling MSRP related SIP session. Besides the ability of relaying MSRP traffic, the 3.3 must extend the SDP parsing support to properly handle the MSRP specific SDP extensions. This addition will enable the easy integration of web-based chat services with OpenSIPS (web sites using WSS and MSRP for chat sessions).

MSRP to MESSAGE gateway

As MSRP is not widely supported in the end-user devices, but MESSAGE method is, a way of doing IM translation from Page Mode (MESSAGE method) to Session Mode (MSRP) will be useful. Such a gateway may be used also middle layer for achieving SMS (SMPP) to RCS/MSRP conversion.

OmniChannel Queue (or Contact Center)

The current Call Center module in OpenSIPS supports only SIP calls (as work items in the queue). But with the planned MSRP support, the IM may be supported also. An IM chat, as an MSRP session, may be handled as a new type of work item in the queue. A unified queue (voice and IM) may deliver items (calls or IM sessions) to agents, in the same time. Of course, the queue distribution logic and the agents capabilities/profile will have to be extended in order to support the IM sessions as well.

IM chat group

The current IMC module is oldish, supporting only Page Mode for IM and only an IRC-based way of functioning. A refurbish of this module in order to (1) support Session Mode IM (MSRP) as well, (2) to provide a more flexible and modern way of managing the chat rooms (not IRC based) and (3) to provide an API to allow the integration of IM with WEB services.

IMS

OpenSIPS 3.2 made the first steps towards IMS by providing DIAMETER support. Another part of the broader IP Multimedia Subsystem (IMS), from the IM perspective is RCS. Rich Communication Services (RCS) a protocol between mobile telephone carriers and between phone and carrier, aiming to replace SMS messages. The RCS gains traction both on the MNO's side (more and more already migrated), as well as on the device's side (Android natively support RCS)

RCS / Chat

The Chat service (from RCS), for IM services, mainly relies on SIP and MSRP. In order for OpenSIPS 3.3 to properly implement RCS, several extensions for SIP and MSRP must be implemented/supported, to align to the GSMA specifications over RCC.07 - Rich Communication Suite - Advanced Communications Services and Client Specification, version 11.0. The RCS support in OpenSIPS will make possible scenarios like:

    SIP IM client (non-RCS)   <---SIP--->    OpenSIPS   <---RCS--->   IMS (third-party)   <----RCS--->   mobile device

Miscellaneous

Structured SDP manipulation

Instead of using regexp-based changes over the SDP, we envision a structured way of accessing and modifying the SDP payload, by using easy variables. All the changes will be visible on the spot. This will allow multiple changes over the SDP, from script or modules, while keeping a single, consistent data set. For example, if you change an "a" line in the SDP from script level, the change will be visible to RTPengine. Furthermore, the new SDP from RTPengine will be visible (and changeable) at script level.

SIP Outbound support

The RFC 5626 specification is mandatory for IMS systems and OpenSIPS should be fully supporting it.

Media Capabilities in B2B mode

The B2B modules in OpenSIPS provide the mechanisms to create complex SIP scenarios in B2B mode. However, they lack support for RTP/media handling, which, if had to be done at the script level, would require some complex logic to store information throughout the B2B context. These modules should rely on the existing RTP Relay interface to handle B2B media in a more easier fashion.

Vote your Favorite Features!

We are undergoing an OpenSIPS 3.3 Feature Survey (due 17th January 2022), and we would like to gather opinions on the currently chosen feature set, as well as any additional ideas you may have. Your feedback will help us prioritize the work that will go into the upcoming 3.3 release. Thank you!

Poll Results

Many thanks to all of you voted for this poll! Please find the poll results below -- regarding the additional feature suggestions we received, we will go through them and pick the most popular / interesting ones in a future announcement.

We try to update the list with their development status, so you can have a clear view over the 3.3 progress. Nevertheless, we strongly recommend you to check the Feature list of 3.3.