OpenSIPS 3.3 – Messaging in the IMS and UC ecosystems

SIP is more than voice and video, it is also instant messaging and presence. Even if the traditional SIP services are more voice focused, the Instant Messaging (IM) gained a lot if importance and traction in the context of IP Multimedia Subsystem (IMS) and Unified Communications (UC).

Messaging in IMS

Thanks to the large adoption of smart devices, the end user messaging capabilities are more and more powerful, allowing more than the old, dry SMS format.

On the other hand, on the M(V)NO side, thanks to the migration to IP networks (IMS), more complex messaging services can be delivered, like chats, integration and more . This is the Rich Communication Services (RCS) which states the SIP as session protocol for messaging too.

Messaging in UC

Once you have 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.

Even more, the integration of messaging service is a very attractive one considering that more and more Enterprises and Service Providers are looking to expand their ways of delivering service to the end-user, via different communication channels, not only voice. Like why should a conference be only audio/video, without having a side chat? Or why should you reach a Customer Service only via calls, why not chatting as well?

OpenSIPS 3.3 in the messaging ecosystem

Let us see how OpenSIPS 3.3 will contribute to supporting the messaging services in both IMS and UC contexts.

In SIP, instant messaging may be done in two modes:

• The Page Mode, making use of the SIP method MESSAGE, as defined in RFC 3428. This mode establishes no sessions.
• The Session Mode, using The Message Session Relay Protocol (RFC 4975, RFC 4976). This mode is able to group multiple messages in sessions.

The OpenSIPS 3.3 strategy is to concentrate on Session Mode as: (a) such a session based messaging is more powerful when comes to service creations and (b) the session mode (MSRP) is the one also used the RCS/IMS.

For just handling, passing through MSRP sessions, OpenSIPS needs to first act as an MSRP relay. This will allow SIP with MSRP endpoints to directly connect into OpenSIPS – like SIP clients with MSRP, application clients or WEB embedded clients.

To support SIP clients with Page Mode (SIP MESSAGE) as well, OpenSIPS will also act as a MESSAGE to MSRP Gateway – in this way, such SIP clients (with MESSAGE only support) will be able to access all the advanced messaging service build on top of MSRP (like chats, Queuing, RCS, etc).

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.

With MSRP support, the Instant Messaging support may be easily implemented in advanced services (like chats, Call Centers) and unified with the voice and audio components.

With 3.3 version, the Call Center module in OpenSIPS will also support queuing and distributing Messaging Sessions via MSRP calls. Agents will have voice or messaging capabilities and the possibility to handle multiple Messaging Sessions in the same time. So, this will become more of a Contact Center.

Similar, to complete the audio/video conferencing services, the 3.3 version aims to provide an MSRP conference/chat capability. This will deliver a full blow modern chatting experience to the SIP (enabled) users as well. To be mentioned that currently OpenSIPS provides an old fashion, IRC oriented, MESSAGE only, chatting support, morally and technically outdated.

Conclusions

OpenSIPS 3.3 targets to implement various components of the overall SIP Instant MESSAGING ecosystem, from gateways and transport to services.

This will allow a wide range of communication possibilities between different types of users and different services.

Just image a user browsing a web page and clicking on a chat box in the page, in order to get sales information. This may be an embedded SIP end point with MSRP session, creating a chat session that is routed via OpenSIPS with MSRP relay into a Contact Center in order to connect our user to a Agent, for chatting. Simple, right ?

Or a person within a mobile network, using his/her smartphone in order to chat with friends that may use a regular SIP application (with MSRP) or an traditional SIP client with MESSAGE’s. Yes, this is going to be possible!

Or why not having a chat room attached to your video/audio bridge, regardless how the participants joined the conference (via web portals, via SIP applications or via PSTN end points).

All these will become possible with OpenSIPS 3.3!

For more technical details, check the roadmap web page.