Group … Messaging

RCS could be probably deployed much faster if it wasn’t that general right from the beginning. To implement a simple 1-1 chat is not a big deal. The same applies for voice and video. And honestly one doesn’t expect much from a new product as long as the basic functionality is working fine.

Well, in case of RCS/RCSe group messaging was always referred as a basic one. But sometimes it was not without struggles. There are many ways how a Conference can be established. Just to find out all the relevant RFCs is not an easy task. RCS Group Chat technical realization is based on the “Ad-Hoc Session Mode messaging”. RCS is referencing to OMA-SIMPLE or OMA-CPM. OMA is defining their ways how to handle the chats and pointing to particular RFCs. Many of them. The basic one is the RFC 4353. In this document it is described the logical architecture. Simply put group messaging is a multi 1:1 chat. All the participants will establish a 1:1 chat with a center point called “focus”. This logical role is implemented as a part of RCS (CPM/SIMPLE) server functionality.

Group Chat - focus

Group Chat – focus

As mentioned, in case of RCS we mostly talk about ‘Ad-hoc’ conferencing. That means that the conference does not need to be scheduled or reserved, but is created “on the fly”. The benefit of this approach is that the conference URI doesn’t need to be known to the user; instead it is created by the focus (RCS server) and used by the participants’ UAs. The SIP URI of the Conference Factory is usually provisioned in the client (as in a “create new conference” button). If Karin wants to create a group chat she will send SIP INVITE to the RCS server. RCS will identify this INVITE request as a request to create a new ad-hoc conference by the Request-URI. The INVITE usually also contains a list of participants in the body:

   INVITE sip:conf-factory@operator.com SIP/2.0
    To: "Conf Factory" <sip:conf-factory@operator.com>
   Require: recipient-list-invite
   Content-Type: multipart/mixed;boundary="boundary1"
   Content-Disposition: recipient-list
<?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
             xmlns:cp="urn:ietf:params:xml:ns:copyControl">
     <list>
       <entry uri="sip:Johan@operator.com" cp:copyControl="to" />
       <entry uri="sip:Rory@operator.com" cp:copyControl="to" />
       <entry uri="sip:Eric@operator.com" cp:copyControl="cc"/>
     </list>
   </resource-lists>

Assuming that all security and policy requirements have been met, a new conference will be created with the Contact URI returned in the 200 OK will be the new conference URI. The Contact header field will contain the ‘isfocus’ feature parameter to indicate that this URI is for a conference.

Group chat call flow

Group chat call flow

A SIP conference URI can be used to inject different kinds of information into the conference. Examples include new participants, new real-time media sources, new IM messages, and pointers to passive information references (such as HTTP URIs). To request that the focus add a new information resource to the specified conference, any SIP UA can send a REFER to the conference URI with a Refer-To containing the URI of the new resource. Since  this REFER is sent to the conference URI and not the Conference Factory URI, the semantics to the focus are to bring the resource  into the conference and make it visible to the conference participants.

In order to get more information about the other participants every participant can subscribe to the conference state event package defined in RFC 6502. The participants send a SIP SUBSCRIBE request to the conference URI, indicating the conference state event package and the duration of the subscription:

SUBSCRIBE sip:Conf-ID@operator.com SIP/2.0
Event: conference
Expires: 3600
Allow: application/conference-info+xml

Group chat +REFER + Conference Event

Group chat +REFER + Conference Event

The scenario for adding a new UA participant is important to support  because it works even if the new participant does not support REFER  and transfer call control only the requesting participant and the  focus need to support the REFER and transfer call control. Upon receipt of the REFER containing a Refer-To header with a SIP URI, the focus SHOULD send an INVITE to the new participant  identified by the Refer-To SIP URI containing a Contact header field  with the conference URI and the ‘isfocus’ feature parameter.

Actually authors of SIP standards wisely thought that it would be better not to overestimate the capabilities of clients. With that idea in mind they defined so-called ‘conference-unaware UA’.  A conference-unaware UA needs only to support the basic SIP from RFC 3261. The conference-unaware UA would simply ignore the conferencing information and treat the session (from a SIP perspective) as a point-to-point session. E.g. the presence of an ‘isfocus’ feature tag in a Contact header field will not cause interoperability issues between a focus and a conference-unaware UA since it will be treated as an unknown  header parameter and ignored, as per standard SIP behavior.

It is also technically possible to base the group messaging on stand-alone messaging. In that case the flows are even simpler.

Group chat - pager mode

Group chat – pager mode

The only problem is to decide for how long will be such a chat active as there is no explicit BYE sent.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s