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
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
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
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
The only problem is to decide for how long will be such a chat active as there is no explicit BYE sent.
Related posts:
Real Time Communication 