Rich Communication Suite Support

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 SBC Core supports Rich Communication Suite (RCS) and MMTel conferencing related signaling with the implementation of the following features:

• 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
• Message Session Relay Protocol (MSRP). Refer to MSRP Support for more information

Device Capability Indication and Device Selection Support

The SBC supports parsing and transparently relaying SIP headers associated with RCS services. For example, the REGISTER request may contain a Require header with the option tag "pref" if the client wants to be sure that the registration server honors caller preferences. If configured, when the SBC receives 'pref' SIP option tag in the incoming SIP REGISTER, it parses and transparently passes the 'pref' to egress side. The “pref” option tag is used to publish and request support for RFC 3840 caller capabilities.

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 SBC also supports the following transparency:

• 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 SBC Core supports RCS capability discovery procedures between RCS endpoints prior to video/audio session setup. The two recommended mechanisms to support this feature include:

• 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 SBC Core supports Rich Communication Suite (RCS) services with the implementation of the following features which are described in this section:

• 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)

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

4. application/end-user-confirmation-request+xml:
5. application/end-user-confirmation-response+xml:
6. application/end-user-confirmation-ack+xml:
7. application/recipient-list:
8. application/im-iscomposing+xml:
9. 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 SBCacting as B2BUA receives a content body with the type 'application/resource-lists+xml' containing a list of parties to be added in to the chat session, each URI (party) has a dialog identifier requiring translation, modification and forwarding to the egress side. The SBC translates the dialog-identifiers specified in the URI list of the incoming resource-lists body to reflect the call identifiers used by the  SBC towards the core network for the respective calls.

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 SBC support this functionality by translating call-info parameters in the 'application/conference-info+xml' body so the core network sees the correct versions of the dialog identifiers for registered and unregistered users in following scenarios:

• 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 SBC Core relays SUBSCRIBE, NOTIFY and REFER to support the Enhanced Address Book (EAB) service for both registered users in Access SBC deployments and un-registered users for Peering SBC deployments. Additionally, the SBC relays PUBLISH from UE towards the core for a registered user in its role as P-CSCF.

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