GSM Association
Official Document RCC.71 - RCS Universal Profile Service Definition Document
Non-confidential
RCS Universal Profile Service Definition Document
Version 2.4
16 October 2019
This is a Non-binding Permanent Reference Document of the GSMA
Security Classification: Non-confidential
Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is confidential to the
Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and
information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those permitted
under the security classification without the prior written approval of the Association.
Copyright Notice
Copyright © 2019 GSM Association
Disclaimer
The GSM Association (“Association”) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept
any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document.
The information contained in this document may be subject to change without prior notice.
Antitrust Notice
The information contain herein is in full compliance with the GSM Association’s antitrust compliance policy.
V2.4
Page 1 of 260
GSM Association
Official Document RCC.71 - RCS Universal Profile Service Definition Document
Non-confidential
Table of Contents
1
Introduction
Structure of this document
1.1 Purpose of the Universal Profile
1.1.1
1.1.2 Universal Profile 2.4 client scope
1.2 Conventions
1.3 Requirement and Technical Realisation Classification
1.4 Terms and Abbreviations
1.5 Table of references
2 Device Provisioning
SIM swap
Secondary Devices
Activation of RCS services
2.1 Description
2.2 User Stories and Feature Requirements
2.2.1
2.2.2 Configuration of the user´s primary device by requesting user identity
2.2.3 Multiple RCS clients
2.2.4
2.2.5 User consent
2.2.6
2.2.7
Error Management
2.2.8
Provisioning push
2.2.9 Dual SIM Devices
2.3 Technical Information
2.3.1 Overview
2.3.2
Technical Implementation of User Stories and Service requirements
3 Capability Discovery and Service Availability
3.1 Description
3.2 User Stories and Feature Requirements
3.3 Technical Information
3.3.1 Overview
3.3.2 Configuration Parameters
3.3.3 Handling of capability exchange triggers in messaging
3.3.4 Capability information for IP Video Call
3.3.5
Technical implementation of user stories and requirements
4 Operator Messaging
5 1-to-1 Messaging
5.1 Description
5.2 User Stories and Feature Requirements
5.3 Technical information
5.3.1 Overview
5.3.2 Network Fallback Support Capability
5.3.3 Chat Message revocation
5.3.4 Configuration Parameters
5.3.5
Technical Implementation of User Stories and Service Requirements
7
7
7
7
8
8
8
15
17
17
18
18
18
20
20
21
23
23
24
24
25
25
26
31
31
32
34
34
35
37
37
38
39
39
39
39
54
54
55
55
55
61
V2.4
Page 2 of 260
GSM Association
Official Document RCC.71 - RCS Universal Profile Service Definition Document
Non-confidential
6 Group Chat
6.1 Description
6.2 User Stories and Feature Requirements
6.3 Technical Information
6.3.1 Overview
6.3.2
Technical Implementation of User Stories and Service requirements
7 File Transfer
7.1 Description
7.2 User Stories and Feature Requirements
7.3 Technical Information
7.3.1 Overview
7.3.2 Configuration Parameters
7.3.3
Technical Implementation of User Stories and Service requirements
8 Audio Messaging
8.1 Description
8.2 User Stories and Feature Requirements
8.3 Technical Information
8.3.1 Overview
8.3.2
Technical Implementation of User Stories and Service Requirements
9 Messaging for Multi-Device
9.1 Description
9.2 User Stories and Feature Requirements
9.3 Technical Information
9.3.1 Overview
9.3.2
Technical Implementation of User Stories and Service Requirements
10 Green Button Promise for Voice
10.1 Description
10.2 User Stories and Feature Requirements
10.3 Technical Information
10.3.1 Overview
10.3.2 Configuration parameters
10.3.3 Technical Implementation of User Stories and Service Requirements
11 Green Button Promise for IP Video Call Services
11.1 Description
11.2 User Stories and Feature Requirements
11.3 Technical Information
11.3.1 Overview
11.3.2 Configuration parameters
11.3.3 Technical Implementation of User Stories and Service Requirements
12 Enriched Calling
12.1 Description
12.2 General
12.3 Technical Information for the General Requirements
66
66
67
77
77
78
82
82
82
93
93
94
95
101
101
101
104
104
105
107
107
107
112
112
113
116
116
116
119
119
119
122
124
124
124
128
128
128
129
131
131
131
131
V2.4
Page 3 of 260
GSM Association
Official Document RCC.71 - RCS Universal Profile Service Definition Document
Non-confidential
12.4 User Stories and Feature Requirements for the Enriched Pre-call
experience
12.5 Technical Information for the Enriched Pre-call experience
12.5.1 Overview
12.5.2 Technical Implementation of User Stories and Service Requirements
12.6 User Stories and Feature Requirements for the Enriched In-call experience
12.6.1 General Requirements
12.6.2
12.6.3 Share any file during call
12.6.4 Exchanging messages
12.6.5 Location Push
12.6.6 Enriched Calling In-call sharing with Non-Enriched Calling enabled
“Live Video”
contacts
12.7 Technical Information for the Enriched In-call experience
12.7.1 Overview
12.7.2 Technical Implementation of User Stories and Service Requirements
12.8 User Stories and Feature Requirements for Interactive In-call experience
12.8.1 Live Sketch Sharing
12.8.2 Specific Requirements for a live sketch on an image
12.8.3 Specific Requirements for a live sketch on a map
12.9 Technical Information for Interactive In-call services
12.9.1 Overview
12.9.2 Shared Sketch
12.9.3 Specific Shared Image Sketch Requirements
12.9.4 Specific Shared Map Sketch Requirements
12.10 User Stories and Feature Requirements for the Enriched Post-call
experience
12.10.1 Enriched Calling Post-call experience with Non-Enriched Calling enabled
contacts
12.11 Technical Information for the Enriched Post-call experience
12.11.1 Overview
12.11.2 User Stories and Feature Requirements for the Enriched Post-call
experience
12.11.3 Enriched Calling Post-Call experience with Non-Enriched Calling
enabled contacts
12.12 User Stories and Feature Requirements for Enriched Call content in Logs
and media contact centric view
12.12.1 Technical Information for Enriched Call Logs experience
13 rcsVVM Service
14 APIs
14.1 Description
14.2 User Stories and Feature Requirements
14.3 User Stories and Feature Requirements of Terminal API
14.4 User Stories and Feature Requirements of Network API
15 Messaging as a Platform: Chatbots
133
136
136
136
136
136
137
139
141
141
142
142
142
143
145
145
148
149
150
150
150
151
151
151
152
153
153
153
153
153
155
156
156
156
156
157
158
158
V2.4
Page 4 of 260
GSM Association
Official Document RCC.71 - RCS Universal Profile Service Definition Document
Non-confidential
15.1 Introduction
15.2 Chatbots
15.2.1 Technical Information for the realisation of Chatbots
15.3 Void
16 Security against Malware
16.1 Description
16.2 User Stories and Feature Requirements
16.3 Technical Information
16.3.1 Client authenticity verification
16.3.2 User Authentication
16.3.3 Encryption
16.3.4 Storage of Authentication and Identification Data
16.3.5 SIM State Handling
16.3.6 Applicability of Authentication Methods
16.3.7 Technical Implementation of User Stories and Service requirements
17 Data Off
17.1 Description
17.2 User Stories and Feature Requirements
17.3 Technical Information
17.3.1 Overview
17.3.2 Technical Implementation of User Stories and Service requirements
18 RCS Settings
18.1 Description
18.2 User Stories and Feature Requirements
18.3 Technical Information
18.3.1 Technical Implementation of User Stories and Service Requirements
19 Multi Device Voice and Video
19.1 Description
19.2 User Stories and Feature Requirements
Annex A
Supporting requirements
A.1 Emoticon conversion table
A.2 Unicode Standard “Emoji” Emoticons
A.3 Panoramic photo view
Annex B OS/Platform Specific Functionality
B.1 Multiple Client handling on Android™ OS
B.1.1 Multiple Client handling on Android™ OS version superior or equal to 7.0
B.1.2 Multiple Client handling on Android™ OS version prior to 7.0
B.2 Android™ Client Authenticity Verification Procedure
Annex C Configuration Parameters
Annex D
Annex E Document Management
Features supported per Chatbot application version
158
159
193
207
207
207
207
208
208
208
209
209
209
210
212
216
216
216
217
217
218
220
220
220
225
225
231
231
231
237
237
238
239
242
242
242
243
246
247
259
260
260
260
E.1 Document History
E.2 Other Information
V2.4
Page 5 of 260
GSM Association
Official Document RCC.71 - RCS Universal Profile Service Definition Document
Non-confidential
V2.4
Page 6 of 260
GSM Association
Official Document RCC.71 - RCS Universal Profile Service Definition Document
Non-confidential
1
Introduction
1.1 Purpose of the Universal Profile
The Rich Communication Services (RCS) Universal Profile 2.4 represents an update of
globally shared RCS specifications. This Service Definition Document (SDD) lists all the
User Stories and Feature Requirements, based on the Universal Profile 2.0 specification.
The Universal Profile describes a single, global RCS implementation that will be deployed
worldwide. The aim of this profile is to reduce the variation that exists today across various
RCS profiles in order to simplify large-scale deployment. The Universal Profile is targeted at
Operating System (OS) developers and Original Equipment Manufacturers (OEM) for open
market device implementations. The focus of requirements is on native device
implementations implemented at the OS or device manufacturer level. It is acknowledged
that downloadable applications may face limitations that prevent such implementations from
fulfilling the complete feature set.
The SDD provides user stories and feature requirements and is complemented by the RCS
Universal Profile 2.4 technical specification to describe a prioritized set of features which
Mobile Network Operators (MNOs) can launch.
1.1.1 Structure of this document
The document details how features are to be implemented from a functional requirements
point of view and details specifics that may influence how certain functions behave, creating
an overall guide for OEMs and application developers.
1.1.2 Universal Profile 2.4 client scope
The Universal Profile can be delivered in two ways for users:
1. Implemented natively within the device by the OS developer or OEM, tightly integrating
the capabilities and services within the address book and many other native touch
points across the device.
2. Implemented as a downloadable application that can be downloaded from Application
stores and accessible as a separate application on the user’s device, usually within the
device’s application folder or its desktop.
In most cases, implementation of features is identical for both native and downloadable
clients and this document for the most part will not differentiate between the two. In cases
where implementation of a feature in a downloadable client differs from the native
experience, these are described separately within the relevant section.
The profile includes some sections that come without a technical realisation (14 and 19). As
such, they are not in scope for implementations in this version of the universal profile. The
requirements are indicative only since they may change following the technical feasibility
assessment and are provided for information in case this information on future evolutions
would be relevant for the design decisions of an implementation.
In addition to maintenance of the core features of RCS, this SDD starts support of 3rd party
developer applications who use interfaces to deliver their services using RCS as an enabler
(we call that “MaaP – Messaging as a Platform”).
V2.4
Page 7 of 260
GSM Association
Official Document RCC.71 - RCS Universal Profile Service Definition Document
Non-confidential
Any major changes in comparison to the Universal Profile 2.0 are listed in the introduction
section of each chapter.
1.2 Conventions
It is a shared understanding by the standardising RCS MNOs that any service described in
the RCS standard may or may not be offered by any given MNO.
NOTE:
For device manufacturers and client developers requirements are classified
based on the conventions defined in section 1.3 of this document.
For the purpose of this document, user stories are identified using the following numbering
convention: “USN.N”, where US= User Story and N= the associated user story e.g. US2.2.
The associated requirements are identified using the following numbering convention: “RN-
N-N, where “R” = requirement e.g. R2-2-1. Sub requirements will appear as a third level e.g.
R-2-2US.
For requirements and parts of requirements that are in italics, no realisation is provided in
this version of the document.
1.3 Requirement and Technical Realisation Classification
Term
Shall
Description
These terms dictate that a functionality and/or process is Mandatory
Shall/Shall Not These terms dictate that a functionality and/or process is Mandatory
Required
These terms dictate that a functionality and/or process is Mandatory
Should/Should
Not
This term dictates that the functionality and or/process is Highly Recommended
Recommended This term dictates that the functionality and or/process is Highly Recommended
May
This term dictates that the functionality and or/process is Nice to Have
Optional
This term dictates that the functionality and or/process is Nice to Have
Table 1: Requirements Classification
1.4 Terms and Abbreviations
Term
3GPP
A2P
Description (contains technical and functional terms)
3rd Generation Partnership Project
Application to Person (communication)
Active device or
interface
A device or interface will be active for a conversation’s “session” if the user has
either started a conversation, or sent events outside of a session from that
device or responded to an incoming event with an event listed in R9-3-4 on that
device/interface. A session is established and associated with that
conversation. Further events sent within the conversation will be sent only to
that device in real-time and will be synchronised with other (inactive) devices
as required. Any given user can only have one active device / interface at any
given point in time for an active session.
AF
Anonymization Function
V2.4
Page 8 of 260