RCS Explained🙂

[adhilaj]

Introduction 1.1 Purpose of the Universal Profile The Rich Communication Services (RCS) Universal Profile 2.3 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.3 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.3 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”).

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 Description Shall 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 Description (contains technical and functional terms) 3GPP 3 rd Generation Partnership Project A2P 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.

This section does not apply to markets that do not require users to accept Terms & Conditions (T&C). For markets which require users to accept T&C before using RCS, two scenarios can be applied, display of “User Message” or display of “End User Confirmation Request”. User Message US2-6 As an RCS Service Provider, I want to be able to provide information and require consent BEFORE my users use the RCS service. R2-6-1 Upon RCS Service Provider discretion a popup showing EITHER Terms & Conditions OR a Welcome Message (OR no popup is shown) shall be displayed to the user during first-time configuration. NOTE: Display of Terms & Conditions requires two buttons (e.g. “accept” & “decline”) for user action while display of Welcome Message requires only one button (e.g. “Ok”). R2-6-2 The presentation of the messages must be clear to the user and not hidden within the notification tray for action, but be presented ‘on top’ of the screen (see figure below). Figure 2: Example Terms & Conditions pop-up R2-6-3 As soon as the user is presented with the popup, the RCS service shall be active on the device. NOTE: This means that if the user leaves the screen without any action it is equivalent to an acceptance of the User Message. R2-6-4 If the user declines the User Message, RCS services shall not be available on the device, (for details see R2-6-2 and Figure 2). R2-6-5 In case of decline, a retry algorithm shall be able to retrigger the service activation and T&C acceptance process (on RCS capable networks

Technical Implementation of User Stories and Service requirements R2-15-1 The requirements in US2-1 and R2-2-1 and its sub requirements shall be realised locally on the device. R2-15-2 R2-2-2 shall be realised as described in [RCC.07] section 2.3.2. R2-15-3 R2-2-3 and R2-2-4 shall be realised locally on the device. R2-15-4 For R2-2-5, shall set the rcs_state to -4 in the configuration request and follow client codes and procedures defined in section 2.3.2.2.1 of [RCC.07]. R2-15-5 Provisioning on networks with automatic identification (see requirement R2-3- 1) shall be done as described in section 2.3.1.1. If the network cannot authorize the user based on the access as described in requirement R2-3-2 then depending on supported mechanisms, the RCS Service Provider may fall back to the SMS via the procedures defined in section 2.5 or 2.8 of [RCC.14]. R2-15-6 R2-3-2 shall be realised locally on the device if configuration without user interaction could not be concluded successfully.

R2-15-7 Configuration over networks where automatic authentication is not possible (e.g. non-cellular networks) shall be realised using the HTTP mechanism as described in section 2.3.1.1 referring to section 2.6 of [RCC.14] and its subsections or section 2.8 of [RCC.14]. R2-15-8 R2-3-3 and its sub requirements shall be realised locally on the device R2-15-9 R2-3-4 and its sub requirements shall be realised locally on the device R2-15-10 R2-3-5 shall be realised locally on the device R2-15-11 R2-3-6 and its sub requirements shall be realised as described in section 2.6 or 2.8 of [RCC.14] using the SMS format being described in section 2.6.2 of [RCC.14] if the SMS should be handled silently. R2-15-12 R2-3-7 shall be realised locally on the device R2-15-13 R2-3-8 and R2-3-9 shall be realised locally on the device R2-15-14 On Android™ devices, Requirements R2-4-1, R2-4-2 and R2-4-3 are linked to the ability of the embedded RCS stack to be used by other messaging applications than the native client. NOTE: Multi-client solutions for other OSs are for further study. Where relevant solutions on such OSs will align with the concepts used on Android™. R2-15-15 When the embedded RCS stack is not opened to other applications than the native client, technical solutions described for requirements R2-4-6-1 and R2- 4-7-1 apply. R2-15-16 On Android™ devices requirement R2-4-4 is implemented locally on the device with the Android setting related to the Default SMS app. R2-15-17 On Android™ devices, R2-4-5 is implemented locally on the device with the Android™ setting related to the Default Dialler (or phone) application. R2-15-18 The technical feasibility of requirements R2-4-6 and R2-4-7 depend on either evolutions of the Android™ Operating System or device specific implementation to ensure that restriction. R2-15-19 On Android™ devices whose OS version is superior or equal to 7.0, requirement R2-4-6-1 depends on the availability of an embedded RCS stack opened to other application than the native RCS client:  On a non RCS device or an embedded RCS device where the stack cannot be used by other applications than the native client: if the messaging application set as Default Messaging Client supports RCS messaging services (using its own stack), the associated stack shall register RCS messaging services to the IMS and announce RCS messaging services in capability exchanges. Any other RCS client previously set as Default SMS app should unregister RCS messaging and Enriched Calling services from the IMS.  On an embedded RCS device where the stack can be accessed by other applications than the native clients, the required behaviour is:Panoramic photo view RCS devices shall be able to record, display and share panoramic pictures in a user- convenient way. The requirements in this Annex A.4 shall be considered as guidelines for the implementations; screen examples are provided to illustrate these requirements but shall by no means mandate any design or UI principles. If a recorded panoramic view covers less than 360 degree full circle pictures, the requirements shall be applied accordingly. Recording Panoramic photos  The device shall offer the ability to record cylindrical photos.  Panoramic Photos shall be stored in a compressed mode to limit memory requirements.  Panoramic Photos shall be recorded in a way that a full 360 degree ‘cylinder’ is recorded or a fraction of the complete 360 degree view.  Resolution and quality shall allow zoom in to see details.  Panoramic Photos shall be stored in a location on the device that is easy to find and to select for further operation (e.g. sharing).  Recording a Panoramic Photo shall be limited to approximately 360 degree circle. If the user stops recording of the panoramic photo before the 360 degree circle is complete, requirements for recording, viewing and sharing shall be valid accordingly. Viewing Panoramic Photos  The device shall display Panoramic Photos in a user convenient way.  The picture shall be displayed in full display size view of a fraction of the full picture, i.e. the picture is always displayed in full height, areas left and right of the displayed areas can be selected. Black barred areas of the screen shall be avoided. Figure 6: Maximum zoom out (device in portrait mode

Android endorsement pointer The endorsement xml file shall be signed by the endorser (MNO) and the signature shall be included as an “endorser” element inside the “endorsement” tag included into the extension descriptor. B.3.9.3 Endorsement XML document This document is used by the Plug-in publisher to declare what is endorsed by the endorser. The package name, version (and version range), signature and the need for clear addresses are all declared and subject to be signed by an endorser. The endorser provides its signature for the given endorsement xml (after appropriate audit and verification). This signature provided by the endorser shall then be included into the Plug-in descriptor. NOTE: a Plug-in publisher can have multiple endorser. All endorsements are inserted into the Plug-in descriptor.

[Anonymous]

Hi please sign the petition for Note 9 series


https://www.change.org/p/change-org-to-get-what-we-deserve?recruited_by_id=1bf27000-7971-11ea-9d4b-3...