Page History

The Rich Communication Suite (RCS) Initiative is an effort, lead by GSMA, of a group of industry players for the rapid adoption of mobile applications and services providing an interoperable, convergent, rich communication experience. The RCS Initiative includes network operators, network vendors and device vendors.

The RCS Initiative uses an iterative, agile methodology to deliver a consistent feature set, implementation guidelines, example use cases as well as demonstrations and trials around interoperable reference implementations based on profiling of existing standards and specifications. It is a global initiative independent of used access technologies, so it is not limited to GSM/UMTS. CDMA based networks are also actively participating in RCS.

With the Rich Communication Suite, operators can fulfill their customer expectations and continue to introduce ever evolving services based on what the consumer demands. To speed up the introduction of commercial IMS services, the participants in the GSMA RCS initiative have defined a core feature set, leveraging existing standards, and implementation guidelines for an interoperable IMS-based communications suite. The IMS is an important architecture for bringing these capabilities to the consumer in an interoperable way.

The 

• Parsing, encoding and transparently forwarding new headers
• Message Body transparency
• MESSAGE method relay
• Relay of Option-tags to the peer entity
• Translate dialog identifiers in URI list of incoming resource-lists body
• Support for conference package—Translating call-info parameters in the application/conference-info+xml body so the core network sees the correct versions of the dialog identifiers

Device Capability Indication and Device Selection Support

The

The CLI syntax to enable transparently fowarding perf  SIP Option tag is shown below. See CLI

Reference Guide or EMA User Guide for parameter details.

% set addressContext <address context name> zone <zone name> siptrunkGroup <TG name> signaling prefRequireTransparency <disabled|enabled>

 The

• Transparently relaying the Accept-Contact header in all SIP INVITE, SIP SUBSCRIBE, SIP NOTIFY (in-dialog) and SIP OPTIONS requests. The capability to transparently pass ‘Accept-Contact header’ in the SIP request is controlled on per IPTG basis.
• Transparently relaying the feature tags in the Contact header of SIP OPTIONS, INVITE, REGISTER, SUBSCRIBE, NOTIFY and their responses to enable capability exchange and call setup based on the service identifiers to identify the RCS services. This is controlled on per IPTG basis.

Capabilities Discovery Through SIP OPTIONS

The 

• Anonymous Subscribe to get peer capabilities—Anonymous Subscribe with expire:0 is used to fetch Peer capability in SIP NOTIFY message without creating the subscription.
• SIP OPTIONS capability exchange—The SIP OPTIONS method is used by the two endpoints involved in m=video or m=audio sessions to query each other’s capabilities prior to session setup. The SBC supports relaying of out of dialog OPTIONS with feature tags from/to registered as well as unregistered users.

Conferencing Support

The 

• Header Transparency—Parsing, encoding and transparently forwarding new headers
• Message body transparency
• MESSAGE method relay
• Relay of Option-tags to the peer entity
• Translate dialog identifiers in URI list of incoming resource-lists body
• Conference package support

Header Transparency

The IP Signaling Profile may be configured from CLI or EMA to transparently pass the following headers in support of RCS services:

• User-Agent
• Server
• Warning
• Accept-Language
• Accept
• Refer-sub
• Conversation-ID
• Contribution-ID
• InReplyTo-Contribution-ID
• Session-Replaces
• Message-Expires
• Message-UID

Message Body Transparency

RCS supports the following Content-Types:

1. multipart/mixed: Includes multiple Content-Types such as “application/sdp” and “application/resource-lists+xml”
2. application/resource-lists+xml: (can be part of “multipart/mixed” data)

3. application/conference-info+xml: (can be part of “multipart/mixed” data)

1. Info
   The following Content-Types are applicable for MESSAGE method only. Transparency of these message bodies are archived using "unknownBody" transparency flag.

2. application/end-user-confirmation-request+xml:
3. application/end-user-confirmation-response+xml:
4. application/end-user-confirmation-ack+xml:
5. application/recipient-list:
6. application/im-iscomposing+xml:
7. XML body with Message/imdn+xml:

Setting the content transparency flag allows the transparency of indicated content types for all messages, whether in-dialog or out-of-dialog, in cases such as the examples below:

• Initial INVITE
• Any in-dialog messages  (including  and not limited to SUBSCRIBE/NOTIFY/OPTIONS)
• Following out-of-dialog messages which are relayed

Message Method Relay

RCS supports MESSAGE relay to egress side for registered (based on registered AOR) and unregistered (based on PSX policy dip) subscribers.

Relay Option-tags to Peer

RCS supports the following options tags:

1. recipient-list-invite
2. multiple-refer
3. norefersub
4. recipient-list-message

Translate Dialog Identifiers in URI List of Incoming Resource-lists Body

RCS implementation supports adding new parties to a chat session.

When the

The “Replaces” parameter in the message body URI List is used to identify the dialog id to translate.

Conference Package Support

The Conference Event package (defined in RFC 4575) is used by the conference notification service as outlined in the SIP conferencing framework (used for Chat service). The information provided by this package is comprised of conference identifier(s), conference participants (optionally with their statuses and media description), conference sidebars, conference service URIs, etc.

The Conference Event package allows a user to subscribe to the information relating to a conference, represented by a URI that identifies a SIP User Agent (UA) called a focus, that is responsible for ensuring all users in the conference can communicate with each other.

This package name "conference" is carried in the Event and Allow-Events header (as defined in RFC 3265). In this event package, the body of the notification contains a conference information document describing the state of a conference in the “application/conference-info+xml" data format.

The

• SUBSCRIBE (and related NOTIFY within the subscribe dialog, up to grace time)
• REFER (and related NOTIFY within the subscribe dialog, up to grace time)

 Enhanced Address Book

As part of Rich Communication Suite (RCS) feature support, the 

The EAB is an evolution of the basic address book whereby contact information is extended with social presence information such as following examples:

• Availability, indicates the user’s (un)willingness to communicate
• Portrait icon, depicting the user (e.g. a photo or image provided by the contact himself)
• Free text, including textual note and possibility to add emoticons (automatic translation of some specific characters into smileys)
• Favorite link, to publish hypertext link of personal and/or favorite site
• Timestamp, date of the last update of the profile, generated automatically
• Geolocation, depicts the user location

Header Transparency

The following headers are passed transparently in support of RCS functionality using the "unknownHeader" transparency flag:

• SIP-Etag
• Suppress-If-Match
• Content-Disposition
• Sip-If-Match
• Content-ID
• Content-Description

Message Body Transparency

As part of RCS implementation, transparently passing the following Content-Types is supported from egress IPSP with respect to a Request:

• application/simple-filter+xml
• application/resource-list+xml
• application/pidf+xml
• application/watcherinfo+xml
• message/external-body
• application/rlmi+xml
• multipart/related
• application/pidf-diff+xml
• multipart/signed